曖昧な仕様

投稿日:2007年04月16日作成者:yasunaka

今日は曖昧な仕様書というテーマです。システムで実現すべきことが書いてあるのが仕様書なわけですが、この仕様書が曖昧で何を実現するのかがはっきりしないものって、結構あります。特に厄介なのはシステム開発の最初の期間で、「じゃあ何をやろうか」というスタイルのシステム開発をする場合です。

この「じゃあ何をやろうか」というのはシステムの概要設計フェーズに含まれている場合も多いのですが、これは設計ではなく分析です。本来設計の前に終わらせるべきことなのですが、事を複雑にしているのは、分析の精度をある程度求めると、投資対効果の費用を算出するためにシステム概要の前提を立てる、つまり設計しておく必要がでてくるということです。これはまさにシステムの概要設計にほかなりません。つまりどういうインフラを用い、どういう運用で、どういう技術やパッケージを使い、おおよそのシステム構成はどうで、などといったことがわからないことには費用の算出ができないということです。

分析フェーズの費用算出においてある程度システムの概要に見込みを立ててしまうと、今度はそれがいろいろな意味でシステム概要設計の足かせとなってしまいます。じゃあそれで問題がでないようにしようとすると、結果として「曖昧な仕様書」が出来上がってくることになります。つまり問題を先送りするわけです。

プロジェクトの運用スタイルの中にはわざと決定を先送りするやり方もあるようですが、そうは言っても基本的な事項を先送りされてしまうと、その先の検討が進まない場合が良くあります。例えばちょっと極端ですが、アプリケーション方式でやるか、Web方式でやるか、なんてレベルのことも決まっていないと、システム構成も決められません。それが連鎖して何から何まで曖昧模糊とした状態からぬけだせなくなる、なんてことも起きます。

これって、良心的な、頭のいい人達が集まってやると余計にこの状態に拍車がかかる傾向があります。ちゃんとやろうとしすぎて物事が運ばなくなる状態です。しかもこうなってしまうと分析期間がかかりすぎ、それだけで莫大なコストがかかったりします。プロジェクトを進めるためには、規模にもよるのでしょうが、むしろ1名のプロジェクト・オーナを決めて、その人が勘と度胸ですべての仕様を決めていく（もちろん裏づけは取った上でですが）、というスタイルのほうが実は費用対効果が優れていることが多いのではないかと、経験上私は思います。