トーク

私はEM2年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後の成長にあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションではそのような状況に対応するため、繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

レコメンド機能や新機能の効果予測など、ウェブアプリケーションで使われる機械学習はエコシステムが出来上がっているpythonで実装されることが多く、ウェブアプリケーション自体はPHPでもデータ取得や推論部分はpythonで実装されていることがほとんどだと思います。
課題は

1. データスキーマをPHPで定義した場合、スキーマを変更したときにデータ取得のpython側でもスキーマを考慮する必要がある
2. ウェブアプリケーションと違う言語なので、頭の切り替えコストが高い
3. python側とのリクエスト/レスポンスの設計が難しく、リアルタイムデータを推論エンジンに与えようとすると、POSTのbodyが超巨大になることもある

PHPのデータ整形/機械学習エコシステムは砂漠状態のため、どうしてもPHPで機械学習をしたい私がPHPの機械学習でできたこと/できなかったことを紹介します

PHPは基本的にシングルスレッドで動作します。そのため、並列処理は得意ではありません。
外部APIを複数叩くようなWebアプリケーションを作ろうと思った場合、1つずつ外部APIのレスポンスを待っていたのでは、処理完了に時間がかかりすぎてしまいます。

PHP製のHTTPクライアントライブラリであるGuzzleでは、非同期リクエストがサポートされており、複数のHTTPリクエストを同時に投げることができます。

並列処理が苦手なはずのPHPで、なぜそんなことが可能なのでしょうか？
このセッションではGuzzleのソースコードを紐解きながら、非同期リクエストがどのように実現されているのか、Guzzleに何ができて何ができないのかを見ていきます。

コードゴルフという競技をご存知でしょうか？
与えられたお題に対して、どれだけ“短く”コードを書けるかを競うもので、今年3月のPHPerKaigi 2025では「PHPerコードバトル」として開催され、大いに盛り上がりました。

コードゴルフでは、可読性や保守性は重視されず、むしろ犠牲にしてでも短く書くことが求められます。
一見実務とは無縁に思えるかもしれませんが、実はこの競技、PHPの文法や関数についての深い知識が求められるため、楽しんでいるうちに言語仕様に詳しくなってしまうという学習効果もあるのです。

このセッションでは、コードゴルフで実際に使われるトリッキーなテクニックと、それを支えるPHPの言語仕様や関数の挙動について解説します。
例えば、PHPの文と式の違い、普段あまり使わないマイナーな関数の仕様など、ちょっとした遊びからPHPの理解が深まる世界をご紹介します！

PHPStanがどのように解析を行っているのか、型を決定しているのかを普段意識することはほとんど無いと思います。
しかし、仕組みを理解することで活用の幅がもっと広がり、そしてかっこよくなれます！

そこで本トークでは、PHPStanへのコントリビュートを通して、更にPHPStanに詳しくなった経験についてお話します。

話す内容

• PHPStanが型を決定する仕組み
• 拡張について
• 実際に提案した内容・追加した内容について
• コントリビュートポイントの探し方
• PR作成からマージまでの流れについて

古くなったプロダクトのコードをリファクタリングしようとして、逆に障害を招いてしまった。そんな経験を何度かしてきました。
特にPHPでは、なんとなくコードを変えただけで、思わぬところが壊れてしまうことも少なくありません。

今回は、そんなPHPリファクタリングでの失敗談を、びゃっと5分でご紹介します。
このトークが、みなさんのしくじりを防ぐヒントになれば幸いです。

PHP8へのメジャーアップデートに挑戦した際、PHPUnitのメジャーアップデート対応など、久しぶりにPHPを触るにしては越えるべきハードルが複数ありました。
ハードルを越えるためにCursor / Claudeを活用して調査や試行錯誤を試みた際の経験を紹介します。

私が担当しているメール共有サービスのメールディーラーは2001年にローンチしましたが、
プログラム構造の陳腐化がリリースを行うごとに進み、いわゆる「スパゲッティコード」が散在し、
それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能が動作しなくなる致命的な障害が発生しました。

これらの対策としてE2Eテストを導入しそれを自動化しました。

E2Eテストを導入したことで、致命的な障害が防げたか？など得られた効果や
テストコードの実装やテストケースの作成における工夫ポイントなど、可能な限り具体的に説明いたします。

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

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

AWSやコンテナは新しい技術ではありませんが、メールディーラーは全機能が一つのサーバに実装されており、
WebサーバとDBがひとつのサーバに集約されているため、導入には苦労しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
可能な限り事例を交えて説明いたします。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先では、PHPを使ったアプリケーションを開発、運用していました。
ただ、チームの状況を見てみると鳴り響くアラートの対応に疲弊していました。
異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• 問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• 調査から対応するまでのリードタイムが長い

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• アラート対応が属人化しないようなアプリケーション設計、チーム作りをしたい方

想定聴講者

• センシティブな値を扱うシステムの開発をしている人
• テストだけでは挙動の担保に不安で、リファクタリングに踏み切れない人

話すこと

• 安全にリファクタリングする方法
• テスト以外で挙動が変わらないことを担保する方法

説明

私たちの会計システムには、取り扱いを誤ると大きな問題につながる金額などのセンシティブな値が存在します。
これらのコードのリファクタリングは安易に手を加えるには不安があり、例えテストがあってもなかなか手をつけられません。

本セッションでは、私が実際に行った"安全な"リファクタリングの手順とその方法についてお話します。

WordPressはPHPで動作するOSSの1つで、多くのウェブサイトにて現在も利活用されています。しかし多様化するウェブサイトの要件に対応するため、プラグインやfunctions.phpへのコード追加による複雑なカスタマイズが施され、保守性が悪化しているケースも少なくありません。

「コンテンツを快適に発信できる場所」というCMS本来の力を活かしつつ、アップデートの手間やアプリケーションの複雑化による負荷増加などを回避するための方法として、「クラウドサービスへのオフロード」を提案します。

セッションでは、AWSやCloudflareなどのサービスが持つフルマネージドな機能を活用し、大規模なウェブサイトの構成をシンプルかつアップデートしやすい形にする方法を、「サイト内検索」「検索エンジン最適化」「アクセス集中対策のトレードオフ」の3点から紹介します。

PHPを社会人になって初めて触りました。またLaravelというフレームワークを知りました。そして新卒だった自分はアプリの初期開発でフレームワークの自由さに魅了され、振り回され、恥の多いコードを書きました。その後、過去の自分が未来の自分を苦しめ、改善を決意し、小さく小さくコツコツと改善を進めました。

本セッションでは自分がどんな恥の多いコードを書いてきたのか、どうやってコード的な側面、非コード的な側面からシステムを改善していけるかを実体験をもとにご紹介していきます。
セッションを聞いた方が「自分と似た経験をしないための知識」、「しくじりを自分の成長に変えていける引き出し」を得られたら幸いです。

話すこと(変更の可能性あり)
・ 設計を知らないで実装をするとこんなことしちゃう
・ 自分が行った小さな改善作業(技術側面、非技術側面)

平均80点ぐらい取れるAWS構成とその使い所と細かいハマりポイントを紹介します

セキュリテイの巻

• rate limitのハマりポイント、WAFとLaravel
• .envに書く内容はパラメーターストアにいれておこう
• ECSはプライベートサブネット(イメージPullできない問題)

コストの巻

• 画像類はなるべくS3に置く(公開したくないやつをlaravelでどうやって表示する？)
• t4gインスタンスいいぞ！（昔はPHPとARMの相性悪かったらしいが）
• ほんとにNginxいる？(Franken PHPでコンテナ一個で運用するのはどうだろう、Nextjsと比較)

動作確認の巻

• ローカルスタックのS3は割と使い勝手が良い
• でも、メールはsmtpでmailtrapとか建てたほうが楽かも
• というかその辺Laravelで良い感じにできる

継続的インテグレーションおよび継続的デリバリー（CI/CD）パイプラインは、昨今のソフトウェア開発ならびに運用・保守で広く普及するようになり、開発プロセスやセキュリティ対策を最適化させる上で欠かせないものになっています。一方、CI/CDパイプラインの使い方によっては攻撃者に標的にされてしまうケースが出始めています。

本トークでは、開発者の生産性を向上させるCI/CDツールとして広く利用されているGitHub Actionsで考慮すべき脅威やセキュリティ観点を解説し、保護策を検討する際のポイントや、ワークフローの改ざんおよび不正実行の防止に役立つツールを紹介します。GitHub Actionsにおける脅威や攻撃手法の対策を踏まえた上で、改めてGitHub Actionsのセキュリティを点検してみましょう。

純粋関数(pure function)という言葉を聞いたことはありますか？ 簡単にいうと、同じ引数を渡せば必ず同じ結果を返す関数のことで、しばしば数学的な関数とも説明されます。

同じ引数で同じ結果ということは確実な再現性があるということで、「純粋」の概念を知って純粋と不純な処理を切り分けられれば、コードを見通しよく、テストしやすいコードにすることもできます。

言葉をトークでは「純粋」および「副作用」という概念について学び、コードを改善するための手掛かりを学びます。

ソフトウェア開発で、「モデル」という概念が使われるようになって数十年。モデルに関する解説も世に多く出ています。皆さんの慣れ親しんだフレームワークでも、モデルという要素が普通に存在し、日々の開発で使っているかと思います。

ところで、モデルって何なのでしょうか？ 概念？ ビジネスロジック？
これらはモデルの用途ではありますが、すべてではありません。
モデルが真に力を発揮するのは、自分でモデルを設計したときです。

このトークでは、よくある予約システムを例に、素朴な設計のモデルからひと工夫加えた設計を行うことによって小さなブレイクスルーが起きる過程を具体例を用いながら説明し、聞いている方にモデルの設計のパワーを追体験して頂きます。

このトークを通じて、聞いている方のモデルについての理解をアップデートし、ソフトウェア開発に登場するモデルに関する諸問題を柔軟に取り扱えるようになって頂きます。

皆さんは、インプットだけでなく、記事を書いたり、LTをしたりといったアウトプットをしていますか？僕は、1年前Qiitaに記事を投稿し始めるまではほとんどアウトプットをしていませんでした。

そんな僕が、去年の2月からQiitaに毎日記事を投稿し始め、約1年でなんと160記事を公開しました。
テーマは主にPHPやReactなど、日々の学びや実践で得た知見です。

「アウトプット経験ゼロ」からスタートした僕が、どのようにして投稿を続け、何を得たのかについてお話しします。

お話しする内容：
　・どんな内容の記事を書いたのか
　・毎日投稿して感じたメリット（知識の定着、反応がもらえる楽しさなど）
　・デメリットや大変だったこと（ネタ切れ、モチベ維持など）
　・投稿を通して得られた成長
　・やってみて感じた素直な感想

「自分も何か書いてみようかな」と思ってもらえるきっかけになれば嬉しいです！

開発が終わってしまったテストフレームワークをリプレイスした事例を元に、技術的負債にどうやって戦ったのかを紹介します。

トーク内容（予定）

• 具体的な課題
  • 開発終了したフレームワークがもたらしていた具体的な課題（メンテナンスコスト、実行速度、新機能への追従困難など）
• 立てた戦略
  • 段階的移行か一括移行か、手動か自動か
• リファクタリングツールの検討
  • rector の紹介
• 得られた成果

最近弊社ではmcpというワードをちらほら見かけます。
そうだ、phpでmcpを作ってみよう！
でも、phpにはmcpのsdkがありません！！😨

mcpとはなんぞや？から、どういうことをすればmcpができるのか？

※まだ何も着手していないので、どこまで紹介できるかわかりませんが
全力でphp&mcpについて紹介したいと思います！