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

AI駆動開発で品質を上げるために、
・4つの図で整理する「sudoモデリング」
・draw.io × AIでモデルを壁打ち・可視化
・受入基準をAIで磨き込み、手戻りを減らす
DDDと仕様駆動を一本のプロセスとして繋げる方法について話しました。

Transcript

1. DDD×仕様駆動で回す高品質開発のプロセス設計 松岡 幸一郎 / ログラス ランサーズAgent 2026/3/19 1
2. 自己紹介 2
3. 今日のゴール DDD × 仕様駆動で、AI駆動開発の品質を上げるプロセスを持ち帰ってもら う 持ち帰ってもらえると良いこと: sudo モデリング ── 4つの図のフレームワーク draw.io × AI ── 図を使ったAIとの協働 仕様駆動との接続 ── AIに「何を作るか」を正確に伝えるプロセス その他の品質向上のためのプラクティス 3
4. アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 4
5. DDDとは DDD（ドメイン駆動設計）= プロダクト開発で大きな価値を生むための手法 「ドメイン」 = ソフトウェアで問題解決しようとする対象（業務領域） DDDの目的: 機能性（役に立つものを作る） × 保守性（長期間作り続けられる） DDDは2003年、今から20年以上前からある手法。 　　AI時代の今、DDDにはどんな価値があるのか？ 5
6. DDDのアプローチはAI時代にも有効 DDDの2つのアプローチは、AI時代にそれぞれ活用できる DDDの目的を2つに分解すると: 機能性（役に立つものを作る） ： ドメインエキスパートと行うモデリング → 作るものを検討し、AIに渡すために活用できる 保守性（長期間作り続けられる） ： モデルをそのまま表現する、保守性の高い実装パターン → 実装のガードレールとして活用できる 6
7. 仕様駆動開発とは 仕様（完了条件・設計・テスト）を先に決め、AIに実装させる開発アプロー チ 設計で押さえるべき3つの要素： 1. 完了条件（受入基準） 2. 技術的な設計 3. テスト 本質は 「上流で品質を作り込み、手戻りを防ぐ」 こと 7
8. 今日お話しすること DDD × 仕様駆動で、開発フロー全体の品質を上げる DDDのモデリングが最上流で「何を作るか」を明確に 仕様駆動が各フェーズで品質を作り込む 作ったモデルが、仕様駆動の各フェーズのインプットになる 8
9. アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 9
10. DDDの目的 役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにす る ①ソフトウェアの機能性を高めること 役に立つものを作る。 「作ったけど使えない」を避ける ②ソフトウェアの保守性を高めること 長期間開発しても機能拡張が容易でありつづける 「技術的負債でどんどん開発速度が低下する」を避ける 10
11. DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング 11
12. DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング 「ドメインモデル」にドメインの知識を反映し、役に立つものになる可能性を高める ドメイン知識があれば役に立つものが作れるわけでは無い ただ、ドメイン知識がなければ役に立つものは作れない →ドメイン知識は十分条件ではないが、必要条件 開発初期だけでなく、各フェーズで発見をフィードバックして改善頻度を上げる → 次のセクション「モデリング」で詳細に紹介 12
13. DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン 13
14. DDDのアプローチ(詳細) ①モデリングと②実装パターン、2つのアプローチで目的を達成する ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン モデルの形をそのままコードで表現し、頻繁な更新を反映しやすくする 保守性の高いデザインパターン（エンティティ、リポジトリ等）を適用する → これをAIのガードレールとして設定する話を後半「技術設計・実装」セクションで紹介 14
15. モデルと実装のつながり(1/3) モデルと実装に乖離があると、対応関係が見えにくくなる 15
16. モデルと実装のつながり(2/3) モデルに変更があった時、コードのどこに反映すべきかわからなくなる 16
17. モデルと実装のつながり(3/3) コードは極力モデルと同じ形での表現を目指す モデルとコードを同じ形にすると、変更の反映先が一目でわかる 17
18. アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 18
19. モデリングとは モデリング = モデルを議論しながら作る活動 モデル = 問題解決のために作る抽象化物 モデリング = それを議論しながら作る活動 成果物だけでなく、作るプロセスで議論・認識合わせ・意思決定することが重要 19
20. モデリングが橋渡しになる理由 ドメインをモデル化し、ソフトウェアで問題を解決する 複雑なドメイン（業務領域）をドメインモデルとして抽象化する そのモデルをもとにソフトウェアを構築し、問題を解決する モデルというワンクッションを置くことで、複雑な問題を解決する精度が上がる 20
21. なぜモデリングが役に立つのか 「ちょうどいい抽象度」で情報を整理でき、仕様決めの精度が上がる ①複雑な構造を整理しやすい テキストは線形で構造を伝えにくいが、図なら2次元で関係性を一目で把握できる ②ちょうど良い抽象度で構造を整理できる 画面の詳細な項目だと具体的すぎて全体構造を整理しにくい モデルを使うとちょうど良い抽象度で整理できる これが仕様駆動の各フェーズの精度向上につながる 21
22. ドメインモデリングを始めるタイミングと目的 新規開発でも、既存システムの理解でも、モデリングは有効 ①新規機能開発や機能改修を行う時 ドメイン理解を深めて、役立つものを作れるようにする わかること、わからないことを明確にして意思決定しやすくする ②モデリングを後追いで実施する時 リバースエンジニアリング的に、すでにあるコードについて理解する コードやモデルの現実と、ドメインの理想とのギャップを明確にする すべてが①で実施できれば理想だが、②も現実的には有用。②から①に繋ぐこともできる 22
23. DDDにおけるモデリング手法 DDDのモデリング手法に決まりはない。 今回は筆者が複数の現場でモデリングをしてきた中で、 最も導入ハードルが低く、効果を出しやすいと考えている手法を紹介します 23
24. sudo モデリングとは sudoモデリング は、ハードルが低く効果が出しやすいモデリング手法 図 やること S: システム関連図 システムに関わるアクターと外部システムを明示する U: ユースケース図 ユーザーがシステムでどのような操作を行うか明示する D: ドメインモデル図 概念と概念の関係を抽象的に描く O: オブジェクト図 具体的なデータ例で理解を深め、モデルを検証する このラインナップは「どんな時にもやると良い最低限の4つ」 他にも以下のものは併用するとよい 業務フロー図 状態遷移図 シーケンス図 24
25. モデリングの題材 採用管理システムの開発初期をシミュレーション 採用担当者が応募者の進捗管理などを行うシステム これから4つの図を使って、このシステムを新規開発する際のモデリングの例を説明します 25
26. モデリングするときのポイント 抽象と具体を行き来し、仮説を回し続ける 抽象だけではなく、具体例が大切 よい解決策を考えるには具体例が必要 具体例が出せない＝そもそもドメイン理解が足りてないサイン モデリングは、成果物以上にプロセスが大切 わからないことを明らかにして、不足している知識や知見を埋めに行く 得た情報の中で意思決定をしていく 意思決定は常に仮説であると考える ドメインの問題解決には、常に不確実性が存在する 初期段階では全ては仮説。いかにフィードバックサイクルを回し、仮説の確度を高められ るかを考える モデル図は仕様書ではなく、ホワイトボードのように扱う ただし、メンテするものは明確に決めて最新化する 26
27. システム関連図（System Context Diagram） 開発するシステム、関わりのあるアクターや外部システムとの関連を示す図 アクター（誰が使うか） 、外部システム（何と連携するか）を描く 全体を俯瞰することで、スコープの認識を合わせられる 27
28. システム関連図（System Context Diagram） 実は、重要な意思決定をしている 大したことのない図に見えるが・・・ 応募者がこのシステムを使わない、とすると開発する機能が大きく変わる この図を作る過程で、 「応募者ってここにログインする？」という議論がされ、 その意思決定の結果 前述の通り「モデリングは、成果物以上にプロセスが大切」 28
29. ユースケース図（Use Case Diagram） ユーザーの要求に対するシステムの振る舞いを定義する図 アクターごとに「どんな操作をするか」を描く 機能の漏れや優先順位の議論に使える 29
30. オブジェクト図（Object Diagram） 抽象的なモデルを「具体例」で検証するための図 「田中太郎さんがA社のバックエンドエンジニア職に応募」のように、実際のデータで描く 具体例を描くことで、ドメインの理解を深め、モデルの矛盾や漏れが見つかる 30
31. ドメインモデル図（Domain Model Diagram） ドメインの概念と関係性を抽象的に描き、共通言語を作る図 オブジェクト図（具体例）から抽象化し、そのままコードで表現できるモデルを作る チームの共通言語になり、コードの設計にも直結する 31
32. ドメインモデル図のモデリングのコツ オブジェクト図から抽象化し、ルール・制約を書き出す オブジェクト図（具体例）から、ドメインモデルに抽象化していく ルール/制約（ドメイン知識） を吹き出しに書き出す モデリング中に疑問が出たものをその場で議論してメモしていく 検討メモ も積極的に記述する 生じた疑問の結論や疑問点もOK。発見を誘発し、関係者の認識を残す 多重度 を定義する 「採用選考から採用ポジションの紐付けは必須か？」など、ルール/制約として重要な意思 決定 実装前に主にエンジニアで決めること: 集約の範囲: リポジトリの範囲を決める 日本語名の対訳としての英語名: ユビキタス言語のマスタ。表記揺れを防ぐ 32
33. フェーズ①：モデリング 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 33
34. 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
35. draw.io × AI 実践(1): AIと壁打ちしながらモデルを育てる draw.ioで描いたドメインモデル図をAIに読み込ませて壁打ち 35
36. draw.io × AI 実践(1): AIと壁打ちしながらモデルを育てる 「具体例を出して」と聞くだけで、オブジェクト図（具体例）を生成 36
37. draw.io × AI 実践(1): AIと壁打ちしながらモデルを育てる 1人では見落としがちな観点を、AIが補完してくれる 「この図の懸念点は？」と聞くと、検討すべきポイントを提示してくれる 37
38. アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 38
39. フェーズ②：受入基準 モデルを作ったら、次はそのモデルを使って仕様を磨く 完了条件が曖昧だと、意図と違う実装がどんどん進む（AIコードドリフト） AIは経験や暗黙知で補完できない。曖昧な仕様は乖離した実装を生み続ける 完了条件を磨き込むことで手戻りを減らせる 明確な完了条件があると、AIが自己修正ループを回せ、出力品質が上がる モデルで整理した構造が、受入基準を書くインプットになる 39
40. 受入基準のアプローチ(1/4) 受入基準は「AIで作る」より「AIで磨き込む」が大事 手段は問わず受入基準を決めたら、AIによるレビュー・リファインメントを入れる 観点 内容 ①レビュー 開発上押さえるべきチェックポイントを確認して質を上げる ②リファインメント 不明瞭なポイントをAIに質問させて明確にする 専用のSkillを作り、観点をプロジェクトで育てていく 上記観点でブラッシュアップできるようにする(レビューとリファインメントを分けなくて OK) 「何を見るか」を言語化することで、毎回確実に同じ観点でレビューされる 40
41. 受入基準のアプローチ(2/4) 大量のドキュメントをレビューするより、とにかく質問させる 大量のドキュメントを見て改善点を出すのは難しい Question-Firstにすることが大事 勝手に聞いてくれない場合は「現時点で検討すべき重要なことを優先して質問して」と指 定する AIに質問させることは、論点を洗い出すこと 重要な論点が最初に出ると、検討を進めやすい Claude Codeは 「AskUserQuestion」 ツールを使うように指示すると選択式で答えられる 選択肢と合わせて推奨度と理由を書かせると、 「こう思うけどどう？」という形で議論しや すい CLAUDE.mdに上記指示しておくと 41
42. 受入基準のアプローチ(3/4) 具体例で仕様を書くと、人もAIも迷わない Specification by Example（SBE）: 抽象的な記述ではなく、具体的な実例で仕様を定義する手法 抽象的な受入基準： 「ユーザーは検索結果を並べ替えることができる」 → 人によって解釈が違うことや、コーナーケースが見えないことがある 実例を用いた受入基準（Given/When/Then） ： Given: 商品A（1000円） 、商品B（500円）が存在する When: 「価格: 安い順」で並べ替え Then: 商品B → 商品Aの順で表示される 具体例を書こうとすると、自然にコーナーケースが洗い出される AIにとっても：具体例 = 入出力が明確 → 意図通りの実装になる sudo モデリングのオブジェクト図がまさにこの「具体例」 。モデリングの成果がそのまま活 用できる 42
43. 受入基準のアプローチ(4/4) 複雑な仕様ほど、図にすると圧倒的に伝わる draw.ioでSBEを可視化する 従来のSBEはテキストで実例を書くが、AIにdraw.ioで可視化させると理解しやすい 考慮漏れの状態遷移やロジックの分岐が一目で見つかる （AIが生成した目標管理アプリのレポート画面の実例） 43
44. アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 44
45. フェーズ③④⑤：技術設計・テスト・実装 品質を上げるには受入基準だけでなく、その先のプロセスも大事 フェーズ①モデリング・フェーズ②受入基準で、上流の品質を作り込んだ ここからは各フェーズでの具体的な施策を紹介していく モデリング → 受入基準 → 技術設計 → テスト → 実装 45
46. 技術設計フェーズ 人間の判断を、重要なポイントに集中させる 意思決定の前倒し: Question-Firstで設計段階でAIに質問させる 論点・選択肢・メリデメを出させ、実装前に意思決定を済ませる 大量のdiffが出てから問題を見つけるのではなく、手前で検討ポイントを明確にする 固定観点レビューSkill: プロジェクトで重視する設計観点を言語化してSkillにする 毎回確実に同じ観点でチェックされる状態を作る 46
47. DDDの保守性アプローチ × AIガードレール ドメインモデルをコードで表現するルールを、AIに守らせる セクション2で紹介した「モデル＝コード」のアプローチを実践する CLAUDE.md / .claude/rules/ にドメインモデルの構造をそのままコードで表現するルールを 定義 エンティティ・値オブジェクト・リポジトリ等のパターンを明文化 設計原則・アーキテクチャ制約・コーディング規約も事前定義 AIはルールがあれば従ってくれる。毎回同じことを言わなくていい状態を作るのがゴール 「モデルを守ったコード」が自動的に生成される状態を作る 47
48. ビジュアルで設計を確認する テキストだけより、図がある方が圧倒的にレビューしやすい 仕様駆動開発では受入基準や技術設計をテキストで書くことが多い しかし複雑な仕様はテキストだけだとレビューが辛い draw.ioでクラス図やデータフローにすると、一目で把握できる 48
49. テスト分析設計フェーズ テストを明示的に検討させ、情報をきちんと渡す テストを明示的に検討させる: 実装計画と同じタイミングでテスト設計も依頼 ClaudeCodeの /plan は実装の計画はするが、 テストをあまり詳細に考慮しない（現時点では） 実装前にテストを考えることで、仕様の抜け漏れ・矛盾に気づける テスト設計・レビューSkill: テスト観点をSkillとして言語化 受入基準・技術設計と同じように、Skillにすることで毎回確実に同じ観点でレビューでき る このSkillのレビュー観点をチームで育てることで、QAの観点・過去の不具合パターンが蓄 積されていく 49
50. 実装フェーズ AIが自律的に実装・検証を回せる環境を整える 自動テスト × ブラウザ操作: playwright-mcp等で画面確認まで任せられると手離れが良くなる 「自動テストOK。画面確認は人間がお願い」で止まると、確認が人間に戻ってきてしまう 画面確認までAIに任せられると、人間は本当に最終確認だけに集中できる 50
51. コンテキストエンジニアリング AIが必要な情報に確実に辿り着ける設計をする FLOW と STOCK に分ける FLOW（随時メモ）: 開発中に書き留める一時的な情報 STOCK（常に最新化するドキュメント）: AIがまず参照する整理済みドキュメント レビューSkillに「更新すべきSTOCK情報があれば教えて」を組み込むと、自然にドキュメ ントが最新化される 51
52. 情報探索の設計（段階的開示） 必要な時に必要な情報だけ渡す「段階的開示」の構造を作る AgenticSearch任せにせず、 「情報への辿り着き方」を設計する README.md にインデックスへのパスを書いておく → AIが段階的にたどれる 大量のドキュメントを一度に読ませるのではなく、必要な時に必要な情報だけ渡す 52
53. アジェンダ 1. 全体像：DDD × 仕様駆動 × 開発フロー 2. DDDのアプローチ 3. フェーズ①：モデリング DDDにおけるモデリング モデリングで活用できるAI 4. フェーズ②：受入基準 5. フェーズ③④⑤：技術設計・テスト・実装 6. まとめ 53
54. まとめ DDD × 仕様駆動で、開発フロー全体の品質が上がる DDDのモデリングは「ちょうどいい抽象度」で、複雑なドメインを整理できる その「ちょうどいい抽象度」が、受入基準・技術設計・テストのインプットになる DDD × 仕様駆動は一本のプロセスとして繋がり、開発全体の品質が上がる 54
55. ご清聴ありがとうございました 質問はQ&Aへ！ 松岡 幸一郎 X(Twitter): @little_hand_s 55
56. 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