PHPer Kaigi 2026 に参加した #phperkaigi
PHPer Kaigi 2026 day1, day2 に参加しました。 今回初のPHP系のカンファレンス、大きいカンファレンスはJSConf JP 2025以来半年ぶりでした。
拝聴したセッション
Specificationパターンという新しい知識を得られたことと、条件分岐の整理を現実にどう活用していくかという事を考える思考過程が参考になりました。
CIのパフォーマンス改善は、テストだけでなくDBやインフラまで関わる総合格闘技だなと思いました。DB周りのボトルネックを解消方法で気付きがあったので早速試してみたいです。
nrsさんの発表はこういう違う分野が抽象化すると同じだよねっていう気づきを与えるもので、いつも聞いていて面白いなと思っています。
Flakyテストの課題と対処法の整理が素晴らしく、このスライド資料を前提にチームで議論すれば良いとも思える内容だった。 特に、テストは期待調整をできる（いらないケースは消しても良い）場合があるというのは、忘れがちだけど大事な視点だなと思いました。 質疑応答で「テストに助けられたことが多いので、テストへのモチベーションが高い」と話されていて、共感しました。
技術的な話も面白かったですが、何よりこれを入社してからガツガツやっていく姿勢に刺激を受けました。 イシュー度の高い課題を見極めて取り組んだと話されていて、自分も勘所を身に付けたいと思わされました。
多摩devでお世話になっている直吉さんの話。チームでオーナーシップを持って取り組める方法として手札が増えました。5分とは言わずもっと聞きたいなと思いました。
雰囲気、交流
セッティングランチ（参加者4人ぐらい集まってお昼食べにいく企画）で初めましての人とご一緒したり、アンカンファレンスを聞いたりして過ごしました。こういった自然にいろんな人とコミュニケーションを取れる仕組みが企画して用意されているのは、初参加者のハードルを下げると思うので非常にありがたかったです。
ランチマッチングでオススメのパスタ屋さんに来たら店内半分PHPerでした😆✨ #phperkaigi pic.twitter.com/XBzhLqC9r7
— ことみん@FE･PHPカンファレンス北海道 (@kotomin_m) 2026年3月22日
オフラインのカンファレンスのメリットを活かすべく、スピーカーに直接質問したり、感想が言えたりして過ごせたので、楽しめました。 懇親会も、初めましての方、お久しぶりの方などいろいろお話しできて楽しかったです。運営の皆様、ありがとうございました。
PS. まだまだ話したい人がいたのですが、それは次回の持ち越しとします。
ERBファイルでJavaScriptを書きやすくするVSCodeの拡張機能の紹介
ERB（eRuby、embedded Ruby）の HTML 上で JavaScript を書きやすくする VS Code 拡張機能を公開しました。
まずは実際に動作している様子を見てください。javascript_tag ブロック内に書いた JavaScript コードに対して以下の機能が利用できます。
- シンタックスハイライト
- コード補完
- ホバーによるメソッドの型や定義の表示
- 定義ジャンプ
本来、ERB ファイルに JavaScript を書いてもコード補完やシンタックスハイライトは効きません。 それを JavaScript ファイルでコードを書くときに近い体験として、ERB 上でも再現できるのが今回の拡張機能です。
開発したモチベーション
筆者は普段、Rails + Hotwire で画面を構築することが多いです。
Hotwire では基本的に Turbo の仕組みを利用して画面を作れます。 しかし実際の開発ではイベントハンドラーを追加したり、HTML のプロパティを付け外ししたりするために、ちょっとした JavaScript を書く場面もよくあります。
しかし、JavaScript を ERB ファイルに直接書く場合は、コードハイライトやコード補完がまったく効きません。 そのため、エディタ支援なしで書いたり、いったん JavaScript ファイルに書いてからコピペしたりして凌いできました。
ただ、こうしたやり方で JavaScript を増やしていくのは流石に大変です。解決できる VS Code 拡張機能も探した範囲では見つかりませんでした。 そこで拡張機能を自作することにしました。せっかくなら同じ問題で困っている人にも役立つかもしれないと思って公開することにしました。
仕組み
シンタックスハイライトは VS Code の TextMate 文法を利用しています。
javascript_tag ブロック内の JavaScript コードを正規表現で検知して、JavaScript として解析・ハイライトされるように設定することで実現できます。
補完やホバーの情報は、javascript_tag に書かれている JavaScript コードを TypeScript Language Service API に渡して取得しています。
取得した情報は VS Code Extension API で連携することで VS Code 上に反映されます。
VS Code Extension API で具体的に提供されているものはざっくり分けて３つです。
- Completion API コード補完候補を返すための拡張API
- Hover API カーソル位置の型情報やドキュメントを表示するためのAPI
- Definition API 「定義へ移動」を提供するAPI
それぞれに TypeScript Language Service API の情報を連携しています。
ぜひ使ってみてください
今は最低限の機能しか入っていませんが、今後は HTML 属性（onclick など）に書いた JavaScript にも反映させることや、簡易的な型チェックなど機能を増やしていくつもりです。 同じ問題でお困りの方はぜひお試しください。
設計に対するコメントや機能要望も歓迎です。
ネクストアクションを決めて仮説検証のサイクルを回そう
こちらは そーだいなる Advent Calendar 2025 22日目の記事です。
3行要約
- 行動しない「考えてみます」は無価値であり、必ず具体的なネクストアクションを置くことが大事
- 仮説に基づいたネクストアクションがあると行動後に検証できる。それが次の仮説につながりサイクルが回る。
- 特に若い方ほど、そーだいさんと1on1をする価値がある。
そーだいさんとの関係
そーだいさんは弊社の技術顧問として関わってくださっています。
社内メンバーではない立場から、常に一段引いた視点でアドバイスをいただける存在です。
技術そのものの相談というよりも、エンジニアとしてのキャリア観や仕事への向き合い方、考え方について相談することが多く、社内にいながら社外視点のフィードバックを得られる貴重な機会になっています。
そーだいさんに言われて印象に残っている言葉 「考えてみますだけで、行動しないのは意味がないよ」
2023年、最初の1on1で悩みを相談した際、自分は「考えてみます」と返答しました。
そのときに言われたのが、「それでは次のアクションが明確ではないから意味がない」という言葉でした。
大事なのは、振り返りできる行動を記載して、必ずネクストアクションを置くことが重要だと強調されていました。
ネクストアクションとは、例えば、
- 考えるための予定を入れる
- ブログを書く
- 誰かに聞く
など、「次に何をするか」が明確で、完了が判断できるものです。 行動がなければ仮説検証は回らず、結果として成長も評価も起きない、という指摘でした
実際に自分が取った（取っている）具体的な行動
最近の行動の手の内を明らかにするようで少し恥ずかしいですが、以下のようなことを意識的に行っています。
- 日報を書き必ず振り返りを入れる
- 紹介された本はその日のうちに注文する
- 社内エンジニアと1on1を行い、自分一人では得られない視点を取りに行く
- チーム内で筋が良いと感じた発言や判断をメモし、次に似た状況が来た際に自分も発言できるよう準備する
ここで意識しているのは、「達成できたかどうか判断できること」をネクストアクションにすることです。
「何かについて考える」といった曖昧なものではなく、「誰かと1on1を組む」「ブログを書く」など、完了条件が明確な行動に落とし込みます。
完了できるレベルまで分解することで、次に何をすればよいかが明確になります。
また、達成できなかった場合でも、なぜできなかったのか、どうすればできたのかを考える材料になり、それ自体が次の改善につながります。
行動を立て、早く実行し、検証し、その結果を次の行動に結びつける。
このループを回すことが何より重要だと学びました。
若い方こそそーだいさんと話すべき
自分がそうだったように、若手が感じる悩みや課題の多くは、すでにそーだいさんが考え抜いており、何らかの形でブログや登壇資料として言語化されています。
実際、1on1の場では、相談してからすぐに関連するブログのURLや資料が返ってくることがとても多いです。
若手のうちは、そーだいさんクラスの方と話すことに緊張したり、気後れしてしまう方も多いと思います。
しかし、だからこそキャリアが浅い段階で一度しっかり話しておく価値があると感じています。
社内に直接の接点がなくても、エンジニアの知り合いを辿ればどこかで繋がれる方です。
ぜひコンタクトを取ってみてください。
私もまた飲みに行きたいです。よろしくお願いします。
日報書くツール最適解の現在
このブログを読んで、「日々の新しい情報や調べたことをストック情報として保持できていない」と感じた。
そこで、情報をうまく保持できるようにするためのメモツールについて考えた記録。
Kaigi on Rails 2025 に「Web Components で実現する Hotwire とフロントエンドフレームワークの橋渡し」というタイトルで登壇しました #kaigionrails
先日 Kaigi on Rails 2025 で登壇しました。 登壇内容の相談や、会社で何回も練習に付き合っていただいてありがとうございました。 特に id:kozy4324 や id:kiryuanzu にはとてもお世話になりました。
資料に盛り込めなかった話の補足や反響に対する私見を載せます。
当日のTwitterの反応
反響への回答
custom element へのデータの渡し方が複雑じゃない？
custom element へのデータを渡すインターフェースは、HTML属性 と DOMプロパティ の2つです。発表では渡したいデータ型によって使い分けるように説明しましたが、どちらかに統一できた方がシンプルだとは思います。
仮に HTML 属性に寄せたい場合は、コンポーネント側で文字列を型キャストする必要があります。Angular なら transform という API が用意されています。
入力プロパティによるデータ受け入れ • Angular 日本語版
ただ、この型キャストもプロパティごとに実装するのが面倒になりそうだったので採用しませんでした。
その代わり、DOM プロパティを利用して JavaScript 側から直接値を渡しました。これなら文字列以外も扱えます。 ただし、この方法は inline script が必要になるため Strict CSP（特に script-src 'self'） が使えません。*1
CSP によりセキュリティを担保したい場合は、DOMプロパティは使いづらいと思います。
今回 custom elements を採用したのは新規サービスであり、コードベースも小さいです。そのため、セキュリティ的にまずいコードが混入しないようにレビューで担保できるので成立していると思っています。
データ属性に配列やハッシュを入れるとき、もっと良いサニタイズ方法はない？
正直なところ、現状は難しいと思います。サニタイズしつつ、ちゃんと動作するコードにするには少なくともの要件を満たす必要があります。
- HTML として正しいこと
- JavaScript として正しいこと
- ERB（Ruby）として正しいこと
この条件を同時に保証する API はなく、自前で作るのも大変です。なので「data 属性に文字列として入れて、JavaScript 側で JSON.parse する」のが現実的だと思います。
もし属性が増えて管理が面倒なら、script 要素に逃げるのではなく HTML 属性の工夫で対応するのが良いと考えています。*2
custom element を自作するとメンテナンスコストが高くない？
ここは設計次第です。うまくカプセル化できれば再利用性も高く、コストは抑えられます。逆に安易に作るとコストは増えます。
また、そこまで作り込むなら Hotwire で自前実装するのも選択肢です。私たちのチームは Angular の知見を持つメンバーが多かったので、custom element 化することで既存の知識を活かせるメリットがありました。チームのスキルセットや環境によって最適解は変わると思います。
こぼれ話
今回初めての登壇で半分病みかけながら、準備をしました。できうる準備はして望めたので、それは良かったかなと思いつつ、今後に活かしたい改善も見つかりました。そのあたりは別でまとめるかもです。
いろんな方に声掛けられまして、「初めて custom elements 知った」「今度使ってみたいといった」声を届けてくれた方々がいて嬉しかったです。 登壇者は正直大変でしたが、その分コミュニティと繋がれた感覚が味わえて、またやりたいなと純粋に思いました。
あとは、懇親会で大倉さんとお話しできる機会がありまして、採択理由やコミュニティの話ができました。今後も Web 標準を追っていくモチベーションが湧きましたし、コミュニティや勉強会を主催したくなりました。*3 ありがとうございました。
色んな人と話して自分もコミュニティ欲しかなった。多摩でやるかー！
— daichi (@da1chi24) 2025年9月27日
同世代のレベル高い発表を見て、刺激ももらいました。自分も今日から良い発表ができるように日々の活動頑張ります。
最後に、Kaigi on Rails を主催していただいたオーガナイザーの皆様ありがとうございました。
「わかったつもり」を乗り越える本の紹介
2024年の"推し"本 Advent Calendar 2024 の 7日目の記事です。昨日はまつーらとしおさんでした。
今年読んだものの中で、特に推したい本として『わかったつもり 読解力がつかない本当の原因』（以下、本書）を紹介します。
本書を読むと、今まで読んだ本をまた読み返したくなります。
読解の最大の障害は「わかったつもり」である
本書は、小学2年生の教科書に掲載されている物語を読むところから始まります。その物語は平易な文章で書かれており、特に詰まるところがなく全て理解できている感覚になると思います。おそらく、これ以上同じ文章を読み返そうと思わないはずです。
しかし読み進めていくと、すぐに物語の読み込みが甘かったことに気付かされます。なぜ最初に読んだタイミングで物語を読み返す気にならなかったのか、それは「わかった」状態になってしまったことが原因であるというのがこの書籍の主張です。
「わかった」状態は、ひとつの安定状態です。ある意味、「わからない部分が見つからない」という状態だといってもいいかも知れません。したがって、「わかった」から「よりわかった」へ到る作業の必要性を感じない状態でもあるのです。浅いわかり方から抜け出すことが困難なのは、その状態が「わからない」からではなくて、「わかった」状態だからなのです。
「わかった」状態とは、よくエンジニアでいう「完全に理解した」に近いかもしれません。全てを理解している、いわば全能感に浸っているような感覚です。 ただ、一旦その安定している状態になると、もう一歩深く理解することができなくなってしまいます。
「わかる」から「よりわかる」うえで必要なのは、「わかったつもり」を乗り越えることなのです。「わかったつもり」が、そこから先の探索活動を妨害するからです。
この状態をどう脱していくかは、文章を読む上で非常に重要なポイントになります。
「わかったつもり」を乗り越える方法
「わかったつもり」状態から抜け出す方法がいくつか紹介されています。1つは「矛盾」や「疑問」を見つけることです。一見すると「矛盾」や「疑問」を見つけると、文章の内容を理解できていないネガティブな印象になりがちです。しかし実はその発見が、次の「よりよくわかる」ためのきっかけになることがあります。
「矛盾」や「疑問」は、次の「よりよくわかる」ための契機となるものです。「矛盾」や「疑問」はネガティブに捉えられることも少なくないのですが、むしろ次の解決すべき問題を発見できたという意味で、「認識の進展」という観点からはポジティブな存在なのです。
ここはしっくりくる内容でした。文章を読みながら疑問を見つけると、自分で内容を検証したり、整理して読み直したりしたくなります。文章を素直に読みすぎず、違和感を見つけるプロセスが「よりよくわかる」に繋がるというのは納得感がありました。
この他にも「わかったつもり」状態から抜け出す方法として、要注意ワードを見つけることや文脈を整理することなど、色々なテクニックが紹介されています。本書では、これらのテクニックを実際の題材の文章を読みながら紹介しています。そのため、腑に落ちやすいと思います。
読解とは終わりなき探求
最後に一番刺さった内容を紹介して締めようと思います。
「わかったつもり」の状態から、「わからない」状態などを経由して、「よりよく読めた」状態に移行できれば、それで読みが終わるわけではありません。自分でかなり読めた、読みの進展があったという文章に、しばらくして出会ったとき、そこに、新たな「わからなさ」を見いだしたり、部分間に関連をつける新しい解釈を思いついたりすることは、珍しくありません。（中略） つまり、「よりよく読めた」という状態は、「以前よりはよく読めている状態」かも知れないけれど、その状態を乗り越えるための、もっとよい読みが存在するのです。
文章は一度読んで終わりではありません。特に名著や名文は何度も読み返すことで、その度に新たな発見や学びに気づけるものです。 より良い読み方を学ぶと、新しい本だけではなく、今までの本もまた読みたくなると思います。
ここまで読んで本書の内容を「わかったつもり」になっていませんか？ 気になる方は、ぜひ『わかったつもり 読解力がつかない本当の原因』を手に取ってみてください。
ありがとうございました。2024年の"推し"本 Advent Calendar 2024 、次はうーたんさんです。
Google Engineering Practices Documentationを読んだ
先日、会社の同僚の方に勧められて Google Engineering Practices Documentation の Google’s Code Review Guidelinesを読んだ。
このドキュメントは、Googleが様々なプログラミング言語やプロジェクトで培ったベストプラクティスのまとめをオープンソースとして公開しているものである。Google’s Code Review Guidelinesはレビュアー用のガイドとレビュイー用のガイドに分かれている。
ちなみにこのドキュメントには非公式な日本語翻訳もある。自分は基本こっちを読みつつ、わかりにくいところは原著にあたるようにした。
google-engineering-practices.translation.shuuji3.xyz
それぞれ内容も多くなく、全体として数ページしかないのでサクッと読みやすかった。
また内容もコードレビューの基準、期待値、レビューの進め方、レビューのスピード、レビューコメントの書き方など多岐に渡っている。実際に明日から取り入れられるような具体的なHowも書いてあるので、理解しやすかった。またレビュー時の反対意見の書き方や不満が生まれてないような振る舞い方などにも触れている。経験に基づいた内容だと感じた。
明日からできることを考える
このガイドラインを守破離の守として、具体的に明日からのコードレビューでできそうなことをNext Actionとして積む。
- PR に対してシステムが今よりも良い状態になっているのであれば、Approveする。完璧を求めない
- PR を読むときは diff だけではなく、システム全体のコンテキストから妥当かを判断する。
- PR に何か優れたところがあったときには、コメントやチャットで伝える。
全部やるのは難しいので、適宜見返しつつやろうと思う。
感想
人間は知ったかぶりをしてしまう生き物だと自覚しておきたいなと思った。
PRを読んでいてなんとなく合ってそうでApproveするには一番避けたいし、ありがちなことだと思う。例えば、よくわからないアーキテクチャや知らないメソッドが出た場合は、その都度調べることができるので理解は進む。しかし、なんとなく知ってるメソッドだったり、他のリポジトリで使われているコードだったりすると、そもそも疑問が湧かない。なので特に調べずに、わかった気になってしまう（結果 Aprprove してしまうこともある）。
エンジニアリングの文脈ではないが、最近読んだ本にも似たような話が書かれていた。
一歩深いレビューをするためには、自分でもドキュメントを読んだり、実際に手元で動かしたり（動かしたログを読んだり）して、ある種批判的に見て行く必要があると感じた。抗いたい。
