トーク

自社プロダクトの保守運用では、ユーザーからのお問い合わせに対して技術調査を行う場面があります。プロダクトが大きくなるにつれて自分の知らない知識（コードベース）も増えて、技術調査が難航する場面もあります。

本トークでは、自分の知らない知識に対し、AIを活用した技術調査の方法についてお話します。特にドキュメントに対してはNotionAI、コードベースに対してはGitHub Copilotを使用した知見についてお話します。

話すこと

• AIを使った技術調査の方法
• AIを有効に使うための情報のストック（議事録からアプリケーションログまで）

PHPの次期メジャーバージョンであるPHP 9.0に向けて、ライセンス変更の議論が進んでいることをご存知でしょうか？現在のPHP Licenseは、GNU General Public License（GPL）と互換性がなく、ソフトウェアの再配布時に制約が生じる状況になっています。将来、現在の独自ライセンスから、三条項BSDライセンスに移行されるかもしれません。

本トークは、OSSに関心のあるPHP開発者や、ライブラリ公開を検討しているエンジニアを主な対象としています。PHP Licenseの歴史や現在進行中の議論を紹介するとともに、OSSライセンスの基礎を初心者にも分かりやすく解説します。OSSライセンスの互換性にも触れながら、OSSにコントリビュートする場合や、自作ライブラリを公開する際に役立つ実践的な知識を紹介します。

GitHub Copilot Code ReviewでPHPのコードレビューをしてもらってます。
レビュアーにアサインするだけでコメントを付けてくれるので非常に便利です。

でも概要はあっさりしてますし、もっと多くの観点からレビューしてもらいたいです。
なので自分は、VSCodeのCopilot AgentにCustom Instructionsでレビュー観点を与えた上で、GitHubのMCPを通してブランチ差分のコードレビューをしてもらっています。
PRのレビュー依頼があればとりあえずCopilotに投げてます。
GitHub Copilot Code Reviewよりもう一歩進んだレビューが得られます。

このトークでは実際の業務で使用しているCustom Instructionsの具体的な設定内容と、
設定前後のレビュー品質の違いを実例でお見せします。

個人開発でWebアプリを作成するのにClaude Codeを使ってます。
AIにコーディングしてもらうと開発時間を圧倒的に短縮できるのが非常に良いです。

ただ保守のことも考えてコーディングをするとなると、個人のレビュー能力を超えた速度でコーディングしてもらうことは難しいです。
ちゃんと理解して、正しいコードかどうか判断した上で進める必要があるからです。

AIと壁打ちをしながら仕様を一つ一つ自分で決めていきます。
完璧を目指さない。まずはやってみるというマインドで試行錯誤を繰り返してきました。

本トークでは実際のWebアプリ開発を例にClaude Codeとの協働開発プロセスを解説します。
特に以下の点を具体的に説明します。

・PRDの作成
・コーディング
・画面・コードレビュー

明日からの個人開発で実践できる具体的なワークフローとコツをお持ち帰りいただけます。

「設計ドキュメントは必要か？」
この議論は開発現場でたびたび持ち上がります！

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。
複数の開発チームを経験する中、『チームトポロジー』を読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。

・ドキュメントの必要性とは
・チーム特性に応じたドキュメント管理
・実際のチームで実践しているドキュメント管理方法

設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。

「スタイルとは何か。野生とは何か」──元同僚がXでつぶやいたとき、探索的テストにまつわる曖昧さに、改めて目を向けるきっかけになりました。
Cem Kanerが「スタイル」と呼んだこのアプローチは、仕様の曖昧さに対して、観察・仮説・検証を繰り返す“ふるまい”です。それは、私自身の思考のクセに根ざしつつ、チームの存在によってアプローチとしての気づきが促されてきました。

本セッションでは、探索的テストを「スタイル」として捉えることで見えてきた、属人性・再現性・品質との向き合い方を語ります。QAの実践における“野生”──型にはまらない問いとふるまいが、どんな価値を生んできたのか。その軌跡を共有します。

「やべっ！テスト落ちた！！一旦Rerun！！！」
──みなさん、これ、やっていませんか？（特大ブーメラン）

通ればラッキー、通らなければ…まああとで考えるか、というアクションに陥りがちです。
このような"たまに落ちる"Flaky Testを放っておくと、じわじわとテスト全体の信頼性を失っていきます。

私自身、何度も同じ轍を踏んできましたが「そもそもそのようなテストを書かないようにする」勘所を掴んできました。
このトークでは、Flaky testになりそうな臭いのするテストの勘所、そして、そもそも生まないためのテストの書き方について話します。

話すこと
・Flaky Testになりやすいパターン（キーワード: 不定な並び順, 非決定的な現在時刻, 日付が変わると落ちる, ...）
・Flaky Testにしないための書き方
・Flaky Testをそもそも生まないために

Amazon RDS Blue/Green Deploymentは本番DBのクローンを作成し、更新後にスイッチすることで安全かつ高速にリリースを行う仕組みです。
ダウンタイムめちゃ少なく移行できる！！というのが旨みで時間のかかるDBアップデートもユーザーに負担をかけることなく終わらせることができます。

これを完遂させるまでにはいくつかの悩み・ハマりポイントがありました。
そのため実録として、どのように運用したか実際に作った手順書も大公開します。
不安の多いDB バージョンアップをハードルなく進めるための指針となる話をします。

話すこと
・Blue/Green Deploymentとは
・実録〜前もって確認すること・手順書・リアルな所要時間〜
・Blue/Green Deployment を選ぶ場面、選ばない場面
・やってみてわかったDBバージョンアップの勘所

何かを志そうと思った時

「どうせ無理」
「そんなのできる訳がない」

と言われたり

「私にはどうせ無理か…」

と諦めてしまったりすることがあるかと思います。

システムエンジニアとして働く中でそんな”どうせ無理”に抗い、今では好きなことを仕事にすることができています。
どう抗い、どう好きなことを仕事にしてきたのかをご紹介します。
誰かが少しでも自分らしく生きるためのヒントになれば幸いです。

バグはゼロにできません。だからこそ、起こさないための仕組みと、起こったときの対応力の両方が重要です。
本セッションでは、QAがエンジニアと協働しながら、PR環境の自動生成やFeature Flagsによる安全な開発プロセスなど、予防的な仕組みにどう関与しているかを紹介します。
さらに、Slackでの即応体制やレトロスペクティブへの関与など、インシデント対応におけるQAの役割と、品質文化の育て方についても共有します。
「防ぐ」と「向き合う」両軸を支える仕組みと文化を、実践例を交えてお話しします。

標準で備わっている多種多様な関数たちはPHPの大きな魅力です。

array_merge() や implode() のような定番の関数がある一方で、
「えっ、こんな関数あるのぅ〜〜〜ぅん！？」と思ってしまうような、
ちょっとニッチで味濃いめな関数も存在します。

今回はそんな"気になる関数"を取り上げて、
背景から意外な使い方までざっくばらんに紹介していきたいと思います。

まだ内容は調整中ですが、5分で「へぇ〜」がひとつ増える
そんなトークを楽しくライトにお届けする予定です！

AIエージェントがコードを生成する時代、エンジニアに求められるスキルは根本から変わりつつあります。
単なるコーディング速度ではAIに太刀打ちできない今、必要なのは「AIに正確で効果的な指示を出す力」。そしてその力の本質は、設計論という“共通言語”にあります。SOLID原則、デザインパターン、クリーンアーキテクチャなどの知識は、AI時代における最強の武器となるでしょう。
本セッションでは注目の「スペック駆動開発」にも触れながら、設計力がどのようにAI協働を支えるのか、実例を交えて掘り下げます。
今こそ、設計を学びなおす絶好のタイミングです！

PHPでwebシステムを開発をしていると、必ずと言っていいほど日付に関わる処理を実装します。

「契約開始日から1ヶ月後の契約だけこんな処理を。。。」
「この条件は注文された日から30日間だけ有効で。。。」
「受注日より前の注文だけ取得して。。。」

新人エンジニアの頃、何気なく渡されたタスクで、何気なく実装した日付に関する処理でエラーを連発してしまいました。

• DateTimeImmutableを使わないとどうなるのか？
• DateTime->modify('1 month')が1ヶ月後にならない
• 1ヶ月後って何日後？

簡単そうなタスクに見えて落とし穴がいっぱいの日付について話します。

Laravel開発でphp artisan serveを叩きビルトインサーバを起動するお馴染みの光景。
しかし、公式ドキュメントには「本番環境で使うな」の一文が。
なぜビルトインサーバーは手軽さと引き換えに、本番環境で採用できないのでしょうか。
また、本番環境でデファクトスタンダードとなっている「Webサーバー + PHP-FPM」という構成は、どのようにそれを解決するのでしょうか。

以下についてお話しします。

• ビルトインサーバーが本番環境で推奨されない理由
• WebサーバーとPHP-FPMの基本的な仕組み

laravelの php artisan optimize
開発環境では思わぬエラーになるかも？

TypeScriptやRubyから、
PHPを触りはじめて1番戸惑ったコチラについて、事例も交えてお話出来ればと思います。

この辺りの理解を深める事で、
なんとなく治った謎のエラーから、
ちゃんと理解して解決できるようになりました！

こんな事を話します。

• 事例
  • こけるはずのテストが通ってしまった
  • laravelのAPP_KEY変更が反映されない
• php artisan optimize とは
• optimizeのクリア用コマンドについて
• どういう運用がベターか？
• なぜ本番環境では必要なのか

皆さんはPHPに機能追加してみたくなりませんか？
私はPHP 8.4から機能追加をPHP本体にやってきていて、様々な関数を世に送り込んできました。

• mb_trim、mb_rtrim、mb_ltrim関数
• mb_ucfirst、mb_lcfirst関数
• grapheme_str_split関数

PHP 8.5では以下の関数が追加予定です

• grapheme_levenshtein
• grapheme*関数にロケールを追加する(8月8日現在では投票中です)
  https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive

みなさんも、RFCで提案してみるのはどうでしょうか？そのコツなどやり取りをお伝えできればと思います。

元々PHPerだった私は、2025/03に転職をし、Gopherとなりました。
まだまだGoの知見は少ないですが、そんな中で感じるPHPの良さについて話します。

当然ながらGoの良さはたくさんあり、パフォーマンス、静的型付け言語、シンプル、ゴルーチンによる並列処理 etc...
しかしながらPHPも進化を重ね、非常に優れた言語となっています。
高速かつ安定したPHPの実行を可能にするPHP-FPM、膨大なライブラリとコミュニティの知見、Laravelのような至れり尽くせりなフレームワーク etc..

Goと比較しつつ、PHPの良さを語ります。
※Go下げをするものではありません

LaravelとInertia.jsを使ったフルスタック開発では、バックエンドからフロントエンドへ渡すPropsやリクエストボディの型情報をTypeScriptで手動で定義する必要がありました。これにより、バックエンドとフロントエンドで型定義の不整合が起きやすかったり、データ構造の変更時に複数箇所の修正が必要などの課題がありました。
Laravel Wayfinderは、Laravelのコントローラーやフォームリクエストから自動的にTypeScript型定義を生成するパッケージです。バックエンドを変更すると自動的にフロントエンドの型情報も変更されるので、開発体験が大幅に向上します。

話すこと

• Inertia.js概要
• Laravel Wayfinderの導入方法と基本的な使い方
• Inertia.jsのPropsとフォームデータの型自動生成
• 実際のコード例とライブデモ

謎のIDや変数と複雑な仕様、夜中の手動更新、トラッキング漏れ──20年使われてきたユーザ流入基盤の運用は、もはや限界を迎えていました。「うちら辛くね？」この一言から始まったプロジェクトで学んだのは、システム改善の成功は「仲間づくり」にあるということ。

チーム・上司・運用・ビジネスを巻き込み、刷新プロジェクトを発足。安全性と保守性を備えた新基盤への移行をリーダーとしてやり遂げました。「ちょっと頑張る必要あるけど、めっちゃ使いやすくするから」という言葉を、どう信じてもらえる形にしたか。

本トークでは、フェージングが雪崩になった失敗、重い課題を別PJに切り出す判断、段階的リリースから一気リリースへの方針転換など、9ヶ月のリアルな軌跡を共有します。中堅エンジニアが直面する「与えられた仕事以外」をどう進めるか、「“やるべき仕事”は自分で作りだす」ための実践的なヒントをお話します

エラーが発生したとき、ログを追ったりデバッグを繰り返したりするのは大切な作業ですよね。でも、それだけだと「エラーが起きた後の対処」に留まってしまいます。もっと良い方法があるとしたら？

設計の段階から、エラーが「見つけやすい」仕組みや「そもそも起きにくい」コードの書き方を取り入れることで、システムの信頼性がグッと上がり、あとから困ることも減ります。

このセッションでは、例外の基本的な役割や考え方から始めて、PHPやJavaのように例外を持つ言語と、RustやGoのように例外を使わない言語のエラーハンドリングを比較。それぞれの特徴を活かした設計方法をお話します。難しい話だけでなく、「こうすれば実務で役立つ！」という具体例も紹介しますので、チームのディスカッションにもぜひ活用してください！