あと1年でデータ件数10億件間近…そうなればテーブル変更したくても怖くて触れない…！

そんな状況から始まった打刻テーブル移行のハイライトを5分で語ります。（DBはMySQLです）
・ 更新パラメータ追加に伴うログ検証
・ 参照切り替えのシャドーテスト的アプローチ
・ βリリースを活用した影響調査

動いているAPIを動いたまま内側のテーブルをすげ替えるために行った工夫にをお話しします。
本LTがみなさまのシステム改善やレガシーシステムの移行の一助になれば幸いです。

転職を機に新規でアプリケーションの実行環境を作ることになり、0から構築しました。もちろん今までに構築した環境をベースしましたが、セキュリティの向上という課題を踏まえて、
ここ数年話題に登ることが増えてきたDevOpsにセキュリティを意識した取り組みを組み込むDevSecOpsを意識して環境を構築しました。

新たな環境の構築に際してセキュリティを意識した自動化の取り組みをどのように組み込みつつ、効率的な開発プロセスを維持するために意識したことや、取り組みの具体的な方法と実践例をご紹介します。

開発を進めていくと、「このAPIってどんなリクエスト/レスポンスをするんだろう」「こんなAPIがあったんだ」となることよくありますよね？
特に外部公開を目的としないプロダクトではAPIドキュメントを書かないので、さらに謎のAPIが生まれたり、コードを読まないといけなくなります。
このような苦労があるものの、いざ0から作るのは大変です。

今回上記の課題を解決するために、dedoc/scrambleというライブラリの紹介ができればと思います。
Laravelで作られたプロダクトであれば、設定なしでOpenAPI記法でのjsonをエクスポートできちゃいます。

本LTは下記聴講者が対象です。

・APIドキュメントを作りたいけど、0から作るのは面倒
・LaravelでよいAPIドキュメント生成ツールを知りたい方

引数をメソッドに渡すか、 __construct に渡すか......
どちらも機能しますが、本当に “どちらでも良い” のでしょうか？
動くのは間違いないですが、より「使いやすく」「保守しやすい」コードを目指すなら、最適な注入方法を選ぶ必要があります。
そこで、わたしの考える判断基準を具体例のコードに落としつつ紹介していきます。

• クラス設計・依存関係の整理
• テストの書きやすさ
• コードの可読性

また、このような話で一緒に出てくるのが依存性注入（DI）です。
具体例とともにあることでふんわり理解からじっくり理解にもっていきましょう。

このトークでは、実際のコード例を交えつつ、コンストラクタ注入とメソッド注入それぞれの判断基準を明確にしながら、DIの仕組みも合わせて紹介していきます！

皆さん、チームを分割してみたけど、結局また一つにまとまっちゃったことありませんか！？

チームが分かれれば効率も上がる、役割も明確になる…なんて思っていたのに、なぜかチームが再び一つに引き寄せられてしまったんです。

その原因、実は「コンウェイの法則」にあったんです！

このLTでは、どうしてチームを分割したのに再統合が起きたのか、そしてその結果として何が得られたのかを赤裸々に語ります。

私たちが直面した課題や学びをシェアして、みなさんの組織設計にも活かしてもらえたら嬉しいです！

みなさんはFour Keysでどのクラスタに属していますか？

Four KeysはDORA（DevOps Research and Assessment）が提唱している開発チームのパフォーマンス指標です。Four Keysではパフォーマンスに応じて、Elite・High・Medium・Lowの4つのクラスタのいずれかに分類されます。

サービス開発においてEliteクラスタに属していないと、ビジネス競争力が低下するリスクがあります。近年ではEliteクラスタに属した上で競争力を高めるためにさらなる取り組みをしていくのは一般的です。

私が所属する合同会社DMM.com 二次元コンテンツ事業が開発に携わっている二次元コンテンツ事業のPHP製ECサービスは現在「High」クラスタに位置しており、Eliteクラスタを目指してさまざまな取り組みを積極的に進めています。

本セッションでは、まだEliteクラスタに属していないチームが具体的にどのようなアプローチを取ればよいのか、実際の取り組み事例を交えてご紹介します。

アジェンダ（予定）：

• Four Keysとは
• なぜFour Keysを使うのか
• スループットと品質の相関
• ECサービスの現状と課題点
• Eliteクラスタへ移行するための取り組み
  • スループット改善への取り組み
  • 品質改善への取り組み
    • リファクタリングに向けた準備
      • FakerとTestcontainersを用いたモデルベーステスト
      • Qodanaを用いたPHPアプリケーションの静的解析

対象者：

• Four KeysのEliteクラスタ入りを目指す開発チームのリーダーやメンバー
• 開発チームのパフォーマンスを具体的に改善したい方

「設計ドキュメントは必要か？」
開発現場でたびたび持ち上がるこの議論に、正解はあるのでしょうか。

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。

複数の開発チームを経験する中、チームトポロジーを読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

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

• ドキュメントの必要性に関するよくある議論
• チームが扱うドメインの種類
• チームタイプによるアプローチの違い
• 実際のチームで実践しているドキュメント管理方法

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

PHPの標準関数やクラスで絶対日時を扱う時に利用するのが、strtotime や DateTime(Immutable)です。
引数には、どんな値が使えましたっけ？

どうしても『おしゃれ』に書きたい！そんな時には、色々な指定方法を知っておくと有利です。
どうやって知ればいいでしょう？PHPのことはPHPに聞くのが1番簡単そうですよね。

PHPについての信頼できるソースとして、php-srcを訪ねてみましょう。
構文解析の定義ファイルを読むことで、利用可能な形式を把握できます。

どこにあるファイルを、どのように読むべきかを知り、実際に使える値(とその調べ方)を知るLTです。

PHPで利用できる例

※ 2025年5月3日に実行すると、全て同じ値になります

<?php
strtotime('today');
strtotime('midnight');
strtotime('noon - 12 hours');
strtotime('3 days ago 00:00:00 + 72 hour');
strtotime('Sat.');
strtotime('00:00:00');
strtotime('00:00');
strtotime('2025-05-03');
strtotime('05/03/25');
strtotime('2025-W18-6');
strtotime('2025.123');

型定義が不完全、変更の副作用も予想しきれない、リファクタしたいけどリスクが読めない――そんなレガシーなPHPモノリスと日々向き合う中で、私たちのチームでは本番環境でユーザーに影響なく検証ができる「シャドーテスト」というお作法を実践しています。

このLTでは、

本番と同じリクエスト・入力を使って新旧ロジックを同時に実行し、
結果の差分を検証する
というアプローチを紹介します。

「テストコードは書きづらい」「型がないから静的検証も弱い」そんな環境でも、実行して確かめることで安全にリファクタや置き換えが進められます。実際にどのように組み込んでいるか、実施してどういうところが良かったか、5分でさくっと共有します。

レガシーPHPと戦う皆さんの一助になれば幸いです！

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

プログラミングはテキストの海。書けても読めない単語は意外と多く、チーム内でも呼び方がまちまち──そんなモヤモヤはありませんか？
もうこの場で決めてしまいましょう。明日からは自信を持って口に出せますよ。

対象者
PHP に限らず、コードの読み上げや口頭レビューで「あれ、どう読むんだっけ？」と一度でも戸惑ったことのある開発者すべて。

「クリーンアーキテクチャ」というものがやりたいのではない。クリーンなアーキテクチャをつくりたいのだ。
そんな思いから、このセッションは始まります。

丁寧につくりあげた設計の理念が、納期・チーム事情・歴史的経緯を前にして思いどおりに適用できないことは珍しくありません。

本セッションでは、特定の設計流派にとらわれることなく、万能レイヤー構成を追い求めるのでもなく「現場で選び取るための判断軸」にフォーカスします。

• どこまで追い求め、どこで割り切るかの基準
• チーム負荷を増やさずに設計方針を整理する考え方
• 現場の文化を壊すことなく改善を提案し、合意を得るための工夫

完成形の図面ではなく、変化し続けるプロダクトと向き合うための「ゆるい設計術」を提案します。

想定対象者: 中規模 PHP プロダクトで設計・リファクタリングに関わるエンジニア

スナップショットテストは、複雑な出力の変化を検知するための便利な手法で、主にフロントエンド領域で発展してきました。近年では PHP においても導入されるケースが増えてきました。

しかし、テストの削除やリネーム、アサーションの回数の変化などにより、使われなくなったスナップショットファイルがリポジトリに残り続けてしまうという問題があります。これらの不要ファイルは徐々に蓄積し、リポジトリを散らかすだけでなく、レビュー時の混乱や誤認、さらには技術的負債や開発者のミスの温床となる可能性もあります。

この問題は長年にわたり認識されているにも関わらず、未だ決定的な解決策が存在しません。大規模なモノレポ環境で複数言語や複数スナップショットライブラリが併存し、独自のカスタマイズも加わっている状況では、汎用的な解法を構築するのは特に困難です。

この LT では、そうした課題に対し、使われなかったスナップショットを自動的に検出し、現実的でシンプルな解決策を提案します。

配属されたPHPプロダクトは、次につくる機能が決まっていませんでした。

私が担当することになったプロダクトは、立ち上げ時に想定していた機能をつくりきった状態でした。
しかし、ビジネスチームのメンバは他のタスクに追われ、次の開発方向性をなかなか決められず、小さなバグ修正や軽微改善のタスクばかりが提案される危険がありました。
そのため、次の一手をビジネスチームと一緒に考えることになりました。しかし、今までの開発チームはビジネスサイドからの要求を実装することがメインの仕事であり、主体的に開発の方向性を考えられるようになるためには、開発フローやいくつか"仕掛け"が必要でした。

このトークでは、ビジネスチームに頼っていた開発チームを、主体的に動けるチームに変えるために行ったことについてお話しします。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

はじめに

PHPの最新版は8.4になり、かなり進化しました。7.0が出たのはすでに10年前。
巷ではモダンなフロントエンド技術が流行っており、PHPerは圧倒的な高齢化の一途を辿っています。
「うちの会社は割と若い人もいるよ！」と思ったそこのあなた。では一番コード書ける人、一番技術力ある人も同じく若い人たちですか？

10年前、第一線で活躍してた人が今もポジション変わらずの状態であればイエローサインです。
PHP界の高齢化を防ぎ、若手が育ちやすい“新陳代謝のある”文化をつくっていきましょう。

ちなみに私は過去COBOLのプログラマーを「おじいちゃんばっかりじゃん」と思っていた時期がありますがそんな自分を殴りたい。

話す内容

• PHPは素敵な言語
• 勉強会による間口を広げるご提案
  • 老害化の注意点
• 他言語とのコラボを狙う
  • 例えばSPAのフロントはJS、API側PHP、というご提案
• PHPの普及ではなくPHPで作られたものの普及を考えてみる
  • 言語の良さを説いても限界がある
  • 魅力的なPHP製品の良さを伝えて、メンテをする楽しさを伝えてみる。WordPressとかEC-CUBEとか

技術の話よりかはPHPerのコミュニケーションの話です。
意見も聞きたいので、みなさんにも意見を聞きながらセッションを進めて行きたいと思っています。
一緒に高齢化阻止の方法を考えましょう

こんな人は聞いてほしい

• PHPの良さを改めて知りたい人
• PHPの良さって何なんですか？と言われてアピりたいけど答えに詰まってしまう人
• 最近若い人減って来たなぁと嘆いてる人
• もっとPHPerを増やしたい人
• ↑のように思ってるのに若者にマウントを取ってしまう人

私は今、受託開発の会社に勤めていますが、受託開発だと複数案件に関わることはあるあるだと思います。
ただ、参画したタイミングや状況により様々なポジションや開発言語で案件をかけもつことがあります。
時にはマネージャーとして管理を行い、時にはメンバーとして開発を行う。イレギュラーな事態は毎日発生し、考えていた進捗まで中々届かない。。
このLTはそんな中で自身を管理しつつ各案件をなるべく燃やさずに進めている方法をお話します。

名前の似た機能の実装を集約して、複数のドメインと機能でテーブルとAPIを共有する。

この設計アイディアによって、弊社機能の立ち上げは部分的には加速しましたが、サービスの成長に伴い高いコストをもたらしました。
この設計アイディアを社内では「汎用テーブル・API」と呼んでいます。

本トークでは、「汎用テーブル・API」がどのようなコストをもたらしたか、ドメインと機能の境界に沿ってテーブルとAPIを分割するまでの道のりを具体例を交えてお話しします。

以下の内容をお話しします。

• 「汎用テーブル・API」とは何か、どのようなコストを発生させているか
• ドメインと機能の境界に沿って分割するまでの具体的な手順

対象者:

• バックエンドの技術負債に向き合っている方
• DBテーブルのデータ移行に興味のある方

Agenda

1. What is DDD x Clean Architecture?
2. What kind of systems is it suitable for?
3. How was the actual implementation in Laravel?
   • What steps were taken to introduce it?
   • What kind of structure was used for the implementation?
   • Good points and bad points

※この資料の内容で話します！日本語版に直すのも可能です。
https://speakerdeck.com/bumptakayuki/laravel-x-clean-architecture

あなたのPHPコードはif文の中にたくさんの条件を連ねて条件分岐していませんか？
可読性の下がりがちな条件分岐、実はもっと読みやすく・テストしやすくすることができるんです！
Specificationパターンを使ったリファクタの実例をライトニングに紹介します。