RFP の書き方の説明です。
第三回は、スケジュール、体制、役割分担、作業環境の説明です。
１．スケジュール
マスタースケジュールで重要なことは一覧性です。
１ページで収めることと、情報を入れすぎないこと。
・RFP発出からキックオフ
・キックオフから要件定義終了
・基本設計開始から基本設計終了
・環境構築
・詳細設計開始から総合テスト終了
・移行リハーサル
・受入テスト
・教育
・本番
こんな感じのスケジュールが分かれば十分です。
これよりも細かいスケジュールを載せる必要があるのであれば、全体のマスタースケジュールの他に、詳細版を用意するのが良いです。
とにかく全体のマスタースケジュールは見やすさが重要です。たくさん情報を載せても、相手が理解できなければ意味がなく、ただの自己満足の資料になってしまいます。
他に通常のプロジェクトではやらないようなタスクがある場合には、そのタスクのスケジュールも記載します。例えば機器の調達がある場合には、発注から納品のスケジュールを記載したり、既存システムの再構築の場合には、既存システムの資産凍結期間を記載したりします。
２．体制
ベンダーにステークホルダーを理解してもらうために、プロジェクトメンバー以外の関係者も記載します。
プロジェクトメンバーは誰で、PMやPLは誰で、アプリの担当やインフラの担当、ユーザー部門の窓口は誰なのかを明確にします。
またそのプロジェクトメンバーの上位職や既存システムが関係するのであれば、既存システムの担当者なども記載し、ステコミメンバーも記載します。
そして、その体制図のどこにベンダーが配置されるのかも重要です。
３．役割分担
役割分担で重要なことは、スケジュールや体制の粒度と整合を取ることです。
例えば環境構築のスケジュールが１本の線で、環境構築の役割分担がベンダーと発注者で分かれる場合、スケジュールも役割分担の単位で分ける必要があります。
また役割分担に出てくる担当が、体制図に記載されていることも重要です。
上記の例だと「統合基盤担当」が体制図のどこにも出てこないので、プロジェクトメンバーなのか、ステークホルダーなのか分かりません。
そこで上記のように追加することで、統合基盤担当は、プロジェクトのインフラリーダーがコントロールする相手だと分かります。
４．作業環境
作業環境では、ベンダーがどこで作業をすれば良いのかを記載します。
発注者のオフィスで作業するのか、ベンダーの自社オフィスで作業できるのか。
工程によっても変わるかもしれません。
また作業場所だけでなく、利用するPC等も発注者が用意するのかベンダーが用意するのかも明記します。
このプロジェクトの仕事を行う上で、必要な作業場所、PC、備品等の扱いを明記します。
また作業場所がベンダーの自社オフィスの場合、発注者のサーバー環境にどのようにアクセスするのかも明確にします。VPNで接続する場合、その費用はどちらが持つのか等も見積りに影響のある内容です。
通常は、製造・単体テストはベンダーの自社オフィスで作業をしますが、その際の開発環境はベンダーが自前で用意し、見積りには含めないことが多いですが、特殊なソフトウェア等を利用する場合には、見積りに含める場合があります。ベンダーが持っていないような特殊なソフトウェアを利用する場合には注意が必要です。
【振り返り】
今回は RFP に記載するスケジュールや体制等の説明でした。次回は工程定義と成果物の説明です。
①はじめに（用語集や関連資料など）、目的と背景、対応概要、スコープ
②スケジュール、体制、役割分担、作業環境
③工程定義、成果物
④前提条件、制約条件、リスク、課題
⑤機能要求、非機能要求
⑥提案方法、評価方法
