私たち開発者にとってログは非常に重要です。
開発時のデバッグやローンチ後の障害解析など、ログを出力していることで救われたシーンは多かれ少なかれあるのではないでしょうか？

そんな私たちを助けてくれるログですが、Laravelでは様々な設定やカスタマイズが可能です。
しかしどのような設定ができるのか理解するところまで手が回らず、デフォルトのまま運用してそのままという悲しいシーンを見ることも多々あります。

このトークでは実際にログ出力する際にLaravelのLogManagerがどのような処理を行なってログを出力するのか、各設定の詳細、Laravel10より追加されているLaravelPailを用いたログの限定出力のやり方等をお話ししますので、今後のログ運用の助けになれば幸いです！

新しいプロダクト開発は失敗が避けられませんが、リスクやコストを最小限に抑えてメンバーが納得する規模でリリースすることで、失敗する恐怖を抑えることはできます。
本セッションでは、ユーザーストーリーマッピングを活用し、『安価に失敗する』ためのプロダクト開発の進め方についてご紹介します。
実際にリリースしたプロジェクトを事例に、どのようにプロダクト開発を進めていったかお伝えします。

新しく加入したメンバーの皆さん、チームに馴染めていますか？
新しいメンバーを迎えた皆さん、メンバーに馴染めてもらえていますか？

一説によるとWebエンジニアの平均在籍年数はおよそ3〜4年だそうです
ということは、最初の半年〜1年である程度新しいメンバーを戦力化できないと、エージェントに支払う費用などを考えると企業としてはよくてトントン、悪いとマイナスになってしまいます

このトークでは「馴染む速さ」に定評のあるいち個人が最近の転職で経験した

• 「オンボーディングされる側」として意識していたことでうまくいったこと
• 自分が組織に馴染む速さを支えてくれた会社の文化
• 上記を２つを支えていると感じた社内の仕組み

についてお話させていただきます。

採用する側、される側双方にとってのヒントになれば幸いです

皆さんは『プロダクト開発者』と聞くと開発者をイメージをしますか？
『プロダクト開発者』と従来の『ソフトウェア開発者／エンジニア』の違いは説明できますか？
（これはおそらく一定答えられる人がいると思います）

あるいは『GLAD開発者』という語彙を聞いたことがありますか？
（おそらく聞いたことある人は日本ではほとんどいないと思います）

この新しい語彙はどのような開発者像を指すのでしょうか？
また、それは従来の『プロダクト開発者』や『ソフトウェア開発者』と何が違うのでしょうか？

このトークでは先日私が衝撃を受けるとともに、長い事悩んでいた

• 専門性を高めるべきか？それとも他の道を探るべきか？
• そもそも21世紀の開発者はどうあるべきなのか？

といった問いに対する一つの回答例となった（と感じた）アイディアを共有します

Interfaceの設計、していますか？

適切なInterface設計はコードの再利用性を高め、保守性を高める一方
不適切な設計をしてしまうと不要な複雑性を周辺に生み出し保守性に大きな悪影響を及ぼしてしまいます

このトークでは

• 「Interfaceを設計する」とは？
• 「良いインターフェース」とは？
• インターフェース設計とその先

といった切り口に対して

• サンプルコード
• 有名な設計原則
• 書籍の引用

などを用いながら「良いInterface設計」についての考察とその効果について解説します

クリーンアーキテクチャを学ぶと、まず目にするのがあの同心円構造です。
そのため、構造、レイヤーの配置に注目されがちですが、本質は依存の向きを整えることにあるとわたしは思っています。

クリーンアーキテクチャが伝えたいのは、構造や配置ではなく、オブジェクトの依存関係を制御することで得られる柔軟性や保守性を高めるための考え方です。

当トークでは、この「依存の向き」と「依存の制御」がなぜ重要なのかを深掘りし、以下の点に焦点を当てます。

■ 依存の向きの重要性
「依存性は、内側だけに向かっていかなくてはならない」というルールがなぜ重要で、システムの安定性にどう貢献するのか。

■ 依存性逆転の原則（DIP）
SOLID原則の一つである依存性逆転の原則を取り上げ、依存の制御がシステムの柔軟性と保守性にどうつながるのか。

一緒に依存の向きの大切さを理解し、設計へ活かす方法を学びましょう。

複雑な条件分岐を含むビジネスロジックは、if文の入れ子で実装されがちです。
しかし、この方法では条件の追加や変更が困難で、保守性が著しく低下します。

デシジョンテーブル（決定表）は、複数の条件と結果の組み合わせを表形式で整理できる強力なツールです。
このテーブルをコードとして実装することで、ビジネスロジックの可視性が高まり、条件変更への耐性も向上します。

本セッションでは、デシジョンテーブルの実装パターンと実践的なコード例を紹介します。
さらに、ユニットテストとの相性の良さ、仕様変更への強さなど、実装のメリットを実例とともに解説します。
明日のコーディングから活用できる具体的な実装テクニックをお持ち帰りいただけます。

コードレビューは、チームの成長やコードの品質向上に欠かせないプロセスですが、組織やチーム体制によって位置づけや進め方が変わります。
本トークでは、コードレビューを効果的に運用するための工夫や、期待できる効果・避けるべきリスクについて考えてみましょう。

本トークで話す内容

• チームや組織ごとに異なるコードレビューの役割
• コードレビューに期待できること、気をつけるべき点
• レビュアーとレビュイーそれぞれの心構えと準備

何かしらのツールを入れたいが、予算がない・・・
なら、コストを削って予算を作ってみませんか？

本講演では、AWSを活用したシステム運用において、
使用頻度が高いサービスのコストを削減するためのテクニックを紹介します。

手軽にコストをカットする方法をはじめとして、
時間の許す限り、注意点も交えながら、以下のような内容を説明します。

主要サービスの特性理解と最適化: EC2、RDS、S3、Lambdaなど、よく使われるサービスでのコスト削減方法
・インスタンスの選択: リザーブド活用によるコスト最小化など
・ストレージコストの管理: S3でライフサイクルポリシーによる不要データの自動アーカイブ
・サーバーレスアーキテクチャの活用: LambdaでPHP

「この関数の実装、頭に入りきらないな...」「結局このコード何がしたいんだ...?」
みなさんこんなことを思った経験はないでしょうか？
これ、もしかすると抽象レベルが整っていないことが原因かもしれません。

このセッションでは

• 認知負荷を抑えたロジックを書く方法
• ロジックの情報量をコントロールする方法
• 抽象レベルを整えるとなぜ関心の分離ができるのか

などをお話しします。

PHPドキュメンテーション
「password_hash() は、 アルゴリズムやコスト、ソルトといった情報もハッシュに含めて返すことに注意しましょう。 」
ぼく
「え、ソルトも同じところにあったらセキュリティ的に意味ないんじゃ？」

このセッションでは、そんな疑問に答えるべく、password_hash関数について掘り下げて解説します。
そもそもパスワードをハッシュ化する目的や、パスワードにまつわる攻撃手段とその対応を見ていきましょう。

話すこと

• ハッシュ化とは何か
• なぜパスワードはハッシュ化する必要があるのか
• ソルトは何を解決するか
• ブルートフォース攻撃やタイミング攻撃への対応

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

DDDといっても、複数のアーキテクチャ(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)があると思います。この中でどのアーキテクチャを選定するかって悩みませんか？
そんな方向けに各アーキテクチャの比較をした話をします！

話すこと

• プロジェクトの検討観点(開発規模、開発メンバーの体制、外部システムとの連携など)
• 各アーキテクチャの比較(クリーンアーキテクチャ、オニオンアーキテクチャ、ヘキサゴナルアーキテクチャなど)
• 各アーキテクチャごとの向いているプロジェクトは？

本格的にDDDを導入しようとすると、なかなかヘビーで実際、開発が始まると開発スピードが上がらないこともあると思います。
そんな方向けに軽量DDDという設計手法をお伝えします！

そもそも軽量DDDとは？

• DDDのValueOvject、Entity、Repositoryなどを部分的にお作法のみを取れ入れ、DDDを行うというアンチパターンとして語られているものです。
• もしくは、コアドメイン、サブドメイン、境界付けられたコンテキスト、ユビキタス言語などを意識していないもの。

話す内容

• 軽量DDDとは？
• 軽量DDDが向いているプロジェクト、向いていないプロジェクト
• 実際の導入した場合の構成などの説明

皆さんLaravelでDDDやりたいと思ったことありませんか！？
このトークではこれから、DDDを始めたい人向けに導入方法やディレクトリ構成についてお話します。

□話す内容

• DDDでどのアーキテクチャを選定するべきか？選定基準は？
• LaravelでのDDDの導入ステップは？
• Laravelに導入する場合はどのようなディレクトリ構成が良いか？

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

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

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

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

一時期「PHP とバージョン番号の変遷が似ている」と言われた MySQL。

つい最近バージョン 5.7 から 8.0 へのマイグレーションが済んだばかりの方も多そうな気がしますが、バージョン 8.0.34 / 8.1.0 からリリースモデルが変更になり、LTS として 8.4 系が、イノベーションリリースとして 9.x 系が登場するなど、すでに「8.0 より後の世界」に進んでいます。

このセッションでは、 普段 MySQL の動向について追いかけていない方々に向けて、以下のような内容をお伝えします。

• リリースモデル変更ざっくりおさらい
• 8.0 以降のバージョンへのマイグレーション
• 周辺ツールの変化
• たまには思い出してあげてほしい HeatWave
• 【おまけ】 phpMyAdmin の Issues から眺める MySQL の変更点

良い設計は「コードの書き換えやすさ」をもたらします
そのためには、関心の分離や抽象度の調整といった仕事が必要です。難しそうですね¯\(ツ)/¯

見方を変えれば 今、一緒に考える?後回しにしたい?を意識すれば、良い感じになりそう と言えるでしょう
コードを書きながら「ここ面倒臭いな」と思う場面、ありますよね？そこにヒントが眠っています

原則やパターン等の形式知だけでなく、感覚に頼って「良い設計」を手に入れられるはず！！というのが本トークの主張です

話すこと

• プログラミング中の「(誰しも)あるある話」を取っ掛かりに
• 実はそれがチャンスであることと、対処法を示し
• 「何故それで良いと言えるのか」の論理的な補強を行う

ねらい

• こんな人に: 「設計って難しそう・自分にはまだ早い」と感じている人
• こんなお土産を: 「良い設計を目指す最初の一歩」になる

PHPアプリケーションをサーバレス環境で動かしたいと思ったことはありませんか？軽く調査していくといくつかやり方はあるようです。

このセッションでは私が実際に様々な方法で簡単なPHPアプリケーションをデプロイしてみてわかったことを共有します。
ホスティング先の参考になれば嬉しいです。

時間の許す限り、以下のようなプラットフォームやツールをセッション中扱う予定です:

• AWS Lambda
• Google Cloud Functions
• Google Cloud Run
• Vercel Functions
• fly[.]io
• Serverless Framework
• Bref

DRY（Don't Repeat Yourself）原則はコードの重複を減らし、保守性を高める効果的な手法ですが、適用の仕方によっては仕様変更に対応できなくなることがあります。
私が直面したのは、二つの似た処理を一つのメソッドに統合し、フラグで細かい違いを切り替えるコードでした。しかし、片方の処理を変更すると、もう片方にも影響が出てメソッドが複雑化する…これ本当にDRYなん？と思いました。

このトークでは、当時はDRYだったものが、時間とともに保守性を損ない、結果的にDRYではなくなったケースについて紹介します。
何を共通化し、何を分離すべきかを考え直し、どのようにリファクタリングを行ったかについて具体的な事例を交えてお話します！

「当時はこうでよかったが、今ここに大変更を加えたい」と感じている方や、似たような体験をした方にとって、私の対処方法が参考になれば嬉しいです！