発注者と制作者の双方で円滑なコミュニケーションが図れるようにするために、どの様な対策をされていますでしょうか。 この記事では、円滑なプロジェクト進行するために欠かせない「プロジェクト計画書」の役割や記載項目、作成のポイントについて紹介します。 プロジェクトをよりよいものにしていくために、ご参考いただければ幸いです。

1. プロジェクト計画書とは？

プロジェクト計画書は、プロジェクトを推進していく上で利害関係者と"共通理解"を高めるための重要なドキュメントです。 具体的な内容は後述の「プロジェクト計画書の記載項目」で述べますが、プロジェクト発足段階においてプロジェクトの目的やゴールを明確に定義して、必要な作業や手法などを文書化することで、関わる人の共通理解の基盤となって、円滑なプロジェクト進行へと導きます。 プロジェクト進行にあたって必要な情報をまとめた計画書であり、共通理解を高めた上で原則はそのまとめた情報からずれることなく進行させるのが目的です（もちろんプロジェクトを進めていく中で記載内容に変更があった場合は適宜調整を行います）。

2. プロジェクト計画書の役割

Webサイトのプロジェクトは、どんな良いコンテンツやデザインが出来ても、認識の違いでプロジェクトの計画や進行が破綻することも多いものです。 プロジェクトが始動した段階で、プロジェクト計画書を作成して利害関係者（ステークホルダー）と読み合せを行うことは、プロジェクトを成功させるためには効果的です。

3. プロジェクト計画書の記載項目

プロジェクト計画書と「計画」という言葉があるため一見スケジュールだけのようにも思えますが、中身はプロジェクトの背景やゴール、スコープ、スケジュール、体制図、コミュニケーションルール...など多岐に渡ります。 ここでは、3回にわたってプロジェクト計画書の記載項目を紹介します。

1. プロジェクト概要（背景/目的/ゴール）

はじめにプロジェクトの背景と目的、ゴールを記載します。 - 背景：「なぜプロジェクトが発足したのか（課題）」 - 目的：「あるべき姿は何か。」「最終的に達成したい事は何か。」 - ゴール：「目的到達のための具体的な目安は何か（KGI/KPI）」 計画書を作成する前のRFPやオリエンテーション、ヒアリング、提案書などの情報を基に記載します。 （例） プロジェクトが進行過程で思わぬ課題が発生したり、途中から参画するメンバーがいても、原点である背景/目的/ゴールに立ち返れるように具体的に記載すると良いでしょう。

2. プロジェクトスコープ定義

制作対象のドメインや、制作全体の作業の中から対象となる領域と対象外となる領域を定義します。 自社で行う作業はもちろん、逆に自社で行わない作業を明記にすることで分掌を明確にします。これがプロジェクトに必要な工期や工数、費用の土台になります。 （例） - リニューアル対象サイト：https://www.XXXXXXXXXX.co.jp （日本語/英語サイト） - 要件定義 - 情報設計 - デザイン制作 - フロントエンド開発 - システム開発 - インフラ構築（サーバー、ドメインなど） - 素材調達（原稿・画像など） - 撮影業務 - ガイドライン制作（デザイン、実装など） - テスト計画

3. 実施タスクと想定成果物

プロジェクトの規模が大きかったり、利害関係者が多く存在すると、誰が何を担当するのかが不透明になることもあります。今後の進行において各工程毎に必要な作業内容や概要、成果物、主担当を明記します。「いつ」「どのようなものを」「誰が」ということを可視化されていて認識合わせすることが大切です。 （例） その他、プロジェクトが成り立つための前置きとなる条件 ＝ プロジェクトの前提条件を明記することも大切です。プロジェクトを成功へと導くために、様々な内部要因や外部要因が発生することがあります。前提条件を事前に洗い出し、プロジェクト計画書で明らかにする。そして、利害関係者の認識を一致させておくことで後々に起こる事象に対する予防線になることもあります。 （前提条件の例） - スケジュールは暫定のものであり要件定義や情報設計を経て、公開日を確定する。 - プロジェクト進行中のスコープの増加や仕様変更に応じて追加費用が発生する。 - サーバーおよびドメインは提供いただく想定である。 - プロジェクト計画書に記載されているスコープ外の対応はしない。 - 成果物は計画書に記載されているもののみであり、その他の作成は行わない。 - ​​​​お客様都合で公開の延期や作業の中断が発生した場合、リソース調整費用が発生する。 - 体制の維持はプロジェクト期間中のみであり、プロジェクト期間外は体制の維持をしない。

4. 納品物

検収対象となる納品物を各工程毎に明記します。 制作進行が順調でも納品物の認識がずれていると、納品対象ではないデータを作成/納品する必要が出てきたり、欲しいと思っていたデータが納品されないなど、後々トラブルになることもあります。 （例） [次回の記事](/blog/107.html)では、プロジェクト計画書の記載項目の「マイルストーン及びスケジュール」から「コミュニケーションルール」についてお話ししたいと思います。