要求の旅は終わらない―開発と並走する「要求管理」：上を目指すエンジニアのための要求エンジニアリング入門（6）（1/3 ページ）

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

[前田卓雄，＠IT]

　いよいよ最終回である。これまでの5回を通じて、要求側が作成した要求仕様書を、設計・開発・実装（以下「開発」と表現）を担う技術者が受領し、要求事項にあいまいさが残っていないなど、要求自体が備えていなければならない品質を確保できている状態にまで到達したとしよう。

　実際のところ、この状態を実現することは非常に難しい。だが、今回はあえて実現している前提で話を進めたい。さらに、要求仕様書に記載したことが実現すれば、ソフトウェアとして、あるいはシステムとして、そしてビジネスとして有効な結果が生じることを確信できる状態が理想的である。要求開発の終了時点では、要求実現を担う開発者に実現してほしい結果・状態・もの（システムやソフトウェア）をまとめ、ベースラインとする。ここから先が、要求管理プロセスである。

第1回 図2　要求エンジニアリングの対象領域

　なお、実際にはほとんどの場合、こうした理想的な状態に到達しないまま要求管理プロセスに入ることになる。プロジェクトによっては、要求ベースラインを決めかねていたり、要求側自身が何を要求しているのか、はっきりと説明できていないことがよくある。それにもかかわらず、どうしてその状態で要求管理プロセスに入ってしまうのだろう。どうすればこのような事態の発生を抑制することができるだろうか。要求開発プロセスは、このような事態を生じさせないプロセスではなかったのか。

　いろいろな疑問や反省が生まれることだろう。反省結果は、今後の要求開発プロセスの改善につなぐことにしよう。大きな飛躍が期待できる。ただ、その際にはこの連載をもう一度、最初から読み直してほしい。第2回「すべての始まり＝『要求』を抽出する」から第5回「あなたの書いた要求仕様書に『妥当性』はあるか」までを熟読すれば、気付くことが数多くあるはずだ。読者は、要求開発・管理プロセスにさまざまな工夫を組み入れることができる。例えば、要求元であるユーザー自身に直接、要求を記述してもらうとどうなるか。エンドユーザーが要求仕様書をそれまでに一度も書いたことがなかったとしても、書き方さえ分かれば、自ら要求を明確化でき、しかも要求の品質も大幅に向上する。こうした「ちょっとした工夫」を追加することで、読者の付加価値は大いに向上し、自信がつくだろう。

要求管理とは

　さて、最終回のテーマ「要求管理」の話に入ることにしよう。要求管理は、要求開発プロセスを引き継ぎ、ソフトウェア開発プロセス内で要求を扱うプロセスである。通常、要求管理プロセスでは、要求品質が十分でない要求や、あいまいに記載された要求仕様書への対処、要求内容に変更が必要になった場合の対処などを扱う。これらは開発プロセスと並行して実施する。

図1　要求開発プロセスから要求管理プロセスへの引き継ぎ

　要求管理プロセスは設計・開発する立場から検討されることが多い。しかし、要求管理プロセスは本来、要求側のプロセスである。開発プロセスを通じて要求を着実に実現させるには、要求が正確に伝わっていることが大前提である。要求したものを理解してもらえたか、開発された成果物の品質は要求した品質以上か、開発を進めている最中に要求を変えたくなったらどうすればよいか、といった、要求を出した側の懸念に応えるプロセスである。

要求のベースラインを定義し、維持する

　要求ベースラインとは、要求者と開発者が合意した要求のことである。この場合の要求とは、第4回 図2で示した広義の要求を指す。

第4回 図2　ソフトウェア要求の分類

　要求には2種類の品質がある。1つは、要求内容そのものを実現し利用した場合の実質的な品質であり、もう1つは、要求が伝わるかどうかという、要求の表現や追跡にかかわる品質である。要求者にとって前者の品質は後者よりはるかに重要であるが、要求を受け取る開発側にとっては、要求を正確に受け取り、要求どおりに実現するために、後者の品質の方が“取りあえずは”重要だ。要求に対する立場が両者で異なっているのである。それでも、両者が合意し、プロジェクトをスタートさせなければ、要求は実現しない。立場は食い違っているが、両者は相手を必要とする、実に悩ましい関係である。だから、両者の折り合いを表した「要求ベースライン」が必須なのだ。

　もう1つ、付け加えなければならないことがある。それは、「開発プロセスに入っても要求の理解や対処に食い違いが発生することがある」ということだ。だから、開発プロセスに入る当初から、食い違いを調整する要求管理プロセスが必要なのであり、この要求管理プロセス自体、両者が合意したものでなければうまく進まないのである。