ベースラインで計画の変更を説明できるようにする

この記事でわかること

「なぜ、完了予定が3週間延びたのですか」。この問いに、計画が変わり続けるWBSだけでは答えられません。比べる基準がないからです。本システムのベースラインは、計画をある時点で固定して保存し、現在の予定とのずれを一覧で示します。この記事では、いつ保存し、どう使うかを紹介します。

前提：機能スイッチで「WBS」がオンであること。ベースラインの保存と削除は、プロジェクト管理員だけができます。他のメンバーは、保存済みのベースラインを見て、比べられます。画面は、WBSの画面から開く「ベースライン」（WBSのベースライン）です。

ベースラインに保存されるもの

保存の時点の、削除されていないWBSの全行について、次を記録します。

• タイトルと、親子関係
• 予定開始日・予定完了日
• 計画人日

進捗率や実績は含まれません。あくまで「計画」の写しです。名前（100字まで）と、メモ（255字まで、任意）を付けます。1つのプロジェクトに保存できるのは、20件までです。

いつ保存するか

メモには、「何の承認で固定したか」「関連する変更要求の番号」を書いておきます。

比較画面の読み方

保存済みのベースラインを選ぶと、現在の予定との比較が出ます。比較は、作業行（子を持たない行）で行います。

「ベースラインから変わった作業はありません」と出れば、計画は動いていません。保存した直後に、差が出ないのが正常です。

ダッシュボードとの関係

最新のベースライン（最後に保存したもの）は、次の場所で使われます。

• プロジェクトのヘルス判定：完了予定が、最新のベースラインより遅れていると、黄になります。14日以上の遅れは、赤です。理由に、ベースラインの名前と日数が出ます。
• PgMダッシュボードのポートフォリオ：プロジェクトごとの遅れ日数が出ます。
• AI要約：「ベースラインとのずれ」が、要約の材料になります。

注意 新しいベースラインを保存すると、ヘルス判定などの基準が、その新しいものに変わります。「承認時の計画」からのずれを見続けたいなら、保存の前に、その比較結果を記録（Wikiやスクリーンショット）に残してください。また、古いベースラインを消すときも、同じです。

使い方の例：延びた理由を説明する

1. ベースライン「承認時の計画」を選ぶ。
2. 完了予定日が、3週間遅れていると確認する。
3. 変わった作業の一覧で、遅れの大きい作業を上から見る。「追加」の作業と、「工数の変更」の作業に分ける。
4. 追加された作業のそれぞれに、関連する変更要求を、関連設定でつないでおく。
5. 説明は、「承認された変更2件で10日、見積の見直しで8日、環境構築の遅れで3日」のように、理由ごとに分ける。

運用のコツ

• 保存する前に、計画チェックを通す：計画の矛盾が残っていると、基準が悪くなります（WBSの「計画チェック」「先行後続チェック」）。
• 変更の承認と、ベースラインの保存をセットにする：承認ワークフローで変更が承認されたら、計画を直して、新しいベースラインを保存します。
• 名前の付け方をそろえる：「いつ・何の時点か」が分かる名前にします。
• 消すのは慎重に：削除は取り消せません。20件の上限が近づいたら、不要な中間のものだけを消します。
• スケジュール計算の結果を反映したあとに保存する：反映前の古い日付を、基準にしないためです。

まとめ

ベースラインは、「当初の約束」を残しておく仕組みです。承認時、大きな変更の後、工程の区切りで保存しておけば、計画が変わったときに、「どの作業が、どれだけ、なぜ」変わったかを、数字で説明できます。