現実的な開発スケジュール作成術｜WBSから完成まで、7つのステップで徹底解説

「タスクは全部洗い出したはずなのに、なぜか現実的なスケジュールが引けない……」
「WBSをガントチャートに並べただけで、本当に納期が守れるのか不安だ」

プロジェクトマネジメントにおいて、WBSの作成は基本中の基本ですが、実は「WBSができた＝スケジュールが完成した」わけではありません。WBSはあくまで「やるべき作業のリスト」です。

今回はシリーズの完結編として、洗い出したタスクをどう並べ、どう調整すれば「完成」と言えるのか。迷わず進める7つのステップで、実行可能なスケジュールを組み上げる手法を解説します。

※本記事は、シリーズ「現場で迷わない！システム開発スケジュール作成の極意」の【第3回：実行計画編】です。

1. WBSを「線」でつなぐ：作業の依存関係を解き明かす

WBSで書き出した作業を、どの順番で進めるのが最速か。まずはタスク同士の「つながり」を整理します。ここが決まらないと、スケジュールはただの「作業の羅列」から抜け出せません。

主に以下の4つの型を意識して、タスクを繋いでいきます。

パターン	内容	具体例
終了ー開始（FS）	Aが終われば Bが始められる	要件定義が固まらないと、設計には入れない
開始ー開始（SS）	Aが始まれば Bも始められる	画面設計が始まれば、並行してテーブル定義も着手できる
終了ー終了（FF）	Aが終われば Bも終わらせられる	全てのテストが完了しないと、品質判定会議は完了できない
開始ー終了（SF）	Aが始まれば Bを終えられる	新システムの本番稼働が始まれば、旧システムの保守を終了できる

依存関係を無視して無理に並行させると、後で大きな手戻りが発生します。現場の感覚として「どこまで決まれば次に行けるか」を冷静に判断することが重要です。

ここが最も頭を悩ませるポイントですが、「工数（人時間）」と「期間（日数）」を分けて考えるのがコツです。

「工数：20時間」の作業でも、1日2時間しかその作業に充てられない場合、カレンダー上の「期間」は10日になります。また、土日祝日や顧客の回答待ちリードタイムも考慮しなければなりません。

予定通りにいかないのがプロジェクトです。以下の式でリスクを加味した期間を算出します。

\text{全体の期間} = \frac{\text{楽観値} + (4 \times \text{標準値}) + \text{悲観値}}{6}

楽観値（最短で終わる場合）、標準値（通常かかる場合）、悲観値（最悪の場合）を組み合わせることで、根拠のある期間を算出できます。楽観値だけで計画を立てるのは、現場では非常に危険です。

プロジェクトの開始から終了までをつなぐ経路の中で、「最も時間がかかる経路」をクリティカルパスと呼びます。

このパスが確定して初めて、スケジュールの「急所」がどこかが明確になります。クリティカルパス上の作業が1日でも遅れると、プロジェクト全体の納期が1日遅れます。そのため、クリティカルパス上の作業には、なるべく経験豊富で安定感のあるメンバーを配置するのが鉄則です。

期間が見えたら担当者を割り振りますが、アサイン時には以下の「現実」を考慮します。

リーダー層の稼働率: 会議や管理業務に時間を取られるため、実作業の稼働率は5〜7割程度で計算します。
生産性の違い: ベテランと若手では、同じ作業でもかかる時間が違います。
ブルックスの法則: 「遅れているプロジェクトへの要員追加は、さらにプロジェクトを遅らせる」。人員を増やせば教育コストが発生し、一時的に生産性が落ちるリスクを考慮しましょう。

ここで「無理なアサイン」を解消することで、初めてスケジュールは「実現可能な計画」へと近づきます。

どうしても納期に間に合わない場合、闇雲に残業を増やすのではなく、戦略的な手法を検討します。

クラッシング（人件費投入）: 人員を追加投入して、クリティカルパス上の作業を短縮する手法です。ただし、人員を増やしすぎると情報の共有だけで一日が終わる「コミュニケーションラインの爆発」を招く恐れがあります。
ファスト・トラッキング（並行作業）: 本来は順番にやるべき作業を、リスクを承知で一部並行して進める手法です。先行作業が確定する前に次を進めるため、手戻りが発生すると後続作業がすべて無駄になるリスクがあります。

無理な短縮は品質のトレードオフを招きます。多くの場合、検証時間の不足やレビューの質の低下によって時間が捻出されるからです。その結果、リリース直後に致命的なバグが発覚し、高いツケを払うことになりかねません。常にリスクと引き換えの判断であることを認識しておきましょう。