トーク

近年、AIを使ってテストを書くという流れが一般化しつつあり、私自身もAIにテストコードを補助的に生成させています。

しかし一方で、「AIにはあえて任せないテスト」が確実に存在します。
それは仕様そのものを表現するテストです。
AIは既存コードや表層の情報をもとにテストを書いてくれますが、「どうあるべきか」という意図やコンテキストの把握は人間がやる必要があり、仕様の補完や抜け漏れの指摘まで踏み込むことはできません。
TDDを行うときに「先にテストを書く」理由と同様に、最初に仕様を描く役割は人間側に残されていると感じています。

私はテストを「振る舞いの記述」であり、「仕様を共有するためのドキュメント」だと考えています。
したがって、他の開発者が見たときに、そのテストがどんな意図で書かれ、どのような状態を期待しているのかが読み取れる形を大切にしています。

このLTでは、AI時代における「AIに任せるテスト」と「手で書くべきテスト」の線引きを、実務の経験と失敗談を交えながら整理します。
AIに任せてショートカットした方が良い部分、一方で人が書くべき仕様の部分をPHPUnitを使った具体例とともに紹介します。

トーク概要（800文字以内・感謝ニュアンス版）

約3年ぶりにPHPへ「ただいま」しました。
復帰して最初に困ったのは文法ではなく、「今の現場の前提」が変わっていたことでした。
PHPのバージョン差に起因する互換性の勘どころ、フレームワークを選ぶときの判断軸、テストや静的解析をどこまで整備するのが標準なのか。
名前は聞いたことがあっても、根拠を持って決めるための材料が手元にない。ここが復帰直後のいちばん大きなギャップでした。

そんなときキャッチアップの根源になったのが、PHPコミュニティが積み上げてきたブログ記事や登壇資料でした。公式ドキュメントへつなぐ導線になっていて、単なる機能紹介ではなく「なぜそうするのか」「どこでハマるのか」「どう進めると安全か」という実務の知恵が、短時間で手に入る。
結果として、復帰直後に必要だった互換性・FW・品質ツールの未知を、一気に理解できる形に変えてくれました。

このLTは、その感謝を伝えにきました。
PHPに戻ってきた人間が、どんな知らなさに直面し、コミュニティの知見にどう救われたのかを共有します。

"技術選定" この言葉から何を感じるでしょうか？
「難しくてわからない…」と悩む人もいれば、
「あの技術を使ってみるのはどうだろう！」とワクワクする人もいるはず。

とりわけ事業、それもゼロイチのフェーズの新規プロダクトにおいては、
技術選定はその先のプロダクト開発の未来を大きく左右します。
事業づくりやその加速に最大限貢献できる技術選定とは、どんなものでしょうか？

このトークでは、技術選定を行う上で陥りがちな落とし穴や、
エンジニアリングと事業づくりをどうリンクさせ、事業づくりの加速に繋げられるのかをお伝えします。

候補を洗い出して、指標を評価して、いいものを選んでプロダクト責任者にいざ提案。
「いい技術選定ができたぞ！」と思っていたのに、実は見えていなかった視点があったことへの気づき。
LaravelやSvelteをはじめとする様々な技術の選定を進める上での失敗、不安、
そしてそれをどのように克服し、どう事業づくりの加速に繋げられたのか。
チーム唯一のエンジニアだった新卒3年目の私のリアルな経験に基づく学びをお伝えします。

このトークでする話

• 技術選定のリアルな経験とハマりがちな落とし穴
• 技術に閉じず事業目線で良い技術選定をするためのポイント
• 異なる立場の相手により伝えるための技術提案の観点

こんな方におすすめ

• 技術的な意思決定をする立場にあるエンジニア
• エンジニアから技術的な提案を受ける立場にある非エンジニア
• 技術選定に対して怖さを感じている若手
• 技術選定がどのようなプロセスで行われるのか知りたい方
• エンジニアサイドとビジネスサイドの意思疎通をもっと良くしたい方

これまで私はPHPを用いてダッシュボード向けのWebAPIを設計・実装してきました。また、それなりに多様なアプローチで開発してきた気がします。しかし、どのアプローチも完璧というわけではなく、それぞれに特徴と改善の余地がありました。

今回は自分の経験をもとにダッシュボードについてはもちろん、ダッシュボードを作る際のWebAPIのアーキテクチャスタイル(REST、GraphQL、 BFF)、開発、フロントエンドとの関わり、ログなどの非機能要件について紹介します。

話すこと(変更の可能性あり)
・ ダッシュボードとは何か
・ ダッシュボード向けWebAPIをどのように作ってきたか
・ 成功した点、苦労した点
・ WebAPIの設計、実装との向き合い方

話さないこと
・ Protobuf, RPCを利用した話し(経験がないため)
・ フロントエンド側の詳細な実装

PHP のコードは、データを「配列」に集約することから始まることが多いです。

「複雑なデータを整理しているはずなのに、なぜか読みやすい」
そんなコードに出会ったことはありませんか？
それらの多くは、 PHP という言語の特性である「強力な配列操作」を最大限に活かしているからだと思います。

本セッションでは、明日から現場で使える配列テクニックをお話しします。
・配列に集める技術：散らばった変数を整理するファーストステップ
・流れを作る技術：標準関数を組み合わせてロジックを表現する方法
・チームを動かす技術：可読性を高め、開発速度を上げるための共通言語としての配列

さあ、配列を武器に、試合をコントロールしましょう。

「コードレビューお願いします」と投げたプルリクエストが、いつまでも待ち行列に並んでいる・・・。
そんな状況に心当たりはないでしょうか？

私たちのチームではレビュー待ちが大量に溜まっている状態が当たり前になっていました。
開発速度は落ち、レビュー品質の劣化、コンフリクト多発、リリースサイクルの悪化、
そんな悪循環をなんとか断ち切るべく、様々なことに取り組みました。

・PHPStanによる静的解析の導入
・プルリクエストのテンプレート改善
・AIコードレビューの導入

しかし、これらを実施してもレビュー待ちは減らず、最終的に効いたのは「毎日決まった時間にレビューする」という固定時間制の運用でした。
カレンダーに事前にスケジュール登録することで差し込み会議を防ぎ、優先度が下がりがちなレビューに強制的に着手する仕組みを運用したことでレビュー待ちが劇的に改善したのです。

このトークでは、レビュー待ちがチームにもたらす悪影響についてや、静的解析やAIでは解決しなかった理由、
シンプルな運用ルールがなぜ劇的に効いたのかを、実体験をもとにお話しします。

想定聴講者

• チームのレビュー待ちに課題を感じている方
• 技術的な解決策を試したが効果が出なかった方
• 開発フローの改善に興味がある方

毎日インクリメントしてますかー！？

昨日の自分より 1 ミリでも前に進めたい、「インクリメント大好きおじさん」です！
何よりリリースして価値を届ける瞬間...最高ですよね。
でも最近、私が一番ハマっているインクリメント対象は、自分でもプロダクトでもありません。

「AI」です。

多くの人は AI をただのツールだといいますが、私は開発を加速させるジュニアエンジニアであり、
チームの新しい仲間だと考えています。

実際、本格導入から半年で、チームの実装時間は半分になりました。
その快適さを知ってしまった今、もはや彼らなしの開発には戻れません。

プロンプトを書く行為は、単なる命令ではありません。優秀な PHPer を育てる教育そのものです。

信頼できる PHPer が増えれば、それだけチームの判断力は上がり、実装スピードは劇的に変わります。
泥臭い調査は AI と協力して終わらせ、人間は「どう作るか」「何を作るか」の本質的な議論に集中できます。

人と人のレビュー文化に、AI という最強のパートナーを掛け合わせる。
チームを次の次元へ連れていく、開発の爆速インクリメント手法をお見せします！

新人の頃は毎日が新しい発見の連続でしたが、業務に慣れるにつれて似たような仕事が増え、成長曲線が緩やかになったと感じることはありませんか？
私は成長曲線を再び急勾配にするために、毎日個人的なふりかえりを 1 年実施しています。

本セッションでは、日々の業務経験を確実なスキルへと変換するために私が実践している、2 つのフレームワークを組み合わせたふりかえり手法をご紹介します。
具体的には、平日は 1 日 10 分で完結する「4 行日記（事実・発見・教訓・宣言）」でクイックに経験を言語化し、週末は「ORID」を用いて深く内省する手法です。

コルブの経験学習モデルに基づき、業務時間から最大の学びを抽出して成長し続けるための仕組み化
そして実践したことで感じた効果について、実例を交えてお話しします。

想定する聴講者
・ある程度業務に慣れ、成長の停滞感を感じている中堅エンジニア
・日々の忙しさに追われ、やったことを振り返る習慣がない方
・アウトプットへの苦手意識を克服したい方

「もし間違っていたらどうしよう」「環境を壊したら怒られるかも」 そんな不安から、提案を躊躇したり、調査ばかりで手を動かせなかった経験はありませんか？

私は元々、失敗を恐れて発言できないエンジニアでした。しかし、ある時ギャルマインドをインストールしたことで、劇的に行動が変わりました。 本セッションでは、単なる精神論ではなく、開発プロセスを改善するための実践知としてのギャルマインドを解説します。

ポジティブ： PHPバージョンアップ作業で調査より壊れてもいいからやってみるを選んで効率化した話
行動力： 完璧主義を捨ててとりあえず出す勇気
バイブス： 肯定的なコミュニケーションがチームの心理的安全性をどう高めるか

明日から心にギャルピースを掲げ、不確実性の高い開発現場をサバイブするためのマインドセットをお話しします。

さてここを覗かれてるあなた、もしかしてプロポーザルに興味がおありでしょうか？
出してみたい気持ちがおありでしょうか？

出してみたいけどふんぎりがつかない。そんなお悩み抱えてますか？
このトークでそのお悩みを少しでも軽くできればと思います。
カンファレンスをより深く楽しめるようになりますよ！

ターゲット

• プロポーザルを出してみたいけど一歩踏み出しきれてない方
• プロポーザル出す人の心理を知りたい方

お話すること

• なぜプロポーザルを出す（カンファレンスに登壇する）のか
• 心理的ハードルの洗い出し
• 心理的ハードルへの考え方、対策
• どうやってネタを出しているのか
• 出すときに意識していること
• 出したらどうなるか

何が得られるか

• プロポーザルを出す勇気
• ネタのひねり出し方

PHPではtry-catchによる例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか。
例外を過度に使用すると、本来の処理の目的が曖昧になり、可読性の低下や予期せぬバグの隠蔽につながることがあります。

こうした課題へのヒントとして、Result型の考え方をPHPに応用するアプローチがあります。
Result型は、成功と失敗を返り値として明示的に扱える型であり、エラーの種類や責任範囲の整理に役立ちます。
結果として、処理の流れや責務が明確になり、例外を多用せずにエラー設計が可能になります。
PHPでは標準で実装されていないものの、軽量な自前実装によって導入できます。

本セッションでは、例外（try-catch）を前提とするPHPプロジェクトに、以下の観点を中心にResult型を取り入れる方法を紹介します。

• エラーの分類と責務の整理
• 例外との使い分け
• PHPでResult型を実装する方法

Result型を導入するかどうかに関わらず、エラーをどう設計するかを見直すヒントを持ち帰っていただけると嬉しいです！

国内のPHPコミュニティは、今も活発です。
しかし、10年以上PHPerとして現場を見てきた立場から申し上げると、参加者の年齢分布が静かに、確実に、変わりつつあるのを感じます。
若手の新規参入が減り、このまま放置すれば、PHPという文化そのものがゆるやかに縮んでいく未来を危惧しています（・・・言い過ぎ？）

本トークでは、コミュニティの高齢化が「気のせい」でなく構造的に起きている現象であることを、実例や現場感覚を交えて整理します。なぜ若手がPHPを選ばないのか。なぜ企業も新人をPHPで育てなくなってきたのか。技術面だけでなく、採用市場・教育環境・コミュニティ文化といった複数の視点から“本当の原因”を紐解きます。

その上で、みなさんが今日から現場で実行できる具体的なアクションを提示します。
「あとは現場の人が頑張りましょう」みたいな投げっぱなしの話ではなく、個人・企業・コミュニティのそれぞれができる実践できる施策を聞いて下さい。

話す内容

• 若手がPHPを避ける心理的・構造的ハードルの正体
• 「モダンPHP」を若者に届く形で伝え直す方法
• 初学者にPHPを選んでもらうための教育デザイン
• 企業が採用・研修でやめるべきこと、すぐ始められること
• コミュニティが若手を迎え入れるための環境づくり
• ベテランPHPerが持つ「邪悪な常識」の正体とアップデート手法

「高齢化しているらしいから危機感を持ちましょう」ではもうちょっと止められない状況にあります。
私のトークを聞き終わって、みなさんが会場を出たその瞬間から、何か行動を変えられるようにすることを目的にしています。

念の為にいうと、PHPの言語自体はさすがに廃れないと思っています。
ただし、何もしなければ静かに活気は失われていきます。
会場の皆さんと一緒に、PHPの未来を“作る側”へ回りましょう。

エンジニアとして学び始めた頃の私は、「どう作るか」という手段ばかりを追いかけていました。
意識が向いていたのは以下のことです。

• 完璧にやる
• とにかく100点を目指すこと

一方で、「なぜそれを作るのか」「誰の何を解決するのか」という目的にはほとんど目を向けられませんでした。
背景には初学者としての不安や失敗したくない完璧主義があり、手段だけを追うことで安心していました。
しかし、その結果、受動的な開発から抜け出せず、本質に気づけませんでした。

そんな自分を変えたのは、先輩エンジニアの一言です。

• 「まず目的を一緒に整理しよう」

目的を言語化し、ユーザーの状況を想像して価値を定めてから手段を選ぶプロセスを意識したことで、開発の視界が広がりました。
完璧主義の方向性も変わり、以前は「100点」を目指していたのが、今は「60点を100点として目指す」ようになり、
余裕を持って自分から問いを投げかけられるようになりました。

具体的には、

• 「この仕様の意図は？」「もっと良い体験にできる？」と問いを立てる
• 受動的だった開発が主体的な創作に変わる
• 意味のある選択

こうして問いを立てる余裕が生まれ、開発の視点も行動も大きく変わりました。

このトークでは、

• 初学者だった私が手段中心に陥っていた理由
• 目的を取り入れたことで生まれた具体的な変化（完璧主義の方向性も含む）

についてお話しします。
初学者や若手エンジニアにぜひ聞いてほしい内容です。
作ることの楽しさが一段深くなるきっかけになれば嬉しいです。

※初心者向けトークです

このトークの対象者

• 「ポリモーフィズム？それ美味しいの？」と思う人
• 名前は知っているが、自分の言葉で説明できない人
• ベテランの方で、他人に説明する自信がない人

トークが目指すゴール

• オブジェクト指向の良さを体感できる
• テストを書く時に効率的に書くヒントを得られる
• クラス設計そのものが楽しくなる（大事）

Javaから始まったオブジェクト指向の波はPHPにも波及し、今やPHPは立派なオブジェクト指向言語になっています。
プログラミング初心者が抱く疑問「ところでオブジェクト指向の何が良いの？」という命題について。
これを改めて解説して「確かに良いね！」「便利だね！」「テストに活かせるね！」とみなさんに再認識してもらうのが目的です。
またそれと併せて日常生活に潜むポリモーフィズムの例を出しながら、わかりやすさに特化します。

さらに、日常生活に潜むポリモーフィズムの具体例を紹介し、わかりやすさを追求します。
熟練のエンジニアであっても、「頭では理解できるけれど、初心者にわかりやすく説明するのは難しい」と感じることがあります。高齢化が進むPHP界隈で、PHPの魅力や便利さを伝える流れの中で、オブジェクト指向の良さも一緒に解説しましょう。

「技術より業務知識が大事だよ」

20年以上前、技術の理解を深めれば良い仕事ができると考えていたジュニアプログラマーとしての私に、先輩が言った言葉です。当時は「業務知識が大事」と言う言葉自体の意味は理解できるしその通りであると思う一方、プログラマーとしての担当していた仕事内容から考えると実感として理解することはできずにモヤモヤしたものを感じていたのを覚えています。
今振り返ると、これは“ビジネスロジックと向き合う姿勢そのもの”に関する示唆であったと理解できるようになりました。

しかし、プログラマーにとってビジネスロジックはしばしば掴みどころがありません。仕様書やソースコードには結論だけが記述され、その背後にある意図や価値基準は薄まり、画面やDBの制約と混ざった断片として現れます。
特にジュニアプログラマーは担当範囲が限定されているため、言ってみれば視野が狭い状態から作業を始めることになります。ジュニアプログラマーにとって、ビジネスロジックを解像度高く把握するのが非常に難しい事であるというのは、自然なことなのかもしれません。

本記事では、この“プログラマーから見たビジネスロジックの掴みにくさ”に正面から向き合い、視点をアップデートすることを試みます。RUP(Rational Unified Process)が体系化した“ステークホルダー”という概念を参考に、ビジネスロジックを形づくる意図の源泉を理解するためのヒントを紹介します。要件定義の専門的な話ではなく、「プログラマーとしてどう捉え直せるか」が主題です。

市場の要求に応じた大規模な新機能の追加は、プロダクトの成長に不可欠です。
しかし、2001年ローンチの「メールディーラー」のようなレガシープロダクトは、その挑戦が特に困難です。

メールディーラーは全機能が一台のサーバーに集約され、フレームワークなしのPHPファイルでDBアクセスとHTML出力を行う陳腐化が著しいシステムが背景にあります。

その一方で、LLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、「AIを導入していないことがデメリット」へと市場の要請が変化。
私たちは、この状況に対応するため、「AIクレーム検知機能」をサービスに導入することを決定しました。
しかし、大規模なリファクタリングが困難な中、私たちはAI機能を既存システムから外出しする戦略を採用。
史上初のβ版をDocker互換のコンテナであるPodmanで構築し、実証実験を通じてChatGPTの精度を向上させました。

さらに製品版をAWSで構築することで実用レベルの精度を実現し、設計時の見積りより約65%のコスト削減に成功しました。

本トークでは、テクニカルリーダーである私が、このレガシーの壁を越えた戦略を具体的な事例を交えて公開します。

・AWS導入にあたり、利害関係者へ目的を整理し、どのように説得・合意形成したか。
・ベータ版での精度向上の試行錯誤と、AWS移行によるコスト削減とパフォーマンスの向上をどのように達成したか
・AWSのSQSを使い、レガシーと新システムとをどのように接続したか？

本セッションを通じて、レガシーなシステムに対して、市場の変化と最新技術を取り込む新しい試みの参考にしてください。

PHPUnitは毎年新しいメジャーバージョンがリリースされ、どんどんと変化を遂げています。
新機能や改善が取り入れられるスピードが速い一方、古いメソッドや機能の非推奨化・削除もどんどん行われます。
実際にPHPUnit 11のChangeLogを見てみると、Deprecatedが19件、Removedが25件もあります。

私たちのチームではPHPUnit 9を使っていたのですが、9から11へのバージョンアップには広範囲の修正が必要になる変更もあり、なかなか実行に踏み切れませんでした。
そこで、コードの変更を自動で行ってくれるツール "Rector" を採用し、手動での変更を極力減らしてPHPUnitのバージョンアップを行いました。

このトークでは、Rectorを用いたPHPUnitバージョンアップの実体験に基づき、以下のことをお話しします。

• Rectorを使ったPHPUnit9→11へのバージョンアップ手順
• 自動では対応しきれず、手動対応が必要だった事例

「間違いたくない」「正解を出したい」
かつての私は、はじめから完璧を目指しすぎて、かえって大きな手戻りを生んでしまっていました。

どうすれば、手戻りを減らせるだろうか？
試行錯誤の末に見えてきたのは、「はやく失敗する」ことの重要性でした。

このLTでは、手戻りの多さに悩んでいた新卒1年目の自分に伝えたい、はやく失敗するメリットと、その実現のために日々の開発で実践していることについてお話しします。
似た悩みを持つ方にとって私の経験が参考になれば嬉しいです！

我々ソフトウェア開発者の日々の業務は、常に不確実性との戦いです。
新しくチームに加入したメンバーが「今までの現場で一番チームとしての一体感がある」と評してくれた我々のチームも、最初から全てが順風満帆だったわけではありません。

立ち上げ当初は、楽観的すぎる見積もり、沈黙が支配するお通夜ミーティング、そして正常系すら動かない壊れたプロダクトコードなど...
プロセスもチームも、まさにバグだらけで崩壊寸前でした。

このセッションでは、立ち上げから半年以上、数々のトラブルや不確実性と向き合う中で私たちが実践してきた、タスクの「解像度」を上げる工夫や対話の文化作りなど、チームを立て直すための具体的なテクニックについてN=1の事例として赤裸々にお話しします。

■ アジェンダ
前途多難なチームの「バグ」と向き合う

• 「根拠なき楽観見積もり」の罠
• 「お通夜ミーティング」はどうして生まれたのか？
• 「壊れたプロダクト」を前に我々はどうしたのか？

立ち上げを乗り越え、チームがぶつかった「3つの壁」と修正パッチ

• 「山頂の見えない台地」とモチベーションを再燃させた問い
• 「俺がn人分になる！」という属人化との決別
• 「次にやることが分からない...」というチームの向きを揃えた羅針盤

そして、その先へ

• チームの現在地と、新たに見えてきたプロダクトマネジメントという課題

■ このトークで持ち帰れること

• 不穏なチームの雰囲気を変えた具体的なアクション例
• 不確実性が高い状況下でのタスク管理・メンタル管理のヒント
• 「N=1」の事例から学ぶ、明日から使えるチームビルディングの知見

昔は3つくらいのGitクライアントを併用していた私も、今ではほとんどの操作をPhpStorm上で完結するようになりました！

• logを見る
• 編集してるコードから、ピンポイントにファイルや行の歴史を辿る
• グラフィカルな操作でrebaseやmergeも自由自在
• todo管理やstashも気軽にok
• 内部的に何をしてるんだ??という時も、簡単に確認できる

などなど、便利なポイントを思い出そうとすると、枚挙に暇がありません！

普段の作業の効率を高める、PhpStormを使ったGit操作の便利な活用術を紹介します。