webサイトリニューアルのプロジェクト計画書。進行の共通認識を持つための必須ステップ。
プロジェクトをふわっとスタートしてはダメな理由。
文字通りといえば文字通りなのですが、
プロジェクと開始から完了までに、どのようにプロジェクトが進むのかを示した計画書
です。
webサイトリニューアルをスタートするとなったら、まずプロジェクト計画書で、今後の進行について、制作会社、発注者となる企業間ですり合わせをすることが必要です。
想定された制作期間の中で、どういうタスクが発生し、いつまでに何を完了させる必要があり、どういうアウトプットを提出するのかを、クライアント企業とすり合わせます。
私は、通常、クライアントとのキックオフミーティングでは、プロジェクト計画書の話だけをしています。
きちんとここをしておかないと、クライアントと、認識の齟齬があったとしてもそれに気づかないまま進行し、あとで「そういうつもりではなかった」ということが起こりうるからです。
大事なことは
「このプロジェクトはこういう風に進めるつもりですよ」
ということを最初に明示することです。
実は「初めてwebサイトリニューアルを担当します。」というクライアント担当者がほとんどです。
webサイトリニューアルの担当者は、それ以外にも複数の役割を兼任しているものです。
その担当者にプロジェクト進行のイメージを持ってもらうことは、今後のスムーズな進行のためには不可欠です。
プロジェクト計画書に含めるべきこと
では、webサイトリニューアルのプロジェクト計画書に含めるべきことにはどのようなものがあるでしょうか。
プロジェクト計画書を提示するのは、プロジェクトの最初段階なので、具体的なwebサイトの機能やコンテンツは決まっていません。
提示すべきは、繰り返しになりますが「このプロジェクトをこのように進めていきますよ。」というところです。
私が関わったプロジェクトでは、そのために下記のようなことをプロジェクト計画書に含めるようにしています。
1. プロジェクト概要
- サイトリニューアルに至った経緯
- 解決すべき課題
- プロジェクト計画時点ではっきりしている制作スコープ
などを整理しておきます。
2. プロジェクトの目的
このwebサイトリニューアルで成し遂げたいことは何か、どうなれば成功と考えるのか、ゴールイメージを明確にしておきます。基本的には、プロジェクト概要に挙げた「課題を解決すること」が入ります。
3. 各制作フェーズの定義と成果物
制作フェーズというのは、プロジェクト進行の「工程のひとまとまり」のことを言います。
プロジェクト計画時には、この各フェーズで何が成果物になるのか、どういうポイントで承認いただきいのかを明確にしておきます。
たくさん項目があるように見えると思いますが、それぞれの「具体的な中身」はプロジェクト計画書には記載しません。
あくまで、今後の進行において、こういうものを各フェーズで確定していきますよ、というものです。
「要件定義フェーズ」で定義するもの
- コンテンツマップ
- 利用サービス
- サーバ環境
- 必須機能、バックエンド連携想定箇所
- コンテンツ有無
- 納品物
「企画・設計フェーズ」で定義するもの
- 機能設計
- 画面設計
- コンテンツ設計
- 導線設計
- UI設計
- アクセスログ分析設計
- データベース設計
「デザインフェーズ」で定義するもの
- 主要ページの意匠
- ページを構成するパーツの定義
「開発フェーズ」で定義するもの
- テスト計画書・報告
「導入・移行フェーズ」で定義するもの
- コンテンツ移行計画
4. プロジェクト期間
各フェーズにどの程度の期間を要するのかを定義をしておきます。
4月〜5月：要件定義フェーズ
6月：企画・設計フェーズ
7月：デザインフェーズ
8月〜9月：開発フェーズ
10月：導入・移行フェーズ
という粒度のものです。
ここで押さえておきたいのは、「理想的には」各フェーズの期間を重複させないことです。
要件定義フェーズが完了したら、企画・設計フェーズ、企画・設計フェーズが完了したら、デザインフェーズ
デザインフェーズが完了したら、開発フェーズ、というように、区切りを明確にすべきです。
ここで「次のフェーズに入ったら、前のフェーズには基本戻れませんよ。」ということを認識してもらいます。
より具体的にできるようであれば、WBS（作業工程表）という形で作業を分解したもので定義をしておきます。
※WBSについてはまた別の機会に紹介します。
5. コミュニケーション計画
どのように制作会社とクライアント企業がコミュニケーションをとるのかを定義します。
メーリングリスト、電話、プロジェクト管理ツールなど、手段のお話もあれば、
定例ミーティングの頻度や承認フローといったことも入ってくると思います。
定例ミーティングにおいては、特にプロジェクト初期段階では、すり合わせ事項が多いので、週1回くらいで行うことになると思います。プロジェクト計画時には、仮に要件定義フェーズが１ヶ月と想定したとすると、定例ミーティングが4回できたとして、その4回をどう進めるのか、このプロジェクト計画時に提示しておいた方が良いと思います。
6. サイト基本仕様書・対応想定外項目
ここは、プロジェクト計画というよりは、若干要件定義フェーズで固めるべきことに近いのですが、制作会社側での基本的な対応方針が既にあるものは、この時点で提示しておいた方が良いです。
例えば、対象ブラウザ、印刷対応、アクセシビリティ対応、レスポンシブデザイン対応などがそれにあたります。
対応する想定がないものも明確であれば、お伝えしておくことをお勧めします。
例えば、既存サイトのデータバックアップや、DNSの切り替え作業、外部サービスとの契約代行などがあるでしょうか。
もちろん、その後の会話の中で、変わってくることもあるので、必要に応じ要件定義フェーズでアップデートします。
7. 体制と役割
クライアント側、制作会社それぞれの窓口になる人が誰か、役割は何か、ということを明確にします。
プロジェクト開始時点では、デザイナーやエンジニアなどは未アサインだと思うので、そこは空欄で問題ないです。
責任者を明確にすることで、コミュニケーションロスや、対応のお見合いを防ぎます。
プロジェクト計画書が必要なタイミング
プロジェクト計画書は、一度提示して終わりではありません。
キックオフミーティングで提示して、会議のアジェンダにするだけでは不十分です。
以下の3つのタイミングで必要になると考えます。
- キックオフミーティング時
- 各進行のフェーズスタート時
- 納品後
1. キックオフミーティング時
上記でお伝えした通り、今後のプロジェクト進行を関係者全員ですりあわせるために必要です。
2. 各進行フェーズのスタート時
要件定義フェーズ、企画・設計フェーズ、デザインフェーズ、開発フェーズ、導入・移行フェーズそれぞれで、何を成果物として提示するのか、それらをどういうポイントで見て欲しいのか、その成果物はどう承認されるのか、そういうことを振り返るために使います。
3. 納品後
アクセスログ分析設計で定義したKPIを元に、プロジェクト計画書に記載してある「プロジェクトゴール」を達成できたのかどうかを振り返りに使います。
まとめ
プロジェクト計画のお話、いかがだったでしょうか。
プロジェクト計画時には、具体的なことは何も決まっていない前提で、今後どのようにプロジェクトを進めるのかの共通認識を持てることが重要です。
例えばコンペなどを踏まえて、プロジェクトスタートすることもあるので、そういう時などは特にプロジェクト計画が疎かになって、いきなり制作物の中身の話に入ってしまいがちです。
ただ、プロジェクトをどう進めるかを押さえておかないと、要件定義をすっ飛ばされ、このプロジェクトで対応することしないことの境界線が曖昧なまま、クライアントの要望事項にコスト度外視で全部対応せざるを得なくなった、というようなことになりかねません。自らを守るためのプロジェクト計画でもありますが、クライアント企業側にとっても、五里霧中のままプロジェクトが進むのは大きなストレスだと思います。双方がプロジェクト全体がどう進むのかを理解できる状態はとても重要だと考えます。
