members

members

Webサイト構築が始まるときに作っておくべきプロジェクト計画書の作り方(Webディレクター/Web担当者向け)

Tweet

Webサイト構築におけるプロジェクト計画書とは、プロジェクトを進めていく上で最初にWebサイト制作担当者からクライアントご担当者様へ提示する資料であり、プロジェクトを計画し、推進していく上でお互いに合意を取るために必要な資料です。

この資料の有無でプロジェクトが予定通りに進むのか、はたまたその時々で変更が発生するたびにプロジェクトの変更に時間が取られ、費用とスケジュールが切迫されていくのかなど、大きな差が出ていきます。なにより、より良いプロジェクトとしていくためにはご担当者様との「共通言語」「価値観」が必要となり、その役割としてプロジェクト計画書が存在します。

このプロジェクト計画書の合意によって、クライアントご担当者とより良いプロジェクトを作り上げていけるのではないかと考え、作り方の一例をご紹介致します。

どのような要素が必要なのかを一覧化し、要所で資料化した場合を想定して記事にしました。
過不足あるかと思いますが、プロジェクトによって柔軟に変えていくということを考えても一通りは網羅できているのではないでしょうか。

プロジェクト計画書に必要な要素

プロジェクトの目的

プロジェクトの目的の例

一言、一文でプロジェクトの目的を説明できることが理想ですが、難しい場合はわかりやすい形でまとめることが大切です。上図の場合はWebサイトとしてユーザーと企業(クライアント様)にとって「あるべき姿」の説明します。

プロジェクト説明

現状の課題と解決策の書き方の例

プロジェクトの全体像を説明。課題と目的、ゴールも簡潔に。プロジェクト名もわかりやすくしましょう。

与件の整理

背景をベースに「課題」と「解決策」。「結果」を描きます。

RFP(依頼事項)の整理

改めてクライアント様の要望を明記します。確認した上で計画していることを示します。

課題と対策

RFPを確認した上で要望と対策をセットで記述します。

スコープ

プロジェクトのスコープ

戦略、設計、開発などに各フェーズにスコープを明記します。上図では箇条書きとなっていますが、一般的なWebサイト構築の際に必要と考えるものとなっています。

納品成果物

納品成果物について

プロジェクトにおいて重要な納品成果物を網羅しておきます。箇条書きになっていますが、ソースコード等の場合はサイトマップとあわせたファイルリストという形で纏めることによって抜け漏れや後対応がしやすくなります。長期プロジェクトであれば各フェーズ毎の納品成果物も明記します。この納品成果物を明記・合意をしていないと後ほどのトラブル&納品しなくても良いデータまで要求される、要求したのに貰えない、など発生する可能性が出てくるため注意しましょう。

スケジュール

全体のスケジュールの例

WBSのほうが詳細の確認が可能となりますが、一番最初の計画ということで全体的なスケジュールにしたほうが確認をする際に便利です。

予算配分

工数の設計を行い、どのフェーズにどのくらいのアサインが必要など、スケジュールに落とし込みます。この配分を行うことで該当プロジェクトに必要な人材だったり、予算が必要なのかを出すことが可能となります。

プロジェクト体制図

プロジェクト体制図の例

制作担当者、クライアントご担当者様の体制を「名前、所属部署、ポジション、メールアドレス」をセットで明記しておきます。特にクライアント側の決済権限を持つ人物や連絡窓口など、キーマンとなり得る人物はしっかり明記することが大切です。

会議体について

プロジェクト会議体の例

プロジェクトの間、具体的な日付を持ってクライアントといつ打ち合わせを行うのか明記します。また、この際に確認いただくものも明記し、誰に参加していただくかなども記述。
この設定をしっかりしておかないと会議をしても「とりあえずの会議」となってしまい無駄な時間が生まれる可能性もあります。

コミュニケーションルール

コミュニケーションルールの例

どのようにお客様と連携するのか明記します。これも重要で、メールでのやり取りなのか、メーリングリストは必要なのか、どのような件名にするのかなどのルールを統一していない場合に混乱を招く可能性があります。
また、ファイルのやり取りについては様々な方法がありますが、企業間でのやり取りの場合は各社セキュリティ規定が存在するかと思いますので、確認が必要です。

プロジェクトの前提条件

プロジェクト前提条件の例

プロジェクトの前提条件は非常に重要です。
プロジェクト全体の変更が発生した場合や、なんらかの追加対応もまとめてやってしまう、というときにこの前提条件を記述しておくことで揉めずにすむこともあります。
制作担当者にとっての防衛ラインにもなる前提条件でもあり、クライアントご担当者にとっては絶対にやってもらいたいこと、プロジェクトの変更可能性がある場合はどうなるのかなどを予め決めておく必要があります。追加費用、変更定義、個人情報取り扱いなど必ず明記しましょう。特に、スコープ外のことは対応しません、と明記しておかないと「ついでに」ということで本来進めるべきプロジェクトの品質低下を招く可能性もあります。

まとめ

プロジェクト計画書は制作担当者とクライアントご担当者がプロジェクトにおける「計画」+「価値観」を共通言語化するものでもあります。
プロジェクトを進めている最中に「このプロジェクトはなんのためにあるのだろう」と立ち返るときや、プロジェクトに途中からアサインされるメンバー、該当プロジェクトを再度リニューアル、改善する際にどのようにしてプロジェクトが練られたのかを確認するためにも使うことができます。
よりよいプロジェクトにしていくために、プロジェクト計画書をしっかり作ることをオススメいたします。

コラム執筆

鈴木 正行(すずき まさゆき)

第2ビジネスユニット-アカウントサービス第2ユニット所属。宮城県仙台市出身、2011年東日本大震災にて被災、継続的な復興支援として仙台に拠点を立ち上げるというメンバーズに共感し2012年5月に入社。プロジェクト計画から要件定義、設計やフロントエンドエンジニアリング、ディレクションなど業務とする。趣味はラーメン屋巡り、料理、Webの未来について考えること。