要件定義の進め方

御用聞き型要件定義から、計画的に決められた期間内に確実に精度の高い要件を定義する進め方

BUC：ビジネスユースケース　　UC：ユースケース

・よく起きること

誰が何のために、どのような状況で使うシステムなのかが明らかにされないままフォーマットを埋めるだけの要件定義から、計画的に素早く全体像をつかみ、論理的に要件を組み立てるための進め方を紹介する。

※この進め方は数十回のRDRAを使った要件定義の経験をまとめたものである

３フェーズで精度を上げる

要件を一度に完成させるのではなく、全体を把握したうえで、徐々に精度を上げていくことが大事である

RDRAによる一連の定義を３フェーズで３回繰り返し、徐々に精度を上げ整合した要件としてまとめる

フェーズ１：議論のベースを作る

発散しがちな要件定義を短時間に効果的に進めるためには、精度は無視してまずは議論のベースを作ることが必要

フェーズ２：要件を組み立てる

上記ベースを足場にRDRAの要素のつながりを利用して、論理的に要件を組み立てる

フェーズ３：ビジネスルールで仕様化可能にする

条件やバリエーションなどの仕様に直結するビジネスルールで、ユースケースを補完し精度を上げ、仕様化につなげる

システム開発の出発点から最終的な条件とバリエーションの明確化まで、９ステップで要件を体系的に組立てる

９ステップで計画的に進める

※前提：要求定義が終わっており大事な要求が明確になっていること

フェーズ２が終了するとUCが全て洗い出されている状態になる、その段階で要件定義をやめるか否かを判断する。要件定義以降でビジネスルールを仕様化するプロジェクトの場合は、ここで要件定義を終える

この段階でUCが洗い出されたことでシステムで何を対象とし、何を対象外とするかが決まると、見積可能になるのでそれを終了判定に使うこともできる

※プロジェクトチームが成熟していない場合は手戻りを少なくするためにフェーズ３まで実施したほうが手戻りが減る

フェーズの詳細

このフェーズでは分かる範囲（合意できる範囲）で素早く洗い出し全体像をつかむことに注力する

フェーズ１：議論のベースを作成する

Step1: 出発点を明らかにする

システムに関わる登場人物を起点として、関わる業務を洗い出し、まずはシステム化対象がどのあたりかを合意する。空中戦を避けて具体的な議論をするために出発点を明らかにする

Step2: スコープの把握

BUCのアクティビティを粗く洗い出すと具体的に行うとが見えてくる。システム化対象を理解するために、アクティビティの正確さより、まずは洗い出すことを優先する

Step3: システムで扱う情報の明示

業務で扱う情報を明らかにし、そこからシステムで扱わなければならない情報を把握できる。ここでも正確さより必要と思われるものは一旦洗い出すというスタンスで臨む

Step4: システムで管理する状態の明示

業務が認識している状態を洗い出す。無理に洗い出すのではなく、思いつくものを洗い出す。

フェーズ１でシステム化対象の業務とシステムの全体像が見えてきたので、再度トップダウンで見直し、情報、状態からボトムアップに整合させ、要件として組み立てる

フェース２：要件を形作る

Step5: トップダウンで要件を組み立てる

業務、BUC、アクティビティを見直し、システム化するところにUCをつなげる。ざっくりと素早くUCを洗い出すことでシステム化範囲を明らかにする

UCに関わるアクターから画面を導出し、関わる外部システムにイベントを追記する。これでUCの入出力が明らかになる

※これらの活動を通じて新たに業務、BUC、アクティビティを逐次見直す

Step6: 情報・状態を使って見直す

洗い出した情報を関係づけ欠けている情報を洗い出す。情報は状態を持つことが多いので、そこから欠けている状態を洗い出す。

見直した情報をUCにつなげ、UCが行うことを明確にする。同時にUCが状態遷移に関わる場合はUCと情報の関りを見直す

このステップではUCと情報、UCと状態の２者の関係を中心に精度を上げていく

Step5,6を繰り返し行うことで、UC、情報、状態を明確にすることでシステム化すべきことが明らかになる

大事なことは要件はヒアリングしてまとめるのではなく、業務を理解し役に立つシステムの要件を要求に沿った形で組み立てることである。答えのない中で要求から要件を決めることです。そのためにRDRAの仕組を使い、素早く繰り返し洗練化する

フェーズ３：ビジネスルールで仕様化可能にする

Step7: UC（ユースケース）につながる条件を洗い出す

システムがどのような条件下で動作するか、そしてそれがUCにどのように影響するかを考察する。これによりビジネスを駆動するために必要なビジネスルールを明確にし条件として整理する。

Step8: 条件の軸となるバリエーションを洗い出す

条件はバリエーションの組合せまたはバリエーションと状態の組合せで表現できる。条件を元にバリエーションを洗い出す

Step9: 条件とバリエーションの要素を洗い出す

最後に、各条件とバリエーションについて、具体的な要素を洗い出す。このステップにより、要件がさらに詳細化され、開発チームにとって明確な実装指針が得られる。

ビジネスルール（条件）を明らかにし、バリエーションとして整理する活動が、要件を精度の高いものへと変えていく

RDRAで素早く要件を定義するために重要なことは、一つ一つの定義を完成させるのではなく、時間をかけずに洗い出し、全体のつながりから徐々に精度を上げていくことである。何度も繰り返し見直すことで何が重要なのか、要求を実現するために必要なことは何かが見えてくる。こうした洗練化の繰り返しで整合した要件としてまとめることができる

一連の定義を３フェーズで３回回し精度を上げる

各ステップは同じ期間ではないが、おおよそ上記のような期間配分にすることができる。ステップ５はUCを洗い出し、入出力を追記するので通常のステップの３倍、ステップ６は情報と状態の精度を上げUCの整合性をあ高めていくので４倍になる。

この比率を開発規模に当てはめるとおおよその要件定義の期間配分が見えてくる。ここからよくわかっていない部分に時間を割き、よくわかっているところは素早く定義する。例えば一つのステップを１日と置くと、全体で１４日間で要件を定義する計算になる。これを実現するためにも業務やBUCなどの要素を洗い出すときは、時間をかけづに精度が低くてもまずは洗い出し、各々の要素の関係性から精度を上げていき、最終的に整合した要件として定義する。

※この配分はあくまでも目安として利用してください