計画はできあがりました。すべてのタスクを洗い出し、期間を見積もり、チームを割り当て、完了日を決めました。全員の認識がそろっています。見た目も完璧です。
そして現実がやってきます。
ベンダーが遅れます。誰かが体調を崩します。スコープがいつの間にか広がります。やがて、丹念に作り込んだスケジュールがずれ始めます。そして、どこから始めたのかの記録がなければ、どれだけ計画から外れたのか、なぜそうなったのかを判断するのはほぼ不可能です。
それこそが、プロジェクトのベースラインの役割です。
プロジェクトのベースラインとは？
プロジェクトのベースラインとは、当初の計画のスナップショットです。作業が始まる時点で取得した、承認・合意済みのスケジュール、スコープ、予算のバージョンです。これは固定された基準点です。一度設定したら変わりません（正式な変更要求によって更新される場合を除きます）。
プロジェクト管理におけるベースラインには、主に3つのタイプがあります。
- スケジュールベースライン：タスクとプロジェクト全体について、当初計画した開始日と終了日
- コストベースライン：時間の経過に伴う支出予定を含む、当初の予算
- スコープベースライン：承認された納品物と要件（WBS にまとめられることが多い）
これらを合わせたものがパフォーマンス測定ベースラインです。プロジェクトが「こう進む」と言っていた計画に対して、実際にどう進んでいるかを評価するための基準になります。
ベースラインが重要な理由：「何と比べて？」問題
ベースラインがなければ、進捗報告はすべて宙に浮いています。「少し遅れている」タスクがあるとして、では何と比べて遅れているのでしょうか。当初の計画でしょうか。先週改訂した計画でしょうか。3週間前にクライアントに伝えた内容でしょうか。
このあいまいさは、プロジェクトチームにおける混乱や対立の最もよくある原因の1つです。「予定どおり」が何を意味するのか、人によって頭の中のイメージが異なり、共通の基準がなければ、ステータスをめぐる議論は不毛になります。
ベースラインは、「何と比べて？」という問いに全員が同じ答えを持てるようにすることで、この問題を解決します。
ベースラインを保存しておけば、次のことがひと目でわかります。どのタスクが当初の計画より遅れて開始または終了したか、スケジュール全体がどれだけずれたか、現在の完了予測日が当初の予定から動いたかどうか、そしてプロジェクトのどの部分が計画より先行しているか、です。
具体例
製品ローンチを管理しているとしましょう。ベースラインでは、デザインフェーズが6月5日に終わり、開発が6月6日に始まり、製品は7月15日に出荷されることになっています。
今日は6月10日です。デザインがちょうど終わったところで、5日遅れです。開発は6月6日ではなく今日から始まります。
ベースラインがなければ、ガントチャートには「開発：6月10日開始」と表示されるだけです。それだけを見れば問題なさそうに見えます。ベースラインがあれば、赤信号が見えます。デザインは6月5日の予定だったのに6月10日に終わり、偏差は5日で、何も変わらなければローンチは7月20日にずれ込みます。
これで手を打てます。開発にリソースを追加して、5日のうち2日を取り戻すかもしれません。後でもっと大きな驚きになる前に、今のうちにステークホルダーに知らせるかもしれません。いずれにせよ、推測ではなく情報に基づいて管理できるのです。
ベースラインを設定するタイミング
ベースラインを設定する適切なタイミングは、プロジェクト計画が承認された後、実際の作業が始まる前です。早すぎる時点（計画がまだ交渉中のとき）に設定すると、本当は確定していなかった計画を記録してしまいます。作業が始まってから設定すると、本当の出発点を記録する機会を逃してしまいます。
実際には、ベースラインの設定は正式なプロジェクトキックオフのプロセスの一部であることがよくあります。スポンサーやステークホルダーがスケジュールを承認したら、それを確定させます。
チームによっては、主要なマイルストーンで中間ベースラインを設定することもあります。たとえば、フェーズ1が計画と大きく異なる形で終わった場合に、フェーズ2の開始時にベースラインを再設定するといった具合です。これは許容されることですが、蓄積した遅れを覆い隠す手段ではなく、意図的な判断であるべきです。ベースラインを再設定するたびに、「予定どおり」の意味を実質的にリセットすることになり、本当のパフォーマンスの問題が見えなくなる可能性があります。
スケジュール差異とパフォーマンス
ベースラインがあれば、進捗を追跡するうえで特に役立つ指標が2つ使えるようになります。
スケジュール差異（SV）は、完了した作業量という観点で、スケジュールに対してどれだけ先行しているか、遅れているかを示します。SV がマイナスなら遅れています。つまり、現時点でベースラインが計画していたより少ない作業しか完了していないということです。
スケジュール効率指数（SPI）は、効率の比率、つまり単位時間あたりに計画した作業をどれだけ完了しているかを示します。SPI が1.0未満なら1日あたりの完了作業量が計画より少なく、1.0を超えていれば予定より先行しています。
これらの指標はアーンドバリューマネジメント（EVM）に由来します。ただし、ベースラインの恩恵を受けるために EVM を本格的に導入する必要はありません。当初のバーをグレーで、現在のバーをカラーで並べて表示するだけのシンプルなガントの比較でも、プロジェクトの健全性について強力な視覚的フィードバックが得られます。
ベースラインとステークホルダーとのコミュニケーション
ベースラインは、社内のプロジェクト管理ツールにとどまりません。コミュニケーションの資産でもあります。
クライアントに「なぜ予想より時間がかかっているのですか？」と聞かれたら、ベースラインを表示して、何が変わったのかを順を追って説明できます。調査フェーズでスコープ外だった3つの追加連携が見つかり、開発スケジュールに10日が追加されました。私たちがいた地点はここ、今いる地点はここ、差分はこれです、と。
このように明確で記録に基づいた説明は、あいまいな「いろいろありまして」よりもはるかに信頼を築きます。それはあなた自身を守ることにもなります。スコープが追加され、承認を得たうえでタイムラインが調整されたのであれば、ベースラインがその判断のポイントを記録しています。
定期的なステークホルダー向けレポートでは、ガントチャート上でベースラインと実績を並べて示すことが、長い説明文なしにプロジェクトの状況を伝える最も明快な方法の1つです。
ベースラインでチームがよく犯す間違い
そもそも設定しない。意外なほどよくあります。特に小規模なプロジェクトでは、チームは当初の計画を「覚えておけばいい」と考えがちです。でも覚えていられません。
ベースラインを頻繁に再設定しすぎる。スケジュールが遅れるたびにベースラインを再設定していると、累積したずれを追跡する能力が失われます。ベースラインは常に現在の計画と一致するので、意味をなさなくなります。
ベースラインを基準ではなく目標として扱う。ベースラインは当初の計画を記録したものです。状況は変わります。それは普通のことです。目指すべきはベースラインに常に一致させることではなく、一致しないときにその理由を理解して記録することです。
計画が安定する前にベースラインを設定する。まだ交渉中の段階ではなく、計画が実際に合意された時点で確定させましょう。
LoopGantt でのベースラインの扱い
LoopGantt では、プロジェクトのスケジュールが固まった後なら、いつでもベースラインを保存できます。ベースラインはライブのスケジュールと一緒に保存され、当初計画したバーを現在のタスクバーの後ろに落ち着いた色で表示する、視覚的なオーバーレイを切り替えられます。
これにより、どのタスクが計画より先行しているか遅れているか、そしてどれだけずれているかがすぐにわかります。ステークホルダーとのレビューやチームのスタンドアップでは、その視覚的な比較が、どんな報告書よりも早く状況を伝えてくれることがよくあります。
LoopGantt Pro は1ユーザーあたり月額 $5 または年額 $45（創業者向け価格、14日間の無料トライアルつき）で、ベースラインの追跡、ガントのスケジューリング、依存関係、マイルストーン、ポートフォリオダッシュボードが含まれます。
まとめ
プロジェクトのベースラインとは、プロジェクトの当初の計画を琥珀に閉じ込めて保存したものです。制約や硬直した目標ではありません。ほかのすべてを測定可能にしてくれる基準点です。
ベースラインがなければ、「予定どおり」はただの意見です。ベースラインがあれば、それは指し示し、説明し、行動に移せる事実になります。
ベースラインなしでプロジェクトを管理してきたなら、解決策はシンプルです。次にプロジェクトを始めるとき、最初のタスクが始まる前に1分だけ時間をとってベースラインを保存しましょう。その1分が、この先何時間もの混乱や議論を防いでくれます。