ユーザー要件の理解/管理が成功のカギ

前ページで説明したように、ユーザー要件を明確に理解することが、ビジネスの正しい把握につながります。しかし、読者の皆さんの多くも感じると思いますが、これは非常に難しいことです。

もう1つ別のデータを見てみましょう（図2）。同じNISTの調査によるものですが、こちらはアプリケーション開発において「不具合がどのフェーズで取り込まれてしまったのか」と「不具合がどのフェーズで検出されたのか」を示しています。

このグラフによると、ソフトウエア開発における不具合の実に70％は、上流に位置する要件定義・設計のフェーズで取り込まれています。一方、その不具合がどこで検出されたのかを見てみると、60％はユーザー受け入れテストの段階でユーザーによって発見されています。

この2つのグラフからは、「要件に関する不具合は、ITのプロである開発者でも検出することができず、開発の最後の段階でユーザーによって検出される」という事実を潜在的に示しています。そして、このことはアプリケーションを開発する人たちにとって、非常に大きな問題になるはずです。

というのは、不具合を修正するのにかかるコストは、プロジェクトの終わりになればなるほど、加速度的に増加するからです。これは、アプリケーション開発においてコストを最適化できない大きな原因の1つです。

そうだとすると、いくら皆さんの会社にスーパー・プログラマや優秀なテスト担当者がいて不眠不休でバグつぶしに取り組んだとしても、要件に関する不具合を減らして品質を改善することは困難ということになります。こうした理由から、プロセス（仕組み）を作って管理することが必要なのです。

どのように要件を管理すればいいのか

どのように要件を管理すれば、最適なコストと品質で、予定通りのスケジュールでアプリケーションを開発できるのでしょうか。この課題に対してHPでは、「HP Quality Model」（HPQM）というユニークな品質管理のアプローチを提唱しています。

HPQMは、HPが提供するソフトウエアの機能として実装されています。ここからは、このHPQMの考え方にそって、HPQMのポイントをいくつか紹介します。

（a）要件を階層的に管理する

ポイントの1つ目は、要件の管理方法です。ひとくちに「要件」と言っても、ユーザー要件（ビジネス要件）、機能要件、非機能要件、テスト要件など、さまざまなタイプがあります。

皆さんは、要件定義書を書くときに、これらの要件をどのような構成で記述しているでしょうか。要件を管理するときの構成次第で、要件の漏れや矛盾を防ぐ効果があるほか、要件に変更があった際の対応にも影響します。

HPQMでは、要件定義にあたり、まずはユーザーのユース・ケースを洗い出すことを推奨しています。ユース・ケースというのは、ユーザーが行う業務手順などを表現しているので、ユーザーから見れば、よく分かっている内容です。

洗い出したユース・ケースをビジネス要件として定義し、その下に機能要件や非機能要件を階層的に定義していきます。いきなり要件について尋ねるのではなく、まずユース・ケースに着目することによって、ユーザーのニーズを具体化し、要件を明確化することができます。

（b）要件を検証する

HPQMでは、要件定義後、設計に入る前に「要件の検証」フェーズを設けることを推奨しています。要件の検証や要件のレビューは、どこの会社でも実施しますが、具体的にどのように検証/レビューするのかは、会社によってまちまちです。多くの会社では、レビュー・ミーティングを開催し、ユーザー側と開発側で読み合わせを行ったりしているようです。

一方、HPQMでは、要件の検証フェーズの工程で、定義した要件を検証するためのテスト条件を作成することを推奨しています。テスト条件を作ってみると、定義のときには十分に明確だと思った要件が、実は不明確で、テストを作ることができないことが判明します。そこで、もう1度要件について検討し、不明点を明確にします。

要件の検証を行う目的は、もう1つあります。このフェーズで作成するテスト条件は、実はユーザー受け入れテスト時に作成するテスト条件に相当します。つまり、受け入れテストの条件を先に作成しておくことになり、後のフェーズにかかる工数を削減する効果があります。

（c）要件と要件、テスト、不具合を関連付ける

HPQMでは、基本的に、“V字モデル開発”をベスト・プラクティスとしています。この方法では、定義された要件は、開発の観点からは、より詳細な設計へとブレーク・ダウンされ、プログラムとして実装されていきます。一方で、品質の観点からは、テストへとブレーク・ダウンされ、プログラムの正当性を検証します。

このため、テストは、「プログラムが仕様書通りに書かれているか」を検証するだけでなく、「プログラム機能が要件を満たすか」を検証するものとなります。これを可能にするために、定義された要件とテスト・不具合を関連付けて、要件がどれくらいテストされているか（テスト・カバレッジ）を管理するとともに、要件が変更されたときにどのテストに影響がでるかを分析する必要があります。

また、前述のようにユース・ケースをベースに要件を階層的に管理すると、同じ機能要件が複数のビジネス要件の下で重複して定義される場合があります。このため、要件同士を関連付けておき、ある要件に変更が加わったときに影響を受ける要件を素早く特定できるようにしておく必要があります。

次ページでは、もう1つの重要なポイントとして、ビジネス要件のリスクの大きさを考慮したテスト戦略の立て方について解説します。さらに、HPQMの実現を支援するソフトウエア製品を紹介します。

ビジネス・リスクに応じてテストを最適化