はじめに
はじめにPHPカンファレンス福岡2025の開催に際し、スタッフ、登壇された方々、スポンサーの方がのおかげでとてもワクワクした時間を過ごすことができました。
ありがとうごうざいますmm
PHPカンファレンス福岡2025
この記事は私の参加したセッションの自分なりのメモ、感想みたいなものを残しておくための記事です。
記事の中に私のフィルタがかかり意味合いがずれている部分もあるかもしれませんがご了承くださいmm
※ 文字ばっかりで図や絵などはないので講演の際に表示されていたスライドを見つけた分はリンクを貼っているのでそちらを見ることをおすすめしますmm
参加セッション一覧
- Laravel x AIで開発効率とコード品質を加速させる勘所
- AIが当たり前になっていくなかで、エンジニア組織をどのように作っていくか。
- コミュニティと共に変化する 私とFusicの8年間
- 予防に勝る防御なし（2025年版） - 堅牢なコードを導く様々な設計のヒント
- Design and implementation of "Markdown to Google Slides"
- AI時代におけるドメイン駆動設計入門
- アーキテクチャレベルで依存性を逆転させたら最高だった話
- バグと向き合い、仕組みで防ぐ
- 組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する
Laravel x AIで開発効率とコード品質を加速させる勘所
変更の範囲をタスク起票時に制限してあげる (若手合流後に大体変更が多いと炎上する)
AIも同様に捉える。
ではどう対応していくか？
結果を予想しやすくする。
タスク作成者は...
- 変更箇所を想像する
- 全体設計を把握して
- 作業できる
このAI時代に若手をどう育成していくか？
ベテランの時間を仕事としてちゃんと育成の枠を作る。
(ただ、なかなかその時間を取れないのはおそらくどこも抱えている課題感か？)
このセッションでおっしゃられていたのはやはり上と話してわかってもらうしかなさそうでした...
AIが当たり前になっていくなかで、エンジニア組織をどのように作っていくか。
個人的にこのセッションで特に以下の点が印象に残っている
- これからAIを使いこなしたものがベテランと呼ばれるようになるかというとそうではないのでは？
- ドメイン知識に関して学ぶ機会はAIがある時、ない時で変わる
- 実際に案件などでチャレンジしてもらう文化を作る
「失敗しても良い」空気や文化を作り、より発言、チャレンジしやすい環境を作り、成長してもらうという組織を目指している部分、とても良いなと。
コミュニティと共に変化する 私とFusicの8年間
本セッションではスピーカーの方が新卒から部門長になるまでの会社、コミュニティと歩んできたの話
自分もこれから歩んでいく上で良いコミュニティ、人との出会いができるよう、日々精進していこうと思える良い機会になりました。
また、普段あまりカンファレンスなどに参加しないのですが、コミュニティへの参加や現地でこういった講演を聞くというならではの楽しみがあり関心が高まりモチベーションを上げてもらいましたmm
予防に勝る防御なし（2025年版） - 堅牢なコードを導く様々な設計のヒント
個人的に箇条書きで面白かったところをピックアップ
- できていいことだけで型定義
- enum 値の組み合わせを減らす
- 良いインターフェースは誤った使い方をすることが困難、正しく使用する方がミスするより簡単
- Make illegal states unrepresentable (不正な状態は表現できないようにする)
- 型設計でコンパイルでテストしてコンパイル時点で不正を防ぐ (面白い)
- Define errors out of existence (エラーを定義で消し去る)
- 処理すべき例外が存在しないようにAPIを定義する
- バグを減らすのに最良なのはソフトウェアをシンプルにする
- Fail Fast (不正な状態ならば速やかに停止させる)
- 不正な状態の場合、速めに停止させる
- 事前条件
- 利用者がそれを守ってない場合は救済せず、停止させる (これ好き)
- 責任分離
- SimpleとEasyを混ぜるな (ここはよく作ってる中で混ざりやすいので自分で作ってる時もレビューの時も気をつけたい...)
- Parse don't (just) validate
- Parseとvalidateの責任を分ける。
- 適切な場所でそれぞれを行う
Design and implementation of "Markdown to Google Slides"
自分で不便を解消するツールを作る
それがOSSとなり、いろいろな開発者が協力してツールが成長していく様や時に思想や意見の違いがぶつかる様子がとてもワクワクしました。
また、OSSへの関心も高まりました。
(同時に個人開発へのモチベーションを上げてもらえましたmm)
AI時代におけるドメイン駆動設計入門
中核的領域をAIと並走して一緒に作り上げていこう
ドメイン駆動設計におけるAI活用例
- 戦略的設計
- ドメインを設計していく上での会話やイベントストーミングなどの要約や記録
- 設計・議論の壁打ち
- 設計における諸々の整理
- ドキュメント化
- 戦術的設計
- 設計・開発
- 上流からモデリングや設計の繋ぎ
- ドキュメント化
同時にコンテキスト設計がAIエージェントを入れていく上で大切なのかなと感じました。
ユビキタス言語やドメインの複雑さなどの知識をAIエージェントにも人同様に持ってもらわないといけない。
その上で与えるコンテキストをどのように設計していくかで導入後の成果が変わってきそうですね
アーキテクチャレベルで依存性を逆転させたら最高だった話
スピーカーの方の記事から引用してきましたが、いかが要点だと考えます。
要は外部からくるデータに依存せざるおえないようなシステムなどはAPIインターフェースを介してやり取りをすることで依存性を逆転させることで互いを疎結合にし、開発を並列で行うことができる。
(私の携わっている業務、プロダクトに応用できそう)
クリーンアーキテクチャなどであるインフラ層とアプリケーション層の依存性逆転にケースとしては似ていると感じました。
「上流のデータ仕様が確定するまでレセプトシステムの設計が進められないという問題がありました。今回、この依存部分を API インターフェースとして定義し、各プロダクトから依存させる形にしました。
これにより、データの流れは従来通り各プロダクトからレセプトシステムへと向かいますが、依存関係は逆転していることになります。」
バグと向き合い、仕組みで防ぐ
前提：テストは欠陥があることは示せるが、欠陥がないことは示せない
バグには以下の2軸で向き合っていく
- 予防的な仕組みづくり
- インシデント対応力の向上 (向き合い方)
ブランチ戦略やテストを走らせるタイミングを工夫して仕組み時点でクリーンに保つ
バグの定義をしておき、機械的に判断などの向き合い方、対応で改善していく
バグの重要度分類やその分類、バグにおける対応などを定義しておき、チームで共有、対応していくなどの工夫が必要
組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する
フィードバックに着目する
「自身の目的を達成するために適切な相手に働きかけ、そのフィードバックから自身の行動を調節できることが、フィードバックの意義」
より良いフィードバックをもらうための仕組み、構造を作ることが重要
フィードバックを受け取って何をしているかが肝で、本来の目的をちゃんと見ておくことが大切
組織もソフトウェアも適切な責任分離と凝縮度が必要
良いフィードバックを得るための仕組みを作っていくことと問題、本来の目的を的確に見抜く力、それを抽象化できるというのが大切なのかなと感じました。
(これを組織、ソフトウェア両方に当てはめるというとても面白い観点ですし、自分的にも納得感がとてもありました。と同時にどのように人を巻き込んでいく、もしくは無意識に参加させていくかも大切になってくるのかなとか考えたりも。)
個人的にとても印象深いのは「自分なりの哲学を持つことで、生み出す設計にも筋が通る。」
(自分も意識し、大切にしたい...)
最後に
自分のメモはここまでです。
LTも参加し、どれもとても面白かったのでぜひ公式のタイムテーブルの方からタイトルを見て検索してみてください！