スケジュール管理とは？何から決める？
スケジュール管理は、プロジェクトを期限までに終えるために、作業の時間の計画を立て、実績と比べて調整し続けることです。表を1回作って終わりではありません。
最初に決めるのは、スケジュールの「決め方」です。どの手法とツールで作るか、どの単位で管理するか、どれだけずれたら対応するかを、スケジュール・マネジメント計画にまとめます。
| 項目 | 決めること | 例 |
|---|---|---|
| 作り方 | 使う手法とツール | クリティカルパス法と工程管理ツール／2週間のイテレーション |
| 単位と精度 | 期間を数える単位、見積りの丸め方 | 日単位。半日未満は切り上げ |
| しきい値 | どれだけずれたら対応や報告をするか | マイルストーンが5営業日以上遅れたら報告 |
| 測り方と報告 | 進み具合の測り方、報告の頻度と形式 | 週次で SPI と節目の予測日を報告 |
| 更新のルール | 誰が、どの手続きでスケジュールを変えるか | ベースラインの変更は変更管理委員会の承認 |
Process タスク8では何が求められる？
ECO 2026年版の Process タスク8は「スケジュールの計画と管理」です。イネーブラーには、次の内容が挙げられています（当サイトによる要約）。
- 選んだ開発アプローチに合わせてスケジュールを準備する
- 他のプロジェクトや運用と調整する
- 作業を見積もる（マイルストーン・依存関係・ストーリーポイント）
- ベンチマークと過去のデータを使う
- スケジュールを作成し、ベースラインにする
- スケジュール管理計画を実行し、差異を分析する
「選んだ開発アプローチに合わせて」とあるように、予測型・アジャイル・ハイブリッドで作り方が変わる点が出題の中心です。ECO によると、予測型の問題は約40％で、残りの約60％はアジャイルとハイブリッドの考え方にもとづく問題です。
旧版（2021年版）では、スケジュールは Process タスク6でした。2026年版では、スケジュールのベースライン化、スケジュール管理計画の実行、差異の分析が新たに明記されました。
予測型のスケジュールはどう作る？
予測型では、スコープを先に確定させ、その作業を時間に並べます。手順は次のとおりです。
- 1
作業を定義する
WBS の作業パッケージを、スケジュールの単位（アクティビティ）に分ける
- 2
順序を決める
依存関係（終了−開始など）とリード・ラグを決め、ネットワーク図にする
- 3
期間を見積もる
類推・パラメトリック・三点見積もりなどで期間を出す
- 4
スケジュールを作る
クリティカルパスを求め、資源の制約を調整する
- 5
ベースラインにする
関係者の承認を得て、比較の基準として固定する
- 6
監視・管理する
実績と比べ、差異を分析して対策をとる
当サイトの整理
承認されたスケジュールはスケジュール・ベースラインになり、以後は変更管理の手続きを通さないと変えられません。ベースラインの意味と変更の手続きは、ベースラインとは？ で解説しています。
作ったスケジュールは、相手に合わせて見せ方を変えます。チームには、作業ごとの ガントチャート が向いています。スポンサーへの説明は節目だけのマイルストーン・チャート、依存関係の検討はネットワーク図が中心です。
遅れが出たらどう対応する？
差異の分析には、計画と実績の比較のほか、EVM の SV・SPI などを使います。遅れが見つかったときは、次の順番で考えます。
- 1
事実と原因を確かめる
どの作業が、なぜ、どれだけ遅れているかを担当者と確かめる
- 2
影響を見る
クリティカルパス上か、フロートの範囲に収まるかを確かめる
- 3
計画の範囲で取り戻す
資源の再配置、ファストトラッキング、クラッシングなどを検討する
- 4
取り戻せなければ変更要求
完了日やスコープの変更を、変更管理の手続きに乗せる
- 5
報告して更新する
関係者に伝え、承認された内容でスケジュールを更新する
当サイトの整理
フロートの範囲に収まる遅れなら、完了日には影響しません。ただし、フロートを使い切ると、その作業も新たにクリティカルになります。クリティカルパス上の遅れは完了日に直結するので、重点的に監視します。
アジャイルではリリース計画とイテレーションをどう作る？
アジャイルでは、最初にすべての作業を時間に並べることはしません。期間（イテレーション）を固定し、その中で価値の高い作業から進めます。スケジュールは、次の2つの層で考えるのが基本です。
- リリース計画：数か月単位で、どの機能群をいつ頃届けるかの見通し。バックログの量とベロシティから予測する。
- イテレーション計画：1〜4週間程度のイテレーションごとに、チームがこなせる量を選んで計画する。
POINT
ベロシティはチームごとの物差しです。チーム間で比べたり、目標として押し付けたりするものではありません。
ベロシティからリリース時期をどう予測する？
リリース時期は、残りのストーリーポイントをベロシティ（1イテレーションでこなせる量）で割って予測します。ベロシティは回ごとに揺れるので、幅でも示します。
必要なイテレーション数 ＝ 残りのストーリーポイント ÷ ベロシティ（切り上げ）
- 1残りのバックログ ＝ 240ポイント、平均ベロシティ ＝ 30ポイント／イテレーション
- 2240 ÷ 30 ＝ 8イテレーション
- 31イテレーション ＝ 2週間 → 8 × 2 ＝ 16週間
- 4ベロシティが25〜35で揺れる場合：240 ÷ 35 ≒ 6.9 → 7、240 ÷ 25 ＝ 9.6 → 10
- 5→ 7〜10イテレーション ＝ 14〜20週間
見通しは約16週間。幅で示すなら14〜20週間
当サイトの架空の例
アジャイルの予測は、イテレーションを重ねるごとに更新します。ベロシティの実績が安定するほど、見通しの幅は狭くなるのが一般的です。予測型とアジャイルを組み合わせる場合の計画の考え方は、ハイブリッド型の進め方 で扱っています。
過去データとベンチマークはどう使う？
見積りの根拠には、組織にたまった過去のデータや、業界のベンチマークを使います。似たプロジェクトの実績期間・単価・ベロシティなどです。根拠のある見積りは、関係者への説明にも使えます。
| データ | 使い方 | 注意点 |
|---|---|---|
| 似たプロジェクトの実績期間 | 類推見積もりの根拠 | 規模・技術・チームの違いを補正する |
| 作業単位あたりの所要時間 | パラメトリック見積もり | 単価の前提が今回も成り立つか確かめる |
| チームの過去のベロシティ | リリース時期の予測 | チームの構成が変わると使えない |
| 業界のベンチマーク | 見積りの妥当性の確認 | 自社の条件との違いを考える |
新しいチームで過去のベロシティがない場合は、似たチームの実績を仮の値として使い、幅を持たせて示します。数回のイテレーションの後に、チーム自身の実績で置き換えます。
他のプロジェクトや運用との調整は？
プロジェクトは、組織の中で単独では動いていません。同じ人や設備を使う他のプロジェクト、システムを日々運用している部門、外部の業者の予定が、スケジュールに影響します。
- 共有の資源：専門家や検証環境を他のプロジェクトと取り合う場合、プログラムやポートフォリオの管理者と優先順位を調整する。
- 運用部門の予定：本番環境の変更は、運用部門の保守時間や繁忙期を避けて計画する。
- 外部の依存関係：行政の許可や業者の納品など、自分では管理できない日程は、リスクとして監視する。
予定どおりにいかない場合に備え、特定済みのリスクにはスケジュールの予備（余裕）を持たせることもあります。予備の考え方は、コンティンジェンシー予備とマネジメント予備の違い で解説しています。
確認問題1
リリース時期の予測
（当サイトの独自問題）アジャイルのチームが、残りのバックログ180ポイントを抱えています。直近3回のイテレーションのベロシティは18・20・22ポイントで、1イテレーションは2週間です。プロダクトオーナーから、残りをすべて終えるまでの期間の見通しを聞かれました。最も適切な回答はどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：1。平均ベロシティは (18 ＋ 20 ＋ 22) ÷ 3 ＝ 20ポイントです。180 ÷ 20 ＝ 9イテレーションで、9 × 2週間 ＝ 18週間になります。
2：イテレーション数を週数と取り違えています。3：最も低いベロシティ18で計算した値（180 ÷ 18 ＝ 10 → 20週間）で、悲観側の見通しです。4：最も高いベロシティ22で計算し、端数を切り捨てた値（180 ÷ 22 ≒ 8.2 → 8イテレーション）です。端数が出たら切り上げます。
確認問題2
運用部門の予定とぶつかる
（当サイトの独自問題）予測型のスケジュールでは、来月の第3週に本番環境への切り替えを予定しています。ところが運用部門から、その週は年に1度の大規模な保守作業があると連絡がありました。本番環境は変更できないとのことです。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：4。他の部門の運用との調整は、スケジュール管理の一部です。運用部門と代わりの日程を調整し、クリティカルパスや完了日への影響を分析します。必要なら変更管理の手続きに進みます。
1：保守の週に切り替えを認めさせようとするのは、運用部門の事情と組織全体のリスクを無視しています。2：大規模な保守と重ねると、障害のリスクが高まります。3：影響の分析が後回しで、関係者への報告もしていません。
確認問題3
過去のベロシティがない
（当サイトの独自問題）新しく編成したアジャイルのチームで、まだ1回もイテレーションを終えていません。スポンサーは、来週の経営会議でリリースの時期を示してほしいと求めています。社内には、似た製品を作った別のチームの実績があります。プロジェクト・マネジャーが次に行うべきことはどれか。
選択肢を押すと、正誤と解説が表示されます。
正解と解説を見る
正解：3。過去のデータやベンチマークを使い、根拠のある見通しを幅で示します。数回のイテレーションの後、チーム自身の実績で更新することもあわせて伝えます。
1：情報がないことを理由に何も示さないのは、関係者の求めに応えていません。2：根拠のない約束になります。4：初回の量を約束しても、スポンサーが求めるリリース時期の見通しにはなりません。実績の無いまま最大の量を約束すると、見積りの水増しや品質の低下も招きます。
次に何をすればいい？
予測型ではクリティカルパスとフロート、アジャイルではベロシティとリリースの予測を、計算できるようにしておきます。そのうえで「アプローチに合った作り方を選ぶ」判断を、問題で練習してください。
スケジュールのタスクを集中的に練習したい人は、タスク別ドリルで Process タスク8を選んで解けます。