Skip to content

プロジェクト計画

ma-san
ma-san(鈴木正行)

プロジェクトの全体像を説明。課題と目的、ゴールも簡潔に。プロジェクト名もわかりやすくする。期間とローンチの内容も簡潔に明記すること。

プロジェクト計画とは#

プロジェクト計画書とは、プロジェクトを進めていく上で一番最初にクライアントへ提示する資料であり、プロジェクトを計画し、推進していく上でお互いに合意を取るために必要なものです。

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

プロジェクトの目的#

「〇〇」に「〇〇〇〇」を 〇〇することができる〇〇〇〇の実現

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

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

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

課題と対策#

課題、解決策、結果いずれにもユーザーと企業の視点が必要です。

課題

ユーザー側

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

企業側

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

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

解決策

ユーザー側

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

企業側

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

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

結果

ユーザー側

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

企業側

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

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

スコープ#

戦略フェーズ

ヒアリング・RFP確認/オリエンテーション/工数設計/WBS作成/コミュニケーション管理/定例会管理/契約/受注管理/ユーザーテスト/ユーザーシナリオ/ペルソナ作成/CJM作成/KGI・KPI/ロードマップ

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

設計フェーズ

シナリオ制作・WF制作/要件定義/タスク管理/システム設計/構築設計/運用設計/画面設計/課題管理/質問管理/リスク管理/環境/サーバー管理

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

開発・検証フェーズ

システム開発管理/デザイン開発管理/フロント開発管理/開発管理/テスト計画/品質管理/途中経過報告/校正・調整管理/納品成果物/公開対応

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

納品成果物#

プロジェクト計画

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

開発要件定義

実装、表示要件

デザイン

psd、ai、xd、PDFなどの資料

ソースコード

html/css/jsなど

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

スケジュール#

要件定義

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

開発

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

テスト・検証

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

公開・納品

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

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

プロジェクト体制図#

お客さま
プロジェクトオーナー:まるまる様
プロジェクトリーダー:ほげほげ様
プロジェクトメンバー:あわあわ様

弊社
プロジェクトマネージャー:たろう
ディレクター:はなこ
デザイナー:ゆうた
エンジニア:ゆみこ

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

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

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

会議体について#

いつ、どこで、どのような会議をするのか明記する

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

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

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

メールによるコミュニケーションについて
メーリングリストを作成いたしますので、ご連絡の際には、下記アドレスまでお願いいたします。
メーリングリスト:soreppoi_project@?????.co.jp
弊社登録メンバー:○○ ○○、○○ ○○、○○○ ○、○○○ ○○
・本プロジェクトに関するメールタイトルの先頭に、【○○プロジェクト】と付けさせていただきます。

ファイルのやりとりについて
ファイルのやり取りは○○○○を使用を想定しております。
また○○○○で管理をすることでチーム内でのコミュニケーションを円滑にし、進捗確認・ファイルの確認を行います。
※クラウドベースのプロジェクト管理ツールとなりますので、貴社セキュリティ規定のご確認をお願いたします。
https://???.???????.jp/

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

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

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

プロジェクト計画書の要と言っても良いくらい重要な「前提条件」となります。

プロジェクト全体につきまして

  • スコープの増加や要件の変更があった場合につきましては、追加で費用が発生いたします。
  • 納品時期は○○○○年○月○日を予定しておりますが、大幅な変更が発生した場合は、別途費用が発生する可能性がございます。また、スケジュール調整についてもご相談させていただきます。
  • 要件/デザイン/システムにつきまして、最終確認者が体制図以外にいらっしゃる場合、該当のフェーズを確定する会議へのご参加をお願いいたします。
  • プロジェクト関係者以外へのトレーニングにつきましては、スコープ外とさせていただきます。
  • 御社体制の変更があった場合、速やかにご連絡ください。これに伴うプロジェクト変更などが発生した場合は別途費用が発生する可能性がございます。
  • 弊社体制維持についてはプロジェクト期間中のみとし、プロジェクト期間外については体制維持の保証は致しません。

プロジェクト対応外の事柄

  • プロジェクト計画書に記述されているスコープ外の対応は致しません。
  • 納品成果物はプロジェクト計画書に記述されているもののみとし、その他の提供は致しません。
  • 個人情報の取扱は一切行いません。

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

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

お仕事・当サイトへ興味を持っていただいた方

お問い合わせはこちらから

お問い合わせを頂く際はご確認ください

プライバシーポリシー

るり
未来へ繋がるWebの可能性。
お客様のサービスを、Webサイト制作を通じてサポートいたします。
Accessible Web Design.

Recommendation

るり

Webアクセシビリティの重要性について 当サイトが最も注力したい「Webアクセシビリティ」について、ぜひ多様な方々と共に学びながら充実化させ、普及活動に勤しみたいと考えています。

るり

初めて依頼を検討している方 初めてWebサイト制作を依頼する方へ。Webサイトを作りたいと思ったときに参考にしていただけると幸いです。

るり

Webサイトの基本 サーバーの準備からドメイン契約。Webサイトに必要なデータや情報を一通り纏めることで初めてWebサイト制作に携わる方々の学習の一助になれば幸いです。