The Rational Edge

プロジェクトの特性に合わせた要件定義手法の選択

Dean Leffingwell
Software Entrepreneur and
Former Rational Executive

2002/8/10

---

　ソフトウェアの開発チームは、最良の方法による最良のソフトウェア開発を望んでいる。この要求を満たすため、多くのソフトウェア開発企業では、ラショナルソフトウェアの“Rational Unified Process”（RUP）に代表される、標準的なソフトウェア開発のプロセスを採用している。開発プロセスは、アプリケーション開発のガイドラインや市場で評価されている手法を盛り込んだ実践的な方法論の集積である。例えばRUPはユースケースをはじめとする各種要件定義のテクニックを適用することで、製品が実現しなくてはならないユーザーニーズの理解を助け、開発チームが適切にソフトウェアを構築できるよう支援してくれる。さらに、RUPをはじめとする最新のソフトウェア開発プロセスは、反復性や成長性もソフトウェアライフサイクルの手法として規定しており、融通の利かない「ウォーターフォール」プロセスのアプローチよりも、開発作業に付随する固有のリスクに対し、効果的に対応する。

　技術や規模、関係者のスキル不足、無理な見通しやスケジュールの問題、健康上もしくは安全上の潜在的問題など、リスクはプロジェクトのさまざまな場所に潜んでいる。これまでの経験から、ライフサイクルの初期段階でこれらのリスクに対応することがプロジェクトを成功へと導く重要な要因であることは何度も証明されてきた。それを成し遂げるのに非常に効果的な手法の1つが要件定義なのである。

効果的な要件定義の実践によるリスクの緩和

　 “Managing Software Requirements： A Unified Approach”（*1）の中で私と共著者のDon Widrigは、開発チームがソフトウェアの要件定義を効果的に管理できる実践的な手法について解説した。現在は、チームで開発を進めるシステムが極めて複雑なものとなり、コードが数十万あるいは数百万行に、開発規模が数十から数百人／年にもなる場合がある。そのため、要件定義自体が極めて複雑なものになりがちなのも理解できる。要件定義の効果的な管理には多種多様なテクニックやプロセス（まとめて「要件定義の規律」とする）が必要になってくるのである。

　だが、顧客の問題を解決する実働コードを提供するというソフトウェア開発の目的を忘れることのないようにしなければならない。われわれはソフトウェアライフサイクルの中の要件定義規律が、結局ただ1つの理由のためだけに存在することを常に思い出す必要がある。要件定義に関する問題の解決は、プロジェクトの成功を妨げるリスクを緩和することにある。もしこのようなリスクが存在しないのであれば、コードを直接書き、要件定義まわりの作業に関連するオーバーヘッドを排除する方がはるかに効率的だろう。従って、チームが要件定義手法を選択する場合、それが自分たちの環境に固有のリスクを反映したものでなくてはならない。われわれが著書の中で説明している要件定義のテクニックや、RUPで推奨している方法は、複数の要件定義に関するリスクに対応する目的で開発されたものなのである。下記の表は、要件定義のテクニックと、テクニックが緩和するリスクの特徴、種類を概説している。

テクニック	対応するリスク
インタビュー	・真の利害関係者が誰であるかを開発チームが理解していない場合がある ・1人もしくは複数の利害関係者の基本的なニーズをチームが理解していない場合がある
要件定義のワークショップ	・特定ユーザーの各種ニーズにシステムが適切に対応していない場合がある ・重要な利害関係者間の意見の不一致が要件への収束を妨げる場合がある
ブレインストーミングとアイデアの絞り込み	・重要なニーズや期待の持てる革新的機能をチームが見いだせない場合がある ・優先順位がうまく確立されておらず、機能の多さが最も重要な「必須機能」を分かりにくくしてしまう
ストーリーボード	・期待されるインプリメンテーションが的外れなものとなる ・アプローチそのものが非常に難解で、計画されたインプリメンテーションの中で事業の業務目的が見失われる
ユースケース	・ユーザーが、自分たちはインプリメンテーションプロセスに関係がないと感じる場合がある ・一部機能の欠落があったり、粗末なユーザビリティもしくはエラー／例外処理のため、インプリメンテーションがユーザーの基本的なニーズを満たせない場合がある
ビジョンドキュメント	・自分たちがどのようなシステムを構築しようとしているのか、もしくはこれがどのようなユーザーニーズや業界の問題に対応するのかを開発チームがよく理解していない ・長期的視野の欠如が、計画やアーキテクチャ／デザインに関する判断の低下を引き起こす
製品計画の全容	・広範な普及に必要な商業的要素がソリューションに欠けている場合がある
適用範囲の設定	・プロジェクトの適用範囲が与えられた時間や資源を超過してしまう
追加仕様	・開発チームが機能的な要件以外のプラットフォーム、信頼性、標準といったものを理解していない場合がある
ユースケースからインプリメンテーションまでのトレース	・ユースケースを記述できても、システムに完全にインプリメントできない場合がある
ユースケースからテストケースまでのトレース	・ユースケースをテストできない場合があったり、代替機能や例外条件が理解、インプリメント、およびテストできない場合がある
要件のトレース	・重要な要件定義がインプリメンテーションから見落とされる場合がある ・本来の要件で必要とされていない定義や機能がインプリメンテーションで採用される場合がある ・要件定義の変更が予想外の形でシステムのほかの部分に影響する場合がある
変更管理	・新しいシステム要件定義が勝手に採用される場合がある ・変更によるマイナス面の影響をチームが過小評価する場合がある

正しい要件定義手法を選択するための4つの原則

　Alistair Cockburnはアジャイルな（Agile：小回りの利く）開発について書いた著書の中で、手法の設計と評価に適用する4つの主要原則を明らかにしている（*2）。

1. 直接会ってやりとりをするコミュニケーションこそ最も安価で高速な情報伝達経路である
   
2. 行き過ぎた手法の負担は犠牲が大きい
   
3. 規模の大きいチームには相応の手法が必要である
   
4. 形式にこだわるのは重要度の高いプロジェクトだけでよい
   

　特定のプロジェクト環境に適応する正しい要件定義手法を選択するための原則を簡単に考察してみる。

■第1の原則：
直接会ってやりとりをするコミュニケーションこそ最も安価で高速な情報伝達経路である

　顧客やユーザーから要件定義の情報を聞き出すにしろ、その情報をチームに伝達するにしろ、直接会ってコミュニケーションを取るのが最良かつ最も効率的な方法だ。顧客とチームとの距離が近く、ダイレクトにコミュニケーションが取れるならば、顧客は要件定義をチームに直接説明できる。また、アナリストが直接、顧客やチームとコミュニケーションを取れるなら、必要な書類も少なくて済む（ただし重要な要件定義については文書化する必要がある）（*3）。そうでない場合、「開発中のものについては全員が理解している」との暗黙の仮定がプロジェクトチームにとって最大のリスク要因となる危険性がある。ただし、チームが必要性の高い最小限の書類（ビジョンドキュメント、ユースケース、追加仕様など）だけで作業を進めることも確かに可能であり、簡潔なものでも構わない場合もある。

■第2の原則：
行き過ぎた手法の負担は犠牲が大きい

　この原則は「成功に必要なことだけをする」という意味に理解していただきたい。不要なプロセスや成果物はどれもがチームの作業スピードを落とし、プロジェクトに負荷を与え、絶対不可欠なコーディングやテスト作業に費やすべき時間やエネルギーを奪ってしまう。チームはコストや要件定義の負荷と前述の表に記されたリスクとのバランスを取る必要がある。もし特定のリスクが存在せず、発生の可能性も低い場合は、対応する成果物や作業をプロセスから排除することを検討すべきだ。その一方で、成果物を特定のプロジェクト中のリスクに見合った「軽い」ものにする方法についても考えたい。要約したユースケースを記述し、要件定義に対する成果物についての調査を削減する方法もある。

■第3の原則：
規模の大きいチームには相応の手法が必要である

　その道の専門家で、顧客とすぐにコミュニケーションの取れる3人のデベロッパによって構成されるチームに適切な手法と、分散した5カ所を拠点として統合製品群の開発をする800人構成のチームに適切な手法は、完全に異なる。要件定義手法はチームやプロジェクトの規模に応じて調整する必要がある。しかし、負荷の大きな手法はどのような規模のチームにとっても効率の低下につながるため限度を超えてはいけない。

■第4の原則：
形式にこだわるのは重要度の高いプロジェクトだけでよい

　プロジェクトの重要性は手法の負荷を決定する際の最大の要因かもしれない。例えば、2〜3人のコーディングチームで心臓ペースメーカーの外部プログラミングデバイス用ソフトウェアを開発するのは、実現の可能性がかなり高い。作業は、その分野の専門知識を有し、インプリメントしなくてはならないアルゴリズムを正確に説明できる臨床専門家と素早くコミュニケーションが取れる開発チームによって進められることになる。しかし、このようなプロジェクトでは、ほんのわずかなミスも容認しがたい。従って、ユースケース、アルゴリズム、信頼性に関する要件定義について記述する中間成果物は極めて詳細に文書化する必要があり、「適切な」認識だけが最終的なインプリメンテーションに反映されるよう必要に応じて見直しや審査を行わなくてはならない。このような場合、規模の小さなチームには細かく記述された手法が必要になる。裏返せば、大規模なチームを投入するだけの規模ではなく、重要性も低いアプリケーションについては、簡単な手法を採用できる可能性が高いということである。

ドキュメントは目的を達成するための手段である

　要件定義プロセスの成果物、ビジョンドキュメント、ユースケースなどの大半（実際のところソフトウェア開発における一般的な成果物の大半）にはコード以外の何らかのドキュメントが必要になる。これらのドキュメントが、絶対不可欠であるコーディングやテスト作業に費やす時間を奪ってしまうことを考えると、だれもが「本当にこのドキュメントを用意する必要があるのだろうか？」との疑問を抱いて当然である。

　だが、次の4つの基準のうち1つでも当てはまる場合、そのような疑問に対する答えは「イエス」なのだ。

1. ドキュメントは、シンプルな口頭によるコミュニケーションが不可能な場合（大規模で分散したチーム間のコミュニケーションを考えてみよう）や、プロジェクトのリスクが非常に高い場合（ペースメーカーのプログラミングデバイスの場合など）に、重要な認識や取り決めを伝達してくれる
   
   
2. ドキュメントがあればチームに新たに加わったメンバーが、より短時間で作業を理解できるようになり、既存のチームメンバーも新メンバーも一段と効率的になれる（*4）
   
   
3. 改訂、保管など、ドキュメントそのものへの長期的な投資は、開発やテスト、メンテナンスで継続されるプロジェクトの場合、明らかに価値がある。例えばユースケースやテストケースの成果物は将来的なリリースの回帰テストで繰り返し利用される
   
   
4. ドキュメントには企業、顧客、もしくは規制の基準によって要件が課されている
   

　 要件定義手法に特定の成果物を組み入れる際、次の2つの質問についてチーム内で自問自答したい（その答えは文書化しなくても構わないのでご安心を）。

• このドキュメントは先の4つの基準を1つ以上満たしているか？満たしていなければ省いてよい
• ニーズを満たすのに最低限どの程度の特異性を持たせるべきだろうか？プロジェクトが要求レベルに満たない場合は、採用をやめるか省略したものを採用する
  

　これらの考え方を踏まえながら、特定のプロジェクトで効果的なアプローチを複数定義する作業に話を移そう。すべてのプロジェクトが同じスタイルであることはなく、完全には同構造ではないことは当然分かっている。1つのプロジェクトの中に一連の非常に重要な要件定義やサブシステムが、重要度の低い多数の要件定義やサブシステムと一緒に盛り込まれている場合もある。リスクを管理するため、要素ごとに異なる手法が必要になる。従って、どのような場合においても混在や組み合わせが必要になってくるが、いくつかの重要なアプローチを選択するに当たってはガイドラインを用意することが可能だ。

手法について覚えておくべき3つのポイント

開発手法導入の目的はプロジェクト固有のリスクを緩和することである 要件定義を行う目的は、プロジェクトの要件定義関連のリスクを緩和することである どのプロジェクトにも適用できるような手法は1つもないので、要件定義の手法は特定のプロジェクトに合わせて用意する必要がある

エクストリーム要件定義手法 （An Extreme Requirements Methods）

　ここ数年、Kent Beckが提唱する「エクストリームプログラミング（XP）」（*5）のコンセプトがある程度の人気（そしてかなりの悪評と論争）を呼んでいる。このトレンドがなぜ巻き起こったかは想像がつく。おそらくは、効率化の進む市場で、避けることのできない時間に対するプレッシャーへの反動か、効果的手法をあまりにも熱心に適用してしまうことへの反動だと思われる。あるいは自分たちが得意とするコーディング作業を進めるためにも関与しないでほしいというソフトウェアチームの願望に対する反動かもしれない。いずれにせよ、XPによってソフトウェア業界に「流行」が生まれ、今度はアジャイルな（小回りの利く）要件定義の手法を採用する動きがエクストリームアプローチにバランスと現実味を与えようとしている。XPのいくつかの鍵となる特徴を指摘した後で、XPと互換性のあるエクストリーム要求定義手法をどのように定義したらいいのか、分析してみる。以下の1〜6はXPを構成する代表的な特徴である。

1. 3〜10人のチームでコーディングできる規模のアプリケーション／コンポーネント開発であること
   
   
2. 1人以上の顧客がサイトに常駐して要件定義の情報を常時提供してくれること
   
   
3. 開発はビルド（もしくはバージョン）を細かく区切って進められ、それぞれがリリース可能な状態になっている。ユーザーには段階的に機能を提供できる
   
   
4. 要件定義の収集は、ユーザーに価値を提供する機能のまとまりである「ユーザーストーリー」を使う。ユーザーストーリーはサイトに常駐する顧客が用意する
   
   
5. プログラマは2人1組（ペアプログラミング）で作業を進め、厳密なコーディング基準に従う。各自にユニットテストを実施し、デザインをシンプルに維持すべく絶えずコードのリファクタリング（デザインの見直し）を行うことが求められる
   
   
6. 将来の要件定義の理解や文書化に関してはほとんど手つかずであるため、変化するユーザーニーズに対応すべくコードは常にリファクタリングを行うこと
   

　１カ所で作業を行う小規模のチームで進行可能なプロジェクトがあると仮定する。さらに、顧客が開発期間の大半にわたってサイトに常駐できるとの仮定も現実的だとする（正直なところわれわれが目にしてきた大半のプロジェクト環境ではあまり現実的ではない条件だが）。さて、ここで要件定義手法の観点からXPを考えてみよう。

　早期かつ継続的にユーザーからフィードバックを得ることは、要件定義手法にとって基本となるポイントである。この観点から見た場合、XPはあまりエクストリーム（究極）だとは思えない。

XPの原則	緩和される要件定義リスク
アプリケーションやコンポーネントの開発規模が、1カ所に集まった3〜10人のプログラマによってコーディングできるような範囲内に収まる	コンスタントに交わされる簡単な会話が要件関連の書類を最小限に抑えるか、もしくは排除してくれる
1人以上の顧客がサイトに常駐して常時、要件定義の情報を提供してくれる	コンスタントに行われる顧客からの情報提供やフィードバックは要件関連のリスクを劇的に削減してくれる
開発がビルド（もしくはバージョン）を細かく区切って進められ、それぞれがリリース可能な状態になっていて、ユーザーには徐々に多くの機能が提供される	顧客にとっての価値を計るフィードバックがほぼ即座に入手できれば方向性が大きくずれることはない
要件定義の収集には、ユーザーに価値を提供する機能のまとまりである「ユーザーストーリー」を使う。ユーザーストーリーはサイトに常駐する顧客が用意する	ユースケースは「ユーザーに価値を提供する一連のイベント」のことだ。ユーザーストーリーとユースケースはそれほど大きく異なるものだろうか？もしユーザーが双方に貢献するのであれば、ユースケースとユーザーストーリーに大きな違いはないでは？

　これらの背景を念頭に置き、XPのプロセスを反映もしくは支持するシンプルで明確な要件モデルを導き出すことができるかどうか見てみよう。これはおそらく図1のようなものになり、次のような特徴を持つことになる。

図1　エクストリーム要件定義手法のモデル

　コンセプト：製品コンセプトはすべての要件定義プロセスの中心である。この場合、コンセプトは顧客からプロジェクトチームに（口頭で頻繁に、そして担当者が代われば繰り返し）直接伝達される。

　ビジョン：“Managing Software Requirements:A Unified Approach”（*6）やRUPの中で説明されているように、ビジョンは短期的、長期的な製品のコンセプトを伝えてくれる。「デルタビジョンドキュメント」は、一般的に特定のリリースにインプリメントされる新機能やユースケースについて記述しているが、XPではこのドキュメントが存在しない場合がある。われわれは、現在そして将来、製品に何が求められるかを伝えてくれる顧客の力に頼っており、開発チームが適切なアーキテクチャ上の判断を現時点で（将来も）下してくれることに頼っている。顧客や開発チームからのビジョンの提示という機能が実際に行われるかどうかは、プロジェクト中の多数の要因と、チームが進んで負うであろう相対的なリスクに左右される。少なくともいくつかのプロジェクトのシナリオについては、必ず機能しなくてはならない（*7）。そこで、この成果物は、今、われわれが検討しているエクストリーム要件定義手法から割愛する。

　要件：われわれの著書やRUPで提起するもう1つの非常に重要な条件は、ユースケースモデルが機能要件の大部分を伝えてくれるというものだ。これは、だれがシステムを使用し、自分たちの目的を達成するためにどのように使用するのかを記述している。XPではユースケースとあまり違わないものの、これよりかなり簡潔な「ストーリー」の使用を推奨している。しかしわれわれとしては、インプリメントされる重要なユーザーストーリーやインプリメントを行うユーザーのタイプについては、グラフィックスを使用せずに要約したシンプルなものであっても、常にユースケースモデルを用意することを推奨する。このユースケースモデルを用意することは、われわれが検討しているエクストリーム要件定義手法でも強く求められる。

　追加仕様／機能以外の要件：XPには追加仕様／機能以外の要件の項目に取って代わる明確なものはないが、それはおそらくこれらがあまり多くないか、言及しなくても理解されるとの考えなのかもしれない。もしくは、顧客がこれらの要件定義をプログラマに直接伝達しているのかもしれない。危険な感もあるが、プロジェクトのこの部分にリスクがないのであればそのままで構わない。この成果物もわれわれが検討しているエクストリーム要件定義手法からは割愛する。

　ツール：XPのツールは、ホワイトボードと、項目別のユーザーストーリーや優先順位を持つスプレッドシートなどのデスクトップツールを指す。しかし、不具合は必然的に発生するだろうし、XPがツールに関して細かく規定していなくても、これらのストーリー（ステータスのほか、将来の機能拡張で排除しなくてはならない不具合）をすべてトラッキングする何らかのトラッキングデータベースを追加できると仮定したい。

　これらのシンプルなドキュメント、作業、およびツールによって、やや極端でも適切な環境で機能するエクストリーム要件定義手法を定義してみた。

アジャイル要件定義手法 （An Agile Requirements Methods）

　エクストリーム要件定義手法ではうまく機能しないプロジェクトが登場する場合がある。例えばこんな場合にはどうするのか？

　もし現場で顧客を探し出せなかったら？ 現時点では顧客が存在しないような新しい種類の製品を開発している場合は？ コンセプトがあまりにも革新的すぎて顧客が実現するストーリーをイメージできなかったらどうするのか？ あなたが構築したシステムを他の新しいシステムや、既存の別のシステムと統合しなくてはならない場合はどうする？ 10〜20人の人員がどうしても必要なら？ システムがあまりにも複雑で「システムによって構成されるシステム」（各システムがほかのシステムに対して要件定義を課している）として考えなくてはならない場合はどうだろう？ チームの中にリモートサイトで作業をしなくてはならないメンバーがいたら？ 潜在的な障害状態の一部が経済的に容認できない場合はどうすればいいのだろうか？

　このような場合には、プロジェクト環境で発生する新たなリスクにも対応できる一段と堅牢な手法が必要になる。そして、それが図2に描かれているアジャイル要件定義手法である。

図2　アジャイル要件定義手法のモデル

　コンセプト：アジャイル要件定義手法でも、依然としてプロジェクトの根本は製品コンセプトであるが、このコンセプトは要件定義作業や見込み客へのインタビューなど、多数の手段によって試され、考え抜かれている。

　ビジョン：ビジョンはもはや言葉によるものではなく、特定のリリースにインプリメントされる新機能やユースケースが記述されたデルタビジョンドキュメントの中でますます多くが定義される。全体的な製品計画は、市場動向やサポート、ライセンス、そのほか成功に欠かせない要因など、ソリューションを成功させるために必要なあらゆる要因について記述される。

　要件：ユースケースモデル図は最も抽象的なユースケースを明確にする。一連のイベント、前後の条件、そして例外や代替フローが詳細に記述された仕様を各ユースケースが持っている。ユースケース仕様の詳細はさまざまなレベルで書かれることが多くなり、重要な分野もあれば、さほどでもないものもあり、コーディングを開始する前にさらに細かく定義する必要のある革新的なものもある。それでも、既存の機能に対する分かりやすい拡張となっており、仕様の追加はほとんど必要ない。

　追加仕様／機能以外の要件：アプリケーションは複数のオペレーティングシステム上で動作し、複数のデータベースをサポートして、顧客のアプリケーションと統合したり、セキュリティやユーザーアクセスに関して具体的な要件を求める場合がある。これには外部の基準か、もしくは個々に明らかにし、議論し、意見をまとめ、テストしなくてはならない多数のパフォーマンス要件定義が適用される。そのような場合には、追加仕様にこの情報が含まれ、これがアジャイル要件定義手法にとっては欠くことのできない成果物となる。

　ツール：プロジェクトがますます複雑になると、ツールの要件定義も複雑になり、チームも情報のキャプチャや優先順位付けを行う。もしくは開発済みのユースケースからユースケースの概要を自動的に生成する要件定義ツールが有益であると考えるようになる場合がある。プロジェクトに関与する人数が多ければ多いほど、そして開発拠点が多ければ多いほど、構築されるシステムを定義するコード自身とユースケースなど、要件定義関連の両方の成果物にとってバージョンコントロールの重要性が増してくる。

　ここでは、エクストリーム要件定義手法に現実的かつ控えめな拡張を行うことで、アジャイル要件定義手法を定義した。この手法はすでに多数のプロジェクトで採用され、その効果が実証されている。

ロバスト要件定義手法 （A Robust Requirements Methods）

　だが、前述のようなペースメーカーのプログラムを開発している場合、果たしてアジャイル要件定義手法は十分な効果を発揮できるだろうか？世界各国で同時に年2回リリースされる6種類の統合製品をチームで開発しているような場合はどうか？ 世界中の6カ所に散らばった800人のデベロッパを採用しても製品は連動しなくてはならないのだ。また、通信会社のように、あるプロジェクトの成功が、数千人のプログラマによる年単位の努力の積み重ねで構築される“第3世代のデジタルスイッチングシステム”いかんにかかっている場合はどうだろう？ このような場合には真のロバスト（Robust：強力な、頑健な）要件定義手法が必要になる。ロバスト要件定義手法を採用すると、当面の課題に対応してスケーリングが可能になり、重要な分野で非常に信頼性の高い製品を提供できるようカスタマイズでき、さらに海外のデベロッパが開発中のサブシステムに関する要件定義を理解できるようになる。また、数百ものユースケースや、そのアプリケーションがほかのシステムやアプリケーションと（確実かつ問題なくシームレスに）連動するために必要な数千の機能／機能外要件定義を自分のシステムが確実に満たしていることの確認に役立つ。

　では、図3に示されるロバスト要件定義手法について考えてみよう。

図3　ロバスト要件定義手法のモデル（クリックすると拡大します）

　コンセプト：アーキテクチャの基盤の大半が開発され、インプリメントされるまでは、実際にリリースできる機能がせいぜいわずかな数にとどまることを考慮して、一連のコンセプト検証テクニックを用意する。これら1つ1つが、開発しようとしているシステムで意図された動作を理解するという目標にわれわれを近づけてくれる。

　ビジョン：多数の利害関係者、デベロッパ、そしてテスターの間の見解を確実なものにすべく、ビジョン（短期および長期の両方）は文書化する必要がある。これは、現在および将来の機能やユースケースをサポートする適切なアーキテクチャをデザイン、インプリメントするに当たって設計者やデザイナーにとって十分に長期的なものである必要がある。製品計画は範囲を拡大し、さまざまな潜在購入パターンや可能性の高い顧客導入オプションまで記述すべきだ。この計画はほかに、サポートされる互換アプリケーションの改訂レベルについても明確にすべきだ。

　要件：見込みユーザーがインプリメンテーションのコンセプトを検証できるよう、必要に応じてユースケースで詳細に説明する。こうすることで、必要不可欠な要件定義が有用性と適合性の確認に役立つ形で確実にインプリメントされるようになる。代替イベントの順番をすべて説明して記述し、前後の条件を可能な限り明確に指定する。さらに、より正式なテクニック（分析モデル、アクティビティ図、メッセージシーケンス図）を利用して、一段と明確にシステムが本来の動作をする方法やそのタイミングを記述する。

　追加仕様／機能以外の要件：追加仕様は可能な限り完全なものとなり、すべてのプラットフォーム、アプリケーションの互換性問題、適用可能な標準、ブランド戦略と著作権の要求事項、パフォーマンス、有用性、信頼性、そしてサポートする要件が定義されている。

　ツール：規模が大きく拡大し、分散したチームには極めて強力なソフトウェアツールが必要となる。分析／デザインツールには、内部と外部の両面からシステムの特定の動作を推進し、複数のサイトにまたがるコンフィグレーション管理システムが採用される。要件定義ツールは、ユースケースからテストケースまでの各機能で要件定義をトレースする。そして、不具合トラッキングシステムはどこにいるユーザーでもサポートできるよう拡張されている。

　プロジェクト管理：大規模なプロジェクトはレベルの高いプロジェクトサポートと管理を必要とする。要件定義コントロールボードは、チームが相互に依存するユースケースのインプリメンテーションを監視し、シンクロできるよう用意されている。変更管理委員会は追加される可能性のある要件定義や不具合の修正について考察し、判断できるよう設置されている。要件分析や影響評価といった作業は、変更および追加案の影響の理解に役立つよう実施される。

　ロバスト要件定義手法の中でこれらのテクニックや作業を併用すれば、膨大な量の人月が投資され、世界中にいる大勢のユーザーの生活にかかわる新システムが、正確で、信頼性が高く、安全で、意図された目的に適していることを確認するのに役立つ。

結論

　本稿では、プロジェクト環境に存在するリスクの確実な緩和だけを目的として、ソフトウェアの開発手法がデザインされているとのコンセプトを強調してきた。行き過ぎた手法は不必要な作業を増やし、チームにとってオーバーヘッドや重荷となる。注意しないと進行が遅れ、コストがかさみ、いずれは競争力を失ってしまう。どこかほかのチームが次のプロジェクトを獲得しなければ、ほかの会社が自分たちの次の顧客を奪ってしまうことになる。逆にこのような手法がまったく存在しなければ、会社や顧客側は過度なリスクを背負い、その結果、一段と深刻な結末が予想される。

　このリスクをうまく処理するため、エクストリーム要件定義手法、アジャイル要件定義手法、そしてロバスト要件定義手法という、それぞれ特定のプロジェクト環境に適した3つの模範となる要件定義手法を考えてきた。個々のプロジェクトがユニークであり、顧客やアプリケーションもそれぞれが異なることは認識していても、あなたにとって最適な要件定義手法はこれらの中にはおそらくないだろう。最適なものはおそらく、見てすぐ分かるような組み合わせであったり、あるいはここで説明しきれなかった派生型かもしれない。だが、適切な準備さえ整えていれば、次のプロジェクトに向けて適切な要件定義手法を選択することができるのだ。

IT Architect 連載記事一覧

---

【参考文献】

“Rational Unified Process 2001”、米Rational Software Corporation刊（2001年）

“Managing Software Requirements: A Unified Approach”、Dean Leffingwell、Don Widrig共著、Addison-Wesley刊（1999年）

“Extreme Programming Explained: Embrace Change”、Kent Beck著、Addison-Wesley刊（2000年）

“Agile Software Development”、Alistair Cockburn著、Addison-Wesley刊（2002年）

---

【注釈】

（*1）“Managing Software Requirements: A Unified Approach”、Dean Leffingwell、Don Widrig共著、Addison-Wesley刊（1999年）

（*2）“Agile Software Development”、Alistair Cockburn著、Addison-Wesley刊（2002年）　149〜153ページ

（*3）このコンセプトは割り引いて理解することが重要である。Philippe Kruchten氏は「私は自分がいったことをもっとよく理解するために文書にしている」としている

（*4）われわれの経験では、この問題はしばしば過大評価されており、チームの新しいメンバーには要件、分析、そしてデザインツールなどの中にある「生きた」文書に重点を置かせる方がよいかもしれない

（*5）“Extreme Programming Explained: Embrace Change”、Kent Beck著、Addison-Wesley刊（2000年）

（*6）前出のLeffingwellとDon Widrigの共著

（*7）前述したように、この手法に対しては批判がないわけではない。ある論評家は、「ユーザーストーリーを１つずつ処理する」ことの大きな欠点を指摘し、アーキテクチャ構築作業の完全なる欠如だとしている。もし当初の仮定が間違っているならば、アーキテクチャのリファクタリングを1つのユーザーストーリーごとに行わなくてはならない。システム全体を構築し、n-1番目のストーリーについて「1人のユーザーではOKだ。今度は3000人でも機能するようにしよう」ということになるのだ

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