トーク

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

• 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 の活用によるテレメトリデータの送信、ローカル環境と本番環境でのセットアップなどについて、デモを交えて紹介します。

開発効率を向上させたいけど、大規模な自動化は難しそうと感じていませんか？
実は 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でもないし、機会が回ってきたときでいっか」
本当にそれでよかったのでしょうか？
本セッションでは、メンバー目線での情報がプロジェクトの成功にいかに重要であり、メンバーだからこそ貢献できるテクニックを話します。

現代において、エンジニアの仕事は常にチームで行われます。
チームで仕事を進める以上、他人との「意思疎通のスピード」が、チーム力に直結してしまいます。

チーム力を上げるために、組織ではさまざまな施策が実施されているかと思いますが、エンジニア個人でできる意思疎通のテクニックについて考えたことはないでしょうか？
チームで行われているコミュニケーション施策に乗るだけでなく、自らコミュニケーションを円滑に進められるよう能動的に動くことで、チームの力をもっと上げることができます。

本発表では私が仕事で実践している内容をもとに、明日から使えるチーム力向上を目指したコミュニケーションのテクニックと考え方をお伝えします。
これを聞けば、明日チームメイトから「ちょっと変わったね」と言われること間違いなし！

我々はのチームはつい最近結成されたら新チームです。チームも未熟でありながら何を作るかも決まっていませんでした。
そんなチームが顧客の要望に応えたい気持ちはあるものの人手も多いわけではないのでできることは限られます。

しかしこのチームが爆速にプロダクト開発をしています。
どんどん動くものができており、スプリントを進めるたびに機能は増えていき、スプリントレビューで改善のフィードバックをもらっています。

どのように開発を進めているのか、意識していること、テクニック、秘訣を教えます！

新しいチームやプロジェクトに参加した際には、まずシステム全体を大まかに理解することが重要です。これはすべてのコードを理解するわけではなく、システム全体の構造やその役割を把握することです。全体像を理解することで、自分の担当機能がどのようにシステム全体に影響を与えるかを見通せるようになり、自信を持って開発に取り組むことができます。この知識は、バージョンアップ対応やパフォーマンス改善、アーキテクチャ変更など、システム全体に影響するタスクで特に重要です。

本セッションでは、初見の PHP アプリケーションの全体像を掴む方法を紹介します。

このセッションでは、以下の内容を含む予定です。

• ビジネスにおけるアプリケーションの立ち位置
• PHP、拡張、パッケージの把握
• Xdebug デバッガでの追跡
• アプリケーション IO を見る

スクラム開発されている皆さん
ストーリーポイントによる見積は相対見積で、時間見積ではないとされています。
とは言っても様々な種類のタスクがある中で同じ基準で比較はなかなか難しいなと思います。

自分たちのチームは便宜上時間見積に近い形を取っており、
今回は実際にどのように進めているのか簡単に紹介してみようと思います。

Laravel 11アップグレードに伴うCarbon2から3での変更について、実際のプロジェクトで発生した修正点を例を交えながら紹介します。

話すこと
・Laravelだけでなく各ライブラリのガイドを確認することの重要性
・Carbon3での変更により実プロジェクトで起きた修正例
・Github Codespacesによる開発環境構築が作業の助けになったこと

このコード、この機能、今も使われているの？
ある機能を削除したいけど影響範囲が分からないので怖くて手を出せない...

システムの機能削除は影響範囲が広く、ハードルが高いものです。
しかし避けているとシステムに不要なコードやファイルが残り続け、実装の妨げになりシステムの保守性が下がります。

そこで、本トークではシステムから不要機能を削除するためのポイントをご紹介します。
不要機能との向き合い方はシステムに左右されますが、皆さんにとってベストプラクティスを見つけるきっかけになれば嬉しいです！

【話すこと】
・不要機能がシステムに残るデメリット
・不要機能ってどこまで削除するの？削除の範囲を決めよう
・機能削除でエンジニア完結の判断は禁物、ビジネスサイドと連携しよう
・不要コードを生み出さないためにできること