#phpcon 2025 に登壇しました
はじめに
表題の通り、 PHP Conferenceに登壇しました。
ぺちこん登壇は2年ぶり2回目でした。
発表したこと
Webブラウザのレンダリングエンジンという、Webページを描画するソフトウェアについて詳しく発表しました。
レンダリングエンジンについては、ネット上の参考資料が豊富なため、この資料のAppendixから深堀りすると良いと思います。
(レンダリングエンジンの挙動について、図解した資料は少なかったため、下記資料はそれらを補えているはず)
発表のモチベーション
世は大AI時代、、、(AIを使い倒すことは前提だが、)コンピュータサイエンス(以下CS)に通ずる基礎がある前提だからこそ、LLMの回答をジャッジし、初めて仕事のアウトカムにできるよな、、
AIは調査 & 壁打ちに使うけど、CSの基礎がないとLLMに振り回される、、、
まずはCS力を少しでも補強したい、、と思い、「使ったことはあるけど中身をよく知らない巨大なソフトの仕組みを理解できれば、とりあえずCSを理解する地力は得られるのでは?」と思い立ち、ブラウザの実装について深堀りしてみました。
※ つらつらとモチベーションを並べたが、「よく使っているのに知らないのは気持ち悪い」とか「知りたい!」の部分が大きかったかも
振り返り
pros
- 図解のため、「めっちゃわかりやすい」との評価はいただけた。
- なるべく読ませないスライドを意識したため、時間をかけた甲斐はあった。
- 資料としては完成度が高かった
- 発表時間が会場の最終枠だったため、会場下見やスライドの微調整の時間が多めに取れた。
- 初めて25分間セッションをやりきった。
- 実業務をやりつつ上記をやるのは結構大変なので、(外向きに見ても)ある一定の実績にはできるはず。
cons
- お客さんが入らなかった。
- 他のセッションが多かった、というのも一因かもだけど、やっぱりテーマがニッチ過ぎた (正直資料見とけばそれでいいや、、となってしまった)
- 資料作成が大変すぎて、しぬかとおもった
- 業務が忙しい中で67枚スライドを作り、HTML仕様書などを見て「本当に内容に間違いがないか?」 をチェックするのが大変だった、、、(テーマのコスパが悪かったかも、、、)
- 当日の発表3時間前に完成した、、、
- 土日のいずれかは資料作成に潰していたので、ワーク & ライフともに効率が悪いのは明白、、
next action
- テーマをトレンドに合わせてみる
- 最近のトピックで最もホットなのはAI、というのは事実。
- みんなが悩んでそうなテーマを考えてみる
- 懇親会であった方々は、だいたい弊社と同じような悩みを持っていた(チームのサイロ化とか)。それに対してアプローチした経験を語ってみるとか?
- 知識ベースでなく、自分の体験ベースを語る
- どこにも書いてないので、聞きに行かないと聞けない
面白かった発表
正直スライド作成が大変すぎて他の発表をあまり見れてません(本当にすいません)
その中でも下記のLTは特に印象に残った。
話の聞かせ方も巧みで、「奥さんに怒られないように」とかフフッと笑える話 & 技術的な話を織り交ぜ、5分のLTに引き込まれた。
まとめ
めちゃくちゃ大変だったけど、チャレンジした甲斐はあった。 (やらなかったら後悔してたはずだし)
next actionを実行しつつ、近い内に何らかのカンファレンスで登壇したい。
以上。
2024年の振り返りと雑感
はじめに
2024年は仕事面で変化が大きく、メンタルが落ちる場面もあったが、自身の美点/欠点の解像度を上げることはできた。
今年の経験をまとめ、来年の成長の糧とするため雑多に言語化する。
仕事面
前述の通り、とにかく変化が多く退職者が大量に出た年だった。
上記の変化は主にリモートワークの是非に対するものだが、世の中のIT企業は多くが出社に傾けているので当然の判断だと思う。 (私も環境が許されれば対面派の人間)
世の中の変化に対応すべく、 ビジネスマンとして事業にコミットし、積極的に責任ある立場に立ち、今まで敬遠していた分野にも挑戦したい。
社外での取り組み
今年はOSSにPRを送り始め、24個マージできた。
Pull request search results · GitHub
数をこなせた点は良かったが、やはり小粒目なバグ修正 and 機能追加にとどまった。
来年は(仕事を主軸に置きながら)、数を絞り、リポジトリのメインストリームに還元したい。
登壇はメンタル的にも負荷がかかるのでPHPerkaigi 2024のLT一本のみだった。
趣味面
膝の不調が長引き、四日市ジャズは無理して出演したものの、それ以外はからきしだった。
その代わり、ピアノにふれる時間は増えたものの、去年ほどのペースではさわれていない。
練習方針を見直したほうがいいかも。
具体的には、
- 30分で集中してやる
- 曲の全部完成を目指さず好きな8小節を繰り返し練習する
などの、練習よりもピアノと遊ぶ的な考えにシフトしたほうがいいかも。
その他プライベート面
健康面
リモートワーク続きで足の筋肉が極端に落ち、膝を痛めてしまった。
片杖でのウォーキング、スイミングなど、平日は頑張って運動を続けた結果、かなり良くなってきた。
この調子で細マッチョになり、ドラムを自由にたたけるようになりたい。
人生設計面
ソフトな観点
リモートワークで極端に人と会話しない & 資産形成のため財布の紐がかなり固くなっている、などの原因も相まって、リアルのコミュニケーションが減っている。
ただ、土日に同世代と喋る機会はなくはないので、そのような機会をさらに増やし、ネットを介さない対人スキル向上に務める。
ハードな観点
資産形成は町外さんレベルの見通しがついたが、将来的な円の価値が暗闇すぎるので、それに備えて外貨建て貯金を始める。
また、人生の極端な不確実性に備えるためにも、金を稼ぐスキルの強化に努めたい。
次にやること
- 挑戦する
- 仕事で責任を取りにいく
- 各種団体に顔を出し、積極的な行動によるGiveを実施する
- プライベートで、人と喋る
- 健康第一
- 日をまたいでOSSにパッチを当てるとかは辞める
- 自身の健康をベースに仕事/プライベートが成り立っていることを忘れない
- 心配を引きずらない
- 経験上、心配事の9割は起こらなかった
- そんなメンタルを築くには貯金の効果が絶大
- 人と喋る機会を増やす
- 仕事/プライベート両面でコミュニケーションに課題がある。そのため、まずは他人の価値観など双方向のコミュニケーション機会を更に増やし、慣れていく。
- 無理に読書量を増やそうとして脳がパンクしている。なにかに影響を与えるための読書がしたいので、まずは自身の頭の中を言語化するスキルを磨く。
最後に
俺おつかれ！！！！！！！！！！！！！！！！！１１１１１１１１１１１１１１１１１１１
【読書メモ】わけるとつなぐ
業務中、自分が提出した行動計画に納得感が持てず、上司に勧められ下記の本を購入。
いつも通り上から目線の読書記録としてメモ。
感想
自身のキャリアの中では、ちゃんと考えて実装したの?、のような詰められ方をする経験が多く、自分なりに悩んでたんだけど、、、そもそも何をすればちゃんと考えたことになるの？、と悶々としていた。
この本では論理的思考(≒筋が通っている)はすべて 「わける」 + 「つなぐ」で説明できる、とあり、小説形式で読者が納得できるよう設計されいる。
また、難しそうな横文字用語もほとんど出てこないため、実際の業務でもいろいろな場面で即応用できる考え方だと感じた。
注意点としては、読みっぱなしは避け業務で即応用すべき。なぜなら実務で実践して初めて価値の出る書籍なので。
まとめ
今回は「わけるとつなぐ」を読んだ。
1~2時間あれば読める本なので、難しそうな本に手を出す前にぜひ読んでほしい。
以上。
PHPerKaigi 2024に登壇してきました。
タイトルの通り、PHPerKaigi 2024にルーキーズLTで登壇してきました。
登壇内容はこちら
スライドはこちら
反省
- 前回登壇した PHP Conference 2023 とは違って、カンペを見ずにスライドを読んだので、お客さんの反応を見ながら発表できた。
- 映像形式ではあるが、音を出すデモが成功してお客さんのインパクトは残せた。
- 会場のテンションに引っ張られて若干早口になってしまった。
- 映像形式でなく、実演でデモしたほうが良いのでは? という意見があった。
- 5分間だと伝える内容の深さに限界を感じ始めた。
聞いた発表のメモ
新たな言語の勉強の一貫として、CLIツールの実装は試したことはあるが、突き詰めるとWebアプリ開発と変わらない奥深さを感じた。
特にUXの話? (人を対象とするか、機械を対象とするか、いずれにせよ使うのは人) は実装に夢中になっていると置き去りにしてしまうことが多く、今後予定している業務では特に大事な領域のため、常にユーザー目線を持てる活動(UXデザインの勉強など)を始めたい。
Wasmと言語処理系の実装にフォーカスしたトーク。
なぜWasmが流行っているのか(ポータブル、速い、安全)、言語処理系を実装する楽しさ(理解を超えたものが突然動き出す瞬間)、など著者の圧倒的な技術バックグラウンドに裏打ちされたモチベーションは説得力がすごい。(語彙力)
そのような領域に少しでも近づけるよう、日々少しずつ技術者として基礎学習(CSとか)を継続したい。
まとめ
有料のカンファレンスへの登壇は初めてだったが、UXの良さが段違いだった。(長谷川さんがすごすぎる)
また機会があれば、何らかの形で関わりたいと感じたカンファレンスだった。
(2日目は起きれず参加できませんでした)
次なにかのカンファレンスで登壇する際は、なんとかして15分~20分のトークをしたい。
以上。
【感想】世界一流エンジニアの思考法 を読んだ
世界一流エンジニアの思考法、を読んだ(１ヶ月前に)
成果の出し方などなかなかスマートな解決策や思考法が多く、プライベートでの振る舞い方なども参考になった。
ただトップダウンで開発案件が降りてくるような職場だと、そりゃそれが理想だけど、、、のように感じる部分もあった。
※もちろん、批判の文化など自分個人でなんとかなる部分は実践すべき
また、イケイケな会社にいる前提のtipsが多かったようにも思う。
※そもそもメンバー全員がCSの基礎があることが前提なんだろうか
そのため、もしJTCやSES勤務でしんどくて、本書に書いてあるTipsが通用しないと思ったら、まずは「なぜあなたの仕事は終わらないのか」を勧める。
どん詰まり状態から改善を繰り返してくtipsが細かに書いてある。
その後で「世界一流エンジニアの思考法」を読むといいかも。
※結局、あくまで一意見なので、内容が刺さりそうな方から読んでね
【読書】なぜあなたの仕事は終わらないのか
概要
会社から求められる動きが若干マネジメントよりになってきたこともあって、まずは自分の仕事を早くさばけるようになりたい、との思いから下記の本を購入。
なぜ、あなたの仕事は終わらないのか | 中島聡 |本 | 通販 | Amazon
色々と使えそうな部分があったため、メモ。
※読み切ったのは５日前なので、色々と記憶があやふやな部分があります。
感想
締め切りを守らない天才より、締切を守る天才
直前になって終わりません、は自分もよくやったんだよな〜とその度に上司の青ざめた顔を思い出した。
これは何も徹夜して終わらせろ、という意味ではなく、10日の仕事は2日で8割終わらせる(つもり)でそのタスクの見積もりをする、のが良いという考えだった。
特に自分は不確実性の高いタスクについて調査しまくってしまう傾向があり、とにかくやってみる、というのも見積もりの一つと捉えるといいかも。
もし最初の２日で8割終わらなかったらタスクの締切調整を上司に連絡する、というのも上司目線では重宝される部下だよな〜と思った。
これはアジャイルの「早く失敗する」の考えそのものに思えた。
すべての仕事はやり直しになる
自分もPRなども完璧を目指しすぎるあまり、時間をかけすぎてしまう傾向があるんだよな〜。
でも前前職の上司は完璧主義でほんとめんどくさかったなあ、、そういうときはどうすればよかったんだろう(組織風土も多分に影響してそう) (自分は結局すぐ転職したけど)
午前中に一日の仕事の8割を終わらせる
これも大事。
自分も残業するし午前中はダラダラ仕事するか、、、なんて愚の骨頂な考えに囚われそうになるが、やっぱり午前中のほうが集中力も段違いだし、そっちのほうが効率いいに決まってるよね。
じゃあ午後はなにをするのかというと、前述のやり直しになった仕事の完成度を上げる時間や、自分のやりたい仕事に使うのが良い、というのもなるほどなと腑に落ちた。
勉強のための勉強はするな
自分は、俺ってこんなに勉強してるんだぜムーブをかましまくってる。ただそれの目的がないってのも結構やりがち、、、(そして大抵続かない)。
集中しなきゃいけない仕事なんかするな
好きなことに対しては勝手にやるし勝手に集中して続けられる。
でもそのような「好きなこと」を見つけるにもやっぱりインプット(勉強、すごい人と話す、とりあえずやってみる)は必要だよね。
著者は高学歴だし。
でも本書を読んでもどうせ内容は覚えてないんでしょ？
はい、そうです。
でも筆者が 絶対にやるべきは「寝る前に明日のタスクリストを作る」の一点だけは実践してほしい、人生を変えたいなら、 と断言しています。
でも寝る直前に仕事のこと考えたらストレスで寝れないんだが、、、と思ったりもしたが、寝る前とは退勤前でもいいよな？と拡大解釈すれば簡単に実践できそう。
まとめ
著者が天才すぎて一般人の実践は無理なんだが、、、と思った部分もあったが大部分は凡人でも実践できそうな考え方も多く、ためになる本だった。
以上。
【読書ノート】システム設計のセオリー を読んだ
社内で求められる動きがマネジメント?っぽい役割になってきたので設計のやり方等を俯瞰すべく下記の積読を消化。
仕事で色々あって２ヶ月かかったが、通読できたのでメモ。
概要
エンタープライズ系の硬めのシステムを中心に、ウォーターフォール開発のシステム設計について全体を俯瞰できる本。
自分はコーディングやリファクタなど、いわゆる後工程に携わってきた人間なので、要求分析などの知識不足を痛感していた。
この本を読めば伝統的なウォーターフォール開発でやることはリストアップされ、タスクの解像度が上がるはず。
それぞれの工程は前後でトレースできることが徹底されているため、複雑で手がつけられなくなった既存システムの仕様解析なども対応できる。
対象読者はIT業界3年目程度と思われる。
読み方
前半は「情報システムの使命」などかなり大事な考え方が書いてあるため一旦前半を読んだ後、設計の進み具合に応じて対応する章(データ設計, プロセス設計など)を読めば良さそう。
ぶっちゃけ１章を読んでおけば後は必要に応じて、という感じ。
参考に読書時のメモは下記。
終わりに
自分が関わったPJではアジャイルだからと、あまり設計せずに突き進んで後で痛い目を見る、、、なんてことがあったような、、、
若干古い本だが、積読を掘り起こした甲斐はあったと思います(毎度偉そうにすいません)
