『要求仕様』を書いてみる

コラムカテゴリー:

ソフトウェア障害が起こった際、その原因はというと、設計やコーディングのミスなど技術的要因とされる事が多いように感じます。
しかし、よくよく原因を分析してみると「仕様漏れ」や「仕様の認識違い」等、仕様に関する問題が根本的な原因となっている事が多くあります。

仕様漏れ」や「仕様の認識違い」が起こるのは「仕様の合意」が発注側、受注側で不十分である事が原因ですが、それは仕様の合意形成の方法に問題があると考えます。
ソフトウェア開発の要件定義工程では大まかな機能要件は文書化され合意はされますが、以降の工程で仕様が文書化されて合意形成されるタイミングは少ないのではないでしょうか。
設計、開発工程になって仕様確認の質問が受注側から発注側へ頻繁にされます。
回答を受けて、要求仕様が設計やコーディングに反映されていくのだと思いますが、仕様として明記されない事が多いと考えます。

仕様確認の質問や回答の文章は、読み手によって解釈の違いがでるものが多く、正しく仕様が反映されない可能性があります。口頭でのやりとりは尚更です。
そして認識のズレがあっても、気付かぬまま仕様が実装されていく余地が生まれます。
また、質問のトリガーが設計や開発作業をする個々の担当者である場合は、本来、仕様を確認し合意を得るべき内容にも関わらず担当者の思い込みで実装されていく余地が生まれます。

「要求仕様の文書化は工数がかかる為、現実的ではない。認識のズレを発見し修正するためにテスト工程がある。」という考え方もあるのでしょうか。
仕様の合意が不十分であると、テスト前にどれほど認識のズレがあるかわからないため、
テスト&修正作業の工数は予想できません。
それに比べ要求仕様の文書化作業自体の工数見積もりは容易です。それに文書化をし、十分に仕様の合意が取れていれば、修正工数も少なくなるため、精度の高い工数見積もりが可能となりプロジェクトのリスクが減るものと考えます。
そもそも認識のズレをテストで発見できるのでしょうか。テスト仕様を受注側が作成するのであればテスト仕様もズレたままテストが実施されるのではないでしょうか。

要求仕様の文書化は、一見当たり前のように感じますが、実際は、軽視される傾向にあり習慣化している組織は稀であるように思います。
原始的な作業ではありますが、その重要性を改めて考えてみても良いのではないでしょうか。
私自身も、要求仕様化手法が解説されている書籍を参考に実際のプロジェクトに適用し、効果を体験した事があります。

※以上で述べた内容は、ウォーターフォールモデルを薦めているものではありません。
また、ソフトウェアの仕様は、基本的には受注側が提案し、発注側の承認を得ていくものと
考えています。

関連サービス

2008年11月15日 (土)

青山システムコンサルティング株式会社

池田洋之