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

データプロバイダーは、1つのテストメソッドを引数を変えて実行する「パラメタライズドテスト」を実現する仕組みです。
PHPUnit 9までなら@dataProvider、10以降なら#[DataProvider]を使うことが多いですが、実はそれだけではないんです。

このトークでは、データプロバイダーを実現する複数の方法を紹介し、それらのメリット・デメリットを考えます。

お話しすること

• データプロバイダーとは何か、それを使う利点
• PHPUnitにおけるデータプロバイダーの実現方法
• 各方法のメリット・デメリット、使い分け方

想定する観客

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

35歳をとっくの昔に過ぎ去った私は、今も変わらずソフトウェアエンジニアとして働いています。
若いころに読み、影響を受けた「情熱プログラマー」の著者ようには、決してなれていませんが、そんな私の仕事への向き合い方を皆さんにシェアし、何か持ち帰っていただければ幸いです。

主な内容

• 文系出身でエンジニアのキャリアを始めた時の焦燥感
• マネジメント職に転身した時に見えた景色
• 地方からみたメガベンチャー企業の世界
• 現在のソフトウェアエンジニアリングへの向き合い方

「なんかこのページ、表示が遅く感じるなあ。速くしたいなあ。」
と感じた経験がある方は多いのではないでしょうか？

しかしながら、いわゆる「チューニング」は各分野の専門家の方が日夜研究しておられる分野です。
サービスの規模・構成等によって目標・対処方法も大きく異なり、
「これをやれば高速になるテク」
をそのまま適用して「おっしゃ解決！」というのは難しいことも多いかと思います。

インフラ・フロントエンド・バックエンドと（強引に）分野を区切ったとして

• どこで
• どのような問題を
• どの程度
• どうやって解決するか？

の判断も難しいかと思います。

このトークでは、昔ながらの構成のWebアプリケーションにおいて
私の実体験から、「表示速度改善取り組む前に知っておくと良さそうな話」をしたいと思います。

このトークが各分野の専門的な内容を学んでいく足がかりになればいいなと考えています。

登壇をする内容の概要
プロダクト開発を成功させるには、重要な機能にリソースを集中させることが不可欠です。重要な機能にフォーカスすることで、最大の価値と競合差別化を生み出せます。
一方で、重要でない機能を含む全体的なリファクタリングや、コードベースの保守性向上だけでは、こうした成果は得られません。
この登壇では、重要な機能についての考え方とLaコストをかけない機能の実装方法も提示します。

話を聞いた人に持ちかえってほしいこと
聞いた人には、プロダクトの機能を再評価し、リソース配分の優先順位を考え直すきっかけにしてほしいです。また、その考え方をチームで共有し、ディスカッションを通じて話し合う機会を持っていただきたいです。

主な内容

プロダクトの価値を考える必要性
どのように優先することを決めるか

同様のタイトルの30分との違い
こちらでは実際のコード例を省きます

変更に強いユニットテストの設計と実装について、実践的なアプローチについてはなします。
多くの開発現場で課題となっているテストコードのメンテナンス性やどのようなテストを書いたほうがいいかを具体的に解説します。

同様のタイトルの15分版となります
話すトピックの数を減らしています

主なトピック:
ユニットテストの本質的な目的の再考
メンテナンス性を重視したテスト設計の考え方
具体的なテストコード作成の指針

クリーンアーキテクチャをベースにした開発においては、レイヤー構成やフレームワーク（FW）の利用方針をどのように棲み分けるか課題に感じる事があるかと思います。
FWの利便性を活かしつつも、ピュアな設計原則を守るためには、どこで柔軟に対応し、どこで堅実に守るかのバランスが求められます。

本セッションでは、私たちの実体験に基づき、具体的な構成やその判断基準をご紹介します。特にドメインモデルの保護を主眼に置き、FWの力を有効に活用しながらもクリーンアーキテクチャの原則に則った構成の実現方法と、現時点で私たちが感じている課題についてご紹介します。

私たちもまだ道半ばで伸びしろがあると思って居ますので是非、質疑応答やAsk The Speakerにて意見交換も出来ればと思います！

Laravelのoptional()関数を使ったことはあるでしょうか？
Nullである可能性のあるオブジェクトに対してoptional関数を用いることで、Nullでない時はオブジェクトの動きをさせ、Nullの時はnullを返させることができるようになります。

optional関数を使って実装していたある日、ふと「どのようにして動いているのか」が気になりました。
調べてみると、Null Objectパターンというものを使って実装されていることがわかりました。

このトークでは、簡単なNullオブジェクトを自作することで、optionalがどのように実現されているのかを見ていきます。

話すこと

• optional関数の説明
• Null Object Patternの実装方法
• Nullsafe operatorとの比較

みなさん、PHPのテストを書くときに「他のクラスや依存関係のせいでテストが難しいな…」と思ったことはありませんか？
そんなときに役立つのが、PHPのモックフレームワーク Mockery です！

Mockeryを使えば、依存するクラスやインターフェースの動作をモックして、テストをもっとシンプルに、効率的に進められます。このトークでは、Mockeryの基本的な使い方から実際の業務で役立つテストケースまで、具体例を交えて解説します。

取り上げる予定の内容はこちら！

• モックを使ったメソッド呼び出しの検証方法
• 高度な引数の比較を使った柔軟なテスト
• 実務でのテストケースの実例紹介
• Mockeryを使えば、テストのストレスが軽減され、もっとスマートにテストが書けるようになります！ぜひ参加して、PHPのテストを楽にする方法を学んでください！

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

本トークでは、SOLID 原則に含まれる5つの原則について PHP のサンプルコードを交えながら解説し、その活用方法についてお話しします。

こんな人に向けて話します

• SOLID 原則？何それ知らないよ！って人
• SOLID 原則、聞いたことあるけどよくわからん、って人
• SOLID 原則、完全に理解したけど実践できていないよ、って人

ソフトウェア開発を行うエンジニアで「『技術的負債』という言葉を知らない」という方は今日においてほとんどいないと思います。その一方で「技術的負債とは何か」を正しく理解し、自信を持って説明できる人はあまり多くないように思います。その相手が非エンジニアであればなおさらです。

このトークを通じて、技術的負債についての理解を深めるお手伝いができればと思います。

お話しすること

• 技術的負債とはなにか
• 技術的負債はいつ・どうして生まれるのか
• 技術的負債を放置することで発生するビジネス面・技術面でのリスクとは
• 技術的負債とどう付き合っていくべきか

画面開発で、こんなお悩みを抱えていませんか？

• デザインに統一感がない
• デザインレビューの観点が曖昧
• ゼロからデザイン制作とコーディングが必要
• CSSの保守が難しい

これらの課題が原因で開発効率が低下しモチベーションも低下してしまいました。その解決策の一手として、デザインシステムの導入を進めました。
今回は、すでに存在していたデザインリニューアルのデザイン案をベースに、プロダクトにデザインシステムをうまく反映できていなかった状況から、仕組みを整備して導入を進めるまでの一連の取り組みをお話します。

話すこと

• デザインシステムとは
• 導入に向けての取り組み
• 導入前の課題、導入後の効果
• 導入が進まなかった要因・進んだ要因

対象者

• 画面開発にお疲れぎみの人
• フロントエンドのレガシーな構成にお悩みの人
• デザインシステムに興味がある人

我々はのチームはつい最近結成されたら新チームです。チームも未熟でありながら何を作るかも決まっていませんでした。
そんなチームが顧客の要望に応えたい気持ちはあるものの人手も多いわけではないのでできることは限られます。

しかしこのチームが爆速にプロダクト開発をしています。
どんどん動くものができており、スプリントを進めるたびに機能は増えていき、スプリントレビューで改善のフィードバックをもらっています。

どのように開発を進めているのか、意識していること、テクニック、秘訣を教えます！

プロダクトにバージョン番号ってつけていますか？
どのバージョンで不具合が起きたかなど、バージョン番号をつけておくと運用や開発管理がしやすくなります。

もちろん、われわれもバージョン管理を行なっています。
しかし、セマンティックバージョニングを導入したために、思ってもいない困難が待ち受けていました。

このセッションでは、セマンティックバージョニングから脱却するために行った、『バージョン管理のリファクタリング』について、行なったことやビフォーアフターについてご紹介していきます。

DIを理解するのは難しいです。

経験の少ない開発者にとっては、コードが読みづらく感じて開発を遅くする原因となり、ベテランにとっても、メンバへの伝え方が難しいために導入を見送らざるを得ないということもあるかもしれません。

このトークでは、依存という概念を「使う・使われる」という、簡単な言葉で整理して、理解しやすくすることを目標とします。

話すこと

• 「依存している」とは「使っている」ということ
• 依存すると何が困るのか
• 依存を外から与える(注入する)メリット

苦労してソフトウェアを開発したのに使ってもらえなかったことや、リリースしてから致命的な問題に気づき作り直しが必要になったことはありませんか？

ソフトウェア開発プロジェクトの失敗のうち、要件定義における失敗が原因である場合は4割にも上るという報告もあります。アジャイル開発のような適応を重視する開発アプローチを採用していても、要求を獲得し分析することの重要性は変わりません。

そこで本トークでは、「要求工学」と呼ばれる分野から、ソフトウェアに求める振る舞いを定義し記述するための以下の知見を紹介します。
・要求工学を実践するプロセス
・利害関係者を明らかにする分析法
・現状を分析し課題を明らかにする手法
・要求を抽出するための手法
加えて、発表者が実際の開発案件にそれら手法を適用して得た学びを共有します。

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

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

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

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

私たち開発者にとってログは非常に重要です。
開発時のデバッグやローンチ後の障害解析など、ログを出力していることで救われたシーンは多かれ少なかれあるのではないでしょうか？

そんな私たちを助けてくれるログですが、Laravelでは様々な設定やカスタマイズが可能です。
しかしどのような設定ができるのか理解するところまで手が回らず、デフォルトのまま運用してそのままという悲しいシーンを見ることも多々あります。

このトークでは実際にログ出力する際にLaravelのLogManagerがどのような処理を行なってログを出力するのか、各設定の詳細、Laravel10より追加されているLaravelPailを用いたログの限定出力のやり方等をお話ししますので、今後のログ運用の助けになれば幸いです！

新しいプロダクト開発は失敗が避けられませんが、リスクやコストを最小限に抑えてメンバーが納得する規模でリリースすることで、失敗する恐怖を抑えることはできます。
本セッションでは、ユーザーストーリーマッピングを活用し、『安価に失敗する』ためのプロダクト開発の進め方についてご紹介します。
実際にリリースしたプロジェクトを事例に、どのようにプロダクト開発を進めていったかお伝えします。

新しく加入したメンバーの皆さん、チームに馴染めていますか？
新しいメンバーを迎えた皆さん、メンバーに馴染めてもらえていますか？

一説によるとWebエンジニアの平均在籍年数はおよそ3〜4年だそうです
ということは、最初の半年〜1年である程度新しいメンバーを戦力化できないと、エージェントに支払う費用などを考えると企業としてはよくてトントン、悪いとマイナスになってしまいます

このトークでは「馴染む速さ」に定評のあるいち個人が最近の転職で経験した

• 「オンボーディングされる側」として意識していたことでうまくいったこと
• 自分が組織に馴染む速さを支えてくれた会社の文化
• 上記を２つを支えていると感じた社内の仕組み

についてお話させていただきます。

採用する側、される側双方にとってのヒントになれば幸いです

皆さんは『プロダクト開発者』と聞くと開発者をイメージをしますか？
『プロダクト開発者』と従来の『ソフトウェア開発者／エンジニア』の違いは説明できますか？
（これはおそらく一定答えられる人がいると思います）

あるいは『GLAD開発者』という語彙を聞いたことがありますか？
（おそらく聞いたことある人は日本ではほとんどいないと思います）

この新しい語彙はどのような開発者像を指すのでしょうか？
また、それは従来の『プロダクト開発者』や『ソフトウェア開発者』と何が違うのでしょうか？

このトークでは先日私が衝撃を受けるとともに、長い事悩んでいた

• 専門性を高めるべきか？それとも他の道を探るべきか？
• そもそも21世紀の開発者はどうあるべきなのか？

といった問いに対する一つの回答例となった（と感じた）アイディアを共有します