RFPの作成方法が分からない！：システム部門Q＆A（6）（1/3 ページ）

RFPの作成は企業のIT戦略を明確化する手段であり、システム発注の要となる。しかしIT成熟度が低い企業の場合、適切なRFPを作成するのは非常に困難だ。どうすれば適切なRFPを作成できるのか？

[木暮 仁，＠IT]

質問

どうやってRFPを作成・評価すればいいのか？

ベンダにシステム開発を依頼するときには、RFP（提案依頼書）を作成するべきだといわれていますが、高度な情報技術者がいない中小企業では困難です。RFPにはどのような意義があり、どのように作成すればよいのでしょうか。また、提出された提案をどう評価すればよいのでしょうか。

　発注側の担当者が、情報システムに対して成熟度の低い場合、適切なRFPを作成するのは現実には困難で、コンサルタントの協力が必要になります。しかし、RFPを作成することは、情報化戦略を明確にすることでもあり、RFP作成により成熟度の向上にもつながるのですから、将来的には自社で作成できるようにすることが望まれます。

そもそもRFPとは何か？

　RFP（Request For Proposal：提案依頼書）とは、発注者が開発するべき情報システムの要件をベンダ（情報システム開発業務の受託企業）に示す文書です。

　発注者はRFPをいくつかのベンダに提出します。ベンダはRFPに応じた提案書を提出し、発注者はその提案を検討して、発注するベンダを決定します。その後、発注者とベンダは詳細について相談して、ベンダがシステム開発仕様書を作成し、発注者が承認することにより契約になります。

　どうせ相談をするのだから、RFPなどは適当でよいではないかと思うかもしれません。しかし、情報システムは目に見えないし企業により千差万別ですから、ベンダは適当に想定することはできません。発注者のニーズに合致した提案をするには、かなりの検討が必要になります。それで、RFPが重要になるのです。

　RFPには通常次のような内容が記述されます（ITコーディネータ協会『RFP／SLA見本シリーズ（配布版）』より）。

1．システム概要

　 システム化の背景、システム化の目的・方針、

　 解決したい課題、狙いとする効果、現行システムとの関連、

　 会社・組織概要、新システムの利用者、予算

2．提案依頼の手続き

　 提案手続き・スケジュール、提案依頼書に対する窓口、

　 提案資料、参加資格条件、選定方法について

3. 提案していただきたい事項

　 提案企業情報、提案の範囲、調達内容・業務の詳細、

　 システム構成、品質・性能条件、運用条件、

　 納期およびスケジュール、納品条件、

　 定例報告および共同レビュー、開発推進体制、

　 開発管理・開発手法・開発言語、移行方法、

　 教育訓練、保守条件、グリーン調達、費用見積もり、そのほか

4. 開発に関する条件

　 開発期間、作業場所、

　 開発用コンピュータ機器・使用材料の負担、

　 貸与物件・資料

5. 保証要件

　 システム品質保証基準、セキュリティ

6. 契約事項

　 発注形態、検収、支払い条件、

　 保証年数（瑕疵担保責任期間）、

　 機密事項、著作権等、そのほか

添付資料

　 要求機能一覧、DFD（データフローダイヤグラム：データの流れを図示したもの）、

　 情報モデル（*）、現行ファイルボリューム、現行ファイルレイアウト

　 *（筆者注）ER（エンティティ−リレーションシップ図：データとデータの間の関連を図示したもの）モデル、あるいは簡単なクラス図に相当するもの

　このようにRFPに記述するべき事項は多いのですが、ここでは発注者が提示する最も重要な部分である「1　システム概要」と「5　保証要件」の分野に限定します。

適切なRFPが重要な理由

　ベンダはRFPにより開発するべきシステムの内容や見積もりをするのですから、RFPはベンダが対象システムを十分に理解できる内容でなければなりません。

1.ベンダ丸投げはもってのほか

　自社で検討をする前に適当なベンダを呼んで、システム化検討の段階から情報システムに関する事項をすべてベンダに依頼するような丸投げは論外です。これではRFPとシステム開発仕様書が混同されてしまいます。受注者が発注書を作成するようなものですから、ベンダにとって都合の良いものになりがちです。

　それは、ベンダが商売志向だからというだけではありません。ベンダが最も知識経験の高いのは自社製品ですから、自信を持った提案をしようとすれば、自社製品を勧めることになります。また、ベンダが経験のある方法を提案することになります。そのような情報システムが必ずしも自社にとって適切なものにはなりません。

　ベンダにRFP作成を依頼する場合には、そのベンダに実際のシステム開発契約を前提とせずに、RFPの作成までを独立して契約するべきです。

2.「販売システム一式」的なRFPはトラブルのもと

　また「販売システム一式、詳細は面談で」というような、漠然としたRFPも多くあります。これは、情報に関する社内成熟度が未熟であり、社内でシステム化検討が十分に行われていないことの証明だともいえます。慎重なベンダだと、そのような顧客を相手にしたのでは、システム開発で多くのトラブルが発生するリスクが高いと考えて、提案に応じないでしょう。

　提案が得られたにしても、その提案はベンダが適当に類推したシステムですので、自社のニーズに合致した提案になるはずがありません。再度説明を繰り返すことになり、それだけ費用と時間がかかってしまいます。それに、ベンダはこのような相手では受注後のトラブル発生リスクが大きいことを予想して、その費用を上乗せするでしょう。あるいは、顧客が素人であることに付け込んで、2流・3流の技術者を割り当てるかもしれません。いいかげんなRFPは、結局は自社の損になるのです。

3.適切なRFPは効果が大きい

　十分に検討されたRFPであれば、ベンダは状況がよく理解できるし、それに合致した適切な提案をするでしょう。しかも、顧客の成熟度が高いことに応じて、その評価に耐えられるように、十分に検討した提案をするでしょう。

　さらに、適切な提案が得られれば、その後の打ち合わせも円滑になり、短期間で適切なシステム開発仕様書が作成できますので、開発に着手するまでの期間が短縮されます。また、この段階で両社の認識が合致するので、システム開発でのトラブルが少なくなり、期待した費用・納期・品質が達成される確率が高くなります。

　RFPは、詳しく具体的なものであることに越したことはありませんが、それには高度な情報技術の知識経験が求められますし、非常な労力が掛かります。どの程度にするかが問題になりますが、それには「標準RFP」のようなものがあると便利です。ITコーディネータ協会では「RFP／SLA見本シリーズ」を公開しています。しかしこれはかなり詳しい記述を求めており、情報技術者がいない中小企業がこれに従ったRFPを作成するには、ITコーディネータのようなコンサルタントの協力が必要になります。

　なおRFPは、ベンダの提案を受けることが目的であり、システム開発仕様書ではありません。「何をしたいのか」は十分に提示する必要がありますが、専門家であるベンダの創意工夫を引き出すためにも、「どのようにして実現するか」については特に重要な事項でない限り記述しない方が適切です。