トーク

主に非エンジニア、WEBディレクターや初心者向けのセッションです。

対象:
• WEBディレクター
• 企業などのWebサイト管理者
• PHPにこれから触れるかもしれない人

ゴール：
エンジニアとの要件定義の確認や、ベンダーとのやり取りが少しでもスムーズになれば、という思いで企画しています。

内容:
開発中にエンジニアへ「それ、どういう意味ですか？」と何度も聞いてしまい、やり取りが止まった経験はありませんか？
本セッションでは、非エンジニアであるWEBディレクターが、PHP開発に関わる上で“最低限知っておきたいPHP用語”を、現場でのすれ違いエピソードとあわせて、やさしくご紹介します。

IT業界の初心者や、これからWEB業界を目指す学生の方にも「話がわかる」「参加してよかった」と感じてもらえるよう、専門用語をできるだけかみくだいてお伝えします。

開発者と“共通言語”を持つことで、プロジェクトはもっとスムーズに、もっと楽しく。
そんなヒントをお届けできればと思います。

転職を機に新規でアプリケーションの実行環境を作ることになり、0から構築しました。もちろん今までに構築した環境をベースしましたが、セキュリティの向上という課題を踏まえて、
ここ数年話題に登ることが増えてきたDevOpsにセキュリティを意識した取り組みを組み込むDevSecOpsを意識して環境を構築しました。

新たな環境の構築に際してセキュリティを意識した自動化の取り組みをどのように組み込みつつ、効率的な開発プロセスを維持するために意識したことや、取り組みの具体的な方法と実践例をご紹介します。

引数をメソッドに渡すか、 __construct に渡すか......
どちらも機能しますが、本当に “どちらでも良い” のでしょうか？
動くのは間違いないですが、より「使いやすく」「保守しやすい」コードを目指すなら、最適な注入方法を選ぶ必要があります。
そこで、わたしの考える判断基準を具体例のコードに落としつつ紹介していきます。

• クラス設計・依存関係の整理
• テストの書きやすさ
• コードの可読性

また、このような話で一緒に出てくるのが依存性注入（DI）です。
具体例とともにあることでふんわり理解からじっくり理解にもっていきましょう。

このトークでは、実際のコード例を交えつつ、コンストラクタ注入とメソッド注入それぞれの判断基準を明確にしながら、DIの仕組みも合わせて紹介していきます！

みなさんはFour Keysでどのクラスタに属していますか？

Four KeysはDORA（DevOps Research and Assessment）が提唱している開発チームのパフォーマンス指標です。Four Keysではパフォーマンスに応じて、Elite・High・Medium・Lowの4つのクラスタのいずれかに分類されます。

サービス開発においてEliteクラスタに属していないと、ビジネス競争力が低下するリスクがあります。近年ではEliteクラスタに属した上で競争力を高めるためにさらなる取り組みをしていくのは一般的です。

私が所属する合同会社DMM.com 二次元コンテンツ事業が開発に携わっている二次元コンテンツ事業のPHP製ECサービスは現在「High」クラスタに位置しており、Eliteクラスタを目指してさまざまな取り組みを積極的に進めています。

本セッションでは、まだEliteクラスタに属していないチームが具体的にどのようなアプローチを取ればよいのか、実際の取り組み事例を交えてご紹介します。

アジェンダ（予定）：

• Four Keysとは
• なぜFour Keysを使うのか
• スループットと品質の相関
• ECサービスの現状と課題点
• Eliteクラスタへ移行するための取り組み
  • スループット改善への取り組み
  • 品質改善への取り組み
    • リファクタリングに向けた準備
      • FakerとTestcontainersを用いたモデルベーステスト
      • Qodanaを用いたPHPアプリケーションの静的解析

対象者：

• Four KeysのEliteクラスタ入りを目指す開発チームのリーダーやメンバー
• 開発チームのパフォーマンスを具体的に改善したい方

「設計ドキュメントは必要か？」
開発現場でたびたび持ち上がるこの議論に、正解はあるのでしょうか。

ドキュメントが少ないことでスピードが出るチームもあれば、丁寧な設計が結果的に開発効率を高めるチームもあります。

複数の開発チームを経験する中、チームトポロジーを読んで「ドキュメントの最適なあり方は、チームの特性に依存する」という気づきを得ました。

本トークでは、以下の観点から「チームごとに適したドキュメント管理の考え方」について具体的にお話しします。

• ドキュメントの必要性に関するよくある議論
• チームが扱うドメインの種類
• チームタイプによるアプローチの違い
• 実際のチームで実践しているドキュメント管理方法

設計やチーム運営に関わるエンジニアにとって、明日からの開発をより良くするヒントを持ち帰っていただける内容を目指します。

私が担当しているメール共有サービスのメールディーラーは2024年10月に「AIクレーム検知オプション」をリリースいたしました。

「AIクレーム検知オプション」の開発に当たり、メールディーラーの史上初となるβ版をコンテナで構築して、
お客様に実証実験ご協力をいただき、ChatGPTで判定しているクレーム検知の精度向上を行いました。
そしてコスト削減やパフォーマンスの分散化を狙い、製品版をAWSで構築することで、
クレーム検知の精度を実用レベルまで向上させ、約65%のコスト削減に成功しました。

AWSの導入にあたって、どのように目的を整理し、利害関係者を説得したのか？どのようにして目標を達成したのか？
将来的なアーキテクチャの構想も含めて、メールディーラーのテクニカルリーダである私が可能な限り具体的に事例を交えて説明いたします。

AWSやコンテナは新しい技術ではありませんが、2001年にローンチしたメールディーラーにとっては違います。
メールディーラーは全機能がひとつのサーバに実装されており、WebサーバとDBですらひとつのサーバに集約されています。
また、フレームワークを導入しておらず、DBアクセスからprint文によるHTML出力が、1つのPHPファイルに実装され、
プログラムの陳腐化が急速に進んでいます。

その一方で市場開拓の必要性から新機能を定期的にリリースすることが求められています。
さらにLLMに代表されるAIブームがメール共有市場にも影響を及ぼし始め、
LLMを「導入していることがメリット」だったのが「導入していないことがデメリット」に変わりつつあります。

AIブームを背景に、ChatGPTを活用したクレーム検知機能をAWS上で構築し、無事リリースに至りました。
本セッションを通じて、新しい試みを試す参考になれば幸いです。

「クリーンアーキテクチャ」というものがやりたいのではない。クリーンなアーキテクチャをつくりたいのだ。
そんな思いから、このセッションは始まります。

丁寧につくりあげた設計の理念が、納期・チーム事情・歴史的経緯を前にして思いどおりに適用できないことは珍しくありません。

本セッションでは、特定の設計流派にとらわれることなく、万能レイヤー構成を追い求めるのでもなく「現場で選び取るための判断軸」にフォーカスします。

• どこまで追い求め、どこで割り切るかの基準
• チーム負荷を増やさずに設計方針を整理する考え方
• 現場の文化を壊すことなく改善を提案し、合意を得るための工夫

完成形の図面ではなく、変化し続けるプロダクトと向き合うための「ゆるい設計術」を提案します。

想定対象者: 中規模 PHP プロダクトで設計・リファクタリングに関わるエンジニア

配属されたPHPプロダクトは、次につくる機能が決まっていませんでした。

私が担当することになったプロダクトは、立ち上げ時に想定していた機能をつくりきった状態でした。
しかし、ビジネスチームのメンバは他のタスクに追われ、次の開発方向性をなかなか決められず、小さなバグ修正や軽微改善のタスクばかりが提案される危険がありました。
そのため、次の一手をビジネスチームと一緒に考えることになりました。しかし、今までの開発チームはビジネスサイドからの要求を実装することがメインの仕事であり、主体的に開発の方向性を考えられるようになるためには、開発フローやいくつか"仕掛け"が必要でした。

このトークでは、ビジネスチームに頼っていた開発チームを、主体的に動けるチームに変えるために行ったことについてお話しします。

「実装は今日からです。仕様はまだ決まっていません。」
チームに告げられた計画はあまりに無謀で、誰もが炎上を覚悟した─────。

この発表では、オニオンアーキテクチャによって仕様追加による改修が最小限に抑えられた事例について解説します。

私たちのチームではスケジュールの都合上、仕様が確定する前に実装に着手する必要がありました。
この危機的状況を切り抜けるため、サービスで採用していた ”オニオンアーキテクチャ” の利点を最大限活かし、
ドメインモデルを中心として ”仕様が決まっているところから着手する戦略” を取りました。
この戦略により、仕様の確定を待たずに手を動かせたことによって、スケジュールの遅延を防ぐことに成功しました。

実際にオニオンアーキテクチャによって、開発がブーストした事例を紹介します。

名前の似た機能の実装を集約して、複数のドメインと機能でテーブルとAPIを共有する。

この設計アイディアによって、弊社機能の立ち上げは部分的には加速しましたが、サービスの成長に伴い高いコストをもたらしました。
この設計アイディアを社内では「汎用テーブル・API」と呼んでいます。

本トークでは、「汎用テーブル・API」がどのようなコストをもたらしたか、ドメインと機能の境界に沿ってテーブルとAPIを分割するまでの道のりを具体例を交えてお話しします。

以下の内容をお話しします。

• 「汎用テーブル・API」とは何か、どのようなコストを発生させているか
• ドメインと機能の境界に沿って分割するまでの具体的な手順

対象者:

• バックエンドの技術負債に向き合っている方
• DBテーブルのデータ移行に興味のある方

Agenda

1. What is DDD x Clean Architecture?
2. What kind of systems is it suitable for?
3. How was the actual implementation in Laravel?
   • What steps were taken to introduce it?
   • What kind of structure was used for the implementation?
   • Good points and bad points

※この資料の内容で話します！日本語版に直すのも可能です。
https://speakerdeck.com/bumptakayuki/laravel-x-clean-architecture

PHPに限らず、プログラムは繰り返しても劣化しない正確さと速さが持ち味です。人間は繰り返すと集中力が落ち、集中力が落ちると正確さと速さが劣化しがちですよね。
私は素早く開発することを突き詰めた結果、定型的なPHPコードは自分で書くよりPHPに書かせた方が早いと考えるに至り、さまざまなコード自動生成を日々試してきました。
2025年、AI時代に入って、世間のPHPerの皆さんもコード生成を始めていると思いますが、単に自然言語でプロンプトを投げては生成ガチャを引くだけになっていませんか？
私は、作業ログを読み込ませたりコンテクストの与え方を工夫するよりも、AIとPHPを組み合わせて利用することで「退屈な仕事」はPHPに任せてガチャの範囲を狭め、より効率的にコード生成を行えるのではないか、という仮説に基づいて実験をしています。その結果を報告します。

「HowじゃなくてWhyで考えよう！」なんてセリフを良く聞きますね。
その一方で、設計について聞くと「○○設計を踏まえていて〜」と返答をもらうことも、しばしば。

ローカル変数の命名1つをとっても、フレームワークやインフラストラクチャの選定にしたって、
一気通貫の「なぜ設計をするのか」「どんなものが必要なのか」の考え方があるはずです。

それが「トレードオフを見極め、織り込み、決定する」ことです。
これこそが「設計行為である」という立場からトークをします。

抽象的で、広いスコープに届くような話を、なるべく具体的で卑近な例を取り上げながら説明していきます。

話すこと

「Why」としての設計

• ソフトウェア開発の最終目的である「品質」 = ユーザーにとっての価値実現
• 求めるべき品質を可能な限り摩擦ゼロで実装する支えが「設計」

取り上げる話題の例

• 「テストしやすくする」時に、何を天秤にかけているのか
• 「YAGNIだ、だからやめよう」は何を捨てているのか・拾っているのか
• ベテランに聞いてみました！ "「設計的な判断をする」時に、何を考えていますか？"

ソフトウェア開発をやっていると、実に様々な「○○駆動」に出会います。
ドメイン駆動、ユースケース駆動、テスト駆動・・・

開発や設計の進め方だったり、考え方だったりについては、「駆動」以外にも似たような単語がありますね。
オブジェクト指向などの「指向」、ユーザー志向などの「志向」、人間中心デザインなどの「中心」、モバイルファーストなどの「ファースト」、etc。

その中にあってTDDやDDDなどは、どうして「駆動/ドリブン」なのか？を考えたことがありますか。
一歩留まって考えると、ただ「○○を最初にやること」ではないはずだ、と気付くはずです。
私は、この言葉を使う時、中核には「フィードバックを得やすくする」「あるべき姿の探索を推進する」ための仕掛けである！という主張が眠っているものと捉えています。

更に一歩踏み込んで、「なぜ、そうした仕掛けが必要なのか？」も考えてみましょう。
その答えは、「人間として、プログラミングを少しでも楽にするため」だと私は捉えています。

複雑で難しい問題を解く時、「できるところから始める」と進みやすくなります。
高度で曖昧な問題に取り組む時、「間違いに気づいて修正ができる」と正解に近づきやすくなります。
つまり、「認知負荷がキャパシティを超えないようにチャンクする」「適切なタイミングでフィードバックを得る」「軌道修正をする」を組み合わせることで、人間の問題解決能力が高まるのです。
「○○駆動」とは、正にこうした「人間が進むための杖」となるべきものでしょう。

このトークで話すこと

• 色々な「○○駆動」は、人間に楽をさせるための道具である
• どうやって楽をするか？に向き合うことが、プログラミングの能力に磨きをかける

このトークで話さないこと

• 特定の「○○駆動」についての解説や宣伝

一般的に「理系の専門職」と言われるプログラミングのお仕事について、
「実は国語力がとても大事だ！」という主張。
皆さんも、しばしば耳にした事があるのではないでしょうか？

多くは、「文章や会話の中から、要求を掴む」「表現すべきことを、構造化して記述する」といった点についての言及です。
なぜ、これらを「国語力」というのでしょうか？
あるいは、他にも要素があるのでしょうか？

例えば、「大学入試科目・現代文」の解き方をトレーニングすることで、職業プログラマーが学べる事とは──
もし、必要な能力が身につくのであれば、取り入れていきたいですよね。

そんなチャレンジをしてみましょう。

やること

• 「現代文(主に入試現代文)」の参考書で、どんなことが述べられているかを調べる
• 実業務と照らし合わせて、関連しそうなケイパビリティを紐解く

聴き手に提供すること

• 改めて「業務で求められる能力(のいち側面)」について分析し、言語化する
• 得意な人には自覚的な「強み」として、苦手な人には「鍛え方」「着目ポイント」として、国語力について考える機会にする

皆さんもここ数年、会社のいたるところで「自動化」を聞きますよね。
必ずと言ってもいいほど、「こういった処理を自動化したいんだけど、詳しいだろうからやってくれない？」みたいなこと起きませんか？
（場合によっては、「なんか動かないから直して！！」もあると思います）

ただし、言われたものをそのまま「自動化」をすると、「思ってたのと違う」「実はこういうことがしたかったんだよね」「コストかかりすぎない？」となることも多いと思います。

本トークでは、実際にあった「自動化」の例を取り上げながら、考えるべきこと、ヒアリングの仕方などを話していきます。

対象の読者

• よく事業部・営業部などに依頼をされることがある人
• 社内にあるあるフローを自動化をしたいと考えている人

自動ユニットテスト、書いていますか？

自動ユニットテストがコードの品質や変更容易性を向上させ、高い開発生産性の実現に寄与することは、もはやソフトウェア開発における共通認識と言えるでしょう。

しかし「どうやって書けばいいかわからない」から脱却できず、自動テストの導入に二の足を踏んでいる現場は未だに多く存在するようです。また「テストを導入した・している」という事実だけで満足してしまい、書いたテストが必ずしも効果を発揮していない、あるいは逆に開発の足かせになっている現場は後を絶たず、「テストは書いているけれど、逆に手間が増えてしまっている」「テストコードが増えすぎて保守が大変になった」といった声を聞くことは珍しくありません。

本トークでは、効果的な自動ユニットテストを書くための考え方やテクニックを、具体例やアンチパターンを通じてわかりやすく解説します。また、動的型付インタープリタ言語である PHP ならではの事情を交えながら、現場ですぐに役立つ知見を共有します。

このトークを聞いて欲しい人

• どうやってテストコードを書けばいいかわからず、導入に踏み切れていない人
• テストコードを書くのが「面倒くさい」「運用が大変」と感じている人
• 自動ユニットテストを書いているが、「これで正しいのか？」と不安がある人
• 良いテストコードを書く技術を身につけて、組織やチーム文化を改善したい人

お話しすること

• 効果的な自動ユニットテストを書くための基本的な考え方とテクニック
• よくあるアンチパターンと処方箋

お話ししないこと

• 自動テスト導入そのもののメリット
• 特定のツールやライブラリ、フレームワークの詳細な使い方
• インテグレーションテストやE2Eテスト、全体のテスト戦略について

ここ数年、私はRaspberry PiでCPUを作っています。
これは、Z80というCPUをコンピュータから取り外して代わりにRaspberry Piで作った自作CPUを取り付けて動かすというものです。

このトークでは私が作成した2つのバージョンのCPUを題材に、以下の様なことをお話します。

• 少ないGPIOで多くの信号線をコントロールする工夫
• CPUを作るというのは具体的に何をするのか
• 手配線で作るCPUと基板発注して作るCPU
• 自作CPUのデバッグ方法
• Linux上でプログラムを動かすことのメリットとデメリット
• 全てを手放して速度を得る - ベアメタル開発

このトークを聞いた方が「CPUを作るというのはどういうことか」をちょっぴり理解し、CPUやハードウェア自作が好きになることを願っています。そしてあわよくば一緒に自作CPUを楽しみましょう！

ここ数年、Raspberry PiでCPUを作っています。
これは、CPUをコンピュータから取り外して代わりに自作CPUを取り付けて動かすというもので、オリジナルのCPUの名前のZ80にちなんでPiZ80と呼んでいます。

PiZ80はZ80採用のパソコン・MSXをあわよくば高速に動かすことを目標にしています。
現在のPiZ80はMSXと同じZ80採用のシングルボードコンピュータ・SBCZ80でZ80よりも高速に動作する様になっていますが、ここに至るまでにはさまざまな改善がありました。

このトークではCPUを作るというのはどういうことか、CPUを作る時にどこに速度的な課題があるのか、そしてMSXでPiZ80を動かすまでの道のりをお話します。

このトークを聞いた方がCPUやハードウェア自作が好きになり、そしてあわよくばPiZ80のソフトウェアをいっしょに改善していけることを願っています！

CPUやプログラムの実行といったコンピュータの"低レイヤ"を知るためにCコンパイラを作成するのはとても良いアイデアです。
Rui Ueyamaさんの「低レイヤを知りたい人のためのCコンパイラ作成入門」はまさにそんな目的で書かれていて、手順どおりに進めていくだけで演算、変数、関数やポインタなど十分にそれっぽいCコンパイラを作れます。
ですが、このドキュメント、C（言語）でCコンパイラを作っていて、それ自体はごく普通のことですがPHPerにとっては若干ハードルが高いんですよね…。
OK。それならPHPでやってみましょう。
このトークではRui Ueyamaさんのドキュメントに従いながらPHPでCコンパイラを作る方法を解説します。
このトークを聞いた方がご自身でもPHPでCコンパイラを作成し、コンピュータの低レイヤを楽しめる様になることを願っています。