プロポーザル

プロジェクトが炎上してしまった…
納期に間に合わない…
あとから仕様の観点漏れに気がついた…

開発をしていればこういうことに直面することがあるかと思います。

どのような行い、マインドセットがプロジェクトに悪影響を及ぼすか、
過去に自分が経験したことを皆様に懺悔することで、
後学に活かせればよいと考えている次第です。

2024 年はどんな 1 年でしたか？
　
日本 PHP 界隈だと，各地で開かれた地域 PHP カンファレンスの印象が強いのではないでしょうか．
様々な背景の人たちが各地に足を運び，配信を見て，コンテンツを持ち寄り，運営をし......
それぞれの形で「貢献したい気持ち」を表現した 1 年でした．
2025 年もその勢いは変わらず，この名古屋開催につながっていると感じます．
　
多くの地域に PHP の名を冠した活動があれば，日常的に PHP に触らない人も PHP コミュニティに関わってきます．
かく言う私もその一人です．大前提として PHP は OSS であり PHP 自体の発展には PHP 自体の改善や利用拡大が不可欠です．
これらが主だと知りながら，その外から関わっています．
　
そんな私が PHP コミュニティに「貢献したい気持ち」を繋げるべく，どう考え，動いているかを話します．

あなたはPHPUnitを使っていますか？では、データプロバイダーは？

データプロバイダーは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
PHPUnit 10以降ではアトリビュートを使って実装しますが、そのときに使えるアトリビュートはなんと4種類もあります！

このLTでは、これら4つのアトリビュートを紹介するとともに、どう使い分ければいいのか考えていきます。

お話しすること

• データプロバイダーとは何か
• データプロバイダーを使う利点
• PHPUnitにおけるデータプロバイダーの実現方法
• 実現方法の使い分け方

想定する観客

• PHPUnitを使っているがデータプロバイダーを知らない人
• #[DataProvider]か@dataProviderしか知らない人

SOLID 原則は、ソフトウェア開発において高品質で保守性の高いコードを書くための重要なガイドラインですが、やたら難しい言葉が並んでいて理解が難しかったり、誤解に基づく理解が広まってしまっている面があります。

本 LT では、SOLID 原則に含まれる5つの原則について5分間で語り、日々の開発に役立てるきっかけになることを目標にしています。

私は業務でPHPに触れていますが、もともとはLispやRubyといった動的言語を好んで使っていました。
一方で私は近年はPHPStanといった静的型検査に力を入れていて、PHP界隈では型にこだわりがある人間のように振る舞っています。

プライベートではPHPStanにプルリクエストを送る一方、長年Emacs PHP Modeというソフトウェアのメイン開発者としてメンテナンスを続けています。

名古屋といえば関数型。なぜ私がまったく異なる特徴の複数のコミュニティで活動しているのか、プログラミング言語、関数型言語、型への想いを騙ります。

2024 年，各地で PHP カンファレンスが開かれ，2025 年の下準備として PHP 勉強会を小規模に開催する都市もありました．しかし，小さな街で開く PHP に対象を絞った勉強会では，十分に人が集まらず，存続不能になってしまうことも少なくありません．
　
第一に守るべきは PHPer リーチャブルな空間をつくることです．勉強会の形式やテーマを絞っている場合ではありません．PHPer と会えて，話ができ，情報交換できることが肝要です．Slack こそありますが，情報を欲する全員がそこに自力で到達できるわけではありません．そこに連れていく PHPer が必要なのです．
　
そこで，ここに来たみなさんが日本の 1,724 市町村※のどこにいても技術系勉強会が開けるよう，そして維持できるよう，どんな小さな街でも勉強会を続けられる最小のノウハウをお話します．
　
※ 北方領土の 6 村を含める

このセッションではPHPで作成したアプリケーションをVercelにデプロイする方法を紹介します。

Vercelは「Vercel のフロントエンド クラウドは、開発者にフレームワーク、ワークフロー、インフラストラクチャを提供し、より高速でパーソナライズされた Web を構築します。」(X：@vercelより引用)で、PHPのイメージはありませんが、PHPのアプリケーションをデプロイすることができます。

また、VercelにはVercel PostgresというPostgreSQL(データベース)を提供するサービスもあります。PHPとVercel Postgresを用いてアプリケーションを作成し、Vercelで公開することができます。

このセッションでは、VerceでPHPを用いたアプロケーションを公開する方法とVercel Postgreの紹介をします。

このセッションでは、iOSデバイス上でPHP開発環境を効率的に構築するためのベストプラクティスを紹介します。以下のポイントを中心に話します。

•主要ツールとアプリ: iOSで利用可能なPHP開発向けのエディタ、SSHクライアント、データベース管理ツールの紹介
•設定方法: PHP開発環境の基本設定手順と必要なアプリのインストール方法
•リモート開発環境: リモートサーバーに接続する方法、VPNやSSHを使った開発ワークフローの構築
•実践的なテクニック: 効率的な作業を支えるテクニックやトラブルシューティングの方法
•コンテナ技術: Dockerなどを利用した仮想的なPHP開発環境の構築方法

対象者

•WebアプリケーションやAPIを開発している
•ノートPCなしでiOSデバイスを使いたい
•オフィス外での開発環境を最適化したい

背景
あるプロジェクトでたくさんの障害を発生させてしまった。。。
障害はユーザーに迷惑をかけてしまうし、エンジニアのメンタルが削られるし、進行中のスケジュールを圧迫する。全然いいことがない。障害はこの世から無くなって欲しい。せめて減らしたい。。。
そんな思いから開発プロセスを見直す動きが社内で生まれました。

本LTでは障害予防のために実際にチームで実施している取り組みやどんなテスト観点表を利用しているのか紹介します。

障害を少しでも減らしたい、自分のチームに見合ったプロセスをカスタマイズしたいと同じ悩みを抱えているPHPerの皆さんにお伝えできれば幸いです！

チームが納得感を持つことで、自然にモチベーションが上がり、協力が深まります。
本LTでは、ファシリテーションを通してチームの合意形成をスムーズにし、全員が納得して前に進めるためのコツや心がけていることを紹介します。
意見を引き出すタイミングや、雰囲気作りの工夫など、誰でもすぐに実践できる方法をお伝えします。

こんな人におすすめ
・チームでファシリする機会が多い人
・ファシリに苦手意識がある人

「いや〜、思ってた以上に時間かかっちゃいました...」
こんな報告、したことありませんか？ 私は何度もあります。でも、これって「見積もりが下手」なんじゃなくて、「自分の実力の解像度が低い」だけかもしれません。
このセッションでは、野球選手が素振りで体の動きを意識するように、タスクと自分の実力の解像度を上げるための反復練習法を紹介します。

おしながき

• タスクを細かく分解して実力との距離を「見える化」する方法
• 実際にかかった時間を計測・記録するコツ、記録表テンプレート例
• 見積もりとの時間のギャップが生まれた理由を掘り下げる視点
• その気づきを次のタスク分解に活かすサイクル

「見積もりが外れる→反省する」で終わらせず、「なぜ外れたか」を深掘りして次に活かす具体的な方法をお伝えします。地道だけど、確実に成長できる練習方法を一緒に考えましょう！

？？？「わかりました！頑張ります！！」
？？？「頑張らなくて良いんで結果出してもろて」

こんなやりとりがあった際にふと気がつくとわたしの心の中には「逃げ」の気持ちがあるなぁということに気付きました。

「頑張ります」って答える時って、なんとなくコンフォートゾーンから出るような、自分の中でパッと想像できないような類のなにかをお願いされた場合が多いです。

そしてもう、みなさん頑張ってます！！間違いなく！！！

なのであえての「頑張る」の宣言は不要で、求められた結果やアウトプットに対してどう考えるか？をより意識するようになりました。

当然、ある時点で不安なことに対して対処するのは重い気持ちにもなりますが、そのような事象に対する意識の向け方、コンフォートゾーンと向き合うための考え方のひとつとしてわたしの体験をお伝えできたらと考えています。

複雑なプロダクトコード、"匂い"や"雰囲気"でリファクタリングしていませんか？

プロダクトコードの技術的負債の解消や保守性の向上のため取り組んでいるリファクタリングのその実際の効果をどれくらい測れていますか？

このLTでは、コードの複雑さを可視化・数値化できるPhpMetricsを使い、実際にコード改善した事例を紹介します！😆

PhpMetricsはcomposerで簡単に導入でき、クラスやメソッドごとの複雑度や、バグが出る可能性など、さまざまな指標を数値化してくれる便利なツールです。
数値に基づくリファクタリングで、より健全で保守しやすいプロダクトコードを目指していきましょう！💪

ご自身の「真ん中」にあるものって、なんですか？

PHPカンファレンス名古屋の中心に据えられている価値観を見て、ふと考えました。
https://phpcon.nagoya/2025/#about

自分は5年前から個人事業を始めたのですが、「真ん中」にあったのは、とある事業会社でのPHPプロダクト運用を回してきた、という経験だけでした。
でも、それを頼りに、新規プロダクト開発に業務委託で参画し、そこから自動テストや自動デプロイの導入や IaC化、さらに複業で幅を少しずつ広げ、「じぶん領域」はフルサイクルと言って良いかなと思えるくらいのなかなかの大きさになっていると思います。

このトークでは、類い稀な広がり方をした「じぶん領域」に関して、参考にしてほしい面と反面教師にしてほしい面をご紹介します。

わたしは十数年間この業界にいますが、いろいろなサービス層を見てきました。

• DB処理が大量に詰め込まれたサービス
• トランザクションスクリプトがひしめくサービス
• どこからでも誰からも呼ばれるサービス
• 複数のサービスと手を組み、仲良く連携するサービス
• ドメイン層を支えるサービス
• 周りに合わせてとりあえず作られたサービス

そこには、愛らしいサービスもあれば、目を背けたくなるサービスもいました。
そしてこう思うのです「人には人それぞれのサービス層がある」と。

当LTでは、こうした多様なサービス層にわたしの独断と偏見で名前をつけ、メリット・デメリットをかたっぱしから語ります。

WEBアプリケーションを安定的に運用する上で、考慮しなければいけない事が多くあります。
私たちのチームは、PHPアプリケーションをAWSクラウドインフラで運用しており、コスト削減とセキュリティ向上という課題に直面していました。

本セッションでは、これらの課題解決に向けての取り組みを、主に下記の内容についてお話します。
・コスト最適化のために検討したサービスや設定の変更点
・セキュリティを強化するための機能や具体的な設定方法

本セッションを通じて、明日から実践できる費用対効果の高い運用改善方法を見つけることができます。
普段クラウドインフラに関わる機会が少ない方でも運用への興味と関心が高まる機会になれば幸いです。

皆さん、どんなアーキテクチャで開発していますか？
私が最近参画した現場にはモジュラモノリスが導入されてから1年超開発が続けられているプロダクトがありました。
チームはモジュラモノリスならではの恩恵を受ける一方で、設計上の難しさや課題にも直面してきました。このトークでは、モジュラモノリスを体感してきたエンジニアたちから見た設計上の留意事項や課題ないし今後の展望を共有したいと思います。

※PHP製ではありませんが言語に依存する話は無いか少ない想定です。

皆さん、オンボーディングを実施してますか？
エンジニアの転職が盛んになってきた昨今、実施側ないし受ける側としてオンボーディングの経験を持つ人も多いのではないでしょうか。
実施側目線では、入社直前に準備でバタバタする、何度も同じ説明を繰り返したことがある、担当者の負担感が大きいなんて感じたことはありませんか？
受ける側目線では、インプットが多くメモが大変、取りこぼす、オンボーディングを消化して成果を出すまでに時間がかかり焦るなんてことがありませんか？
このトークでは、これまでにオンボーディングを受ける側、実施する側で助かったこと、ドキュメントの作り方や見聞きしてきたコツを思い出し、共有します。
新規参画者の早期戦力化のヒントになれば、あるいは、オンボーディングで助けられたハッピーな気持ち、あの時の初心を思い出し、カンファレンス明けのお仕事を”やっていき”な気持ちで迎えられたら幸いです！

皆さん、スプリントレビューを実施してますか？

• 興味があるんだけれどやり方がわからない。
• 周囲の共感が得られない（説得材料が欲しい）。
• やってるっぽいんだけど実はよくわかってない。
• やってるんだけど何か違う気がする、もっとうまくやりたい。
  など、悩みやモヤモヤがもしあれば是非話をさせて下さい！

私が所属するスタートアップでは週一でスクラムチームとステークホルダがレビューに参加するという運用を5年以上続けてきました。スクラムガイド、自社事例、他社公開情報を参照しつつ、スプリントレビューのやり方、コツ、現場が感じている価値をまとめてお届けします。
プロダクトの改善、アジャイル開発に興味がある方の参考になれば幸いです。

システムに何かあったとき、どのような通知手段をとっていますか？
私が現在関わっているシステムでは、slack通知するよう設定をしています。警告時、異常検知時、それぞれにあった通知を設計したつもりでした。
しかし、slack通知が多すぎて本当に必要なものが埋もれてしまったり、@channelだらけでミュートしたくてもできないチャンネルになってしまったり、実は通知が届いていたのに誰も対応できなかった、なんて事が発生してしまいました。
そんな状況を少しずつ改善していったアレコレをお伝えできればと思います。