皆さん、昨年度はどのように成長しましたか？
そして、今年度はどのような成長を計画していますか？

このトークでは、以下の方を対象に

• キャリアに悩んでいるジュニア層の方
• 「伸び悩んでいる」と感じている中堅の方

私自身が学習の速さにおいて一定の成果を上げてきた経験をもとに、次のような内容をお届けします。

• 短期的に素早くキャッチアップするために実践してきた具体的な方法
• 中期的に無駄なく成果を上げるために意識している戦術
• 長期的に自身の価値を高め続けるために考えている戦略

このトークを通じて、皆さんが自身の成長を加速させるためのヒントを得られることを願っています。

PHPのInterface、使っていますか？

このトークでは

• PHPはある程度読み書きできるが、オブジェクト指向や設計パターンに不安がある
• 「抽象に依存する」という考えがいまいち理解できていない
• Interfaceの使い方がいまいち腑に落ちていない

といった方を対象にサンプルコードをによる実践的な使い方を通して、
その根底にある原理原則を解説し、言語機能としてのInterfaceへの理解を深めると共に

• Interfaceがどのような場面で有用なのか？
• 良いインターフェースとはどんなものか？
• なぜInterfaceのような抽象的なものが必要になるのか？

を解説します

Interface、コワクナイヨ！

みなさんPHPStanを使っていますか？ PHPStanはオープンソースで開発されているので誰でもソースコードを読んで仕組みを学ぶことができ、理に適った提案であれば取り入れてもらうこともできます。

ところが静的解析ツールはPHPや標準関数の仕様通りに実装すれば完成すればるというわけでなく、さまざまな考慮事項や現実との折り合い付けかたなどがあります。

本トークでは私がこれまでPHPStanに送信したPull Request(※トークプロポーザル時点で未マージ含め49件)について分類して紹介します。

• 取り入れられた提案
• マージされたPR
• マージされなかった
• マージされたが後にrevertされた提案
• 投げ出してしまって完成していないPR

私たちは、プロダクトコードの中でさまざまなコードをtry-catchで囲み、ばしばしエラーを処理しています。
そしてエラー処理にはさまざまな選択肢があることを知ります。
例外を投げっぱなしにする（そもそもキャッチしない）、例外をキャッチして処理する、あるいは例外をキャッチしてうまく戻り値を定義する、など...です。

これまでプロダクトコードのみでの経験だった私は、OSSのコードを見て、「こんなアプローチもあるんだ」と新たな視点を得ることが多くありました。
特に例外処理に関しては、さまざまな場面での使い方や選択肢を知り、自分の考え方が広がりました。
このトークでは、プロダクトコードを書いていく中で実践的に得た知見と、OSSを通じて新たに学んだ例外処理の手法や考え方を深掘りします。

話すこと

• プロダクトコードにみる"例外処理"の扱い方
• OSSにみる"例外処理"の扱い方
• キャッチしたい場面・したくない場面
• 投げっぱなしにしたい場面・したくない場面
• 最適な選択肢をどう選ぶか

テストコードを書く中で、「モックとスタブの使い分けが分からない」「どちらを使うべきか迷う」と感じたことはありませんか？その原因は、テストコードの書き方そのものではなく、オブジェクト設計の曖昧さに起因している場合があります。

本トークでは、モックやスタブを「どう使うか」を直接学ぶのではなく、オブジェクト設計のアプローチを通じて、結果として自然に正しい使い分けができる状態を目指します。

具体的には、次のステップを通じてオブジェクト設計を進め、テストコードを構築する方法を解説します：

1. 依存するオブジェクトを明確にする
2. コマンドメソッドとクエリメソッドを明確に分離する
3. システム境界を超えるときにモックやスタブを使用する

これらのステップを経ることで、モックとスタブの選択が「意図した設計の結果」として整理され、テストコードを書く際に迷う必要がなくなる状態になるでしょう。

「ライブラリが古いせいでやりたいことが出来ない」なんて経験はありませんか？

古いライブラリは技術的負債であり、セキュリティリスクにもつながります。
本トークでは定期的なライブラリバージョンアップを続けている実体験をもとに、継続的バージョンアップのメリットや始め方についてお話します。

想定観客

• ライブラリのバージョンが古いせいで苦しんでいるかた
• セキュリティやパフォーマンスに敏感なかた

お話しすること

• なぜライブラリをバージョンアップするべきか
• バージョンアップ時に見るべきポイント
• 安全に上げるために整えている仕組み
• 継続的バージョンアップのはじめ方と文化作り

「テストがないコードはレガシーコードだ！」
Webアプリケーション開発においてテストコードが書かれることは一般的になってきました。

ですが、テストにかかる時間は適切でしょうか？ テストにかかる時間は開発スピードに大きな影響を及ぼします。
本トークでは自動テストを高速化するための考え方やテクニックについてお話します。

想定観客

• テストにかかる時間を短縮したい方

お話しすること

• Google提唱の「Test Sizes」を取り入れて、テスト対象をCIとローカルで変えるテスト戦略
• テスト実行の並列化 (Makefile, xargs, paratest)
• CIをジョブ分割して体感速度を上げる
• OPcache有効化とXDebug無効化による高速化

Laravelの魅力の一つであるORM「Eloquent Model」。
雰囲気でも動くものが書けてしまう反面、実は正しく動かなかったり、パフォーマンスの悪いコードを書いてしまう恐れがあります。

本トークではEloquent Modelを使うときにハマりがちなトラップを取り上げて、それらが「良くない理由」と「どうすれば良くなるか」をご紹介します。

想定観客

• 雰囲気でLaravelを書いている方
• 不具合が起きにくいコードを書きたい方
• パフォーマンスの良いコードを書きたい方

お話しすること

• そのメソッド、返り値nullableにつき
• 全件取得による富豪的プログラミングにご注意
• データベース泣かせのN+1問題
• 良くある間違いを仕組みで防ぐ (Laravel IDE Helper x PHPStan)

古いコードベースを読み解く作業はしばしば「ソフトウェア考古学」と呼ばれ、多くの人にとって大変で辛い作業と思われがちです。
しかし、サービスの歴史を辿ることで当時の設計思想や変化の過程を知ることができ、それ自体が良い設計を体験し、学べる貴重な機会でもあります。
私の実体験としても20年もの歴史のあるWebサービスの考古学からは学べることがたくさんありました。

本トークでは、新卒5年目エンジニアである私が、20年以上稼働し続けるWebサービスの改善に向き合う中で試行錯誤したことをお話しします。

お話すること

• 古いコードベースを読み解き改善を行った事例とその課題
  • Webメディアの広告運用のための管理画面改修
  • 歴史の塊のバッチ処理をPerlからPHPに移行する
• 全体を知るための「鳥の目」と細部を観察するための「虫の目」の考え方
  • 鳥の目で意図や構造を理解する作図ツールなどを使ったコードの読み方
  • 虫の目で詳細を把握するためのデバッグ方法
  • 「どこまで深掘りするか？」の判断基準
• ソフトウェア考古学の経験から学んだこと
  • 理解しやすいコードを書くコツ
    • 自分が書いたコード、その後どうなった？上手く行ったこと、行かなかったこと
  • ソフトウェアの健全な変化を助けるドキュメントとは？

話さないこと

• トークの中で出てくるツール自体の詳細な使い方
• リファクタリングやデータ移行といったソフトウェア改善に伴う手順の詳細

聴いてほしい人

• コードベースが古い環境で悩んでいる人
• 歴史のあるコードを改善したいと思っている人
• プロダクションコードに初めて触れ、規模の大きさや複雑さに圧倒された経験のある新卒の人たち

レガシーと向き合い続けるって大変ですよね。
大小様々な問題を抱えながらも、小さなパッチを当て続けることで生き抜いてきた、まさにプロダクトの中枢。
これはそんな「レガシーシステムのフルリプレイス」という大きな課題と向き合った、とある小さなチームの挑戦記です。

弊チームでは先日、大きな障害を出すことなく、レガシーシステムのリプレイスを終えることができました。
その際に以下の検証手法・リリース手法を組み合わせて、リスクを最小限に抑える「安全に倒し切ったリリース」を実現しました。

• チームオリジナルの検証手法「ペンギンテスト」
• シャドーテスト
• カナリアリリース
• ダークローンチ
• フォールトマスキング など

特筆すべきは「ペンギンテスト」で、これは以下のような特徴を持ったオリジナルの検証手法です。

• 本番環境で実際のデータを使いながらも
• ユーザー影響は出さない
• 未然に徹底的に見落としを削ぐための検証

この「ペンギンテスト」についてを主軸に、どのようにして予期せぬトラブルを未然に防ぎ、
計画通りのリプレイスを成し遂げたのか、その実践的なプロセスについて詳しくお話しします。

他の組織、チーム、プロダクトでも応用可能な知見を共有するので、
今同じような壁に直面している方には、有用な解決策の一つとして聞いていただけます。
安全に倒し切ったリリースを必要としている方、そして日々レガシーシステムと向き合う方は必見の内容です。

「フレームワークに依存するなと言っても、フレームワーク移行なんてほぼ起こらないのでは？」
そう思っていた頃が私にもありました。では、いま使っているフレームワークが開発停止になったらどうしますか？
かつて、symfonyはv1.4で開発を停止し、Symfony v2.0という名前で全く新しいフレームワーク（Symfony v2〜最新のv7は連続性があり、v1のみ別）に生まれ変わりました。
維持されたのは名称とMVCアーキテクチャベースであることだけ。使い方も、考え方も大きく変わってしまいました。当然、symfony v1を使ってアプリケーションを開発していた世界中の開発者は大混乱。
「ほぼ起こらないのでは？」と言われつつも、私がフレームワークに依存しない開発を求めてしまう原動力となっている当時の大混乱をふりかえり、フレームワークに依存しないことのメリット・デメリットと現代でのやり方についてお話します。

スクラム開発において「振り返り」と「スプリントゴール」は、単なるイベント以上の意味を持ちます。これらを形骸化させず、しっかり活用することでチームのパフォーマンスは大きく向上します。

本セッションでは、振り返りを通じて課題を具体的な改善アクションに変える方法や、スプリントゴールを設定する効果を説明します。

これらを実現した現場での成功例や失敗例を交えながら、スクラムの本質的な価値を掘り下げ、明日から実践できる具体的な方法論をお伝えします。スクラム開発を採用してもしていなくても、このセッションを通じてチームの開発プロセスを改善することができるでしょう。

サービスを作る上で、維持費と収益を獲得できるかどうかは、非常に重要な要素です。
StripeのDeveloper Relationsとしてユーザーや社内のプロジェクトに関わった経験と、
前職や個人開発におけるマネタイズに関する経験と想いを元に、ウェブサービスを開発する際のマネタイズ手法や料金モデル、そしてリリース後に発生しがちな請求管理に関するアレコレを紹介します。

トピックの例
・初期フェーズで決済・サブスクリプション機能の開発をやるべきか否か？
・開発工数と売上は比例しない話
・本当にあった、サブスクリプション請求管理で頭が痛くなる話

オブジェクト指向を学ぶ私たちは、必ず一度は「SOLID原則」に触れる機会があると思います。
私も何度も学習を重ねる中で、その原則がもたらす恩恵や、守ることの重要性を徐々に理解してきました。

…ただ、「リスコフの置換原則（LSP）」だけは「これを守るとどう良いのか？」がいまいちしっくりきていませんでした。
「同じ気持ち！」なあなたに向けて、このセッションでは、以下のようなお話をします。

・LSPとは何か？よくある例と「なぜピンとこないのか」
・実際に私が遭遇したLSP違反の具体例
・LSPと"継承"の関係性をしっかりと理解する

「なるほどLSP完全に理解した！」といってもらえるようなトークにします！