RFP作成の注意点　スクラッチの場合、パッケージ／SaaSの場合

システム投資に失敗しないために、比較的小規模のシステム導入でもRFPを作成しようと考える企業が増えてきた。本稿ではスクラッチ開発の場合、パッケージもしくはSaaS利用の場合、それぞれのRFP作成の注意点を解説する。

公開 2010年12月09日 08時05分

更新 2012年09月04日 16時27分

著者

永井昭弘

[イントリーグ]

印刷する

「何を、幾らで、いつまでに」をベンダーに明確に伝える

　RFP（Request For Proposal）とはユーザー企業がベンダーに対して、情報システムの調達のための提案依頼を文書で提示する行為、または提案依頼の文書そのもの、つまり「提案依頼書」のことだ。システム調達を行う際にRFPを書くという行為はかなり以前からあったが、大企業などの一部のシステムの場合がほとんどであった。しかしここ数年、システム調達の失敗を防ぐ有力な手段として、中小規模のシステム案件でもRFPが用いられるケースが増えてきている。

　RFPがあらためて注目されるようになったのは、やはり昨今の不景気が影響しているだろう。経営上システムは不可欠であるが、多大な投資が必要である。そして、その投資には失敗は許されない。システム投資を失敗すると、コストが当初の2倍、3倍、そしてそれ以上に増加することも珍しいことではない。また、本番稼働時期が遅れることで、業務に多大な影響が出たり、商機を逃したりといった弊害も小さくない。失敗のリスクを少しでも小さくするために、多少面倒でもRFPを作成しようと考えるユーザー企業が増えているのだ。

　「システム投資の目的や背景」「何をシステムに求めているのか」「幾らの予算で検討しているのか」「いつごろまでにシステムが稼働している必要があるのか」、つまり「何を、幾らで、いつまでに」をベンダーに明確に伝えることは、システム投資を成功させる上で非常に重要である。

提案依頼書とシステム発注

最適なERP選びは「ベンダー丸投げ」から自己責任へ

スクラッチ開発とパッケージ利用の特徴

　RFPを作成する上で考慮しなければならないことは幾つかあるが、今回はスクラッチ開発の場合とパッケージ利用の場合において、それぞれ注意すべき点について解説したい。また、一般的なパッケージソフトとSaaS（Software as a Service）の場合でのRFPの留意点の違いなどにも触れてみる。まずは、スクラッチ開発とパッケージ開発、それぞれの特徴を確認しておこう。

スクラッチ開発の特徴

　スクラッチ開発とは、独自のシステムを新規に開発することである。基本的に制約のない一からの開発なので、いかようにでもシステムを組むことができる。

スクラッチ開発の特徴

業務に合わせて、思い通りにシステムを開発できる
ほかに事例のない特殊な業務や大規模なシステムの開発に用いられることが多い
一般的に開発コストはパッケージ利用より高価になる
一からの開発のため、システムはある程度完成しないと動かない
設計者やプログラマーの力量により、バグなどの品質が左右される

パッケージ利用の特徴

　パッケージ利用はその名の通り、既存の業務パッケージソフトを導入する方法である。パッケージをそのまま利用する場合と、カスタマイズ（機能の修正）やアドオン（機能を新たに追加）を行った上で利用する場合がある。

パッケージ利用の特徴

パッケージをそのまま利用する場合は、システムに業務を合わせることになる
上記では業務要求が満たせない場合は、カスタマイズやアドオン開発を行うことになるが、その場合はパッケージ利用のメリットが減少する
スクラッチ開発より安価である（ただし、カスタマイズやアドオン開発が増えると、高価になる場合もある）
導入に要する期間がスクラッチより短期間である（上記と同じ原因で長期化する場合もある）
最初から動くし、バグも少ない

　さらにパッケージ利用のもう1つの選択肢として、SaaSやASPなどのサービス利用もある。この場合、上記パッケージの特徴に以下が加わる。

SaaS／ASPの特徴

ハードウェアやサーバの運用場所が不要となり、初期コストを大幅に削減できる
逆にランニングコストは相応に掛かる
契約したその日（または翌日）から利用できる
カスタマイズやアドオンは通常のパッケージ以上に大きく制限される
データをすべてサービスベンダーに預けることになる

　RFPを作成する場合に、システム構築の方針がスクラッチ開発か、パッケージ利用か、あるいはSaaS利用か明確に決まっている場合は、それぞれの特徴を把握した上で記述する方が要求内容は明確になり、ベンダー側としても前提条件が決まるので提案がしやすくなる。

　もちろん、RFP作成段階ではスクラッチにするかパッケージにするか決まっておらず、ベンダーからの提案書を見てから判断したいという場合もあるだろう。その場合は純粋に業務要求や運用要求を洗い出して記述すればよいが、当然のことながら提案書評価の作業は複雑かつ増大する場合が多い。一般論で言えば、RFPを書く段階でシステム構築の方針が決まっている方が、調達活動全体の作業負荷は小さい。

RFP作成時の留意点

スクラッチ開発のRFPの留意点

　業務に合わせて思い通りにシステム開発ができるというメリット、つまり自由度が高いということは、逆に「要求を明確にしないと、いかようにも解釈できてしまう」というリスクもある。極端な言い方をすれば、「RFPを受け取る前のベンダーは、前提知識がゼロである」と考えた方がよい（実際の調達活動では事前にベンダーに情報提供したり、面談したりするのでゼロということはないが）。従って、かなり詳細な情報をベンダーに与える必要がある。

　そこで最も重要な情報が、業務フローとなる。ここでは話を分かりやすくするために純新規ではなく既存システムの再構築の場合で説明すると、以下2点をどれだけ具体的に提示できるかがスクラッチ開発の場合のRFPの要点となる。特に新業務フローが明確に記述されていれば理想的である。

スクラッチ開発のRFPで明示すべき業務フロー内容

既存システムではどのような業務を、どのようなフローで処理しているのか
新システムでは現行業務フローのどこを改善したいのか、あるいは既存ではやっていないどのような新業務フローを追加したいのか

　しかし、現実的にはスクラッチ開発を前提とした場合であっても、RFP作成時点では新業務の目的や内容は決まっているが、新フローまでは決まっていないことも多い。そのような場合は以下の点を注意すべきである。

RFP作成時点で新業務フローが決まっていない場合

まず業務そのものをきちんとベンダーに理解してもらうこと。そのために現行業務フローをきちんと提示する
現行業務フローの課題部分を明示し、問題点を分かりやすく文章化する
業務の中心となる処理が新たな業務フローとなる場合は、RFPの段階でもできる限りフローを提示する。未確定の部分があれば、どこが未確定かコメントしておく

パッケージ利用のRFPの留意点

　パッケージ利用の場合、システム開発のスケジュール・品質・コストに最も影響を与えるのは、「カスタマイズやアドオン開発をどれだけやるか」ということだ。特にアドオンの増加は影響が大きい。アドオンが増えると開発コストが高くなるだけでなく、運用後のメンテナンス、つまりランニングコストも増大する。例えばパッケージのバージョンアップでは、パッケージ本体部分は動作保証するが、アドオン部分は対象外となる場合がある。その場合、別途ユーザー側のコスト負担で検証テストをしなければならない。従って、業務要求を記述するときに、「必須の機能」と「あれば便利な機能」を明確に分けて、さらに優先順位を付けることが重要となる。

　また、「この処理は自社独特のもので、パッケージにはないだろう」と予想される業務処理がある場合は要注意である。そのような処理はアドオンになる確率が高いし、情報が少ないとベンダー側が要求を理解しきれずに、後々品質やコストでもめる要因となる。従って、文章だけでなく模式図などで「見える化」して伝えるべきである。

　パッケージ利用の場合、業務要求とパッケージがどれだけ適合するか、フィット＆ギャップ分析を行う。このフィット＆ギャップ分析ではすべての業務要求を均一に評価してはいけない。

パッケージのフィット＆ギャップ分析の注意点

優先順位の高い要求からフィット＆ギャップ分析を行い、重み付けをして評価する
「必須の機能」がパッケージ基本機能またはカスタマイズでどれだけ対応可能かベンダーが分析しやすいよう、RFPの記述を工夫する

　上記、「必須の機能」には当然自社独自の機能も含む。RFPの記述を工夫するとは、例えば要求を表形式でまとめて、「1ライン1要求」「明確な優先順位（重み付け）」「基本機能・カスタマイズ・アドオンの3択」などの表記を行うとよいだろう。

　また、パッケージ利用の場合はスクラッチ開発と比較して、新業務フローの必要度は低いと考えてよい。もちろんあればそれに越したことはない。しかし、RFP作成は限られた時間しかない場合が多いので、作業の取捨選択も必要だ。パッケージ利用は基本的に「業務をシステムに合わせる」という発想をすべきで、新業務フローを頑張ってゴリゴリ書いて「この業務フロー通りの処理をパッケージで用意しろ」というのは、労多くして益が少ない。従って、パッケージ利用の場合はフィット＆ギャップ分析を意識した要求の明確化と優先順位付けを重視しよう。

永井昭弘（ながいあきひろ）

株式会社イントリーグ　代表取締役社長兼CEO

日本アイ・ビー・エムの金融担当SEを経て、ベンチャー系ITコンサルティングのイントリーグに参画。1996年、代表取締役に就任。情報化企画、RFP作成支援、ベンダー選定支援、プロジェクトマネジメント支援などのITコンサルティングの実績多数。特にRFP作成からベンダー選定の調達フェーズに対し独自に体系化したコンサルティングノウハウを持つ。著書『RFP&提案書完全マニュアル』（日経BP）

印刷する