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

◆話すこと
・採用の課題感
・技術力を客観的に評価する必要性
・テスト内容
・どのようなポイントを評価したか
・採用プロセスにおける成果

「どこで何が起きているのか分からない」──複雑な処理が詰め込まれたコードを前に、そう感じたことはありませんか？

本セッションでは、そんな不透明なロジックを “出来事” を軸に整理し直す、イベント駆動アーキテクチャへの段階的な移行プロセスを紹介します。
「〇〇が起きた」というドメインイベントを導入し、処理を手続き型から宣言的なスタイルへと転換することで、コードの見通しや責務を明確にしていきます。

まずは同期イベントによる責務分離から始め、そこから非同期イベント処理へと進化させる3ステップを、PHPコードの実例とともに解説します。
さらに、非同期化に伴って生じる整合性の落とし穴についても、Transactional Outbox などの実装パターンを交えて紹介。

“出来事”を中心にコードを組み立てることで得られる、読みやすさと保守性を兼ね備えたアーキテクチャ設計のヒントをお届けします。

「PHP 8.4.0から、インターフェースプロパティを宣言できるようになりました。」

私はこれをみたときに、「よっしゃ、きた！！！！」と大興奮しました。

とはいえ、この内容については多くの人が注目していたのかなと思っており、話のネタとしては今更感がありますが...
改めて皆さんに 「インターフェースにプロパティを定義できる喜び」 をシェアします。

そこで、以下についてお話をさせていただきたいです

• 基本的な使い方や注意点
• インターフェースにプロパティを定義できることで何がうれしいのか

PHP では try-catch による例外処理が一般的ですが、「どこで例外を処理すべきか？」「本当にこの場面で例外を使うべきなのか？」と迷ったことはありませんか？
過剰なエラーハンドリングや、catch したけれど何もしていない“握りつぶし”が積み重なると、責任の所在が曖昧になり、コードの見通しや保守性にも悪影響を及ぼします。

こうした課題へのヒントとして、Rust などの言語で採用されている Result 型の考え方を、PHP に応用するアプローチがあります。
Result 型は、失敗を型として明示的に扱い、成功も失敗も返り値で表現する設計手法です。

本セッションでは、さらに一歩進んで、処理の流れを線路のように“合成”する「Railway Oriented Programming」の考え方を取り入れ、複雑な分岐処理をシンプルに記述する実践的な方法を紹介します！

PHPはWeb開発の現場でカジュアルに使われてきましたが、「正しく」使うのが難しい言語だと言えます。
20年以上の歴史を重ねてきたWeb開発の現場でもさまざまな言語が生まれてきましたが、PHPの存在感は未だに衰えてはいません。

そのような言語の中でも揺れ動いてきたのが「静的(static)」と「動的(dynamic)」という概念です。
PHPは一般に「動的型付けのスクリプト言語」のように分類されますが、異なる特徴を持った言語も多く登場しています。

本トークではPHPの静的性と動的性について紹介し、PHPの現在地点、そして「静的解析」という技術がどのように問題解決につながるかを紹介します。

概要

Web を支える重要なプロトコルのひとつ、HTTP。言語やライブラリ、フレームワークの下に隠蔽され、通信プロトコルを直接意識する機会は少ないと思います。そこで、PHP のソケット API を使って HTTP を解する小さなサーバを実装し、HTTP の理解を目指しましょう。

話すこと

• TCP/IP スタック
• HTTP の基本的なプロトコル
• Pure PHP でソケット API を用いて小さな HTTP サーバを実装する
  • GET / POST メソッド
  • Cookie / Set-Cookie ヘッダ

実際に公開サーバ上で動く状態にしてデモを見せます

対象

• Web サイトの通信がどのようにおこなわれているのか詳しく知りたい方
• プロトコル実装に興味がある方

私のいるチームではスクラムを導入して2年ほど運用してきましたが、いろいろあってスクラムをやめてみることにしました。
そうしたらなぜか効率が上がり、ベロシティの数字ベースで1.5倍ほど成果を出せるようになりました。
このLTでは、なぜスクラムをはじめて、そしてやめたのか、なぜスクラムをやめると生産性が上がったのか、について分析しながら共有します。

■ 話すこと

• スクラムをはじめた理由
  • 朝会長すぎ！タスク管理手法としてのスクラム導入
• スクラムをやめた理由
  • スプリントゴールどうする問題
  • ステークホルダーは意識しないといけない？
• Beyond the scrum 〜スクラムを超えた先で見たもの〜
  • これが俺たちのチームの"答え"？

長年運用されてきた PHP プロダクトをこれからも安心して使い続けるためには、 PHP 本体のアップデートが不可欠です。
本セッションでは、 PHP 4 の時代から20年以上運用されたプロダクトを PHP 8.3 までアップデートしてきたことで得られた知見と、 PHP 8.4 以降にバージョンアップするために何をするのか、を共有します。
レガシーと向き合う皆さんに役立つ実践的な知見をお届けします。

■ 話すこと

• PHP をアップデートするためにやっておくといいこと
  • レガシーだからこそ、PHP の最新情報をキャッチアップしておこう
  • 技術的負債は少しずつ解消しておこう
• PHP 以外の OSS ライブラリの動向にも注意
  • 自分たちでコントリビュートすることも考えよう

マイクロサービス流行の時代で、あえてモノリスを作りませんか？

バックエンドとフロントエンドの連携を行う際は、辛い思いをした方が多いのではないでしょうか。
APIの作成、認証の実装、フォーム送信など、様々なハードルがあります。
そういった問題を解決して、フルスタック開発を楽にするライブラリさえあれば...
実際にありますよ！

このLTでは、SPAのフロントエンドをバックエンド内で作れるInertia.jsをご紹介します。
基本的な使い方から、直近の新機能やInertia.jsの将来を解説します。
このLTを通じて、「フルスタック開発が楽になった！」「フロントエンドのためのAPI設計はもうさらばだ！」と思ってもらえればと思います。

PHP-FPMを使ったWebシステムで，応答が遅くなった，突然繋がらなくなった，という経験はありませんか？
PHP-FPMのメトリクスを取るとプロセスやリクエストの状況を把握でき，これら問題の解決に役立ちます.

メトリクスを出力するために従来まではphp-fpm_exporterなどのデータ形式を変換する外部ツールが必要でしたが，
PHP8.1からは多くの監視ツールが対応するOpenMetrics形式で出力できるようになりました.
一方，Web上にはPHP-FPMのみでメトリクスを出力する方法の情報が少なく，実際に出力すると幾つかの落とし穴がありました.

発表ではPHP-FPMのみでメトリクスを出力する場合の設定例・注意点，exporterを使う方法との比較を話します.

設定例は下記で公開中
https://github.com/Daichi-1637/PHP-FPM_metrics

私は京都のスタートアップで働くエンジニアです。

スタートアップでは、売上拡大のために新規顧客獲得が重要になりますが、既存の業務フローがある顧客にはそのままでは導入できないことも少なくありません。

個別のカスタマイズ要望は、プロダクト開発のヒントとなりうる反面、その後の開発に影響を与える要因にもなります。

このトークでは、以下のテーマを主に扱います。

• 標準機能にするのか個別の機能にするのか
• 個別機能開発をする際にどのように作るのか
• リファクタリングをいつ行うか

このトークを通じて、プロダクトの今と将来を両立するための考え方の一例を提案したいと思います。

php-srcを知りたいときの教材として、てきめんさんの「var_dumpを写経する - php-srcを学ぶぞ -」は分かりやすいです。

https://techbookfest.org/product/5746408227340288?productVariantID=6343868242984960

このトークでは、実際に本に倣って進めていくところで詰まったポイントとその解消方法や、php8で写経をしてみるために必要な準備を解説します。

実際にextensionを含めてビルドして動くところまで到達することを目標にします。

現代のコンピュータはハードウェアから私たちプログラマが書くプログラムの動作までの間が多くのレイヤーに分けられて動作しています。
レイヤーは自分より下を抽象化し、下のレイヤーを詳しく理解しなくても多くの場合プログラマはプログラムを書けます。
一方、プログラムが期待した様に動作しない時には下のレイヤーの動作の理解が問題の解決の助けになることもあります。

このトークでは私たちが愛するPHPをスタート地点にして、「VMって何？」「 PHPやJavaとC言語の根本的な違い」など、コンピュータプログラムがどの様に動作するのかを解説します。

コンピュータのレイヤー構造を理解すると、いままでは見えていなかった角度からプログラミングを楽しめるようになります。
このトークを通じて、低レイヤーが好きになったり、いろいろなレイヤーで面白いことをしたりする方が増えることを期待しています！

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しいのですが近年のコンピュータの高速化はすべてキャッシュによるものと言っても過言ではないぐらいキャッシュは重要な技術です。

このトークでは「なぜキャッシュメモリは速いのか」の説明から、なぜキャッシュが必須の存在なのか、そしてキャッシュが引き起こすCPUの脆弱性について初心者の方にもわかりやすくご説明します。

コンピュータアーキテクチャの勉強、というよりはキャッシュを取り巻くハートウォーミングストーリーを聴きに来るつもりでいらしてください。きっと「CPU脆弱性って言っても思ったより難しくないな」「おもしろいな」と思って頂けると思います。

2024年1月、「なぜキャッシュメモリは速いのか」が話題になりました。
この質問に答えるのはなかなか難しく、X（Twitter）ではいろいろな回答がされていました。この回答はさまざまな立場・理解からされていて、Xのタイムラインをご覧になっていた方はいまいちしっくりこなかったのではないでしょうか。

このトークでは「なぜキャッシュメモリは速いのか」に答えるのに必要な知識を、初心者の方にもわかりやすくご説明します。

• キャッシュメモリとは何か
• なぜキャッシュメモリを使用するのか
• キャッシュメモリとメインメモリは何が違うのか
• 結局なぜキャッシュメモリは速いのか

キャッシュの使いこなしは現代コンピュータにおいて避けることはできず、キャッシュを制するもののみがコンピュータを高速に動作させられると言っても過言ではない状態です。キャッシュを理解し、キャッシュを楽しみましょう！

これまでダッシュボード向けのWebAPIをPHPで設計・実装してきました。その中で、どのような方式を採用するべきか、どこで迷い、何を試し、なぜその形になったのか──実際のプロダクション開発を通じて得た知見を紹介します。

RESTやGraphQL、BFFなど方式の選択はもちろん、データの整形、責務の分離、フロントエンド側との関わりなど、実装中に直面した「悩み」やその対応、やむなく方向転換をしたことにも触れながら、WebAPI設計の話しをします。

「こんなふうにもできそうだけどどうだろう？」という話しも少しします。

話すこと(変更の可能性あり)
・ ダッシュボード向けWebAPIをどう作ってきたのか
・ なぜそのように作ってきたのか
・ こんなところで迷った
・ こんな方法でも作れそうと考えている

Eloquentのdelete()で想定外の全削除が発生した実体験。
複合プライマリーキー対応の限界と、安全な設計方法について解説。

Symfony 6系以降で登場した一連のDIアトリビュートは、サービス定義ファイルへの依存を減らし、依存注入をコードの近くに集約することができます。
本セッションでは、さまざまなアトリビュートを利用したDIについて紹介し、実務に役立つTIPSをコード付きでご紹介します。これらを戦略的に使いこなすことで、責務分離、リファクタリング・テストの自由度が劇的に向上します。初めてSymfonyを触る方やまだ試したことのない方も、SymfonyのDIを“制御できる”実践的な20分をお届けします。

LaravelのFacadeは、簡潔な記述で機能を呼び出せる便利な仕組みですが、「静的でテストしづらい」「依存関係が見えづらい」といった理由から敬遠されることもあります。しかし、目的やスコープを明確にした上で戦略的に活用すれば、開発やリファクタリングの助けとなる強力なツールにもなります。本セッションでは、Facadeを使って開発やリファクタリングを効率的に進める手法を紹介します。日常の開発でのFacade活用について考えていきます。

「もっとアウトカムに向き合おう」
そんな声をよく耳にするようになりました。
ユーザーに届く価値、ビジネスインパクト、意味のある成果。どれも間違いなく大切です。
でも、ふと立ち止まって考えたとき、こんな問いが浮かびました。
「私たちは、そもそも安定してアウトプットできる状態にあるんだっけ？」と。

このセッションでは、アウトカムを意識する前に私たちがやってきた、チームの土台づくりについて紹介します。
アウトプットの可視化、専門領域を越えて協力し合えるチーム構造、Slackのハドルや朝会の工夫によるコミュニケーションの改善など、地味だけど確実に効いた取り組みを中心にお話しします。

派手な成果や成功事例ではありませんが、足元を固めることで初めてアウトカムに届くようになった、そんなリアルな試行錯誤を持ち帰ってもらえたら嬉しいです。