目次
博報堂アイ・スタジオが対応するプロジェクトでは、PMO（Project Management Office）がバックアップ体制に含まれることで、RFPの読み解きやプロジェクト開始時の体幹の整えも実現します。
ここでは、なぜ ”初動” に注力しているのかも踏まえて、プロジェクト（案件）の序盤で意識しておいた方がよいこと、やっておいた方がよいことを詳しく説明します。
なぜ “初動” に注力するのか？
例えば、買物を頼まれてスーパーへ出かけた以下のケースを想像してみてください。
あらかじめ目的地やミッションが明確で、地図があれば最適ルートの検討や迂回路の想定もでき実行がスムーズになります。 しかしながら.....
→レジに並んでいると「牛乳もお願い！」と連絡くる
→帰っている途中に「鶏肉もお願い！」と連絡がくる
→帰宅後「他のスーパーの品が良かったのに」と言われる
→帰宅後「他のスーパーの品が良かったのに」と言われる
こうなるともう、「先に言ってくれ！」「家を出る前に確認しておけばよかった」となりますよね。 帰宅時間に間に合わない、手持ちのお金が足りなくなる、ということもありえます。このように “初動” での情報吸い上げと認識合わせ、方針決めが大事になるわけです。
プロジェクト（案件）における “初動” には、２つタイミングがあり、１つめは「オリエンから提案」時、２つめは、「受注後（プロジェクト開始）から要件定義」時です。
提案の要は “RFP”
相談やオリエンでざっくりと概要説明は受けたものの、提案に向けて「何を考慮すれば...」と感じることもあると思います。 背景・目的・要望を理解してアイデアを提示するという提案時から、クライアントとの要件握りはスタートしています。ここで重要なことは、まずRFPをしっかり読み解くことです。
情報源の核はRFP！ 
相談・オリエン段階での情報源はいろいろありますが、大まかには図のようなイメージです。中でも核となるのはRFPです。 まずは案件内容や依頼事項が纏められた（情報の大本となる） RFPから、 提案の検討材料を洗い出し整理する必要があります。
また、RFPに紐づく補足資料や個別に入手した情報、公開情報（サイトなど）などから 補完した上で、提案する上で足りていない不明点は、 オリエン後のQ＆Aにて確認する流れになると思いますが、ここで注意しなければならないのは、 RFPにすべてが記載され正しく表現されているわけではないということです。
一部の要件や表面的なことのみ記されている、 クライアント内部で方針決めや検討が充分になされていない （相談が含まれている）といった場合があります。 提案する範囲や考慮点として足りていないこと、 要望を上手く表現できていないこともあるため、それを見極めた上でクライアントから付加情報を吸い上げる必要があります。
意識するポイント
RFPから情報を拾う上で意識するポイントとしては、対応案を検討する上で足りていない情報や・目的や理由が不明確な部分が無いかということですが、例えば以下が挙げられます。- QCDに関わる情報（Quality：品質、Cost：コスト、Delivery：納期/期限）
- 目的、対応範囲（提案範囲、プロジェクト範囲）、前提条件
- 記載要件を仕分け分類する（例：デザイン要件、機能要件、システム要件など）
- 記載要件の温度感を分類する（必須要件なのか、要望なのか、提案を求めているものなのか）
- 技術面・体制面でフィージビリティ確認が必要な部分はないか
- 記載情報から案件受注後のプロジェクト体制やスケジュール、推進方法をイメージできるか
- 表現の意図や想いが汲み取れない部分はないか
放置されがち、見落としがちな点
提案する際は、制作物のコンセプト・デザインなど視覚的に訴えられるもの、華やかで目立つ部分に意識が偏りがちですが、次のような記載（記載していない場合）にも注視が必要です。・情報セキュリティやサイバーセキュリティに関する要件
・インフラ環境や運用・保守まわりの要件
・リニューアルの場合、現行環境や現行運用体制の状況
・法に関わる考慮点有無
・インフラ環境や運用・保守まわりの要件
・リニューアルの場合、現行環境や現行運用体制の状況
・法に関わる考慮点有無
また、オリエン後のQ＆Aにて他社からの質問に対する回答も漏れなく拾っておくことや、提案資料作成時にRFPや個別に入手した要件が考慮され盛り込まれているかをチェックすることも大切です。
プロジェクトの “体幹” を整える
晴れて案件を受注し、いよいよキックオフを迎えプロジェクトをスタートした際、 いきなり 制作物の構想・デザイン、設計の話を始めてしまったことはないでしょうか？でもちょっと待ってください。
これでは全容・ルール・戦法が曖昧 且つ準備なしでゲームを開始しているようなものです。
これでは全容・ルール・戦法が曖昧 且つ準備なしでゲームを開始しているようなものです。
計画と共通認識がない状態でとりあえず手を付けてゆくと、プロジェクトはカオスまっしぐらです。 また、調査実施や構想・デザインの議論に時間をかけたことで、気づいたら実装やテストの期間を充分に確保できず、 品質が担保できなかった、ローンチが延期となったという経験もあるかもしれません。
まずは、QCD（Quality：品質、Cost：コスト、Delivery：納期/期限）を常に意識することは大前提のもと、 プロジェクト序盤では次のような初動が大事になります。
4つのステップ別に準備や意識ポイントをあげてみました。
4つのステップ別に準備や意識ポイントをあげてみました。
１．キックオフ（プロジェクト立ち上げ）
キックオフ時に最低限として共通認識合わせをしておいたほうがよいこととしては、案件概要の他、まずはプロジェクトを進行する上で欠かせない登場人物把握とコミュニケーション方法です。利用ツールによっては準備手続きが必要となるためタイムロスを回避することが先決です。
ココがPOINT
- 案件概要（全体像）
- 登場人物（プロジェクト体制・関係者）
- 概要スケジュール（全体ロードマップ、直近の進行スケジュール）
- コミュニケーション方法（連絡手段、ファイル共有方法、会議体、課題共有方法など）
２．分掌の明確化
クライアント側、受託側などの 対応（作業）範囲や役割を明確にしておくことで、対応・検討・コスト考慮 の漏れを防ぎます。
ココがPOINT
- 対応することだけでなく、対応しない(対象外)という視点でも明確化する
まとめるドキュメント例：作業範囲記述書（SOW：Statement of Work ）
３．プロジェクト計画
プロジェクトの進め方（方針・ルール）やプロジェクト概要の認識を合わせておくことで、スムーズな進行の基盤を整えます。
ココがPOINT
-
計画時点では決められないものはいつ決めるかを合意する（例：要件定義時、設計時など）
-
調査/ユーザーインタビュー実施の考慮
-
スコープ、条件、体制、スケジュール、工程定義、成果物、コミュニケーション、品質、セキュリティ
-
プロジェクト計画時点で想定されるリスクと対策
まとめるドキュメント例：プロジェクト計画書（Project Plan Document）
４．要件定義
設計や実装 (制作) に突入してからの変更・やり直し・追加は、ローンチ期限やコストに大きな影響を及ぼすことが多いです。 設計・実装を始める前に要件定義のフェーズを設け、しっかりと具体的な要件を握っておく必要があります。
手戻りや「言った」「言わない」を回避するために、このタイミングでクライアントの要望や意図を吸い上げ、 小さなボタンのかけ違いや考慮漏れの芽を摘む必要があります。
ココがPOINT
-
受注時点のインプット情報（上記図）では不明な要件も含め確認する
-
漏れがちな以下の点も意識する
ー 情報セキュリティやサイバーセキュリティに関する要件
ー インフラ環境や運用・保守まわりの要件
ー リニューアルの場合、現行環境や現行運用体制の状況
ー アクセシビリティ要件
ー 品質を担保/証明するためのテスト要件
ー 成果物・納品物対象まとめるドキュメント例：要件定義書（Requirement Definition Document）
これらのステップは地味な作業ではありますが、 最初にプロジェクトの 体幹（軸）をしっかりさせておけば、円滑な進行を維持しつつ、 想定外の変化球にも大きくブレることなく体勢の立て直しをし易くなります。 その先のプロジェクト成功にもつながるはずです。
最近の投稿
