プロジェクト計画

この資料の有無でプロジェクトが予定通りに進むのか、はたまたその時々で変更が発生するたびにプロジェクトの変更に時間が取られ、費用とスケジュールが切迫されていくのかなど、大きな差が出ていきます。
僕自身はこのプロジェクト計画書の合意によって、クライアントとより良いプロジェクトを作り上げていくのではないかと考えています。

プロジェクトの目的は「このプロジェクトを実行したことでなにが実現するのだろう」という一文を記入するようにしています。

ユーザー・企業になにをもたらすか

ユーザー側にはどのようなことが実現するのか、クライアント側にはどのようなことが実現するのかも記述します。文章は抽象的で構いませんが、該当する人々が感情移入できるような目指すべき内容にしてください。
この項で重要なことは「あるべき未来の共有」です。

課題

ユーザー側

・〇〇ができない
・〇〇という印象を持っているため〇〇だけという〇〇がある

企業側

・〇〇のコストが発生している

できないこと、どのような問題が発生しているのかを記述します。但し、細かく書くにはプロジェクト計画書を書くタイミングでは調査が薄いため、クライアントから提示されたRFPや与件を確認しつつの記述となります。クライアントからこれらの提示がない場合は仮定を立てて記述するため、より大きな範囲で記述してあげるほうが軌道修正がしやすいです。

解決策

ユーザー側

・〇〇ができる〇〇の実装
・〇〇が気軽に〇〇できる
・〇〇で〇〇する前提の〇〇を提供

企業側

・〇〇というオペレーションが〇〇となる

課題を解決するためにはなにを作るのか、なにを用意するのか、そのためにはなにができるようにするべきなのかを記述します。

結果

ユーザー側

〇〇が可能となり、〇〇の〇〇時間が減る。〇〇により〇〇を〇〇する方が増加。

企業側

〇〇のオペレーションが〇〇することで〇〇のコストが減少。

結果はわかりやすく纏めて書いてあげたほうが良いでしょう。ここでやりがちなのはまたしても具体的な数値の記述になりますが、その数値を出す場合は大体が短期的な、目先の収益に特化したものになりやすいため、プロジェクト行った結果、中長期で実現していく未来を描くのであれば理想論と言われようと「目的を達成した未来の道筋」をイメージして記述しましょう。

プロジェクトをスタートする場合にはこの戦略フェーズから開始することが多い、というか基本となるでしょう。具体的な指標などはこちらで設定をしていく、調査などを行った上でKGIやKPIの設定が必要です。プロジェクト計画書はこれらを端的に、且つ分かりやすい方向性を示すためのものですが、戦略フェーズがある程度佳境に差し掛かったら一つの資料としてプロジェクト計画書にまとめ上げるということもあります。

設計、というとUIを思い浮かべるかもしれませんがどのようなシナリオでプロジェクトの目的実現に向けて進むことができるのか、要件定義はどうするか、システムは、構築はどう進めるか、構築した後の運用はどのようにするか、それらを実現するための課題はどのように管理するのか定義します。

クライアントにも分かりやすい形になっていくためお互いに手を抜けません。楽しくもあり、辛くもあるフェーズなのでここでもスコープはしっかり定義しておきましょう。ここまでしっかり定義しておけば後でなにかを言われたとしても大丈夫となる場合が多いです。

デザインデータ、ソースコード自体は納品確認書かサイトマップを作成して具体的なファイル名やディレクトリパス、どこでデータが使われているかなどの紐づけも必要になる場合もあります。

それぞれのフェーズに対して期間とやることを簡単に記述しています。もちろん、これを深掘りしたWBSの作成なども必要ですが、初期に提出するプロジェクト計画書としてはこのレベル感で共有することも多いです。
WBSのように事細かなスケジュールをプロジェクト計画の初期段階から提示した場合、スケジュールの調整を延々とする、ということが発生する場合もありますが、プロジェクト規模が（数ヶ月で終わるような）小さい案件の場合は最初からWBSを作って提出するのもありでしょう。

クライアント、制作側でどのような人物がいて、ということがイメージできない状態ですとそのワークフローまで影響が出てきます。

重要なのはお客様で誰が決済権限を持っているのかを明確にしておくことが重要です。決済権限を持たない担当者とプロジェクトを進めていて、いざ担当者の上司に話したらプロジェクトがひっくり返る、ということがよくあります。なので、必ず決裁権限を持つ人物を特定し、明記しておきましょう。

双方の連絡窓口を明記しておくことも重要です。プロジェクトに関わる人物も多くいる場合は誰がどこを担当するか、なども明記しておきます。

フェーズ終了ごとに進捗報告の会議を行うのかを決めておく必要があります。この設定がない場合、お客さまの貴重な時間を随時段取りしていただく必要ができるため、事前に確認をしておくことが重要です。

お客さまによってはとにかく会議をたくさんしたい、という方もいますが会議がメインになってしまうと、実働稼働の調整が大変になる可能性があるため、重要な会議以外は「※必要に応じて分科会を開催いたしますが、運用やツールに関するトレーニングや、御社システム開発部様によるレクチャーはスコープ外とさせていただきます。」など、必要に応じるけど設定外の会議についてはスコープ外とする、というのは重要です。

メールでのコミュニケーションを行う場合はこのようにメーリングリストを用意する、どのような登録メンバーがいるか、件名には必ず決まった言葉を入れるなどのルールが必要です。

ファイルのやりとりについても明記しておきましょう。
可能であればファイルの共有が可能なクラウドベースのプロジェクト管理ツールなどでやり取りができるのが楽です。その場合はクライアント側のセキュリティ規定などの確認も必要なので、必ず同意を取るようにしましょう。

過剰に書いているように見えるかもしれませんが「スコープ外はお金が発生しますよ、リスケが発生した場合も調整が入りますよ」などを明記しておく必要があります。

プロジェクト計画は制作サイドも、発注サイドも双方にとって重要な指標となる重要な役割を果たします。
お互いの合意を取り、双方ともに真摯に向き合ってプロジェクトを推進できる関係性を構築するためにも必要なツールとしてプロジェクト計画をしっかり行いましょう。