プロジェクト計画書は、アイデアを現実に変えるためのマスタードキュメントです。スコープやスケジュールから予算やリスクまで、あらゆる情報をまとめて記録します。Trupeerなら、無料のプロジェクト計画書テンプレートから始めて、ブランドアイデンティティでカスタマイズし、計画をステークホルダーに素早く共有できる動画ウォークスルーに変換することで、計画作成にかかる時間を何時間も節約できます。

プロジェクト計画書テンプレートとは何で、何ではないのか？

プロジェクト計画書は、何を、どの順序で、誰が、いつまでに、そして何に依存して実行するかを示します。最初に一度書き、合意し、その後は、現実がその計画と照らし合わせられる基準として使われます。

トラッカーは、物事が現在どこにあるかを記録します。毎週変わり、最新の状況を反映し、その役割は意図を記録することではなく、ステータスを示すことです。

プロジェクト計画書テンプレートを探すと、見つかるものの多くがトラッカーです。これはテンプレートを批判しているわけではありません。人々が実際に必要としているものの反映です。この用語に関連する検索の大半が、Excel、Googleスプレッドシート、またはトラッカーを明示しているのです。

問題は、この2つが1つのスプレッドシートに統合され、その統合によって、計画が本来果たすべき唯一の役割が失われることです。日付をその場で編集すると、元の約束が消え、「私たちは遅れているのか」という問いに答えられなくなります。

計画を探している多くの人には、トラッカーが必要

この点は率直に言う価値があります。なぜなら、それが「何を作るべきか」を決めるからです。

質問が「何を、どの順序で、そして何に依存して進める必要があるのか」なら、計画書が必要です。計画書は一度書き、議論し、そして順序と依存関係が含まれます。私たちのITプロジェクト計画書テンプレートでは、多くのテンプレートが無視しがちな外部制約に基づいて計画を作ることをカバーしています。

質問が「各タスクのステータスは何で、どれが遅れているのか」なら、トラッカーが必要です。週次でメンテナンスし、計画書よりもはるかに短くするべきです。

ほとんどのチームは両方を必要とし、そして多くのチームは1つのスプレッドシートを作ってそれを計画書と呼びます。そのスプレッドシートには、タスク、担当者、開始日、終了日、完了率があり、継続的に編集されます。つまり、記憶のないトラッカーです。

このページの残りは、1つのファイルの中でこの2つを分けて管理する方法についてです。ほとんどの人にとって、それが現実的な答えになります。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したい任意のテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開して全体のレイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内では、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、その位置や関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新されたテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるかを確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが思い通りに表示されることを確認できます。

プロジェクト計画書テンプレートでできること：

• 計画作成の時間を節約：包括的なプロジェクト計画書の構成で、空白のページをスキップできます。

• あらゆる観点をカバー：スコープ、スケジュール、予算、リスク、コミュニケーションのための組み込みセクション。

• ブランドに合わせ続ける：Trupeerのブランドキットを使って、ロゴ、フォント、カラーを適用できます。

• ステークホルダーを揃える：密度の高い計画を、誰もが5分で見られる動画サマリーに変換します。

• プロジェクト間で標準化：すべての取り組みに同じ計画書テンプレートを使用します。

• グローバルチームに対応：1クリックでプロジェクト計画書を65+言語に翻訳できます。

ベースラインのないプロジェクト計画書はトラッカー

結論を1行で言うと、計画書内の日付が毎週更新する同じセルであるなら、計画書ではありません。

ベースラインとは、合意された日付のセットを固定して凍結したものです。編集することはありません。日付が動けば予測は変わりますが、ベースラインは変わりません。

この1つの規律によって、ほかでは得られない3つのことが手に入ります。

遅れているかどうか、そしてどれくらい遅れているか。 気分ではなく、タスクごと、そして合計での数値です。

遅れがどこから生まれたのか。 プロジェクトの遅延は少数の根本原因にたどり着き、下流はそれを引き継ぎます。ベースラインがないと分かるのは「多くのタスクが動いた」という事実だけで、「1つの意思決定が9週間かかったために、そのうち40個が動いた」ということまでは分かりません。

見積もりがどれくらい良いか。 複数のプロジェクトにおける実績との比較で、組織が「現実的に計画できているか」を判断する唯一のフィードバックループになります。現場でその場編集するチームは、決してそれを知ることがありません。

なお、ベースラインの再設定は正当な場合もありますが、スプレッドシートを更新した副作用としてではなく、「日付」と「理由」を伴う意思決定であるべきです。元のベースラインも保持してください。

ベースラインと予測を分けて管理する方法

同じ行に2つの「日付列セット」を用意し、ルールは1つ。

原因（Cause）列は、多くの人が省いてしまう列であり、差異レポートを「実行可能なもの」に変える列です。これがないと「40個のタスクが動いた」ことしか分かりません。これがあると、「同じ上流の意思決定が原因で、そのうち30個が動いた」ことまで分かり、話がまったく別物になります。

ベースラインの列は、誤って編集できないように保護してください。スプレッドシートではロックすることを意味し、プロジェクトソフトウェアでは通常、存在を知られていない明示的なベースライン機能を使うことになります。

トラッカーは計画書より行数が少なくて済む理由

2つ目の失敗は「量」であり、トラッカーが間違っているというより、放棄されてしまう原因になります。

計画書には、合理的に言えばすべてのタスクが含まれます。トラッカーに必要なのは、遅れが問題になる行だけです。つまり、クリティカルパスと、プロジェクト外の誰かに依存するすべての項目です。

300行を週1回、1人が更新するのは90分で済み、4か月目あたりでその作業は止まります。40行なら20分で済み、続きます。

トラッカーから外れたタスクは、放置されるわけではありません。そのワークストリームを所有する人が、自分たちのリストで管理し、トラッカー上で脅威になる場合に限ってトラッカーに表れます。

行がトラッカーに属するかどうかのテストはこうです。2週間遅れたら、プロジェクトの終了日が動くのか、それともプロジェクト外の誰かに伝える必要があるのか？ どちらでもなければ、それは計画書に属し、週次更新には属しません。

無料のプロジェクト計画書テンプレート：コピーすべき列

ここからコピーしてください。計画書とトラッカーを統合した1枚のシートに加え、2枚目のシートとしてナラティブ（文章）を用意します。

1枚目（Sheet one, tasks）： タスクID。タスク名（動詞から）。ワークストリーム。オーナー（指名された個人）。前提タスクID。ベースライン開始。ベースライン終了。予測開始。予測終了。実績開始。実績終了。差異（日数）（計算）。差異の原因。ステータス：未着手、進行中、完了、ブロック中。トラッカーに載せる：はい／いいえ。メモ。

2枚目（Sheet two, plan narrative）： 目的と成功基準（プロジェクトブリーフを参照）。スコープ（含む／含まない）。前提（Assumptions）はそれぞれ番号を付け、差異の原因がそこを指せるようにする。外部依存関係（相手先と、相手と合意した日付）。リソース。スコアではなくトリガー付きの主要リスク。ベースラインの日付と承認者。

3枚目（Sheet three, variance log）： 原因（cause）列から自動で入力：根本原因ごとに1行。影響を受けたタスク数と追加された日数を記載します。ステアリングミーティングで読まれるのはこのシートです。

ここまでコピーしてください。差異ログは価値が集中する場所であり、すでに取得しているデータから導出されるためコストはかかりません。

遅れているかどうか言えなかったERPプロジェクト

食品メーカーのNetherfield Foodsは、新しいエンタープライズシステムを導入しました。計画は340行のスプレッドシートで、タスク、担当者、開始、終了、完了率が記載されていました。週次で、その場で更新されていました。

14か月後、スポンサーが妥当な質問をしました。「私たちは遅れているのか、そしてどれくらい遅れているのか？」

誰も答えられませんでした。スプレッドシートには現在の予測が表示されており、ゴーライブは当初より約5か月先でしたが、元の日時は約60回上書きされており、ファイル内に記録が残っていなかったのです。

彼らは、1か月目にメールで送られ、今もスポンサーの受信箱に残っていた計画書のPDFから、ベースラインを再構築しました。これには3日かかりました。

再構築は、誰もが想像していた以上に役立ちました。元の計画は11か月で、予測は現在16か月です。340のタスクのうち61は4週間以上動いていました。そのうち44は、たった3つの遅延が原因でした。データ移行の依存関係、第三者の統合、そして9週間かかった勘定科目表（チャート・オブ・アカウント）に関する意思決定です。

3つの根本原因が移動の約72%を占めていましたが、どれも見えていませんでした。すべての日付がその場で編集されており、スプレッドシートには常に「現在」しか表示されなかったからです。

同じ起点に由来する2つ目の問題もありました。340行ということは、週次更新に約90分かかり、1人が対応していたということです。9か月目には隔週で行うようになり、約190行の完了率の数値は3か月間変わっていませんでした。

5か月の遅れによる追加コストは、外部委託の契約者と社内リソースの双方で約48万ポンドでした。より回避可能だったのは勘定科目表の意思決定で、20の下流タスクをブロックしていたにもかかわらず、トラッカー上では何もブロックしているように見えなかったため、6週間エスカレーションされませんでした。

次のフェーズでは2つのことが変わりました。ベースラインの日付は、それぞれ独自の列に固定してロックされました。予測の日付はそれらの横に並び、計算された差異と原因列が付くようになりました。そしてトラッカーは340行から47行に削減されました。つまり、クリティカルパスに加えて、すべての外部依存関係です。残りのタスクは計画書に残し、ワークストリームリードが管理しました。

週次更新は90分から約20分へ短縮されました。このフェーズは7か月で計画され、7か月と3週間で完了しました。発生した2つの遅延はいずれも1週間以内にフラグが立ちました。クリティカルパスの行で2週間の差異が自動的に検出され、300行のうちの1つのセルが変わっただけのような扱いにならなかったからです。

すべてのプロジェクト計画書に必要な重要要素

目的と成功基準。 このプロジェクトは何のためで、どうすれば「うまくいった」と判断できるのか。ここはブリーフから取り、ここで新しく作らないこと。

スコープ（含む／含まない）。 含まないリストが、揉め事を防ぎます。

担当者のいるタスク。 チームではなく、個人名で。

順序と依存関係。 どのタスクがどれに依存しているか。これが「日付に意味を持たせる」からです。

外部依存関係。 プロジェクト外の誰かに依存するものはすべて対象にし、あなたが想定した日付ではなく、相手と合意した日付を記録します。

ベースラインの日付。 合意し、凍結し、誰かが承認する。

前提（Assumptions）を番号付きで。 何かがずれたときに、原因が「失敗した前提」を指せるようにするためです。

リソース。 誰が、どれくらいの時間使えるのか、そして代わりに何をしていないのか。

トリガー付きのリスク。 確率スコアではなく、観測可能な状態とアクション。

最もよく欠けるのは、番号付きの前提と、相手と合意した外部依存関係の日付です。どちらも計画時のコストは安く、そして差異分析が6か月後に必要とするのもまさにこの2つです。

最初から最後までプロジェクトを計画する方法

タスクリストから始めるのではなく、ブリーフから始めます。問題と成功基準を言語化できないなら、計画は「活動の羅列」になってしまいます。

タスクの前に成果物をリスト化します。成果物から導き出したタスクは完了できますが、直接ブレストしたタスクは、領域を丸ごと見落としがちです。

それらを順序付けし、依存関係を見つけます。特に他チームやサプライヤーに関する依存関係です。私たちの調達管理計画書テンプレートでは、クリティカルパス上にあるのに見過ごされがちな調達リードタイムをカバーしています。

作業を実際に行う人たちと一緒に見積もりを行い、本当に不確実な場合は見積もりをレンジとして記録します。

次にベースラインを設定します。承認者を立てて承認を取り、日付を記録し、列をロックします。

上記の2週間テストを使って、どの行を週次トラッカーに載せるかを決めます。

その後、運用頻度（cadence）を設定します。タスク担当者による週次の予測更新、原因付きの月次差異レビュー、そして再ベースラインは明示的な意思決定としてのみ行います。

プロジェクト計画書のバリエーション：ガント、ドキュメント、アジャイル

ガントチャートの計画： タイムラインに対して棒グラフとして同じタスクデータを表示します。依存関係やフロートを把握するのに優れており、別のドキュメントというより「ビュー」です。まず表を作り、そこからチャートを生成します。

計画書ドキュメント： ナラティブ版です。目的、スコープ、アプローチ、前提、リスク、リソースに加えて、スケジュールは埋め込むのではなく添付します。これが承認されるものです。さらに、私たちのプロジェクト概要テンプレートでは、プロジェクト外の人に見せる短い版もカバーしています。

アジャイル計画： タスク単位のスケジュールではなく、スプリントやインクリメントで進めます。スコープは変数で、日付は固定します。ベースラインは引き続き適用されますが、タスクではなく成果物やリリース日を基準にベースラインを取ります。

シンプル／1ページの計画： マイルストーン、担当者、日付のみ。小規模プロジェクトには本当に十分で、メンテされていない300行のスプレッドシートよりはるかに優れています。

プログラム計画： 相互依存関係を持つ複数のプロジェクト。ここでは、ベースラインの規律がより重要になります。というのも、面白い差異は常にインターフェース（接点）で発生するからです。

プロジェクト計画書、ブリーフ、概要：どれが必要？

3つのドキュメントが混同されがちです。なぜなら、3つともスポンサーに提示されるからです。

ブリーフは、問題を示し、作業を承認します。最初に書かれ、凍結され、計画書によって置き換えられます。私たちのプロジェクトブリーフテンプレートがそれをカバーしています。

計画書（plan）は、作業をどう提供するかを示します。ベースラインを設定し、その後はそれに照らして追跡します。これがこのページです。

概要（overview）は、プロジェクト外の人向けに現在の状況を要約し、毎月書き直されます。私たちのプロジェクト概要テンプレートがそれをカバーしており、ステータスの色が読者に何も伝えない理由も含まれています。

スケジュールではなくゲート条件が必要な場合は、私たちのプロジェクトチェックリストテンプレートが、各項目が実際にアクション可能になるタイミングと、プロジェクトを通じて残すべきものをカバーします。さらに、残すべき資料のセットについては、私たちのプロジェクトドキュメンテーションテンプレートがカバーしています。

ExcelまたはGoogleスプレッドシートでプロジェクト計画書テンプレートは入手できますか？

ExcelまたはGoogleスプレッドシートで、そしてほとんどのプロジェクトでは妥協ではなく、それが正しい答えです。タスクシートは計算列を含む表で、数式が必要になります。

最初に一度だけ設定するべきことが3つあります。ベースラインの列をロックして、編集できないようにします。差異の数式と、しきい値を超えたものをフラグする条件付き書式を追加します。2週間を合理的なデフォルトにしておくとよいでしょう。そして、トラッカー列にフィルターを追加し、週次更新の表示を300行ではなく40行にします。

Googleスプレッドシートには、注目すべき利点があります。バージョン履歴が自動なので、たとえその場で編集してしまってもベースラインを復元できます。これは列をロックする代わりとしては不十分ですが、それでもプロジェクトを救った実績があります。

計画書のナラティブにはWordまたはGoogleドキュメントが適しています。文章として承認されます。

提示する計画書にはPowerPointが適しています。タスクリストではなく、マイルストーンと依存関係にするべきです。

承認時点のベースライン版はPDFで書き出し、日付付きでそのファイルを保持します。上記の実例での再構築がそれに依存していたのは、その1つのファイルを残していたからです。

スプレッドシートの使用をやめてソフトウェアに切り替えるタイミング

スプレッドシートが「正しいツール」ではなくなるのは、かなり予測可能な時点であり、ソフトウェアベンダーが示すよりも後になります。

合図となるのは、次の3つが揃ったときです。追跡対象のタスクが概ね100件を超えること。同じファイルを4〜5人以上が更新していること。そして、手作業で順序を再計算するのがエラーになりやすいほど、依存関係が頻繁に変わること。

それ以下なら、ベースラインをロックしてきちんと整えたシートは、誰もログインしないプロジェクトソフトウェアよりも優れています。

それ以上なら、ソフトウェアが提供する具体的な利点が効いてきます。自動での依存関係の再計算、実際に機能するベースライン機能、プロジェクト間でのリソース平準化、そして監査証跡です。逆に奪われるのは、プロジェクト外の人がそれを開けなくなることです。だからこそ、多くの組織は両方を維持することになり、それは望ましくありません。

もし切り替えるなら、再ベースラインのたびに、ベースライン済みのコピーをスプレッドシートへエクスポートしてください。5年後に計画書を読めることは、ライセンスに依存すべきではないからです。

計画書をチームの実作業につなげる方法

計画書はタスクを説明します。計画書が想定した通りにそのタスクが実行されているかどうかは、スケジュール上では見えません。そしてギャップは、通常「1か月間、完了率が80%のままのタスク」として現れます。

最もよくある理由は、そのタスクが誰も説明していなかった作業を含んでいることが判明し、実行している人が、日付に照らして追跡されながら同時にプロセスを作り始めてしまうからです。

Trupeer AIは、その時点で役立ちます。作業をしている人がプロセスを一度だけ記録すると、手順と画面がキャプチャされた書面のガイドとして出力されます。つまり次に同じことが起きたときは速くなり、その見積もりも現実的になります。さらに、差異の原因に紐づけられる具体的な材料も得られます。「この手順は4つのシステムが関わっていたため、3倍時間がかかった」といった具合です。

記録する。ブランド化する。翻訳する。Trupeerする。

これらの記録は、後で引き継ぎやトレーニング資料になります。そのため、報告だけに労力を費やす必要がありません。資料はナレッジベースに一貫したブランドで保存され、プロジェクトの最後に何かを引き継ぐ際に、受け取るチームが実際に必要としていることはプロジェクト引き継ぎテンプレートでカバーされています。セットアップ手順はドキュメントテンプレートセットアップガイドにあります。

よくある質問

Excelで無料のプロジェクト計画書テンプレートはありますか？

Excelはほとんどのプロジェクトに適した形式で、上記の列セットは1つのシートに組み込まれます。ゲート付きのダウンロードもフォームもありません。すでに使っているテンプレートに対して行うべき2つの変更は、ベースラインの日付列のセットをロックすることと、差異の横に原因列を追加することです。

Wordで無料のプロジェクト計画書テンプレートはありますか？

Wordは計画書のナラティブに向いています。目的、スコープ、前提、依存関係、リスク、リソースです。スケジュールはスプレッドシートに保持して参照してください。Wordのタスク表では差異を計算できず、約30行を超えると管理不能になります。

Googleスプレッドシートで無料のプロジェクト計画書テンプレートはありますか？

はい。さらにGoogleスプレッドシートには、Excelに対してここで言及する価値のある本当の利点があります。自動のバージョン履歴です。つまり、誰かがその場で編集してしまっても、ベースラインを復元できます。仕組みとしてではなくセーフティネットとして使い、いずれにせよベースライン列はロックしてください。

PowerPointで無料のプロジェクト計画書テンプレートはありますか？

実行する計画ではなく、提示する計画にスライドを使ってください。マイルストーン、外部依存関係、クリティカルパスです。300行のタスクリストを提示するのは、47行目について議論するために1時間を使う確実な方法です。

PDFで無料のプロジェクト計画書テンプレートはありますか？

承認時点のベースライン版を、日付付きで書き出してそのファイルを保持してください。上記の実例では、元の計画のメール送付PDFがベースラインの唯一の残存記録であり、それをもとに再構築するのに3日かかりました。

Excelでプロジェクトトラッカーテンプレートはどこで見つけられますか？

トラッカーは、重要な行だけにフィルターをかけた同じシートです。つまり、クリティカルパスに加えて外部依存関係。ほとんどのプロジェクトでは300行ではなく40〜60行になります。計画を先に作り、フィルターでトラッカーを導出してください。2週間の間に食い違う2つのファイルを維持するのではなく。

プロジェクトトラッカーには何行必要ですか？

実質的なプロジェクトなら40〜60行です。各行のテストは、その行が2週間遅れた場合にプロジェクトの終了日が動くか、またはプロジェクト外の誰かに伝える必要が出るかどうかです。どちらでもなければ、それは計画書に属し、週次更新には属しません。これが、更新を90分ではなく20分に保つ理由です。

プロジェクト計画書とスケジュールの違いは何ですか？

スケジュールは日付と順序です。計画書はスケジュールに加えて、それを意味あるものにするすべてを含みます。目的、スコープ、前提、依存関係、リソース、リスクです。前提が記録されていないスケジュールでは、なぜ遅れたのかを説明できません。ベースライン列と原因列が存在するのは、そのギャップを埋めるためです。