decomposition-planning-roadmap

分解の計画とロードマップ

このスキルでは、モノリシックアーキテクチャから分散アーキテクチャへの移行を導くため、構造化された分解計画とロードマップを作成します。分解パターンを通じて作業の優先順位を決め、進捗を追跡します。

使用方法

クイックスタート

分解計画の作成を依頼します。

• 「このコードベースの分解ロードマップを作成してください」
• 「分解移行戦略を計画してください」
• 「コンポーネント分析に基づいて分解作業に優先順位を付けてください」
• 「段階的な分解計画を作成してください」

使用例

例 1：完全なロードマップ

User: "Create a decomposition roadmap for this codebase"

The skill will:
1. Analyze current codebase state
2. Identify decomposition patterns to apply
3. Prioritize work based on risk and value
4. Create phased roadmap
5. Generate architecture stories
6. Estimate effort and dependencies

例 2：優先順位を付けた計画

User: "Prioritize decomposition work based on component analysis"

The skill will:
1. Review component inventory and dependencies
2. Assess risk and value for each pattern
3. Prioritize patterns by impact
4. Create prioritized work plan

例 3：フェーズ計画

User: "Create a phased decomposition plan"

The skill will:
1. Group decomposition patterns into phases
2. Identify dependencies between phases
3. Create phase timeline
4. Define phase success criteria

手順

1. 現状を評価する：コードベースを分析し、完了済みの作業を特定します
2. パターンを特定する：適用する分解パターンを決定します
3. 作業に優先順位を付ける：リスク、価値、依存関係に基づいてパターンを順位付けします
4. ロードマップを作成する：マイルストーンを含む段階的な計画を作成します
5. ストーリーを生成する：追跡用のアーキテクチャストーリーを作成します
6. 進捗を追跡する：分解フェーズを通じて進捗を監視します

使用するタイミング

次の場合にこのスキルを適用します。

• 分解作業を開始するとき
• モノリスから分散アーキテクチャへの移行を計画するとき
• 分解作業に優先順位を付けるとき
• 分解用のアーキテクチャストーリーを作成するとき
• 分解パターンを通じて進捗を追跡するとき
• 分解に構造化されたアプローチが必要なとき
• 作業量と依存関係を見積もりたいとき

主な概念

分解パターンの順序

コンポーネントベースの6つの分解パターンは、次の順序で適用します。

1. コンポーネントの特定と規模の把握 - 現状を把握します
2. 共通ドメインコンポーネントの収集 - 重複を見つけます
3. コンポーネントのフラット化 - 孤立したクラスを取り除きます
4. コンポーネントの依存関係の特定 - 結合度を評価します
5. コンポーネントドメインの作成 - ドメインごとにグループ化します
6. ドメインサービスの作成 - サービスとして抽出します

段階的なアプローチ

分解は通常、次のフェーズで進めます。

フェーズ 1：分析と準備（パターン 1～4）

• コンポーネントの特定と規模の把握
• 共通コンポーネントの検出
• コンポーネントのフラット化
• 依存関係の分析

フェーズ 2：ドメインの整理（パターン 5）

• ドメインの特定
• コンポーネントのグループ化
• 名前空間のリファクタリング

フェーズ 3：サービスの抽出（パターン 6）

• ドメインサービスの作成
• サービスの抽出
• API 境界の定義

優先順位付けの要因

分解作業に優先順位を付ける際は、次の点を考慮します。

• リスク：リスクが低いほど抽出しやすく、依存関係も少なくなります
• 価値：価値が高いほど、ビジネス上重要で影響も大きくなります
• 依存関係：独立して実施できるかどうか
• 複雑さ：単純であれば、コンポーネントが少なく境界も明確です
• 結合度：結合度が低いほど、抽出しやすくなります

分析プロセス

フェーズ 1：現状を評価する

すでに完了している作業を分析します。

1. コンポーネント一覧を確認する

   • コンポーネントは特定され、規模が把握されていますか？
   • コンポーネント一覧のドキュメントはありますか？
   • 規模の大きすぎるコンポーネントは特定されていますか？

2. 共通コンポーネントの分析を確認する

   • 共通ドメインコンポーネントは特定されていますか？
   • 統合の機会は記録されていますか？
   • 結合への影響は分析されていますか？

3. コンポーネントの構造を確認する

   • コンポーネントはフラット化されていますか？
   • 孤立したクラスはありますか？
   • コンポーネントの構造は整理されていますか？

4. 依存関係の分析を確認する

   • コンポーネントの依存関係はマッピングされていますか？
   • 結合度の分析は完了していますか？
   • 実現可能性は評価されていますか？

5. ドメインの特定状況を確認する

   • ドメインは特定されていますか？
   • コンポーネントはドメインごとにグループ化されていますか？
   • 名前空間はドメインに沿っていますか？

6. サービスの抽出状況を確認する

   • サービスは抽出されていますか？
   • ドメインサービスは作成されていますか？
   • サービスベースのアーキテクチャは導入されていますか？

出力：完了済みの作業と残作業を示す現状評価

フェーズ 2：適用するパターンを特定する

適用する必要がある分解パターンを判断します。

1. パターンの前提条件を確認する

   • パターン 1：常に必要（基盤）
   • パターン 2：共通コンポーネントが存在する場合に必要
   • パターン 3：コンポーネントに階層がある場合に必要
   • パターン 4：常に必要（実現可能性の確認）
   • パターン 5：サービスを抽出する前に必要
   • パターン 6：最終ステップ（サービスの抽出）

2. パターンの完了状況を確認する

   • 完了したパターンはどれですか？
   • 進行中のパターンはどれですか？
   • 未着手のパターンはどれですか？

3. 不足しているパターンを特定する

   • まだ適用が必要なパターンは何ですか？
   • パターンの適用を妨げているものは何ですか？
   • どのような依存関係がありますか？

出力：適用するパターンのステータス一覧

フェーズ 3：作業に優先順位を付ける

分解パターンと作業項目に優先順位を付けます。

1. リスクを評価する

   • 低リスク：インフラストラクチャコンポーネント、独立した機能
   • 中リスク：一部の依存関係があるドメインコンポーネント
   • 高リスク：中核となるビジネスロジック、結合度が高い部分

2. 価値を評価する

   • 高価値：ビジネス上重要で、影響が大きく、変更頻度が高い
   • 中価値：重要だが、不可欠ではない
   • 低価値：あると便利だが、影響は小さい

3. 依存関係を評価する

   • 独立：他の作業なしで実施できる
   • 依存：先に他のパターンや作業が必要
   • ブロッキング：他の作業の進行を妨げる

4. 優先度スコアを算出する

   Priority = (Value × 3) - (Risk × 2) - (Dependencies × 1)
   
   Higher score = Higher priority
   

出力：パターンと作業項目の優先順位付き一覧

フェーズ 4：段階的なロードマップを作成する

マイルストーンを含む段階的なロードマップを作成します。

1. フェーズを定義する

   • フェーズ 1：分析と準備
   • フェーズ 2：ドメインの整理
   • フェーズ 3：サービスの抽出
   • フェーズ 4：最適化と改善

2. パターンを各フェーズに割り当てる

   • 各パターンはどのフェーズに該当しますか？
   • 各フェーズ内の順序はどうなりますか？
   • フェーズ間にどのような依存関係がありますか？

3. マイルストーンを設定する

   • 各フェーズの完了を示すものは何ですか？
   • 成功基準は何ですか？
   • どのような成果物が期待されますか？

4. 期間を見積もる

   • 各フェーズにはどのくらいの時間がかかりますか？
   • どのような依存関係がありますか？
   • クリティカルパスは何ですか？

出力：期間とマイルストーンを含む段階的なロードマップ

フェーズ 5：アーキテクチャストーリーを作成する

作業を追跡するためのアーキテクチャストーリーを作成します。

1. ストーリーテンプレートを作成する

   As an architect, I need to [apply pattern/refactor component]
   to support [architectural characteristic/business need]
   so that [benefit/outcome]
   

2. 作業を細分化する

   • パターンの適用ごとに 1 つのストーリーを作成する
   • 大規模なリファクタリングごとに 1 つのストーリーを作成する
   • ドメインのグループ化ごとに 1 つのストーリーを作成する

3. 受け入れ基準を追加する

   • 何をもって「完了」としますか？
   • 成功を検証する指標は何ですか？
   • 完了を確認するテストは何ですか？

4. 作業量を見積もる

   • ストーリーポイントまたは所要時間の見積もり
   • 複雑さの評価
   • リスク要因

出力：見積もりを含むアーキテクチャストーリーの一覧

フェーズ 6：進捗を追跡する

分解の進捗を監視します。

1. パターンの完了状況を追跡する

   • 完了したパターンはどれですか？
   • 進行中のパターンはどれですか？
   • ブロックされているパターンはどれですか？

2. ストーリーの完了状況を追跡する

   • 完了したストーリー
   • 進行中のストーリー
   • 未着手のストーリー

3. 指標を追跡する

   • 特定したコンポーネント数
   • リファクタリングしたコンポーネント数
   • 作成したドメイン数
   • 抽出したサービス数

4. ブロッカーを特定する

   • 進捗を妨げているものは何ですか？
   • 不足している依存関係は何ですか？
   • 新たに発生したリスクは何ですか？

出力：進捗ダッシュボードとステータスレポート

出力形式

分解ロードマップ

# Decomposition Roadmap

## Current State Assessment

**Completed Patterns**:

- ✅ Pattern 1: Identify and Size Components
- ✅ Pattern 2: Gather Common Domain Components
- ⚠️ Pattern 3: Flatten Components (in progress)
- ❌ Pattern 4: Determine Component Dependencies (not started)
- ❌ Pattern 5: Create Component Domains (not started)
- ❌ Pattern 6: Create Domain Services (not started)

**Key Findings**:

- 75 components identified
- 3 common domain components found
- 2 oversized components need splitting
- High database coupling detected

## Phased Roadmap

### Phase 1: Analysis & Preparation (Weeks 1-4)

**Goal**: Complete component analysis and refactoring

**Patterns**:

1. Complete Pattern 3: Flatten Components
2. Apply Pattern 4: Determine Component Dependencies
3. Refactor oversized components

**Milestones**:

- Week 2: Component flattening complete
- Week 4: Dependency analysis complete

**Deliverables**:

- Flattened component structure
- Dependency diagram
- Feasibility assessment

### Phase 2: Domain Organization (Weeks 5-8)

**Goal**: Organize components into domains

**Patterns**:

1. Apply Pattern 5: Create Component Domains
2. Refactor namespaces for domain alignment

**Milestones**:

- Week 6: Domains identified
- Week 8: Namespace refactoring complete

**Deliverables**:

- Domain map
- Refactored component namespaces
- Domain documentation

### Phase 3: Service Extraction (Weeks 9-16)

**Goal**: Extract domains to domain services

**Patterns**:

1. Apply Pattern 6: Create Domain Services
2. Extract services incrementally

**Milestones**:

- Week 12: First domain service extracted
- Week 16: All domain services extracted

**Deliverables**:

- Domain services deployed
- API boundaries defined
- Service documentation

優先順位付き作業計画

## Prioritized Work Plan

### High Priority (Do First)

1. **Complete Component Flattening** (Priority: 9/10)
   - Risk: Low
   - Value: High (enables domain grouping)
   - Dependencies: None
   - Effort: 2 weeks

2. **Dependency Analysis** (Priority: 8/10)
   - Risk: Low
   - Value: High (validates feasibility)
   - Dependencies: Component flattening
   - Effort: 1 week

### Medium Priority (Do Next)

3. **Domain Identification** (Priority: 7/10)
   - Risk: Medium
   - Value: High (enables service extraction)
   - Dependencies: Dependency analysis
   - Effort: 2 weeks

### Low Priority (Do Later)

4. **Service Extraction** (Priority: 5/10)
   - Risk: High
   - Value: High (final goal)
   - Dependencies: Domain identification
   - Effort: 8 weeks

アーキテクチャストーリー

## Architecture Stories

### Story 1: Flatten Ticket Components

**As an architect**, I need to flatten the Ticket component hierarchy
to support better component organization
so that components exist only as leaf nodes.

**Acceptance Criteria**:

- [ ] No orphaned classes in root namespaces
- [ ] All components are leaf nodes
- [ ] Component structure validated

**Estimate**: 5 story points
**Priority**: High
**Dependencies**: None

### Story 2: Identify Component Domains

**As an architect**, I need to group components into logical domains
to support service-based architecture
so that components can be extracted to domain services.

**Acceptance Criteria**:

- [ ] All components assigned to domains
- [ ] Domain boundaries validated with stakeholders
- [ ] Domain map created

**Estimate**: 8 story points
**Priority**: High
**Dependencies**: Component flattening complete

進捗ダッシュボード

## Decomposition Progress Dashboard

### Pattern Completion Status

| Pattern                    | Status         | Progress | Blocker                 |
| -------------------------- | -------------- | -------- | ----------------------- |
| Identify & Size Components | ✅ Complete    | 100%     | None                    |
| Gather Common Components   | ✅ Complete    | 100%     | None                    |
| Flatten Components         | ⚠️ In Progress | 60%      | None                    |
| Determine Dependencies     | ❌ Not Started | 0%       | Waiting on flattening   |
| Create Domains             | ❌ Not Started | 0%       | Waiting on dependencies |
| Create Domain Services     | ❌ Not Started | 0%       | Waiting on domains      |

### Story Completion Status

**Completed**: 5 stories (25%)
**In Progress**: 3 stories (15%)
**Not Started**: 12 stories (60%)

### Key Metrics

- Components Identified: 75
- Components Refactored: 45 (60%)
- Domains Created: 0
- Services Extracted: 0

分析チェックリスト

現状の評価：

• コンポーネント一覧を確認しました
• 共通コンポーネントの分析を確認しました
• コンポーネントの構造を評価しました
• 依存関係の分析を確認しました
• ドメインの特定状況を確認しました
• サービス抽出の状況を評価しました

パターンの特定：

• 完了しているパターンを特定しました
• 進行中のパターンを特定しました
• 適用が必要なパターンを特定しました
• パターン間の依存関係を確認しました

優先順位付け：

• 各パターンのリスクを評価しました
• 各パターンの価値を評価しました
• 依存関係を評価しました
• 優先度スコアを算出しました

ロードマップの作成：

• フェーズを定義しました
• パターンをフェーズに割り当てました
• マイルストーンを設定しました
• スケジュールを見積もりました

ストーリーの作成：

• アーキテクチャストーリーを作成しました
• 受け入れ条件を追加しました
• 作業量を見積もりました
• ストーリーに優先順位を付けました

進捗管理：

• 追跡の仕組みを整えました
• 指標を定義しました
• ダッシュボードを作成しました
• 障害要因を特定しました

実装メモ

ロードマップのテンプレート

シンプルなロードマップ（小規模プロジェクト向け）：

• フェーズ 1：分析（2-4 週間）
• フェーズ 2：リファクタリング（4-6 週間）
• フェーズ 3：抽出（8-12 週間）

詳細なロードマップ（大規模プロジェクト向け）：

• フェーズ 1：分析と準備（4-8 週間）
• フェーズ 2：ドメインの整理（4-6 週間）
• フェーズ 3：サービスの抽出（12-16 週間）
• フェーズ 4：最適化（4-8 週間）

優先順位付けマトリックス

優先順位付けには 2x2 マトリックスを使用します：

High Value, Low Risk    | High Value, High Risk
(Do First)              | (Do Carefully)
────────────────────────┼──────────────────────
Low Value, Low Risk     | Low Value, High Risk
(Do Later)              | (Avoid/Defer)

ストーリーの見積もり

ストーリーポイントまたは時間で見積もります：

ストーリーポイント（フィボナッチ数列）：

• 1：ごく簡単（数時間）
• 2：簡単（1 日）
• 3：小規模（2-3 日）
• 5：中規模（1 週間）
• 8：大規模（2 週間）
• 13：非常に大規模（3 週間以上）

時間の見積もり：

• 小規模：1-3 日
• 中規模：1-2 週間
• 大規模：2-4 週間
• 非常に大規模：1 か月以上

ベストプラクティス

推奨事項 ✅

• 分析パターン（パターン 1-4）から始めます
• リスクが低く、価値の高い作業を優先します
• 追跡用にアーキテクチャストーリーを作成します
• 明確なマイルストーンと成功基準を設定します
• 定期的に進捗を追跡します
• 学びに応じてロードマップを調整します
• 優先順位について関係者と協力します

避けるべきこと ❌

• 分析パターンを省略しないでください
• サービスの抽出を早く始めすぎないでください
• パターン間の依存関係を無視しないでください
• 非現実的なスケジュールを作成しないでください
• 進捗管理を省略しないでください
• 関係者との検証を忘れないでください
• 実現可能性の評価なしに進めないでください

他のスキルとの連携

このスキルは、他の分解スキルの使用を調整します：

1. コンポーネントの特定と規模の見積もり → 計画の基盤
2. 共通ドメインコンポーネントの検出 → 統合作業を特定
3. コンポーネントのフラット化 → ドメインのグループ化に備える
4. コンポーネントの依存関係分析 → 実現可能性を検証
5. ドメインの特定とグループ化 → サービス抽出を可能にする
6. 分解計画とロードマップ（このスキル）→ 全体を調整

次のステップ

ロードマップを作成した後：

1. 関係者と確認する - 計画への合意を得ます
2. フェーズ 1 を開始する - 分析パターンから始めます
3. 進捗を追跡する - 完了状況と障害要因を監視します
4. 必要に応じて調整する - 学びに応じてロードマップを更新します
5. マイルストーンを祝う - 進捗を称えます

注記

• ロードマップは定期的に更新する、生きたドキュメントにします
• 学びが深まるにつれて、優先順位が変わることがあります
• パターン間の依存関係を必ず考慮します
• 先に進む前に実現可能性を評価することが重要です
• 成功には関係者との協力が不可欠です
• 進捗を追跡することで、問題を早期に特定できます