知っ得スキル！もらってうれしいRFP ～最終章～提案受領へ

前回まででRFPの基本とシステム要件の具体的な書き方がわかりましたね。「システム要件書けたら終わりかな？」と思いきや、実はもう少し続きます。RFPは、ベンダーからの提案を受け取るまでがRFPと言っても過言ではありません。RFPの書き方の最終章です。

RFPは提案を受け取ることがミッション

前回までで、RFPの根幹となる予算や開発スケジュール、システム要件について解説してきました。改めてRFPの全体の目次を見直してみましょう。
RFPのシメには、ベンダーが提案検討を進めるための具体的な情報を共有するようにします。

さて今回は、より良い提案を受け取るためのRFPのまとめです。

 

RFPの〆（シメ）は、よりよい提案のための確認事項

RFPの後半部分には、ベンダー側でよりよい検討案を作るために明確にしておくべきことを書きます。

ざっと、これまででシステムの機能的・非機能的な要件が見えてきたところでさらに考慮すべき条件、提案を送る際に必要となる管理情報などです。

９．納入物　～作るべきものは何か

この項目は、最終的に納入する物が何かを定める項目です。
「仕様書」「Webサイトコンテンツ一式」「プログラムを含むサーバー類一式」など、成果物として提出すべき物を定めます。

結局のところ、ここで定める作成物が価格に直結します。

「テスト環境」や「操作マニュアル」など、コンテンツ実体以外に必要な物の漏れがないかしっかり確認しましょう。ここで漏れてしまったために後々予算が足りなくなる、という悲劇が歴史上何度も繰り返されています。
尚、納入物のファイル形式などの形式指定がある場合は書いておきましょう。

１０．体制　～みんなでOne Team

ここでは、システムの開発体制を書きます。
発注側の体制との関係性や「週次の進捗確認を行う」など工程管理の方針、ベンダー側の人員の技術レベルなど求める条件を書きます。

ここは実際ベンダーと相談してから決めたいということもあるかもしれませんが、先にある程度決めておくと、ベンダー側でもそれを意識した体制を組んでくれるので、後々の工程管理がしやすくなります。

１１．既存情報共有　～ギョーカイ用語は控えめに

ベンダーは、発注元の業界や業務情報に精通しているとは限りません。
こうした項目を設けて既存の業務についての情報を共有することで、より具体的にシステム要件を理解してもらうことができます。

通常業務のフローや業務の規模など自社の業務の基本的な情報を書いたり、既存システムを更改する場合や既存システム連携が必要な場合などではその既存システムについての情報提供を行います。
また、顧客向けシステムである場合は自社がターゲットとする顧客層などの情報も書きます。
尚、発注元の業界用語はベンダーに通じない可能性もあります。ベンダー側で業界用語を必死でググることになってしまいますので、あまり多用しないようにしましょう。

１２．提案依頼指示　～宛先はコチラ

ここでは、このRFPに対してどのように提案してほしいかを指定します。

• 提案書に必ず含めてほしい内容
• 提示方法（書類の提出方法や送付期日、宛先など）

を記載します。

必ず含めてほしい内容とは、例えば工程ごとの予算分けだったり課題を解決するためのアイディアの検討だったりと場合によって異なることでしょう。ベンダー側では、自社版の提案書フォーマットを持っていることがほとんどです。各社のフォーマットによっぽどの大きなずれはないものと思われますが、改めて書いておけば各ベンダーからの提案内容を比較しやすくすることができます。

提示方法は、送付の場合の宛先や提出先担当、期日などです。受領の対応を一元化して効率的に行うため、提出方法は必ず明記します。ちなみにこれがないと、おたよりを募集しているのに宛先や締め切りが書いてない状態と同じで、おたよりを送ってもらえる確率が下がってしまいます。

１３．選定スケジュール　～提案受領のその先へ

RFPに対する提案を受け取った後の選定について、その基準や選定にかかるスケジュールなどを決めておきます。
ベンダー側では体制を用意するため計画的に準備を行う必要があります。選定期間がしっかりとスケジュール化されていると、ベンダー側も安心して開発予定を組むことができます。

また、ここに選定基準も書いておくこともよいでしょう。例えば、ベンダーのセキュリティ意識を重視するのであれば「セキュリティ認定（ISO/IEC27001など）を持っているベンダーを優先する」、と記述したりします。
こうした基準が明記してあれば、ベンダー側も発注元がどういった要素を重視しているのかわかり、より良い提案につながるでしょう。

RFP後の選定基準がないと比較作業に苦労するのは発注元なので、全ての基準をRFP上に書かないにしろ、発注元で基準を決めておくのは重要です。社内での説明もしやすくなります。

さてこれで、RFPを送付してベンダーから提案を受け取る準備が整いました。

開発開始への道は一つではない

RFPを作るには、さまざまな事柄を事前に決めておかなければならないということがわかりましたね。こうした、細かく見える項目を事前に検討しておくことで、システムに期待していることや実現される姿が明確になります。より効率的なIT投資ができるということにつながります。

おさらい：RFIとは？

さて、RFPとよく似た言葉で「RFI」があります。

RFIは、「正直、RFPなんて書けないよ」という人にも書ける情報提供依頼書です。

RFI（Request For Information）とは、情報依頼書という意味で、ベンダーが持っている製品・サービスの情報や会社の情報の提供依頼のための文書です。

これは、RFPのように細かく要件を書く必要がなく、逆にベンダーから必要なシステムに関する情報を提供してもらうことができます。

RFIでは、提案をしてくれそうなベンダーに対し、今検討している課題に関する製品名やサービス、価格体系、導入実績といったソリューション情報に加えて会社の基本的な情報と業務内容や売上高といった情報の提供を依頼します。

RFIはRFPとは異なり、詳細な要件を書きません。そのため、ベンダー側も詳細な見積もりや検討は行わず、製品パンフレット一式を送るようなざっくりとした回答となります。

 

要件定義を他社に手伝ってもらうという選択肢も

RFPを自前で作成することだけが全てではありません。
RFPを作成するためにSIerに依頼をして要件定義を手伝ってもらうというケースもあります。
もしくは、RFIを発行して回答を受け取った中からベンダーの候補を絞り込み、そこに開発を依頼したりRFP作成を手伝ってもらったりするというケースもあります。

「RFIだけ作って開発を依頼するならRFP要らないじゃん」と思うかもしれませんが、RFPの内容はシステム要件定義のために必要な内容であり、遅かれ早かれ同じような項目を検討する必要があります。

また、ベンダーとしてもRFP作成のお手伝いをする中で、RFPの中に上手に自分たちが得意な領域を仕込むことも忘れません。そうしておくことでベンダー選定の際には自分たちに有利に働きますので、あながち無駄な作業でもないのです。（官公庁ビジネスでは、原則公募となる為、このような手法を行うことが多いです）

システム開発は、SIer任せ・ベンダー任せだけでは発注元が「本当にやりたいこと」を「効率的に」実現することはできません。自身でRFPを作ることは、発注元としても主体的な要件整理ができ、ベンダーとのよりよいパートナーシップを築くための第一歩となります。

それにはベンダーにきちんと意思を伝えられる書き方をすることが大事なのです。

 

【執筆：編集Gp　星野 美緒】