RFP(Request for Proposal)

今日は、RFPについて少し述べたいと思います。まず、用語をご存知ない方に少々説明させてもらいますとRFP(Request for Proposal)は「提案依頼書」とも言われ、政府・自治体や企業がシステム調達を行う際に供給者（サプライヤー）によりよい提案を競っていただくために使われるツールです。なぜ、こんなものが必要なのでしょうか？今までの方法に問題があるのでしょうか？

実は（驚くべきことに）システム調達の購入側はほとんどシステムの内容を知りません。必要な機能が使えればそれでよいからです。車のエンジンの構造を知らなくても運転ができれば問題ないと思うのと似ています。ただし、車の価格と調度品（グレードとかオプションですね）さらにランニングコスト（車の場合は燃費と税金、それと修理にかかる費用ですかね）は皆さんよく検討されます。ですので予算内で一番グレードの高い車で、オプションがいっぱいついていて、燃費がよく、壊れにくいとされているメーカーの車を選ぶわけです（選び方の基準はそれぞれですけど）。

さて、システム調達の場合もこの購入の基準と選定が（本当は）必要です。本当に必要な機能が網羅されていて、予算内で一番グレードが高く、気の効いたオプションがいっぱいついていて、ランニングコストが安く、壊れにくい（改造・追加が容易）とされているメーカーのシステム製品を選ぶべきです。

ここで最初の問題は「予算が立てられないことが非常に多い」ということです。織田がいつも不思議に思うのは、「なぜ皆さんは、そのシステムの購入によって得られる利益を基準にしないのか」です。コストダウンなり売上の向上なりの目標があって、それに見合うシステムの調達を行うのですから、おのずと予算は出てくると思うのですが。極めて乱暴な言い方をすれば「元が取れるのか取れないのか」の「元」は皆さんわかっているのではないですか？ってことです。

さて、RFPに話を戻しますと、これを作ることによって購買者と供給者は互いの思いの違いを把握することができるようになります。「本当に欲しいもの」と「こんなのありますけど」のすり合わせができるようになるわけです。今まで口頭でメーカーの営業担当者に言っていたことかもしれません。けれど口頭では言い切れない細かい内容が本来必要なのです。後々「言った、言わない」にならないために。

ちょっと書ききれませんが、RFPでは以下の事項を記載します。

• システム概要（背景、目的・方針、課題、効果、現行システムとの関連、利用者、予算、・・・）
• 提案手続き（提案スケジュール、対応窓口、提供資料、参加資格、選定基準・方法、・・・）
• 提案内容（企業情報、提案の範囲、内容の詳細、構成、品質基準・性能、運用条件、納期、・・・）
• 開発要件（期間、場所、機器負担、貸与資料）
• 保証要件（品質保証基準、セキュリティ基準、・・・）
• 契約事項（発注形態、検収、支払い条件、保障期間、機密事項、著作権、・・・）

これはちょっと口では言い切れませんよね。ですが、これらを決めておかないと必ず後々問題が発生します。一番困る問題は「欲しいものが期間内に提供されない」ことです。多々ある問題を未然に防ぐためのツールだと思えば、実はこれほど強力で安心なものはありません。昔から言うではありませんか「段取り８部」と。日本のシステム調達の標準になればよいと考えています。

「こんなのプロでないと無理だ」と思われた人もおられるかもしれません。しかし、どんな立場の人も結局は上記の項目（のほとんど）を結果的に対応しています。大きな企業のCIOで、システムに関わっていない人でもRFPを作成することはできます。必要なのは供給者まかせにしないで自分たちで考えることです。自分たちの使うシステムなのですから。我々は、それをお手伝いすることしかできません。