トーク

このセッションでは、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でもないし、機会が回ってきたときでいっか」
本当にそれでよかったのでしょうか？
本セッションでは、メンバー目線での情報がプロジェクトの成功にいかに重要であり、メンバーだからこそ貢献できるテクニックを話します。

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

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

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

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

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

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

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

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

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

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

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

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

私はコンピュータサイエンスの学位も海外留学の経験もない普通のエンジニアです。
そんな私が今年6月にLaravelのコアチームに加わり、グローバルなチームのなかで尊敬するメンバーたちと共に日々開発に携わっています。
このセッションでは、私が2014年にLaravelに出会ってからコアチームに加わるまでの経緯や、グローバルなLaravelコミュニティでどのような活動をしてきたか、そしてコアチームに加わってからの活動についてお話しします。
特別な経歴がなくても、行動することで可能性が大きく広がるということを、私の経験を通じてお伝えできればと思います。

このトークでは、OPcodeを読み進めていたはずが、気づけばPHPのソースコードを読み込むことになった体験を共有します。

当初はパフォーマンスや最適化を目的にOPcodeを読んでいましたが、調べるうちに言語の内部構造にまで興味が広がっていきました。
そのプロセスを具体例とともに振り返りながら、技術的な知識に加え、その過程で得た学びや気づきについてお話しします。

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

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

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

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

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

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

ソフトウェア開発において、顧客理解や問題発見は、しばしばPOやデザイナーの役割とされます。しかし、私たちのチームは「解くべき課題について誰も具体的なイメージがない」という状況に直面し、チーム全員で顧客への理解を深めることを選択しました。

本セッションでは、PO1名とエンジニア2名で構成された新チームが、全員でペルソナを考え、ユーザーインタビューを実施し、プロトタイプを作成・検証するプロセスを共有します。そして、この取り組みを通じて、素早いアウトプットの重要性を再認識できた経緯について、エンジニア目線でお伝えします。

主な内容：

• チーム全員で顧客理解を深めるための具体的な進め方
• エンジニアが顧客理解を深めることの意義と効果
• 素早いアウトプットを出すために私たちができること

本セッションを通じて、エンジニアが顧客理解を深めることの意義について考えるきっかけになると嬉しいです。

【概要】
認証処理は一度実装されると変更が少なく、日常的に触れる機会が少ない分野です。
普段当たり前の様に使われている機能ですが、システムに必須かつ複数のサービスから使われるケースも多いため、システム全体の要と言っても過言ではありません。
そのため普段認証システムを触らない人でも、最低限の仕組みやフローを理解しておくことは重要です。

そこで、認証システムを触ったことがない人に向けて、事前に知っておくと便利なポイントをまとめました！
認証はハードルが高い分野ですが、トークをきっかけに認証システムに興味を持ち、日々の業務やトラブル対応に活用していただければ幸いです。

【話すこと】
・システム固有の知識+認証固有の知識を知ろう
・ユーザーの種類は？SNSログインは使うの？認証システムの仕様そのものを知ろう
・ウチの認証システム、どの認証フローを使っているの？
・認証についてもっと知りたい！

【概要】
ドキュメントを作ってチームに情報共有したぞ！これで属人化解消！と思ったら未だに自分宛に問い合わせが来る???こんなはずじゃなかったのに...皆さん、このような経験はありませんか？
せっかくドキュメントを用意しても、チームに読んでもらえない・理解してもらえないのでは作った意味がありません。
本トークでは、日常的な個人メモの取り方やそれをドキュメントに成長させる方法、さらにドキュメントを通じて業務の属人化を解消する方法をお伝えします！

【対象者】
・業務の属人化を解消したい人
・個人メモ・ドキュメントの作成が苦手な人

【目的】
・個人メモ・ドキュメント作成のポイントが分かる
・ドキュメントを通じた属人化解消

【話すこと】
・まずは個人メモから！記録のコツ
・個人メモとドキュメントはどこが違うの？
・ドキュメントを成長させるために必要なこと
・属人化解消のメリット

ご存知の通り、レビューとは「講評」「批評」という意味です。
そのためコーディングにおけるレビューも、どうしてもレビュワーから実装者への一方通行コミュニケーションになりがちな側面を持っています。

しかしレビューとは、実装者とレビュワーが解釈をすり合わせる場であり、
双方向のコミュニケーションをしてこそ、漏れなく効率的なすり合わせができると私は思っています。
今回は私がPRレビューを双方向コミュニケーションの場にするためにしていることを、3つお話しします。

• 些細な違和感を逃さない[Q]と[MEMO]
• レビュー修正者を迷わせない効率的レビュー
• チームメンバーの癖を把握した、メンバー特化型レビュー

テストを書くことにもだいぶ慣れてきましたが、いまだに嫌で仕方ないものがあります。それがデータプロバイダです。

データプロバイダを書くのは面倒くさい。本当に本当に面倒くさい。
というのもリリース恐怖症の私は、テスト対象のありとあらゆる条件やパスを通したくなります。
「いや〜書かなくても大丈夫だろうけど、怖いし一応書いとくか…」を繰り返すうちに、どんどんテストパターンが増え、データプロバイダが膨大になります。

ここでは、私をそんな無限コピペ地獄から救ってくれた「差分だけデータプロバイダ」をご紹介します。
同地獄に陥っている方の一助となれば幸いです。

⁠対象者

• いつもデータプロバイダが太りがちな方
• ツールなど使わず手動で、大量のパターンをテストしなければいけない方
• データプロバイダを書くのが億劫で仕方ない方