コミュニケーションにおける「パス」について、「コミュニケーションパス」がまず頭に浮かぶと思います。

いわゆる、1対1のコミュニケーションがどれだけ発生するか？というコミュニケーションパスとともに、チーム間を跨ぐ場合に誰を経由してコミュニケーションするか？という経路としてのパスもあります。

個人的に、直接のコミュニケーションにおけるやりとりも「パス」(pass)することだと考えていて、相手にいいパスを出せるか？というのもチームコミュニケーションにとって大切な要素ではないでしょうか。

本トークでは、1対1のコミュニケーションにおける対話（パス交換）に着目して、私が大切にしていることを共有したいと考えています。

アプリケーションのパフォーマンス改善を行う場合、適当に手を動かしてもうまくいかないことが多いと思います。

少しでもよいカイゼンを行うためには「事実」を把握するために「計測」するというアクションが大事です。

ツールを使ってコードのメトリクスの取得するのも1例です。
コードのサイズ、重複コードの有無、コーディング規約の遵守状況、循環的複雑度、エラーの有無などコードに対する「事実」を把握することができます。

把握できた色々な「事実」を元に、どこがアプリケーションの改善点なのか…？何がアプリケーションにとって最適なのか…？？プロダクトにもっとも寄与するためには…？？？を考え「判断」し、「行動」に繋げていきたい。

このトークではどのように考えてカイゼンのための行動をとっているのか？をお伝えしたいと思っています。

モブプログラミングを始める際は、業務コードを書き始めるのではなく実験的なコードから入るのが良いとされています。
そのためには実験用のリポジトリが必要です。

しかし、下記のような問題でリポジトリ作成ができず、モブプログラミングを始められないケースが考えられます。

• Organizationにリポジトリを作る権限が無い
• リポジトリの作成申請にとても時間が掛かる
• Organizationに参加していないメンバーが参加する

このセッションでは、GitHubリポジトリにあるCollaborators機能を用いて、手軽にモブプログラミングを始めるためのリポジトリを準備する方法を紹介します。

PHPはインタプリタ言語であり、Zend EngineによってPHPコードが「OPcode」という中間表現にコンパイルされます。
またOPcodeは、OPcacheを有効にすることで共有メモリ上にキャッシュされるものです。
※OPcacheとは、予めコンパイル済みのバイトコード(OPcode)を共有メモリに用意し、パフォーマンスを向上させる仕組みです。

ではPHPコードから変換されたOPcodeを読んだことはありますか？
本トークでは下記の内容について話すことによって、PHPコードから変換されたOPcodeと慣れ親しみます。

• コンパイルされたOPcodeの出力方法
• 簡単なコードから出力されたOPcodeの読み方

このLTを聞き、PHPコードが内部でどのようなOPcodeに変換されるかを目の当たりにすることで、PHP処理系内部や低レベルへの興味が掻き立てられることでしょう。

2人月くらいの工数がかかる機能開発を1人で担当することがあります。
納期のプレッシャーに追われながら必死にコードを書いた結果、気づけば1回で80ファイル分の変更がある地獄のような巨大プルリクが出来上がっていました。

レビューをすり抜けたバグが障害を発生させてしまい、どげんかせんといかん！となった時に改善を行ったことで、リリースを細かくできたり、障害の発生が抑えられたりと良いことづくめで開発品質を上げることができるようになりました。

このLTでは、PRを分割した方法や分割することの大事さについてお話します。
PRを小さくしてみんなで幸せな開発ライフを送りましょう。

俺は普通のPHPer。今日もそれなりのコードを書いて普通にGitを使ってチーム開発をしている。

「(git add / git commit / git push)」
「プルリクエスト出したので確認お願いします！」

これはいつもの日常だ。

俺も入社したての頃よりはGitコマンドにも慣れて開発出来るようになってきたな。

そういえばこの前、git rebaseやgit cherry-pickとかいう便利そうなコマンドのことを先輩から聞いた。

でもなんだか難しそうだし、今は困っていないからいつか調べてみよう。

LT内容

私も以前はこのPHPerと同じでしたが、ブランチやコミットを整理してレビューしやすいプルリクエストを作ることで、チーム開発がスムーズに進むようになりました。
このLTでは、時間が許す限り、発展的なGitコマンド・オプションの使い所をお伝えします。

どうですか？社内イベント、開催してますか？

エンジニアとして生まれたからには様々な社内イベント開催のチャンスがあるかと思います。
LT会や勉強会、輪読会や懇親会……

でもどうやって開催したらいいんでしょう？何を、いつまでに、どのように進めたら？当日はどうする？

本セッションでは、私が社内イベントの運営や司会進行を数年務めてきた中で、
得たノウハウや個人的に大事にしている価値観についてお伝えできればと思います。
皆で楽しく円滑な社内イベントを作り上げていきましょう！

ぜひ聞いてほしい方

• 社内イベントを開催してみたいけどどうしたらいいかな……と悩んでいる方
• 社内イベントを開催しているけどなかなか上手に進められない方

※トーク内容の大半は社内/社外を問わないものとなりますが、
社外イベント特有の観点について扱わないため今回は「社内イベント」に限定します

フレームワークのドキュメントに従って、あるいはプロジェクトの既存のコードに従ってファイル上部に書いた「namespace」「use」といったキーワード。

この意味、正しく理解していますか？
「ディレクトリ名と対応させて書くやつ」「他の言語でいう import みたいなやつでしょ？」みたいな認識をしていませんか？

実は PHP の機能としては namespace（名前空間）とディレクトリ名、ファイル名には一切の関係はありません！

「じゃあ、なんで require とかを書かずに他のファイルに定義したクラスを使えているの？」と思ったあなたに、その仕組みと、それらを支えている存在をお教えします。

※本トークは「第 146 回 PHP 勉強会@東京」にて発表した LT の改訂版です。

「システム移行の際に、リリース後に不具合が発生した」という苦い経験をお持ちの方は多いのではないでしょうか？
特に、影響範囲が大きい機能に手を入れると、不具合の規模も大きくなってしまい、後始末に追われることになります。

影響範囲を狭めて段階的にリリースするための手法として「レガシーミミックパターン」というものがあります。
弊社においても直近の開発で採用し、かなりの安心感を得られたので、知見を共有したいと思います。

開発概要

• メール送信の機能がフレームワーク標準のものではなく独自拡張されていました
• これをフレームワーク標準のものに戻すための開発をしました
• しかしメールは 50 種類ほどあり、不具合が起きるとメールの再送などの後始末が大変そうです
• そこでレガシーミミックパターンを採用し、メールの種類ごとに新旧版を切り替えられるようにしました

Macユーザーの皆様。Docker環境はどうされておりますか？
Rancher Desktopですか？Docker for Macですか？

そこでOrbStackをおすすめしたいです。MacのDocker環境の遅さに悩まれている方に最適です。
このLTではOrbStack( https://orbstack.dev/ ) のメリットデメリット、最新の情報の追い方を説明していきます

日々のチーム開発のスループットを上げる取り組みを紹介していきます！

会社でのプロダクト開発では複数人のチーム開発で進めている方が大多数だと思います。
皆さんはチーム開発で何か課題を感じたり、もっと開発のスループットを上げたいと思ったことはありますか?

弊社ではスクラム開発を採用していますが自分が今いるスクラムチームでどんな課題があったのか、 それをどのように解決してスループットを向上させていくのか
試行錯誤して徐々に改善をしていった事を話します。

複数のテーブル構造を1つの集約として一括で取り扱うことができるRepositoryパターン。
Repositoryを呼び出す側からは複雑なテーブル構造などを隠蔽できるため、綺麗に実装できます。
ただし、当然ながらRepositoryパターンでは1オブジェクトに対して1回保存処理を行うので、クエリもオブジェクトの数だけ発行することになります。

画面から1つのオブジェクトを保存するだけであればパフォーマンスとかは気にしなくてもいいのですが、
例えば、CSVで一括登録する処理だったり、キューに溜まったものを深夜に処理するバッチのように、
大量のオブジェクトを登録する場合はクエリ発行回数が多くなってしまい、処理パフォーマンスは下がってしまいます。

そこで、本発表では、Repositoryパターンで綺麗に処理を書きつつ、一括保存をするためにやったことを紹介しようと思います。

勉強会とかカンファレンスに何回か参加しているとそのうち湧き上がってくる感情があると思います。
それは、自分も登壇する側に立ってみたい！

でも、
発表には憧れてるけど、発表することがない。
自分なんかが発表したって誰にも刺さらないでしょ？
発表したいけど発表ネタが浮かばないから、手を挙げられない。

その一方で、いつも登壇してる人がいるし、なんなら勉強会が決まった後にネタなんて考えればいいでしょ？って人もいるんです。
同じようにネタがないのに発表できる人と発表を尻込みしてしまう人、この違いはなんなんでしょうね？

そこで、ネタがなくて発表を尻込みしちゃっていた自分が、発表ネタを見つけるために心がけたことを話します。
同じように発表したいけど話すネタがなくて困ってる方の背中を押せたら嬉しいなと思います。

アプリケーションコードや運用保守などSQLを使ってクエリを書く機会は多々あります。
皆さんはSQLを使ってクエリを書くとき、どんなことを意識していますか？
「えーっと、まずはSELECT句から書いて…」
簡単なクエリを書く分にはそれでも良いですが、複雑なクエリを書かないと目的が達成できないような状況だったらどうでしょうか？

当LTでは複雑なクエリを書く上で必要な観点について話していきます。
具体的には以下のことについて解説していきます。

• ベン図を意識しよう
• 複雑なクエリは複数のクエリの塊なので、一つ一つのクエリを動作確認しながら進めよう
• SQL実行順序に沿ってクエリを書いてみよう

ある程度ゆるくコードがかけてしまうのもPHPの良さ。
しかし、キャリアを進めていけば必ずテストや静的解析で品質を担保する機会はやってきます。

「テスト書け！話はそれからだ。」「PHPStanのレベルは5以上な」
急に上司から命じられ、ゆるふわPHPerは愕然とすることでしょう。

本LTでは、テストを書くこと、静的解析がプログラムの品質にどうメリットがあるのかに加え、
それらがゆるふわPHPerの開発者としてのキャリアにもたらすメリットについてもお話しします。

結論、テストと静的解析はいいぞ、になるのですが、世の若手が
なるべく負荷なく自主的にテスト、静的解析したいぞ、となるLTにします。

対象者
PHPUnitやPHPStanをなんとなく触っている若手
全く触ったことない初心者
とりあえずテスト書けで終わらせちゃうシニア

話さないこと
細かいPHPStanやPHPUnitの書き方

みなさん、テストを“書かされて“いないでしょうか？

私は以前、テストコードに対する苦手意識が高く、テストコードも合わせてリリースするルールがあるから書く、という気持ちで書いていました。
約1年間抱いていた苦手な思い、なんと丸一日で（ほぼ）なくなりました！
やったことは、テストコードのペアプロです。

• ペアプロ中に意識して取得した知識
• 苦手意識がなくなったことで得たメリット

をお話しします！

皆さん開発を楽しめて進められていますか？
現在開発周りではCI/CD、テストコード、デプロイ自動化など多くの生産性を高める技術というのが多いと思います。
ただし、慣れてない方にとっては最初の一歩はとてつもなく大きいと思います。

本トークでは、そんな慣れていないときの最初の一歩を踏み出すための心構えに関して話したいと思っています。

▼対象者

・何かの改善をしてみたいが思いつかない方
・提案するのが怖い方

▼話すこと
日々の業務や開発プロセルに関して下記のようなことを話す予定です。

・どういうところに「カイゼン」ポイントがあるか
・改善する時の観点について

REST API を利用したり機能追加するときに、こんなことを思ったことはありませんか?

・必要なリソースを取得するために複数の API を実行しないといけない
・機能追加に伴って API のエンドポイントが増えて管理が大変

GraphQL を利用すると、クライアントが必要とするリソースだけを 1 回のリクエストだけで取得できます。
さらに、 GraphQL のクエリに、クライアントが要求するリソースの情報が記載されているため、従来の REST API のように、必要と思われる分だけエンドポイントを用意する必要もありません。

本 LT では、 Laravel と GraphQL を使って、 API サーバーを構築する方法を紹介いたします。
GraphQL に興味があるけれど触ったことがない方々に、始めるきっかけとなれば幸いです。

皆さん！ 何かしらcomposerコマンドを叩いたことがありますか？
おそらくこの会場に足を運んでくださっている皆さまなら、何回も叩いたことがあると思います！

しかし、どうでしょう？
パッケージの導入や依存関係の管理をサポートしてくれる神ツールだと思いながら、特定のコマンドだけなんとなく叩いていませんか？
ComposerはPHPシステム開発現場において、大体どこでも導入されているが当たり前すぎてあまり普段気にかけてやれない、、、そんな技術だと思います。

このLTでは、Composerのすごいところ、良いところを5分間できる限り話します！
具体的にはこんな話をします。
・Composer単体でのinstallからパッケージ導入までの話
・Composerがおすすめパッケージを勧めてくれる話
・痒い所に手が届くComposerコマンドの話
・Composerへの感謝の言葉

みなさん、commitで物語は書いていますでしょうか？私は書いています。

commitとは「読み手を意識して書くもの」、すなわち物語なのです。
commitは歴史に残る重要な資産と考えている私のcommitの積み方を聞いてください！
共感したら始めてみて欲しいです！

私がcommitを積む上で気にしていること

• 読者にとって不要な「物語（=commit）」は積まない
• 「起承転結」を意識する
• 「文脈」を的確に伝える