LaravelはWebアプリケーションを簡単に早く作成できる人気のフレームワークの１つです。Laravel本体の機能は非常に充実しており、3rd partyライブラリを使わなくても柔軟な開発ができます。しかしながら、デフォルトの設定や機能だけではLaravelの強みを十分に活かしきれません。例えば、マジックメソッドを多用したフレームワークなため、コア機能だけではEloquentモデルのプロパティやFacadeメソッドのコード補完が効きません。そこで laravel-ide-helper のライブラリを使うと自動生成されたヘルパーファイルによりコード補完が効くようになり、開発効率が上がります。不正なプロパティ・メソッド呼び出しもPHPStan/Larastanなどの静的解析ツールを入れることで事前検知ができ、より堅牢な開発ができます。

本トークではLaravelのアプリケーション開発で入れるべきツールや設定について紹介します。コード補完、静的解析、ロギング、パフォーマンス改善、デバッグ、フロントエンド、フォーマッター、ライブラリの定期アップグレードなど、それらを導入する理由やできることを紹介します。

このトークで紹介するツールや設定により、皆様のLaravelアプリケーション開発がもっと効率的で堅牢で楽しいものになれば幸いです。

外部システムと連携を行うときに、頭を痛めるのが ”APIでの連携” です。
API で機能連携を行う場合、みなさんも一度はこんな経験があるのではないでしょうか？

「レスポンスデータが扱いづらい」
「エラーレスポンスを適切にハンドリングできない」

私たちのチームでも同様の課題に直面しましたが、
API 呼び出し時に専用の Result 型 を用意することで、解消することができました。

これであなたも、API の仕様に惑わされない実装ができるようになります。

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

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

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

オブジェクト指向大好きPHPerのみんなで、構造化プログラミング以前のスタイルで考えてみよう というトークです
クラスも無ぇ、制御フローもマトモに無ぇ、globalやgoto頼り！！！
非構造化の世界で、ぼくらの「認知負荷」は、どうなっちゃうの・・！？

開発生産性や変更容易性が特に重んじられる昨今、「認知負荷」との闘いに多くの時間が費やされます。
プログラミング言語もまた、こうした課題を解決する「あるべき姿」へと進化してきました。

一方で、「解決済み」の問題は見えにくいものです。
関数を定義できる、if-elseが使えることに、感謝の気持ちを抱いていますか？

それを理解するためには、温故知新のアプローチが役立ちます。
時代を遡ってみましょう。
オブジェクト指向以前の・・・手続き型？いいえ、もっと根源へ──
脱・構造化です！

この探求の先に、「今とは全く違うように見えるパラダイム」と「現在の姿」が地続きであると実感することでしょう
そして今の世界にも通じる「良さ」の再確認へと繋がるトークを提供します

みんなでスパゲティを食べに行きましょう

対象者と得られること

• 「どうしたら読むのに疲れるコードを生み出せるのか」に興味がある人
• 逆説的に「普段の開発で避けるべきこと」を知る

話すこと

• 構造化プログラミングの簡単なおさらい(定義・歴史)
• 「非構造化」のルールに則って書いたコードの紹介: お題 => 簡易CMS
• これらを踏まえ「我々が普段やっている&戦っていることはどんな意味があるの？」の確認

「非構造化」のルール(一部)

• 使わない: クラスや例外、while(true)以外のループ、名前空間
• 制限する: ユーザー定義関数 => 引数は使わない、値を返さない
• 使う: gotoや標準関数は使う

システム設計における「美しさ」は単なる見た目や感覚の問題ではありません
それは設計を維持し、守り、そして未来へ導くための重要な基盤です
本トークでは「美しさ」を設計の中心に据える意義と、それがアーキテクチャ全体の秩序や一貫性をどのように支えるのかを深掘りします

美しいコードやシステムに触れ、感動を覚えたことはないでしょうか
技巧を凝らしたコードに感嘆し、理路整然としたシステムの完成度に心を打たれた経験があるかもしれません
美しさには人の本能に訴えかける抗いがたい魅力があります
この魅力はアーキテクトが最も大切にする「システムの未来を形作る力」を秘めています

本トークでは以下の内容をお話します

• 美しさの価値：美しさがなぜ有用で、アーキテクトにとって欠かせない要素であるのか
• 審美眼の鍛え方：美しさを見極め、活用するために必要な視点やアプローチ
• 実践的な活用法：美しさを設計プロセスに組み込み、システムの秩序を守るための具体的な方法

対象者:

• システム設計やアーキテクチャに関心のあるエンジニア・リーダー
• 持続可能な設計を目指す方
• チームでの設計文化を改善し、秩序あるアーキテクチャを構築したい方

美しさが設計にもたらす力を探求し、設計の未来を描くインスピレーションを手にしましょう

私が現在開発に携わっている販売管理サービス「楽楽販売」は誕生して15年以上経つプロダクトです。
フロントエンドにフレームワークは利用しておらず、長年にわたり静的に生成されるHTMLの画面部品コードがコピペされ続けており、共通化が行われていない状況に陥っています。
その結果コピペコードは新画面を作成するたびに増殖していき、PhpStormが親の仇の如く「Duplicated Code」を指摘してきます。

この課題を解消するため、私たちは以下の2つの目標を重視し「画面部品のUIコンポーネント化」に取り組みました。
　・新しい画面を作成する際に、コピペする必要がない環境を構築する
　・画面の構成パーツに何があるのかを容易に把握できる仕組みを作る

ゴールは以下２点です。
・複数画面から共通利用可能なUIコンポーネントを作成する
・将来的なコピペを駆逐すること

本セッションでは、取り組みの背景の課題から具体的な解決策、さらに実践例までを詳しくご紹介します。

■お話しすること
　・なぜUIコンポーネント化が必要か
　・どのようにコンポーネント化を進めたか
　・コンポーネント部品を活用してもらうための施策

■想定する視聴者
　・技術負債を解消したい人
　・フロントエンドのフレームワークを利用していない人
　・画面部品のUIコンポーネント化に興味がある人
　・レガシープロダクトから脱却したい人

OpenAPIはAPIの仕様を記述するための仕様で、リクエストやレスポンスの詳細をYAMLまたはJSON形式で記述することができます。これを採用すると、記載内容を統一できる、バージョン管理しやすいなど様々なメリットがあります。
しかし、単なる仕様書と考えていると、徐々に実装との乖離が生まれてしまうリスクがあります。

これを防ぐための仕組みとして、OpenAPIドキュメントを使ってコードを生成したり、実行時に検査をする手法があります。
本セッションでは、Slimフレームワークを採用したシステムにOpenAPIドキュメントを用いたバリデーションとテストを導入した実例をご紹介します。
具体的には以下のような内容を含みます。

• OpenAPIを導入する際のポイントと注意点
• 具体的な実装方法 (league/openapi-psr7-validator)
• 導入の効果と進め方の反省点

Slim以外のフレームワークをお使いの方にも役立つセッションになるはずです。

ソフトウェア開発を行うエンジニアで「『技術的負債』という言葉を知らない」という方は今日においてほとんどいないと思います。その一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くないように思います。その相手が非エンジニアであればなおさらです。

また、技術的負債についての理解が不十分なことによる誤解や偏見も散見されます。例えば「技術的負債＝悪」というイメージから無用・無謀なリファクタリングを行ったり、逆に放置しすぎた結果、ビジネスにおけるリスクが表面化してしまうこともあります。

このトークを通じて技術的負債についての理解を深め、技術的負債とどのように向き合えばよいのか、その具体的なアプローチを考えるきっかけにしていただければと思います。

お話しすること

• 技術的負債とはなにか
• 技術的負債はいつ・どうして生まれるのか
• 技術的負債を放置することで発生するビジネス面・技術面でのリスクとは
• 技術的負債を最小限に抑えるいくつかのテクニック
• 技術的負債とどう付き合っていくべきか

メンター「力がほしいか、、、？」
私「ほしい！」
メンター「ならばLaravelを写経せよ」
私「？？？」

会社のメンターに実力をつけたいと相談したところ、自分の使っている道具を細部まで知ることによって、誰よりも強くなれると教えられました。
幅広く使ってもらうように作るフレームワークとそのフレームワークを使って作る業務に特化したアプリケーションでは、そもそも作るときの思想が違うのでは？と一度は思った私でしたが、そういう言い訳はやってから言わないといけないと思い、素直に写経を行うことにしました。

そこで写経の際にどのような順番で取り組み、その都度どのようなことを考え、そこで学んだこと、そして写経に意味があったのかどうかという、この挑戦の足跡を伝えていきたいと思います。

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

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

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

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

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

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

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を使ってアプリケーションを開発していた世界中の開発者は大混乱。
「ほぼ起こらないのでは？」と言われつつも、私がフレームワークに依存しない開発を求めてしまう原動力となっている当時の大混乱をふりかえり、フレームワークに依存しないことのメリット・デメリットと現代でのやり方についてお話します。