トーク

SOLID原則・凝集性・結合度・関心の分離・DDD・クリーンアキテクチャ...
設計を考える際、学ぶべき原理や手法が多すぎて圧倒されてしまうこともありますよね。

しかし、これら設計原則は、実は私たちがよく知っている「英語の文法」にヒントが隠されているかも...?
英文法の基本的なルールに着目することで、仮に設計原則を知らなくても、シンプルで明確な設計ができるようになるかもしれません！

このトークでは、SVO・SVOCなど基礎的な英語文法がどのようにコード設計に応用できるかを具体的に解説します。
例)

• S(主語)やV(動詞)の明確化が単一責任原則の遵守に繋がること
• 「S(主語)がV(動詞)した」とクラス設計を考えることの恩恵
• コード上での形容詞・副詞の在り方

想定聴講者

• 設計詳しくないけど興味がある人
• 設計に原理・手法多くてなかなか手を出せないでいる人

人生初プロポーザル提出です！
登壇経験ありません！

Laravel 11 がリリースされて半年以上経ちましたが、皆さんの会社では、技術力向上のためにどのような取り組みをされていますか？

弊社では、7月から「Laravel 11 公式ドキュメント輪読会」を実施しています。
ざっくり進める会ですが、初心者には理解が難しいことも多く、Slackでの共有内容も後から見返すのが大変です。

そこで新卒エンジニアである私が考えました！
「参加していないメンバーや後から振り返るメンバーにも役立つ資料の作り方」を提案します。

公式ドキュメントを活用し、メンバーが知見を追加できる資料作成の手法を提案します。
これにより、輪読会の参加者だけでなく、後から参照するメンバーとも知識を共有できます。

当日は、この資料作成の方法や活用方法を実例を交えて紹介します。

みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

モックを使ったメソッド呼び出しの検証方法
高度な引数の比較を使った柔軟なテスト
実務でのテストケースの実例紹介
Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

わたしは十数年間この業界にいますが、いろいろなサービス層を見てきました。

• DB処理が大量に詰め込まれたサービス
• トランザクションスクリプトがひしめくサービス
• どこからでも呼ばれてしまう「神」サービス
• 複数のサービスと手を組み、仲良く連携するサービス
• ドメイン層を支えるサービス
• 取り急ぎ作られた「なんちゃって」サービス

そこには、愛らしいサービスもあれば、目を背けたくなるサービスもいました。
そしてこう思うのです「人には人それぞれのサービス層がある」と。

なぜ、人はみなそれぞれのサービス層を作ってやまないのか謎に迫りつつ、

• サービス層とはそもそも何なのか
• 憎まれるサービス、愛されるサービスとはなにか
• 理想のサービス層とはどんな姿をしているのか

について、SOLID原則、特にSRPを切り口として理想的なサービス層について考察したいと思います。

みなさん、モックは好きですか？わたしは好きです。
外部依存から隔離してテストの実行を容易にしたり、テストを高速化できるからです。最高。

ですが、わたしが観測している限りどうやらモックというのはテストが壊れやすくなるので、なるべく使わない方がいいという風潮も耳にします。
ではテストが壊れにくければモックは使っていいのでしょうか。モックを使うとテストが壊れやすくなるのでしょうか。善いモックというのは無いのでしょうか。

そういった疑問を解消すべく、果たしてモックは悪いのか、善いモックというのはあるのか、モックの使い方はどうあるべきかをお話できればと思います。

キーワード

• 壊れやすいテストとは何か
• 実装の詳細が漏れるとは何か
• ロンドン学派vs古典学派
• アウトサイドインvsインサイドアウト
• モック、スタブ、スパイ
• モックとしての振る舞いとスタブとしての振る舞い

本セッションは、Laravelを使って現場でCIをぶん回すエンジニアを対象に、CI/CDパイプラインのベストプラクティスを紹介します。

PHPUnitとParatestなどを活用し、テスト時間を短縮しつつ、GitHub Actionsでコストパフォーマンスを最大化する方法を具体例とともに解説します。

⚪︎ CIの高速化
⚪︎ 効率的なリソース管理
⚪︎ カードで必要な変更

を交えつつポイントを共有します。

昨年7月から11月にかけて、49歳で約25年勤めた会社を退職してソフトウェアエンジニアとして転職活動を行い、PHPを書ける会社に転職しました。
比較的高齢なおじさんがどのような気持ちで転職活動をおこない、その結果どうなったのかをできるだけ赤裸々に且つスピーディにお話しします。

Laravelアプリケーションと事業の成長に伴い、フェーズごとに最適なアーキテクチャは変化します。

本セッションでは、シードフェーズからシリーズA、さらなる成長フェーズに至るまで、各段階でのアーキテクチャの変遷と最適化ポイント(スケーラビリティ、コスト効率、開発速度などのバランス)をメインの観点として保ちながら、持続可能なシステム設計を実現するためにやった施策を交えて紹介します

みなさん、ドメインイベントって使っていますか？

このトークでは、ドメインイベントを使ってPHPコードをリファクタリングする方法についてお話しします。ドメインイベントは、ビジネスドメインで発生する「出来事」を表現するモデルで、これをうまく使うことで、副作用をわかりやすく整理し、システムをシンプルにできます。

ドメインイベントを導入してみると、「あ、こんな風に設計すれば良いんだ！」と新しい発見があるはずです。リファクタリングを通じて、どうやってドメインイベントを設計し、活用するのか、その具体的な手法をお伝えします！

話すこと

• ドメインイベントって何？
• リファクタリングでドメインイベントをどう導入するか
• システム間の連携を簡単にするイベントの使い方

開発しているときにこんなことはありませんか？
「プロダクションコードをきれいに書きたいけど、なかなか書く時間が取れない・・・。」
「ここを触る前にリファクタリングしたいけど、納期的にそんな余裕はないしなぁ・・・。」
「// TODO: いつかキレイに直す」

リファクタリングしたい気持ちはありつつも、機能開発の事業価値とリファクタリングによる事業価値を天秤にかける必要があります。
しかし、リファクタリングによる事業貢献度を算出するのはなかなか難しく、なかなかここを説得力のある数字を出しながら進めていくのは骨が折れます。

本セッションでは、このリファクタリングによる事業貢献度を算出するための考え方と、
PhpMetrics( https://www.phpmetrics.org/ )を使い 開発的にも、事業的にも 効率よくリファクタリングをしていく方法について話します。

OOP はクラスやオブジェクトというものを前提としています。また、「抽象化」や「一般化」「共通化」というような用語がプログラミングでは普通に使われます。
OOPの設計・実装では「こう書けば後からうまくいく」式の解説ばかりですが、その実OOPの本質に立ち向かったものは少ないのではないでしょうか。

本発表では、西洋哲学の知恵を借りてOOPという営みを捉え直すというチャレンジをします。
最初に「クラスはプラトンのイデア論に似ている」というOOP界隈で真っ先に言及されるこの命題が真か偽か考察することから始めます。
プロポーザル執筆時では、プラトン、アリストテレス、カント、ウィトゲンシュタイン（後期）には言及する予定です。
なお、アラン・ケイの考えていた本当のオブジェクト指向にも言及する予定です

このワークショップでは、ゼロからLT（Lightning Talk）を考えて、資料を用意し、実際に発表するまでをやっていきます！

でも、そもそもアウトプットって何で大事なんでしょう？
自分の成長に気づけたり、他の人に新しい気づきを与えたり、メリットはたくさんありますよね！
とはいえ、「何を話せばいいの？」「資料ってどう作るの？」って不安もありますよね。実際、アウトプットをするのって結構ハードルが高いんです。
だからこそ、みんなでミニPHPカンファレンスに挑戦するつもりで、一緒にチャレンジしてみませんか？

初めてでも大丈夫！
LTのプロ（自称）である私が、誰でも簡単にLTができるように徹底サポートします！このチャンスに、ぜひLTに挑戦してみましょう！
みなさんが今日、PHPカンファレンスに来たこと自体がすでに成長の一歩です！さらにもう一歩挑戦してみませんか？

■ 発表内容
「オブジェクト設計スタイルガイド」という書籍の良さについて熱弁します。

スタイルガイドという名前がついているものの、その実はOOPの設計のベストプラクティスを集めた設計・実装集です。
この本は頭から一つずつ書き方を見ていくだけで、自然と以下の重要概念が身につく優れた書籍なのです。

・サービス層とドメイン層の違い
・SOLID原則
・クリーンアーキテクチャ
・CQS（コマンドクエリ分離原則）
・エンティティ・バリューオブジェクト（もちろんミュータブル・イミュータブルの考え方も）
・ドメインイベント
・DI
・リファクタリング

OOPのベストプラクティスを学ぶことができる新時代の「リーダブルコード」と言っても過言ではないでしょう

チームでこの本の読書会を実施しているので、そこで出てきた「現場の意見・疑問」もお伝えします（発表時には終了予定）

このセッションでは、PHP ユーザ向けに OpenTelemetry を導入して、PHP アプリケーションを計装する手法について解説します。OpenTelemetry は、サービスやアプリケーションのテレメトリーデータ（トレース、メトリクス、ログなど）を収集、送信するためのオブザーバビリティフレームワークです。ベンダーニュートラルな OSS であり、PHP 版 SDK も提供されています。これを利用することで、PHP アプリケーションの動作を外部から観測することができます。手軽に利用できるので、オブザーバビリティツールの最初の一歩として触ってみるのも良いでしょう。

本セッションでは、OpenTelemetry SDK の導入、手動計装と自動計装、OTel Collector の活用によるテレメトリデータの送信、ローカル環境と本番環境でのセットアップなどについて、デモを交えて紹介します。

このセッションでは、PHP ユーザ向けに OpenTelemetry を導入して、PHP アプリケーションを計装する手法について解説します。OpenTelemetry は、サービスやアプリケーションのテレメトリーデータ（トレース、メトリクス、ログなど）を収集、送信するためのオブザーバビリティフレームワークです。ベンダーニュートラルな OSS であり、PHP 版 SDK も提供されています。これを利用することで、PHP アプリケーションの動作を外部から観測することができます。手軽に利用できるので、オブザーバビリティツールの最初の一歩として触ってみるのも良いでしょう。

本セッションでは、OpenTelemetry SDK の導入、手動計装と自動計装、OTel Collector の活用によるテレメトリデータの送信、ローカル環境と本番環境でのセットアップなどについて紹介します。

例外処理って「エラーをキャッチするもの」と思いがちですよね？
でも、実はもっと重要な役割があります。例外を使うことで「自分のコードがどこまで責任を持つべきか」を明確にし、処理を他に委任することができるんです。

このセッションでは、例外を活用してエラーハンドリングを整理し、過度なキャッチによるコードの複雑化を防ぐ方法をお伝えします。
さらに、フレームワークが担うべき役割や、ビジネスロジックを表現するカスタム例外の作り方も紹介します。

ぜひチームでのディスカッションに活用してみてください！

話すこと

• 例外の型の使い分け
• ビジネスロジックを表現するカスタム例外
• 例外をハンドリングする方法

パフォーマンス改善してますか？スロークエリ改善してますか？

Amazon RDSには便利な機能としてPerformance Insightsというスロークエリなどを分析して可視化してくれる機能があります。
しかし、この機能はt2およびt3, t4gのmicro, smallインスタンスでは利用することができませんし、RDSを利用していない場合には使用することができません。
この場合、スロークエリのログ出力設定を行いファイルに吐き出して、手動で解析すれば改善することはできますが、とても手間がかかってしまいます。
そこで便利なのが、MySQLの機能であるPerformance Schemaを使って簡単に可視化し改善していく方法を紹介したいと思います。
想定聴講者は、スロークエリ改善をしたいができていない方、なにから手をつければわからない方、お手軽にスロークエリ分析をしたい方におすすめです。

開発効率を向上させたいけど、大規模な自動化は難しそうと感じていませんか？
実は GitHub Actionsを使えば、小さなことから少しずつ気軽に自動化の仕組みを作ることができます！

このLTでは、自動化のアイデアの見つけ方から GitHub Actionsでの実装までをわかりやすく紹介します。
設定ファイルの管理やライブラリのアップデートの自動化など、私が実際に作成した身近な例を通じて、自動化の楽しさと手軽さを体感していただけます。

このLTを聞けば、明日から自動化への第一歩を踏み出す自信がつくはずです！

このLTを聞いて欲しい人

• 自動化に興味があるけれど、どこから始めれば良いかわからない人
• GitHub Actionsを使って効率的に作業を進めたい人
• 個人またはチームの開発プロセスをもっと楽しくしたい人

■ 発表内容
新しく組成された8人のチームが、新規機能の開発を「1ヶ月の期限で」と任された。

不確実性に対処しつつ円滑に開発を進めるために、
スクラム、XP、DevOps（リーンとDevOpsの科学）のプラクティスを取り入れて開発を進めた結果、時間が経つごとにチームは一致団結。

しかも、ビジネスチーム、セキュリティチーム、CSチームなど部署の垣根を超えた開発の実現に成功。
チームの誰もが「真のアジャイルチームになった」という手応えを感じていた。

何がうまくいったのか。3ヶ月に渡るチームの取り組みを総括します。

■ 発表の構成
・スクラム（スクラムイベントなど）、XPのプラクティス、DevOpsのケイパビリティの概観
・各プラクティスのチームへの導入と改善の様子をスプリントごとに提示
・チーム外の人と協働して効果的だったエピソード
・メトリクスを紹介して開発の成功度合いを定量的に説明

　PM Aさんこれから一緒にプロジェクト頑張ろうね
私は初めてプロジェクトに参画することになった
　PM じゃあ次Aさん進捗どうですか？
進捗を聞かれてもいつでも答えられるし、開発はスケジュール通り開発できている。何も問題はない。
　PM Aさんいつもオンスケで助かるよ。お陰でプロジェクトも順調だよ。次この機能開発してくれる？
プロジェクトのことはよくわからないけど、プロジェクトも順調らしい。
「あれ？でも、この機能って前にやった機能といっしょに開発したほうが早かったな。それに前カンファレンスで聞いた〇〇って技術使えばもっといい感じにできたかもな。」
「でもテックリードでもPMでもないし、機会が回ってきたときでいっか」
本当にそれでよかったのでしょうか？
本セッションでは、メンバー目線での情報がプロジェクトの成功にいかに重要であり、メンバーだからこそ貢献できるテクニックを話します。