最近のシステム開発は、要件定義、基本設計といったお客さまとの打ち合わせの工数が、開発工数に比較して、より多くとられる傾向にあります。
これは、上流で失敗してしまったものは、下流で取り返しがつかないということに所以しているのだと思います。
また、実際のところ、上流で失敗したシステムが、それほど多かったのだということの証ですね。
しかし、実際のところ、すべてのパターンにおいて、この要件定義、基本設計というパターンで進むのが良いかというと、そうではないと思います。
正直、「要件定義しなくても良い」と思う開発は多いものです。
SEが2人参加して要件定義、基本設計というスケジュールを作った場合、要件定義に2か月、基本設計に2か月というスケジュールとすると、人月だけで考えても8人月の費用がかかります。
要件定義をしなくても良いというのは語弊がありますね。
「要件定義や基本設計で全力を出し合い、互いのコミュニケーションをきちんと取り合えば、設計は100%固まる」とシステム開発会社側は考えている気がするのが不満なのです。
大きな声で言えない真実がここに潜んでいます。
つまり設計は、長すぎても深すぎても、冗長な打合せが続いたり、重要性の低い些細なことに拘泥して無駄な工数を生むのだと、そのデメリットについてどれだけ理解されているのでしょうか。
ある意味、客とSEのやる気が空回りしてしまうようなものなのです。
実際は、これだけの工数をかけて話し合ったのだから、お互いの認識漏れは無いという風な流れに持っていくことを狙っているのではないでしょうか。
お互いが掛けた時間工数で責任をとり合おうとしているような気がするのです。
山のように意味が薄いドキュメントが出来てしまうのも、同じ理由である気がします。
お互い、開発前の打合せで、ユーザーも開発会社側も、体力、精神力ともに消耗してしまうのは考えものであると思うのです。
開発金額のどれほどの割合を設計で費やしているかを考えれば、よく分かると思います。
わたしは、要件定義と基本設計の期間は、「長すぎても短すぎてもダメ」だと思っています。
基幹システムの大規模開発で、ウォーターフロー開発をきちんと守らなければいけない場合であり、SEが3、4人以上かかわる場合には、ある程度のお約束の形が必要ですが、実際には、そうでない場合が多いのではないでしょうか。
そして、要件定義をするのであれば最大の課題は、開発側とユーザー側に、それぞれ、その設計に専念・集中できるスタッフの確保と、彼らが毎週の中で確実にお互いの時間を無駄にしないような、
協調するための時間がとれるかどうかなのです。
また、お互いに要件定義に夢中になりすぎてしまうことも、負の問題になってしまいます。
細かな問題や道はずれの思いつきに首を突っ込んで抜けられなくなるのを防ぐために、要件定義をするくらいの大きさのシステムであれば、「第三者のコメンテータに、会議のときだけでも参加してもらう」
といった方法をとるのはいかがでしょうか。
Vol.00152