合意を得る - 神崎コンサルノート

要件定義を行う上で合意しながら決めていくということはとても大切なことです。

合意が取れなければプロジェクトとして統一した意見にはならず、いつまでたっても要件が決められません。
この当たり前のことがなかなか実現出来ません。

　　「俺はこの機能が必要だと思う」
　　「私はその機能よりもこっちの機能の方が必要だと思う」
　　「ユーザのXXさんがこう言っていた　だからこの機能は必要だよ」

このような様々な意見を集約してしかるべき機能に決めていく必要があります。

なぜなかなか機能が決められないのか？
その理由は決めるための枠組みが無いことに起因します。

合理的に決める枠組みがあれば合意を得やすくなります。

RDRAはその要件を決めるための枠組みを提供したいと考えており、それが要求分析のフレームとしてまとめたモデルのつながりです。

例えば、RDRAではシステムに関わるアクターをもとめ、そのアクターと要求、業務フローのアクティビティ、ユースケースを結びつけていきます。このようなモデル間のつながりがアクターからシステムの機能とデータまで続きます。

そしてこのつながりには意味があり、その意味が要件を決める枠組みになります。

例えばRDRAではユースケースは人とシステムの境界を表すものとして位置づけていますので、ユースケースには何らかのユーザーインターフェース（画面・帳票）がつながることになります。
従って必要な画面と帳票はユースケースを土台に導き出すことが合意のためのルールになります。

この時画面の役割や内容について合意が得られないときは、対応するユースケースについて合意できるかどうかを確認します。そこでも合意が取れないときはユースケースに結びつく業務フローのアクティビティで合意を得ることになります。

このように合意が得られないところからモデルを遡ることで合意を得ることができます。

重要なことはこの合意を得るためのプロセスを要件定義のメンバー内で確認しておくことです。

当然RDRAで示したつながりが全てではありませんので、このようなつながりをプロジェクト内で決め合意を得やすくすることが大事です。つまり要件の決め方を考えるということです。

これがプロジェクト内でできるようになればそのプロジェクトは相当難しいシステムでも対応できるようになります。