少し前の記事ですが、システム開発の訴訟で野村HDが日本IBMに敗訴する、というものがありました。プロジェクトが上手くいかず、中止となった損害分を日本IBMに請求したというものになります。
裁判では最終的には要件変更の多さが、プロジェクトが難航した要因の一つとして挙げられています。このプロジェクトの開発ではウォーターフォールかアジャイルかは明示されていませんが、おそらくウォーターフォールで行われた開発なのでしょう。たしかにウォーターフォールであれば、要件変更はプロジェクトの進行において大きな遅延要因となりうる要素ではあります。
ただ、今の時代に要件が途中で変わらないといったことがあるでしょうか。私もプロジェクトの現場はいくつか経験していますが、要件が途中で変わらないケースの方が珍しいという感触です。多かれ少なかれ、要件変更が発生してしまうのが現実だと思います。要件変更が多くなると想定された場合に、アジャイル開発という手段を取ることがあるでしょう。ただ、アジャイル開発だからといってスプリント中に要件変更を繰り返して、そのスプリント内に終わらないといったことをしてしまっては意味がありません。
もちろん、ちゃんとしたものを出すのも大事ですが、「まず終わらせる」というのも大事になってくると考えています。下記の記事にあるような、終わらせることによる、安心感はけっこうバカにならないと感じます。
私が以前書いた記事ですが、終わらせるということに対して、機能の絞り込みが大事になってくると考えています。変えたい要件が発生した時に、それは今やらなければいけないのか、後でリリースすることに支障があるのか、そもそもその機能無しでリリースすることは可能か、
などなど、絞りこむにしても提供価値に、どのような影響があるか当たりがつかないと、絞りこみは出来ません。
エンジニアの機能への理解がないと、何が優先すべき事なのかという判断が、適切に行うのは難しいと考えています。下記の記事にある通り、まずは要件の理解、そして意志決定を行う判断基準は大事です。ここら辺がしっかりチームで共有されてないと、要件変更にダラダラ付き合わされる、いつまでもリリースできないといった、よろしくない状況につながる気はします。
