«

»

1月 04

015ケースバイケースで変わる提案依頼書(RFP)の必要項目と提示先

RFP(Request For Proposal)とも呼ばれる提案依頼書には、標準的な記載事項はあるが、独自開発の度合いや、事前の要件の固まり具合などの状況の応じた修整が必要となる。RFPの基本的な内容と、調達案件の状況に応じた対応方法について考えてみたい。

□ RFP発行の目的
RFP発行の目的は、これから行なう業務改革にフィットした情報システムを、確実に、もっとも安く調達することである。また、システムの本番稼働後も低いコストでの運用、業務の変更に応じた改修などを、委託先ITベンダーの協力を得て適切におこなえるようなシステム、ITベンダー、契約条件の選定を行なうこともその目的の範囲となる。

□ 標準的なRFPの記載事項
RFPの標準的な記載事項の概要は以下のようなものである。

1.システムの概要
・システム化の目的、目標・方針     ・狙いとする効果
・想定されるユーザー         ・既存システムとの関連

2.システム要件 (要件定義)
・システム化の範囲  ・解決したい問題
・業務の要件(業務フロー、業務記述書、詳細説明書、等)
・機能要件(必要な機能)
・非機能要件(システム構成、性能、運用、セキュリティ、開発手法、言語、等)

3.開発体制・推進方法・環境
・開発推進体制            ・工程計画
・テスト計画           ・レビュー実施方法
・仕様変更・機能追加などへの対応   ・作業場所
・開発機器、使用材料の負担、貸与物件 ・資料   ・成果物・納入物

4.ベンダーの遂行能力確認事項
・企業基本情報         ・ISO、ISMS、CMMI等の保有資格
・対象業務分野における開発経験   ・技術者の資格保有状況

5.契約条件
・発注形態      ・瑕疵担保期間     ・知的所有権
・導入後サポート   ・支払い条件      ・守秘義務

6.提案依頼手続き
・提案手続き・スケジュール         ・対応窓口
・調達者がITベンダーに提供する資料   ・参加資格条件

7.依頼内容
・要件を実現する提案   ・費用見積 ・納期、スケジュール

□ RFP記載事項を変える必要があるケース
RFPの記載事項が変わってくる大きな要因は、独自開発の必要性の程度と事前のシステム形態の決定度合いである。
全てがオリジナルな機能として作り上げる独自開発の場合、上記表のような内容が必要となるが、既製品であるパッケージソフトやSaaS、ASPを想定する場合は、事前の調査も進んでいるであろうから、それに合わせた必要な項目だけでいいだろう。パッケージソフトでも、提示した要件と異なる部分をアドオンやカスタマイズで開発するなら独自開発とほぼ同様な項目としたい。
事前のシステム形態の決定度合いというのは、予め特定のパッケージソフトやSaaS、ASPに決まっているようであれば、業務要件からしてそれに合わせる必要があるし、RFP記載事項のシステム機能要件は非常に簡単でよくなる。ただ、パッケージと決めてはいるがどのパッケージかをRFPによる提案で決める場合には、提示するシステム要件とパッケージ機能の違いに関する情報提供を、提案依頼のメインにする必要がある。また、パッケージソフトやSaaS、ASPの契約条件は、ユーザー毎に個別に決めることができない場合もあるので、必須条件にするかどうかは事前に確認してからの方がいい場合もある。

□ RFPの提示先のリストアップ方法
次にRFPの提示先をどのようにしてリストアップし、決めるかについて、考えてみる。
リストアップの方法には主に以下のような方法がある。
(1)既に付き合いのあるITベンダー
(2)コンサルタントや同業他社などから紹介されたITベンダー
(3)キーマンズネットなどの情報サイトで、調達対象分野で紹介されている製品やサービスから収集する
(4)日経コンピュータ、情報ストラテジーなどの付録の冊子、「××総覧」で調べる
(5)インターネットで、キーワードを入れてリストアップする
上記はいずれも有効だが、ITベンダーはほぼ必ず製品やサービスを自社Webサイトに掲載しているので、上手に使えばインターネットからの情報収集がもっとも効率的である。

□ RFPの提示先の決定方法

RFP提示先の決定については以下のような考え方で決めるとよい。
(1)リストアップした先が少なければ地域など現実性も考慮した上で、原則全てをRFP提示先候補とする(実際に提示するかどうかは打診してから決める)。
(2)リストアップした先が多く、絞り込みづらい場合は、RFI(情報提供依頼書、Request For Information)を発行して、収集できた情報を判断材料とする。

(3)同業他社などで採用して評判の良いところが分かるようであれば候補とする。

(4)時間と手間はかかるが、パッケージの場合は、有望そうな会社に実際に説明に来てもらい情報を収集する。担当営業やエンジニアを評価することも可能なので、「いいところ」をしっかりと探す場合に有効である。

以上が、RFPの記載内容、提示先選定の考え方の概要である。
(2012.3.14 執筆:山田一彦)