目次
はじめに
「プロジェクトマネジメントのドキュメントって、結局どれを用意すればいいの？」「計画書や要件定義書って名前は聞くけど、いつ・どのタイミングで作ればいいのか分からない…」「なんとなく資料は作っているけど、これで本当に足りているのか不安…」と感じている方も多いのではないでしょうか。
実際の現場では、プロジェクトを開始した直後にゴールや体制を整理した計画書を作り、そのあとに要件定義書や設計書、テスト仕様書といったドキュメントを、工程の進み具合にあわせて一つずつ用意していきます。どの資料も、その時点で「誰が見ても同じ認識で進められる状態にする」ために必要なものです。
ただ、名前だけを見ても役割や使いどころがイメージしづらく、「どの資料から手をつければいいのか」「どこまで作れば十分なのか」で迷ってしまうことも少なくありません。
この記事では、プロジェクトで使われるドキュメントを、種類・役割・工程ごとに順番に整理しながら、「今この段階なら何を作ればいいのか」「どの資料を用意すれば安心して次に進めるのか」が自然と分かるように解説していきます。
プロジェクトマネジメントにおけるドキュメントとは？
プロジェクトマネジメントでは、開始前に作る計画書、要件定義書、設計書、進捗を記録する週次レポート、テスト結果をまとめた報告書など、工程ごとに複数のドキュメントを作成し、それぞれを関係者で共有しながら進めます。
これらのドキュメントは、タスクの抜け漏れを防ぎ、認識のズレを減らし、納期や品質を維持するための判断材料として使われます。
ここでは、なぜドキュメントがプロジェクト運営において重要になるのか、そして実際にどのタイミングでどのような場面で必要になるのかを具体的に整理していきます。
プロジェクトマネジメントでドキュメントが重要な理由
プロジェクト開始時に作成した計画書や要件定義書に、作業範囲・納期・担当者・完了条件を数値と条件で明記しておくことで、10人規模のチームでも各メンバーが自分の担当タスクと期限を同じ内容で把握できます。
ドキュメントがない状態では、口頭指示の内容が人ごとに変わり、1つのタスクに対して異なる解釈が発生し、手戻りが発生しますが、ドキュメントに記録しておくことで「何を」「いつまでに」「どの状態で完了とするか」を全員が同じ条件で確認できます。
その結果、進捗確認時に予定との差分を日単位で把握でき、遅延が出た場合も影響範囲を特定して修正判断を行えるため、納期遅延や品質低下を防ぐことができます。
プロジェクトでドキュメントが必要になる場面
プロジェクト開始時に目標・納期・予算・担当者を確定するタイミングで計画書を作成し、関係者10人全員に同一内容を共有する場面でドキュメントが必要になります。
作業範囲を確定する際には、機能一覧や対応範囲を項目単位で整理した要件定義書を作成し、認識のズレがないかを事前に確認するために使用します。
実行フェーズでは、タスクを日付と担当者単位で分解したスケジュール表を用いて、進捗を毎日または週次で更新し、遅延が発生したタスクを特定します。変更が発生した場合には、変更内容・影響範囲・対応期限を記載した変更管理表を作成し、修正の判断を行う場面で使用します。
プロジェクト完了時には、実績の納期・コスト・品質結果を記録した報告書を作成し、次回案件で同じ条件の判断ができる状態にするためにドキュメントが必要になります。
プロジェクトマネジメントで使われる10個の主要ドキュメント
プロジェクトマネジメントでは、開始前に全体方針と体制を整理する計画書、作業範囲を明確にするスコープ定義書、タスクを細分化するWBS、日単位や週単位で管理するスケジュール計画書、想定リスクを洗い出して対策を決めるリスク管理表、発生した問題を記録して対応状況を追う課題管理表、進捗率や遅延状況を共有する進捗報告書、会議内容を記録する議事録、仕様変更を管理する変更管理書、納品対象を整理する成果物一覧といった複数のドキュメントを工程ごとに使い分けます。
これらはそれぞれ役割と作成タイミングが異なり、どれか1つでも欠けると進行判断や意思決定にズレが生まれます。
ここでは、実務で使用される主要なドキュメントを一つずつ整理していきます。
①プロジェクト計画書
プロジェクト計画書では、開始日と終了日をYYYY/MM/DD形式で設定し、全体スケジュールを週単位または日単位で区切って記載します。
作業範囲は機能単位や工程単位で明文化し、対象外の範囲も同時に記載して判断基準を固定します。担当者はタスクごとに1名を割り当て、責任範囲を重複させない形で記録します。
予算は総額と内訳を数値で示し、人件費や外注費を項目ごとに分けて管理できる状態にします。進捗管理の方法として、週1回の定例会議で進捗率をパーセンテージで報告し、計画との差分が5%以上発生した場合に対応判断を行う条件を設定します。
これらを事前に定義しておくことで、実行中に判断基準が変わらず、遅延やコスト超過が発生した際にも同一条件で修正判断を行うことができます。
②スコープ定義書
スコープ定義書では、開発対象となる機能を画面単位やAPI単位で一覧化し、各機能ごとに「実装する内容」「対応しない内容」「完了条件」を文章と数値で明記します。
例えば、ログイン機能であれば、メールアドレスとパスワードでの認証を対象とし、SNS連携は対象外と記載し、正常にログインできることを完了条件として設定します。対応範囲を確定する際には、関係者全員が同じ内容で合意できるように、項目ごとに確認を行い、承認日と承認者名を記録します。
この定義がない状態で作業を進めると、追加要望が発生した際に対応可否の判断基準がなくなり、当初計画に含まれていない作業が増えて工数が超過しますが、スコープ定義書を事前に作成しておくことで、変更が発生した場合でも対象内か対象外かを文書で判断でき、作業範囲の拡大を防ぐことができます。
③WBS（作業分解構成図）
WBSでは、プロジェクト全体の作業を最上位から工程単位、タスク単位へと分解し、1つのタスクが1人で1日から3日以内に完了できる粒度まで細分化して記載します。各タスクには開始日と終了日を日付で設定し、担当者を1名に固定して責任範囲を明確にします。
さらに、タスクごとに完了条件を具体的に定義し、例えば「画面表示が仕様書どおりに再現され、エラーが発生しない状態」など、確認可能な基準を記載します。
この分解を行わない場合、作業が大きすぎて進捗を日単位で把握できず、遅延の発見が遅れますが、WBSでタスクを細分化しておくことで、各タスクの完了・未完了を日単位で判断でき、予定との差分を即時に把握して調整判断を行うことができます。
④スケジュール計画書
スケジュール計画書では、プロジェクトの開始日と終了日をYYYY/MM/DDで設定し、WBSで分解した各タスクに対して日単位で開始日と終了日を割り当てます。
タスク間の前後関係も明記し、前工程が完了しないと着手できない作業を依存関係として設定します。
さらに、週単位で進捗を確認する基準日を決め、計画上の進捗率と実績の進捗率を比較できる状態にします。
例えば、全体進捗が50%に到達する予定日を事前に設定し、その時点で実績が45%以下であれば遅延と判断する基準を設けます。
このように日付と進捗基準を明確にしておくことで、進行中に遅れが発生した場合でも、どのタスクが何日遅れているかを特定でき、調整やリスケジュールの判断を同じ条件で行うことができます。
⑤リスク管理表
リスク管理表では、発生する可能性がある事象を1件ずつ登録し、発生確率を10%・30%・50%などの数値で設定し、影響度を納期遅延日数や追加コスト金額で具体的に記載します。
各リスクには担当者を1名割り当て、対応期限をYYYY/MM/DDで設定し、発生前に実施する対策内容と発生後の対応手順を文章で明記します。さらに、週1回の定例会議でリスクの状態を「未対応」「対応中」「解消」の3段階で更新し、発生確率が50%以上に上がった場合は優先的に対策を実行する判断基準を設定します。
このように数値と期限で管理しておかない場合、リスクが放置されて発生時に対応が遅れますが、リスク管理表を事前に整備しておくことで、発生前に対策を実行でき、納期遅延やコスト増加を抑えることができます。
⑥課題管理表
課題管理表では、すでに発生している問題を1件ずつ登録し、発生日をYYYY/MM/DDで記録し、内容を具体的な事象として記載します。
各課題には担当者を1名割り当て、解決期限を日付で設定し、対応状況を「未着手」「対応中」「完了」の3段階で更新します。さらに、影響範囲を納期遅延日数や対象機能数で数値化し、優先度を高・中・低のいずれかで判断できる状態にします。
週1回の定例会議で全課題を確認し、解決期限を過ぎたものは対応方法の見直しをその場で決定します。
このように期限と状態を明確に管理しない場合、課題が放置されて遅延が拡大しますが、課題管理表で管理することで、対応状況を日単位で把握でき、解決の遅れを防ぐことができます。
⑦進捗報告書
進捗報告書では、報告日時点の全体進捗率をパーセンテージで記載し、計画上の進捗率との差分を数値で明示します。
各タスクについては、完了・未完了を日付単位で整理し、未完了のタスクは何日遅れているかを具体的に記載します。さらに、遅延が発生しているタスクについては、原因と対応内容、修正後の完了予定日をYYYY/MM/DDで設定します。
報告の頻度は週1回または日次で固定し、同じフォーマットで更新することで、前回との差分を比較できる状態にします。
このように数値と日付で進捗を記録しておかない場合、遅れの発見が遅れますが、進捗報告書を定期的に作成することで、遅延を早期に把握し、修正判断を迅速に行うことができます。
⑧議事録
議事録では、会議の実施日時をYYYY/MM/DD HH:MMで記録し、参加者全員の氏名を記載したうえで、決定事項・保留事項・対応タスクを項目ごとに文章で残します。
各対応タスクには担当者を1名設定し、実施期限を日付で明記します。会議終了後は24時間以内に関係者全員へ共有し、内容に誤りがないかを確認できる状態にします。
この記録がない場合、会議中に決めた内容が参加者ごとに異なる解釈となり、対応漏れや重複作業が発生しますが、議事録を作成して共有することで、誰が何をいつまでに実施するかを同じ内容で確認でき、作業のズレを防ぐことができます。
⑨変更管理書
変更管理書では、変更内容を1件ずつ登録し、申請日をYYYY/MM/DDで記録し、どの機能や工程に対する変更かを対象範囲として明記します。
変更による影響は、追加工数を人日単位、納期への影響を遅延日数で数値化し、コスト増加が発生する場合は金額で記載します。各変更には申請者と承認者を設定し、承認日を記録したうえで、対応開始日と完了予定日を日付で管理します。
この記録がない状態で変更対応を行うと、どの変更が正式に承認されたものか判断できず、作業範囲とスケジュールが不明確になりますが、変更管理書で申請から承認までを記録しておくことで、対応可否と影響範囲を同一条件で判断でき、無秩序な変更による遅延やコスト超過を防ぐことができます。
⑩
成果物一覧
成果物一覧では、プロジェクトで作成するすべての成果物を1件ずつ登録し、成果物名・作成担当者・提出期限をYYYY/MM/DDで記載します。
各成果物には提出形式をPDFやExcelなどのファイル形式で指定し、レビュー担当者と承認日を設定します。さらに、各成果物ごとに完了条件を明記し、例えば「指定フォーマットで作成され、レビュー指摘が0件の状態」など、確認できる基準を設定します。
この一覧がない場合、どの成果物が未提出かを把握できず、納品漏れや確認漏れが発生しますが、成果物一覧を作成しておくことで、提出状況を日付単位で管理でき、未完了の成果物を特定して対応を進めることができます。
工程別に見るプロジェクトマネジメントドキュメント
プロジェクトマネジメントで使用するドキュメントは、開始から完了まで同じものを使い続けるのではなく、立ち上げ時には目的や体制を決める計画系の資料、実行中には進捗や課題を管理する運用系の資料、完了時には成果や振り返りを整理する報告系の資料といったように、フェーズごとに役割が明確に分かれています。
各工程で必要なドキュメントを適切なタイミングで作成し、更新していくことで、進行の遅れや認識のズレを防ぐことができます。
ここでは、工程ごとにどのドキュメントが使われるのかを具体的に整理していきます。
プロジェクト開始・計画フェーズのドキュメント
プロジェクト開始・計画フェーズでは、開始日と終了日をYYYY/MM/DDで設定したプロジェクト計画書を作成し、全体スケジュールと予算を数値で確定します。
同時に、対応する機能や作業範囲を項目単位で明記したスコープ定義書を作成し、対象外の範囲も含めて記録して判断基準を固定します。
さらに、作業を1日から3日で完了できる単位に分解したWBSを作成し、各タスクに担当者と開始日・終了日を割り当てます。加えて、想定されるリスクを発生確率と影響日数で数値化したリスク管理表を用意し、対応期限と担当者を設定します。
これらを開始前に作成して関係者全員で承認しておかない場合、作業範囲やスケジュールの認識が一致せず、実行段階で修正が発生して遅延が発生しますが、事前にドキュメントを整備することで、同一条件で作業を開始でき、進行中の判断基準を固定することができます。
プロジェクト実行・管理フェーズのドキュメント
プロジェクト実行・管理フェーズでは、週1回または日次で更新する進捗報告書を作成し、計画進捗率と実績進捗率の差分をパーセンテージで記録します。
同時に、発生した問題を発生日と解決期限をYYYY/MM/DDで管理する課題管理表を運用し、対応状況を「未着手」「対応中」「完了」で更新します。
変更が発生した場合は、変更内容と影響範囲を人日と遅延日数で記録した変更管理書を作成し、承認日をもとに対応を開始します。さらに、会議ごとに議事録を作成し、決定事項と対応タスクを担当者と期限付きで記録し、会議後24時間以内に共有します。
これらを継続して更新しない場合、進捗や課題の状態が把握できず、対応が遅れますが、各ドキュメントを定期的に記録することで、遅延や問題を日単位で把握し、修正判断を同じ条件で行うことができます。
プロジェクト完了フェーズのドキュメント
プロジェクト完了フェーズでは、全成果物の提出状況を成果物一覧で確認し、提出日と承認日をYYYY/MM/DDで記録して未完了の有無を最終確認します。
同時に、実際の終了日と当初計画の終了日との差分を日数で記録し、コストについても予算額と実績額の差分を金額で整理した完了報告書を作成します。さらに、発生した課題と対応結果を課題管理表から抽出し、再発防止のための対応内容を記録します。
これらを完了時に整理しておかない場合、納品漏れや実績の差分が把握できず、次回プロジェクトで同じ判断ができませんが、完了フェーズでドキュメントを確定させることで、成果物の納品状況と実績を数値で確認でき、次回の計画に同じ条件で反映することができます。
プロジェクトドキュメント管理の基本
プロジェクトでは、計画書や進捗報告書、議事録などのドキュメントを作成するだけでは不十分で、誰がどこに保存し、いつ更新し、どの版を正とするかまで決めて運用する必要があります。
共有ルールが曖昧なまま進めると、最新版が分からず古い情報で判断してしまい、修正や手戻りが発生します。そのため、保存場所の統一、閲覧権限の設定、更新手順や版数の付け方をあらかじめ決めておくことが重要です。
ここでは、ドキュメント管理を安定させるための基本的なルールと運用方法について整理していきます。
ドキュメント共有のルール
ドキュメント共有のルールでは、すべての資料をクラウドストレージ上の1つのフォルダに集約し、フォルダ構成を「計画」「実行」「報告」など工程ごとに固定します。
各ファイルには作成日をYYYYMMDD形式で付与し、ファイル名を「20260324_計画書_v1」のように統一します。
更新した場合はバージョン番号を1ずつ上げ、更新日時と更新者名をファイル内に記録します。共有範囲は関係者全員に閲覧権限を付与し、編集権限は担当者のみに制限します。
新規作成や更新を行った場合は、当日中にチャットまたはメールで通知し、確認期限を翌営業日までに設定します。
このルールを定めない場合、最新版のファイルが特定できず、古い内容で作業が進むことで手戻りが発生しますが、共有ルールを統一することで、全員が同じファイルを参照し、内容の不一致を防ぐことができます。
ドキュメント更新とバージョン管理
ドキュメント更新とバージョン管理では、ファイルを更新するたびにバージョン番号を「v1.0」「v1.1」のように0.1単位で上げ、更新日時をYYYY/MM/DD HH:MMで記録し、更新者名を明記します。
変更内容はファイル内の更新履歴欄に「2026/03/24 v1.1 スケジュール日付を3日延長」のように具体的に残します。重要な仕様変更の場合はバージョンを1.0単位で上げて「v2.0」とし、変更前のファイルは削除せずに「_old」フォルダへ移動して保管します。更新後は当日中に関係者へ通知し、最新バージョンを基準として作業を進めることを明示します。
この管理を行わない場合、複数のバージョンが混在してどの内容が正しいか判断できず、誤った情報で作業が進みますが、更新履歴とバージョンを統一して管理することで、常に最新の内容を特定でき、作業のズレを防ぐことができます。
まとめ
プロジェクトマネジメントでは、開始前に計画書やスコープ定義書で作業範囲・納期・担当者を数値と条件で確定し、WBSやスケジュール計画書でタスクを1日から3日単位に分解して日付ベースで管理します。
実行中は進捗報告書で進捗率をパーセンテージで把握し、課題管理表や変更管理書で発生した問題や変更内容を日付と影響数値で記録しながら対応を進めます。
会議内容は議事録で24時間以内に共有し、対応タスクと期限を固定します。完了時には成果物一覧と報告書で提出状況や納期・コストの差分を数値で整理し、次回に同じ条件で判断できる状態にします。
これらのドキュメントをフォルダ構成・ファイル名・バージョン番号まで統一して管理することで、全員が同じ情報を基準に作業でき、認識のズレや手戻りを防ぎながら、納期と品質を維持した進行が可能になります。