あなたの書いた要求仕様書に「妥当性」はあるか：上を目指すエンジニアのための要求エンジニアリング入門（5）（1/3 ページ）

上級技術者を目指すのであれば、要求エンジニアリングの習得は必須である。要求を明確化できれば、後工程の不具合が減少し、プロジェクトコストの削減や競争力強化につながるからだ。6回に渡って、要求エンジニアリングの基礎を解説する。

[前田卓雄，＠IT]

　あなたが前回までを参考に、要求仕様書を書いてみたとしよう。さて、このまま後工程に送り出してよいものか。何かを見直し、補強した方がよいだろうか……。

　この段階では、このような「不安」を感じることが多い。書いたものに自信が持てないとすれば、その原因はどこから来るのか。今回のテーマは、要求開発の最終フェイズである。

生き残るために「要求エンジニアリング」を学ぶ - ＠IT自分戦略研究所

　前回、要求仕様書にはさまざまな形があることを説明した。それぞれの要求仕様書によって、不安の表れ方も異なる。業務システムを調達する提案依頼書（RFP）では、ベンダから調達すべきIT製品に対する要求事項をもれなく記載したであろうか、という心配が発生する。システム機器の商品企画書に含まれるような要求仕様書であれば、商品力のある機能を定義できたか、競合他社に比べ競争力のある商品になるだろうか、機能は盛りだくさんで、利益の出る商品になるか、といった側面が特に気になる。

　これらの不安は、要求仕様書に記載したものを実現したい、と願う人の思いが反映している。この思いが弱ければ、要求仕様書も内容が希薄でセールスポイントのないものにならざるを得ない。今回は、「自信の持てる要求仕様書が書けたか」をどのように確認するか、というテーマを取り上げる。

妥当性を（早い段階で）確認する

　「妥当性」がある要求仕様書とは、いったいどんなものか。一口でいえば、「投資をしてもよい」「コストをかけてもよい」「発注してもよい」と思えるものである（提案依頼書の場合は「調達を進めてもよい」と思えるものである）。換言すれば、要求仕様書に記載された内容が実現すれば、期待の効果が得られる、というものである。もちろん、本当にそうなるか誰にも分からないということは、誰もが理解している。しかし、誰しも多額の投資や多くの技術者の時間をムダにしたくはないであろう（実際には、あいまいな要求仕様書から多くのムダが生じている。第1回参照）。

　妥当性確認とは、本来、投資に値する期待効果が得られるか確認する行為である。すなわち、要求の実現を通じて、企業が求める経営効果が実現するかどうかの可能性を判断することである。

顧客の「真の要求」が分かる技術者を目指せ - ＠IT自分戦略研究所

　例えば、収益向上、費用削減、競争力向上などの経営効果の実現である。開発が終わった段階で妥当性がないことが判明したとしても、それまでに投入したコストは元には戻らない。

図1　ソフトウェア開発のVモデル

　図1は、いわゆるソフトウェア開発のVモデルである。このモデルでは、受け入れテストを経て妥当性を確認する。しかし前述のように、この段階で妥当性がないことが分かったとしても手遅れである。もっと早い段階で妥当性を確認する工夫がなければならない。例えば、プロトタイピングはそのための有効な手法である。プロトタイピングそのものは、要求開発段階でも実際の開発段階でも実行することが可能である。

図2　プロトタイピングによる期待のコントロール

　余談だが、CMMI（Capability Maturity Model Integration：能力成熟度モデル統合）の妥当性確認についても見ておこう。CMMI V1.2によれば、「妥当性確認（VAL：Validation）」の目的は、成果物または成果物の構成要素が、意図された環境に設置されたときに、その意図された用途を充足することを実証することである。従って、CMMIのいう妥当性確認は、開発プロジェクトの終結段階で作成されている成果物ないしその構成要素に対するもので、要求開発段階の妥当性確認とは異なる。