implementation-planning

実装計画

承認済みの要件または仕様を、実行可能なデリバリープランに変換します。 このスキルは計画を立てるための規律であり、コードや仕様を作成するものでも、ライフサイクルをオーケストレーションするものでもありません。

このスキルを読み込むタイミング

入力が承認済みの要件、仕様、または決定事項であり、依存関係、順序付け、リスク、検証を考慮した具体的なデリバリープランを作成する必要がある場合に読み込みます。

トリガー	例
承認済みの SPEC.md またはプロダクトブリーフについてデリバリープランが必要	「決済チェックアウト仕様の実装計画を立ててください」
チーム横断または複数リポジトリにまたがる機能について作業の調整が必要	「3つのサービスにまたがる ID 移行変更の展開計画を立ててください」
データ移行に段階的な実行計画が必要	「ロールバック段階を含むスキーマ移行の計画を立ててください」
リスクの高い変更や重大な変更に展開戦略が必要	「認証プロバイダーの置き換えを段階的に展開する計画を立ててください」
複数のワークストリームに依存関係のマッピングとクリティカルパス分析が必要	「プラットフォームのアップグレードにおける依存関係とクリティカルパスを整理してください」

使用しない場合

• 承認前の探索やニーズの把握 — 入力がまだ承認済みの要件ではありません。product-discovery に引き継いでください。
• 仕様を一から作成する場合 — 承認済みの仕様がまだありません。spec-driven-development に引き継いでください。
• コーディング、実装、またはアーキテクチャ設計 — 計画は完了しており、これから実行します。backend-engineering、frontend-engineering、または software-architecture-analysis に引き継いでください。
• neckbeard のイシューから PR までのデリバリーフロー — このスキルは作業を計画しますが、neckbeard のライフサイクルゲート、デリバリーパケットの順序付け、フェーズのオーケストレーションは実行しません。デリバリーの実行は別の領域です。
• 前提となる決定が未承認 — 要件または仕様が承認されていない場合は、停止してください。未承認の作業を計画することは明示的な停止条件です。不足している承認を記録してエスカレーションし、計画を作成しないでください。
• 実行全体にコントロールプレーンのプロトコルが必要 — インテント契約、作業の分類、自律性のゲート、トリアージとしてのレビュー、計画とその実行を取り巻く失敗時の振り分けが必要な場合です。bmad に引き継いでください。このスキルはデリバリープランを作成し、bmad はインテントからデリバリーまでの作業を一貫して実行するプロトコルを担います。

計画後の継続的なマイルストーンレビュー、予測の変更、スポンサーの意思決定、プロジェクトの完了については、technical-project-management に引き継いでください。 複数の関連プロジェクトにまたがる調整、共有キャパシティ、プログラムの便益、または変革の成果については、technical-program-management に引き継いでください。 詳細な作業分解と依存関係計画の保守は、引き続きこのスキルで行います。

開始ゲート：前提条件となる承認

計画作業を始める前に、入力となる要件または仕様が、権限を持つ意思決定者によって承認済みであることを確認してください。承認済みの入力とは、レビューゲート（SDD 仕様レビュー、プロダクトブリーフの承認、アーキテクチャ決定記録の承認、または同等の手続き）を通過したものです。

入力が未承認の場合：

1. 停止します。 計画案、部分的な作業分解、または「承認済みと仮定した」成果物を作成しないでください。
2. 不足している承認を明示します。未決の決定事項と、誰（役職または氏名）が承認する必要があるかを示してください。
3. 適切な上流スキルに引き継ぎます：
   • 仕様がない → spec-driven-development
   • 要件が未検証 → product-discovery
   • アーキテクチャ上の決定が未決 → adr-authoring

このゲートがあるのは、未承認の基盤の上に作成した計画が、後続のすべてのチームの時間を無駄にし、誤った確実性を生み出すためです。

コアワークフロー

1. 承認済みの入力を取り込む。 承認済みの要件、仕様、または意思決定記録を読みます。情報源、承認日、承認者、明示的な制約や対象外事項を記録します。

2. 作業に分解する。 承認済みの範囲を、独立した価値を提供する垂直スライスまたはワークストリームに分割します。水平レイヤー（データベース、次に API、次に UI）よりも、垂直スライス（エンドツーエンドの機能）を優先します。各スライスには、明確な完了基準が必要です。

3. 依存関係をマッピングする。 上流の入力、下流の利用者、共有サービス、データストア、プラットフォーム機能、チームの稼働状況、外部ベンダーやパートナーチームなど、すべての依存関係を特定します。ハード依存関係（ブロッカー）とソフト依存関係（希望事項）を区別します。依存関係記録に記載します。

4. クリティカルパスを特定する。 最短で完了できる時期を決定する、依存する作業の最長の連鎖をたどります。遅延するとクリティカルパスがずれる依存関係に印を付けます。

5. 責任者を割り当てる。 すべてのワークストリームと依存関係に責任者を割り当てます。責任を持つとは、作業を自分で行うことに限らず、完了に対する説明責任を負うことです。担当者を氏名または役割で記録します。

6. 順序を決め、並列化する。 依存関係を尊重し、並列性を最大化できるよう作業の順序を決めます。同時に進められるスライス、順次進める必要があるスライス、並行するトラック間で同期が必要な箇所を特定します。

7. ロールアウト戦略を設計する。 変更を本番環境に適用する方法を定義します。一斉展開、段階的展開（顧客別、地域別、割合別）、カナリアリリース、フィーチャーフラグによる展開、またはその組み合わせを選びます。各段階のロールアウト、ゲート、所要期間を定義します。

8. ロールバックと復旧を設計する。 ロールアウトの各段階について、ロールバックの手順を定義します。ロールバックのトリガー、実行方法、所要時間、実行後に残る状態を明確にします。該当する場合はデータのロールバックも含めます。

9. 元の要件に照らして検証する。 すべてのワークストリームを承認済みの入力までたどります。漏れがなく、余計なものも含まれていないことを確認します。意図的に決定したスコープについて記録します。

10. 未解決の意思決定とリスクを特定する。 計画中に解決できなかった意思決定と、残存するすべてのリスクを列挙します。それぞれに責任者と解決期限を割り当てます。

成果物

実装計画には、以下のセクションを含めます。テンプレートはtemplates/にあります。

成果物	テンプレート	目的
作業分解	templates/implementation-plan-template.md	垂直スライス、ワークストリーム、完了基準、責任者
依存関係と引き継ぎの記録	templates/dependency-record.md	依存関係マップ、クリティカルパス、チーム間の引き継ぎ契約
リスク、意思決定、検証の記録	templates/risk-decision-verification.md	リスク、未解決の意思決定、前提、検証チェックリスト

チーム間およびリポジトリ間の計画

このスキルは、単一のリポジトリやチームを前提としていません。承認済みの要件が複数のリポジトリ、チーム、組織にまたがる場合：

• 各リポジトリまたはチームの境界を依存関係インターフェースとして扱います。契約（API、スキーマ、イベント、または引き継ぎ成果物）とその責任者を定義します。
• チーム間の作業を最後だけでなく、共に検証する統合チェックポイントを計画します。
• 調整の仕組みを明示します。共有カレンダー、定例会議、Slack チャンネル、またはステータスダッシュボードなどを指定します。
• 移行では、切り替え戦略（並行稼働、一斉切り替え、段階的な移行）とバックフィル／照合の計画を含めます。

段階的なロールアウトと移行計画

変更に重大なリスクが伴う場合、計画には段階的なロールアウト戦略を含める必要があります。このスキルのロールアウト計画とrelease-engineeringのパイプライン設計、およびsite-reliability-engineeringのSLOベースの段階的なロールアウトとの関係については、references/discovery-brief.mdを参照してください。

段階的なロールアウト計画では、最低限、次の項目を定義します。

• 段階：段階の数、各段階で判断基準となる条件、および各段階の実施期間。
• 可観測性：各段階が正常であることを確認するためのメトリクス、ログ、またはシグナル。
• ロールバックのトリガー：各段階でロールバックを実行する具体的な条件。
• 復旧手順：データ、設定、およびトラフィックをロールバックする方法。

データ移行では、さらに次の項目を含めます。

• 移行期間中のデュアルライトまたはバックフィル戦略。
• 移行中のスキーマ互換性（前方互換性と後方互換性）。
• 古い経路を削除する前の切り替えと整合性確認。

専門スキルへの引き継ぎ

このスキルが作成するのは計画です。専門スキルがその計画を実行します。計画から実行への引き継ぎは意図的な境界です。計画に実装を持ち込まないでください。

計画の対象...	引き継ぎ先
仕様書の作成または正式なフェーズゲート	spec-driven-development
未検証要件の発見	product-discovery
QA 戦略、テスト計画、または検証設計	qa-methodology
計画に関する意図の契約、自律性のゲート、または障害時のルーティング	bmad
リリースパイプライン、昇格ゲート、またはカナリアの仕組み	release-engineering
社内開発者プラットフォームまたは CI/CD インフラストラクチャ	platform-engineering
セキュリティ要件、脅威モデリング、またはセキュア設計	secure-software-engineering
信頼性目標、SLO、インシデント対応、または運用準備	site-reliability-engineering
正式な ADR が必要なアーキテクチャ上の決定	adr-authoring
API 契約の設計または進化	api-design-and-evolution
データパイプライン、スキーマ、またはストレージの設計	data-engineering

上記の専門スキルが計画のセクションをすでに担当している場合（例：ロールアウトの仕組みをrelease-engineeringが担当する場合）、このスキルは内容を再導出せず、専門スキルの成果物を引用します。計画には専門スキルの成果物とその所有者を記載し、専門スキルの手法を重複して記述しません。

ファイル一覧

パス	読み込むタイミング
references/discovery-brief.md	このスキルが担当する範囲と、隣接するスキルに引き継ぐ範囲を把握するとき
templates/implementation-plan-template.md	完全な実装計画を作成するとき
templates/dependency-record.md	依存関係、クリティカルパス、および引き継ぎ契約を整理するとき
templates/risk-decision-verification.md	リスク、未解決の決定事項、および検証のトレーサビリティを記録するとき