要件定義でスコープを明確にというけれども

要件定義でスコープを明確にしろといわれて、機能の範囲は確かに決まった。
でも、詳細な粒度に当然落ちていないので、どれくらいの深さというか、どのくらい作りこみが必要なのかは決まっていない。
それによって、製造量が違うんだけれど、それって、設計していく中で決まるよね。

なのに、要件定義でしっかりスコープを明確に、というけど、それ以降は、スコープを明確にしろとはいわない。
仕様を決めていって、見積もった結果、当初考えていた概算と乖離して問題になることがあるけど、じゃあ、論理設計以降に考える深さって、スコープじゃないとしたら、何なんだろうかね？

・・・・

ま、それはおいといて、（いや重要な問題だけど、深さについて議論しないのは、ちょー問題だけど。おいといて）

実際、見積もり額が要件定義のころに比べると多くなるとすれば、どういう対応をその後するんだろうか？

１）構築工程以降を安くする手段を考える。オフショアとか。

でも、いきなり論理設計の出力でオフショア側が開発できるならまだしも、物理設計書は日本で書くとすれば、コストダウンにも限界がある。

２）機能を減らすというやり方。
これは最初の要件定義で決めたスコープを縮小することになる。
コスト的にはそれでいいかもしれないが、窓や扉のない家を作るか、窓や扉はあって、シャンデリアがぶら下がるけど、基礎工事の手を抜き、壁の中の材質をカットしたいわゆる手抜き型の家を建築することになるわけさと。

そこで出てくるのが、生産性を劇的に向上するツールの登場。
所詮、プログラミングしている時間は全体の中では大した割合ではなく、要件定義や設計に時間がかかるわけだから、思ったほど効果はない。

これが、ここ10年とはいわないけど、少なくとも５−６年は繰り返されているいわゆるWF型契約と品質管理を徹底しようとした日本型SIのジレンマ。
多段階契約でも、品質レビューを徹底しても、改善されない問題。

どうやって解決したらよかんべ？

解決するにはさ、工程の考え方、工程でやることを変えればいいだけさと。それについては、次回、考えが整理されたらね。