プロジェクト計画書と要件定義書の違いとは？混同しがちな2つを解説

プロジェクト計画書とは

プロジェクト計画書とは、プロジェクトを進めるために、必要な内容やスケジュールを資料化したものです。

大規模なプロジェクトになると多数の人員が関わります。
そのような場合に、プロジェクトに関わる全てのメンバーで認識を合わせるためのツールとしても活用されます。
当初のプロジェクトの目的からズレが生じないように防止する役目も果たします。

プロジェクト計画書とは何かについて、具体的に見ていきましょう。

プロジェクト計画書を作成する目的

プロジェクト計画書を作成する主な目的は、プロジェクトを円滑に進めるためのスケジュール設定、およびそのスケジュール管理が挙げられます。

その他、プロジェクトに参加するメンバーそれぞれが、プロジェクトの目的、求められる品質、期間などを共有することも目的とします。

プロジェクト計画書を指針として、メンバーが作業を進めていくためです。

プロジェクト計画書に記載する項目

プロジェクト計画書に記載する内容としては、下記のような項目が挙げられます。

特にプロジェクト計画書のフォーマットを決めて作成すれば、情報共有しやすくなるほか、後から修正を入れる際にも効率よく行えます。

• 具体的なプロジェクトスケジュール、日程
• 担当範囲と担当メンバー
• 予算、成果物の品質目標

具体的なプロジェクトスケジュール、日程

プロジェクト開始日、マイルストーン、テスト、リリース日などについて細かい日程を決め、計画書に書き込んでいきます。

担当者と担当範囲

各タスクの担当者、担当範囲はチームで状況を共有するためにも必要な情報です。
担当範囲と組織図、役割表などを作成すれば、全員が誰が何を担当しているのかがより分かりやすくなります。

円滑に進めるためにプロジェクト進捗状況の共有が重要となるため、誰が担当なのか、担当範囲はどこまでか、を分かりやすくしておくことは必須です。

予算、成果物の品質目標

プロジェクトをフェーズ、機能などに分け、大体の項目別予算、項目別予算から導き出し、全体の予算を算出して記載します。
また、成果物の品質目標についても決め、目的に合わせた予算を配分し、予算内で品質レベルに到達できるように設定します。

修正や切り戻しでスケジュールが長引くとコストがかさむことを計算に入れ、予算に余裕を持たせることも必要です。

プロジェクト計画書を用いる利点

プロジェクト計画書には、スケジュールごとに詳細に各メンバーの担当範囲、期限などが記載されているため、メンバーが責任を持ち作業にあたりやすくなります。

これにより、メンバーが自分の役割のみでなく、他のメンバーとの関係を把握できるため、迷うことなく取り組むべきタスクに取り掛かれるという利点が生まれます。

担当範囲が分かりづらい場合は、認識の違いが生まれたり、都度確認が必要になったりするのですが、そういったことがなくなります。

その他の大きな利点としてはプロジェクトのリスク対応があります。
プロジェクト計画作成において、あらかじめリスクを査定しておくことは、スケジュール通りに進めるために見落とせないことです。
リスクへの対応を決めておけば、計画の脱線、大きな手直しなどの発生を防げます。

また、どこでどのようなリスクが発生し、どのような対応をしたかを可視化できるという点も利点です。　　

要件定義書とは

要件定義書とは、顧客に行ったプロジェクトの提案をより具体的に実行レベルに進めるために作成されるものです。
顧客の要望、要望を具体的に提供するためのシステム要件、運用環境、優先順位、プロジェクトの予算、品質などを盛り込んで作成します。

具体的に要件定義書とは何か、作成目的、課題などについて見ていきましょう。

要件定義書を作成する目的

要件定義書は、プロジェクトを実行するために、顧客およびプロジェクトメンバーとの意識合わせを行うことを目的として作成されます。

顧客のビジネス要件、目的、戦略にシステム要件サービスが合っているか、運用するにあたっての環境、機能を要件定義書で明確にし共有します。

具体的には、プロジェクトのスケジュール、予算、納品方法、成果物の品質について、コミュニケーション方法についても記載します。

プロジェクトの途中でトラブルが発生しないよう、要件定義書をしっかりと定めておくことが重要です。

要件定義書と提案書の関係

要件定義書を作成するにあたり、ベースとして活用する資料として提案書というものがあります。
提案書は顧客に最初に提案を行う際に提出する資料です。
提案書で出した内容をカバーした、具体的なプロジェクト実施同意書にあたるのが要件定義書です。

提案書の段階で出された顧客の要望を読み取り、それらを織り込んで要件定義書を作成するため、提案書は要件定義書のベースと言えます。

要件定義書の記載項目

要件定義書に記載する項目は下記です。

• プロジェクトの目的・課題
• システムの機能・品質
• どこまでをシステム化するのか、システム化で目指す事業目標範囲
• 予算
• 顧客とのコミュニケーション方法・頻度
• リリース予定・スケジュール
• リスクやそれに対応するための対策

この中で予算は、プロジェクト計画書で算出したものを用いれば、実際にかかる予算に近くなります。

プロジェクト計画書と要件定義書の違いとは

本題に入り、プロジェクト計画書と要件定義書、両者の違いについて比較していきます。

まず、プロジェクト計画書は、プロジェクトのスケジュール、進捗を詳細に管理することを主な目的とするものです。
これに対して要件定義書は開発プロジェクトを進めるために顧客とプロジェクトメンバーに対してプロジェクト実行のための要件を示したものです。

どちらも開発プロジェクトを進めるに先だって必要ですが、利用目的と盛り込まれる内容に違いがあります。

要件定義書はプロジェクト計画書のあとに作成

要件定義書は、通常プロジェクト計画書を作成した後に作成されるものです。
プロジェクト計画書で立てたスケジュール通りに全体を通して途中で頓挫することがないよう、十分なリソースを織り込むことが必要となるためです。

十分なリソースは、まずプロジェクト計画書を解析して、どの程度必要になるのかを割り出します。

共有対象の違い

プロジェクト計画書と要件定義書では、共有する対象に違いがあります。
プロジェクト計画書は、プロジェクトに関わるメンバー同士で共有するのに対し、要件定義書は顧客とプロジェクトメンバーでの共有を目的とします。

要件定義書は外部に提出する資料、プロジェクト計画書は内部で使用する資料と区別しても良いでしょう。

プロジェクト計画書では、要件定義書に基づき中長期の目標を立て、各タスクの進捗管理やマイルストーンの達成率確認を行います。

要件定義書は顧客への分かりやすさを意識して作成

要件定義書は分かりやすく作成することが重要です。
キックオフミーティングなどで顧客との意識合わせに用いられることもあり、顧客に提出するためです。

プロジェクト計画書は専門的な用語を利用しても問題ありませんが、要件定義書では解説や注釈を加える必要があります。
そのうえ、視覚的に分かりやすいよう図表を用いるなどの工夫が望まれます。

特に重要な点は、分かりやすく、明確に記載することです。
各項目を明確に、曖昧さを失くすように記載し、顧客との認識に相違が出ないように努めます。

また、顧客が目的とするビジネス要件をカバーできているか、システム化による効率化や投資効果については、図、数値で示すと明確です。

開発プロジェクトにおけるプロジェクト計画書と要件定義書の活用の仕方

プロジェクトの可視化と共有

プロジェクトを進めている間は、定期的な顧客と進捗の認識合わせが必要です。
基本的には、要求定義書のスケジュール通りにプロジェクトが進んでいるかを確認する作業を行います。

これには、プロジェクト計画書を可視化することが必要不可欠です。

プロジェクト計画書の可視化のためには、下準備が必要です。
WBS（Work Breakedown Structure）、ガントチャートなどを用いてスケジュールのロードマップを作成することで下準備を整えます。

WBSとは、プロジェクトにおける個々の機能を作成するために必要な作業をタスクに分け表にしたもののことを指します。

タスクとは、機能の構成要素となる一番小さい作業単位を指し、この小さい要素が組み合わさり機能が作られます。例えば、うどんを作る工程を考えてみると、「麺をゆでる」「つゆを作る」「ねぎを切る」「天かすを乗せる」という作業がタスクです。

WBSは、構成する要素を最小のタスクレベルまで分解して、それらの関係性を表にしたものです。
WBSでは、前のタスクが完了後に開始されるタスクがある場合、依存関係のあるタスクを結びグループ化（クリティカルパス化）して表示します。

ガントチャートは、カレンダーに横棒で各フェーズの対応期間を示したものですが、ガントチャートにWBSを組み合わせると有用です。
カレンダーのスケジュールに対応するそれぞれのタスクの進捗がブレイクダウンされて対比できるためです。

その実現には、ガントチャートにWBSが組み込まれ、その配下のタスクの進捗状況がワンクリックで確認できるといったスケジュール管理システムがあれば便利です。　

プロジェクト計画書でスケジュールを可視化することで、要件定義書とつきあわせた進捗管理ができます。
顧客にスケジュール報告する際も、進捗に関する質問にスムーズに応えられます。

リスク管理を網羅

プロジェクトをスケジュール通りに進めるためには、リスクの管理が必須です。

要件定義書にはプロジェクトで考えられるリスク、またリスクに対応する具体的な方法を記載します。
リスクの管理、防止にあたっては、まずプロジェクト計画書でタスク漏れがないかを洗い出すことから始めます。

タスク漏れがあることにより、不十分なままプロジェクトを進めてしまわないようにするためです。
システムの機能面はもとより、機能面以外の作業環境上のリスクも見落とさないよう、プロジェクト計画書にチェック項目を作成します。

機能面以外の作業環境上のリスクとは、セキュリティが保たれているか、またはメンバーの稼働率などです。
これにより、機能面以外のリスク、セキュリティが不完全、特定メンバーの負荷率が高いことなどでリスクにつながる可能性を防ぎます。

プロジェクトを進めるうちで想定されるリスク、それにより引き起こされるスケジュールへの遅れへの対応を盛り込んでおくことも欠かせません。

プロジェクト計画書をベースにした要件定義書のリソース記載方法

プロジェクト計画書をもとにした要件定義書へのリソース記載手順について紹介します。
プロジェクト計画書で計算された数値をもとに、必要な予算、人員などリソースを算出し、要件定義書へ記載します。

要件定義書に記載するプロジェクトリソースは、プロジェクト計画書の組織図、役割図などをベースに算出します。
その際には、プロジェクト範囲、プロジェクトの目的をプロジェクト計画書とずれのないように定めます。

要件定義書内でプロジェクトの全体的なリソースを記載し、顧客との共有に備えたドキュメンテーションを行っていきましょう。

プロジェクト計画書と要件定義書の違いを明確にして開発品質向上を目指そう

プロジェクト計画書と要件定義書は、両方とも資料作成というフェーズの完成度を「いかに高められるか」が成果物の品質に結びつく、という共通点を持ちます。

しかし、資料に盛り込まれる内容と目的には違いがあります。
プロジェクトの目的、効果、予算、リソースといったプロジェクト全体の包括的な内容をカバーする要件定義書に対して、プロジェクト計画書はプロジェクトを推し進めるための具体的なスケジュールを示したものになります。

プロジェクト計画書、要件定義書ともに作成する担当者は開発経験に加えて、スケジュール管理、フォローアップやクライアントとのやり取りなどの知識、経験を持つことが望まれます。

それぞれの違いを押さえて、プロジェクト開始前の準備を周到に行い、プロジェクト計画書、要件定義書を綿密に作り上げることで、成果物の完成度を高められるでしょう。