要求分析に表れるソフトウェア技術者の心：上を目指すエンジニアのための要求エンジニアリング入門（3）（1/3 ページ）

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

» 2009年05月13日 00時00分公開

　在庫調整が進んだので生産増、景気回復が望めるとの一部報道がある。しかし、経済環境は相変わらず厳しい。

　とはいえ、ソフトウェア開発を糧にして生きるには、ソフトウェアの開発需要が必要である。需要の提供者、中でも業務システムを必要とするユーザー企業、およびソフトウェア製品やソフトウェアを組み込んだシステム機器ベンダの多くは急激な収益悪化に直面し、コスト削減を迫られている。こんな時期には、収益向上あるいはコスト削減に効き目があると期待できるソフトウェアやシステムに対する需要・要求が顕在化する。

あなたの目の前に要求があるか

　前回は「要求抽出」を扱った。要求抽出が順調に進めば、目の前に要求が積み上がることだろう。

　今回のテーマである「要求分析」は、言葉どおり要求を分析することである。そのため、要求がなければ分析しようがない。要求を蓄積し記録しているファイルやデータベースから、どの要求を取り出し、分析して仕様をまとめ、設計・開発に導けばよいのだろうか。要求から実現すべき何かをはっきりさせる工程が必要だ。

　まず、要求の棚卸しをしてみよう。事態を進展させるには、要求がなければならない。もし要求がないのであれば、要求を生み出す方法を知らねばならない。すなわち、要求の一歩手前の「不満・不足・問題・トラブル・不愉快なこと・期待はずれ……」から直接、要求を創造しなければならないのである。幸い、要求を創造するための発想法がある。新しい価値を生み出すための発想法も強みの1つにすればよい。だから、要求がないからといって引き下がる必要は何もない。むしろ、さらに上流に進む、自分の可能性を高めるチャンスが到来しているといえる。

図1　要求がない場合に必要な「要求創造」

　要求創造につながる発想法は、「プログラムは『どう書くか』の前に『何を書くか』」で紹介した。ぜひ参照して可能性を増やしていただきたい。

　今回のテーマである「要求分析」に戻ろう（図2）。要求分析の大ざっぱな仕事は、要求データベースから取り出して要求リストに載っているあいまいな要求を明確にし、要求に優先度をつけ、要求の実現可能性を確認し、実現するプロダクトが備えるべき品質、要求を実現するプロセスの制約条件などを明確にし、仕様化すべき要求を整えることである。

図2　「要求分析」とは、あいまいな要求を明確にし、仕様化すべき要求を整えること

誰が要求を料理するか

　要求が山積しているとしても、誰かが要求を料理しなければならない（＝分析し結果を示さなければならない）。誰も料理をしなければ、素材としての要求の鮮度（＝機会）が失われるだけである。上級技術者を目指す読者が登場しなければならない場面である。

　要求分析の担い手を「要求アナリスト（あるいは要求エンジニア）」と呼ぶことが多い。日本では役割をはっきりさせずに要求を分析することが多く、要求があいまいなまま下流に送り出されたり、要求の取りまとめ（処理）に時間がかかったりする一因になっている。また、役割を明確にしてくれれば相応の仕事ができると考えている技術者も多い。しかし、あえて要求アナリストと呼ばれなくても、要求を料理する腕は獲得すべきであろう。ここでは、あなたがその料理の担い手である。

　あなたはいろいろな人から多くの期待を寄せられる。

経営者「コストは安く、雇用を維持せよ！」
マーケティング担当者「新しい機能。出荷を早く。魅力ある商品を！」
保守担当者「変更しやすく！」
顧客／エンドユーザー「コストは安く、タイミングよく出荷を。変更は抑えて！」

　期待は、時には怒りとして伝わってくるかもしれない。表現の仕方が極端に違うとしても、怒りの原因を要求として書き留め、素材を増やしておこう。

　ある程度素材が集まったら、要求分析に進むことになる。要求を仕様化するための「下ごしらえ」をするのである。このプロセスを「要求分析」という。しかし、要求分析を始める前に「調理に値する」要求か否か、その品質を確かめなければならない。

　1つは、要求が文章で表現されているか。社長や上司が大きな声で「売れる製品を作れ」と叫んだだけでは、まだ「要求」ではない。書き留めて文書にする。そうすれば、素材になる。社長や声の大きい上司の思いつきで開発プロジェクトに要求を出すことによって、プロジェクトが混乱することが知られている。まず、このような事態を避けなければならない。

　もう1つは「要求」の記録が誰かのメモ書きにとどまっていないか、である。要求は組織の顕在化していない価値ともいうべき財産だ。そのため、要求プロセスの調理台に載せ、組織的に、あるいはチームで共有された公式なものにしておかなければならない。

　そして、要求の品質を確認する。前回、最後に「要求にも品質がある」と記したことを思い出してほしい。1つ1つの要求の品質を調理する前に確認しておこう。品質を確かめないまま先へ進むと、要求に含まれていたバグを先送りしたことになる。先送りにした代償はあまりにも高くつくことになるので注意しよう（「生き残るために『要求エンジニアリング』を学ぶ」の図4と図5を参照）。

　要求の品質が悪い場合、どうすればよいか。いろいろな方法で要求の品質を高めることができる。とりわけ要求を発生させた源の主張を再確認し、要求データベース（＝要求リスト）に書き加えることが大切である。その要求がなぜ生まれたのか、その発生理由をあらためてインタビューすると、それまでに気付いていなかったことを発見できる。あいまいな内容は放置せず、何度でも質問することが大切である。