下記の記事で、QCDの議論をする前に、スコープを決めようという趣旨の記事を書いた。スコープというのがどういうものかわからないかもしれないので、今回は、スコープを決めるということの概念的なイメージについて説明する。
スコープとは
スコープという単語は、英単語である。日本語に訳すと、範囲や領域という意味合いになる。したがって、システム開発のスコープを決めましょうといった場合は、システム開発の範囲を決めましょうという意味となる。範囲を決めましょうといういっても、あまり具体的な意味がつかめないと思う。なので、概念的なイメージを下記図に示した。
システムを作ろうとした場合、数多ある機能(まだ世の中にない機能/世の中にある機能)の中から、機能を選び出していくこととなる。その際に、この機能は作るのか、この機能は作らないのか、という話になる。そして、そのような検討をまとめた結果が、上図の概念図となる。概念図では、色々な機能が、「する」か「しない」かにグループ分けされている状態となっている。「する」「しない」には明確な線引きがなされており、白抜きの部分が「スコープ内」という状態となっている。
スコープを決める＝する/しないをはっきり決めること
スコープを定義するという作業は、機能実現するものと機能実現しないものをはっきりと区分けする作業のことを言うのだ。そして、この「する」となった部分を文章でまとめたものが、要件定義書である。「スコープを決める＝するしないをはっきりさせる＝要件を定義する」ということである。
する/しないをはっきりさせると、要件定義書の表現が力強くなる
「概念図」や「機能実現イメージ」を記載した要件定義書をよく見かけるのだが、筆者はあまり好きではない。概念図はあくまで概念図であって、機能実現イメージはあくまでイメージなのである。それは、要件ではなく、理解するための補助資料だ。もしその通りに作って欲しいならば、「下記概念図のとおりに機能実現すること」というふうに、命令形で力強く表現すべきだ。そうすることで、ベンダ側も、ここは指示通りに作らなければならない、という意識が芽生える。
また、するしないをはっきりさせることで、テスト仕様書が簡単に作れるようになる。「こうしろ」と書いてあるのだから、「こうなっている」ことを確認するだけでよい。するしないをはっきりと書くことは、いいことづくめなのである。
しかしながら現実には、そのようなはっきりとした表現を好まない人もいる。要件の記載に誤りがあった場合、要件を変更しなければならないからだ。改訂履歴を追記し、バージョンも変更しないといけない。面倒くさい作業だ。
それでも、筆者としては、「要件は絶対に変更しない」という意気込みで、要件を考え抜き、定義していく態度が必要ではないかと考える。そのような態度は、検討の深堀という行為につながる。深堀りすることで、要件が具体化され、見積もりのブレは少なくなり、システムの品質は向上するはずだ。
開発の初期段階で、スコープを厳格に定義する努力をする、そういう努力が大切だ。
