要件定義工程はさまざまなことが決まっていない混沌とした状態にあります。このような状況の中で、洗練化などの繰り返し作業の方法と上位のステークホルダーの意向にあわせて軌道修正する進め方を説明します。そのポイントはマイルストーンごとにテーマを決め、そのテーマに基づく作業とレビューを行い、軌道修正しながら成果物を洗練化することです。
レビューを計画の中心におく
レビュー駆動で進める
プロジェクトオーナーなど上位のステークホルダーはプロジェクトに責任を負うので、プロジェクトに対する軌道修正や中止などの大きな権限をもちます。従って要件定義段階では上位のステークホルダーの意見を十分に配慮し、適切に要件を組み立てる必要があります。
そのために上位のステークホルダーが参加するレビューを計画の中心に据え、要件定義以降に大きな方針転換が起こらないように計画を組み立てます。
例えばレビューが月1回行われるようであれば、1か月を1マイルストーンととらえます。要件定義工程が3か月の場合は3回のマイルストーンがあると考えます。この時重要な意志決定のタイミングが2回訪れます。大きな軌道修正はこの2回のレビューで吸収します。
ここまで読んで「そんなの今でも行っているよ、上位のステークホルダーのレビューがあるのは当たり前だろう！」という声が聞こえてきそうです。
しかし、従来とはちょっと違うのです。「要件定義工程の進め方」で説明した通り上流工程の管理はタイムボックスで管理するのが適しています。そのタイムボックスをマイルストーンと考え、タイムボックスの終わりにレビューを置きます。そのレビューの場で方向性を決められるように成果物を調整します。この成果物の調整が洗練化の目安になります。
従って成果物の作成はレビューにおいてステークホルダーが評価・判断できる情報を中心に構成します。これにより大きな軌道修正はマイルストーンの切れ目で計画的に吸収します。
テーマとレビューを同期する
成果物を繰り返し洗練化させていくためには作業にテーマ性を与えることが大事です。その時点で行っておくべきことをテーマとして掲げ、要件定義メンバーの作業のベクトルをあわせます。
それを計画的に行うためにタイムボックスごとにテーマをもたせ、「そのテーマをつなげていった先に要件定義工程のゴールがある」という形で計画を組み立てます。
マイルストーン毎のレビューではテーマを説明した上で、それが実現されていることを検証します。そして今の状況とゴールに向けた道筋を示した上で、次のマイルストーンまでに実現すべきことを検討しテーマを見直します。この見直しが軌道修正になります。
これによりステークホルダーの意向に沿った要件を定義することができ、要件定義工程以降で大きな手戻りが発生しないようにします。
成果物中心のレビューを改善する
テーマとレビューを同期させたら次はレビューをいかに有効活用するかが問題になります。
レビューというと成果物のレビューが一般的です。成果物中心のレビューはどうしても成果物そのもののレビューになってしまいます。つまり定義の内容よりも成果物の書き方や体裁などの本質的ではないことに終始してしまう傾向があります。さらに成果物をベースに説明が行われると、思考がその範囲に限定され、本質的な問題を見逃してしまう可能性が高くなります。
レビューを有効に活用するために重要なことは成果物が正確に書けているかを確認することではなく、要件として何を取り上げ、それらの要件が妥当で有効なものであるかを検証し、さらに影響する範囲をとらえ問題を探り出すことです。同時に成果物がステークホルダーの要求を反映していることを確認することです。
そのためには個々の成果物を確認するのではなく。定義した内容を広く全体から掘り下げるように確認します。また、前回のレビューで確認したところからつなげて確認することも大事です。
レビューの場を有効に活用するためのコツは、定義した内容そのものよりも「なぜそのように定義したのか」、複数の候補があるときは「なぜそれを選んだのか」を説明することです。要件定義者の思考過程を知り、その上で定義した内容を確認することで、その担当者が何を大事と考え、どう問題解決しようとしているかが分かります。このようにレビューの内容を成果物中心から担当者が考えていることを重視する方式に変えていきます。
要件定義の構造を利用したレビュー
「RDRA（リレーションシップ駆動要件分析）」の定義手法はWhyとWhatの構造になっているので、要件を説明するときにも役に立ちます。以下に説明の一例を示します。
- システム化の目的、価値を説明しゴールを明確にする
- どのような責務や課題を持った人にとって価値があるのかを示す
- 価値はシステムを使う場面とともに説明する
- その場面におけるシステムとの関わり方をユースケースと画面・帳票で説明する
各々の利用シーンの目的とシステムとの関わり方を、ユースケースと画面・帳票とをつなげて説明することでシステムのイメージがつかめるようになります。そのときに関係するアクターの責務と解決したい課題なども合わせて示すと効果的です。
まとめると「どのような課題を抱えた人がどのような環境でどのようにシステムを利用するのか」をイメージできるようにつなげて説明することです。
一方外部システムとの連携も必要になります。外部システムとの間でやりとりされるイベントを説明しながら、外部システムと当該システムの関係を説明することで、イメージをふくらませることができます。
「この外部システムはなぜ必要でこのシステムとどのように関係するのか」を伝えます。
最後にシステム境界であるユースケース、画面・帳票、イベントを実現する機能とデータを説明します。システム化に必要なシステム境界が分かれば、定義された機能とデータがなぜ必要なのかを理解できます。
