方向性を出すために
要件定義書でコミュニケーションする
要件定義を成功させるために重要なことは、ドキュメントを作成することではなく、関係者がアイディアを出し合い、真に役に立つシステムの要件を組み立てることです。そのためには議論の対象となるものを視覚化し、お互いのイメージやアイディアを形にして共有することが大事です。
RDRAでは要件定義工程を"要件定義書を作成する工程"とは捉えません。有効な要件を組み立てるための議論をする工程と考えます。要件定義書作成を第一義と考えず、議論により要件を組み立てることを第一義とします。つまり要件定義書の作成を目的とした作業をなくし、要件定義書をコミュニケーションと合意を得るための議論の対象と捉え、議論の結果がそのまま要件定義書となると考えます。
要件の洗い出し、共有、確認を一度に済ます
打ち合わせ後にそこで決めた内容をドキュメント化し、次の打ち合わせでその内容を確認する。問題があれば修正し、また次回確認する。これを繰り返して要件を決めていく…
これは要件定義工程でよく見られる作業の進め方です。この方式で要件を決めるのは時間がかかり過ぎます。要件は一度に決まるわけではなく、徐々に決まっていきます。何度も見直す必要があることから、要件を決めるのには時間がかかります。限られた時間の中に納めるためには、要件定義の一連の作業をスピーディーに行う必要があります。
打ち合わせの場で要件定義書を作成する意図はこのスピードアップにあります。つまり要件定義で定義する情報を使って議論し、それをそのまま要件定義書とします。こうすることで、要件定義書の作成と共有、内容確認の時間が省け格段にスピードを上げることができます。
打ち合わせの場で要件定義書を作成するためには、大量の文章を書くようなスタイルは不向きです。複数視点の少量の情報をつなげることで幅広い情報を表すようにしなくてはいけません。そのために定義する個々の情報は名前と説明の二つだけにします。ちょうどUMLモデルの各アイコン（クラスやユースケースなど）に名前とノートを設定するのと同じです。
要件をつなげて洗い出す
詳細な仕様の策定に先だってシステム化の方向性を示すのが要件定義の重要な役割です。方向性を決めるためには要件定義のメンバーが集まり課題を把握し、要求を整理しながら方向性を決めます。
しかし、漫然とメンバーが集まって打ち合わせをしても方向性は定まりません。人が集まって有効な結果を得るためには進め方を工夫する必要があります。
要件をつなげて洗い出す仕組みがRDRAの4つの視点にあることを前に紹介しました。アクターを洗い出し、そこにつながる要求、業務フロー、利用シーンなどを順次導出していきます。要件の組み立て方が決まっていれば後はシステムの要件そのものに議論を集中させることができます。複数メンバーで物事を決めるためには、このように要件の決め方が定まっていることがとても大事です。
メンバー全員で一つの対象をベースに議論できるように、プロジェクターに要件定義書（UMLのモデル）を映し、傍らのホワイトボードで議論します。UMLモデルのつながりを意識しながら、情報をつなげることで議論が発散することなく、効率的に作業を進めることができます。
例えば、ある画面の必要性で議論が紛糾した場合は、画面を導き出す元になったユースケースの役割や内容を再度検討します。そこで合意が得られれば、「そのユースケースにとって必要な画面は何か」という視点で画面の検討を行えばいいのです。
状況に合わせて定義する情報を変える
プロジェクトの状況は千差万別です。個々のプロジェクトの状況に合わせて要件の組み立て方を変える必要があります。
既存のシステムがすでに存在する場合には利用シーンやユースケースを省いてアクター、画面・帳票、機能の3つをつなげて素早く整理することができます。逆にまったくの新規システムの場合は要求を整理し、アクターから利用シーンへと順次つなげていきます。
プロジェクトのメンバーの知識レベルや対象システムの状況に応じて洗い出す情報を変え、要件定義をスピーディーに進めていくことが必要です。
