members

members

Webサイト構築が始まるときに作るプロジェクト計画書の納品成果物とスケジュールの書き方(Webディレクター/Web担当者向け)

Tweet

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

ここではタイトルにある通り「納品成果物」と「全体スケジュール」の書き方について書きます。

ここで重要なのはクライアントとの作るべきものと道筋の共有であり「プロジェクトが終わるまでにするべきこと」です。プロジェクトの「予定」や「タスク」を説明するときにお互いがスケジュールを共有していることで、同じ方向に向かってプロジェクトを推進していくことが可能となります。

納品成果物がなにか次第でスケジュールに大きく影響し、ここで握っておかないと後々トラブルとなりやすいです。こちらの記述内容によっては「納品するものしないもの」の差が出てくるため、しっかりと説明が必要です。

ここでは納品成果物とスケジュールの例をご紹介します。
また、例で上げた内容でも足りない場合もあるプロジェクトもあれば、余分すぎる場合もあるのであくまで例ということで考えてください。

納品成果物について

プロジェクト計画書

全体スケジュール、スコープ定義、納品物定義、体制定義、会議体設計 など

現在説明しているプロジェクト計画書のことです。こちらに様々なことを書いておくことで、プロジェクト自体の目的など振り返りが可能です。
また、「やってもらうつもりだった」「やらないつもりだった」という言った言わない、思い違いなどを避けることもできます。

開発要件定義書

実装、表示要件 など

画像では少なくしてしまっていますが開発スコープ、運用要件、動作環境、使用するライブラリ諸々を明記してあげる必要があります。要件定義書はある種、制作側の腕の見せどころでもありますね。

デザインデータ

psd、ai、xd など

例えばトップページやカテゴリページ、コンテンツページやお問い合わせページなどのデザインデータが存在する場合、納品が必要となることもあるでしょう。また、クライアントによってはpsdではなくSketchで、とかXDで、とかもあるため、ここの定義はしっかりとしておく必要があります。

ソースコード

html、css、js など

デザインデータからWebサイトとして形にした姿を納品します。ソースコードそのものをサーバーにアップする、なども必要となる可能性もあります。また、記述した拡張子以外にも全然あり得るため、どのようなファイルが必要になるのか事前に確認しておきましょう。

全体のスケジュールの例

やるべきことが決まればあとは全体のスケジュールに無理がないかの調整が必要です。場合によってはスケジュールにまったく余裕がないが故に、スケジュールがただのお飾りになることもしばしば。但し、最初の段階でしっかりと確認をしておかないとクライアントとも、制作側としても不幸になるだけです。できること、できないことを判断した上でスケジュールを立てましょう。

どこにどれくらいの期間が必要なのか、合意を取る必要があります。特に公開日や納品日については明記しておく必要があるでしょう。よくあるのは公開した後、納品した後に次々と質問がきて、ついつい対応してしまうけどそんなことをしていると工数が発生する、でも次の仕事に繋がるかも、、、という生産性が不明瞭な状態になるのです。とはいえ、クライアントとの良好な関係を維持するのであればそれも一つの手段ではあります。

要件

20○○年○○月○○日~20○○年○○月○○日

要件定義書、ワイヤーフレームの作成を行う。

開発

20○○年○○月○○日~20○○年○○月○○日

デザイン開発、フロントエンド開発、システム開発を開発環境にて行う。

テスト

20○○年○○月○○日~20○○年○○月○○日

開発環境からステージング環境に移行。ステージング環境にて総合テストを行う。

公開・納品

20○○年○○月○○日~20○○年○○月○○日

本番環境にて20○○年○○月○○日午前○○時にアップロード。

まとめ

プロジェクト計画書は制作担当者とクライアントご担当者がプロジェクトにおける「計画」+「価値観」を共通言語化するものでもあります。

納品成果物ではそれぞれの作るべきもの、全体スケジュールではそれぞれのフェーズに対して期間とやることを簡単に記述しています。もちろん、これを深掘りしたWBSの作成なども必要ですが、初期に提出するプロジェクト計画書としてはこのレベル感で共有することも多いです。

プロジェクト計画書で重要なことは、クライアントと制作者(つまり、プロジェクト計画書を作る人ではなく見る人)のために重要なこととパッと見て振り返ったりすることができるようにしておくことです。

WBSのように事細かなスケジュールをプロジェクト計画の初期段階から提示した場合、スケジュールの調整を延々とする、ということが発生する場合もありますが、プロジェクト規模が(数ヶ月で終わるような)小さい案件の場合は最初からWBSを作って提出するのもありでしょう。

コラム執筆

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

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