RFPとは
RFP(提案依頼書)とは何でしょうか?
「情報システムの導入や業務委託を行うにあたり、発注先候補の事業者に具体的な提案を依頼する文書。システムの目的や概要、要件や制約条件などが記述されている。(IT用語辞典 e-Wordsより)
インターネット等で、この言葉を検索すると、概ねこのような説明が出てきます。要は自分たちがほしいITについて提案予定者に理解してもらい、有用な提案、そして自分たちの組織(企業等)に役立つITを提供してもらうために出す文書、これがRFPということになります。自分たちが今、置かれている現状と抱える問題を明らかにして、その解決策としてのITはどのようにあるべきか、それを実現するためにどれだけのコストや時間がかかるのか、そんなことを複数の専門家に提案してもらい、その中で一番よいものを選び、構築あるいはサービス提供をしてもらい、業務の改善等を行う。RFPは、まさに、その出発点とも言うべき文書ということもできるでしょう。
このRFPの書き方が不備で、ベンダにIT導入の目的と要件が十分に伝わっていないと、どんなことが起きてしまうでしょうか。RFPの不備が起因して要件が不十分だったためにユーザ企業とベンダが裁判で争うことになった裁判の例があります。
(東京地方裁判所 平成21年2月18日判決より)
ある薬局運営企業がWeb調剤薬歴管理システムの開発をITベンダに委託したが、完成したシステムには電子薬歴機能(薬歴一覧表示,薬歴メモ入力,問診表示,薬歴印刷,調録印刷)が同一画面で容易に確認できることが必要なところ、これが出来ず、その他にも不備があって業務に使用できないと、ベンダとの契約を解除した上、開発費用の変換を求めて裁判を提起した。
ところが裁判所は、電子薬歴機能はシステムに実装されている。ユーザ企業は、これらの機能が同一画面で確認できることが必要だったと主張するが、そこまでの合意をした証拠はないとしてユーザ企業の訴えを退けた。
この例は、IT開発における要件定義あるいは基本設計工程における要件漏れなのですが、元々の原因はRFPにあります。複数の業務が同一画面で行うことが、業務上、どうしても必須のことであれば、ユーザ企業は、自らの業務内容と処理の状況をベンダに理解させ、それを元に要件を定義して見積もりをさせるべきでした。見積もりをさせるために書く文書とは、まさにRFPそのものです。
この事件の例では、要件定義から開発までを一本の契約で行っていましたので、要件定義書作成の前に見積もりが行われていました。その元となったRFPに記述した要件に漏れがあったのです。
要件定義と開発を別契約で行う場合においても、開発の見積もりの前提がRFPであることに変わりはありません。要件は決まっていても、それ以外の諸条件(スケジュールや体制など)が開発以降の提案を行うベンダに示され、ベンダはそれを元に見積もるわけですから、やはり、それらを包含したRFPは、とても大切な文書ということになります。極端に言えば、RFPは、IT導入、いや、それを通して実現される新しい業務の具体的な出発点とも言え、これをしくじると、上記の裁判のように、全く役に立たないモノに対してお金だけを払う羽目に陥ってしまいます。