PHP カンファレンス 2025 に参加しました。
- イベントの概要
- イベント参加の背景
- セッション
- ブース
- その他
- まとめ
- おまけ
イベントの概要
PHPの未来を形作る
PHPカンファレンスは、PHP関連の技術を主とした技術者カンファレンスです。 2000年に日本のユーザ会によってPHPカンファレンスが初めて行われ、今年で26回目の開催となります。 これからPHPをはじめる方から、さらにPHPを極めていきたい方まで幅広く楽しめるイベントになるよう様々なプログラムをご用意しております。
引用：
イベント参加の背景
- 昨年末に参加したPHPカンファレンスの学びが多かった。
- PHPコミュニティの文化に魅力を感じている。
- １日通して聞きたいセッションがあり朝から参加！！
セッション
1. PHPの今とこれから 2025
メモ
新しいPHPバージョンと界隈の話。
PHPとはWEBアプリケーション中心に使われているスクリプト言語。
サーバサイド言語としては74.3%占めている。
PHPは今年６月に30周年を迎えた。
PHPはボランティアベースで動いている。
PHP財団。Nikitaさんが2021年に離脱。属人化を防ぐためにFoundationを設立。
2012年。PHP5.4でモダンな開発言語となった。
2016年。PHP7.0で大幅に高速化された。
2022年。PHP8.0 JIT導入された。
現状、PHP7と8が全体の利用の4割を占める。EOL版は6割。
PHPの各バージョンのライフスパンは4年。8.1は25年末でEOL迎える。
PHP8.5。α版は7/3,17,31。正式版11/20リリース予定。
PHP8。より早く、快適になっている。特にJITの効果が大きい。
8.5で主に変わること。
・パイプ演算子で一連の処理を結合できるようになる。
・cURLによる脆弱性の可能性が無くなる。
・非対称なプロパティ可視性をstatic変数に拡張
・コンストラクタでfinalを利用可能に
・clone時にreadonlyプロパティの設定が可能に
FRANKEN PHP。爆速。Foundationから公式サポートされている。
感想
はじめてPHPの文化・背景・文脈を知ることができました。
自分はJavaで育った人間ですが、バックエンド開発でPHPがしめる率に驚きました。
バックエンド開発について考える時や誰かと会話する時に、意識しないとズレが生まれそう。
JITの話も興味深かったです。先日のTSKaigiでの10x fasterの話も興味深かったけど、開発するときとプログラムが実現されて行く時のタイムラグはどんどん減っていると感じました。
特にこのスライドがPHPに対するイメージが持ちやすく素敵でした。
2. AIエージェントはこう育てる：GitHub Agent導入・活用・共進化のリアル
メモ
プロポーザル時点ではCopilot Agentが最適だと思っていたが、
現時点ではClaude Codeを導入検討すべきかもしれない。
Copilot Agentは、開発者とのやり取りにおける自律性の面から、はじめてのAIエージェントとしては適している。
・AIエージェントの利用は全員でやる。
・IssueやPRの作成から改善していく
・Copilot用のドキュメントのメンテナンスに注力する
AIエージェント導入に当たるハードル。
採用判断。取り組みに対する温度感。
チームで習熟度を合わせるためのサイクルを回していく。
解消すべきこと。
・Agent導入
「VSCodeインストールして、GitHubにつなげばOK」とはしない。
細かいステップでできる／できない分かれるので、みんな共有しながらやる。
システムプロンプトをあらかじめ用意しておく。
・prompt整備
使いこなせる／こなせないの分断を避ける。
さぼりやすい。時間がかかるissue、PRの作成から適用する。
プロンプト運用コツ。
目的を細かくして作る。入力指示減らす／次のプロンプトを明示／練習用ディレクトリ用意
・infrastructionメンテナンス
目的に合わせて作業指示、PRごとに改善を検討する。
開発に関する知識や情報だけではなく、テーブル定義・API仕様書なども入れる。
感想
チームで足並みを揃えて段階的に導入していく重要性を感じました。
できる人ができれば良い訳ではもちろんなくて、むしろAIが今まで単純だけど労力がかかってきたような作業を持っていってくれると考えると、チーム全員で捉えていくべき。
それを実現するための取り組みが素敵だと思いました。
セッションの本質からは離れるけど、これがコドモンさんに所属の方の発信というのも、保育園に通う娘を持つ親としても嬉しく思いました。
3. 純粋 vs 副作用 〜 PHPはなぜ難しいのか？
メモ
PHPの関数は数学っぽい関数。
同じ引数を渡すと結果が同じになる。戻り値は使わないと無駄。
ユニットテストは期待値と結果を比較してチェックする。
PHPの関数には種類がある。
いつの間にかどこかの何かの影響を受ける。
罠。
・呼び出すごとに結果が変わるかも知れない。
・呼び出すごとにどこかに影響を及ぼすかも知れない。
PHP初心者が何も考えず作るとテストしにくい関数になる。
制御できないものは制御できるものにしていく。
副作用がある部分を切り離し、テストしやすい状態にしていく。
アーキテクチャは必須ではない。純粋関数を目指す。
純粋関数＝参照透過性。副作用を持たない。
仕組み＝PHPStanで判定する。PHP Doc@pureタグ使う。
純粋じゃなくても戻り値が重要な関数はある。
NoDiscardする。戻り値を無視したくないものに適用するとチェックしてくれる。
感想
私がいま開発に利用している言語はPython、TypeScriptですが、こうした言語に対した認識はチームの共通認識として持ちたいと思いました。
そして、PHPStanやNoDiscard気になります。
4. PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
メモ
TDD。テスト駆動開発。アジャイルソフトウェア開発手法。
TDDを拡張したものがBDD。振る舞い駆動開発。
TDDでは要求仕様をもとにテストを書く。
要求仕様とは顧客やユーザーのニーズや期待を具体的に言語化したもの。
ふるまい駆動開発は要求仕様を自然言語で記述したテストコードをもとにステークホルダ間で要件に対する合意を取ったうえで開発を進めていく。
PHPではBehatが使える。Behatで自然言語を定義し、Seleniumで検証する。
日本語で丁寧にテストコードを記載することにより、何を目的としたテストか分かりやすい。
振る舞いとは。（マーティン・ファウラー参照）
GWTに沿ってユーザーストーリーを整理する。
ビジネス指向テスト。エンジニアに限らず巻き込んでいく。
求められているのは顧客への価値。
振る舞いを意識しないと、作り方の保証に寄ってしまう。
感想
振る舞い駆動開発をコードで実現していく姿を初めて見ました。
実例マッピングやそれをGherkin（ガーキン）に落とし込んでいくところは意識できていましたが、それがコードで表現される姿を見ると、改めてシステムがどのように動くかを定義したドキュメントとしても価値が高いと思いました。
Playwrightとかでやってみたいと思いつつ、ハードル高く感じていたため、コードを見て理解できるのは嬉しい体験でした。
5. PHP開発者のための SOLID 原則再入門fortee.jp
メモ
５分でやろうとしたが無理だった。その拡大版。
原則＝絶対的なルール、ではない。
SOLID原則の恩恵。
・安定性・安全性
・拡張性・変更容易性
・テスト容易性
・保守性・可読性
代償。
・設計実装コストの増加
・学習コスト
・さじ加減
ただ、AIによってほぼ解決される。
DRY原則。SOLID原則を理解する上では不可欠。
Don't Repeat Yourself。
同じ知識を繰り返し書くことを徹底的に避ける。（コード重複はOAOO原則）
・単一責任の原則
機能にいくつも詰め込まない。軽率に使いまわさない。
・解放閉鎖の原則
機能追加の際、既存コード変更せず、新しいコードを追加することで対応する。
ストラテジパターン、DRY原則がポイント。
・リスコフの置換原則
メソッドの事前条件／事後条件増やさない。
オブジェクトの不変条件を変えない。
メソッドが投げる例外の種類を増やさない。
・インターフェース分離の原則
目的によってインターフェースは分けて、関心を集中できるようにする。
・依存性逆転の原則
上位モジュールは下位モジュールから何もインポートしてはならない。
上位下位に問わず、実装ではなく抽象に依存すべき。
DI。腐敗防止層の導入。クリーンアーキテクチャ。
SOLID原則は銀の弾丸ではない。
ただ、勝ち得るための手段として取捨選択する。
感想
SOLID原則、何度聞いても勉強になります。
そして、何度聞いてもリスコフさんだけ名前なのが気になります。。
今、若手エンジニアととりあえず単一責任の原則について実践していこうという抽象的な取り組みを始めています。
ただ、私の言いたいことには、リスコフさんの言いたいことも混じってる気がします。
チームでSOLID原則についてだらだら語る会とか開催すると面白そう。
6. モブワークによるSECIモデルの実践
メモ
モブプログラミング。皆でパソコンを囲んで開発をする。ペアプロの拡大版。
ドライバーとナビゲーターの役割を交代しながら、全員で学び成長し課題解決力を向上させる。
利点：知識共有、コード品質向上、学習機会の増加、問題解決力の強化
結果、知識・品質・スピードの面でチーム全体が強くなる。
モブワークはプログラミングに限らない。
問題自体が曖昧、解決方法も複数存在する問題に適用する。
モブワークにおける効率に対する考え方。
リソース効率を見ると悪手。フロー効率を目指すプラクティス。
なぜモブか？「個人vsタスク」から「チームvs問題」へ意識を変化していける。
SECIモデル。モブワークと親和性高い。
４つのプロセスがぐるぐる回ることで知識が発展していく。
1. 共同化（Socialization）
暗黙知を直接共有する。
重要：心理的安全性、意図的な体験設計。
2. 表出化（Externalization）
暗黙知の言語化。暗黙的なものを言語化、論理化する。
重要：何でも聞ける雰囲気。見える化、言語化。
3. 連結化（Combination）
形式知と形式知をつなぎ合わせる。異なる解決方法を統合する。
協働編集ツールで組み合わせていく。
重要：多様性。実践重視。
4. 内面化（Internalization）
学んだことを経験にして無意識に使えるようにしていく。
既にやったことがあるものはソロワークに移行していく。
段階的に実践。フィードバックサイクルを回していく。
学びを深めるには場当たり的にではなく、意図的なチームとしての実践の場の設定が必要。
まったく初めてのものごとをチームで捉え、気づきを共有し、新しい知識をチームで得ていく。
そうして覚えたことは記憶に残っていく。
モブワークは、知らないことを一緒に発見する場になる。
感想
突き詰めて考えると、チームで開発する上でモブを前提にした方が良いと思いつつ、その実現を提案するにも大きな圧力を感じるのは、結局は考える人作る人の関係や受発注という役割が邪魔しているように感じました。
ただ、モブワークで複雑性や不確実性が高いものをチームが扱える状態にしたら、ソロワークに移行すればよいという話は目から鱗でした。
難しいPBIはまずモブワークで、のように臨機応変に対応することで、目に見えぬ圧力は弱めることができる気がします。
チームが成長していけるプラクティスとして取り組んでいきたい。
7. なぜ「共通化」を考え、失敗を繰り返すのか
メモ
共通化とは。
各機能で共通して表れる処理を１つの共通処理として纏めること。
共通化によってサービスの成長を加速したい。
共通化がうまくいかないと、サービスの成長を遅くさせる。
共通化の失敗例。似たコード集めただけ。
明確にふるまいが異なるものを１つに纏めている。
作り方目線で汎用的。
実装者間で同じ認知にない場合に目的があいまいな場所にメソッドは作られやすい。
共通化の言葉に振り回されていないか？
言葉の意味が広い。一定の制限を設けることが重要。
全体を俯瞰し、影響を意識し、最低限コストと効果のトレードオフを考え、少しずつ進める。
ふりかえる機会を定期的に設ける。
感想
「共通化」が抽象的過ぎてコンテキストに依存しやすいことが問題と思いました。
共通化は手段であって目的ではない。また、共通化は対象があってこそ実現できる。
ドメインベースで同じ領域内での共通化を考えられるようなコミュニケーションや制約が重要だと理解しました。
8. イベントストーミング図からコードへの変換手順
メモ
モデリングって結局どれがいい？
勝ち馬に乗りたかった。イベントストーミングに全賭けした。
イベントストーミング。
大きく２つの始め方がある。ワーキングセッションとヒアリング。
ビジネスプロセスモデリングの次にはシステムモデリングがある。
図ですべてを表現する必要はない。役立つドキュメントとして活用する。
感想
成瀬さんのお話はいつも分かりやすくて面白いです。
少し前にチーム開発のためにロバストネス図を採用した際に、拡張していくシステムに追随するために課題を感じました。
ストーリーを起点にシステム実装へ落とし込めるイベントストーミングの方が合っているのかも知れない。
もう一度動画を見直して、理解を深めたいと思います
ブースでも成瀬さんとお話しできてほくほくでした。娘がいつも保育園でお世話になっています。
9. 設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
メモ
背景。３部作。
①モジュラーモノリス②クリーンアーキテクチャ③オブジェクト設計
今回は３部目。
オブジェクト思考で書きたいときに参照。
リーダブルコードの次に読んで欲しい。
今回理解できること：MVC、サービス層・ドメイン層
持ち帰れること：クリーンなコード、レビュー時の良し悪し判断
３つの視点。
・クリーンなコードを書く、読む、説明。
認知負荷が低いコードとは、理解しやすいコード。仕様に対する習熟がある。
定量：凝集度が高く、結合度が低い、循環的複雑度低い
定性：構造を表現、整理されている、命名がわかりやすい
チームの中でクリーンを知っている人が偏っていると意味がない。チームで捉える必要がある。
・オブジェクト思考アプリケーションの構成要素
レイヤー：インフラ層、アプリケーション層、ドメイン層
オブジェクト：サービスとそれ以外
サービス：オブジェクトを呼び出すオブジェクト。オブジェクトがダンスをする場。
メソッドには３つある。
コマンドメソッド：タスクを実行するメソッド。（副作用がある）
クエリメソッド：データを取得するメソッド。（副作用がない）
モディファイドメソッド：ValueObjectの値を書き換える。値の変更は新しいオブジェクトの作成。
・オブジェクトとメソッドのコード例
コントローラー：サービスのエントリーポイント。
アプリケーションサービス：単一のタスクを実行する。ドメイン層にのみ依存。インフラ層含まない。
クエリサービス：永続化先からデータを取得する。ユースケースに応じて専用のDTOを返す。
レポジトリ：エンティティが持つデータを永続化先に保存する。永続化先からデータを取得しEntityを復元する。
サービス以外のオブジェクト。
Entity：他と区別できる実在物。区別するためにIDを持つ。（Identity）
ValueObject：値の範囲をバリデーションで制限をかける
Interface：抽象的なシグニチャを定義する。ポリモーフィズムの実現。
自分が書いているコードをそれぞれどこのために書いているのかを意識しながら実装していく。
そして書いていくうえでのチーム内でのコミュニケーションを行うことで、チーム内での共通認識を醸成できる。
感想
クリーンコードに対する解像度をチームで揃える重要性を改めて感じました。
学習と実践のフィードバックを通してチームで経験リソースを育み、結果状況リソースを整理していく。
少し前にコードの整理に向けて『良いコード／悪いコード』をチームの課題図書にしたところ、各メンバーのコンテキストの違いにより実践にスムーズに移行することができませんでした。
『オブジェクト設計スタイルガイド』に対する『リーダブルコード』の次に～という紹介で、我々にも扱いやすい書籍なのかと思いました。ひとまず積みます。
パンダさんのチーム開発のお話にいつも大きな刺激を頂いています。
ブース
ほぼすべてのブースを回ることができました。
いろいろな企業様のお話をお聞きすることができて楽しかったです。
抽選にも当選し、家族へのお土産もできました。ありがたい。
その他
配信ありがたいです。
現地参加は夕方まででしたが、帰り道もLT等楽しむことができました。
また、現地で聞けなかった気になるセッションも追います。
まとめ
PHPerではない自分も１日通してカンファレンスを楽しむことができました。
扱う言語が違っても向かう先は大きく違わないことに気付きます。
JJUGが設計の話が多かったことに対し、チーム開発の話が多かった気がするのも面白いです。
また参加したいです。その時までにPHPも扱いたい。
次回を楽しみしています。
おまけ
前回行列で諦めた和渦製麺、最高でした。
