生き残るために「要求エンジニアリング」を学ぶ：上を目指すエンジニアのための要求エンジニアリング入門（1）（3/3 ページ）

» 2009年01月26日 00時00分公開

要求エンジニアリングを実践しなければならない本当の理由

　読者は技術者として仕事をする中で、例えば以下のような事態に遭遇し、面倒な課題を突きつけられていないだろうか。

あいまいな要求に起因するバグの発生とその対応
よく発生する仕様変更や仕様追加と開発済み成果物に対する影響
次第に大きくなるソフトウェアの品質問題
プロジェクトの納期遅延や予算超過という問題
技術者の士気の低下
開発プロジェクトの失敗やキャンセル

図4　バグから見た工程の意味

　図4は、極めて一般的な開発プロセス上のどこでバグが「混入」し、そして「検出」「露見」するかを記したものだ（コード上のバグに限らず、仕様書など文書上の誤りもここではバグと表現している）。バグが見つかると、何らかの手戻りが発生し、バグを正すために（余計な）工数・期間・コスト、そして対応する技術者が必要になる。これは、問題が発生してから事後的に対処する「問題発生・対処型」のアプローチである。実際に、多くの技術者がこのために多くの時間とエネルギーを消費している。

　これでは競争力や自己の強化につながらない。そこで、バグの根本原因の分析を実施し、バグの再発を防止しようとする「再発防止型」のアプローチを採用することになる。最終的に上流の要求開発工程まで立ち返ることを経験された人も多いことだろう。これにより、ソフトウェアの品質を向上させることができる。

　図5は、バグの修正にかかる実装工程のコストを1とした場合に、ほかの工程ではいくらかかるかを相対的なコスト比で示したグラフである。一般に、実装工程よりさらに下流の開発テスト工程で修正が行われると、実装工程で行う場合に比べて1?5倍程度、受入工程まで進んでしまえば5倍程度、運用工程（市場に送り出された後）では5?100倍程度になる。つまり、修正にかかるコストは、工程が下流になればなるほど余計にかかる、ということである。逆に、設計工程で修正できれば0.5倍、要求工程であればさらに少なくなる。グラフ上では0.4?0.1倍程度で示されている。極端な見方をすれば（グラフの両端を比べると）、1000倍近くも余計にコストをかけて修正していることになる。

図5　バグの修正にかかるコストを相対比較する
出典：『Software Requirements Engineering』 p.481（IEEE発行、2000年）

　バグが見過ごされて下流に行けば行くほどコスト増になり、逆に上流で解決できればコストが格段に安くつく。もちろん、バグの修正コストの多くは技術者の「負の作業」、すなわち明解で適正な要求に基づいて設計・実装・テストが行われれば、本来不要なはずの作業コストである。「問題発生・対処型」プロジェクトでは高額のコストを、「再発防止型」を採用したとしても、当面はバグ修正のコストを負担しなければならない。

　もしバグを埋め込まない「未然防止型」アプローチを採用できればどうなるだろう。事態は大きく変わるに違いない。「未然防止型」ではバグの混入を徹底して排除する。

　このアプローチでは、不明確な要求によるバグ混入を未然防止する要求エンジニアリングの実践が欠かせない。そして、プロジェクトコスト削減や競争力強化も期待できる。さらに、技術者には時間的余裕が生まれ、新たな需要や要求を創造する時間や、自己成長のための時間に振り分けることもできる。このように、要求エンジニアリングを習得することは、「自分の強み」を強化することにつながる。

　次回以降、5回に分けて「要求エンジニアリング」の各プロセスを紹介する。読者の能力向上に役立ててほしい。

著者紹介

前田卓雄

匠システムアーキテクツ株式会社代表取締役

外資系コンピュータベンダのシステムエンジニア、デロイトトーマツコンサルティングを経て独立。主に、ユーザー企業、行政機関、大手システムインテグレータ、ハイテク企業、大手組み込みソフトウェア開発ベンダにおいて、情報戦略の立案、ユーザーが自ら作成するRFP（提案依頼書）作成を支援、ソフトウェアビジネスのプロジェクトポートフォリオ、プログラムマネジメント、プロジェクト管理とプロセス改善、開発プロジェクト管理システムの開発、バグ削減・欠陥予防・ソフトウェア生産性や競争力向上コンサルティングに従事。

「次回」へ

「上を目指すエンジニアのための要求エンジニアリング入門」バックナンバー