要件定義の話を再開

ここのところ要件定義セミナーの告知ばかりになっていましたが、結構このブログを見ていただいている方がおり、要件定義ネタを楽しみにしておられる方がおられることを最近知りました。

そうだと分かればちゃんと要件定義ネタを書かないといけないと　一念発起　連載で書いていこうと思います。
どこまで続くか分かりませんが、週１話程度でがんばっていこうと思います。

まず最初は「要件定義書」から始めます。

「要件定義書」に何を書くかは人あるいはプロジェクトによって千差万別です。

そこで今日は私が定義している「要件定義書」を紹介します。

そして次回は「要件定義」を紹介します

私は「要件定義書」を要件定義の次の行程への入力情報を提供するためのドキュメントと捉えています。

こんなことを言うと「何を今更　そんなことは当たり前だろう」と言われそうですが、実際要件定義書を作成している人の中でそれを意識している人がどれだけ居るでしょうか。

つまり、要件定義書が次の行程でどのように使われ、そのために何が定義されている必要があるのか　をきちんと認識して作成しているかどうかということです。

会社によって要件定義の位置づけやそれに続く行程が違います。

要件定義はユーザ企業で行い、次の行程からシステム開発会社が担当することもあるでしょうし、要件定義行程から開発までをシステム開発会社がになっている場合もあります。

従ってシステム開発の各工程はどのような体制(会社間の役割分担など)で開発するかに大きく依存します。

ということはシステム開発の工程のとらえ方や実際の行程の切り方はプロジェクトによって違ってきます。

このように行程が違えば自ずと要件定義書に書かれる内容も違ってくると言うことです。

私が言いたいのも正にこの点です。
要件定義書として絶対的な記述内容があるとは考えないですし、そのように考えて作成すると不必要なドキュメントを作ってしまうと考えています。

要件定義の次の行程はプロジェクトによって変わるので要件定義書に書かれる内容もプロジェクト毎に変わる。

でもこれは「プロジェクト毎に要件定義書に記述する内容は異なるので要件定義書に書く内容は定義出来ない」と言いたいわけではありません。

そこで私の要件定義書の定義は以下のように定義します。

要件定義書は次の行程を担う人にそのドキュメントを使って説明でき、かつ、次の行程の入力となる情報（判断、類推する元ネタ）が網羅的に含まれていれば、それで要件定義書として満たしている　と考えています。

逆に言うと要件定義書として非常に大量のドキュメントがあったとしても、そのドキュメントを使って次工程の人に説明することができず、次の行程の入力となり得ないものは要件定義書とは言えない　と考えています。
つまり役に立たない要件定義書はフォーマットがきちんとしてても、それが大量にあっても意味をなさないと考えています。

従って私は意味のある要件定義書を作るためには、要件定義行程の後に来る行程がどのようなもので、そこを担う人たちがどのようなスキルレベルでどのような体制で行程を引き継ぐかをある程度理解する必要があると考えています。

そして、それが要件定義行程のゴールを決める重要なファクターだと考えています。

私は説明可能な要件定義書であることがとても重要だと考えています。
「自分たちで作った要件定義書なら説明出来るに決まっているだろう」という声が聞こえそうですが、最近の開発では要件定義書の内容を説明できないプロジェクトが結構増えています。

説明可能とは、システムの目的などのマクロな視点から、システムの全体像を説明し、徐々に細かな内容にブレークダウンしながら説明出来ることです。

全体像の説明もないままいきなり細かな説明になったり、本当に概要だけを説明して「後はドキュメントを読んで」のように相手に投げ出したりすることは説明可能とは考えていません。

また「次の行程の入力情報になる」というのはどのような情報を満たすことなのかを説明できないプロジェクトも増えています。

このように説明可能でかつ次の行程の入力を作り出す要件定義とはどのようなものなのか　を次回のテーマとしたいと思います。