---
name: validating-design
description: 開発戦略・イテレーション計画・設計ドキュメント・過去のイテレーション計画の間で、設計トピックの整合性を横断検証する。3 軸で検証する — (A) 開発戦略（docs/development/development_strategy.md）とイテレーション計画の局面・アプローチ整合、(B) イテレーション計画と docs/design 設計ドキュメント群の整合、(C) 過去のイテレーション計画の設計トピックとの整合（命名・設計判断・ユビキタス言語の連続性）。「設計整合性をチェックして」「開発戦略とイテレーション計画がずれていないか確認したい」「イテレーション計画と docs/design の設計が一致しているか検証したい」「過去のイテレーションの設計と矛盾していないか確認したい」「設計トピックの一貫性を検証したい」といった場面で必ず発動する。イテレーション計画を作成・更新した直後や開発着手前に本検証を実施することで、局面をまたいでも設計判断とユビキタス言語の一貫性を保てる。単一計画とアップストリーム設計の詳細突合は validating-iteration-plan、本スキルはそれに戦略整合と過去計画との連続性検証を加えた広域版。
---

# 設計整合性の横断検証

開発が複数イテレーションにまたがると、設計トピック（集約名・テーブル名・URL パス・アプローチ・ユビキタス言語）が、開発戦略・当該計画・設計ドキュメント・過去計画の間で少しずつずれていく。ずれは実装の不整合に直結するため、計画作成・更新の直後に横断検証して開発着手前に解消する。

本スキルは 3 軸で検証する。各軸は独立に実行でき、不整合を見つけたら**設計ドキュメントと開発戦略を「正」とし**、イテレーション計画側を修正する（戦略や設計判断そのものを見直すべき重大なずれは、その旨を報告して判断を仰ぐ）。

## 検証の 3 軸

| 軸 | 検証対象 | 正となるドキュメント | 主眼 |
| :--- | :--- | :--- | :--- |
| A | 開発戦略 ↔ イテレーション計画 | `docs/development/development_strategy.md` | 局面割り当てとアプローチの一致 |
| B | イテレーション計画 ↔ 設計ドキュメント | `docs/design/*` | 設計トピックの相互トレーサビリティ |
| C | 今回計画 ↔ 過去のイテレーション計画 | `docs/development/iteration_plan-*.md`（既存分） | 命名・設計判断・ユビキタス言語の連続性 |

> 軸 B のドキュメント単位の詳細突合（ドメイン/データモデル・UI のフィールド名・型・遷移）は `validating-iteration-plan` が担う。本スキルの軸 B は「設計トピックが計画と設計ドキュメントの双方向で欠落なく対応しているか」というカバレッジ観点に絞り、詳細突合が必要なら `validating-iteration-plan` に委譲する。

## 軸 A: 開発戦略とイテレーション計画の整合

開発戦略はイテレーションを序盤・中盤・終盤の局面に割り当て、各局面のアプローチ（アウトサイドイン / インサイドアウト）を定める。当該イテレーション計画の設計・タスクが、戦略が指定する局面・アプローチと一致しているかを検証する。

**チェック項目**:

- [ ] 当該イテレーション番号が、開発戦略の局面割り当て表でどの局面に属するかを特定できる
- [ ] 計画の設計・タスクの進め方（テストの入口・レイヤー貫通順）が、その局面のアプローチと一致している（例: 中盤=インサイドアウトなのに、計画が受け入れテスト起点のアウトサイドイン手順になっていないか）
- [ ] 序盤の場合、ウォーキングスケルトン基盤化（ナビゲーション一括作成等）の方針が計画に反映されているか
- [ ] 戦略が定める「イテレーションごとの設計ドキュメント整合」フロー（着手時検証・実装中の docs/design 更新・完了時の取り込み）が計画の進め方と矛盾しないか
- [ ] 戦略の対象ユーザーストーリー表と計画の対象ストーリーが一致している（局面をまたいで US が移動していないか）
- [ ] 局面移行の境界イテレーションの場合、移行時の一貫性確認事項（前局面パターンの踏襲・リリース条件）が考慮されているか

**よくある不整合**:

- 戦略では中盤（インサイドアウト）の IT なのに、計画のワークフローがアウトサイドインで書かれている
- 戦略の局面別 US 割り当てとリリース計画・計画の US がずれている（戦略更新漏れ）
- 序盤 IT なのにウォーキングスケルトン基盤化への言及がない

## 軸 B: イテレーション計画と設計ドキュメントの整合（トピックカバレッジ）

計画の「設計」セクションに現れる各設計トピックが、`docs/design/` の該当ドキュメントに存在し、逆に当該ストーリーが要する設計ドキュメントの要素が計画に取り込まれているか、双方向で確認する。

**チェック項目**:

- [ ] 計画のドメインモデルトピック（集約・エンティティ・値オブジェクト）が `domain-model.md` に存在する
- [ ] **【絶対項目】対象スコープの設計図が計画の「設計」節に含まれているか**: 当該 IT の実装対象に絞った (1) ドメインモデル図、(2) 状態遷移図、(3) ER 図、(4) 画面遷移図 の 4 図を PlantUML で「設計」節に掲載する（`docs/design/` の全体図をコピーせず、当該 IT スコープに絞る。後続 IT の要素は破線・コメントで区別し、`docs/design/` へ反映が要る新規要素は注記する）。状態を持たない集約が対象 IT に無い場合は状態遷移図を、画面を伴わない IT の場合は画面遷移図を省略可とし、その旨を明記する
- [ ] **【ドリフト再発防止】新規追加した「ドメインサービス（Calculator/Policy 等）」「BC 固有の列挙型」が `domain-model.md` の要素表に定義行として載っているか**（集約・VO だけでなくドメインサービス・enum も要素表に含める。IT1/IT2/IT3 で反復したドリフトの防止）
- [ ] **【ドリフト再発防止】`ui_design.md` の salt ワイヤーフレーム本体が仕様セクションと同期しているか**（仕様だけ更新して図が旧内容のまま、を防ぐ）
- [ ] 計画のデータモデルトピック（テーブル・カラム）が `data-model.md` に存在する
- [ ] 計画の UI トピック（画面・URL・遷移）が `ui_design.md`（画面一覧・画面遷移図）に存在する
- [ ] **【絶対項目】ナビゲーション整合性**: 当該 IT で新規／実画面化する画面が `ui_design.md` のナビゲーション構成表に表示ロール付きで存在し、かつ計画に「navbar（`_Layout.cshtml`）とダッシュボード（`Home/Index.cshtml`）へロール条件付きで反映＋ナビ表示の検証テスト」がタスク／注記として含まれている（個別画面の整合性とナビゲーション整合性は両方確認する。片方だけでは不足）
- [ ] 計画の API 設計・ディレクトリ構成が `architecture_backend.md` / `architecture_frontend.md` と整合している
- [ ] 逆方向: 対象ストーリーの受入基準が要求する設計要素で、設計ドキュメントにあるのに計画に取り込まれていないものがないか
- [ ] 実装で設計判断が変わった箇所が「注」として計画に明記され、`docs/design/` への反映要否が示されているか
- [ ] ADR が必要な設計判断（構造変更）が計画の ADR 節に挙がっているか

**詳細突合が必要な場合**: フィールド名・型・命名規約・遷移方式（GET/PRG）・htmx パターンまで踏み込む場合は `validating-iteration-plan` を実行する。本軸はトピックの過不足検出に留める。

## 軸 C: 過去のイテレーション計画の設計トピックとの整合

`docs/development/iteration_plan-*.md` の既存分（今回より前の全計画）を確認し、過去に確立した設計トピックと今回計画が矛盾していないかを検証する。設計ドキュメントに未反映の設計判断が過去計画にのみ残っている場合、それも「正」として扱う。

**チェック項目**:

- [ ] 集約・エンティティ・値オブジェクトの命名が過去計画と一致している（同じ概念に別名を当てていないか）
- [ ] テーブル名・カラム名・命名規約（単複・サロゲートキー + UK・FK 参照先）が過去計画と一貫している
- [ ] URL パス・画面名・ナビゲーション項目が過去計画・ウォーキングスケルトンと連続している
- [ ] ユビキタス言語（用語）が過去計画と一致している（例: 請求書/精算書、追跡番号の呼称ブレ）
- [ ] 過去計画で確立したパターン（ポート/ACL・UoW・イベント発行・スタブ契約）を今回も踏襲しているか、変える場合は理由と ADR があるか
- [ ] 過去計画の「持ち越し事項」「次のステップ」「注」で今回対応と明記された設計事項が、今回計画に反映されているか
- [ ] 集約フィールドの段階的追加（nullable/Maybe での導入等）の方針が過去の進め方と整合しているか

**よくある不整合**:

- 過去計画で `Location` 共有カーネルを使う設計だったのに、今回計画が locode を `string` 直持ちしている
- 過去計画のテーブル命名（単数形・サロゲートキー）と今回が食い違う
- 過去計画で定義済みの用語と別の用語を使う（ユビキタス言語の分岐）
- 過去計画で「IT(N) で対応」と明記された設計事項が今回計画から漏れている

## 検証手順

1. 対象イテレーション番号を特定する（引数がなければ最新の `iteration_plan-*.md`）。
2. 軸 A: `development_strategy.md` を読み、局面割り当てとアプローチを確認して計画と突合する。
3. 軸 B: 計画の「設計」節を読み、`docs/design/` 各ドキュメントとトピックの過不足を突合する。あわせて対象スコープの 4 図（ドメインモデル図・状態遷移図・ER 図・画面遷移図）が「設計」節に掲載されているかを確認し、欠落があれば当該 IT スコープに絞って追加する。
4. 軸 C: 今回より前の `iteration_plan-*.md` を全て読み、命名・設計判断・ユビキタス言語の連続性を突合する。
5. 各軸は並列実行可能。サブエージェントが使える場合は 3 軸を並列に走らせると速い。
6. 不整合を発見したら計画を修正する（設計ドキュメント・開発戦略・過去計画が正）。戦略や設計そのものの見直しが要る重大なずれは報告して判断を仰ぐ。

## 検証結果の報告

```markdown
## 設計整合性検証結果

### 検証対象
- イテレーション計画: `docs/development/iteration_plan-N.md`
- 局面（開発戦略）: 序盤 / 中盤 / 終盤（アプローチ: アウトサイドイン / インサイドアウト）

### 検証結果サマリー

| 軸 | 検証対象 | 結果 | 不整合件数 |
|----|---------|------|-----------|
| A | 開発戦略 ↔ 計画 | OK / NG | N 件 |
| B | 計画 ↔ 設計ドキュメント | OK / NG | N 件 |
| C | 計画 ↔ 過去計画 | OK / NG | N 件 |

### 不整合一覧（NG の場合のみ）

#### 軸 X: 〇〇との不整合

| # | 不整合内容 | 計画の記述 | 正しい記述（正となる出典） | 出典 | 修正要否 |
|---|----------|-----------|------------------------|------|---------|
| 1 | ... | ... | ... | development_strategy.md / design/xxx.md / iteration_plan-M.md | 要修正 |
```

## 注意事項

- 検証は計画の作成・更新直後、開発着手前に実施する。
- 正の優先順位は「設計ドキュメント・開発戦略 > 過去計画 > 今回計画」。ただし設計ドキュメント未反映の設計判断が過去計画にのみ残る場合、その判断を正として扱い、必要なら `docs/design/` への反映を促す。
- 単一計画のフィールド単位の詳細突合は `validating-iteration-plan` に委譲し、本スキルは戦略整合・トピックカバレッジ・過去計画との連続性に集中する（役割の重複を避ける）。
- ユーザーの指示があるまでコミットしない。

## 関連スキル

- `validating-iteration-plan` — 単一計画とアップストリーム設計のフィールド単位の詳細突合（軸 B の詳細版）
- `creating-development-strategy` — 開発戦略の作成・更新（軸 A の正の出典）
- `planning-releases` — イテレーション計画の作成（検証対象の入力）
- `operating-docs` — 検証で判明した設計ドキュメント更新後のインデックス同期
- `git-commit` — 修正後のコミット