トーク

「全数テストは不可能」というソフトウェアテストの原則があります。
ごく単純なソフトウェアを除けば、すべてのバグを見つけることは不可能です。
では、私たちは不完全さを理由に、テストという活動やその責務を放棄してよいのでしょうか？

私はそうではないと考えます。
無限のテストに立ち向かうためには、「どこまでやれば我々の責務を果たしたと言えるか」を定義し、チームで納得する必要があります。
私はそれを「テスト計画」によって示せると考えています。

多くの現場において、テスト計画は「スケジュール調整」「テンプレートを埋める作業」と誤解されていますが、それは本質ではありません。
本来のテスト計画とは、ソフトウェア開発におけるコンテキストを深く理解し、「テストすべきもの」と同時に「テストしないもの」を定義します。
そして、「我々はこれでリリースできる」と納得することです。

本セッションでは、QAエンジニアである私の視点から、テンプレ埋め作業ではない、「テスト計画」という活動を構成するプラクティスを一部紹介します。

「コンテキスト」を集める

「テストはコンテキスト次第」という原則があります。
「なぜ作るのか」「誰が使うのか」、そして「制約」そういった情報を集め、整理することがテスト計画の第一歩となります。

「作ってはいけないもの」を見つける

我々は「作るべきもの」に集中することが多いです。
一方テストでは、「作ってはいけないもの」ということも考える必要があります。
プロダクトリスクと言いますが、これを批判的な問いによって見つけていきます。

完璧なソフトウェアが存在しないように、完璧なテストも存在しません。
しかし、我々はプロとして、「これなら大丈夫」と胸を張って顧客に届ける必要があります。

その方法のひとつとしての「テスト計画」について語りたいと思います。

"Official PHP SDK for MCP"、mcp/sdkというライブラリがあります。
これを使うと、簡単にPHPアプリケーションを「MCPサーバー」化できます。

例えばToolsを提供するなら、「jsonを返すPHPのメソッドに、「Tools」用のattributeを付けて、 Mcp\Server クラスを run() する」で、もうAIエージェントから使えます！
あまりに簡単。魔法のようですよね。

これは、一種のフレームワーク(FW)としての開発体験を提供していると言えます。
すなわち、

• 開発者は、自分の必要なロジック(アプリケーション機能)にだけに関心を払えば良い
  • それより下の、「クライアントとのやり取り作法」については、全てカプセル化
• 「実装した機能」の検出と呼び出し = ルーティングを一式備えて、正式で唯一のエントリーポイントを提供する
• この2点により、「制御の逆転」を実現する

というものです。
──さて、phper的には「どうやって、”足場”と”アプリケーション機能"の分離を行っているのか」「MCPならではの特殊な事情を繋ぎ込んでいるのか」が気になりませんか？
なぜ、こんな少ない労力で「すぐ動く」のでしょうか。

そんな訳で、「MCPそのもの・便利な使い方」はさておき、「FWとしてのmcp/sdkはどう設計され、機能を実現しているのか？」を読み解こう！というトークです。

このトークでは、次のような知識と知恵を提供します。

• 「FW」とは何を指しているのか、目的と要件
• mcp/sdkの「制御の逆転」と手続きの隠蔽、MCP的な事情をクリアするための実装
• 現代PHPのエコシステムに則った拡張性の実現(PSR関連)

テストコード、書いていますか？

今日において、自動ユニットテストを整備することが開発生産性の向上に寄与することはもはや疑う余地がありません。また AI の活用により、テストコードを書くコストは従来に比べて大幅に減っています。

しかし「テストコードの書き方や導入方法がわからない」「テストコードがあるだけで満足してしまい十分にその効果を発揮されていない」「テストコードが負債化し開発の足枷になっている」などの課題に直面している方も多いのではないでしょうか。

AI がコードを書く時代になっても……いや、むしろ AI がコードを書く時代だからこそ「価値のある」ユニットテストについて一緒に考えてみませんか？

お話しすること

• AI 時代における自動ユニットテストの価値とは
• 価値のあるテストコードを書くための基本的な考え方
• よくあるアンチパターンと処方箋・テクニック

コードを書く時に、「文法」って無視できないですよね。
巨大な存在すぎて、「何かそういうもの」「所与のものとして、そう在る」と思ってしまっているフシはありませんか？
しかし、プログラミング言語もソフトウェアです。
私たちが業務や趣味で書いているものと同様に、「仕様があり、それを実装している」に過ぎません。つまり、文法も「仕様に対する実装」と言えるのです。

「最初からある」から「そういうものに見える」のなら、視点を変えるために逆のアプローチを取るのが効くことでしょう。
自分で作るのです！文法を、実装してみましょう。

このトークでは、ドメイン固有言語(DSL)の自作を通じて、「プログラミング言語と文法の関係」に光を当てます。
最後には、文法が「そういうもの」から「仕様と実装があるだけ」と感じられるようになるでしょう。

話すこと

最終的にPHPに変換される、小さなDSLを作成します。
その過程で、「ソースコード(つまり、ただの文字列！)」→「語句に分解された集まり」→「語句同士の連なりである文(構文)」へと変換される手続きと、そこに必要な登場人物を追いかけていきましょう。
字句解析・構文解析といった概念のざっくりとした理解と、文法や言語仕様を読み解くための基礎知識を提供します。

話さないこと

字句解析・構文解析の理論や実装パターンについての網羅的な解説は行いません。「流れを体感する」ことを優先します。
(構文解析器の生成にはパーサージェネレータを利用し、実装における詳細なアルゴリズムは本トークで扱いません。）

代わりに、参考にした書籍等の紹介を発表資料と一緒に展開します。

想定するターゲット

• 言語やパーサーを自作した経験はないが、興味はある方
• YAML、SQL、正規表現などを日常的に使っているが、「作る側」の視点を持ったことがない方

概要

GitHub Copilot は優秀な相棒ですが、あなたのプロジェクトの「空気」まで読んでくれていますか？
特に長く運用されているレガシーコードや、独自のフレームワークを採用している現場では、AIが良かれと思って提案する「モダンで洗練されたコード」が、逆に修正の手間を生むノイズになることがあります。
「そこは namespace ではなく、アンダースコア区切りで……」と、AIの提案を人間が修正する作業に疲弊していないでしょうか。

本セッションのテーマは、Copilot への「教育」です。
単なるコード生成ツールとしてではなく、プロジェクトの文脈を理解した「専属の一流エンジニア」として育てるための、 Custom Instructions の活用と実践術を深掘りします。

話すこと

• Custom Instructions について: 設定ファイルの仕様と、AIに「空気を読ませる」ための基本的な記述ルールについて解説します。
• 独自ルールの徹底: モダンな学習データには少ないルールをどう言語化すればAIに伝わるか解説します。
• Before/After: 同じプロンプトでもインストラクションの有無で、AIの提案コードがどう変化するのか見てみます。

ターゲット

• AI の出力修正に時間を取られているエンジニア
• 長期運用中のレガシーシステムや、厳格な独自規約を持つプロジェクトに携わっている方
• チーム全体のコード品質均一化を目指す、2〜5 年目のリーダー層

曖昧な指示を排除し、意図通りに動かすプロンプトエンジニアリングの基礎から、標準規約とレガシー規約の共存テクニックまで。
明日からチームの Copilot が「新人」から「熟練の古参メンバー」へと変わる、実践的な育成技術をお持ち帰りください。

Laravelアプリケーションのデプロイは、特にクライアントにDevOpsの経験がない小規模プロジェクトでは困難を伴うことがあります。
そこで、モジュール式のLivewireベースのパッケージ開発者がアプリケーションにセルフサービスインストーラーを埋め込むことを可能にする。このインストーラーにより、エンドユーザーは自分でLaravelアプリをデプロイして設定できるコマンドラインを操作したり、環境変数を手動で設定したりする必要はありません。
この講演では以下の内容を取り上げます。
特に共有サーバーでの小規模な Laravel プロジェクトによくあるデプロイメントの課題。
私たちのインストーラーはこれらの問題をどうやって解決するのでしょうかモジュラーLivewireコンポーネント。
デモ: 小さな Laravel アプリケーションを最初からデプロイします。
開発者がインストーラーをアプリに統合し、ニーズに合わせてカスタマイズする方法。
セルフサービス インストーラーを構築するための教訓とベスト プラクティス。

この講演は次のような方々に役立ちます:
Laravel プロジェクト (小規模なアプリ/Web サイト) を頻繁にクライアントに提供するフリーランサーや小規模な代理店。
自分自身またはユーザーのために展開を簡素化したい開発者。
実際のアプリケーション向けの Livewire ベースのモジュラー アーキテクチャに興味のある方。

「PdMとのコミュニケーションに課題を感じる」「PdMが技術の壁を理解してくれない」と感じているエンジニアの皆さん、それは相互理解の機会不足かもしれません。本LTは、非エンジニアのPdMである私が、PHPコミュニティ（広島/香川スタッフ）での活動を通じて得た知見を共有します。PdMをPHPカンファレンスに送り込むべき明確な理由と、エンジニアの皆さんがPdMを巻き込むことで得られる3つの具体的なメリットをお話しします。プロダクト開発におけるPdMとエンジニアの連携の質を高めるヒントを持ち帰ってください。

とある事情により、Google Cloudの組織を移行することになりました。
このセッションでは、移行の背景や具体的な手順、直面した課題について詳しくお話しします。
また、移行と同時に進めたセキュリティの強化や、これまでIaC化されていなかったリソースの一部をIaC化する取り組みについてもご紹介します。
これらの経験を通じて得た知見を共有し、同様の課題に直面する可能性のある方々のお役に立てればと思います。