「なぜ、提案依頼書（RFP）を書くのか？　提案依頼書（RFP）にかかる基本的な考え方について」

【発注者としての対応とは？】

一般財団法人 日本情報システム・ユーザー協会（以下、JUASと表記）より例年発行される「企業IT動向調査」（2012年度版）は、ユーザー企業からのアンケート調査（有効回答数 1000件以上）とヒアリング調査（40社）を実施してまとめられたものです。
その調査の内容で興味深い兆候が見て取れました。それは、発注者としての対応ができている企業ほど、プロジェクトの工期は規模を問わず、予定通りに完了し、プロジェクトの予算も予定通りに完了し、満足した品質を得ているということです。
では、発注者としての対応とは、どのように定義されているのでしょうか。JUASの調査では、以下の4点を挙げています。

• 「要求仕様の明確化」
• 「委託先の進捗管理」
• 「委託先の体制・能力の評価」
• 「委託先とのコミュニケーション」

この中でも重要なのが、「要求仕様の明確化」であり、要求仕様を明確にして文書化することで提案依頼が可能になります。その文書化したものが提案依頼書（以下、RFPと表記）そのものであります。

【要求仕様の明確化ができていない状態とは？】

システム開発でたまにシステム側から聞くことがあるものとして、仕様確定後もユーザー側の仕様変更が多発するとか、ユーザー側で要件を明確に定義できないとか、それは特定の人の頭の中だけに業務ノウハウがあり文書化されていないからだとか…
逆にユーザー側は、ビジネスのスピードが早いから仕様変更が発生するのであって、そのスピードにシステム側がついていけていないとか、要件を明確に定義できなくてもシステム側で行間を読んでくれとか、行間がわからないのはシステム側に業務ノウハウがないからだとか…
このようなよじれ状態を要求仕様の明確化ができていない状態と言うのではないでしょうか。そもそもなぜこんなによじれてしまったのでしょうか。それは端的に言うと、コミュニケーションギャップです。業務用語で話すユーザー部門とシステム用語で話すシステム部門が通じ合うのは、そもそも困難です。両者の思いが情報システムによって実体となり、そこで初めて両者の思い違いがあきらかになり、システム開発時のトラブルとなるというパターンが多いように見受けられます。
一方、経営者と一般社員との間では、「社長のいうことは、わかるのだけれど、実際自分たちは何をして良いのかわからない」といった、コミュニケーションギャップが生じているのにも関わらず、そのギャップを解消すること無しに、現場が必死に働いたが、結局経営向上につながらなかったという話は、珍しいことではありません。これは、経営者と一般社員の考えていることがそもそも違うからです。それを経営戦略→ビジネス要求→業務仕様→システム仕様へ途切れなくシームレスに情報が繋がるような工夫がRFPに必要ですし、そのつながりがRFPには、不可欠で、それにより要求仕様の明確化が可能になると考えます。

【じゃあ、何を書いたら明確になるの？】

RFPは、さあ書きましょうと言って簡単に書けるほど、簡単なものではなく実際に書き始めるといろいろな壁にぶつかります。以下に例を上げます。

• 何を書くの?
  • 要件定義?→業務の概要?システムの仕様?外部設計まで?
  • データ定義?→概念モデル?論理モデル?物理設計?
  • IT基盤?→ハードウェア?ソフトウェア?ネットワーク?
• どのレベルまで書くの
  • 業務フローは書くの?
  • 詳細に書くことがいいことなの?
  • 品番や型番まで決めないといけないの?
• いつ、誰が依頼するの?
  • 丸投げって、どういうこと?
  • 開発だけ依頼するの?
  • 依頼責任者と担当者って誰がいいの?

実は、上記に対する答えはありません。そもそもRFPに書き方の決まりは無いのです。
ただし、外さないためのポイントを含んだテンプレートはあります。
ビジネスイノベーションセンターでは、特定非営利活動法人 ITコーディネータ協会の見本を使うケースがあります。
http://www.itc.or.jp/foritc/useful/rfpsla/

情報化資源調達フェーズにおいて活用する開発用RFP見本と契約書内に盛込み難いサービス品質を開発用SLA（サービスレベルアグリーメント）見本、並びに運用を外部に委託する場合の運用RFP見本と運用SLA見本のあわせて4つの見本がサイト上で公開されています。

図１　「情報システム開発の流れ（抜粋）とRFP・SLA見本の関係」 出典：特定非営利活動法人 ITコーディネータ協会 ＲＦＰ・ＳＬＡドキュメント見本提供について

見本に沿って、開発用RFPで記述する項目を例示してみます。
何を書いてもらうかは、各社の状況、対象システムの状況により異なりますことが前提になりますので、あくまでも見本です。
開発用RFP見本は、大きく分けて5つのブロックから構成されています。（現状の開示・要求事項・条件提示・回答依頼事項・特記事項）
そのブロックごとに記述項目が見本として、提示されています。

（現状の開示）

• 会社の状況
  • 業界の動向、ビジネスユニット（主要な製品）別の売上/利益、コアコンピタンス
• 経営戦略
  • このプロジェクトで達成したい経営目標、期待する定量的/定性的効果
• 現状業務
  • 現状の業務、課題、従業員のＩＴリテラシー
• 現状システム
  • 現状のシステムの状況、課題

（要求事項）

• 業務要件
  • 新ビジネスユースケース
  • 新ビジネス鳥瞰図
  • システム導入後の新業務フロー
• システム要件定義
  • ユースケースモデル、概念モデル、品質要求
  • サービスレベル、システム環境要件、システム運用要件の各定義書

（条件提示）

• 予算
  • 提示するか否かは個別判断 。提案の評価軸は、企画OR価格？
• スケジュール
  • 概略開発工程、マイルストーンや期限（得意先システムとの連動、税制改定等）
• 発注側の体制
  • プロジェクトオーナー、開発支援、ユーザー、プロジェクトマネージャー
• 検収方法
  • 検査要領書（検査事項はベンダーに作成させる方法もある）
• 権利関係
  • 成果物の帰属、二次使用、インターフェースやマスタデータ構造公開、知的財産権の帰属、第三者ソフトウェアの利用

（提案依頼事項）

• 一般事項
  • 会社概要（財務、事業概要、沿革、社内基準、災害時の体制）、業務実績
• 個別案件事項
  • 提案システムの内容
  • 提案条件（業務分担、二次外注業者）
  • 独自提案
  • 費用見積（初期費、保守費）、スケジュール
  • コミュニケーション （打ち合わせ、会議、書類）
  • 開発体制、開発方法、開発者スキル、保守体制
• 発注時
  • 発注方法、支払い条件、契約条件、契約類型（準委任／請負）、損害賠償責任（範囲・限度額・期間）、再委託

（特記事項）

• 評価方法
  • 一次選考有無、プレゼンテーションの有無、評価結果の連絡
• 提案事務
  • 質問受付、回答方法、担当者、提案書書式（電子媒体有無）、提出方法
• その他
  • 提案依頼に当たっての機密保持

【事例から学ぶ、書いたら嬉しいRFP！】

RFPをきちんと作成し、提案依頼をしたら、何が嬉しいのでしょうか？
期待感のレベルとして、2段階あると考えます。

（基本レベル）
・妥当な発注先の決定

基本レベルの事例としては、自力で要求仕様をとりまとめて、ベンダーにシステム提案を求めたが、結局発注先を決め切れなかった。その状況でビジネスイノベーションセンターに相談に来られたのです。ですから、仕切り直した上で発注先を決めることがゴールです。
原因は、要求仕様の明確化ができていなかったことに尽きます。不明確な要求仕様では、各ベンダーの提案が百社百様の状態になるのも必然です。ベンダーの提案を見ているうちに、どう評価・選定をしたらいいのか？どこに発注するのがいいのか？あるいは、自分たちが何をしたいのか？がわからなくなってしまって、支援を依頼された例がいくつもあります。

そのような事例に共通して言えることは、発注者とベンダーとの間のコミュニケーションギャップが大きいということです。業務用語で話す発注者とシステム用語でしか理解しないベンダーが通じ合うのは、そもそも困難です。事例を省みると、発注者側からの情報提供量が少なすぎたことが共通点かと思われます。あまりにもベンダーの裁量が大きすぎて、結果的に比較評価できない提案書が山積みになりました。そのようなときにRFP見本を参照し、情報量を整えることは効果があると言えます。

（応用レベル）
・コストダウンを実現した上での発注先の決定

応用レベルは、発注先の決定がゴールではなく、コストダウンがゴールです。10年以上もの長きにわたりベンダーとお付き合いしているといわゆるベンダーロックインに陥っていると考えてよいと思われます。通常、運用費用を含めて高止まりしていると考えるのが、一般的ですし、多くの場合は、何もしなくてもベンダーが提案を持ってきてれるという大変楽な状態、いわゆるぬるま湯につかっている状態になってしまっています。
このような状況では、きちんとRFPを発行し、競争入札形式で発注先ベンダーを評価して決めるという調達プロセスを実行するだけで想定外の素晴らしいコストダウン効果を産むというのが常です。
現状ベンダーとの契約見直しをしようと決意するだけで、ほぼ確実にコストが下がるのですが、調達プロセスを導入し、RFPを作成し、これまでのお付き合いを見直すことは、相当の勇気ある決断が必要です。その勇気があるかないかが、応用レベルでの果実を得ることができるかどうかの境目かと思われます。

【終わりに】

RFPは、提案依頼書という文書に過ぎないのですが、RFPを作成するということは、RFPを中心に様々なプロセス改革が起きるということです。業務やシステムの要件定義プロセスの変革、調達プロセスの変革、調達体制など組織の変革など影響は多岐に渡ります。それだけに、大きな効果が得られるものだと考えてよいというのが、実績から言えると感じています。
ビジネスイノベーションセンターでは、RFP作成支援コンサルティングサービスを提供しておりますので、何なりとご相談ください。

*本Webマガジンの内容は執筆者個人の見解に基づいており、株式会社オージス総研およびさくら情報システム株式会社、株式会社宇部情報システムのいずれの見解を示すものでもありません。

• 「 BigData　第1回　ビッグデータとは 」 前の記事へ
• 「グローバル時代の製造業のIT人材　「戦うマザー工場」へのIT部門からの貢献　その１」 次の記事へ

『WEBマガジン』に関しては下記よりお気軽にお問い合わせください。

• お問い合わせ

同一テーマ　記事一覧

• さらに見る