---
name: creating-development-strategy
description: 開発戦略ドキュメント（docs/development/development_strategy.md）の作成・更新を支援。イテレーション計画（planning-releases でのイテレーション作成）を前提に、イテレーション群を序盤・中盤・終盤の局面に分け、各局面で採用する TDD アプローチ（アウトサイドイン / インサイドアウト）、ウォーキングスケルトンの基盤化、イテレーションのデモ項目を受け入れ基準（E2E / 受け入れテスト）とする方針、設計ドキュメント整合方針、Living Documentation によるドキュメントとコードの同期方針を定義する。「開発戦略を作りたい」「開発の進め方を局面ごとに決めたい」「アウトサイドインとインサイドアウトをどう使い分けるか整理したい」「ウォーキングスケルトンの方針を文書化したい」「デモ項目を受け入れ基準にする方針を決めたい」「デモ項目を BDD のシナリオにする方針を決めたい」「アウトサイドインで BDD を使うか決めたい」「イテレーションと設計ドキュメントの整合方針を決めたい」「Living Documentation を開発に組み込みたい」「ドキュメントをコードと同期させる方針を決めたい」「用語集や設計図をコードから生成する方針を決めたい」といった場面で必ず発動する。リリース計画・イテレーション計画を作成した後、開発フェーズに着手する前に開発戦略を定めておくことで、局面が変わってもアーキテクチャと品質の一貫性を保った開発を進められる。特定の言語・フレームワークに依存しない汎用スキルであり、参照元・コマンド・テスト構成は対象プロジェクトの実構成に合わせて解決する。
---

# 開発戦略作成

計画済みのイテレーション群を **序盤・中盤・終盤** の局面に分け、各局面で採用する TDD アプローチと横断的な進め方を定義する開発戦略ドキュメントを作成する。

本スキルは **イテレーション計画の作成（`planning-releases`）を前提** とする。開発戦略は個々のイテレーション計画の上位に位置し、「どのイテレーションでどちらのアプローチを採るか」「イテレーションの完了をどう受け入れ判定するか」という戦略レイヤーを明文化する。個々の TDD サイクルは対象プロジェクトのコーディング/テストガイドに従うため、本戦略はその上位で「テストの入口をどこに置き、レイヤーをどの順で貫通するか」を局面ごとに決める。局面が切り替わってもアーキテクチャ・品質・ユビキタス言語の一貫性を保つことが狙い。

本スキルは特定の言語・フレームワーク・アーキテクチャに依存しない。参照するガイド名・ディレクトリ・ビルド/テストコマンド・テスト構成は、対象プロジェクトの実構成を確認して当てはめる（憶測で書かない）。

## 成果物

- 配置場所: `docs/development/development_strategy.md`
- 正となる参照元（存在するものを使う。無いものは前提にしない）:
  - **イテレーション構成・デモ項目・受け入れ基準**: 各 `docs/development/iteration_plan-N.md`（**主たる入力**。イテレーション計画を前提とする）
  - **イテレーション × ユーザーストーリーのマクロ配分**: `docs/development/release_plan.md`（あれば SSoT。無ければ計画済みイテレーションから局面を導く）
  - **TDD アプローチ・手順・品質基準**: 対象プロジェクトのコーディング/テストガイド（例: `docs/reference/コーディングとテストガイド.md`）
  - **テスト種別・受け入れ/E2E 方針**: 対象プロジェクトのテスト戦略（例: `docs/design/test_strategy.md`）
  - **受け入れテストの記述形式（BDD / Gherkin）**: `docs/reference/BDD導入ガイド.md`（アウトサイドインの入口をシナリオで定義する場合）
  - **画面遷移・ナビゲーション**（UI を持つ場合）: UI 設計（例: `docs/design/ui_design.md`）
  - **ドキュメントとコードの同期方針（Living Documentation）**: `docs/reference/LivingDocumentation導入ガイド.md`。個別の手法は `アノテーション導入ガイド.md`・`ダイナミックキュレーション導入ガイド.md`・`ガイドツアー・サイトシーイング導入ガイド.md`（いずれも `docs/reference/`）

## 前提: イテレーション計画

開発戦略は計画済みのイテレーションを局面へ振り分ける。着手前に以下を満たすこと。

- `planning-releases` で少なくとも当面のイテレーション（最低でも序盤の 1-2 IT）が計画され、各 `iteration_plan-N.md` に **対象ユーザーストーリー** と **デモ項目（イテレーションレビューで実演するシナリオ）** が定義されていること。
- 全イテレーションが未計画でも、確定済みのイテレーション範囲で局面を割り当ててよい。未計画分は「局面割り当ての暫定案」として記し、計画確定時に追従する。

## 局面戦略の基本形

局面ごとに変えるのは **テストの入口** と **レイヤー貫通の順序** のみ。Red-Green-Refactor サイクルそのものは全局面で不変とする。局面数・順序はプロジェクトの性質（中核ドメインの複雑さ）に応じて調整してよい。

| 局面 | 対象イテレーション | 主アプローチ | 狙い |
| :--- | :--- | :--- | :--- |
| 序盤 | 最初の 1-2 IT | アウトサイドイン | 縦切りで「歩けるスケルトン」を通し、アーキテクチャ基盤の妥当性を早期検証 |
| 中盤 | 中核ドメインの IT | インサイドアウト | 複雑なドメインロジックをデータ層・ドメイン層から堅牢に作り込み、貧血ドメインモデルを回避 |
| 終盤 | 仕上げの IT | アウトサイドイン | 既存ドメインを業務シナリオ起点で結合し、リリース全体の一貫性を担保 |

### アプローチ選択の根拠

選択は対象プロジェクトの実装アプローチ選択フロー（コーディング/テストガイド）に対応づけて説明する。理由を書くことで、局面が機械的な区切りでなく論理的必然であることを示す。

- 序盤（アウトサイドイン）: API・基盤とも未実装 → UI/受け入れテストのニーズから API を導出し薄く貫通させるのが安全（「API 未実装 → アウトサイドイン活用」）。
- 中盤（インサイドアウト）: 複雑ドメインで貧血モデルを避けたい → データ層・ドメイン層の基盤を固めてから上位へ展開（「基盤未確立 → インサイドアウト推奨」）。
- 終盤（アウトサイドイン）: 基本実装済み × ドメイン複雑 → 既存集約を組み合わせ業務シナリオを受け入れテストで束ねる（「基本実装済み × 複雑 → アウトサイドイン推奨」）。

中核が単純な CRUD 中心で複雑ドメインを持たない場合は、中盤（インサイドアウト）を省略し序盤・終盤のアウトサイドイン 2 局面に簡素化してよい。

## デモ項目を受け入れ基準とする（局面横断）

イテレーション計画のデモ項目を、局面横断の受け入れ基準として位置づける。受け入れ/E2E テストはテストピラミッド上は最小でも、「業務価値が実際に成立するか」を担保する最終ゲートとして各 IT の DoD に組み込む。具体的なツールは対象プロジェクトに合わせる（UI があれば Playwright/Cypress 等の E2E、API 中心なら受け入れテスト/HTTP シナリオテスト）。

- **序盤**: 受け入れ/E2E テストの基盤をセットアップし、ウォーキングスケルトンの妥当性を担保する（UI を持つ場合は全ナビゲーション遷移、API 中心の場合は主要エンドポイントのスモーク）。
- **中盤・終盤**: 各 `iteration_plan-N.md` の **デモ項目をそのままパスする受け入れ/E2E テスト** を追加し、当該 IT の受け入れ基準とする。デモ項目を「操作/リクエストの系列」に翻訳してテスト化する。
- **判定**: 当該 IT のデモ項目テストがすべて green であることを DoD に含める。green でなければイテレーションはクローズしない。追加したテストは以降も実行し、既存デモ項目の回帰を防ぐ。

### アウトサイドインの入口を BDD で定義する

アウトサイドインは「一番外側のテストから内へ向かう」アプローチなので、その最外殻をどう書くかで戦略の質が決まる。デモ項目を自然言語のまま人が実演するだけにせず、**BDD のシナリオ（Gherkin）として書いて実行可能にする**と、デモ項目・受け入れテスト・ドキュメントが 1 つの成果物に収束する。記法・処理系・実装手順は `docs/reference/BDD導入ガイド.md` に従う。

BDD を採用するかはプロジェクトの判断だが、採用する場合は開発戦略に次を明記する。

- **どの局面で使うか** — 序盤・終盤のアウトサイドイン局面で使う。中盤のインサイドアウト局面ではドメイン層の単体テストが主役になるため、BDD シナリオは既存分の回帰実行にとどめる
- **誰が書くか** — デモ項目の元になるシナリオは、実装前にスリーアミーゴ（Biz / Dev / Tester）で合意する。AI-DLC ではこの合意が Mob Elaboration に相当し、シナリオが人と AI の契約になる
- **記述言語** — 対象プロジェクトのユビキタス言語に合わせる。日本語で業務を語るなら `# language: ja` の日本語 Gherkin で書き、プロジェクト内で言語を混在させない
- **処理系と配置** — 採用する Cucumber 系処理系（Cucumber-JS / Cucumber-JVM / Reqnroll など）、フィーチャーファイルとステップ定義のディレクトリ、実行コマンドを実構成に合わせて記載する
- **ステップ定義の責務** — ステップ定義は薄く保ち、業務ロジックを持ち込まない。アウトサイドインでは、ステップ定義から呼ぶインターフェースが「まだ無い内側」の設計を駆動する

BDD を使う場合、アウトサイドインの各サイクルは次の順に進む。

1. デモ項目を Gherkin のシナリオに翻訳し、スリーアミーゴで合意する
2. シナリオを実行する。ステップ定義が無いので **Undefined** になる
3. ステップ定義を書き、まだ無い内側のインターフェースを呼ぶ。**Red** を確認する
4. 内側へ一段下りて（UI → アプリケーション → ドメイン → データ）、各層を TDD で実装し **Green** にする
5. リファクタリングする。シナリオは業務語彙のまま変えない

BDD を採用しない場合でも、デモ項目を「操作/リクエストの系列」へ翻訳して受け入れテスト化する方針そのものは変わらない。開発戦略には、採用・不採用のどちらであるかとその理由を書く。

## ドキュメントをコードと同期させる（Living Documentation・局面横断）

局面が変わるたびに設計の理解がずれる最大の原因は、手書きのドキュメントがコードより遅れることである。Living Documentation は「知識の大半はすでにコード・テスト・コミット履歴にある。それを取り出し、足りない意図と根拠だけを補い、システムと同じ速さで更新する」という考え方で、局面移行時の一貫性維持を支える。原則と手法は `docs/reference/LivingDocumentation導入ガイド.md` に従う。

採用するかはプロジェクトの判断だが、開発戦略には採用・不採用とその理由を書く。採用する場合は、全イテレーションに一度に広げず、**これから書くコードから適用する**（既存コードへの一括適用はしない）。

### 局面ごとの重点

局面のアプローチと、そこで生まれる知識の種類に合わせて重点を変える。

| 局面 | 生まれる主な知識 | Living Documentation の重点 | 参照ガイド |
| :--- | :--- | :--- | :--- |
| 序盤（アウトサイドイン） | アーキテクチャ・レイヤー・外部アクター | アノテーション語彙（ステレオタイプ・レイヤー）を決める。レイヤー依存をアーキテクチャテストで検証し、アーキテクチャ図・コンテキスト図をコードから生成する仕組みをスケルトンに含める | アノテーション導入ガイド |
| 中盤（インサイドアウト） | ドメインの概念・集約・業務ルール | コア概念のハイライトと、ドメインモデルから生成する用語集（Living Glossary）でユビキタス言語をコードに一本化する。判断の根拠は ADR に残す。模範となる集約を示す | ダイナミックキュレーション導入ガイド |
| 終盤（アウトサイドイン） | 業務シナリオ・処理の流れ | デモ項目の処理チェーンをガイドツアーとして案内し、見どころをサイトシーイング・マップにまとめる。BDD を採用していればタグでシナリオダイジェストを作る | ガイドツアー・サイトシーイング導入ガイド |

### 開発戦略に明記すること

- **何をコードに持たせ、何を文書に残すか** — コードで表せる知識（構造・用語・依存関係）は生成し、`docs/design/` に手で複製しない。`docs/design/` にはコードから読み取れない意図・判断・却下した代替案を残す。「イテレーションごとの設計ドキュメント整合」の方針と矛盾しないよう、生成物と手書きの境界を書く
- **重複させた知識の検証方法** — やむを得ず重複する知識（公開 API の契約、シナリオとコードなど）は、不一致を検出するテストで守る。どのテストが整合性検証を担うかを書く
- **アノテーション語彙** — 採用する語彙（例: `ValueObject`・`CoreConcept`・`GuidedTour`）と置き場所。言語に合わせてアノテーション・属性・デコレータ・命名規約のいずれで表すかを決め、本質的な知識だけを付ける
- **生成と公開の自動化** — 用語集・図・ツアーの生成を、ビルドまたは CI のどの段階で実行し、どこに公開するか（対象プロジェクトの実構成に合わせる）。手作業で更新する一覧は作らない
- **根拠の記録先** — 設計判断は ADR（`creating-adr`）、変更ごとの意図はコミットメッセージ（`git-commit`）に残す

### 完了条件への組み込み

採用する場合、各イテレーションの完了条件に次を加える。

- 生成するドキュメント（用語集・図・ツアーなど）の生成がビルドまたは CI で成功している
- その IT で下した設計判断が ADR に記録され、コードで表せない根拠だけが `docs/design/` に反映されている
- 手書きでコードの内容を複製した一覧・図が新たに増えていない

## 作成の進め方

1. **参照元を読む**: コーディング/テストガイド（アプローチのシーケンス・品質基準・コミット規約）、計画済みの各 `iteration_plan-N.md`（対象 US・デモ項目）、あれば `release_plan.md`（マクロ配分）を読み込む。
2. **局面を割り当てる**: 計画済みイテレーションを局面へ振り分ける。基盤・入口の IT を序盤、複雑ドメイン中核の IT を中盤、例外・仕上げの IT を終盤とする。未計画分は暫定案とする。
3. **共通の TDD サイクル節を書く**: Red-Green-Refactor と品質チェック（対象プロジェクトの実ビルド/テストコマンド）、テスト種別とレイヤーの対応表を、実構成を確認して記載する。
4. **各局面の節を書く**: 目的・対象ユーザーストーリー・ワークフロー（アウトサイドイン/インサイドアウトのシーケンスに基づく PlantUML/Mermaid）・手順・完了条件を記述する。完了条件には該当 IT のデモ項目受け入れテスト green を含める。アウトサイドイン局面で BDD を採用する場合は、シナリオの記述言語・処理系・配置・ステップ定義の責務を明記する（`docs/reference/BDD導入ガイド.md` 参照）。
5. **横断方針を書く**: デモ項目を受け入れ基準とする方針、Living Documentation の採用可否と局面ごとの重点（`docs/reference/LivingDocumentation導入ガイド.md` 参照）、局面移行時の一貫性維持、アプローチが変わっても不変な規律（サイクル 3 原則・コミット単位・品質基準・アーキテクチャテスト常時グリーン）を明記する。
6. **インデックスを同期する**: `operating-docs --update` で `docs/development/index.md` と `mkdocs.yml` に開発戦略を追加する。
7. コミットは `git-commit`（ユーザー指示があるまでコミットしない）。

## ドキュメント構成（推奨見出し）

```markdown
# 開発戦略 - <プロジェクト名>

## 概要（参照元と Single Source of Truth の明記・イテレーション計画前提）
## 戦略の全体像（局面 → アプローチの対応表・図）
## 共通の TDD サイクル（Red-Green-Refactor・テスト種別対応・品質チェック）
## デモ項目を受け入れ基準とする（受け入れ/E2E 方針・BDD 採用可否）
## ドキュメントをコードと同期させる（Living Documentation 採用可否・局面ごとの重点・生成と公開）
## 序盤: アウトサイドイン（目的 / 対象 US / ワークフロー / 手順 / 完了条件）
## 中盤: インサイドアウト（同上。中核が単純なら省略可）
## 終盤: アウトサイドイン（同上）
## イテレーションごとの設計ドキュメント整合
## 局面移行時の一貫性維持
## 更新履歴
```

## 拡張トピック（プロジェクトに応じて追加）

### ウォーキングスケルトンの基盤化（受け入れ/E2E で担保）

序盤で横断基盤（DI 組み立て・認証/認可・共通ミドルウェア・レイアウトなど）を構築した直後に、UI を持つ場合は UI 設計の画面遷移図に従ったナビゲーション（ロール制御付き）と全ルートのプレースホルダ画面を一括作成し、これを骨格とする。横断関心事を業務ロジックが薄いうちに全画面で成立させ、以降の各 IT を「スタブを実画面へ差し替える」インクリメンタルな作業に落とす。

このスケルトンの妥当性は受け入れ/E2E テストで担保する。序盤の最初のタスクとして E2E 基盤（例: Playwright）をセットアップし、UI を持つ場合は各ナビゲーション遷移（全ルート到達・ロール別の表示/非表示/403）を、API 中心の場合は主要エンドポイントの疎通を、テストで green にすることをスケルトン成立の判定基準とする。対象ルート・表示ロール・担当 IT を対応表で明示する。

### イテレーションごとの設計ドキュメント整合

各 IT で `iteration_plan-N.md` の設計トピックと `docs/design/`（ドメイン/データモデル・UI 設計・アーキテクチャ・ADR）の整合を、着手時・実装中・完了時に確認する。イテレーション計画は局所ビュー、`docs/design/` は全体の「正」であり、実装で設計判断が変わったらその場で `docs/design/` を更新する（計画側だけに書いて放置しない）。着手時は `validating-iteration-plan` で検証し、構造変更はアーキテクチャテストとフルテストで裏取りする。

## 途中から再開・更新

既存の `docs/development/development_strategy.md` がある場合はまず内容を読み、局面割り当てやアプローチの追記・修正のみを行う。新たにイテレーションが計画された・イテレーション構成が変わった場合は、局面への割り当て表と各局面の対象 US・デモ項目受け入れテストを追従させ、更新履歴に日付と変更内容を追記する。

**Example:**

```text
ユーザー: 「中盤にイテレーションを 1 つ追加したので開発戦略を更新したい」
回答: 追加された iteration_plan-N.md の対象 US とデモ項目を確認し、
      development_strategy.md の中盤節の対象 US 表・ワークフロー・受け入れ基準に反映。
      戦略の全体像の対応表を更新し、更新履歴に追記して、
      operating-docs --update でインデックスを同期する。
```

## 注意事項

- 本スキルは **イテレーション計画を前提** とする。イテレーションが未計画なら先に `planning-releases` で計画する。少なくとも序盤の IT に対象 US とデモ項目が定義されていること。
- アプローチ選択は必ず対象プロジェクトのコーディング/テストガイドの選択フローに理由づける。「なぜこの局面でこのアプローチか」を書かないと、単なる区切り表になり戦略の価値が失われる。
- `ALWAYS`/`MUST` の羅列でなく、各局面の狙い（why）を説明する文体にする。局面が変わっても不変な規律（Red-Green-Refactor 3 原則・1 コミット 1 変更・品質基準・アーキテクチャテスト常時グリーン）は明記する。
- BDD を採用する場合、シナリオの記述形式・処理系・実装手順は `docs/reference/BDD導入ガイド.md` を正とし、本スキルでは「どの局面でどう使うか」という戦略判断だけを書く。記法の解説を開発戦略ドキュメントに複製しない。
- Living Documentation を採用する場合も同様に、手法の解説は `docs/reference/LivingDocumentation導入ガイド.md` と個別の導入ガイドを正とし、開発戦略には「どの局面で何を生成・記録するか」という判断だけを書く。開発戦略ドキュメント自体も、イテレーション計画や設計ドキュメントの内容を複製せず参照する。
- 品質チェックコマンド・テスト構成は対象プロジェクトの実構成を確認して合わせる（憶測で書かない。ビルド設定ファイル・テストディレクトリ・タスクランナー設定を実際に確認する）。
- 新規作成後は `docs/development/index.md` と `mkdocs.yml` を必ず同期する。ユーザーの指示があるまでコミットしない。

## 関連スキル

- `planning-releases` — リリース・イテレーション計画（**本スキルの前提入力**。局面割り当てとデモ項目の供給元）
- `orchestrating-development` — 開発フェーズ全体の TDD ワークフロー（本戦略の実行フェーズ）
- `validating-iteration-plan` — イテレーション計画と設計ドキュメントの整合検証
- `developing-backend` / `developing-frontend` — 各局面での TDD 実装
- `creating-adr` — 局面ごとの設計判断の根拠の記録（Living Documentation の根拠の記録先）
- `operating-docs` — インデックス同期（`--update`）
- `git-commit` — 作成後のコミット