プロジェクト ベースライン 変更 履歴｜動かす条件3つと履歴の記入5項目
公開 2026.11.02
この記事の要点
- ベースラインは「承認された当初の計画」を固定した比較の基準。最新の予定(予測)とは別に持つ
- 動かすかは3軸で決める。①ずれの原因 ②約束への影響 ③変更を認める人の合意
- 合意が取れていないなら動かさず、最新予測と差異だけを報告する
- 変更履歴には日付・旧→新・理由・承認者・影響の5項目を書く(編集部の設計。職場のルールがあればそちらが優先)
納期がずれたとき、いちばん避けたいのは「日付だけ静かに直して、遅れが見えなくなること」です。この記事は、直してよい場面と、直す前にそろえるものを自分の状況で決められるようにするためのものです。段取りが崩れたときの立て直しは段取り 苦手 克服も参照してください。
ベースラインは「当初の約束」を固定した比較の基準で、最新の予定とは別に持つ
結論: ベースラインは、比べるための物差しです。予定が動いても物差しは勝手に動かない、というのが基本の考え方です。
ベースラインとは、承認された当初の計画を、後で最新の予定や実績と比べるために固定しておいた基準のことです。
Microsoft Project デスクトップのヘルプ(2026年11月2日時点の記載)では、スケジュールの追跡を開始する前に、後半で最新のスケジュールと比較できるようにベースラインを設定する、と説明されています。また、ベースラインを保存すると元の計画作業量は[ベースライン]フィールドに保存され、まだ開始していないタスクの[作業時間]には最新の予測値が入ります。つまり、当初の計画と最新の予測は、別の欄に持つ仕組みです。
これは Project デスクトップの場合の説明です。他のツールや表計算、手書きの計画表でも考え方は同じですが、操作や用語は職場のものに合わせてください。
当初・最新・実績の3列を並べると、遅れと前倒しを別々に説明できる
結論: 日付を1列だけ持つと「いつから遅れたのか」が説明できません。3列に分けると、遅れも前倒しも「何に対して」かが言えます。
下の表は、編集部が作った架空の例です(日数は編集部算出)。
| 例(架空) | 当初(ベースライン) | 最新予測 | 実績 | 当初との差 | 最新予測との差 |
|---|---|---|---|---|---|
| 遅延の例 | 6月30日 | 7月10日 | 7月8日 | 8日遅れ | 2日早く完了 |
| 前倒しの例 | 6月30日 | 6月26日 | 6月25日 | 5日前倒し | 1日早く完了 |
遅延の例では、最新予測(7月10日)に対しては2日早く終わっていますが、当初の6月30日に対しては8日遅れです。日付を最新の7月10日に書き換えるだけだと、この「8日遅れ」は残りません。
差異(ズレ)の定義も確認しておきます。Project では[差異]フィールドは、計画作業時間と予定作業時間の計算された差です。ここでいう「計画」が、ベースラインに保存した値にあたります。
日付だけ直すとズレが消え、遅れの説明も振り返りもできなくなる
結論: 基準を持たないまま日付を直すと、あとで何と比べればよいかが分からなくなります。
| 避けたい判断 | こうすればOK |
|---|---|
| 遅れが出たので、計画表の日付をそのまま新しい日付に上書きする | 当初の日付は残したまま、最新予測の欄だけ新しい日付にする |
| 「変更前は何日だったか」を誰にも伝えない | 当初・最新・差異を一緒に報告する |
| 毎回ずれるたびに日付を直して済ませる | 常にずれるなら、見積りの前提や範囲を見直す |
Project デスクトップの場合、基準計画を設定していないと、基準計画フィールドの0値を使って差異を計算するため、差異がスケジュール値そのものの大きさになり、意味のある比較になりません。また、基準計画の情報が現在のデータと常に異なるときは、元の計画が正確でなくなっている可能性があり、範囲の確認が必要になる、と説明されています。
自分の抱えている作業の洗い出しから見直したいときはタスク管理 できない 新人が近い内容です。
ベースラインを動かすかは、原因・約束への影響・合意の3軸で決まる
結論: 動かすのは「約束が動き、変更を認める人が同意した」ときだけです。それ以外は最新予測の更新と報告で足ります。
3つの軸は次のとおりです。
- ずれの原因: 見積りミス、依頼・範囲の変更、外部要因(取引先の都合など)、前倒し
- 約束への影響: 納期や関係者との約束が動くか
- 合意: 変更を認める人が同意しているか
Project デスクトップのヘルプには、プロジェクトの利害関係者が、違いがそれを保証することに同意した場合は、プロジェクト中にいつでもベースラインを変更または手直しできる、という説明があります。裏返すと、同意がなければ動かさない、が基本です。
下の表で、原因(行)と約束への影響(列)から結論を引いてください。表は編集部の目安で、制度ではありません。
| ずれの原因 | 約束(納期など)に影響しない | 約束に影響する |
|---|---|---|
| 見積りミス(作業量を読み違えた) | 最新予測だけ直す。差異を報告 | まず相談。合意が取れたら新版にする |
| 依頼・範囲の変更(作業が増えた・減った) | 最新予測だけ直し、変更内容を履歴に残す | 変更内容を示して合意を取り、新版にする |
| 外部要因(取引先や他部署の遅れ) | 最新予測だけ直す。外部要因と記録 | まず相談。合意が取れたら新版にする |
| 前倒し(早く終わりそう) | 最新予測だけ直す | 関係者に伝え、必要なら合意して新版にする |
境界は次のとおりです。
- 合意が取れていない間は、ベースラインを動かさず、最新予測と差異だけを報告します
- 小さな遅れで約束に影響しないものは、動かさなくてかまいません
- 毎回ずれる場合は、ベースラインを直す前に見積りの前提を見直します
- 複数のベースラインを保存していても、Project の差異の計算に使われるのは[基準計画]フィールドの値だけです(Project デスクトップの場合)
ずれた状態で何を先にやるかは優先順位 つけられない 新人で整理できます。
承認は誰に何を示して取るかを先に決め、旧ベースラインは消さず版として残す
結論: 承認者と旧版の置き場所は、職場ごとに違います。動かす前に3問で確かめてください。
承認の方法、承認者、版の残し方は職場ごとに違います。以下は編集部が考えた一般的な目安で、自社のルールがあればそれを優先してください。
動かす前のチェック3問です。
- 合意者は誰か: 納期の約束を決めた人(上司、依頼者、顧客窓口)は誰か
- 旧版はどこに残すか: 上書きせず、別ファイルや別の列、別の版名で保存できるか
- 自社に既存のルールがあるか: 変更の申請書、変更管理表、チャットでの承認など、決まった方法があるか
聞くときは、当初の日付・最新予測・ずれの原因・約束への影響を並べて示し、「ベースラインを新しくしてよいか」を確認します。
旧版を消さない理由は、後から「最初は何日の予定だったか」を示せなくなるからです。Project デスクトップの場合は、複数フェーズのプロジェクトでは各フェーズの最後に個別のベースラインを保存して、計画値を実際のデータと比較できます。更新時に既存の保存データがある場合は、上書きするかどうかを確認するメッセージが出るので、旧版を残したいときは安易に[はい]を押さないでください。保存できる数にも上限があります(FAQで触れます)。
遅れを伝える言い方は報連相 できない 新人に、悪い数字を早く出す練習は営業 報連相 できないにまとめています。
変更履歴には、日付・旧→新・理由・承認者・影響の5項目を書く
結論: この5つがあれば、後から読んだ人が「いつ・何が・なぜ・誰の了解で・何に響いたか」を再現できます。
| 項目 | 書くこと | 記入例(架空) |
|---|---|---|
| ①日付 | 変更した日 | 7月3日 |
| ②旧→新 | 変更前と変更後の日付・範囲 | 納期 6月30日 → 7月10日 |
| ③理由 | ずれの原因 | 依頼者から資料の追加指示があり、作業が増えた |
| ④承認者 | 誰がいつ認めたか | 上司(7月2日、口頭で承認。同日チャットに記録) |
| ⑤影響 | 約束や他の作業への影響 | 顧客への提出日を7月10日に変更。他案件への影響なし |
この5項目は編集部が設計したもので、公的な様式ではありません。職場に変更管理表などがあれば、その項目に合わせて、足りない項目だけ補ってください。
小さな遅れは動かさなくてよく、演習で自分の判断を確かめられる
結論: 約束に影響しない範囲の遅れは、ベースラインを動かさず最新予測の更新で足ります。演習で確かめましょう(数値は編集部の架空例)。
演習1: 社内資料の下書きの当初期限が5月20日、最新予測が5月27日です。提出先との約束は5月30日で、まだ動いていません。実際には5月25日に終わりました。ベースラインを動かしますか。当初との差は何日ですか。
模範解答: 動かしません。約束(5月30日)に影響しておらず、合意の必要な変更もないためです。最新予測だけを5月27日にし、実績は5月25日と記録します。当初との差は5日遅れ、最新予測との差は2日早く完了です(編集部算出)。
演習2: 依頼者から追加の指示があり、納期の約束を6月30日から7月10日に変えることで、上司と依頼者が同意しました。どうしますか。
模範解答: 原因は依頼の変更、約束に影響があり、合意もあるので、新しい版にします。旧版(6月30日)は消さずに残し、変更履歴に5項目を書きます。日数は、6月30日から7月10日で10日の延長です(編集部算出)。
ただし、毎回のようにずれて演習1のような更新が続くなら、見積りの前提を見直すサインです。
参照した一次情報(取得日: 2026年11月2日)
- Microsoft・Project デスクトップで基準計画または中間計画を作成または更新する: https://support.microsoft.com/ja-jp/project/create-or-update-a-baseline-or-an-interim-plan-in-project-desktop
- Microsoft・スケジュールの進捗状況を確認する(Project): https://support.microsoft.com/ja-jp/project/review-the-progress-of-your-schedule
3列の数値例・演習・判断表・履歴の記入例は編集部が作成した例(架空)で、公的統計や調査の数値ではありません。製品の挙動は Microsoft Project デスクトップのヘルプの記載に基づく説明で、一般の業務ルールや社内の承認ルールを示すものではありません。
よくある質問
ベースラインと最新の予定(予測)は何が違いますか?
ベースラインは、承認された当初の計画を比較のために固定した基準です。最新の予測は、いまの状況から見直した予定です。Microsoft Project デスクトップでは、元の計画作業量は[ベースライン]フィールドに保存され、未開始タスクの[作業時間]には最新の予測値が入る、と別のフィールドで持つ仕組みになっています(2026年11月2日時点のヘルプの記載)。
遅れたら、ベースラインを直してもいいですか?
直すかどうかは、ずれの原因、約束への影響、変更を認める人の合意で決めます。合意が取れていないなら動かさず、最新予測と差異だけを報告します。約束に影響しない小さな遅れは、最新予測の更新だけで足ります。承認者や手順は職場ごとに違うので、自社のルールを先に確かめてください。
ベースラインは何回まで変えられますか?
一般的な回数の決まりはありません。Microsoft Project デスクトップの場合は、プロジェクトごとに設定できるベースラインが合計11個で、これとは別に中間計画を最大10個まで設定できます(2026年11月2日時点のヘルプの記載)。これはツールの上限で、業務の一般ルールではありません。何度も変えたくなるなら、見積りの前提や範囲を見直すサインです。
古いベースラインは消してもいいですか?
消さずに残すのが基本です。後から当初の予定を示せなくなるためです。Project デスクトップでは、更新時に既存の保存データがあると上書きの確認が表示されます。旧版を残したいときは、上書きせずに別のベースラインとして保存することを検討してください。残し方は職場のルールを優先します。
変更履歴は誰に見せればいいですか?
変更を認めた人(上司、依頼者など)と、約束に影響を受ける関係者に見せます。誰に何をいつまでに見せるかは職場ごとに違うため、変更管理表や共有の決まりがあればそれに従ってください。決まりがなければ、日付・旧→新・理由・承認者・影響の5項目を添えて、承認を取った相手に共有しておくと後で確認しやすくなります。