DDD×仕様駆動で回す高品質開発のプロセス設計

by Koichiro Matsuoka

Embed

Start on current slide

Slide 1

Slide 1 text

DDD×仕様駆動で回す高品質開発のプロセス設計松岡幸一郎 / ログラスランサーズAgent 2026/3/19 1

Slide 2

Slide 2 text

自己紹介 2

Slide 3

Slide 3 text

今日のゴール DDD × 仕様駆動で、AI駆動開発の品質を上げるプロセスを持ち帰ってもらう持ち帰ってもらえると良いこと: sudo モデリング ── 4つの図のフレームワーク draw.io × AI ── 図を使ったAIとの協働仕様駆動との接続 ── AIに「何を作るか」を正確に伝えるプロセスその他の品質向上のためのプラクティス 3

Slide 4

Slide 4 text

アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 4

Slide 5

Slide 5 text

DDDとは DDD（ドメイン駆動設計）= プロダクト開発で大きな価値を生むための手法「ドメイン」 = ソフトウェアで問題解決しようとする対象（業務領域） DDDの目的: 機能性（役に立つものを作る） × 保守性（長期間作り続けられる） DDDは2003年、今から20年以上前からある手法。　　AI時代の今、DDDにはどんな価値があるのか？ 5

Slide 6

Slide 6 text

DDDのアプローチはAI時代にも有効 DDDの2つのアプローチは、AI時代にそれぞれ活用できる DDDの目的を2つに分解すると: 機能性（役に立つものを作る）：ドメインエキスパートと行うモデリング → 作るものを検討し、AIに渡すために活用できる保守性（長期間作り続けられる）：モデルをそのまま表現する、保守性の高い実装パターン → 実装のガードレールとして活用できる 6

Slide 7

Slide 7 text

仕様駆動開発とは仕様（完了条件・設計・テスト）を先に決め、AIに実装させる開発アプローチ設計で押さえるべき3つの要素： 1. 完了条件（受入基準） 2. 技術的な設計 3. テスト本質は「上流で品質を作り込み、手戻りを防ぐ」こと 7

Slide 8

Slide 8 text

今日お話しすること DDD × 仕様駆動で、開発フロー全体の品質を上げる DDDのモデリングが最上流で「何を作るか」を明確に仕様駆動が各フェーズで品質を作り込む作ったモデルが、仕様駆動の各フェーズのインプットになる 8

Slide 9

Slide 9 text

アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 9

Slide 10

Slide 10 text

DDDの目的役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにする ①ソフトウェアの機能性を高めること役に立つものを作る。「作ったけど使えない」を避ける ②ソフトウェアの保守性を高めること長期間開発しても機能拡張が容易でありつづける「技術的負債でどんどん開発速度が低下する」を避ける 10

Slide 11

Slide 11 text

DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング 11

Slide 12

Slide 12 text

DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング「ドメインモデル」にドメインの知識を反映し、役に立つものになる可能性を高めるドメイン知識があれば役に立つものが作れるわけでは無いただ、ドメイン知識がなければ役に立つものは作れない →ドメイン知識は十分条件ではないが、必要条件開発初期だけでなく、各フェーズで発見をフィードバックして改善頻度を上げる → 次のセクション「モデリング」で詳細に紹介 12

Slide 13

Slide 13 text

DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン 13

Slide 14

Slide 14 text

DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターンモデルの形をそのままコードで表現し、頻繁な更新を反映しやすくする保守性の高いデザインパターン（エンティティ、リポジトリ等）を適用する → これをAIのガードレールとして設定する話を後半「技術設計・実装」セクションで紹介 14

Slide 15

Slide 15 text

モデルと実装のつながり(1/3) モデルと実装に乖離があると、対応関係が見えにくくなる 15

Slide 16

Slide 16 text

モデルと実装のつながり(2/3) モデルに変更があった時、コードのどこに反映すべきかわからなくなる 16

Slide 17

Slide 17 text

モデルと実装のつながり(3/3) コードは極力モデルと同じ形での表現を目指すモデルとコードを同じ形にすると、変更の反映先が一目でわかる 17

Slide 18

Slide 18 text

アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 18

Slide 19

Slide 19 text

モデリングとはモデリング = モデルを議論しながら作る活動モデル = 問題解決のために作る抽象化物モデリング = それを議論しながら作る活動成果物だけでなく、作るプロセスで議論・認識合わせ・意思決定することが重要 19

Slide 20

Slide 20 text

モデリングが橋渡しになる理由ドメインをモデル化し、ソフトウェアで問題を解決する複雑なドメイン（業務領域）をドメインモデルとして抽象化するそのモデルをもとにソフトウェアを構築し、問題を解決するモデルというワンクッションを置くことで、複雑な問題を解決する精度が上がる 20

Slide 21

Slide 21 text

なぜモデリングが役に立つのか「ちょうどいい抽象度」で情報を整理でき、仕様決めの精度が上がる ①複雑な構造を整理しやすいテキストは線形で構造を伝えにくいが、図なら2次元で関係性を一目で把握できる ②ちょうど良い抽象度で構造を整理できる画面の詳細な項目だと具体的すぎて全体構造を整理しにくいモデルを使うとちょうど良い抽象度で整理できるこれが仕様駆動の各フェーズの精度向上につながる 21

Slide 22

Slide 22 text

ドメインモデリングを始めるタイミングと目的新規開発でも、既存システムの理解でも、モデリングは有効 ①新規機能開発や機能改修を行う時ドメイン理解を深めて、役立つものを作れるようにするわかること、わからないことを明確にして意思決定しやすくする ②モデリングを後追いで実施する時リバースエンジニアリング的に、すでにあるコードについて理解するコードやモデルの現実と、ドメインの理想とのギャップを明確にするすべてが①で実施できれば理想だが、②も現実的には有用。②から①に繋ぐこともできる 22

Slide 23

Slide 23 text

DDDにおけるモデリング手法 DDDのモデリング手法に決まりはない。今回は筆者が複数の現場でモデリングをしてきた中で、最も導入ハードルが低く、効果を出しやすいと考えている手法を紹介します 23

Slide 24

Slide 24 text

sudo モデリングとは sudoモデリングは、ハードルが低く効果が出しやすいモデリング手法図やること S: システム関連図システムに関わるアクターと外部システムを明示する U: ユースケース図ユーザーがシステムでどのような操作を行うか明示する D: ドメインモデル図概念と概念の関係を抽象的に描く O: オブジェクト図具体的なデータ例で理解を深め、モデルを検証するこのラインナップは「どんな時にもやると良い最低限の4つ」他にも以下のものは併用するとよい業務フロー図状態遷移図シーケンス図 24

Slide 25

Slide 25 text

モデリングの題材採用管理システムの開発初期をシミュレーション採用担当者が応募者の進捗管理などを行うシステムこれから4つの図を使って、このシステムを新規開発する際のモデリングの例を説明します 25

Slide 26

Slide 26 text

モデリングするときのポイント抽象と具体を行き来し、仮説を回し続ける抽象だけではなく、具体例が大切よい解決策を考えるには具体例が必要具体例が出せない＝そもそもドメイン理解が足りてないサインモデリングは、成果物以上にプロセスが大切わからないことを明らかにして、不足している知識や知見を埋めに行く得た情報の中で意思決定をしていく意思決定は常に仮説であると考えるドメインの問題解決には、常に不確実性が存在する初期段階では全ては仮説。いかにフィードバックサイクルを回し、仮説の確度を高められるかを考えるモデル図は仕様書ではなく、ホワイトボードのように扱うただし、メンテするものは明確に決めて最新化する 26

Slide 27

Slide 27 text

システム関連図（System Context Diagram）開発するシステム、関わりのあるアクターや外部システムとの関連を示す図アクター（誰が使うか）、外部システム（何と連携するか）を描く全体を俯瞰することで、スコープの認識を合わせられる 27

Slide 28

Slide 28 text

システム関連図（System Context Diagram）実は、重要な意思決定をしている大したことのない図に見えるが・・・応募者がこのシステムを使わない、とすると開発する機能が大きく変わるこの図を作る過程で、「応募者ってここにログインする？」という議論がされ、その意思決定の結果前述の通り「モデリングは、成果物以上にプロセスが大切」 28

Slide 29

Slide 29 text

ユースケース図（Use Case Diagram）ユーザーの要求に対するシステムの振る舞いを定義する図アクターごとに「どんな操作をするか」を描く機能の漏れや優先順位の議論に使える 29

Slide 30

Slide 30 text

オブジェクト図（Object Diagram）抽象的なモデルを「具体例」で検証するための図「田中太郎さんがA社のバックエンドエンジニア職に応募」のように、実際のデータで描く具体例を描くことで、ドメインの理解を深め、モデルの矛盾や漏れが見つかる 30

Slide 31

Slide 31 text

ドメインモデル図（Domain Model Diagram）ドメインの概念と関係性を抽象的に描き、共通言語を作る図オブジェクト図（具体例）から抽象化し、そのままコードで表現できるモデルを作るチームの共通言語になり、コードの設計にも直結する 31

Slide 32

Slide 32 text

ドメインモデル図のモデリングのコツオブジェクト図から抽象化し、ルール・制約を書き出すオブジェクト図（具体例）から、ドメインモデルに抽象化していくルール/制約（ドメイン知識）を吹き出しに書き出すモデリング中に疑問が出たものをその場で議論してメモしていく検討メモも積極的に記述する生じた疑問の結論や疑問点もOK。発見を誘発し、関係者の認識を残す多重度を定義する「採用選考から採用ポジションの紐付けは必須か？」など、ルール/制約として重要な意思決定実装前に主にエンジニアで決めること: 集約の範囲: リポジトリの範囲を決める日本語名の対訳としての英語名: ユビキタス言語のマスタ。表記揺れを防ぐ 32

Slide 33

Slide 33 text

フェーズ①：モデリング 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 33

Slide 34

Slide 34 text

draw.io × AI を実現するSkill AIがdraw.ioファイルを直接操作できるSkillを作成 claude-drawio-skill: https://github.com/little-hands/claude-drawio-skill 「この処理をシーケンス図で整理して」などと指示するだけで .drawio ファイルが完成 Claude CodeのSkillとして動作し、プロジェクトに導入するだけで使えると思ったら直前に公式のskillがあるという情報が入ってきました https://github.com/jgraph/drawio-mcp/tree/main/skill-cli モデリングで活用できるが、仕様設計・技術設計など幅広く活用できるので紹介します 34

Slide 35

Slide 35 text

draw.io × AI 実践(1): AIと壁打ちしながらモデルを育てる draw.ioで描いたドメインモデル図をAIに読み込ませて壁打ち 35

Slide 36

Slide 36 text

draw.io × AI 実践(1): AIと壁打ちしながらモデルを育てる「具体例を出して」と聞くだけで、オブジェクト図（具体例）を生成 36

Slide 37

Slide 37 text

draw.io × AI 実践(1): AIと壁打ちしながらモデルを育てる 1人では見落としがちな観点を、AIが補完してくれる「この図の懸念点は？」と聞くと、検討すべきポイントを提示してくれる 37

Slide 38

Slide 38 text

アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 38

Slide 39

Slide 39 text

フェーズ②：受入基準モデルを作ったら、次はそのモデルを使って仕様を磨く完了条件が曖昧だと、意図と違う実装がどんどん進む（AIコードドリフト） AIは経験や暗黙知で補完できない。曖昧な仕様は乖離した実装を生み続ける完了条件を磨き込むことで手戻りを減らせる明確な完了条件があると、AIが自己修正ループを回せ、出力品質が上がるモデルで整理した構造が、受入基準を書くインプットになる 39

Slide 40

Slide 40 text

受入基準のアプローチ(1/4) 受入基準は「AIで作る」より「AIで磨き込む」が大事手段は問わず受入基準を決めたら、AIによるレビュー・リファインメントを入れる観点内容 ①レビュー開発上押さえるべきチェックポイントを確認して質を上げる ②リファインメント不明瞭なポイントをAIに質問させて明確にする専用のSkillを作り、観点をプロジェクトで育てていく上記観点でブラッシュアップできるようにする(レビューとリファインメントを分けなくて OK) 「何を見るか」を言語化することで、毎回確実に同じ観点でレビューされる 40

Slide 41

Slide 41 text

受入基準のアプローチ(2/4) 大量のドキュメントをレビューするより、とにかく質問させる大量のドキュメントを見て改善点を出すのは難しい Question-Firstにすることが大事勝手に聞いてくれない場合は「現時点で検討すべき重要なことを優先して質問して」と指定する AIに質問させることは、論点を洗い出すこと重要な論点が最初に出ると、検討を進めやすい Claude Codeは「AskUserQuestion」ツールを使うように指示すると選択式で答えられる選択肢と合わせて推奨度と理由を書かせると、「こう思うけどどう？」という形で議論しやすい CLAUDE.mdに上記指示しておくと 41

Slide 42

Slide 42 text

受入基準のアプローチ(3/4) 具体例で仕様を書くと、人もAIも迷わない Specification by Example（SBE）: 抽象的な記述ではなく、具体的な実例で仕様を定義する手法抽象的な受入基準：「ユーザーは検索結果を並べ替えることができる」 → 人によって解釈が違うことや、コーナーケースが見えないことがある実例を用いた受入基準（Given/When/Then）： Given: 商品A（1000円）、商品B（500円）が存在する When: 「価格: 安い順」で並べ替え Then: 商品B → 商品Aの順で表示される具体例を書こうとすると、自然にコーナーケースが洗い出される AIにとっても：具体例 = 入出力が明確 → 意図通りの実装になる sudo モデリングのオブジェクト図がまさにこの「具体例」。モデリングの成果がそのまま活用できる 42

Slide 43

Slide 43 text

受入基準のアプローチ(4/4) 複雑な仕様ほど、図にすると圧倒的に伝わる draw.ioでSBEを可視化する従来のSBEはテキストで実例を書くが、AIにdraw.ioで可視化させると理解しやすい考慮漏れの状態遷移やロジックの分岐が一目で見つかる（AIが生成した目標管理アプリのレポート画面の実例） 43

Slide 44

Slide 44 text

アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 44

Slide 45

Slide 45 text

フェーズ③④⑤：技術設計・テスト・実装品質を上げるには受入基準だけでなく、その先のプロセスも大事フェーズ①モデリング・フェーズ②受入基準で、上流の品質を作り込んだここからは各フェーズでの具体的な施策を紹介していくモデリング → 受入基準 → 技術設計 → テスト → 実装 45

Slide 46

Slide 46 text

技術設計フェーズ人間の判断を、重要なポイントに集中させる意思決定の前倒し: Question-Firstで設計段階でAIに質問させる論点・選択肢・メリデメを出させ、実装前に意思決定を済ませる大量のdiffが出てから問題を見つけるのではなく、手前で検討ポイントを明確にする固定観点レビューSkill: プロジェクトで重視する設計観点を言語化してSkillにする毎回確実に同じ観点でチェックされる状態を作る 46

Slide 47

Slide 47 text

DDDの保守性アプローチ × AIガードレールドメインモデルをコードで表現するルールを、AIに守らせるセクション2で紹介した「モデル＝コード」のアプローチを実践する CLAUDE.md / .claude/rules/ にドメインモデルの構造をそのままコードで表現するルールを定義エンティティ・値オブジェクト・リポジトリ等のパターンを明文化設計原則・アーキテクチャ制約・コーディング規約も事前定義 AIはルールがあれば従ってくれる。毎回同じことを言わなくていい状態を作るのがゴール「モデルを守ったコード」が自動的に生成される状態を作る 47

Slide 48

Slide 48 text

ビジュアルで設計を確認するテキストだけより、図がある方が圧倒的にレビューしやすい仕様駆動開発では受入基準や技術設計をテキストで書くことが多いしかし複雑な仕様はテキストだけだとレビューが辛い draw.ioでクラス図やデータフローにすると、一目で把握できる 48

Slide 49

Slide 49 text

テスト分析設計フェーズテストを明示的に検討させ、情報をきちんと渡すテストを明示的に検討させる: 実装計画と同じタイミングでテスト設計も依頼 ClaudeCodeの /plan は実装の計画はするが、テストをあまり詳細に考慮しない（現時点では）実装前にテストを考えることで、仕様の抜け漏れ・矛盾に気づけるテスト設計・レビューSkill: テスト観点をSkillとして言語化受入基準・技術設計と同じように、Skillにすることで毎回確実に同じ観点でレビューできるこのSkillのレビュー観点をチームで育てることで、QAの観点・過去の不具合パターンが蓄積されていく 49

Slide 50

Slide 50 text

実装フェーズ AIが自律的に実装・検証を回せる環境を整える自動テスト × ブラウザ操作: playwright-mcp等で画面確認まで任せられると手離れが良くなる「自動テストOK。画面確認は人間がお願い」で止まると、確認が人間に戻ってきてしまう画面確認までAIに任せられると、人間は本当に最終確認だけに集中できる 50

Slide 51

Slide 51 text

コンテキストエンジニアリング AIが必要な情報に確実に辿り着ける設計をする FLOW と STOCK に分ける FLOW（随時メモ）: 開発中に書き留める一時的な情報 STOCK（常に最新化するドキュメント）: AIがまず参照する整理済みドキュメントレビューSkillに「更新すべきSTOCK情報があれば教えて」を組み込むと、自然にドキュメントが最新化される 51

Slide 52

Slide 52 text

情報探索の設計（段階的開示）必要な時に必要な情報だけ渡す「段階的開示」の構造を作る AgenticSearch任せにせず、「情報への辿り着き方」を設計する README.md にインデックスへのパスを書いておく → AIが段階的にたどれる大量のドキュメントを一度に読ませるのではなく、必要な時に必要な情報だけ渡す 52

Slide 53

Slide 53 text

アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリングモデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 53

Slide 54

Slide 54 text

まとめ DDD × 仕様駆動で、開発フロー全体の品質が上がる DDDのモデリングは「ちょうどいい抽象度」で、複雑なドメインを整理できるその「ちょうどいい抽象度」が、受入基準・技術設計・テストのインプットになる DDD × 仕様駆動は一本のプロセスとして繋がり、開発全体の品質が上がる 54

Slide 55

Slide 55 text

ご清聴ありがとうございました質問はQ&Aへ！松岡幸一郎 X(Twitter): @little_hand_s 55

Slide 56

Slide 56 text

Q&A / もっと知りたい方へご質問があればお気軽にどうぞ！ X（匿名質問OK） https://x.com/little_hand_s 過去の勉強会動画: sudo モデリングの4つの図をじっくり解説 https://www.youtube.com/watch?v=HgtCKlOzRiQ&list=PLXMIJq1G- _66F9woQpidJfe4HHCFxdXaA&index=1 書籍: 「## ドメイン駆動設計モデリング/実装ガイド」 https://little-hands.booth.pm/items/1835632 書籍: 「ドメイン駆動設計サンプルコード&FAQ」 https://little-hands.booth.pm/items/3363104 一緒にモデリングする勉強会: 現場のテーマでモデリングを実践する勉強会 https://little-hand-s.notion.site/DDD-22429f7110574439a4c3e126c20fa9a2?pvs=74 56