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 に興味があるけれど触ったことがない方々に、始めるきっかけとなれば幸いです。

皆さん、毎日デプロイしたくないですか？＼ した〜い ／

私たちのチームではふりかえりをした結果「毎日デプロイする！」という目標を立てました。

そのためにタスク分解とタスクの順番を工夫し毎日デプロイする体制に変えました。
そうすることでチームの意思疎通が以前より楽にとれるようになりました。

本トークでは自分たちのチームでやっていた工夫・訪れた良い変化をお話しします。
毎日小さくデプロイする魅力をお伝えします！

PHPは裾野の広い言語です。WordPress、Laravelをはじめ、Web開発で広く使われており、コミュニティも非常に活発です。
そんな楽しげなコミュニティに異業種から転職したジョブチェンPHPerだって参加したい！

というわけで今年のPHPerKaigiからプロポーザルを送るようになり、先日無事福岡の地方カンファレンスで登壇デビューを果たしました！
このトークではその中で得られた知見についてお話させて頂きます。

これを機にプロポーザル送ってみようかな？という人が一人でも増えれば幸いです！

開発していると何かと話に出る「具体と抽象」
何かを説明する時に抽象度ってとても大事だと思います。
例えばWebアプリケーションがどうやって動いているかを説明する際に、説明したい箇所や相手によって話す内容は異なるかと思います。
ネットワークの話が必要か？
Webサーバーの話が必要か？
内部で動いている言語処理の話が必要か？
これが理解できていないと、例えば営業の人にクエリの話を出してしまってポカンとされてしまう訳です。
逆に適切な抽象度で話ができれば人に説明するのがグンとうまくなります。

本LTでは抽象度についてお話したいと思います。

• コード書くの怖いな〜
• リリースするの怖いな〜
• このクラス触るの怖いな〜

こう思った経験、誰しもあるのではないでしょうか？
恐怖とはつまり「分からなさ」に起因していると私は考えています。
触った時の影響が分からないものは誰しも触りたくないと感じるかと思います。

本LTでは、そんな開発するうえでの恐怖にどうやって立ち向かっていくのか、お話できればと思います。

ブロックチェーンとは、一般的には、「取引履歴を暗号技術によって過去から1本の鎖のようにつなげ、正確な取引履歴を維持しようとする技術」とされています。
今回はPHPを使ってブロックチェーンのサンプルアプリを実装する話をします！具体的にはコミュニティに招待するとトークンが付与されるアプリを作る予定です。
本当にPHPでも実装できるの？と疑問を抱いている方は是非聞いてください！

皆さん、「読みたいな」と思える本に出会えていますか？
私は「趣味は何ですか？」「はい、積ん読を増やすことです」と胸を張って答えられるくらい、ここ数年は家に本が増えています。

読書をしてインプットをする、知識を増やすというのは非常に大事なことです。
それと同じくらい、「自分を高めてくれそうな知識との出会い方」も大事なのではないでしょうか？

題して、「積ん読を増やす技術」です。
このLTでは、実際に体験したことをお伝えしながら
「どうやって本を買っているか、見つけるのか」「積ん読を増やすことで広がる世界」について、紐解いていきます。

話すこと

• 面白そうな本と出会うコツ
• 「家に本が沢山ある」という状況とどう向き合うか・活かせるか

話さないこと

• コスパ、タイパ
• 収納術