あなたは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 原則、完全に理解したけど実践できていないよ、って人

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

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

お話しすること

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

私が主宰するカンファレンスではSNSアイコンが印刷された名札をご用意しています。
この名札は「バリアブル印刷」といって印刷所に「このIllustratorデータをテンプレートにしてココにアイコンをココに名前を入れて下さい」的にお願いして作っていますが、なかなかツラく時間がかかる作業です。

今年3月に開催されたPHPerKaigi 2024ではカンファレンス運営支援ツールforteeに名札生成機能を実装し、印刷所への依頼から作業完了までの日数を3営業日まで縮めることができました。

このトークでは印刷所に入稿できる名札データをPHPでいかにして作るかをお話しします。透明色入りPDFデータ、CMYK変換、フォント埋込など、泥臭く手探りの世界でどう苦しみ、どう解決したかをお楽しみください。

このセッションでは、FrankenPHPにおけるPHPの稼働方法とその高速性の理由について解説します。以下のポイントを中心に進めます。

• FrankenPHPの概要: FrankenPHPの基本構造と仕組みを説明し、他のPHPランタイムと比較してどのように異なるかを紹介します。
• PHPの稼働メカニズム: FrankenPHPでPHPがどのように実行されるか、そのプロセスフローを詳述します。
• 高速性の理由: FrankenPHPが高速である理由を技術的な観点から解説します。

対象者

• 高速なPHP実行環境を求めている方
• ウェブアプリケーションのパフォーマンス最適化に関心がある方
• FrankenPHPに関心がある方

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

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

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

話すこと

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

対象者

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

『自分がJOINしたチームで障害がよく起きていてチームが大変そうにしているときにどうしますか？』

私の場合はサービス監視・オブザーバビリティがこのチームに必要なことだと考え推進してきました。
そしてその結果、障害は減りチームは機能開発も安定して行える状態になることができました。

このトークでは、

• どのようにサービス監視・オブザーバビリティを推進したか
• オブザーバビリティを通してのチームリード
  についてお話します。

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

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

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

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

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

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

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

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

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

話すこと

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

小さくコツコツ手をつけておけばよかった…そんな気持ちになることもあるかもしれません。。
日々降ってくる、マイナーバージョン・パッチバージョンの更新を適応するのはとても大事です。

メジャーバージョンがあった場合はどうでしょう？？
依存パッケージ間の依存関係があるなど、マイナーバージョン・パッチバージョンの更新と比較して、複数のパッケージの同時更新が必要だったりもします。

・composer updateのおさらい
・composer updateで何ができるのか？何が起こるのか？
・パッケージ更新のはまりポイント
・コツコツパッケージを更新していくために…

パッケージを更新するコマンドであるcomposer updateを軸に、日々のパッケージ更新のヒントとなるポイントをお伝えできればと思います！

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

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

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

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

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

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

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