トーク

ご自身の「真ん中」にあるものって、なんですか？

PHPカンファレンス名古屋の中心に据えられている価値観を見て、ふと考えました。
https://phpcon.nagoya/2025/#about

自分は5年前から個人事業を始めたのですが、「真ん中」にあったのは、とある事業会社でのPHPプロダクト運用を回してきた、という経験だけでした。
でも、それを頼りに、新規プロダクト開発に業務委託で参画し、そこから自動テストや自動デプロイの導入や IaC化、さらに複業で幅を少しずつ広げ、「じぶん領域」はフルサイクルと言って良いかなと思えるくらいのなかなかの大きさになっていると思います。

このトークでは、類い稀な広がり方をした「じぶん領域」に関して、参考にしてほしい面と反面教師にしてほしい面をご紹介します。

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

• DB処理が大量に詰め込まれたサービス
• トランザクションスクリプトがひしめくサービス
• どこからでも誰からも呼ばれるサービス
• 複数のサービスと手を組み、仲良く連携するサービス
• ドメイン層を支えるサービス
• 周りに合わせてとりあえず作られたサービス

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

当LTでは、こうした多様なサービス層にわたしの独断と偏見で名前をつけ、メリット・デメリットをかたっぱしから語ります。

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

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

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

WEBアプリケーションを安定的に運用する上で、考慮しなければいけない事が多くあります。
私たちのチームは、PHPアプリケーションをAWSクラウドインフラで運用しており、コスト削減とセキュリティ向上という課題に直面していました。

本セッションでは、これらの課題解決に向けての取り組みを、主に下記の内容についてお話します。
・コスト最適化のために検討したサービスや設定の変更点
・セキュリティを強化するための機能や具体的な設定方法

本セッションを通じて、明日から実践できる費用対効果の高い運用改善方法を見つけることができます。
普段クラウドインフラに関わる機会が少ない方でも運用への興味と関心が高まる機会になれば幸いです。

数学でよくわからない記号や公式で苦手意識はないでしょうか。
プログラミングにおいても計算量オーダーと呼ばれるO(n^2)やO(log n)といった表記が出てくることがあります。
パッと見で拒絶反応は出てやしませんか？
実際にコードでこれらの表記が何を意味しているか理解し、パフォーマンスの良いコードを書けるようになりましょう

お話すること
・時間計算量
・空間計算量
・良くないコードの実例
・改善案

対象者
・オーダー記法を理解したい方
・パフォーマンスへの意識を高めたい方

皆さん、どんなアーキテクチャで開発していますか？
私が最近参画した現場にはモジュラモノリスが導入されてから1年超開発が続けられているプロダクトがありました。
チームはモジュラモノリスならではの恩恵を受ける一方で、設計上の難しさや課題にも直面してきました。このトークでは、モジュラモノリスを体感してきたエンジニアたちから見た設計上の留意事項や課題ないし今後の展望を共有したいと思います。

※PHP製ではありませんが言語に依存する話は無いか少ない想定です。

皆さん、オンボーディングを実施してますか？
エンジニアの転職が盛んになってきた昨今、実施側ないし受ける側としてオンボーディングの経験を持つ人も多いのではないでしょうか。
実施側目線では、入社直前に準備でバタバタする、何度も同じ説明を繰り返したことがある、担当者の負担感が大きいなんて感じたことはありませんか？
受ける側目線では、インプットが多くメモが大変、取りこぼす、オンボーディングを消化して成果を出すまでに時間がかかり焦るなんてことがありませんか？
このトークでは、これまでにオンボーディングを受ける側、実施する側で助かったこと、ドキュメントの作り方や見聞きしてきたコツを思い出し、共有します。
新規参画者の早期戦力化のヒントになれば、あるいは、オンボーディングで助けられたハッピーな気持ち、あの時の初心を思い出し、カンファレンス明けのお仕事を”やっていき”な気持ちで迎えられたら幸いです！

皆さん、スプリントレビューを実施してますか？

• 興味があるんだけれどやり方がわからない。
• 周囲の共感が得られない（説得材料が欲しい）。
• やってるっぽいんだけど実はよくわかってない。
• やってるんだけど何か違う気がする、もっとうまくやりたい。
  など、悩みやモヤモヤがもしあれば是非話をさせて下さい！

私が所属するスタートアップでは週一でスクラムチームとステークホルダがレビューに参加するという運用を5年以上続けてきました。スクラムガイド、自社事例、他社公開情報を参照しつつ、スプリントレビューのやり方、コツ、現場が感じている価値をまとめてお届けします。
プロダクトの改善、アジャイル開発に興味がある方の参考になれば幸いです。

システムに何かあったとき、どのような通知手段をとっていますか？
私が現在関わっているシステムでは、slack通知するよう設定をしています。警告時、異常検知時、それぞれにあった通知を設計したつもりでした。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになってしまったり、実は通知が届いていたのに誰も対応できなかった、なんて事が発生してしまいました。
そんな状況を少しずつ改善していったアレコレをお伝えできればと思います。

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

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

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

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

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

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

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

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

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

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

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

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

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

登壇者はここ2年ほど、複数のプロダクトから利用されるレセプト業務を X as a Service（XaaS） として開発しています。
本セッションでは、次の点にフォーカスしてお話しします。

1. なぜXaaS化を目指したのか
   狙いと実際にどうだったのか？
2. XaaS開発における重要なポイント
   • コアドメインの見極めと責務の明確化
   • ユーザーとのコミュニケーション設計と開発プロセス
3. 継続的な開発を通じて得られた知見
   • 安定した開発を行うための勘所
   • コアドメインと向き合う方法、そのメリットと課題

本セッションを通して、XaaSの開発における具体的な戦略と経験を共有し、コアドメインと真摯に向き合うことの重要性をお伝えします。

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

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

このトークでは

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

といった切り口に対して

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

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

PHPアプリケーションの課題解決のために使われる有用なツールとしてXdebugなどのデバッガ、ベンダの提供するAPMツールなどがあります。

一方でこれらのツールでもカバーされない領域としてPHPのC拡張や実行エンジン内部のイベント情報などがあります。

eBPFを利用してこれらのイベントにフックすることにより、課題解決に役立つより詳細な情報をピンポイントで得ることができます。

本セッションでは、eBPFツール（ebpf_exporterなど）とPrometheusスタック（Prometheus/Grafana）を組み合わせ、PHPのアプリケーションコードを変更することなく、低コストで、継続的なモニタリングツールを作成する方法をお話します。

得られること

• eBPFの概要とPHPにおける適用可能領域、始め方を知る
• コードとデモを通して現実の問題に対する活用のイメージを得る

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

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

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

Laravel でのドメインバリデーションをどこに書くか迷いますよね。

Controller に直接書くか、Model に public メソッドを生やすかのどちらかが一般的ですが、Model のライフサイクルイベントに対するフックで行うという方法もあります。

本LTでは、実際に行った実装を例にフックを使ったドメインバリデーションを紹介します。

OpenAPI仕様は、RESTful APIのドキュメント化において事実上の標準として広く採用されています。
しかし、そのエコシステムの豊富さゆえに、ツールやエディタの選択、コードファーストかドキュメントファーストか、自動生成アプローチの選定など、多くの判断を迫られます。

これらの課題の本質は「APIドキュメントとコードの同期維持」にあります。ドキュメントの陳腐化を防ぎ、開発効率とチーム全体での一貫性を確保することが重要です。

本セッションでは、新しいアプローチとしてライブラリ「eg-r2」を紹介します。
eg-r2は、コードとドキュメントの緊密な統合、効率的な更新メカニズム、開発ワークフローへのシームレスな統合を実現します。
参加者は、最新のベストプラクティスと実践的な指針を得られ、即座に活用可能なテクニックを学ぶことができます。

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

本トークで話す内容

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

データベースエラーに困ったことはありませんか？本トークでは、よくあるデータベースエラーを例にとり、そのエラーを再現するコードを使いながら、原因と防止策をわかりやすく解説します。エラーの発生を深く理解し、データベースと仲良くなって、今後のトラブルを未然に防ぎましょう。

本トークで話す内容

• よくあるデータベースエラーの紹介
• エラーを再現するコード例と解説
• エラーが示す原因と、その意味
• エラーを防ぐためのコーディングのポイント