delivery-timeline

デリバリーのタイムライン

完成した milestones.yaml からデリバリーのタイムラインを生成します。デリバリーのパラメーター（本番環境へのデプロイ日、QA ラウンド数、QA セッションごとの日数）を確認し、日数の見積もりをマイルストーンに追加して、相対日数の timeline と、本番環境へのデプロイ日を基準とする実日付の workback スケジュールの2つのセクションを含む timeline.yaml を作成します。

前提条件

• {base_directory}/implementation/milestones.yaml が完成していること（/implementation-planner の出力）

使い方

/delivery-timeline [base-directory]

ディレクトリが指定されていない場合は、現在のディレクトリ内に implementation/milestones.yaml があるかどうかを確認して自動検出します。

見つからない場合は、ユーザーに「計画アーティファクトはどこにありますか？」と尋ねます。

続行する前に、ユーザーがパスを指定するまで待ちます。base_directory として保存します。

処理手順

ステップ 1：ベースディレクトリを特定してマイルストーンを読み込む

ディレクトリのパラメーターが指定されていない場合、現在のディレクトリに implementation/milestones.yaml があるかどうかを確認します。

• 見つかった場合は、現在のディレクトリを base_directory として使用します
• 見つからない場合は、「計画アーティファクトはどこにありますか？」と尋ね、ユーザーの回答を待ちます

base_directory が決まったら、次の操作を行います。

{base_directory}/implementation/milestones.yaml を読み込み、各マイルストーンの id、name、dependencies、estimated_duration を抽出します。

meta.ordering_strategy が存在する場合は、それも読み込みます。ordering_strategy として保存します。存在しない場合は、foundation-first を既定値として使用します。

ordering_strategy の値によって、ステップ 6 と 7 の構成が変わります。

• multi-pr：開発タイムラインの各マイルストーンの後に、PR／レビュー／マージのサイクルを挿入します。ステップ 7 の固定の QA 前 PR ブロックは省略します。
• その他のすべての戦略（single-feature-branch、value-first、risk-first、vertical-slice、foundation-first）：標準の単一 PR による開発後のフロー（現在の動作から変更なし）を使用します。

ステップ 2：デリバリーのパラメーターを確認する

次の3つの質問をユーザーに尋ねます。1つのメッセージにまとめて提示してもかまいません。

1. 本番環境へのデプロイ日 — 「希望する本番環境へのデプロイ日はいつですか？（YYYY-MM-DD）」
2. QA ラウンド数 — 「QA は何ラウンド必要ですか？」
3. QA ラウンドあたりの日数 — 「各 QA セッションに何日を割り当てますか？」

指定された本番環境へのデプロイ日が土曜日または日曜日の場合は、次のように警告します。

「注： [date] は週末です。[previous Friday] または [next Monday] を使用しますか？」

続行する前に、ユーザーが確認または修正するまで待ちます。確認済みの値を次のように保存します。

• production_deploy_date（ISO 8601 形式の日付文字列）
• qa_rounds（1以上の整数）
• qa_days_per_round（1以上の整数）

ステップ 3：期間を日数に変換する

次の表を使用して、各マイルストーンの estimated_duration 文字列を、営業日の整数に変換します。

estimated_duration	estimated_days
0.5 weeks	3
1 week	5
1.5 weeks	8
2 weeks	10
2.5 weeks	13
3 weeks	15
3.5 weeks	18
4 weeks	20
N weeks	N × 5 (rounded up to nearest whole day)

すでに日数で表されている期間（例：5 days）は、その数値をそのまま使用します。

ステップ 4：milestones.yaml を更新する

{base_directory}/implementation/milestones.yaml のすべてのマイルストーン項目に estimated_days を追加します。ほかのフィールドは変更しないでください。

例 — 変更前：

- id: m0
  name: Foundation & Project Setup
  estimated_duration: 1 week

変更後：

- id: m0
  name: Foundation & Project Setup
  estimated_duration: 1 week
  estimated_days: 5

ステップ 5：プロジェクトの規模を判定する

すべてのマイルストーンの estimated_days を合計して、total_development_days を計算します。

次のいずれかの条件を満たす場合、大規模プロジェクトとします。

• total_development_days > 30
• マイルストーン数が5を超える

大規模プロジェクトでは、既定で2ラウンドの QA フィードバックを受けます。ただし、これはステップ 2 でユーザーが指定した qa_rounds の値によって上書きされます。is_large_project は、情報提供のため、引き続きサマリーに記録されます。

Step 6: 開発タイムラインを作成する

Day 0 を起点に、依存関係の順序に従って各マイルストーンに completion_day を割り当てます。各マイルストーンの start_day は、最後の依存先が完了した翌営業日（依存関係がない場合は 0）です。completion_day は start_day + estimated_days です。

日数の計算式：

• 依存関係がない場合：start_day = 0
• 依存関係がある場合：start_day = max(dependency.completion_day) + 1（依存先の完了後、次の営業日）
• completion_day = start_day + estimated_days

順次進行するマイルストーンのチェーン（それぞれが直前のマイルストーンに依存する場合）：

m0: start_day=0, completion_day=0+estimated_days(m0)=5
m1: start_day=5+1=6, completion_day=6+estimated_days(m1)=16
m2: start_day=16+1=17, completion_day=17+estimated_days(m2)=27
...

並行するマイルストーン（同じ依存先を共有する場合）は、すべてその依存先の完了翌日に開始します。start_day は共通ですが、completion_day は各マイルストーンの estimated_days に基づいて個別に計算します。

標準戦略（multi-pr 以外すべて）

last_milestone_day = すべてのマイルストーンのうち、最も大きい completion_day

multi-pr 戦略

各マイルストーンの後、次のマイルストーンを開始する前に、4 つの PR サイクルフェーズを挿入します。マイルストーン ID を接頭辞として使用します（例：m0 の場合は m0-pr-creation、m0-pr-review、m0-review-feedback、m0-merge）。

ID のパターン	名前のパターン	estimated_days	備考
[milestone-id]-pr-creation	[Milestone Name] PR 作成	0	マイルストーンの completion_day に作成
[milestone-id]-pr-review	[Milestone Name] PR レビュー	2
[milestone-id]-review-feedback	[Milestone Name] レビューフィードバックの実装	2
[milestone-id]-merge	[Milestone Name] マージ	0	レビューフィードバックの完了と同日

PR サイクルにより、各マイルストーンの後に 4 営業日 のオーバーヘッドが加わります。次のマイルストーンの start_day = 前のマイルストーンの merge フェーズの completion_day + 1（マージ完了の翌日に開始）。

multi-pr における順次進行するマイルストーン：

m0: start_day=0, completion_day=0+estimated_days(m0)=5
m0-pr-creation: start_day=5, completion_day=5          # 0 days, opens same day
m0-pr-review: start_day=5, completion_day=5+2=7
m0-review-feedback: start_day=7, completion_day=7+2=9
m0-merge: start_day=9, completion_day=9                # 0 days, merges same day

m1: start_day=9+1=10, completion_day=10+estimated_days(m1)=20
# ... repeat for each milestone

multi-pr における並行マイルストーンでは、各ブランチに独自の PR サイクルが割り当てられます。複数の並行する先行マイルストーンに依存するマイルストーンは、それらの merge の completion_day のうち最も遅い日の翌日に開始します（max(merge.completion_day) + 1）。

last_milestone_day = すべてのマイルストーンにおける最終の [milestone-id]-merge フェーズのうち、最も大きい completion_day

Step 7: 開発後のタイムラインを追加する

last_milestone_day から始まるデリバリーフェーズの項目を追加します。各項目には、作業を開始する日を示す start_day と、作業が完了する日を示す completion_day を設定します。estimated_days: 0 の項目は、開始日と同じ日に完了します。

QA セクションの作成には、Step 2 の qa_rounds と qa_days_per_round を使用します。

QA 前の固定フェーズ

標準戦略（multi-pr 以外すべて）： 以下の PR／マージ／デプロイメントのブロック全体を含めます。これはプロジェクト終了時に行う単一の PR を表します。

id	name	estimated_days	notes
post-pr-creation	PR の作成	0	最後のマイルストーン日にオープン
post-pr-review	PR レビュー	2
post-review-feedback	レビューフィードバックの実装	2
post-merge	マージ	0	フィードバック実装と同日
post-deployment	デプロイメント	1

multi-pr 戦略： post-pr-creation、post-pr-review、post-review-feedback、post-merge は省略します。これらのサイクルはステップ 6 で、マイルストーンごとにすでに実施されています。post-deployment から直接開始します。

id	name	estimated_days	notes
post-deployment	デプロイメント	1	すべてのマイルストーンのマージ後に行う最終デプロイメント

QA フェーズ（各ラウンド 1..qa_rounds で繰り返し）

ラウンド R ごとに、qa_days_per_round を QA 期限の期間として、以下のフェーズを生成します。ラウンド固有の ID を使用します（例：post-qa-r1-deadline、post-qa-r2-deadline）。qa_rounds == 1 の場合、ID からラウンドの接尾辞を省略してもかまいません（例：post-qa-deadline）。

id pattern	name pattern	estimated_days	notes
post-qa-rR-deadline	QA 期限（ラウンド R）	qa_days_per_round	QA チームのテストに割り当てられる期間
post-qa-rR-feedback-impl	QA フィードバックの実装（ラウンド R）	3 if (R == 1 and qa_rounds > 1) else 2
post-qa-rR-pr	QA PR（ラウンド R）	0
post-qa-rR-feedback	QA フィードバック（ラウンド R）	2 if (R == 1 and qa_rounds > 1) else 1
post-qa-rR-merge	QA マージ（ラウンド R）	0

QA 後の固定フェーズ（すべてのプロジェクト）

id	name	estimated_days
post-signoff	承認	1

ステップ 8: 逆算スケジュールを作成する

production_deploy_dateから逆算して、タイムラインのすべての項目（マイルストーン＋納品フェーズ）を実際のカレンダーの日付に割り当てます。

基準日： production_deploy_dateは、post-signoffのcompletion_day（タイムラインの最終日であるtotal_delivery_days）に対応する実際の日付です。

営業日の計算： 逆算する際は、土曜日と日曜日を除外します。月曜日から営業日を1日戻す場合は、前の金曜日になります。

各タイムライン項目について：

• completion_date = production_deploy_dateから（total_delivery_days − item.completion_day）営業日を戻した日付
• start_date = production_deploy_dateから（total_delivery_days − item.start_day）営業日を戻した日付

project_start_date = production_deploy_dateからtotal_delivery_days営業日を戻した日付（Day 0）。

timelineのすべての項目を同じ順序で含めます。さらに、date: production_deploy_dateを指定したproduction-deployの項目を最後に追加します。

ステップ 9: timeline.yamlを生成する

{base_directory}/delivery/timeline.yamlに書き込みます。

ディレクトリが存在しない場合は作成します：

mkdir -p {base_directory}/delivery

出力形式

更新後のmilestones.yaml

各マイルストーンの項目にestimated_daysフィールドが追加されます。それ以外の内容はすべて変更せずに保持します。

timeline.yamlのスキーマ

出力ドキュメントには、version、project、generated、milestones_file、summary（合計日数、プロジェクト規模、QAラウンド数、納品モデル）、timeline（start_day／completion_day／estimated_daysを含むマイルストーンと納品フェーズ）、およびworkback（本番デプロイ日、プロジェクト開始日、実際のカレンダースケジュール）が含まれます。

すべてのフィールド、フェーズの種類、逆算ルールを含むドキュメント仕様の全体については、**references/output-spec.md**を参照してください。

完全な例については、**references/example.yaml**を参照してください。

出力例

タイムラインの完全なサンプルについては、**references/example.yaml**を参照してください。

ギャップ分析

timeline.yamlを生成した後、ギャップ分析を実施し、結果をインラインで報告します。

チェック項目

網羅性

• milestones.yaml のすべてのマイルストーンが timeline.yaml に記載されている
• すべてのマイルストーンの依存関係が守られている（依存先の完了前にマイルストーンが完了していない）
• milestones.yaml のすべてのマイルストーンに estimated_days が追加されている

期間の妥当性

• estimated_days: 0 のマイルストーンがない（確認対象としてフラグを立てる）
• 範囲を説明する注記なしに、30日を超えるマイルストーンがない
• 期間の換算がステップ 2 の表と一致している

プロジェクト規模の分類

• is_large_project が total_development_days > 30 または milestone_count > 5 を正しく反映している
• timeline.yaml の QA ラウンドが、ユーザー指定の qa_rounds と一致している
• QA Deadline のフェーズで、それぞれ qa_days_per_round 日が使われている

デリバリーモデル

• ordering_strategy が milestones.yaml から読み取られている（またはデフォルトの foundation-first が適用されている）
• timeline.yaml の概要にある delivery_model が、解決された戦略と一致している
• multi-pr の場合：各マイルストーンに対応する [milestone-id]-pr-creation / pr-review / review-feedback / merge ブロックがタイムラインにあり、開発後のフェーズに post-pr-creation から post-merge までが含まれていない
• それ以外のすべての戦略の場合：開発後のフェーズに post-pr-creation から post-merge までが含まれており、マイルストーンごとの PR ブロックがない

タイムラインの整合性

• 順次実施するマイルストーンの completion_day の値が、厳密に昇順になっている
• 並行するマイルストーンの completion_day の値が正しく独立している
• 開発後のフェーズが last_milestone_day の直後に続いている
• total_delivery_days = post-signoff の completion_day

ワークバックの整合性

• project_start_date = production_deploy_date から total_delivery_days 営業日を差し引いた日付
• production-deploy のエントリー日が production_deploy_date と一致している
• すべての completion_date が平日（月～金）になっている
• workback.schedule に timeline のすべてのエントリーが同じ順序で含まれている
• post-signoff の completion_date = production_deploy_date

ギャップ分析レポート

ファイルを生成した後、簡潔なインラインレポートを出力します：

## Timeline Gap Analysis

**Project:** [name]
**Delivery Model:** [ordering_strategy]
**Total Development Days:** [n] ([n] weeks)
**Total Delivery Days:** [n] (including post-dev phases)
**Project Size:** [Small / Large] ([reason if large])
**QA Rounds:** [n] × [qa_days_per_round] days each
**Production Deploy:** [YYYY-MM-DD]
**Project Start:** [YYYY-MM-DD]

**Checks:**
✓ All [n] milestones included
✓ Dependency order respected
✓ Duration conversions applied
[✓ / ✗] estimated_days added to milestones.yaml
[✓ / ✗] QA rounds match user-specified value ([n] rounds)
[✓ / ✗] All workback dates land on weekdays
[✓ / ✗] post-signoff completion_date = production_deploy_date

**Issues:** [none / list issues]

**Recommendations:** [none / list recommendations]

問題が見つかった場合は、次のように尋ねます：

"次のタイムラインの問題が見つかりました：

• [Issue 1]
• [Issue 2]

どのようにしますか？

1. 今すぐ問題を修正する
2. このままのタイムラインで進める
3. 生成前に見積もりを手動で調整する"