知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」

本書では、プロジェクトの成否に多大な影響を及ぼす「要求管理」について、その工学的な概念と、ツールを使った実践手法を紹介します。プロジェクトの現場に素早く要求管理の仕組みを導入するために、要求管理ツールの 1 つである「RaQuest」を使いながら、要求管理の 7 つの実践手法を具体的に解説します。

目次
1.

はじめに ............................................................................................................................... 32.

要求管理と要求管理ツール「RaQuest」 ............................................................................. 4

3.

RaQuest による要求管理「7 つの実践」 ............................................................................. 6【実践 1】 要求をリポジトリに蓄積する ............................................................................... 6【実践 2】 要求を分類する .................................................................................................... 8【実践 3】 トレーサビリティを使って要求を検証する ........................................................ 12【実践 4】 要求属性を使って暗黙知を可視化する ............................................................... 14【実践 5】 要求の状態でプロジェクトを制御する ............................................................... 17【実践 6】 「プロジェクトスコープ」をベースラインで表現する ...................................... 19【実践 7】 変更要求管理でベースラインを保守する............................................................ 20

4.

まとめ ................................................................................................................................ 22

RaQuest について
「RaQuest」は、スパークスシステムズジャパン株式会社が開発・販売する要求管理ツールです。
このホワイトペーパーでは、RaQuest バージョン 4.4 を使用しています。

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

<製品詳細> https://www.raquest.jp/

21.

はじめに要求管理の現状
近年「要求管理」という言葉が頻繁に使われるようになりました。文献などの情報源は他の分野と比較しても豊富に揃っており、要求管理に関する情報が収集しやすい環境になりつつあります。しかし、要求管理の考え方が正しくプロジェクトの現場に浸透しているかというと、まだ疑問符を付けざるを得ません。この背景には、要求管理という概念が漠然としているため、具体的に何を実施すれば良いのか分かりにくい、という現実があります。
要求管理は、プロジェクトの成否に多大な影響を及ぼすテーマと深く関連しています。特にプロジェクトのスコープ（開発範囲）と要求管理には非常に密接な関係があります。誰もが関心を持っている「次のリリースにどこまでの要求を実装すべきか？」という、“曖昧なプロジェクト範囲”の問題は、プロジェクトに要求管理の仕組みを導入しなければ、解決することはできないでしょう。つまり、要求管理はプロジェクトにとって”あれば便利な概念”ではなく”必ず必要な仕組み”なのです。
現在、要求管理は、「その言葉や概念は浸透しつつあるが現場には定着していない」というステージにあると言えます。プロジェクトにとって必須の仕組みであるにも関わらず現場に十分定着していない、というこの現状はソフトウェア開発の現場にとって早期に解決しなければならない課題です。

要求管理はツール活用のメリットが大きい分野
この状況を打開するための１つのヒントが、本書のテーマでもある要求管理へのツールの適用にあります。本来、ツールというものは手作業で行っていることを効率化する補助的なものであるはずです。しかし、ツールには、漠然とした工学的概念を具体的に可視化できるという面があります。特に要求管理では、その概念が非常に捉えにくいため、ツールを使うことによって“具体的に何を行うべきかを理解する”というアプローチが特に有効に機能する分野なのです。
本書では、漠然として分かりにくいと思われているこの要求管理というテーマを、要求管理ツールの 1 つである「RaQuest」の機能を使って、具体的に実践する手法を紹介していきます。

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

3

2.

要求管理と要求管理ツール「RaQuest」

要求管理の位置づけ
本書のテーマである要求管理は、要求定義と同様に「要求工学（Requirements Engineering）」に含まれる分野です＜図 1＞。要求工学とは、要求に関するアクティビティ・技法の集大成であるとともに、ソフトウェア工学を構成する 1 つの領域として位置づけられています。
要求工学では、要求の特性や構造を明確にした上で、要求を取り扱う上でのさまざまな実践原則（ベストプラクティス）が示されています。その中でも特に重要なトピックとして、「要求の可視化」「要求スコープの制御」「要求のベースライン管理」「要求プロセスの運営」があります。それぞれの詳細は専門書に譲りますが、本書ではこれらの主要なトピックを RaQuest の各機能に照らし合わせながら具体的に解説します。

（関連する他の工学分野）

要求工学（Requirements Engineering）
要求定義
要求の抽出

要求の分析

ソフトウェア設計

要求の仕様化

要求の妥当性確認

要求定義ツール

ソフトウェア構築

要求管理
要求の可視化

要求スコープの制御要求のベースライン管理

要求プロセスの運営

ソフトウェア構成管理

プロジェクトマネジメント

要求管理ツール＜図 1＞要求管理の位置づけ

２種類のツール
他のソフトウェアエンジニアリングの分野と同様に、要求工学の分野においても作業をサポートするためのツールが市場に多く流通しています。さらに要求に関するツールは、大きく以下の 2 つに分類できます。
・ 要求定義ツール・ 要求管理ツール

1 つは要求定義ツールです。例えばユースケースを記述するための UML モデリングツールや、DFD を記述するための描画ツールなど、要求を定義し文書化・仕様化をサポートするツールです。もう 1 つが、本書で取り上げている要求管理ツールです。一般的な要求管理ツールは、要求の蓄積、要求の可視化、要求の追跡、変更要求の管理、影響範囲の分析など、手作業で行うことが困難で、正確性が保証されない作業をサポートする機能を有しています。

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

4

要求管理ツール「RaQuest」
本書の説明で使用する「RaQuest」は要求管理ツールに属します。RaQuest は要求工学の概念・ベストプラクテ
ィスが多く取り入れてられていますので、「要求工学の考え方や要求管理の必要性は理解しているが、具体的に何をすべきかを身につけたい」という方の利用に最適です。
次節以降では、RaQuest の主要機能を使いながら、要求管理で扱う重要なトピックについて、その考え方と実践法を紹介していきます。

本書で紹介する7つのRaQuest実践法【実践1】 要求をリポジトリに蓄積する【実践2】 要求を分類する【実践3】 トレーサビリティを使って要求を検証する【実践4】 要求属性を使って暗黙知を可視化する

対応する要求管理アクティビティ
要求の可視化
要求プロセスの運営
要求のスコープ制御
要求の可視化
要求の可視化【実践5】 要求の状態でプロジェクトを制御する

要求の可視化
要求プロセスの運営【実践6】 「プロジェクトスコープ」をベースラインで表現する

要求のベースライン管理
要求のスコープ制御【実践7】 変更要求管理でベースラインを保守する

要求プロセスの運営要求のベースライン管理

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

53.

RaQuest による要求管理「7 つの実践」【実践 1】 要求をリポジトリに蓄積する
ソフトウェア開発での要求は、ユーザからのヒアリング等によって識別され、情報として参照できる形式ですぐに記録されます。一般的には、紙のメモ、ホワイトボード、スプレッドシート等を使って収集した内容を記録することが多いでしょう。識別した要求を後で再確認したり、他人に説明したりする程度であれば、このような“一時的な”記録方法で十分です。しかし、収集された要求をソフトウェアのライフサイクル全体に渡って活用していくには、個々の要求が一ヶ所に蓄積され、一覧できる状態で維持されていなければなりません。つまり、ファイルサーバ的な管理ではなく、リポジトリ管理が必要となるのです。リポジトリに要求を蓄積することによって、記録された要求が一意に識別でき、必要な時に要求を正しく参照し、変更することが可能になります。また、要求同士を関連づけたりグループ化したりなど、要求をまとまった単位で扱う場面では、リポジトリは欠かせない環境となります。

識別された要求

要求の蓄積
内容の参照

要求-001要求のグループ化

要求の詳細

要求の関連付け要求-002
要求-003・・
・
要求リポジトリ＜図 2＞リポジトリに蓄積された要求

RaQuest を使って要求を作成すると、要求は管理可能なデータの要素としてリポジトリに格納されていきます。リ
ポジトリに蓄積された要求は、紙やスプレッドシートに記録されたものとは異なり、さまざまな目的で活用するための基礎データとなります。要求がリポジトリに格納されている状態は、要求管理を行う上で求められる最も基本的な条件のひとつです。
RaQuest を使って要求を作成する際には、ツールが提供するさまざまな恩恵を受けながら入力することが可能です。例えば、要求に一意の ID を付与する作業はどのような場面でも発生しますが、RaQuest では自動で行われます。その他、要求を登録する時の主な入力支援機能は以下の通りです。＜画面 1＞
・ ID、リビジョンの自動採番
・ バージョン、フェーズの設定
・ 登録日時、最終更新日時の自動記録
・ 更新履歴の自動記録

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

6

＜画面 1＞新規要求の作成

RaQuest では要求がリポジトリに蓄積されるため、さまざまな角度から要求を参照することができます。スプレッド
シートと同様に要求を一覧形式で見ることも＜画面 2＞、ワードプロセッサのように個別の要求を詳細に見ることも可能です＜画面 3＞。どちらの参照形式でもリポジトリに格納されている要求を参照しているだけなので、要求が一意である（ビューが異なっても同じ要求を参照している）ことが保証されています。リポジトリを利用することによって、情報の更新漏れ等で記述されている要求の内容が異なってしまったり、情報の反映が一部にしか行き渡らなかったりといった、いわゆる“要求の不整合”を避けることができます。

＜画面 2＞要求の一覧表示＜画面 3＞個別要求の詳細表示＜要求管理のプラクティス 1＞ 要求をリポジトリに蓄積する・ 要求はリポジトリに蓄積しておく・ 要求を参照する際はリポジトリに蓄積された情報を活用する

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

7

【実践 2】 要求を分類する
要求が数多く収集されてくると、何らかの切り口で要求をまとめて管理する必要が出てきます。要求工学の観点
では、一般的に要求を「抽象度」と「種類」という 2 つの切り口で分類するようにします。
・要求の抽象度
1 つめの切り口である「要求の抽象度」は、要求の詳細レベル、要求の発生元、識別されたタイミング等によって変化します。要求を管理する際に抽象度をあらかじめ識別しておくことで、“今扱っている要求”がどのレベルの要求であるのかが明確になり、要求定義をスムーズに進めることができます。以下に要求の 3 つの抽象度について説明します。
「要望」「要望」は"利害関係者が抱えるニーズ"を表します。最も高レベルの抽象度に位置づけられ、「要件」や「仕様」の根拠となります。要望は利害関係者の直接の声や意見を反映したものであり、ソフトウェアの利用者の真のニーズを表していなければなりません。要望が漏れてしまうと、その要望を満たすべき要件や仕様が識別されにくくなり、ソフトウェアがユーザの目的を満たさない、いわゆる「使われないシステム」になってしまう可能性があります。

「要件」「要件」は"ソフトウェアがユーザに提供する能力・サービス、及びソフトウェアが持つべき質"を表します。英語では"Requirement"ではなく"Feature"と表現されています。文献によっては日本語でもそのまま「フィーチャ」としている例もありますが、一般的には「要件」と呼ばれます。要件は 1 つ以上の要望を満たすための回答であるべきです。したがって、「要件 X は、要望 X の○○を満たすために存在する」という文脈が満たされなければなりません。

「仕様」「仕様」は、要求が設計作業の入力として意味を持つ単位まで詳細化され、文書化されている状態を指します。 仕様には機能仕様、インターフェース仕様（画面・帳票など）、データ仕様が含まれます。また、「仕様」は、最終的に全て公式な文書である「要求仕様書」として扱われます。要求仕様書は、システムが提供しなければならない機能と能力、及び遵守しなければならない制約を正確に記述するものであり、以降の開発作業（設計、実装、テストなど）を行うための根拠を示すものです。

高抽象レベル

要望「利害関係者が抱えるニーズ」

要件「システムが提供するサービス」

仕様「設計の完全な入力」

低＜図 3＞要求の抽象度知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

8

RaQuest で要求の抽象度を表現する方法の一つに「パッケージ」機能があります。パッケージは、個々の要求を任意の単位で物理的にグループ化できる入れ物です。UML のパッケージやファイルシステムのフォルダとほぼ同等の役割と考えるとイメージしやすいでしょう。抽象度別（要望パッケージ、要件パッケージ、仕様パッケージ）にあらかじめパッケージを作成しておくことによって、先に説明したアプローチで要求の抽象度を管理することができます。＜画面 4、5＞

＜画面 4＞抽象度別のパッケージツリー＜画面 5＞パッケージ単位の一覧表示

また、要求をパッケージでグループ化しておくことで、複数の要求をまとめて管理するための RaQuest の付加機能を利用することができるようになります。以下にパッケージを利用した際の主な機能を挙げます。
・ パッケージ別の要求一覧表示・ パッケージ毎の表示項目の変更
・ パッケージ毎に要求 ID を採番
・ パッケージ単位での要求のエクスポート

また、要求を抽象度とは別の単位（業務分野別やバージョン別など）でグループ化したいというケースや、物理的にはフラットに格納しておきたいというケース等があるでしょう。
そのような時は、RaQuest の「要求カテゴリ」という機能を使用します。要求カテゴリを使うと、物理的なパッケージ構成を跨いで要求の抽象度を表現することができます。なお、カテゴリ別（抽象度別）に要求を参照する場合は、ツリー表示を「要求カテゴリ別ツリー」に切り替えます。

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

9

・要求の種類
2 つめの切り口である「要求の種類」は、要求の特性によって「機能要求」と「機能外要求（非機能要求）」の大き
く 2 つに分けるアプローチが一般的です。「機能要求」は、システムの存在理由から生じる観測可能な振る舞いのことであり、「機能外要求」は、システムが持たなければならない固有の属性や質のことです。要求の種類を利用すると、あらかじめどのような観点で要求を収集すれば良いかが分かり、収集の漏れを未然に防ぐことができます。

機能要求

機能外要求

「機能」

ユーザにとって有益な機能性を提供するためにシステムが行わなければならない行動「ユーザビリティ」

ユーザインターフェースの統一性、習得のしやすさ、ヘルプ・サポート文書の必要性に関する要求「性能」

応答時間、スループット、キャパシティ、資源効率性に関する要求「信頼性」

利用可能性、可用性、データの正確性、システムの安全性、データ保護に関する要求「セキュリティ」

機密性、保全性、セキュリティ可用性に関する要求「保守性」

変更のしやすさ、移植性、再利用性、ローカライズ可能性に関する要求「運用性」

運用のしやすさ、監視のしやすさに関する要求「システム制約」

技術的制約、法律・規定への準拠に関する制約事項＜図 4＞要求の種類

要求の種類には、図 4 で紹介した方法以外にもさまざまなモデルが存在します。代表的な例として、FURPS+（Robert Grady, 1992）と、ISO/IEC 9126 (JIS X 0129-1)「ソフトウェア製品の品質」を紹介します。
◇FURPS+(Robert Grady, 1992)における要求の分類
F: 機能、U: 操作性、R: 信頼性、P: 性能、S: 保守性、+：その他◇ISO/IEC 9126 (JIS X 0129-1)「ソフトウェア製品の品質」における要求の分類
・機能性 ・信頼性 ・使用性 ・効率性 ・保守性 ・移植性

RaQuest では、要求の「種類」を設定することができます。個々の要求毎に種類を指定することによって、要求を分類モデルの観点に当てはめることができます。また、RaQuest では標準で FURPS+の分類モデルを採用しているので、要求をどう分類しなければならないかを検討する必要はありません。＜画面 6＞

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

10＜画面 6＞要求の種類指定後の機能外要求一覧

RaQuest には、要求のツリーをさまざまな切り口で表現するためのツリー切り替え機能があります。これは、リポジトリの構造を変えることなくさまざまな切り口で要求を表現したい場合に有効です。 例えば、機能外要求の分類に注目したい場合には、ツリーを「種類別ツリー」に変更します。＜画面 7＞＜画面 7＞種類別に表示した要求ツリー＜要求管理のプラクティス 2＞ 要求をパッケージで分類する
・ 要求を抽象度によって区別できるようにする
・ 機能要求と機能外要求に分類する

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

11

【実践 3】 トレーサビリティを使って要求を検証する要求管理で広く知られているプラクティスのひとつとして「要求のトレーサビリティ（追跡可能性）」という考え方があります。簡単に言えば、ある要求から他の要求や他の作業分野（設計や実装）の要素に追跡できる状態のことです。トレーサビリティは、ある要求が変更になった際に、他のどの要素に影響を及ぼすかを調べる「影響分析」
や、要望がどのくらい満たされているかを検証するための「カバレッジ分析」を行う際には無くてはならない要素です。
要求の数が増えれば増えるほど要素間の関連は二次曲線的に増加していき、トレーサビリティの管理を手作業で行うことはほぼ不可能になります。また、トレーサビリティの管理は要求定義の期間中だけ行えば良いものではなく、ソフトウェアのライフサイクル全般に渡って実施されるべき作業です。手作業では一定の品質を継続的に実施することが難しいため、継続的に実施できるツールの助けが必要不可欠となります。

ビリトレー
サ

＜前方追跡＞
・要望の充足度評価（カバレッジ分析）
・変更による影響範囲評価

ティ

要求トレーサビリティが管理されている状態

要望要件
仕様

＜後方追跡＞
・修正による影響範囲調査
・適用技術の正当性評価＜図 5＞要求のトレーサビリティ

RaQuest では、トレーサビリティをサポートするための機能をいくつか備えています。影響分析やカバレッジ分析を実現するために、まず要求を登録する時点で、要素間に関係を追加します。そうすることで関係を付与した要求をさまざまなビューから参照することが可能となります。影響分析を行う際には、個々の要求に注目したトレーサビリティを参照するケースが多いでしょう。その際には、「要求の関係を図示」という機能を使って要素間の関係を確認することができます。＜画面 8＞＜画面 8＞要求の関係を図示して影響分析を行う
知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

12抽象度の異なる要求間の完全性を検証する際（カバレッジ分析）には、「トレーサビリティマトリクス」を使うと便利です。トレーサビリティマトリクスは複数の要求の関係をまとめて確認することができる機能です。例えば識別された要望に対して要件が全て洗い出されているかという網羅性の検証では、このマトリクス表示機能を利用することでビジュアルに要求の状態を確認することができます。また、トレーサビリティマトリクスは更新機能も備えている
ため、検証時に新たに関係を追加、削除することができます。＜画面 9＞＜画面 9＞トレーサビリティマトリクスによるカバレッジ分析＜要求管理のプラクティス 3＞ トレーサビリティを使って要求を検証する
・ 要求の関係は要求項目の作成時に付与する・ トレーサビリティマトリクスを使って要求の網羅性を検証する

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

13【実践 4】 要求属性を使って暗黙知を可視化する要求は関係者の視点によって認識の仕方が異なり、それぞれの認識内容も暗黙的です。その暗黙的な認識を、「要求属性」として個々の要求に付加することによって、関係者の立場による感じ方の違いやリスクなどを浮き彫りにすることができます。つまり、要求属性を付与することで、要求間のトレードオフや優先度を客観的に評価するための情報を可視化できるようになるのです。よく利用する要求属性を以下に列挙します。
「優先度」
最も一般的な要求属性であり、多くのプロジェクトで識別されます。この属性は、要求の取捨選択が必要な場合に客観的な判断基準を提供するものであり、要求の妥当性評価を行う際の指標にもなります。

「難易度」
要求を実現（実装）しようとした場合に発生するリスクについて評価するための属性であり、要求をテクノロジの観点から評価した結果が表現されます。

「コスト」
システムのおおまかな規模を把握するための属性であり、個々の要求に対して何らかの指標に基づき計測した規模が表現されます。

「要求安定性」
要求が変化する可能性など内在する潜在的リスクの識別と、その対処が必要となるかどうかの可能性について、個々の要求に対して評価した結果が表現されます。

要求の暗黙知•誰の要求か？
•誰が関係するか？
•背後にある問題は？
•いつ実装すべきか？
•実現できるか？
•どのくらい複雑か？
・・・

要求要求には様々な情報が含まれている要求の状態•承認されているか？
•実装されているか？
•明確になっているか？
•いつ発生したか？
•いつ変更されたか？
•変更されたことがあるか？
・・・＜図 6＞さまざまな要求属性

RaQuest で最も簡単に要求属性を設定するには、デフォルトで準備されている要求属性を使うと良いでしょう。
デフォルトの要求属性には設定する値（高・普通・低などのレベル）もあらかじめ含まれているので、要求属性をカスタマイズすること無く、すぐに要求属性を設定することができます。＜画面 10＞

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

14

＜画面 10＞要求の詳細タブによる属性の設定

実際のプロジェクトでは、要求属性をカスタマイズする必要があるでしょう。例えば、作業量という表現をコストに変えたい、優先度を「A・B・C」で表現したい、新たな要求属性として「代替手段（有・無）」を追加したいなど、カスタマイズの動機と内容はさまざまです。RaQuest では、「ユーザ定義属性」を使って、要求属性のカスタマイズが容易にできるようになっています。＜画面 11、12＞＜画面 11＞ユーザ定義属性の作成＜画面 12＞一覧項目のカスタマイズ

RaQuest では利用したい要求属性の組み合わせをカスタマイズする「一覧項目」設定機能を備えています。例
えば、”要件一覧”には「難易度」という属性を表示したいが、”要望一覧”には表示したくないという場合に便利です。「一覧項目」で定義した要求属性の組み合わせは、パッケージ毎にデフォルトの表示項目として設定します。
また、要求一覧表示後にあらかじめ作成しておいた別の「一覧項目」に変更することもできます。＜画面 13＞

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

15

＜画面 13＞カスタマイズした一覧項目で表示した例＜要求管理のプラクティス 4＞ 要求属性を使って暗黙知を可視化する
・ 要求の暗黙知は要求属性として付与する
・ 要求属性をプロジェクトの特性に合わせる

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

16

【実践 5】 要求の状態でプロジェクトを制御する
実践 4 で紹介した要求の暗黙知を表す要求属性に加え、「要求のステータス」を表す属性も与える必要があります。要求の状態を可視化することで、変化する要求の状態をリアルタイムに把握することができます。要求の状
態を表す主な属性を以下に挙げます。
「ステータス」
個々の要求がプロジェクトにとってどのような状態にあるかを表現する。

「バージョン」
個々の要求とベースラインやシステムのバージョンとを関連づけるための属性であり、要求セットの版管理を行うための仕組みを提供する。

「リビジョン」
個々の要求について変更の履歴を記録する際に付与される属性であり、ツールによって自動的にナンバリングされることが多い。

RaQuest には、要求のステータスを表現するために、個々の要求に「状態」を設定する機能があります。要求の状態に合わせて値を変更できることはもちろん、要求がある特定の状態になると要求に制御がかかる仕組みが連動しています。例えば、「検討済」ステータスにある要求を編集不可としてロックするなど、プロジェクトの運用ルールをツールで制御することが可能になります。＜画面 14＞＜画面 14＞検討済みの要求は編集不可となる

RaQuest では＜図 7＞のような要求の状態遷移を想定していますが、状態の値は他の要求属性と同様にプロジ
ェクトのルールに応じて値をカスタマイズすることが可能です。

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

17

＜図 7＞RaQuest 標準の要求の状態遷移

その他、RaQuest では要求のステータスを表現するために、「バージョン」と「リビジョン」をサポートしています。リビジョンは要求に何らかの変更を加える度に自動的にカウントアップされます。バージョンは、要求セット全体の版管理を行う際に使用するのが一般的であり、RaQuest では、「プロジェクトオプション」として要求セット全体に対する一括変更が可能です。＜画面 15＞＜画面 15＞プロジェクトオプション「状態と初期値」を表示＜要求管理のプラクティス 5＞ 要求の状態でプロジェクトを制御する
・ 要求の状態を監視し記録する
・ 要求の状態を使ってプロジェクトの運用ルールを制御する知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

18

【実践 6】 「プロジェクトスコープ」をベースラインで表現する
要求のベースラインとは、”プロジェクトにおいて実現することが合意された時点での要求の集合（要求セット）”を表します。プロジェクト管理の観点では「スコープベースライン」とも呼ばれます。IEEE Standard Glossary ofSoftware Engineering Terminology ではベースラインは以下のように定義されています。
「正式にレビューされ、合意された仕様あるいは製品。その後のさらなる開発のベースとなり、正式な変更管理手続きによってのみ変更される」要求のベースラインは、要求管理作業分野において最も重要な概念です。ベースラインが存在しなければ、プロジェクトにとって重要な事項である「ユーザに提供する機能の範囲」「スケジュール」「見積り」「変更の基準」の全てが不明確となってしまいます。要求のベースラインを定義しなければ”曖昧な開発範囲の問題”は解決できないのです。

識別された
要
求

実現が合意された要求実現・変更されない要求

ベースライン要求•ユーザに提供する機能の範囲•開発スケジュール立案の根拠•開発コスト見積もりの根拠•変更の基準＜図 8＞要求のベースライン

RaQuest においても、ベースラインの管理機能がサポートされています。プロジェクトの範囲を決定する際に、識別された要求セットをベースラインとしてその時の要求の状態も含めて保存することが可能です。＜画面 16＞
ベースラインは外部ファイルまたはプロジェクトファイルに保存できるので、一度合意した要求セットに変更や追加を検討したい場合などは、まずベースラインを保存するようにします。一度保存したベースラインはいつでも呼び出すことができるので、過去に合意した要求の状態を参照したい場合などに有効です。

＜画面 16＞新規ベースラインを作成する＜要求管理のプラクティス 6＞ 「プロジェクトスコープ」をベースラインで表現する・ 要求にベースラインを設定する
・ ベースラインを常に参照できる状態を維持する

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

19【実践 7】 変更要求管理でベースラインを保守する
要求の変更は、一般的にはプロジェクト期間中いつでも発生してしまうものと捉えられています。しかし、何をもって「変更」と捉えるかによって、その意味は大きく変わります。有期性のあるプロジェクトで変更を捉える場合、何をもって変更とするかという決め事（合意）が必要不可欠となります。要求のベースラインが管理されているプロジェクトでは、ベースラインに対してのみ変更が行われるように制御されるべきです。

当初のベースライン変更されたベースライン

実現が合意された要求実現された要求

ベースライン要求

追加・変更が合意された要求追加・変更要求
実現・変更されない要求＜図 9＞変更されたベースライン

RaQuest では、合意された要求にのみ変更が適用できるようになっており、変更要求を明確に区別するメカニズ
ムを持っています。＜画面 17、18＞ 実践 6 で説明したように、要求が合意された時点で要求の状態を「承認」に変更し、ベースラインを設定しておくことで、それ以降に発生する要求は「変更要求」として別個に扱うことができます。RaQuest における変更要求は、以下のような特徴を持っています。
・ 新規変更要求は、状態が「承認済み」となっている要求にのみ作成することができる
・ 変更前の要求は履歴として保持される・ 要求一覧では変更要求が区別されて表示される＜画面 17＞新規変更要求の作成知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

20

＜画面 18＞要求一覧による変更要求の確認＜要求管理のプラクティス 7＞ 変更要求管理でベースラインを保守する
・ 変更は要求のベースラインに対して行う
・ 変更された要求を区別できるようにする

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

21

4.

まとめ

要求管理のプロジェクトへの導入
これまで紹介してきた要求管理の仕組みを実際のプロジェクトに導入するにはどうするべきでしょうか？
要求管理は、プロジェクト全体に関わるテーマであり、チーム全体に適用して初めて大きな効果を発揮するものです。要求管理を理解している人が個人的に活動してもそのメリットは局所的にしか生かせません。チーム全体にその効果が行き渡るような工夫が必要です。以下に要求管理の仕組みをプロジェクトに導入しチームで有効活用する際のポイントを挙げます。
・ 要求管理を行うことでどのようなメリットが享受できるのかを理解し、チームメンバーで共有する・ 要求管理を行う担当者（可能ならば専任）をプロジェクトに配置する
・ プロジェクト開始時から要求管理の仕組みを導入する

また、要求管理を行う際に RaQuest のような要求管理ツールが有効です。以下に要求管理の仕組みと共に要求管理ツールである「RaQuest」を導入する際のポイントを挙げます。
・ プロジェクトで行う要求管理のスタイルに合わせて、RaQuest で利用する機能を絞り込む
・ 利用する機能について、サンプルデータを使って要求管理を一通り体験してみる
・ 要求属性や状態に設定する値を、プロジェクトの特性に合わせてあらかじめ設定しておく

冒頭で述べたように、要求管理は、プロジェクトの成否に多大な影響を及ぼすテーマであるにもかかわらず、十分にプロジェクトの現場に定着していません。ぜひ本書で紹介したアプローチを参考にして要求管理に取り組んでみてください。きっとプロジェクトに変革がもたらされるはずです。

著 者

紹介

岡 大勝（おか ひろまさ）
日本ディジタルイクイップメント(DEC)や日本ヒューレット・パッカード（現ヒューレット・パッカード・エンタープライズ）で、主に金融機関のシステムアーキテクチャ設計／開発プロセス設計／運用プロセス設計を担当。のちに入社した日本ラショナルソ
フトウェア社では、開発プロセス／オブジェクト指向分析設計手法の導入支援を展開した。2003 年にゼンアーキテクツを設立し、最新の IT 技術のエンタープライズシステムへの適用を推進。2019 年より、株式会社 ZOZO テクノロジーズに入社し、現在に至る。2013 年には、日経 BP 社が選ぶ「日本のトップ IT アーキテクト」の一人として選出されている。著書に「本当に使える開発プロセス」「本当に使える開発プロセス［改訂版］」（共著、日経 BP）、「要求の基本原則」（共著、技術評論社）、訳書に「ディシプリンド・アジャイル・デリバリー」（共訳、翔泳社）がある。

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

22

＜参考＞ 要求管理と RaQuest の効率的な導入
RaQuest のような専門分野に特化したツールを使うには、ある程度の準備が必要になりますが、プロジェクトの開始が目前に迫った状態で（または既に開始している状態で）利用を開始せざるを得ないことも多いのが現実です。このような場合には、RaQuest に付属している各種ドキュメント、開発元（スパークスシステムズジャパン）から提供されている各種サポートサービスや追加ドキュメントを利用することはもちろんですが、有償サービス「RaQuest クイックスタートサポート」の活用も有効です。特に要求管理の工学的な考え方と要求管理ツールを初めて経験される方やプロジェクトにとっては、容易に要求管理を開始できるソリューションとなるでしょう。
＜RaQuest クイックスタートサポート＞

サービス名
対象者

達成目標

RaQuest クイックスタートサポート「要求工学と RaQuest を活用した要求管理」⚫

システム開発プロジェクトにおいて要求定義を担当される方⚫

企業の情報システム部門に所属し、システムの企画をされる立場の方⚫

プロジェクトリーダーやプロジェクトマネージャ、およびその候補者⚫

RaQuest の導入直後のお客様⚫

システム開発における要求の位置付け・重要性と、要求の概念・特性を理解できる⚫

要求プロセスの全体像と作業の進め方を理解できる⚫

要求の一貫性・参照性・追跡性の管理、及び変更管理など要求管理の仕組みを理解できる⚫
詳細 URL

要求プロセスにおける RaQuest の活用方法、作業手順を理解できる

https://www.raquest.jp/service/quickstartsupport.htm

知っていますか？要求管理を確実に行うための 7 つの「実践ポイント」
Copyright(C) 2019 Hiromasa Oka All Rights Reserved.

23