 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| RFP作成の難しさ | ||||||||||
|
近年では、様々な企業でRFPは作成され提示されています。これまで筆者も、いろいろなRFPを見てきました。 しかし、実はRFPといっても冒頭に述べた「ユーザからA業務のB画面を使いやすくしてほしい・・・」というメモレベルのものから、非常に詳細で膨大なものまであり、現在は大きく二極化しているようです。 完成度から見るとメモレベルのものは論外としても、実は詳細で膨大なものについても、問題がないわけではありません。 例えば画面仕様は非常に細かく書かれているのに「何のためのシステムなのか」「どのような業務で何を達成すればよいのか」というシステムの全体像が見えないものが多いのです。 このような全体像が見えない状況では、見積りも過剰になりがちなのが現状です。これは、開発ベンダー側がRFPから読みきれない部分を余分に見積りに織り込むためであり、そのリスクを想定すれば当たり前のことなのです。 通常、システム開発におけるRFPでは、どのような手段（How）で実現するのかという点が提案の依頼内容になります。つまり手段（How）については詳細まで検討できないケースがほとんどです。 このため何のために開発しようとしているのか（Why）と、何を開発しようとしているのか（What）を提案の依頼先に明確に伝えることが重要になります。 しかしシステム開発では、何を（What）と手段（How）がかなり密接に関連しています。例えば、Webアプリケーションで業務システムを構築して欲しいというように、両者が密接に関連している場合が多いのです。 何を（What）の全体概要は当然伝えるべきことなのですが、ともするとシステムすべてを設計した結果を記述するということになってしまいます。 それはそれで誤りではないのですが、そのためにかなりの時間と費用をかけてRFPを作成することになります。これでは、投資に値するかどうかの判断をするには過剰なものということになります。 このように、何を（What）をどこまで記述しておくべきなのかということが、RFP作成において一番難しいところなのです。 また、設計した結果を記述しているようなRFPでは、一般的に手段（How）の提案を求めることが多いため、提案に対する回答をあらかじめ与えることにもなります。時間と費用をかけて設計すれば、手段（How）までを記述し、開発の体制やスケジュール、費用を提案させるというRFPも作成することはできます。 しかし本連載ではそのようなRFPではなく、投資に値するかどうかの判断をできるだけはやく正確にするために、本格的な要件定義の前にRFPを作ろうとするものです。そのため、本連載ではできるだけコンパクトに、「何を（What）」を提示できるようにすることに重点をおいて解説していきます。 |
||||||||||
| なぜRFPの作成は難しいのか | ||||||||||
|
整理すると、システム開発におけるRFPでは、システムによってどのような業務を実現するのかという「何を（What）」の部分がITという手段（How）を前提とするために、「何を（What）」の具体性を増せば増すほど手段（How）に近づいていき、どこで切り分ければよいのかがわからなくなってしまい、結果として「RFP作成は難しい」ということになるのです。 次回は、この「何を（What）」をどこまで記述すればよいのかについて解説していきます。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
