先日検証の記事を投稿して、順番が逆転しちゃっていますが
「要件定義」が終わって、お客様のニーズにこたえるように「設計」する作業が発生します。
設計と言っても色々あって
登場人物と業務内容で機能を洗い出します。
その中でシステム化するものしないものを決め
機能一覧や、画面設計、遷移図（フロー）、DB設計を行っていきます。
要件定義も大変時間がかかりますが、
設計フェーズの工数をしっかりかけておかないと、開発フェーズの工数がかかってしまう。戻りが多くなってしまう。
結果、全体の工数がかかってしまうことになるので、設計をしっかり行って、お客様と話し合うのが重要です。
なのですが、実際には設計書だけでお客様が要件を満たせるかどうか判断できません。
結局出来たものに対して、注文を付けてくることがほとんどです。
設計書なんてかみっぺらなので、そんなもので完成形を想像できませんよね。
私は人生で一度っきり（いや運よく2回あるかも？）の自分の家を建てました。
そのとき、設計図で間取りや、外観を決めましたけど、結果、作っている途中や完成してからも、
あーこういうことじゃなかったんだけどなぁ、という状態に。
もう出来上がってしまったものを修正することが出来ない有形物ではない、システムは、簡単に手直し出来るように思われるかもしれませんが
骨組みである、設計を修正するというのはかなり大掛かりなことであり、費用が掛かってしまうのです。
その点を理解していただき、納得していただくためにも、
「要件定義」をしっかり行い、「設計」でやることはもちろんのこと、やらないこともしっかり落とし込んで
お客様と合意を得る。というのが重要になります。
まぁ、なぜこんな話をするかというと
これまで炎上してきた案件はこの手の対応が出来ていなかったことにより、納期遅延、要件定義ミス、トラブル多発の事態をまねく案件を見にしてるからですねぇ。
事故を防ぐためにも案件のコントロールは大事。