トーク

6年間運用したPHP製テレビCM分析管理画面で、ストレージとデータ構造の限界から大規模刷新を決断。この機会に、アプリケーション全層の型安全性も確立する統合的リアーキテクチャを実行した事例を紹介します。
きっかけはストレージのスケーラビリティ問題でしたが、管理画面特有の複雑なビジネスロジックにおいて、各層での型の曖昧さが顕在化していました。インフラ刷新と同期させることでリスクを最小化しつつ、gRPC-Connect+静的型付け言語への完全リアーキテクチャを実現しました。
本トークでは、インフラ起点で全体を巻き込む意思決定プロセス、リアーキテクチャの設計と実行、各層での型問題の具体的な解決例、DIを活用したテスタビリティ向上について、実コードとともに解説します。管理画面システムの統合的リアーキテクチャの実践知をお届けします。
話すこと: 実践的な移行プロセス、型とDIによる品質向上の具体例

皆さんは機能を作成する際に、何から始めますか。

私は情報設計に取り組むチームに所属しており、日々情報設計と向き合っています。
情報設計とは、Web に限らず情報の整理が必要なあらゆる場面で活用できる普遍的な設計の考え方で、受け手が望んだ情報を適切に与える方法を作ることです。

先日、私たちは概念オブジェクト（ユーザーがイメージする「写真」や「メール」のような対象物）を発見し、Slack ワークフローを作成するワークショップを主催しました。

ワークショップでは「なに が なに を どうする」という構文から概念オブジェクトを発見しました。発見された概念オブジェクトは開発者以外にも伝わる共通言語となりました。

本トークでは、ワークショップでおこなった誰にでも分かりやすい概念オブジェクトの発見の方法から、PHP のコードがどのように現れるかを考察しどのような恩恵が得られるのかをお話します。

テレビCMを軸にマーケティング分析プラットフォームを開発する株式会社テレシーで、Laravel Novaは6年間、私たちの事業成長を支え続けてくれました。管理画面の爆速開発を実現し、今の事業スピードを可能にしてくれたのはNovaのおかげです。なぜNovaを選んだのか、どのように事業にインパクトを与えたのか、そしてなぜ今、別れを決意したのか。
本トークでは、Laravel Novaの強みと適用領域、運用で見えてきた限界点、そして「卒業」のタイミングの見極め方を、実際のコードと共にお話しします。さらに、次の技術への移行で採用した仕様書駆動開発のアプローチもご紹介。
Laravel Novaは適材適所で本当に輝く技術です。これから導入を検討している方には最適な活用シーンを、すでに運用中の方には「卒業」のタイミングを見極めるヒントをお届けします。6年間の感謝を込めてお話させて頂きます。

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

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

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

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

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

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

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

プログラミングにおける "関数" は 数学の写像とは同じではないものの、一部似た性質を持っています。
数学における写像は集合と密接に関係しており、それらは関数と型に対応します。

集合なしには写像は定義できず、プログラミングでも型なくして関数は定義できないと言っても過言ではありません。
しかし、PHPのような型の宣言を省略できる言語では、型の理解というのは往々にして後回しになることがあります。

本発表ではプログラミングにおける型や関数を、集合と写像によるメンタルモデルで捉える方法について解説し、 PHPのための設計に落とし込む方法を説明します。

お話したいこと

• 数学における素朴集合論と写像
• 写像とプログラミングの関数の違い
• 集合を使ったモデリングと型のメンタルモデル
• PHPアプリケーションの設計への落とし込みと他言語との比較

お話ししないこと

• 圏論

ありがとうPHPカンファレンス福岡！

私が体験したPHPカンファレンスで得たことをとりあえず叫ばせてください

こんなことを話します

• PHPerじゃなくてもPHPカンファレンスに登壇していいんだ！ PHPカンファレンス福岡のおかげ！
• Testerでもテストの話以外を話していいんだ！ PHPカンファレンス福岡のおかげ！
  -社外のエンジニアに知り合えた！ PHPカンファレンス福岡のおかげ！
  -社外のエンジニア以外の人にも知り合えた！ PHPカンファレンス福岡のおかげ！
  -プロポーザルはとにかく出しちゃえの気持ちになれた！ PHPカンファレンス福岡のおかげ！
• 働きたい会社に転職できた！ PHPカンファレンス福岡のおかげ！

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

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

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

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

標準機能にするのか個別の機能にするのか
個別機能開発をする際にどのように作るのか
リファクタリングをいつ行うか
このトークを通じて、プロダクトの今と将来を両立するための考え方の一例を提案したいと思います。

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

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

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

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

PHPに限らず我々はフレームワークを使って開発を行うことが多いです。一方であえてフレームワークを使わず開発することもあるでしょう。

フレームワーク、便利ですが便利すぎるが故に「なんとなくコードを書いてる感」を自分は感じます。また、フレームワークをそのまま使わず自分たちでカスタマイズ(ライブラリを組み込む、フレームワークの1部だけ使う)する場合は 「なぜこれが今動いているのか」を理解できないとうまくカスタマイズできません。

いわゆる「よくわからんけど動いてる」を少しでも無くし、これまで以上に自分たちがフレームワークやライブラリを使いこなすために何ができるのかを自分の視点で紹介します。PHPに限らず他の言語にも応用できるような紹介を目指します。

話すこと(変更の可能性あり)
・ 今回の話をする経緯
・ 原理を理解するために自分がしていること
・ 「車輪の再開発」という言葉に対する持論

ソフトウェア開発の現場では、短いサイクルで継続的に学習する仕組みとしてスクラムが広く採用されています。
しかし、直近で担当した納期必達のPJでは、コミュニケーションコストを削減するためにスクラムイベントをすべて取りやめる決断を下しました。
このPJは無事に納期を守り、大成功で終わりましたが、後続の追加開発プロジェクトでは、スクラムイベントの廃止により課題共有の不足や、チームの一体感の低下などの問題を経験をしました。
そこで、課題を発見するたびにスクラムイベントを一つずつ再導入した結果、チーム連携が向上し、課題解決も円滑に進むようになりました。
本セッションでは、スクラムイベントの廃止によって発生した具体的な問題と、それらをスクラムイベントがどのように解消していったかをご紹介します。
日頃当たり前のように行っているスクラムイベントが持つ価値を改めて実感してもらえるようなトークをします

新卒でエンジニアとして働き始めてから、タスクの取りかかり方や進め方で度々つまづきました。
知識やスキルといった技術面だけでなく、「どこから手をつければ効率的か」「わからないことをどう相談すればいいのか」といった小さな判断に迷い、手が止まってしまう場面も多くありました。

このセッションでは、そんな“タスク詰まり”を感じたときに私が実践してきた、

・タスクの進め方を整理するちょっとした工夫
・周囲とスムーズに相談・連携するための意識の持ち方

など、日々の業務の中で培ったTipsをお話しします。

これからエンジニアとして経験を積んでいく若手・新人の方はもちろん、
後輩を支える立場の方々にも、現場の小さなつまずきに気づくきっかけやヒントを持ち帰っていただけたら嬉しいです。

GitHubには多くの便利な機能があると知りつつも、 「結局どれを使えばいいのか分からない」 「CI/CDやAI活用をどう始めればいいか迷っている」 と感じている方は多いのではないでしょうか。
開発のスピードと品質を高めるActions、Codespaces、Copilotなどの機能は、単体で使うだけでなく、DevOpsの実践やチーム開発の改善にもつながります。

本セッションでは、GitHubを使っている・これから活用したい開発者を対象に、私が実践しているGitHubの活用方法を30分で紹介します。
10月にはGitHubの年次カンファレンスである「GitHub Universe」に参加予定ですので、カンファレンスの様子も交えてお話しする予定です。

きっかけなんて、なんだっていい

私がPHPを始めた理由。それは「象がかわいかったから」でした。そう、PHPのマスコット“ElePHPant”に心を撃ち抜かれたんです。

「なぜゾウなのか？」と調べていくうちに、PHPという言語の特徴にも、その姿勢にも、ゾウのようなおおらかさや包容力を感じました。そして気づけば、私はPHPを書くようになっていました。

このLTでは、ゾウに惚れてPHPを始めたちょっと恥ずかしい話とともに、「始める理由は人それぞれでいいんだよ」というメッセージをお届けします。
誰かが明日、ゾウに惹かれてPHPを始めてくれたら、それだけで嬉しいです。

対象者

• 初学者や、これからPHPを始めようとしている人
• ベテランだけど改めてPHPへの愛を再確認したい人
• 技術的な話にちょっと疲れて、ほっとしたい人
• ゾウが好きな人

コードの自動修正を行うツール、Rector。提供される修正ルールは700超！
大量で多様なルールに対応する裏には、高い拡張性を実現する「良い設計」があります

中核的なコンセプトの1つは、対象コードを抽象構文木として扱うことです。 そして、各ルールはVisitorパターンで適用されます
──ツリーに対してVisitor。美しく王道的なアプローチの魅力を、一緒に覗いてみましょう

• 目的
  • 普及しているOSSという実践的な例から、Visitorの概要と効果について学ぶ
• 対象
  • これからデザパタやVisitorパターンを身に付けたい
  • Rectorやカスタマイズに興味がある
• 話すこと
  • Rectorの概要
  • ルールを自作して基礎を掴む
  • Visitorパターンの概要、使われ方

与えられたテキストを文法に則って解析し、別の構造へと変換するのが、構文解析器(パーサー)です
独自のPHP製パーサーを生成する、PHP-Yaccをご存知ですか？
文法を定義するための記法(BNF)を使い、本格的なパーサーを生み出すものです
有名どころでは、nikic/php-parserにも利用されています

本トークは、「JSONをPHPのデータに変換する」をお題に
自作パーサー開発の入門レベルの解説を行います
どんな風に作るの？どんなコードができるの？を味わいましょう

これを聞いたら、次はあなたが自作パーサーに入門する番です！

話すこと

• パーサージェネレーターを使ってみる
• 文法の定義(.yファイルを書く)

話さないこと

• レキサー、パーサーの詳細なアルゴリズム、実装パターン

技術コミュニティへの参加は、エンジニアにとって学びや刺激を得る貴重な機会です。
しかし、様々な制約がある中で「どこまで集中して参加できるか分からない」という不安から、足が遠のいてしまうこともあるのではないでしょうか。

先日子連れでPHPカンファレンスJapanに参加した体験では、参加者・スタッフの皆さんの温かい配慮に支えられ「全力で参加できなくても、コミュニティとの小さな繋がりがエンジニアのモチベーションを支えてくれる」ことを実感しました。
あまりセッションを聴けなくてもブースでの何気ない会話から仕事のヒントが得られたり、同世代・若い世代のエンジニアのアウトプットに刺激を受けたりと、予想以上の収穫がありました。

実際の参加体験から得た気づきや感謝、そして参加後の変化までをお話する予定です。
同じように「全力のコミュニティ参加」を迷っている方の背中を押すきっかけになれば幸いです。

「やる気が出ない。でも何かしなきゃ。」
そんな焦りに飲み込まれていた自分が、少しだけラクになれた経験をお話しします。

仕事での責務が増えてアウトプットが止まり、アウトプットするネタも浮かばず、周りがどんどんアウトプットしているのに自分だけが取り残されているように感じて、焦っていた時期がありました。
そこで私は、無理に動かず“できる範囲だけ続ける”ことを選びました。

このセッションでは、私が試してきた工夫や気づき、そして“やる気がない前提でどう設計するか”についてお話します。
やる気が出ないことにモヤモヤしている方、立ち止まっている自分に不安を感じている方へ、エンジニアとして長く続けていくための“ペースのつくり方”の一例として、少しでもヒントになれば嬉しいです。

カンファレンスに行き始めた頃、「カンファレンスの歩き方」に迷っている自分がいました。
セッションを通じて学ぶことが多く、満足はしていたものの、どこか聞いて終わりで完結してしまっている感覚がありました。

そんな中で、あるカンファレンスの懇親会に参加したことをきっかけに、一気に世界が広がりました。
登壇者からセッションでは語られなかった裏話を聞いたり、遠い存在に感じていた人たちと気軽に話ができたり、自分の悩みを相談できたり、参加することで得られるリターンの質が大きく変わったのを感じました。

このセッションでは、自分の中でカンファレンスの価値が「学ぶ場」から「つながる場」へと広がっていった体験をもとに、ちょっとした行動で変わる景色についてお話しします。
初参加の方や、踏み込みきれていない感覚を持っている方に届いてほしいなと思っています。

プロジェクトやプロダクトのマネジメントにおいて特に難しいのはステークホルダーやチーム外でのコミュニケーションだと思います。
マネジメントにおいてこういう課題に出会ったことはないですか？

• ビジネスから後から差し込まれ続ける要件
• プロジェクト/プロダクトを進めたい方向に進めようとしてもビジネスや外部のステークホルダーが納得しない
• 外部パートナーにお願いしたのに動いてくれない

これらの課題に対して1つ1つ向き合って解決していくための考え方と進め方について話します。

話すこと

• プロジェクトを進めたい方向に向かわせるためにステークホルダーとどう対話していくか
• プロジェクト/プロダクトの中で自分たちのコントローラビリティをどう高めていくか

話さないこと

• プロジェクト/プロダクトの具体的なチケット管理の仕方
• プロジェクトチーム内のピープルマネジメント