Web制作におけるプロジェクト計画書の全体スケジュールについて

この記事は「Web制作におけるプロジェクト計画書の納品成果物について」の続きとなります。

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

できること、できないことを判断した上でスケジュールを立てましょう。

全体のスケジュール

全体のスケジュールの例

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



■要件

20○○年○○月○○日~20○○年○○月○○日
要件定義書、ワイヤーフレームの作成を行う。

■開発

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

■テスト

20○○年○○月○○日~20○○年○○月○○日
開発環境からステージング環境に移行。ステージング環境にて総合テストを行う。

■公開・納品

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

こちらで書いてあることも至ってシンプルですね。それぞれのフェーズに対して期間とやることを簡単に記述しています。もちろん、これを深掘りしたWBSの作成なども必要ですが、初期に提出するプロジェクト計画書としてはこのレベル感で共有することも多いです。

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

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

あわせて読みたい