要件定義をしないシステム開発

システム開発には、要件定義という重要な工程があります。それは「ユーザーの要件を調査・分析して、どのような樹能をシステムで実現するかを具体的に決める」ことを目的とします。この工程は非常に困難で、ユーザとSIerお互いの情報量の違いによる誤解もさることながら、要件を文書化するのは大変な作業です。


さらにユーザが事前にシステム化の要件や範囲を詰めきれていない場合は、高い確率でスケジュールが伸び作業量が増加します。つまり、SIer にとってリスクが高い工程と言えます。それはユーザには高い費用として跳ね返ってきますので、双方にとって面白くありません。


この要件定義工程における課題をクリアするために、「要件定義しない」という手法を開発した企業があります。スターロジックです。この企業はユーザに自ら要件定義をさせることで要件定義工程を回避しています。*1


この要件定義をしないという部分については、私にもアイデアがあります。
まず、SIer は、ユーザの要件をある程度聞きます。ここでは特に成果物などを約束しません。そして、その要件を元に プロトタイプ(以下、プロト)を開発します。その完成したプロトをユーザに見せ、気にいったらそのプロトをパッケージとして買い取ってもらいます。その後はそのプロトを元に追加の要件を確定し製造工程へとすすみます。


従来のスパイラル開発との違いは、プロトタイプの開発を SIer の提案活動の一環として無償で行うことです。もし、最初のヒアリングが不十分であった場合は、SIer は無駄な稼動を行ったことになります。そういう意味でリスクが高いやりかたです。ただ、提案手法としてユーザにとって魅力的があるのではないでしょうか。また SIer には優れた要件定義をする必要がでてきますので、優秀な技術者の投入や優れた方法論を開発するインセンティブが働きます。これはユーザにとって大きなメリットです。


このやり方がよいところは、事前にユーザが出来上がりの姿を想像しやすいことです。それによって要件定義の段階で、業務に必須な機能や非機能要件の過不足を知ることができます。SIer 側では想定開発範囲をプロトとして公開することで、誤解の発生を未然に防ぐことができます。また、ドキュメントの量も減らせるでしょう。*2
業務プロセス改善系のシステム開発なら威力を発揮しそうな手法のような気がしますがどうでしょうか。

*1:ユーザが要件定義するには技術的にもインセンティブ的にも困難がありますが、うまくやるための仕掛けが見事なので興味があるかたは、同社のサイトをご覧ください

*2:ドキュメント作成の手戻りを減らせるという意味で