PHPerKaigi 2026 DAY1 に参加しました。
以前からPHPコミュニティの文化に魅力を感じており、今年はPHPerKaigiに参加できました。
しかも今回はDAY2のルーキーズLTで自分も登壇予定です。
そんな目線で過ごしたDAY1の印象をまとめます。
- イベントの概要
- イベント参加の背景
- 学びの多かったセッション
- ランチ
- ブース
- まとめ
イベントの概要
PHPerKaigi（ペチパーカイギ）は、PHPer、つまり、
現在PHPを使用している方、過去にPHPを使用していた方、
これからPHPを使いたいと思っている方、そしてPHPが大好きな方たちが、
技術的なノウハウとPHP愛を共有するためのイベントです。
今年の開催もオフライン会場を軸とした
オフライン・オンラインハイブリッド開催です。
みなさんのご都合に合う参加方法をお選び頂けます。2026年3月20日（金）〜 3月22日（日）はPHPerたちのお祭りです！
歴戦の勇者みたいな方はもちろん、初心者の方にも、
全てのPHPerが楽しめるイベントです。
スケジュール、空けておいて下さい！
引用：
イベント参加の背景
- 一昨年ぐらいからPHPのエンジニア文化を知り魅力を感じている。
- 昨年のふりかえりカンファレンスの懇親会でPHPerKaigiの魅力を聞き、ずっと気になっていた。
- 今年こそは参加と思いつつ、いっそ登壇もできればと応募したら採択頂きました！！DAY2ルーキーズLT枠で登壇します！
学びの多かったセッション
オープニング
PHPerKaigiはカンファレンスでもあり、コミュニティでもあるという言葉がとても好きでした。
PHPer Book Revue
雑に作る by きんじょうひできさん
・メモ
とにかくやっていくことを進めている一冊。
ハウツーから、マインドまで揃えている。
わくわく感を思い返せる。執筆陣の醸し出す雰囲気の良さ。
楽しくやってることが大事。
・完成予想図にはかわいさを足す。かわいいと嬉しい。
・車輪の再発明のスタートラインにも立っていない。分解、理解でわくわくする
・経験値を積んでいっても、ものを作る・動かす楽しさ大事にしたい。
時代とかツールなんかは変わるけどテクノロジーに対する態度とバイブスは変わんないじゃん⚡️🧠
— ギャル電 (@GALDEN999) 2026年3月11日
・学び
やりたいことに対してハードルを感じている場合、そのハードルの乗り越え方は雑さなのかも知れない。
横浜ノースAM ep133聞き直します。
Rubyソースコード完全解説 by nsfisisさん
・メモ
読んでもRubyは書けない。
なぜ今読むか？
初見のコードをどう読むかというコードリーディングの完全解説。
熟練のエンジニアが、どのような経験・ツール・思考過程・仮説をもとにコードを読んでいるのか理解できる。
・学び
コードリーディングの完全解説すごい。
Ruby、ぜんぜん読んだことないけど読んでみたいです。
マネジメントシステムに魂を入れる by やまずんさん
・メモ
組織は、顧客に価値を提供する。
製品サービスは顧客に受け入れられるべきである。
かつ、一時的ではなく、持続的であるべき。
そのためには、品質が重要になる。相手に満足をさせるもの。
目的のために何かをすること自体が品質マネジメントに繋がる。
・学び
はじめてやまずんさんのリアル登壇をお聞きすることができました。
目的を実現することの重要性。スライドが素敵です。
Fearless Change by 小泉岳人さん
・メモ
組織変革のパターン。
見つけづらい。当たり前のことがかいてある。
ただ、理解のために読書会に参加した。
参加者との交流で各参加者のコンテキストを学ぶことができた。
パタンランゲージの創造はコミュニティによって行われることが重要であった。
・学び
きゃー！小泉さんー！！#phperkaigi #a pic.twitter.com/D5GkJhr3Y8
— 幡ヶ谷亭直吉@技術書典20く05／多摩.dev／子育てMeetup (@asagayanaoki) 2026年3月21日
いつも刺激と励みを頂いている小泉さんの登壇。
Agile Leadership Summit 2026での小泉さんの登壇でFearless Change読みたいと思ったのにまだ積んだままのことに気づきました。
輪読会をはじめる好機なのかも知れない。
Science Fictions by fkuMnkさん
・メモ
・学び
昨年のTechRAMENConferenceで書籍紹介されてるのを聞いて以来、いつも増岡さんのご紹介される本が楽しみです。
条件判定に名前、つけてますか？ by 菱田裕美さん
メモ
もともとPHPerだが、今は仕事でJava書いてる。
名づけるということが、話題になったのはリーダブルコード起因。
名づけると何が嬉しいか？名前があると記憶しやすい。
コードを書く時に名づけは日ごろやっているはず。
では、条件分岐に名前があるとは？
レベル1：変数にする
「20歳以上」といった判定に対しても、飲酒可否や選挙権などある。
20歳という値を定数化することでも解消はできる。
レベル2：関数にする
クラス内で判定する。
ただ、クラス内で定義したら、いろいろなところに同じ分岐が点在する。
レベル3：Specificationクラスにする
専用のクラスを用意する。Specificationクラス。
デメリット。同じ判定条件を基に別なことをしたいとき、2度同じ判定をしてしまう。
設計原則は楽になるために作るべき。
また、なんでも名づければよいわけではない。
条件分岐を処理の外で実施するのが、レベル3のうえにある。
学び
PHPとJavaの類似性が興味深かったです。
基本的には判定条件は、値オブジェクトやドメインクラスに集約されるイメージがあります。
そのうえで、条件分岐に対する名づけを超えて、名づけがどこまでプログラミングにおいて有効か興味を持ちました。
大きい単位であればあるほど、われわれは多くのことを意識できる気がします。
「お金で解決」が全てではない！大規模WebアプリのCI高速化 by すてにゃんさん
メモ
CIに時間がかかると、アジリティ下がる。利用料かかる。
GitHub Actions→2コアランナー9並列から18並列に。
アプリケーションコード→
実行ログから重いテストを特定。sleep(1.minutes)などもあった。
トップ20を対応しても全体で考えるとそこまで影響を感じなかった。
プロファイラを使ってボトルネック特定。
UserFactoryでいろんなことをやっていて、テスト実施に不要な処理が多く呼ばれていた。
けど、そこまで早くならなかった。同時並行でつくられた機能が結局重かった。
データベースダンプを非同期に作ってリストア。毎回同期で作る必要ない。
my.cnfのチューニング。
パワフルマシンの導入。
AIがPRを自動で作ることによって、CIが回る数が増えた。
並列に何個もジョブをエンキューできる状態に。
委員会という制度で腰を据えて考えることができた。
3人で運営することで、実務の忙しさがあっても、吸収できた。
チューニングに対するヒントはISUCONからも得た。
メンテナンスも委員会がやっている。
学び
委員会という制度がとても興味深かったです。
自分のコンテキストにはない存在。けど、すごく有効そう。
ひとつひとつのトライ＆エラーを形式知にまとめていくことが素敵でした。
私たちも自分たちの実践を言語化していきたい。
車輪の再発明をしよう！PHPで実装して学ぶ、Webサーバーの仕組みとHTTPの正体 by H1R0さん
メモ
待つ→読む→返す
待つ：ソケットの作成、接続を待ち受ける
ソケットとは、通信の出入り口。
読む：リクエストを読み取る。リクエストはテキストでRFCが記載されている。
返す：レスポンスを組み立てて返す。
車輪を再発明することで仕組みの理解が容易になった。
仕組みを理解するとWEBサーバーの設定値に対する理解も深まった。
学び
車輪の再発明に対する捉え方が素敵でした。
考える人作る人の境界があるとしたら、どうしても車輪は作る人的な傾向に陥りがちな気がします。
自分の思考を通して作ることによる体験からの学びに大きな価値を感じました。
モジュラモノリス導入から4年間の総括：アーキテクチャと組織の相互作用について by 川島慧さん
メモ
4年前の意思決定に対する答え合わせ。
リアーキテクチャ、事業競争力を得るため。
分散自律型組織を目指していた。
モジュラモノリスを採用。マイクロは難しすぎた。
目的別組織はすぐに廃止された。頻繁に組織図は変更された。
目的別組織はサイロ化、環境への固執、プロセス習熟後の上限、負荷の偏りが原因。
目的別組織の代わりに、横断機能開発組織がはじまった。
どの組織もモジュールを持たない。
安定を担うコアドメインチームが新設された。
ただ、コアドメインチームもセクション制が導入され、3つに分化された。
現状セクション制で新アーキテクチャのもと開発を進めている。
組織図は高頻度に更新。コアドメインチームが運用改善を自律的にやった。
ほぼすべての開発プロジェクトで複数モジュールを跨いだ開発をしていた。
コアドメインチームへの依頼が積み重なり続けた。
継続的なリファクタリングはほとんど実施されなかった。
プラットフォームチームは過剰サービスになっていた気もする。
自律分散からは程遠い状態だった。
顧客価値検証と分散自律改善は両立できないのでは？
バリューストリームと境界づけられたコンテキスト。
突き詰めると、この2つはコンフリクトする。
バリューストリーム：Lean思考。無駄をなくす。顧客への価値提供の最適化。
境界づけられたコンテキスト：DDD。境界の限定。マイクロサービス化の判断基準にもなる。
バリューストリームに最適化された組織：
企画からリリースまでに1つのチームが主導できる。
カスタマージャーニーや顧客の価値で生成される。
アクターの単位だと分かりやすい。
境界づけられたコンテキストに最適化された組織：
技術的な意思決定を最適化する。作った人が運用することが望ましくなる。
知識の蓄積はチームになる。
この2つの最適化は自律したチームを目指すうえでは似ている。
バリューストリームと境界づけられたコンテキストが1対1になるのであれば問題はない。
アクターごとに境界づけられたコンテキストを分けると、開発上で課題が発生する。
境界づけられたコンテキストは、事業者目線に寄りやすい。
両方に同時に最適化された組織は成立しない。
バリューストリームは顧客価値検証、境界づけられたコンテキストはチームごとの自律最適化。
4年間の事象。
目的別組織はチームの自律に向いていたが、顧客価値検証に最適ではなかった。
カスタマージャーニーは境界づけられたコンテキストを横断する。
答え合わせ。
震源地。目的不確実性のPDCAと方法不確実性のPDCAには矛盾があった。
モジュラモノリス以前に問題があった。
顧客価値検証最適、分散自律改善最適が両方最大化することは難しい。
3者のトレードオフ構造。
時間の経過とともに均衡点も推移する。事業は変わり続ける。
顔ぶれも変わるし、それにアーキテクチャが適応する必要がある。
モジュラモノリスは最適だった。
両者の溝を超えるのは、人と組織の質的変化が必要になってくる。
学び
横浜ノースAMを聞いて楽しみにしていたセッションでした。
考えることが多く、持ち帰るものも大きく、他では得られない体験をしました。
私はここまで真摯に開発に向き合えているだろうか、と考えさせられました。
そのうえで、4年間の実践を聞くことができるという大きな体験を得ました。
資料読み直します。
ビジネスがわかるエンジニアになろう：経営学とエンジニアリング、その共通点と活用法 by nrs / 成瀬允宣さん
メモ
経営学は開発者に影響があるか。
CTOになった頃、本をたくさん読んだ。MBAプログラムの本に興味を持った。
ケーススタディ：状況把握→分析→議論→意思決定
MBAは、フレームワークで問題に挑む。経営学は体系化された知識。
技術革新の波、何から手を付けるか：変革を組織に浸透させるための8段階プロセス
指導する相手ができた：パス/ゴール理論
後輩が失敗した：失敗のグラデーション
導入したいサービスがある：加重平均資本コスト/正味現在価値
プロダクトが伸び悩んで知る：イシューを考え、分解する
エンジニアリング = 勝ち創出の営み。経営学 = 意思決定。
学び
今までMBAについてもっと遠い存在に感じていました。
今日扱われた考え方に、より身近な存在として感じることができました。
ビジネスがわかるエンジニアになるため学びたいです。
【アンカンファレンス】DBについて by sodaiさん
メモ
・DBのモデリングにAIをどう利用しているか
DB設計のやり方は世の中的にある程度やり方は決まっている。
外部→概念→内部と落とし込んでAIを使うことはできるが、一気通貫で利用するとうまくいかない。
AIは答えは知らないが、一般的にどっちかは答えられる。
リソースとイベントを分ける面でも活用できる。
自分の考えに対する反論を与えることにも使える。
・リファクタリングタイミング
腐った牛乳とチーズの違いは経験で分かる。
直したことで価値が出るかが重要。
DBのリファクタが難しいのは経験が少ないから。
学び
合間を縫ってsoudaiさんのアンカンファレンスに参加できました。
アンカンファレンスの流動的な流れがとても面白かったです。
DBのモデリングにおいて、AIにすべて丸ごとお願いするのではなく、ステップ踏んでお願いすべきというのは、改めての気づきになりました。
自分がほぼ正しいと思っていることに対して、反論を言わせるという使い方も取り入れたいと思いました。
ランチ
Magnolia.Kさんやnrsさん、山岡さん達とご一緒させていただきました。
Magnoliaさんには多摩.devの発起にあたり感謝をお伝えしたいと思っていました。
今まで機会を逃していたため、お話しできて嬉しかったです。
nrsさんにはカンファレンスでお見かけするたびに、「（コドモンに）娘がお世話になっています」とお伝えしてきましたが、
その娘がとうとう昨日卒園式を迎えたことをお伝え出来ました。
普段ご一緒できない方たちとご一緒できて嬉しかったです。
ブース
各ブースを回ることができました。
いろいろなお話をお伺いすることができて嬉しかったです。
カオナビさんのブースで顔はめました。
得意なことを書きました！！#phperkaigi #カオナビ pic.twitter.com/nt2ZWPXXTa
— 幡ヶ谷亭直吉@技術書典20く05／多摩.dev／子育てMeetup (@asagayanaoki) 2026年3月21日
PR TIMESさんのブースで好成績を出しました。
[⏰PHP8.5秒チャレンジ] タイムは8.552秒で、誤差は±0.052秒でした！✨
— 幡ヶ谷亭直吉@技術書典20く05／多摩.dev／子育てMeetup (@asagayanaoki) 2026年3月21日
記録は現在ブース来場者中「5位」です！🌟
#prtimes_dev #phperkaigi (@prtimes_dev)
ビンゴフルコンボの上、特賞ゲットしました。
ビンゴフルコンプの上、特等あたりました！！うれしい！！#phperkaigi pic.twitter.com/Fgr2xhjUTk
— 幡ヶ谷亭直吉@技術書典20く05／多摩.dev／子育てMeetup (@asagayanaoki) 2026年3月21日
まとめ
PHPerKaigi初参加ですが、オープニングからとても素敵でした。
手作り感のある温かい運営に、以前参加したTechRAMEN Conferenceの雰囲気を思い出しました。
セッションやブースだけでなく、アンカンファレンス、ランチ、廊下も楽しむことができました。
交流させていただいた皆さまありがとうございました。
明日はLT登壇します。楽しみです。
