要件定義はスコープ管理から始まる

　仕様のすり合わせプロセスは、まず仕様のスコープを決めることから始まる、という当たり前だが最も忘れやすいことを再認識した。

　仕事でも勉強会でも、あるビジネスのイメージからビジネスルールを一つずつ確定していき、最終的に設計書という成果物を作っているのだが、各設計者のイメージが異なると、いくら議論しても仕様が確定しない。
　「ユースケース実践ガイド―効果的なユースケースの書き方」には、議論のスコープを追跡するために「In/Outリスト」を提唱している。In/Outリストは、各トピックが作業スコープ内にあるのかスコープ外にあるのか、を示すテーブルに過ぎないのだが、実際、議論はよく食い違う。

　作業スコープが定まったら、更に「アクター・目的リスト」を作成することを提唱している。アクター・目的リストは、システムが要求するユーザ目的のリストに過ぎないが、各トピックの整合性を考えると、不一致が生じたり、トピック漏れが起きたりすることが実際多い。

　最近はプログラミングよりも、ユースケースの妥当性を確認するテクニックをひたすら追いかけている気がする。
　管理職や経営者のような部下をマネジメントする立場にある人は、まずスコープを意識してコントロールするというテクニックが最も基本的なスキルとして要求されているのかもしれない。