RFP（提案依頼書）の勘所

こんにちは、せぇべぇでございます。

今回は提案依頼書（Request for Proposal）について、もらう側（受け側・読む側）、だす側（発行側・作る側）の両方の経験から読み解くまたは書くポイントを話していこうと思います。

RFPの最終目的は、受けた側が発行した側に提案することになります。
RFPには良い提案をしてもらうために、こんなシステムが欲しいんだということを記述していきます。システム開発に向けての最初の条件（最低限の条件）みたいなものですね。提案して実際に発注となった後には必ず要件定義を行うので、細かい話しはそこで詰めていきますので。

それでは項目ごとにみていきましょう。

概要、背景、目的

どういった理由で・・・や何をしたくて・・・ということを記載します。
目的や背景は様々。
・新しいサービス提供にあたり開発する
・手作業の業務をシステム導入で自動化し業務効率を改善したい
・部門ごとに契約し利用していた業務システムを一元化したい
・現行システムが老朽化したためまたはOSなどのサポート切れでシステム刷新（リプレース）

ここについては基本的な内容なので必ず記載はあります。企業としてよりよく仕事をするための投資でもあるので、経営方針からビジョンといったことも書いてあったりします。それらを受け側が十分に思いを受け止めて提案していくことになるので、これがズレていると提案自体もズレてしまいます。
また対象のシステムが決まっている場合（CRMやERPや他サブシステムなど）は、ピンポイントでの提案となるのでそこまでズレはないかと。

スコープ・範囲、スケジュール

こういった業務範囲を想定しているや（その場合は業務フローも記載があると提案側はイメージができるので良い）、このサービスの一部（請求業務や○○業務）を対象とするということを記載します。また業務をこう変えていきたいということも書いてあると良いです。
あまり経験がない業界だと、このあたり業務のイメージができなく苦しい提案になってしまいます。

ものによっては利用するユーザの範囲を記載している場合もあります。子会社社員、グループ会社社員、派遣嘱託バイト、社員のみ、総務部社員のみなどなど。
優しいRFPだと登場人物の記載がありそれぞれの役割なんかも書いてあると、かなりイメージができるのでいいなぁと思います。

スコープでいうと周辺システムとの連携についても、ある場合は記載しておきます。業務システムだとユーザマスタなどは人事システムから連携してもらったりと考えられますし、システム化にあたり他システム連携は検討する企業は多いと思いますので書いてなくても連携できるような作りにする提案ができると良い。

そしていつごろリリースしたいのか。リリース（本稼働）に向けてどういったスケジュールなのか。そのあたりも重要です。受け側が今回のスコープのボリュームがリリースまでに出来上がるのか、できないような場合は、段階的リリースが可能か。そういった調整の余地が発行側にあるのか。

システム要件、機能要件、非機能要件

システム要件を全て記載するとボリュームが多くなってしまうので最低限でいいと思います。記載時に想定しているシステムの全体構成やハードウェア構成、ソフトウェア構成、ネットワーク構成などもあれば。この辺りはクラウドでやるのかオンプレでやるのかで変わってくると思います。

機能要件については、○○が可能であること、といった記載が一般的。「登録時にメールが管理者に送信される。」という機能要件がある場合、スクラッチであれば作りこめばいいけど、パッケージシステムの提案だとその機能があるかないかとなります。ないなら作るか・・・

リプレースの場合は、現行の機能は大体全て必要になるので機能が多い場合は機能要件のボリュームがかなり大になってしまいます。それに追加でほしい機能もあるはずなので書き方には注意したいところ。

各種データの出力も機能要件では記載します。項目単位でズバリでは出力できなくても、そのデータを使って後続の業務でこのようなことをしたいという書き方が大事になります。

セキュリティについても記載が必須の項目です。個人情報を扱うシステムなら尚更ですよね。企業によってはセキュリティ規約がある場合はそれに準じるという前提条件となります。

またスマホやタブレットなどでも利用を想定している場合は記載します。細かい企業の場合は、OSのバージョンや通信方式まで記載していることもあります。クライアント端末も同様に。稼働後にそのブラウザは想定していなかったと、あるあるですよね。

開発推進体制、開発手法、成果物

受け側の体制を記載しますが、プロジェクトマネージャーはどんな人か、その人の経験や保有資格はなにか。今回対象となる業界や業務のシステム開発経験はあるか。その会社に任せられるのかという判断のため、会社としての実績を求める場合もあります。その会社の不得意な部分はコンサルを入れた体制にするなどで逃げることも可能。

開発手法は指定があればそれに準じるのみですし、指定がなければ、案件によって最適であろう手法での提案をすればいいと思います。ここも１パターンでいくか、複数パターン容易して挑むかは、この案件を取りたい温度感によります。

成果物は、もう記載の通り。後だしにならないよう出す側が最低限必要な成果物・ドキュメントは記載しておきましょう。

保守・運用、サポート体制

リリース後はどう対応してもらいたいのか、またどんなことができるのか。どの範囲で面倒を見てもらえるのか。単に作るだけで終わりか、作った後もお付き合いを考えているのか。出す側受け側ともに探り探りなところでもあります。

見積・費用

金額はとても重要ですよね。ただし状況によって見せ方はそれぞれです。
発行側は、概ねこれくらいの予算で・・・というケースと記載しないケースがあります。記載しない場合は純粋にどれくらいかかるのか予測がつかないからや単に各社からの提案を見てみたいという願望もあったり。とはいえ大体裏ではいくらからいくらというレンジ持たせている場合があります。前に一度あったのですが、価格は御社が一番安かったけど安すぎるので本当にできるのか不安だ、と。もったいない・・・
提案時に保守費用あたりが含まれていないこともあるので明記することも大事。

契約事項、提案手続き

このあたりの項目はお決まり事項なのですが、RFP発行側の窓口は提案までの問い合わせでコミュニケーションとることになるので抑えておく。そして提案まではほどよく質問する。全く質問がないと発行側は不安になってしまいます。
手続きの仕方は出す側に合わせることが基本。

まとめ

RFP発行側としては、良い提案をしてもらうために「最低限必要な条件を記載すること」これに尽きます。

受け側としては、良い提案をするためにRFPの情報から出来る限り完成後をイメージし提案書を作る。どうしても難しい場合は、早めに辞退することも当然ありです。

共通で、記載の仕方、され方によっては、その言葉や文章が双方で異なる認識をしてしまうこと。これはとてももったいないので、書く側は用語集のようなもので補てんしたり、読む側は質問したりして齟齬がないようしていくことも大事だと思います。