【知っ得スキル】もらってうれしいRFP ～第1章～
システム発注をするとき、「RFPを書くぞ！」と意気込んだまではいいけれど…、一体どうやって書くんだっけ？
RFPでベンダーと意識を合わせられれば、開発の期間やコストを抑えることにもつながります。今回は、ベンダー側の視点からもらってうれしいRFPの書き方を紹介します。
『RFPにもコツがある！』
■情シス「RFPって、何を書けばいいの？」
2020年、押し寄せるデジタルトランスフォーメーション（DX）の波に、そしてCOVID-19による生産・消費活動の変化にと、企業は既存業務からの転換に迫られています。業務の改善・変更となれば、当たり前に話題に上るのがシステム構築や更新の話です。
こうしたシステムの導入・入れ換えは情シスにとっても一大イベントといえるでしょう。
そして多くの場合、システム開発はベンダーへ発注することになります。そんなとき我らが情シスに、ベンダーへの「提案依頼書＝RFP（Request For Proposal）」を作る機会が訪れます。
RFPから始まるシステム開発
RFPとは、システム構築の予算や概要、開発スケジュールなど「システム開発で実現してほしいこと」の要件をまとめたものです。
システム発注側が作成し、ベンダーに配布します。ベンダーはそれを元にシステムの規模を見積もり、体制を用意し見積もりを作って提案します。その提案を受けて発注側はベンダーを選定し、タッグを組んで開発が始まるのです。
このRFPを使ったベンダー選定は、特定の開発ベンダーを持たない企業にとってはとても効率のよい流れといえます。なぜなら、RFPがないと、ベンダーからの提案内容がバラバラで、出てくる提案をどのように選んでいいかわからなくなりがちだからです。
■ベンダー「システムの要件を書いてよ！」
「でも、要件っていったってシステムを作る側の理屈もあるだろうから、やっぱり打ち合わせしながら決めたほうがいいんじゃない？」
そう思う情シスもいるはずです。確かにそれも一理あるかもしれません。
しかしながら、もしRFPを作らないで発注を行うとすると、打ち合わせやメールなどで要件を伝えることになります。
例えば、
「今回のシステムは、スマートフォンから注文をできるようにするものです」
「6末までのスケジュールは必須かって？ 無理なら仕方ないですが、なるべく速く作ってほしいです」
「商品に“いいね”ボタンを付ける？ それいいですね！」
打ち合わせでは、きっとこのように対話をしながら進めることができるでしょう。
しかしながら、これではその時々の話の流れに要件の内容が左右されてしまうかもしれません。伝え漏れ・聞き逃しが発生して意識が合わせられないということが簡単に起こり得ます。ベンダー側には、どれが必須の要件でどれが単なる感想か判別ができません。
そうして出てきたベンダーからの提案内容はバラバラになってしまうことでしょう。
A社：全商品が一列に並んだシンプルな商品サイト 開発期間：3カ月
B社：主力商品を華麗にアピールするAI搭載サイト、電子マネー決済機能有 期間：6カ月
C社：Amazonに出品するための登録代行サービス 契約次第開始可能
D社：独自SNSサイト 開発期間：3カ月
少し極端な例かもしれませんが、このようなケースは、自社サイトが必要なのかどうか、電子マネー決済機能が必要なのかどうか、その後の運用をどうするのかといった、本当に必要な要件が何なのか開発ベンダーにきちんと伝えられていない状態といえます。
この中からベンダーを選んでも、他のベンダーとはそもそも出している条件が違うため、費用や性能面での比較ができません。これでは最適なベンダーを選んだとはいえないかもしれませんね。
しかも、きちんと要件を伝えられていないと、見積もりに必要な機能が盛り込まれていなかったり余計な機能が紛れこんでしまったりしていることがあります。ゴールまでの道のりを迷走してしまうことにもつながります。
システムにしっかりと必要な機能を盛り込み、さらに価格や性能を横並びで比較するために、RFPに要件を書くのです。
RFPでは、まずは”システムで何をしたいのか”を明確にし、求める機能やスケジュールを社内の計画に沿って具体的に書く必要があります。
ベンダーには「要件定義は神」
RFPでの要件定義は、受け取る側のベンダーから見てもとても重要なものです。
発注側が望んでいることは何なのか、どこまでが必須でどこに力を入れるべきかを見極め、自社の得意分野を効果的にアピールすることができるからです。
また、要件定義はその後の開発工程にも直接影響を及ぼします。要件とは、システムにおいて“必ず守らなければならないもの”です。
実際に受注できたとして、もし開発途中で「これはやっぱりこうだった」などと意識違いからの仕様変更が発生すると、それに合わせるために多大な時間と労力をロスしてしまいます。
RFPを作るメリットは、実際の開発が始まる前にシステム開発のゴールを発注側とベンダーで共有できるので、ゴールまでの道のりを明確にしやすいということです。
ベンダーにとっては、RFPは発注元の意図や計画の代弁者です。そのため、RFPが具体的な内容であると理想的です。しかしながら、何事にも匙加減が必要です。あまりに細かい内容まで決めてしまうとベンダー独自の解決方法について提案を見ることができなくなるので注意が必要です。
■RFPの目次サンプル
では、実際RFPの目次にはどういう項目があるのかを見てみましょう。
あくまでも一例ですが、ウォーターフォールモデル開発におけるRFPの項目は以下の通りです。
- システム概要
システム名、システム開発の背景や何をするためのものかの概要 - 開発目的
システムによって達成したい目標、解決すべき課題 - 開発期間
開発を行う期間、工程の目安、リリース日 - 開発予算
開発予算の上限や工程ごとの目安 - 機能要件
開発システムの機能と操作、性能要件など - 開発範囲
発注する範囲、責任の境界 - 運用要件
サービスレベル、運用条件、保守条件、教育条件など - セキュリティ要件
セキュリティポリシーなど - 納入物
必要な納入物の定義、形式など - 体制
開発体制、求める技術レベル、工程管理方法など - 既存情報共有
既存システムについての情報提供や、業務についての情報共有など - 提案依頼指示
提案書に含めてほしい内容、提示方法など - 選定スケジュール
提案を受け取った後の選定基準やスケジュールなど
システムの形態や開発の前提条件によって多少は異なりますが、概ねこのような項目があるとベンダー側の要件判断がしやすくなります。
次回は、各項目についての詳細な内容を説明します。
【執筆：編集Gp 星野 美緒】
関連記事
