RFP の書き方の説明です。
第二回は、はじめに(用語集や関連資料など)、目的と背景、対応概要、スコープの説明です。
1.はじめに(用語集や関連資料など)
用語集は別紙にすることもありますが、数が少ない場合には、RFP の冒頭に記載します。
会社の略称や業界用語、社内用語、関係する既存システムのシステム名など、RFP に登場する名称を記載します。
関連資料には、RFP で参照している別紙を記載します。例えば要求定義書や非機能要求定義書を別紙にしている場合には、それらを記載します。
またシステム開発をする上での社内ルールがある場合には、それらの資料も関連資料として記載します。セキュリティールールやサーバー等の命名ルール、自社のフレームワークがある場合には、フレームワークの利用ガイドなども対象となります。
これらのシステム開発をする上で守らなければいけない社内ルールは、ベンダーが見積もりをする上で重要なため、記載が漏れると後になって揉める原因にもなります。
2.目的と背景
目的や背景も RFP には必須ですが、どこまで何を書くかはとても難しいです。
ベンダーはシステム開発のプロであって、コンサルタントではありません。発注者が要求したことを実現はしてくれますが、それ以上の期待はしない方が良いのです。
例えば「ビジネスの変化が激しいので、その変化に柔軟に対応できるシステムにすることが目的」のような記載をしても、あまり意味がありません。
また、例えばコストカット目的で他社や社員に影響が出るようなプロジェクトの場合には、それら本当の目的を書くこともできません。
大部分のプロジェクトは経営戦略から降りてきているものですが、それを書いてもあまり意味はありません。ベンダーは自社の業界動向や業界内での自社の立ち位置など詳しくないからです。
ではどういう内容を書いた方がいいのかというと、経験上、業務的な視点ではなくシステム的な視点で書いた方が、後々、役に立つことが多いです。
例えばメーカーから小売までの物流を管理する SCM のシステムを小売の会社で構築する場合、「サプライチェーンの効率化を図り、物流コストを削減する」というような書き方よりも「メーカーや物流業者に幅広く利用してもらえるシステムとすることで、業界内のデファクトスダンダードを目指す」のような書き方の方が、後々、役に立ちます。
「物流コストの削減」のような目的にすると、プロジェクトメンバーは自分ごと化することが難しいのですが、「業界内のデファクトスタンダード」のような目的にすると、主要なメーカーや物流業者にも意識がいき、後々になって大手メーカーが利用するには機能が足りない、といった悲しい事態を避けることができるようになります。
またプロジェクトによっては目的とは別に目標を記載する場合もあります。
ただ目標を明確にすると、良くも悪くもプロジェクトの成否が分かってしまうので、大部分のプロジェクトでは、そこは曖昧にすることが多いのかなと思います。
3.対応概要
実現したいことは機能要求や非機能要求に詳しく記載するので、ここではそれらの全体感を掴めるようなサマリー情報を記載します。1ページで収まればベストですし、多くても2、3ページで収まるくらいの内容にします。
業務フローの新旧を記載する場合もあります。
4.スコープ
スタンドアローンのシステムでない限り、通常はベンダーが対応する範囲と、それ以外の部分(既存システムの改修やインフラ)で責任分界点が存在します。
責任分界点の詳細は役割分担の星取表に記載しますが、ここでは全体感を掴めるようなサマリー情報を記載します。新しく機器を導入する場合、ベンダーに委託するのか自社で調達するのかも明確にする重要なポイントです。
また手作業で行っている業務をシステム化する場合、どこまでをシステム化して、手作業が残る部分がどこなのかも明確にする必要があります。
これらは1ページで収まればベストですし、多くても2、3ページで収まるくらいの内容にします。
将来的な対応と今回の対応とで区別が必要な場合には、それについても記載します。
予算についても公開して良い場合には記載します。通常は公開しない場合でも、ベンダーには予算感を伝えるものなので、個人的には RFP に明記すべきと考えています。
余談ですが、政府調達の場合には予算をベンダーに伝えることは厳禁ですが(バレたら首が飛ぶ・・・)、実際にはオフレコで伝えている場合が多いです。
【振り返り】
今回は RFP に記載する目的や背景等の説明でした。次回はスケジュールや体制等の説明です。
①はじめに(用語集や関連資料など)、目的と背景、対応概要、スコープ
②スケジュール、体制、役割分担、作業環境
③工程定義、成果物
④前提条件、制約条件、リスク、課題
⑤機能要求、非機能要求
⑥提案方法、評価方法