 |
||||||||||
|
||||||||||
| 1 2 3 次のページ | ||||||||||
|
||||||||||
| RFP作成前に決めること | ||||||||||
|
第1回では、RFPがなぜ最近になって注目を集めているかという背景を説明し、RFPに記載すべき事項と開発におけるRFPでは、「何を（What）」が「手段（How）」と密接に関係していることを解説してきました。 第2回は引き続き、何を（What）はどこまで決めておくのが適切なのかを解説していきます。 |
||||||||||
| RFP作成の考え方 | ||||||||||
|
第1回でも説明した通り、要件定義前のRFP作成では、何を（What）をどこまで決めておくべきなのかを、決めることが難関です。このことを考える際は、まず何を目的としてRFP作成に取りかかるのかということに、立ち返る必要があります。RFP作成の目的は第1回でも示した表1の通り、次の条件を備えた提案を得ることです。
表1：提案の備えるべき要件（再掲） 表1で注目すべきことは2の費用です。 提案する側（RFPを受け取る側）の立場に立って考えてみると、1の対応策については課題がわかれば「このような感じのシステムを構築するのが対応策になります」という程度のことは比較的容易に提案することができます。 しかし2の費用については、「どんな開発・運用環境で、どんな画面がいくつあって、どんなバックエンドプロセスやバッチプロセスが必要で…というようなことがわからないと、なかなか怖くていえない」というのが実情です。 つまり、費用の見積りを可能にする要素を提示していないRFPで見積りを提示せよなどというのは、無理難題以外のなにものでもありません。そのため、開発ベンダーの方から「要件定義が完了してからでないと見積りは提示できません」という話をよく聞きます。 しかし本連載のテーマは、時間をかけてゆっくりと要件定義をして、それからRFP作成にとりかかるというものではなく、要件定義よりも前に「本当に要件定義以降の開発に着手していいのか？」を判断するための提案を求めようというものです。 では、いったい何をどこまで提示すれば、開発の見積りが可能になるのでしょうか。 |
||||||||||
| システム開発における見積方法から見積るための条件を考える | ||||||||||
|
システム開発の現場では様々な見積技法が試みられていますが、ここではもっとも一般的と思われる技法を取り上げ、何を提示すれば開発の見積りが可能かを検討してみます。 なお、実際の開発現場での見積りは、ここで取り上げる見積方法を組み合わせて相互検証をするなどの運用がなされています。 |
||||||||||
|
1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
