■ 1. DDDの概要と目的
- DDD（ドメイン駆動設計）はプロダクト開発で大きな価値を生むための手法であり、2003年から存在する
- 「ドメイン」はソフトウェアで問題解決しようとする対象（業務領域）を指す
- DDDの目的は機能性（役に立つものを作る）と保守性（長期間作り続けられる）の両立
- DDDは2つのアプローチで目的を達成する:
- ①ドメインエキスパートと共に行うドメインモデリング（機能性向上）
- ②頻繁なモデル更新に耐えられる実装パターンの適用（保守性向上）
- ドメイン知識は役立つものを作るための十分条件ではないが、必要条件である
■ 2. モデリング: AIへの「共通言語」を作る
- モデリングの定義:
- モデル（問題解決のための抽象化物）を議論しながら作る活動
- 成果物だけでなく、作るプロセスでの議論・認識合わせ・意思決定が重要
- モデリングの価値:
- テキストより図の方が2次元で関係性を把握しやすい
- 「ちょうどいい抽象度」（画面項目より抽象的、要件文より具体的）でAIに渡すコンテキストとして最適
- sudoモデリング（4つの図のフレームワーク）:
- S（システム関連図）: システムに関わるアクター・外部システムを明示
- U（ユースケース図）: ユーザーがどんな操作をするか描く
- D（ドメインモデル図）: 概念と関係を抽象的に描き、共通言語を作る
- O（オブジェクト図）: 具体例で理解を深め、モデルの矛盾・漏れを検証
- モデリングのポイント:
- 抽象と具体を行き来し、仮説を回し続ける
- 具体例が出せない場合はドメイン理解が不足しているサイン
- モデル図は仕様書ではなくホワイトボードのように扱う
- draw.io × AI活用:
- AIが.drawioファイルを直接操作できるスキルが存在する（claude-drawio-skill、drawio-mcp）
- 「この処理をシーケンス図で整理して」などの指示だけで図が完成する
- 1人では見落としがちな観点をAIが補完できる
- モデルとコードの関係:
- モデルの形をそのままコードで表現することで変更の反映先が一目でわかる
- モデリングは「実装の下書き」を兼ね、AIへの入力として精度が高まる
■ 3. モデルを各プロセスに繋ぐ
- ドキュメントの階層化:
- エピック（プロジェクト/機能群）: What/Whyを扱い、要求・要件・大まかな仕様・技術設計を記述
- PBI（バックログアイテム）: Howを扱い、受入基準・細かい技術設計・PBI単位のテストを記述
- モデリングはエピックレベルで実施し、後続の各プロセスで再利用する
- 受入基準（Specification by Example）:
- 具体例で仕様を書くことで人もAIも迷いなく実装できる
- 共通理解の形成、コーナーケースの炙り出し、テストへの接続が利点
- Given/When/Then形式は自動テスト（BDD）にそのまま活用できる
- sudoモデリングのオブジェクト図がそのまま受入基準のインプットになる
- ドキュメントレビュー:
- AIに質問させる形にすることで重要な論点が洗い出せる
- Claude CodeのAskUserQuestionツールで選択式回答（選択肢に推奨度・理由を付与）を活用
- 技術設計:
- DDDの実装パターンをAIのガードレールとしてCLAUDE.md/.claude/rules/に定義
- エンティティ・値オブジェクト・リポジトリ等のパターンを明文化
- アーキテクチャ制約・コーディング規約を事前定義し、毎回指示不要の状態を作る
- 静的解析でカバーできる範囲は決定論的にチェックし、AI判断はそれ以外に絞る
- 図でのレビュー:
- draw.ioでクラス図/データフローとして可視化することで妥当性を一目で判断できる
■ 4. チームの現在地を測る
- AI活用の成熟度フェーズ（ELEKS「AI SDLC Maturity Model」をベースにカスタマイズ）:
- フェーズ1（個人利用）: コーディングエージェントを個別に使う
- フェーズ2（スキル共通化）: チームで特定プロセス用のスキルを定義（点としてのスキル）
- フェーズ3（プロセス再定義・スキル連結）: AI前提でプロセスを再定義し、スキルのアウトプット/インプットを設計（線になる）
- フェーズ4（AIによる自律的開発）: 各プロセスでAIが自律的に判断する割合を増やす
- 全プロセスを一気に再設計するのは現実的でなく、まず現在地を測ることから始める
- どのプロセスから検査と適応のサイクル設計に着手するかを決める
■ 5. まとめ
- AI時代にもDDDのプラクティスはそのまま活用できる
- ドメインモデリングはAIに渡す「共通言語」となり、「ちょうどいい抽象度」が各プロセスのインプットになる
- DDDの実装パターンはAIの「ガードレール」となり、モデルとコードのルールを定義することでAIが守れる状態を作る
- 各プロセスで検査と適応のサイクルを設計し、アジャイルの基礎をAIで高速に回す
- まずは現在地を測り、1プロセスからDDDを試すことを推奨