RFPを実際に記載する際に抑えるポイントや注意点
以前の記事でRFPの意味とRFP作成の必要性(メリット)を記載しました。
この記事では、RFPを実際に記載する際に抑えるポイントや注意点を記載していきます
- RFPを記載する際に抑えるべきポイント
- システム化を行うに至った背景
- 依頼するスコープ(範囲)
- 連携するシステムなどがあれば、それらの情報もまとめて提示
- 重要視していること、妥協できる事
- まとめ
RFPを記載する際に抑えるべきポイント
以前の記事(RFPとは?システム開発を開発会社に依頼する際に準備すべきこと)では要点として以下のように記載しました。
・システム化を行うに至った背景(なぜシステム化を行うのか?)
・依頼するスコープ(範囲) (システム化を行う範囲。プロジェクトを進めるにあたっての依頼したい役割)
・連携するシステムなどがあれば、それらの情報もまとめて提示(他のシステムとの連携があるとないとでは見積もりも難易度も違います)
・重要視していること、妥協できる事
ここではそれぞれについてより詳しく必要性やポイントを記載していきます。
システム化を行うに至った背景(なぜシステム化を行うのか?)
よく見るRFP(というよりは開発の見積もり依頼)では、欲しい機能について書かれている事が多いです。
機能を示してもらえるのは、見積もりを検討する開発会社からしたら非常にありがたいのですが、機能とは課題を解決するための「手段」であり「目的」ではありません。
目的を正しく理解しない状況で手段である機能を開発しても、機能は実現したが結局課題は解決しないなんてこともあり、その場合プロジェクトは意味がなかったということになり、失敗してしまいます。
そうならないために、RFPを作成する場合には、まず「なぜシステム化を検討するに至ったのか」を説明して頂くことをお勧めします。
そのうえで、RFP作成側として考えた機能一覧(課題の解決策)があるのであれば、それも合わせて記載して頂くと、見積もりや提案を検討する開発会社は理解しやすく、見積もりの比較もしやすくなります。
また、稀にあるのが「課題の開発方法はシステム開発ではなく、SaaSやパッケージ製品の導入」であるというケースです。
これは、「システム化を行うに至った背景」がきちんを書かれれば良いのですが、「SaaSやパッケージ製品の導入ではなくシステム開発を選択する」のであれば、それも合わせて説明して頂けると良いかと思います。
例を挙げると以下のような感じです。
「2年前に〇〇という課題を解決するために△△というパッケージを利用したが、××の問題が発生し、このパッケージでは■■のため解決が困難という判断に至った。そのため、今回は新たに自前のシステムを開発する事とした。」
依頼するスコープ(範囲) (システム化を行う範囲。プロジェクトを進めるにあたっての依頼したい役割)
こう書くと「システム開発を依頼したいんだ」とこれを読まれている方は思うと思います。
しかし、システム開発にはいくつものプロセスがあり、現状がどうなのか、またどの工程を依頼したいのかにより費用は大きく変わります。
多くの場合、こういった情報が明示されないシステム開発プロジェクトの場合、開発会社からの見積もりは高くなる可能性が高いです。
記載する場合か以下のような情報を記載するのが良いです。
・プロジェクトの責任者
これを依頼者側が立てられるかどうか。
システム開発の責任者は、システム開発会社からプロジェクトマネージャーが選出されることと思いますが、システム会社からの提案や確認に対して承認やフィードバックしたりするのは通常依頼者側です。
その結果責任を持つのがプロジェクト責任者であり、これをシステム開発会社に負わせるのは通常あり得ませんが、プロジェクト責任者を立てられないような依頼者の場合、質問しても回答が返ってこなかったり曖昧だったりで、プロジェクトがなかなか進まないということが予想されます。
こういったことが出来る要員を依頼者側で準備できるかできないかで、開発会社から出てくる見積もりの金額が変わってきたり、もしくは提案してもらえる数に影響が出るかもしれません。
・関わって欲しい工程や役割
どこからどこまで、どのように関わって欲しいかです。
簡単に書くなら「要件定義」「設計」「開発およびテスト」「リリース」や「受入テスト支援」など。
リリースしてからの事を考えるなら「保守」「運用」なども必要です。
上記に明示的に入れていないものとしては、「インフラ設計・構築」や「初期データ作成」「データ移行」などもあります。
プロジェクトによっては必要のないものもあるかもしれませんが、何も記載がない場合は全て必要という前提で開発会社側は見積もることになります。
仮に全部依頼したいとしても、こういった情報を記載してあることで、開発会社からすると「この依頼者はある程度は分かっているんだな」と思い、何も記載がないよりは身構えなくなるかと思います。(お見積りの金額が抑えられる可能性が上がったり、提案数が増えることが若干ですが期待できます。)
連携するシステムなどがあれば、それらの情報もまとめて提示(他のシステムとの連携があるとないとでは見積もりも難易度も違います)
これは見出しの通りですが、特に連携する対象のシステムが、独自開発しているような基幹システムなどであったりすると、工数が大きく増える要因になります。
こういった情報を提案段階で記載しないと見積もりが抑えられたり提案が増えたりするかもしれませんが、いざプロジェクトが開始したら話が違ったと開発会社と揉め、プロジェクトがとん挫するリスクもあります。
ですので、重要な情報ですので決まっていたらRFPに記載しておいた方が良いです。
重要視していること、妥協できる事
これも記載の通りですが、以下に項目についてどれが優先事項でどれが優先でないかを明確にすると、提案が受けやすくなったり、プロジェクト進行中のハンドリングもしやすくなります。
・品質
・予算
・スケジュール
上記をQCD(Q=Quality、C=Cost、D=Deliverly)ともいいまですが、全てが高い基準でまとまっているということは、通常ありません。(品質が高く、見積もりが安く、納期が短い、という意味)
あるとしたら、要件に合致したパッケージがあったり、過去開発したものを使いまわせるなどといった場合だけでしょう。
もちろんそういうこともあるとは思うので、全てを優先するという判断も提案時には良いかもしれませんが、システム開発は不確実性やトラブルとの戦いでもあるので、そういった際にどういった判断をするかという意味で、優先すべきことや優先しない事を明確にしておくメリットはあると言えます。
全ての人にビジネスクラスやファーストクラスは必要ないでしょうし、車でも3ナンバーのワンボックスが欲しい人もいれば軽自動車で良い人もいます。いずれも目的地に着くという目的や、人を乗せて走るということは達成できます。しかし、金額にはかなりの違いがあるのは説明するまでもないと思います。
まとめ
この記事ではRFPを記載する際に抑えておくポイントをまとめて説明しました。
繰り返しになりますが、RFPを作成するには時間や多少の専門知識も必要ですが、それをやるだけのメリットもあります。
リケスタではRFP作成のためのアドバイスなどもサービスを行っていますので、アカウント登録のうえご相談頂ければと思います。
■RFPに関する記事