The Rational Edge

要件定義の管理技術（Lv0〜Lv5）

by Jim heumann
Requirements Evangelist
Rational Software

2003/3/13

Maturity：the quality of sound judgment associated with adult humans
（成熟度：成人が持つ正しい判断の質）
--The Wordsmyth English Dictionary／Thesaurus

　「成熟する」とは、大局を見て優れた選択を行うことを意味する。ビジネスの文脈で考えると、以下のようになるだろう。つまり、ビジネスの全体像を把握し、明確に理解していることを前提とした、損失と利益の（微妙な）取捨選択判断を下すことだ、と。

　今回のThe Rational Edgeは、「組織が下すべき判断」と「要件定義管理の成熟度（Requirements Management Maturity：RMM）向上のための作業」との関係について考察する。山を登るときにコスト（エネルギーや時間）がかかるのと同様、IT業界のトップを目指して上っていくにも当然コストがかかる。従って、（企業としての）成熟度を高めるメリットを考えた場合、「時間」「労力」「費用」といった必要投資を無視することはできない。適切な要件定義を遂行するには、莫大なコストがかかるものだ。組織は、そのとき、コストとメリットの取捨選択を迫られることになる。さらに、それを乗り越えた組織が、さらなるRM（Requirements Management）成熟度向上を目指す際に使用する、自動化された要件定義管理（RM）ツールについて、これらが企業の成熟度向上にどのように役立つのかも分析していく。

　Software Engineering Institute（SEI）のCMM（Capability Maturity Model）をご存じの方ならば、CMMとは直接関係がないラショナルのパラレルモデルが、いくつかの類似点を持っていることに気付くだろう（注1）。当たり前のことだが、組織全体のプロセスを完成させるより、要件定義の管理という1つの分野で高いレベルの成熟度を達成する方が容易であることは覚えておいた方がいい。

（注1：ただしRMMのレベル5を達成すれば少なくともCMMのレベル3達成には確実に役立つ）

　ラショナルのRMMがうたう成熟度は、（1）文書化、（2）整理、（3）構造化、（4）記録、（5）統合の5つのレベルに分けられている。いまからこのカテゴリごとに要件定義の管理作業を分類していこう。下のレベル（1）から始めて、レベル5へと進んでいく。

■カオス：要件定義の不在（レベル0）

　前述したRMMの5レベル以外に実は、もう1つのレベルが存在する。要件定義がまったく存在しないレベル0だ。レベル0の段階では、組織が手探りで作業を進め、構築すべきものは理解しているものとして大ざっぱに仮定し、要件定義の未収集によって節約した時間が、将来的に機能の過剰もしくは不足によって浪費されることはない、と決めつけて“冒険”に出てしまう。

　この“冒険”は成功することもあるが、たいていの場合、機能不足の製品、機能過剰の製品、もしくは低品質の製品をリリースするという結果に終わる。欠陥製品のリリースが与える影響は、販売対象となる顧客や（企業の業務システムにおける）当該ソフトウェアの重要度によって千差万別だが、もし深刻な結果を招くことがあれば、再発を防ぐためにも、全組織横断型の「要件定義の実施」（そして並行したRMプロセスの作成）へとつながってくれるかもしれない。

■レベル１：要件定義の文書化

　要件定義の不在というカオスからの脱出へ向けた第一歩は、要件定義を単純に文書化することだ。ただし、ここではホワイトボードや付せんなどに書いたものは含まれない。バックアップや復元のできないメディアはリスクが多きすぎて対象にすることはできない。

　要件定義を文書化すると、いくつかのメリットが明らかになる。

　第1に、顧客と交わす契約書の客観的な基盤ができることだ。慎重に用意した要件定義は、顧客の依頼する開発内容に対する解釈を明確にしてくれる。顧客は、要件定義（の文書）を読むことで、開発内容に同意（もしくはこれを拒否）することができる。

　第2に、開発チームの全員が作業基盤を手にするというメリットがある。開発チームの中には、設計者やデザイナーが含まれている。彼らだけで、顧客の期待にこたえられるシステムの設計については検討を開始できるが、従来は開発の初期作業に参加することのなかったテスターも早期の段階で、テストの手順やスクリプトのベースにできるテストケースの準備を開始できる。

　第3に、開発チームの要員が増強され、新メンバーが続々参加する際に、要件定義の文書があれば、（開発中の）アプリケーションやシステムで想定される機能を理解することが容易になる。文書化された要件定義は、必要に応じてバックアップや復元が可能なため、リスクの低減に向けた大きな一歩となるはずだ。

　ところで、コストについてはどうだろう？ 要件定義の文書化は個人（もしくはグループ）が時間を割いて取り組まなければならない作業だ。そして、開発チームが直接（顧客の）要件を定義するほか、文書化を行う以前の段階として、顧客から要望を聞く話し合いも必要になる。文書の保守作業も時間／費用を消費する。文書は常に最新の状態を保たなければ、要件定義として使いものにならない。さらに、たとえマイクロソフトのWordであれノートパッドであれ、文書保守の担当者は、文書化のために使用した「ツール」の使用方法を習得し、（文書の）更新作業を繰り返さなくてはいけない。

　要件定義の文書化は果たして、ここまでの時間と労力に見合う結果をもたらすのだろうか。この疑問に答えるには、要件定義のための労力を惜しむことによって起こり得る結果とコストをはかりに掛ける必要がある。

　顧客が望むものを開発して提供しなければどうなるだろう？ 機能を搭載し過ぎたらどうなるだろう？ もしこれらの疑問に対する答えが「たいしたことはない」というのであれば問題はない。だが、不適切なシステムを提供することが自社株の暴落や顧客離れにつながるのであれば、この投資は必要なのではないだろうか。

■レベル2：整理

　このレベルまでくると、組織は要件定義の品質、フォーマット、セキュリティ、保管場所、バージョン管理にも気を配ることになる。

　要件定義が目指すのは、提案されたソフトウェアの動作を各方面の関係者に明確に伝えることだ。これには開発チームのほかに、ユーザーや顧客といったそのほかの利害関係者も含まれる。これは大変な仕事であり、うまく実行するのは容易なことではない。だが、うまくまとまった要件定義があるならば、このようなコミュニケーション作業を適切に実行できるだろう。不適切な要件定義ではダメだ。優れた要件定義は要件を規定した人々に理解できるものであると同時に「設計者」「開発者」そして「テスター」も活用できるものだ。レベル2を実現するには、読みやすいだけでなく、明瞭かつテストに適用できるものにしなくてはならない。

フォーマット

　要件定義は効果的にフォーマットされなくてはならない。一貫したナンバリング、ヘッダ、フォント、そして優れた目次があればドキュメントが読みやすく、理解しやすく、そして活用しやすくなる。うまくまとまった要件定義でもフォーマットが悪ければ使いものにならない。フォーマットそれ自体は単純なことだが、要件定義を「終わらせる」ことを急ぐあまり、見落とされることが多い。文書のテンプレートや、要件定義文書向けのシンプルなフォーマット基準も有効だ。

利便性、セキュリティ、バージョン・コントロール

　要件定義文書が見つからなくてイライラしたことはないだろうか？ レベル2では、集中管理が可能で、だれにでも分かり、関係者全員がアクセスできる保管場所が要件定義文書向けに必要である。セキュリティについても考えたい。ファイルシステムのシンプルなセキュリティ機能を使用する場合でも、また一段と洗練されたテクニックを活用する場合でも、要件定義の整合性を確実にするためには、許可を受けた者にしか要件定義文書を修正できない制限をかけることが必要だ。
　
　さらに、バージョン・コントロールを導入することは、最新バージョンで作業していることを常に把握できるため、時間の節約とイライラの回避につながる。さらに、誰がどのような理由で変更を加えたのかを常に把握できるようになる。

　レベル2のメリットは、レベル1のメリットを自動的に強化することにつながるため、上記の項目だけにはとどまらない。要件定義文書が一層読みやすく、理解しやすい（そして信頼できる）ものとなれば、顧客との契約に向けて、一段と優れた交渉の根拠が獲得できる。開発チームにとっては、要件定義が利用しやすくなる。さらに、新たに加わるスタッフは、短時間でこれまで蓄積されてきた作業を把握できるようになるのである。

　要件定義の管理レベルをレベル2へ進めるためのコストの大半は、要員の「トレーニング」と「審査」にかかってくる。品質の高い要件定義文書を書くのは簡単なことではない。スキルの高いアナリストがすでに参加しているような幸運でもなければ、チームに対してトレーニングを実施しなくてはならないのだ。また、一定の成熟度に達し、それを維持するには、定期的な要件定義文書の審査とある程度の「プロセス強化」作業が必要となる。これらの付加的作業には非常に時間がかかるものだ。

　もちろん、このようなコストは、要件定義が正しい姿で管理されていれば、修正作業の減少や顧客による評価の改善などを確認できるという明確なメリットによって埋め合わせることができる。一度で適切な仕事をしなくてはならないのであれば、それだけのコストをかける価値があるだろう。

■レベル3：構造化

　レベル3へ進むには、収集する要件定義の種類をもっと具体化する必要がある。機能的なことか、機能以外のことか。業務的なことか、システム的なことか。仕様なのか、ソフトウェアの要件定義なのか。顧客、マーケティング担当者、ユーザーのそれぞれの要件定義は、など関係者間での切り分けが、要件定義の理解とよりよい対応に役立つ。レベル3へ進むということは、基本的なテキスト以外に、要件定義そのものに関する情報を追加することも意味する。この追加情報とは要件定義の管理と報告の作業を大幅に改善するのに役立つ「条件」という形で提供することができる。

種類の整理

　予想されるさまざまな要件定義を考えながら、特に2つの問題を考えていただきたい。最初の問題は、種類の異なる要件定義の切り分けを行わない場合に発生する。
　
　既存の要件定義文書で、分類を示すものがなく個々の要件定義が単純に数多く羅列されているだけという場合、当然ながらさまざまな種類のものが混在してしまっている可能性が高い。例えば、「サプライヤのヘルプデスクは、チケットトラブルの90％に4時間以内で対応すること」といった要件定義もあれば、「システムにとって必須条件である自動チェックをサポートすること」という、まったく「種類」の異なる要件定義が同列に配置されている場合がある。

　これらの要件定義はいずれも正当だが、それぞれが明確に異なる問題を念頭に置いたものだ。最初の要件定義は、ソフトウェアベンダのサポート組織向け要件定義であり、2番目の要件定義は、ソフトウェアの機能に関する仕様だ。種類を示すものがない場合、大量の要件定義が混乱を生み、読む側の時間を無駄にすることにつながる。ソフトウェアの要件定義を求めている人々にとっては、サポート向けの要件定義は邪魔な存在だし、その逆でも同様のことがいえる。また、ソフトウェアの要件定義だけを示すようなレポートの印刷も困難になる。

　2番目の問題は、要件定義の種類を用意しながらも、それらに持たせる意味に整合性がない場合、発生する。要件定義を必要とするチームメンバーに、さまざまな要件定義の種類を定義させると面白い。解釈の仕方がさまざまであることに驚くかもしれない。ある「ユーザー要件定義」が「自分の仕事のために、将来のシステムが実現しなくてはならないとエンドユーザーが考えるビジネスニーズ」と定義されたかと思うと、一方で「ユーザーの操作性のための要件定義」と定義される場合もある。これは明らかに問題だ。

属性

　ここで、レベル3におけるもう1つの機能である、要件定義の属性の概念について考えてみたい。要件定義はすべてが平等なわけではない。ほかより重要なものもあれば、永続的なものもあり、ものによっては対象とするリリースが異なる場合もある。このような状況は常に把握しておくことが重要だが、属性を付加することでそれが実現可能になる。属性には、要件定義の文書を補完する情報や要件定義の理解を助け、利用しやすくする情報などがある。

　しかし、どうやって必要な属性情報を見分ければよいのだろうか？ その方法は、要件定義情報を利用する人のニーズに依存する。よく犯す間違いの1つが、別のプロジェクトや要件定義管理ツール（Rational Requisite Pro付属のものなど）で、あらかじめ定義された一連の属性をむやみに使うことだ。プロジェクトのテンプレートは出発点としては素晴らしいが、ニーズに合わせて修正を加える必要がある。そうしないと、不要な属性が負担となってのしかかり、本当に必要なものが多数割愛されてしまう可能性がある。
　
　さまざまなアナリストに要件定義を割り当てるような大規模プロジェクトでは「所有者」の属性が非常に便利だが、この属性は1人がすべての要件定義を「所有」する小規模プロジェクトでは理にかなわない。必要な属性を理解するためには、要件定義がどのように利用されるのかを理解する必要がある。サポートをするためにどのような報告や照会が必要になるか？ どのような基準を維持しなくてはならないのか？ これらの疑問に対してあらかじめ答えを用意しておけば正しいスタートを切るのに役立つだろう。

　レベル3まで進むメリットは、要件定義に対する理解度が深まり、管理がしやすくなるといったことが中心になる。優れた構造の要件定義は、異なる種類の要件定義を明確に特定してくれるし、属性は要件定義グループの問い合わせや選別を可能にしてくれる。これはつまり、チームメンバーが、自分たちの責任範囲や作業を特定するための手掛かりを探す作業が著しく減ることを意味する。要件定義をうまく分類することで、チームが重要な要件定義をすべて割り出したというさらなる確信につながるのだ。
　
　一方、レベル3へと進んだときの最大のコストは、「計画」と「保守」だ。適切な要件定義の種類と属性を判断するのはそう簡単な作業ではない。それ自体が小さなプロジェクトであり、各要件定義のユーザーに話を聞いて必要なものを判断する作業が発生する。通常、この情報は要件定義管理計画（RMP）の中で入手する。そして、要件定義の属性は常に最新でなければあまり役に立たないため、レベル2以上では保守という負担が発生する。また、正しい属性を判断するには時間がかかるため、コストも増加する。組織がレベル3に進むと、たいていは、要件定義管理ツール（Rational Requisite Proなど）を使い始めることになる。これらのツールは、購入、更新、そして管理に要するコスト以上の大きなメリットを提供してくれる場合が多い。

■レベル4：記録

　これまでの3つのレベルを組織に導入すれば、各要件定義の関係を判断し、トラッキングできるところまでくるだろう。ただ、複雑なシステムには、階層化された要件定義が付きものだ。システムエンジニアリングの環境では、階層はまず、メインシステムの要件定義から始まり、サブシステムの要件定義へ下りて、プログラムの要件定義、そしてエレメントの要件定義へと進む。RUP（Rational Unified Process）の手順では、この階層がユーザーのニーズから始まり、ユーザー機能へと進み、それからユースケースへ進む。これらの関係をトラッキングすることは、一般にトレーサビリティと呼ばれ、階層での要件定義の「“導出経路”（上方向）とアロケーション／“深耕経路”（下方向）」特定、「文書化」が必然的に伴う。トレーサビリティは、ある要件定義に対する変更が別の要件定義に与える影響を理解（インパクト解析）できるようにしてくれる。また、要件定義が完全にそろっているかどうかの判断（カバレージ解析）にも役立つ。

　レベル4に進む組織は通常、プロジェクトの開始前に明確なトレーサビリティ戦略を作り出し、それを要件定義管理計画の中で文書化する。この戦略で要件定義のレベルと、そのレベルをいかに階層の中に当てはめるのかを定義する。さらにこの戦略は、要件定義関係の「ルール」もいくつか規定することになる。例えば、「ユーザーニーズ」にはそれぞれ少なくとも1つの「ユーザー機能」がなくてはならず、各ユーザー機能には、それぞれ少なくとも1つのユースケースがなくてはならない、といったルールが考えられる。このような要件定義管理プロセスを導入すると、前述したような洗練されたレポート機能が完成する。

　カバレージ解析レポートは、ハイレベルの要件定義それぞれにローレベルの要件定義が付随しているかどうかを示してくれる。その結果、カバーされていないものがないかどうかを判断しやすくなるだろう。例えば、ユースケースが伴わないユーザー機能があった場合、完成したソフトウェアは機能が不足しているかもしれない。また、ユーザー機能が伴わないユースケースがあった場合は、ビジネス的に価値のない機能を組み込んでいるのかもしれない。

　インパクト解析レポートは、変更点の管理を主な目的としている。ある要件定義に対する変更が、ほかの要件定義にどのような影響を与える可能性があるのかを明確に示し、変更の正当化もしくは阻止を格段に容易にしてくれる。例えば、誰かがユーザー機能を変更しようと考えた場合、その変更が複数のユースケースに対する変更を余儀なくさせる（そしてプロジェクトのスケジュールを遅らせる）ことがインパクト解析レポートによって明らかになれば、ユーザー機能の変更に関して、コストとメリットをはかりに掛ける作業が容易になる。

　要件定義をトレースした場合のこれらのメリットは大きいが、ここにもコストがかかってくる。トレース関係の入力や保守に要する労力は並大抵では済まない。カバレージ／インパクト解析レポートの定義、作成、分析は時間と労力を要するのだ。プロジェクトの規模が小さければ、要件定義のトレースはWordやExcelで簡単なテーブルを使って手作業で行うこともできるが、複雑なプロジェクトでは「Rational Requisite Pro」のような要件定義管理ツールが必要になる。このようなツールを使うメリットはかなり大きいが、先に述べたようにツールの購入、保守、そしてトレーニングの実施にはコストが伴う。

■レベル5：統合

　ソフトウェアが想定する機能について顧客の同意を得るべく最初に要件定義を活用する場合が多いが、通常このような要件定義は、ソフトウェアの開発方法とはあまり結び付かない。そして流れに取り残され、目的を達成しない要件定義やソフトウェアが完成してしまう。レベル5まで進むということは、要件定義管理プロセスと残りのソフトウェア開発環境との統合を意味する。それは要件定義をソフトウェアデザイン、変更管理、テスト、そしてプロジェクト管理の中で直接利用することを意味するのだ。

　顧客の期待どおりに機能するソフトウェアは、要件定義を満たすように開発されている。つまり、チームのソフトウェア開発プロセスが要件定義を重要な入力情報として利用していることになる。システムの設計者やデザイナーは、プロセスに従うことでデザインの中にすべての要件定義が確実にインプリメントされるようにする。RUPはユースケースを分析とデザインのために入力する情報として扱うことでこれを実現している。

　要件定義を変更管理プロセスに統合することは、要件定義の変更に検査や承認を必須とすることにつながる。既存のものや新しい要件定義にそれぞれの変更要求を関連付けることは、不用意なユーザー機能の追加を制限するのに有効だ。

　要件定義に基づいたテストは、ソフトウェアの目的達成を検証するためにも重要な部分だ。デザイナーがシステムをデザインするために要件定義を利用しなくてはならないように、テスターもこれらをテストケースなどのテスト用成果物作成のために利用しなくてはならない。

　要件定義は、開発プロセス全体の基盤となるため、プロジェクトマネージャは、要件定義に対するプロジェクトのステータスを直接チェックできなくてはならない。これには新しい要件定義、インプリメントされた要件定義、要件定義テスト、そして要件定義変更要求に関する基準が含まれる。

　ここで説明した、総合的で要件定義をベースにしたソフトウェア開発プロセスには、長期的な計画の存在、トレーニングの繰り返し、そしてプロセスの強化が必須である。ソフトウェア開発ツールもこのようなプロセスのインプリメントにとっては重要な部分だ。「Rational Rose」や「Rational XDE」のようなビジュアルモデリングツール、「Rational Clear Quest」のような変更管理ツール、「Rational Requisite Pro」のような要件定義管理ツール、そして「Rational Project Console」のようなプロジェクト・ステータス・レポートツールは、どれもRM成熟度の最も高いレベルに組織が到達できるような力を大幅に強化してくれる。繰り返すが、これらのツールには明確なメリットがあるものの、購入、保守、そしてトレーニングのためのコストもかかってくる。

■要件定義管理ツールのサポート

　これまで説明してきたことはすべて、手作業、もしくはワードプロセッサやスプレッドシートなどの汎用ツールを利用することで実現可能だ。そして、それで十分レベル5まで到達できる。しかし、レベル2からは、RMツールを使うことで大幅に効率的かつ確実にすることができるだろう。ここで、「Rational Requisite Pro」のユーザー機能が、5つのRM成熟度それぞれの重要なポイントをどのようにサポートするのか表に示す。

Rational Requisite Proのユーザー機能	成熟度
Microsoft Wordと要件定義データベースとのダイナミックな統合	1 --文書化 2 --整理
セキュリティの高い一元管理要件定義レポジトリ	2 --整理
ユーザーセキュリティ	2 --整理
要件定義の変更履歴	2 --整理
Webインターフェイス	2 --整理
要件定義プロジェクト用テンプレート	3 --構造化
ユーザー定義要件定義タイプ、要件定義属性、ドキュメントタイプ	3 --構造化
要件定義属性およびクエリ機能	3 --構造化
要件定義のトレーサビリティとカバレージ解析	4 --記録
要件定義変更の影響	4 --記録
各種ソフトウェア開発ツールとの統合	5 --統合
表：Rational Requisite ProによるRMMレベルのサポート

■RUPによるサポート

　これまで説明してきた5つのレベルは、要件定義管理プロセスすべてを包含している。プロセスは、誰が何をするのか、いつするのか、そして何が出来上がってくるのかを判断し文書化する。プロセスをどうするのか判断し、それを文書化するには時間と労力が必要だ。組織は、分かり切ったことをわざわざ一からやり直すようなことをせず、自社のニーズに適した標準プロセスを導入すればリソースを節約することができる。例えば、RUPはいくつかの法則に分かれているが、その1つが要件定義法だ。この法則を見れば、ここで説明した多くの概念の詳細が示されたワークフローが含まれていることに気付くだろう。まずRUPを利用すれば、組織はRMの成熟度向上に向けて幸先のよいスタートを切れるようになる。

■評価と前進

　これまでの本稿の目的は、要件定義管理作業の成熟度に合わせて、組織が導入し、一段と洗練度を高めるための最優良事例について説明することだった。ここまで説明してきた5つのレベルは、自社を評価し、自社がどのレベルにあって、何を改善しなくてはならないのかを理解するためのフレームワークを提供してくれるはずだ。また、要件定義管理のさらに上の成熟度を目指す場合のメリットとコストを理解する方法も示してくれるはずである。

本記事は「The Rational Edge」に掲載された「The Five Levels of Requirements Management Maturity」をアットマーク・アイティが翻訳したものです。

IT Architect 連載記事一覧