このエントリーをはてなブックマークに追加LINEで送る

7.1. 要件定義の重要性

ハッピィ・エンジニアリング表紙

 一般的に、システムの欠陥のほとんどは、要件定義プロセスや、その分析プロセスで発生しているといわれている。つまり、要件定義プロセスで、すでにシステムの品質の多くが作り込まれているのである。要件定義プロセスで作り込まれた欠陥には、要件自体があいまいなために誤解を生んだもの、要件の抽出漏れ(要件リーク)、要件定義プロセスが終了してからの要件の追加(要件クリープ)の3種類に分類できる。これらの欠陥は、修正するプロセスが後になればなるほど、修正に必要なコストが増加し、結果的にシステムの安定稼働に影響する。

 

 言い換えれば、要件定義プロセスの成果物品質が高ければ高いほど、システム設計時に潜在している欠陥が少なくなり、開発における手戻りや改修のコストが大幅に削減されるということである。さらに、SIベンダがリスクを見越して見積もりに上乗せしているコストをも削減することが可能になる。

 

 要件定義プロセスの成果物品質を高めるためには、要件定義に関わるメンバそれぞれが高い意識を持って望むことも重要な要素であろう。特に意思決定権者は、単に書類に捺印するのみならず、積極的に要件定義の場に参加し、事業的な観点からの意見を述べるとともに、その承認に際しては、システムの目的に照らし合わせた合理的な判断をすべきである。

 

 「バグを出すわけにはいかない」という意識を強く持っている開発者が、しっかりと設計レビューやテストを行い、結果につなげていくように、要件定義プロセスにおいても高い意識を持ち、品質向上のための作業プロセスを作り上げていくことが重要である。バグと同様の定量的な尺度により、その動機付けを行うのはよい方法であろう。以下は要件定義プロセスの問題を定量化した言葉である。

 


要件の30%は要件プロセス"後"に追加される
『要件プロセス完全習得法』スザンヌ・ロバートソン/ジェームズ・ロバートソン著, 苅部英司訳, 三元社, ISBN4-88303-111-X


開発の期間中、要件定義は月1〜3%で増大するために、大型システムにおいては初期の要求定義が50%の機能しか示していないような場合が起こる
『ソフトウェア品質のガイドライン』Capers Jones著, 富野壽訳, 構造計画研究所, ISBN4-320-09726-2

 

さらに、一般的なプロジェクトにおける手戻りのコストは開発工数の40〜60%を占める。プロジェクトメンバの誰もが、要件クリープや要件リークを後のプロセスで修正するコストがどれだけ大きなものかを理解していれば、要件定義プロセスで「欠陥を作り込まない」やり方に対する意識が高まり、さらに成果物に対する目も厳しくなるはずである。現状の「要件定義ごっこ」における甘えをなくし、正しいやり方に変革していかなければならない。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

7.1. 要件定義の重要性 ハッピィ・エンジニアリング関連ページ

7.2. 要件定義プロセスにおける課題
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.3. 歴史的背景
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.4. 相互誤解
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.5. 要件定義プロセス
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
7.6. 要件定義の未来像
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング