14:00この連載では「要件定義は洗練化を繰り返して進めていく」と何度か説明してきました。「どうやって管理するの??」と頭に「?」マークが浮かんだ読者も多いことと思います。要件定義工程の終盤になって上位のステークホルダーに「なんでここはこうなったんだ!」という指摘により大きく方針転換し、要件定義が予定通り終わらなかった経験がある方もいるかと思います。目次Page1レビューを計画の中心におくレビュー駆動で進めるテーマとレビューを同期する成果物中心のレビューを改善する要件定義の構造を利用したレビューPage2マイルストーンを組み立てる要件定義のゴールは変わるテーマの候補Page3目的を徐々に明確にする全体を俯瞰する作業量を調整するPage4ツールを利用する目的を共有するマイルストーンを組立、共有する全体を俯瞰するレビューを支援するツール参考資料まとめ要件定義工程はさまざまなことが決まっていない混沌とした状態にあります。このような状況の中で、洗練化などの繰り返し作業の方法と上位のステークホルダーの意向にあわせて軌道修正する進め方を説明します。そのポイントはマイルストーンごとにテーマを決め、そのテーマに基づく作業とレビューを行い、軌道修正しながら成果物を洗練化することです。レビューを計画の中心におくレビュー駆動で進めるプロジェクトオーナーなど上位のステークホルダーはプロジェクトに責任を負うので、プロジェクトに対する軌道修正や中止などの大きな権限をもちます。従って要件定義段階では上位のステークホルダーの意見を十分に配慮し、適切に要件を組み立てる必要があります。そのために上位のステークホルダーが参加するレビューを計画の中心に据え、要件定義以降に大きな方針転換が起こらないように計画を組み立てます。レビューが月1回行われるようであれば、1か月を1マイルストーンととらえます。要件定義工程が3か月の場合は3回のマイルストーンがあると考えます。この時重要な意志決定のタイミングが2回訪れます。大きな軌道修正はこの2回のレビューで吸収します。要件定義工程のイメージここまで読んで「そんなの今でも行っているよ、上位のステークホルダーのレビューがあるのは当たり前だろう!」という声が聞こえてきそうです。従来とはちょっと違うのです。「要件定義工程の進め方」で説明した通り上流工程の管理はタイムボックスで管理するのが適しています。そのタイムボックスをマイルストーンと考え、タイムボックスの終わりにレビューを置きます。そのレビューの場で方向性を決められるように成果物を調整します。この成果物の調整が洗練化の目安になります。従って成果物の作成はレビューにおいてステークホルダーが評価・判断できる情報を中心に構成します。これにより大きな軌道修正はマイルストーンの切れ目で計画的に吸収します。テーマとレビューを同期する成果物を繰り返し洗練化させていくためには作業にテーマ性を与えることが大事です。その時点で行っておくべきことをテーマとして掲げ、要件定義メンバーの作業のベクトルをあわせます。それを計画的に行うためにタイムボックスごとにテーマをもたせ、「そのテーマをつなげていった先に要件定義工程のゴールがある」という形で計画を組み立てます。マイルストーン毎のレビューではテーマを説明した上で、それが実現されていることを検証します。今の状況とゴールに向けた道筋を示した上で、次のマイルストーンまでに実現すべきことを検討しテーマを見直します。この見直しが軌道修正になります。大きな手戻りが発生しないようにします。成果物中心のレビューを改善するテーマとレビューを同期させたら次はレビューをいかに有効活用するかが問題になります。レビューというと成果物のレビューが一般的です。成果物中心のレビューはどうしても成果物そのもののレビューになってしまいます。定義の内容よりも成果物の書き方や体裁などの本質的ではないことに終始してしまう傾向があります。成果物をベースに説明が行われると、思考がその範囲に限定され、本質的な問題を見逃してしまう可能性が高くなります。レビューを有効に活用するために重要なことは成果物が正確に書けているかを確認することではなく、要件として何を取り上げ、それらの要件が妥当で有効なものであるかを検証し、さらに影響する範囲をとらえ問題を探り出すことです。同時に成果物がステークホルダーの要求を反映していることを確認することです。そのためには個々の成果物を確認するのではなく。定義した内容を広く全体から掘り下げるように確認します。前回のレビューで確認したところからつなげて確認することも大事です。レビューの場を有効に活用するためのコツは、定義した内容そのものよりも「なぜそのように定義したのか」、複数の候補があるときは「なぜそれを選んだのか」を説明することです。要件定義者の思考過程を知り、その上で定義した内容を確認することで、その担当者が何を大事と考え、どう問題解決しようとしているかが分かります。このようにレビューの内容を成果物中心から担当者が考えていることを重視する方式に変えていきます。「RDRA(リレーションシップ駆動要件分析)」の定義手法はWhyとWhatの構造になっているので、要件を説明するときにも役に立ちます。以下に説明の一例を示します。システム化の目的、価値を説明しゴールを明確にするどのような責務や課題を持った人にとって価値があるのかを示す価値はシステムを使う場面とともに説明するその場面におけるシステムとの関わり方をユースケースと画面・帳票で説明する各々の利用シーンの目的とシステムとの関わり方を、ユースケースと画面・帳票とをつなげて説明することでシステムのイメージがつかめるようになります。そのときに関係するアクターの責務と解決したい課題なども合わせて示すと効果的です。まとめると「どのような課題を抱えた人がどのような環境でどのようにシステムを利用するのか」をイメージできるようにつなげて説明することです。外部システムとの連携も必要になります。外部システムとの間でやりとりされるイベントを説明しながら、外部システムと当該システムの関係を説明することで、イメージをふくらませることができます。「この外部システムはなぜ必要でこのシステムとどのように関係するのか」を伝えます。最後にシステム境界であるユースケース、画面・帳票、イベントを実現する機能とデータを説明します。システム化に必要なシステム境界が分かれば、定義された機能とデータがなぜ必要なのかを理解できます。大手SIerにおいて大小10システム以上のプロジェクトリーダを勤め、20年ほど前に独立。2002年から5年間(株)豆蔵での社員も兼任しながら要件定義などの上流工程のコンサルティングを行う。圧縮・解凍UNIX基本講座@CodeZine『CodeZine(コードジン)』の公式アカウントです。【NEW】デブスト2019デブサミ2019福岡・関西デブサミ2019夏デブスト関西デブサミ2019×ログインEメールパスワード※旧SEメンバーシップ会員の方は、同じ登録情報(Eメール&パスワード)でログインいただけます。イラストの無断転載を禁じます。記載されているロゴ、システム名、製品名は各社及び商標権者の登録商標あるいは商標です。