プロポーザル

トーク概要

いつものようにコーヒーを片手にミックスナッツを食べながら、今日もコードレビューの時間がやってきました。

プルリクエストを眺めながら、こんなことを思ったことはないでしょうか？

• 差分でかすぎる...これ正しくレビュー出来る人いる？
• ここまで実装進んでから指摘しにくいなぁ...
• フィードバックするのはこれで何度目だろうか...

恥ずかしながら私の部署でも、このようなことはよくありました。

このセッションでは、コードレビューの存在意義とは一体何なのか？を改めて考え、私たちの部署で普段行われているコードレビューやプルリクエストに対するガイドラインをご紹介します。
このセッションが終わる頃には、明日からのコードレビューが楽しみになる事間違いなしです！（カリッ）

話さない内容

• 具体的なGitHub ActionsのCIの組み方
• GitHubの設定

想定読者

• コードレビューという作業でもやもやを感じる人
• レビュー指摘に対してモヤモヤを感じる人
• チームのパフォーマンスを改善したい皆様

任意の時点の PHP プロセスのメモリ状態のスナップショットをとり、SQL で「一番大きな文字列」「あるクラスの全インスタンスにおける特定プロパティに格納された配列の平均サイズ」「前回取得時のスナップショットから生き残り続けているオブジェクト」といった情報を自由に取り出せるとしたら、とてもおもしろいと思いませんか？

え、何の役に立つのかって？そりゃ何かの役には立つでしょう。何かの役に立つという確信はありますが、しかしそのような実用一辺倒の観点でものごとの価値を決めつけていくのは、あまり豊かな生き方とは言えません。役に立とうが立つまいが、とにかくスクリプトの状態を SQL でクエリするのです。

このトークは自作のメモリプロファイラ Reli に、登壇駆動開発で機能追加をするための枠です。採択されトークが行われることで、世界中の PHPer がメモリリークの心配なく long running な PHP スクリプトを安心して作ったり動かしたりできる、そんな夢のある世の中へ一歩近づくこともできます。
トーク内容そのものは PHP 処理系の内部状態をどう RDB のテーブル構造で表すかというマニアックな話が延々続くこととなります。
PHP スクリプトによる大道芸に興味のある方には、大道芸として面白く聞こえるかもしれません。
聞く人がほぼ全員置いてけぼりになるけれど喋ってる本人は妙に熱量が高いという、その温度差を眺めて苦笑いしたり、運が良ければ「こんな変なことやっていいなら俺も/私も変なことをやるぞ」と妙な熱量が伝染したような気持ちになることもできるかもしれません。

15年以上にわたり、社内の売り上げを支え続けてきた基盤システムが存在しました。
このシステムは、事業ドメインの変遷に合わせて不断に拡張され、事業の成長を支えてきました。
しかし、その結果として、巨大なモノリシックレポジトリ、仕様書の欠如、1ファイルに集約されたJavaScript、そして無数のマジックナンバーという問題に直面しています。
これにより、不具合の発生頻度増加、開発生産性の低下、追加開発の難易度上昇といった「技術的負債」が無視できない状況になりました。

本トークでは、これらの課題を解消すべく、fuelPHP（PHP version 7.3）から社内で標準的に利用されているLaravel（PHP version 8.2）へのリプレイスを実施した事例についてお話しします。

具体的には以下のトピックについて詳しくお話しします。

• リプレイスに際して最初に決定した事項とその理由
• プロジェクトの実現可能性を高めるために考慮したスケジューリング
• 開発環境の技術選定プロセスとその選定理由
• 基本的なアーキテクチャ設計のアプローチ
• リリース時に行った対応策
• リプレイス後に得られた具体的な効果

PHPに関する深い技術的な議論は難しいかもしれませんが、技術的負債を抱える皆様にとって役立つ情報を提供できれば幸いです。
ぜひ、このセッションを通じて、皆様のプロジェクトの成功につながるヒントを得ていただければと思います。

PHP は 1995 年から続く Web 向けプログラミング言語であり、30 周年を迎える今、技術の進化が著しい中で、PHP も大きく進化を遂げています。

PHP がこの世に生まれた頃、私はまだ 10 歳くらいの少年でした。
PHP が 30 周年を迎える今、世の中の何もかもがもはや当時とは違っています。もちろん私も 40 歳のオッサンになりました。

このトークでは以下のようなトピックへ触れつつ、2025 年の PHP プログラミングの現況を雑多な観点からまとめて紹介していきます。
・エディタをはじめとした開発環境
・今の言語機能を活かした典型的なコードの姿
・コードの部品分割方法、構成方法
・パッケージシステム
・静的解析や自動リファクタリングなどの周辺エコシステム
・実行環境の選択肢
・フレームワークの選択肢
・かつて PHP では不可能・不得意とされていた非同期処理や OS とのインタラクションなど

このトークを通じて、PHP 4 や PHP 5 の時代しか知らない人からすれば信じられないような、PHP 7 が出た 10 年前を知っている人が見ても少し意外に思うような PHP の現在の姿を知ることができるでしょう。またこれまで PHP をあまりつかったことがない人向けには、どういった言語機能やツールを前提に言語を使っていけばよいかを古い情報に惑わされずひと巡りできるような、簡単な手引となることを目指します。

今すぐ社内用のWebツールを作らなくてはいけなくなったので、いまからこの部屋で、20分だけ仕事をさせてください!

2025年現在、OpenID Connectが多くのIDプロバイダーに実装され、とても良い時代になりました。
PHPでのライブラリも多くあり、OktaやOneLoginなどを社内で使っている方なら、すぐに社員にアクセスを限定した簡単なWebサービスを作成可能です。

今回は、OpenID Connectで社員情報を認証、認可するところまでをBref(serverless on AWS Lambda)でライブコーディングし、
20分で社内Webツールが初心者でも簡単に作れるところまでを実践します。

みなさん、もっと気軽に会社のアカウントで認証認可、やっちゃいましょう!

私は2024年11月から新しい環境で仕事しています。
そして2024年12月現在、絶賛オンボーディング の真っ最中です。

ここで進めているオンボーディングを通して良かった点、改善したほうが良いとフィードバックした点などをお話しして、聞いてくださった皆さんがオンボーディング する時、される時に活かしていただきたいなという想いでお話しします。

私のエンジニアとしてのキャリアは、予想外の展開をたどってきました。皆さんのキャリアも、同様に多様な道を歩んでいるのではないでしょうか。

私がPHPerとしてキャリアをスタートさせたのは約4年前のことです。その後の道のりを以下に示します。
1年目
└既存サービスの運用開発（PHPerとしての開発）
2年目
└SREチームに所属し、コンテナ化や新規サービス立ち上げを経験
3年目〜現在
└新規サービスの立ち上げメンバーとして、インフラ〜アプリケーション開発を経験
└クライアントへのサービス導入アポイントメントに同席

このキャリアの道筋は、当初の予想とは異なるものですが、その中で得た「エンジニアとしての基礎技術」の重要性についてお話ししたいと思います。

特に、キャリアの選択に迷っている若手エンジニアや、新しい分野に挑戦したいと考えている方に、このトークはぜひお聞きいただきたい内容です。

CTOとして内製開発チームをゼロから立ち上げ、現在では社員・業務委託を含め約20名の規模にまで成長させてきました。このチーム拡大の過程では、採用難が叫ばれる時代の中、スキルやマインドを見極め、自社にフィットする人材を見つけることに真剣に向き合ってきました。
その一方で、採用活動ではさまざまな課題にも直面しました。理想の人材と巡り合えないことや、採用後に感じるミスマッチなどの試行錯誤を繰り返してきた中で、一つの有効な手法としてコーディング試験を導入しました。この取り組みによって、候補者の技術力や考え方をより深く理解し、チームに適した人材と出会う手ごたえを得ることができました。
本セッションでは、コーディング試験導入の背景や実際の運用方法、そこで得られた成果や課題、そしてそれを通じて得た学びを共有します。同じように採用の課題に直面している方々にとって、実践的なヒントとなれば幸いです。

◆対象者
・エンジニアの採用に関わるエンジニア
・新規の開発チーム立ち上げをしている人

◆話すこと
・なぜ採用プロセスを改善しようと思ったのか？
・PHPer採用の課題感
・技術力を客観的に評価する必要性
・テスト内容の作成
・実施してみた結果
・候補者の反応やフィードバック
・実施したうえでの改善
・どのようなポイントを評価したか
・採用プロセスにおける成果
・コーディングテストの有効性

非常に便利な PHPStan ですが、大規模プロジェクト、特に Laravel を採用したプロジェクトだとものすごく時間がかかってしまったりすることも多いかと思われます
そんな PHPStan を様々な手法を用いて高速化を試み、最終的にどうなったかをライトニングにお話してみたいと思います

皆さんはコードレビューしていますか？

コードレビューするとき、レビューイの気持ちを考えることはできていますか？
日々の業務に追われる中でコードレビューを行うとだんだんと相手の気持ちを考えることができなくなり、
時には厳しい言葉だけを投げてしまう状況になってしまい、レビューイのモチベーションを奪いかねません。

本LTでは、そんな忙しいあなたでも最低限のワーディングで相手をやる気にさせるコメントを厳選して紹介します！

「なぜこのコメントが良いのか」の解説も交えながら消化しようと思います！

案件や開発について相談する際に、何に困っていて、何を相談したいのか、
頭の中が混乱してしまう経験ありませんか？

このセッションでは、実際の案件でどのような開発メモを活用し、思考の整理に繋がったかご紹介します。
ここでの「開発メモ」とは、単なる作業記録ではなく、現在の状況や課題、解決策を明確にするための記録方法です。

【概要】

• 何がわからないのかわからないが続き、相談できず、失敗・苦労した経験
• 相談する際に、何に困っていて、何を相談したいのか思考をまとめる方法
• 思考を整理する際に、活用した開発メモの項目
• 実施後の変化

【おすすめの人】

• 新卒エンジニア
• エンジニア初学者

皆さんはDaemon（デーモン）をご存じですか？Daemonとは、バックグラウンドで実行され続けるプログラムのことです。ジョブキュー、バッチ処理、アプリケーションサーバー、クローラーといった役割を担うプログラムがその例です。

このトークでは、PHPを用いてDaemonプログラムを「飼いならし」、実用的に運用する方法についてお話します。具体的には、Daemonとはどのようなものなのか、その基本構造や必要な技術を解説します。PHPでのメインループの実装、シグナル処理、終了時のリソース解放といった基礎から、安定稼働を支えるスーパーバイザー（systemdやコンテナ）との連携、監視の仕組み、さらには並列処理やワーカーの協調についても取り上げる予定です。

もし、まだデーモンを「飼いならした」ことがない方は、Daemonという言葉だけで少し身構えるかもしれません。でも安心してください。初心者でもわかるシンプルなDaemonプログラムの構築方法から丁寧にお話しますので、召喚する楽しさ、支配するスリルと万能感を得られる要になると思います。

単純なウェブアプリや、Cronによるバッチで物足りないPHPerのあなたも（あるいはそうでないあなたも）、この機会にDaemonを造り、飼いならしてみませんか？

皆さんは Joe Watkins さんをご存知でしょうか。
PHP コア開発者の一人で、インターネット上ではしばしば krakjoe というニックネームで活動しています。

ご存知ない方は、以下いずれかの PHP 拡張や SAPI のお世話になったことはありますでしょうか。彼はこれらの拡張や SAPI の作者です。
・apcu
・pcov
・phpdbg
・parallel
・pthreads

また彼は PHP Foundation 設立のきっかけとなった一人でもあります。
ここ最近のバージョンの PHP を使っている人は PHP Foundation の雇ったコア開発者の仕事の恩恵を得ており、つまり最近のバージョンの PHP を使うだけでも、間接的にですが krakjoe さんの取り組みから少しばかりの嬉しさを得ている、と言えます。

彼は現在、健康上の理由・経済的理由から危機に瀕しており、gofundme にて寄付を募っています。
https://www.gofundme.com/f/a-big-ask-from-a-big-community

この記事では krakjoe 大先生がまた元気になってよく分からないものを沢山作って、世の中や PHP 界隈を賑やかにできるよう、その偉業をたたえつつ寄付を煽っていきたいと思います。

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

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

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

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

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

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

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

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

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

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

PHPの、新しいExtension Installer・・・PIE!
php/pie: The PHP Installer for Extensions

そして、このツールで導入できる拡張たちは、Packagist上で検索やメタ情報の取得ができます。
・・・となれば、興味が湧くのは「ここで、どんな情報が扱われているのか」ですよね✨️
また、従来からPackagistで扱われていたComposerパッケージのそれとは、なにか違うのでしょうか？
更に言えば、ここで取得された情報は、どんな役割を果たして、PIEによるインストールのプロセスに役立っているのでしょうか？？

この記事では、「PIEをどう使うか」「どう活用・運用していくか」といったトピックには重きを置かずに、
「レポジトリ(Packagist)の提供するAPIとして、どうなっているの？」といった内部事情・詳細部分にフォーカスを当てた、
ちょっとニッチな話題を扱います。

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

考えるべきこと

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

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

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

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

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

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

話さないこと

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

想定オーディエンス

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

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

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

取り上げる内容：

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

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

ScalaやErlangなどでアクターモデルは、1973年に発表された並行計算の数学的モデルの一種ですが、
長い間PHPでは実現が難しいとされてきました。
アクターモデルは、並行プログラミングにおける効率的な計算モデルであり、プロセス間の非同期通信も特徴の一つとしています
効率よくそれぞれが並行で動作し、簡単に状態を復元することができたりPHPのOSSなどではあまり見ない特徴を持っています。
PHPでももしそれが実現できたら・・・

しかし時間が経つにつれ、Swooleなどをうまく活用することで実現できそうなことがわかり、
PHPでフルスクラッチで開発したアクターモデルのツールキットがPhluxorです。

Phluxorは、PHPではあまり見られないメッセージングを活用した仕組みを持ち、
各インスタンスが独立して動作し外部から隔離されたアクターを実現しています。
さらに、物理的に異なるサーバ間でのアクター操作が可能な機能を実装しています。
Webフレームワークとは異なり、情報伝達設計に特化した仕組みを持ち、
PHPでは他に類を見ないヒエラルキー構造や自動復旧機能でアクターシステムをサポートしています。

これらは一体どのように実装して、どんな仕組みで動いているのか？
アクターモデルのツールキットの作り方について、詳しくお話します！乾杯！

皆さん、ちょっとしたコードの動作確認をしたい・サクッとRDBを参照/書込する作業をしたい、等の場合に何を使っていますか？

コードを対話式で実行できるREPL(Read Eval Print Loop)は書き捨てのスクリプトを作ったりせずにコードを実行でき、開発を大いに助けてくれます。

PHPではphp -aコマンドで起動されるランタイム同梱のインタラクティブシェルや、より高機能で補完機能やコード実行結果の自動出力機能などを備えたPsySH (bobthecow/psysh)などがあります。

また、laravel/tinkerやcakephp/replなど特定の用途向けに作成されたREPLも存在し、筆者は簡単なRDBの読み書きであればREPLから行うこともあります。
実はそれらのREPLはPsySHをベースとして開発されています。

そんな便利、かつ他のツールの基盤となっているPsySHはPHP製のOSSです。
そう、PHPerが普段使い慣れた言語で作られているのでコードを読めば仕組みがわかります。

この発表では、REPLの基本である「入力の読み取り (Read)」「評価 (Eval)」「出力 (Print)」を軸に、PsySHがどのように実装されているのか・laravel/tinkerなどがどのようにPsySHを拡張しているのかを深掘ります。

• 発表の対象
  • PsySH（やそれを拡張したツール）のREPLとしての機能
• 話さないこと
  • REPL以外の機能 (デバッガ、コマンドライン引数で受け取ったコードの実行など)
• 対象聴衆
  • 普段REPLを使っている人
  • (普段REPLを使っているかどうかは関係なく) REPLの仕組みに興味がある人