昨今、開発の中にコードレビューのフローが存在するチームは多いのではないでしょうか。
そして、そういったチームへのジョインや会社への入社したエンジニアは、いつかコードレビュー1日目を迎えることでしょう。

特に、自分自身のスキルに自信がない方は、
・ 他の先輩方のコードレビューをするのは気が引けるな・・・
・ 自分はスキル的にまだまだだから、コードレビューなんてまだできないよ・・・
・ いざレビューしてみてるものの、なんてコメントしたらいいかわからないな。。
・ 自分はLGTM( = Look Good To Meの略。自分的にはOKという意) と思ってLGTMにしたけど、他の人がめっちゃコメントしてる・・・

のようなネガティブな考えに囚われてしまい、気付けばLGTMしかコメントしなくなっていたり、誰かがLGTMとコメントした後に自分もコメント残しておこうみたいなマインドにもなってしまいます。（新卒時代の僕がまさにその状況でした。）

本セッションでは、自分自身が思考錯誤して見つけた「自信を持って最初の1歩を踏み出す方法」を紹介します。

・ これならできそう
・ そんなに難しく考えなくていいんだ
と思っていただけると嬉しいです。

新たにチームにジョインする方が新しい環境にも臆さずコードレビューできるようになったり、
チームに招き入れる側の方が、新人に対して安心させてあげられる状況作りの1つになると幸いです。
新卒1年目の僕のような状況に陥ってしまう方が1人でも少なくなりますように。

対象者：コードレビューの体制のあるチームの全エンジニア（役職問わず）、これから新卒として入社を控えるエンジニア志望の学生の皆様

昨年のカンファレンスで「CodeReviewerが求められること」について発表させていただきました。
その中で、Revieweeが
・気づきや学びが欲しい
・自信を持ちたい
と感じていることが明らかになりました。
またその時の発表では触れませんでしたが、Revieweeは「楽しく働きたい」とも考えていることがわかりました。

しかし、コードレビューにおいて、Reviewerが気づきや学びにつながるようなコメントをしたとしても、伝え方次第でRevieweeから楽しさや自信を奪うことがあります。
逆に言えば、伝え方次第ではRevieweeが自信を持たせたりコードレビュー依頼を活性化させることもできるようになります。
本セッションでは、Revieweeのやる気を促進させつつ、レビューも行っていく方法を紹介し、PHPerエンジニアへのヒアリングも交えながら、心地よいコメントの条件を考察します。
コードレビューの場が楽しくなり、組織が活発になる一助となれば幸いです。

対象者：コードレビューを行う全エンジニア（役職問わず）

設計に詳しくなりたいし、設計力が欲しいし、色々な場面で良い感じな設計を描けるようになりたいですよね。
ソフトウェアづくりに設計は必要です。
何をもって「良い設計ができた」と言いますか？何を目指していますか？
本トークは、その自信と根拠を持つための、「なぜ設計を行うのだっけ」を考えるきっかけとなることを目指します。

考えるべきこと

このトークにおける「設計」に対する態度

• 設計は、何かしらの品質を支えるためにある。その意思決定が具体化されたものと捉える
• 品質には「いま必要なものを、必要なレベルで実現できている」「必要な期間中、継続的に、要求に応え続けられている」の両軸が必要
  • 「将来的にも拡張・変更しやすい」だけでは満足されず、「今の環境や要員でついて行ける」ことも重要
• 自信が持てるような設計にするには、「身の丈にあう」のガイドラインとしての機能を果たす必要がある
  • 「ぼくのかんがえたさいきょうのデザイン」にしない

「良い設計」のために必要なこと

• 設計の「ねらい」をトレードオフとして表現して伝える
  • カーゴカルトよりテイラーメイドを重んじる
  • 何が本質かは自ら選び取り、思考をdumpする
• その設計を「支える」のはメンバーたち
  • 本来のねらいが、実現され続けてこそ意味がある
  • 技量面への教育やツールによる支援が必要

このトークで得られるもの

• ねらい: 「良い設計」を議論するための観点を提供する
• 得られるもの: チームで「自分たちに必要な設計」を見つめ直すきっかけ

話さないこと

• 具体的な設計技法やパターン
• 各論的な品質特性やその計測方法

想定オーディエンス

• 「設計ってなんだろう？」に興味を持ち始めたジュニア
• 駆け出しテックリード

PHPではtry-catchを使った例外処理が一般的ですが、「この例外はどのレイヤーで処理すればいいのか？」や「どの場面で例外を使うべきなのかが曖昧だ…」と感じたことはありませんか？
例外の種類や扱い方が曖昧だと、設計の混乱やコードの保守性低下を招きます。この課題に対するヒントとして、Rustなどの言語で採用されているResult型の考え方があります。

Result型は、失敗が起こり得るということを型として扱い、例外に頼らずエラーを管理する手法です。これにより、エラーの種類や処理責任が明確になり、設計の一貫性を保ちながら保守性を高めることができます。このセッションでは、Result型をPHPに応用する方法を実装例を交えて解説します。

取り上げる内容：

• 例外の種類や扱い方が曖昧になる原因とその解消方法
• Result型の基本的な考え方とPHPでの実装方法
• try-catch採用プロジェクトでも活かせる学び

例外の扱いをもっと明確にし、エラー処理を改善するヒントをお持ち帰りください！

話者は普段PHPをBrefというOSSを利用してAWSにデプロイしています
この方法は非常に有用で、サーバーレス環境にPHPアプリケーションを載せるための標準手法として紹介してきましたが
一方で第三者が構築しているOSSに対する不安を感じる方もいるはずです

既存コードをどのようにサーバーレス化すれば良いのか、またカスタムな環境構築がどこまで信頼できるのかといった懸念があるかもしれません
特に既にLaravelやSymphonyなどのフレームワークを用いて開発されたアプリケーションを、
既存のワークフローを大きく変えずにクラウドネイティブな環境へと移行したい場合、そうした課題はより顕在化します

そこで今回はAWSが構築を行っているAWS Lambda Web Adapterを利用します
PHPerはサーバーレスの利点を享受しつつ、従来のWebアプリケーションをシームレスに移行する手法を身につける事が出来ます
さらにLaravelに適用する際には、既存のルーティングやミドルウェア、コントローラ群をそのまま活用し、AWS Lambda上でリクエスト-レスポンスサイクルを再現することが可能です
最終的に話者がいつも利用しているBrefとの比較を行うとで、選択肢を提示します

AWS Lambdaの可能性を広げるWeb Adapterを利用したサーバーレスPHPの普及に助力出来れば幸いです

• お話すること

  • AWS Lambda Web Adapterについて
  • Brefについて（簡易版）

• 想定聴講者

  • サーバーレスPHPに興味がある方
  • AWSを利用してPHPを利用している方

• お話しないこと

  • Laravelのデプロイ手順（GitHubにコードを公開します）

PHPユーザーであれば、日々APIのパフォーマンスと向き合うことがあるかと思います。
中でもGolden Signalと呼ばれる4つの指標（レイテンシー、トラフィック、エラー、サチュレーション）は、システムが「健全」であると判断する基準となるものです。
本セッションではGolden Signalを中心に、Performance Insightや周辺のメトリクス、モニタリングツールの操作、問題の特定や推論を可能にする為のTipsについて話します。

• Golden Signalについて
• 価値のあるログとは何か、どこにあるのか
• Performance Issueをどう特定するか
• ケーススタディ、 ex: このアプリケーションは20時台にCPU Usageが跳ね上がるのってなぜ？
• ログとメトリクスからユーザー特性を推論する、問題発生箇所のコードを探す技術

何かを作ることって楽しいですよね。プログラミングを始めたキッカケは、それぞれ違うでしょうけれど、「動くもの」ができたときに得る快感は、およそ共感できるでしょう。
ところで、日々のお仕事に忙殺されて、その得られる快感が薄くなっていませんか？業務ではさまざまな制約があることでしょう。

そんなあなたに、自由な開発をする後押しをしたい。そして自由を糧にしてあなたのWayを作って欲しいのです。

想定ターゲット

• お仕事でしか開発をしない人
• 日々のお仕事に忙殺されてる人
• 個人開発ってなんだろう、どうすればいいんだろう、という人

話さないこと

技術的な詳細には触れませんが、トーク後に質問をいただければ大歓迎です！嬉！

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

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

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

• モックを使ったメソッド呼び出しの検証方法
• 高度な引数の比較を使った柔軟なテスト
• 実務でのテストケースの実例紹介

Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

「アジャイルなんてオシャレな自社開発企業だけの特権でしょ？」

そう思っていた時期が自分にもありました。

その後、自組織へのアジャイル導入を主導し、実践を重ねた今となっては、アジャイルはチーム単位や、ひとりからでも始められる！と確信しています。

このセッションでは、アジャイルの魅力、そして「はじめの一歩の踏み出し方」についてお話しします。

こんな人に聞いて欲しい

• アジャイルのことは知っているけど、まだ実践できていない人
• 受託開発だからアジャイルは無理、とあきらめてしまっている人

お話しないこと

スクラムや XP などについての細かいお話はしません。

現在担当しているプロダクト（建設DX領域のバーティカルSaaS）で多言語対応プロジェクトに参画した際の学びを共有したいと思います。

背景

プロダクトは10年以上運用しているものでリポジトリのファイル数は3千を超えます。
図面を見たり写真を撮ったりという標準的な機能のほか、外部機器と連携して検査をするというオプショナルな機能をあわせると30以上機能があります。
標準的な機能は多言語対応が完了していましたが、オプショナルな機能をこれから多言語対応していくというタイミングでした。

本トークで話すこと

• サービスを多言語対応をするうえでそもそも起こりうる、日本語と英語で文字数や記号による違いなど、表現について。
• 長く運用しているプロダクトの複雑な仕様を理解しながら進める多言語対応。
• 考慮不足によって発生したバグからの学び。

発表者について

プログラミング歴約2年半で転職して入社した会社での話し。
入社から数カ月後に参画したプロジェクトが多言語対応でした。

対象者

これから多言語対応をする予定の方、今多言語対応している方。
多言語対応で起きる問題に興味がある方。

皆さんはゲーム大好きですか？
わたしもネットがあまり普及されてない頃、攻略本を片手にずっとゲームをやってました。

実はPHPにも攻略本があります。ナ、ナンダッテー！？
全て印刷したら六法全書になるであろうボリューム。その名はPHPマニュアル！
本当にコントリビューターの方々には頭が上がりません。いつもありがとうございます。

もちろん、、、PHPerと名乗るからにはPHPマニュアルマラソンをやったことありますよね？
え？やってない？
それなら、一緒に習慣化するしかない！

この発表を経て、PHPの素晴らしさを再認識しましょう！

テストコード実装によるアプリケーションの実装設計や中長期の運用メンテナンス性に変化が出た話をします。
当初、ファットコントローラーや行数の多いメソッド、ライブラリへの依存性高い設計などが原因で、メンテナンスしにくいPHPアプリケーションを運用していたチームがテストコードの実装から技術負債を徐々に解消していけるようになりました。
理由は「テストコードを入れやすい実装と設計」をするようになったこと。
挙げた課題へどのような実装・設計の変化が起きたかリファクタリングの具体例や、テストコード導入によるコード設計の変化を紹介します。
またテストコードによるリプレイスを叶えたアプリケーションを立ち上げた事でPHPやフレームワークバージョンアップへの適用性、テストコード実装スピード向上やコードレビュー時のコミュニケーションの変化についても語ります。

新卒から6年間所属した部署から大異動で全く別のチームに配属された先には鳴り響くアラートの日々が待っていました。
みなさんも、プロダクトの監視の状況で以下のようなケースに出会ったことはないでしょうか？

• 何をしたらいいのか、何が問題なのかわからないアラート
• 既存チームメンバーから無視され続けているアラート
• アラートが来ても反応するメンバーが限られている、対応できるメンバーが限定的
• アラートが頻繁に来ていてチームがアラート対応に疲弊している

上記のアラートについて見ていくと異動先のチームには、以下のような問題を抱えていました。

• アラートの詳細を詳しく見なければ問題がないことを判断できない
• アラートの判断は属人化している
• ほとんどのケースにおいて問題ないアラートが飛び続けている
• 最初に監視を設定した人はすでに社内におらず、意図がわからない
• メンバー間のアラートに対する認識齟齬

これらに対して、一つ一つ向き合って出してきた答えについてお話します。
聞いて欲しい方

• 新たに配属されたが、アラート対応ができなくて悔しいと思ってる人
• アラート対応に課題感を持っている人
• 一緒に見直していく仲間を増やしていきたい人

皆さんは、Laravelでの定期実行をどう実現していますか？？

我々のチームでは、サービスをECSにてデプロイしていることもあり、Laravelのタスクスケジュール機能を使わない選択をしました。

しかし、ECSのLaravelサービスに対して定期実行する方法には、以下のようなものがあります。
・ECSのスケジュールされたタスク
・Amazon EventBridge SchedulerからのECSタスクの実行
・Amazon EventBridge SchedulerとLambdaを使用したAPI呼び出し
この中から「早くて安くて安心な」手段を選ばねばなりません。
そこで、AWSのコストを抑えつつ、必要な要件を満たし、運用が簡単な方法を見つけるべく我々はアマゾン（AWS）の奥地へと向かいました。

そして冒険の果てに見つけた、最適な定期実行の方法をお話します。

仕事の内容をドキュメント化することで得られるメリットはたくさんあります。

• 多数の人に内容を共有できる
• 言った言わなかったの議論にならない
• 後から見返して経緯がわかる

しかし、実際にドキュメントに起こそうとすると面倒に感じ、なかなか実行に移せていない人も多いのではないでしょうか？
また、チームメンバがなかなか仕事内容をドキュメントに起こしてくれず、困っているマネージャーもいることでしょう。

たしかに、物事をドキュメントに起こすことは面倒です。
しかし、逆にドキュメントへ起こさないことによってどのような問題が発生するかを知ることができればドキュメントに起こす気になるのではないでしょうか？

この発表では、仕事内容をドキュメントに起こさないことで発生するデメリットの具体例を示し、なぜドキュメント化をする必要があるのかをドキュメント化を避けるメンバ向けに説きます。

開始前から炎上を宣言されているプロジェクトに参画したことはありますか？

私は昨年、そんな「炎上必須」と言われたプロジェクトに参画し、プロジェクトのマネジメントを行い、無事に完了させることができました。
本トークでは、このプロジェクトにおいて、炎上を抑え込むためにチームで行なった施策とその効果を紹介します。

自社プロダクトを開発している場合、大抵はリリース日程をずらすことで、大炎上を避けることができるでしょう。しかし、稀に何らかの理由で納期必須の開発が行われることがあります。
私たちのチームは、外部システムとの連携が必要なプロジェクトを短納期で開発することになりました。
プロジェクト開始当初のスケジュールでもすでに期限通りの開発は厳しく、また複数の組織が関係することによる仕様決定の遅れが予想され、会社内でも誰もが炎上を覚悟していました。

そんな中、開発チームは様々な工夫をすることで無事高品質な状態でスケジュール通りに開発を終えることができました。
仕様策定、開発手法、チーム構成などをどのように工夫し、どんなカードを切り、工数を抑え、稼働を確保し、プロジェクトを推進したか... 聞いた人が自分のプロジェクトでも活かせるようにそのTipsを解説します。

開発生産性はソフトウェアの品質と市場投入へのスピードに直結します。本トークでは、PHPをメイン言語で扱うチームとして、又は1人のPHPerとしてプロダクトの開発生産性向上へ行ったことを紹介します。

• チームで開発生産性に向き合う文化醸成や改善への行動。
  ┗どのようにPRを分割するか・設計時に考慮すべきポイント・チームの士気向上などの変化について
• 中長期的な開発生産性向上への行動。
  ┗テストコード設置やPHP・フレームワークバージョンアップ運用とアプリケーション基盤作りについて
• リリースサイクルを上げるための取り組み。
  ┗PHPプロダクトでのFeature Flag導入や運用フローの変化について

個人・チーム開発で生産性向上を目指していける具体的な手法や経験談の話をします。

backward compatibility、訳すると「後方互換性」です。タイトルをかっこ良くしたかったので英語にしています。
本発表は、リリースエンリニアリングの観点から、後方互換性というテーマに絞った内容になります。
サーバ運用やSchema管理、テスト環境におけるデータの差異がもたらすリスク、Mobile Appのバージョン管理まで、リリース時に頭を抱えない為のTipsと実例について解説します。

・リリースエンジニアリングと「後方互換性」
・テストが担保する後方互換性と、担保しない後方互換性
・サーバ運用時の後方互換性と、リリース順序、ロールバック
・GraphQL schemaの後方互換性と、Schema変更時のルール
・Mobile appの後方互換性と、強制アップデートのユーザー影響

概要

我々PHP界隈は最近、高年齢化が危惧されています。
「若手が居ない、育たない」と嘆いているそこのあなた！！具体的に対策できてますか？
その原因は主に以下の2つと考えます（偏見）

• 凝り固まったシニア層がやり方を変えないため新しい風が起きにくい
  • 新しい技術の導入が最近少なくないですか？
• 若手が参入しようにも入る余地がなさそうに見える
  • 若手が活躍する場が限られていませんか？

この問題を解決するために最適なソリューションが読書会です。
他の言語でもフレームワークでもフロントエンドの技術でも。
何でも良いので、普段自分がいない集団の読書会に参加してみましょう。
今まで知らなかった新しい考えや全然違った常識にきっと打ちのめされるはずです。
でもそれで良いんです。知らないことを知るっていうことはそういうことです。
シニアエンジニアもまだまだ知識とチャンスを得る機会があるんです。

我々シニアのエンジニアがもっとネットワークを広げ、かつ若手を取り込むための第一歩。
その読書会がいかに良いソリューションであるかをお話します。

対象の人

• ベテランのエンジニア
• PHP以外の界隈と普段交流を持たない人
• 若手にもっと来て欲しい人

得られるもの

• 若手を増やすことの要素で何を大事にしないといけないか
• 凝り固まった価値観に意外と支配されているという気付き
• 自分が普段属していないコミュニティの人たちと触れ合うことによって得られる視点や知識

私が担当しているメール共有サービスのメールディーラーではE2Eテストを導入することで、一定以上の品質を担保することに成功しました。

E2Eテストを導入したことの効果やテストコードの実装やテストケースの作成で工夫しているポイントなど、
メールディーラーのテクニカルリーダである私が可能な限り具体的に事例をもって説明いたします。

メールディーラーは2001年にローンチしましたが、フレームワークを導入しておらず、
DBアクセスとHTMLの生成をひとつのプログラムで行っています。

内部構造のアーキテクチャもさることながら、プログラム構造の陳腐化がリリースを行うごとに進みました。
いわゆる「スパゲッティコード」が散在し、それらがサービスの品質にまで影響するようになりました。

具体的には、ある共通関数が別の共通関数を呼び出し、
それが繰り返されることでプログラムが複雑にネスト化しています。

その結果、コード全体の把握が難しくなり、修正前に十分な影響調査ができない状況が生まれました。
このような状況下で、思ってもみない機能に不具合が混入し、
新機能のリリース直後に改修していないはずの機能で「画面が表示できなくなる」といった致命的な障害が発生しました。

そこで対策としてE2Eテストの導入と自動化を行いました。

通常の開発と並行して約3ヶ月という期間で273画面に対してテストコードを実装し、
導入後は「画面が表示できなくなる」といった致命的な不具合の発生を防止することができました。

限られた期間とリソースでどのようにして、当初の目標通りの成果を出すことができたか？をご説明いたします。
本セッションを通じてE2Eテストの導入や品質担保の参考になれば幸いです。