これは何か
全体スケジュールは、プロジェクトの工程・マイルストーン・工程どうしのつながりを、時間の流れに沿って示す成果物です。
「いつ何をするか」の一覧であると同時に、「どの作業が遅れると、全体が遅れるか」を読み取るための資料でもあります。
なぜ作るか
- 関係者が、同じ時間の見通しを持つ
- 作業の順番と、前の作業に依存する作業が分かる
- 遅れが出たとき、全体への影響を判断できる
誰が使うか・いつ作るか
- 使う人：プロジェクトの責任者、PMO、各工程の担当、ベンダー
- 一般的には、計画の段階で作り、変更や遅れが起きるたびに見直します。見直した版と理由を残します
- アステリア案件の工程ごとの時期は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
正本に記載されたマイルストーン
| 時点 | 内容 |
|---|---|
| M-6 | 構想開始 |
| M0 | 正式キックオフ |
| M18 | 本番稼働 |
| M21 | 初期安定化完了 |
正本では、Stageと月の対応、中間のマイルストーンは定められていません。危機演習の時点は タイムライン で確認できます。
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — スケジュールに書く項目
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
| 項目 | 何を書くか | 書き方の例（教材上の例） |
|---|---|---|
| 工程 | 大きな作業のまとまり | 要件定義、設計、開発、テスト、移行、切替 |
| 開始・終了 | 工程の予定の期間 | 月（M）単位の予定 |
| マイルストーン | 節目となる時点と、その条件 | 「要件確定」「本番稼働判定」など |
| 依存関係 | 前の作業が終わらないと始められない作業 | 「連携の仕様確定 → 連携の開発」 |
| 担当 | 工程の責任を持つ役割・会社 | 役割名・会社名 |
| 余裕 | 予定に含めた余裕の期間 | 工程ごとの余裕 |
| 版と変更理由 | いつ、なぜ予定を変えたか | 版番号、変更日、理由 |
アステリア案件の実際の工程・期間・担当は、この表には入れていません。
何を書いてはいけないか
- 根拠のない日付を、確定した予定のように書く
- 依存関係を書かずに、工程を横に並べるだけにする
- 遅れを反映せず、古い予定のまま示す
どこを見るか
- 工程どうしの依存関係が書かれているか
- 遅れると全体が遅れる作業の並び（一般的にクリティカルパスと呼ぶ）が分かるか
- 他の会社・他のシステムに依存する作業に、その相手の予定が反映されているか
- マイルストーンに、達成したと判断する条件があるか
- 最新の版で、変更の理由が残っているか
赤信号
- 何か月も同じ予定のまま、進み具合と合っていない
- 余裕がどこにもない
- 他社の作業の予定が入っていない
- 本番稼働の日だけが固定され、前の工程が詰め込まれている
関係するUnit・危機演習
- Unit：03-05 プロジェクトの問題をどう管理するか、01-05 どこまでを今回の対象にするか、12-05 誰が本番稼働を決めるのか
- 危機演習：CR01 要件定義が終わらない、CR05 開発が2か月遅延（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
「このスケジュールを確認し、①依存関係が書かれていない作業、②他社・他システムの作業に依存しているのに相手の予定がない作業、③余裕のない工程、④マイルストーンの達成条件がないもの、を挙げてください。日付を提案したり変更したりしないでください。」
REVIEW
- AIが依存関係を推測で足していないか
- 最新の版のスケジュールを渡したか
- 遅れの影響の見積もりを、AIが断定していないか
人間が判断すること
- 予定を変えるか、範囲や体制を変えて予定を守るか
- 本番稼働などの節目の日を動かすか
- 遅れの影響を、誰にどう説明するか
いつ使うか
この教材では STAGE 03｜120人をどう動かすのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
このスケジュールで、どの作業が1週間遅れると本番稼働の日が動くか分かりますか？