実現機能一覧の作り方

　パッケージベースのシステムの要件定義では、通常、実現機能一覧表、すなわち、実現機能とカスタマイズ内容を説明する一覧表を作ります。
　先日、他のメンバが作った表をレビューしていて、自分がどのようにこの表をチェックしているかの手順が明確になりました。

　まず横軸。カスタマイズの内容が妥当かどうかを判断できる論理構成になっているかどうか？
　そのための構成としては、横軸を実現したい機能（ToBe）、パッケージの標準機能（AsIs）、カスタマイズの内容（実現方法）にするのが一般的だと思います。すなわち、実現したい機能と事実としてのパッケージの標準機能を説明しつつ、その差分が、カスタマイズ内容の根拠となるように横軸を構成します。

　次は縦軸。縦軸は実現したい機能をリストアップするわけですが、適当に思いつくままリストアップしたのではなく、漏れなくリストアップしたことということが示されているかどうか？
　そのことをどうやって示すかというと、実現機能をＭＥＣＥで分類し、分類が論理的に漏れていないことを示すしかありません。
　では、どのようにＭＥＣＥ分類すればよいのか？
　これには、オブジェクト指向的な分類が簡単だと思います。すなわち、システムに存在する論理的なオブジェクト（データ）をリストアップし、それぞれに対して、そのオブジェクトに対する一般論としての操作をリストアップする。それを分類として、実現したい機能を当てはめていく。
　オブジェクトは「ユーザ情報」「ドキュメント情報」というようにそのシステムで扱うオブジェクトを挙げていきます。これはシステムごとに違ってきます。これは一見すると至極簡単なことのように思えますが、パッケージベースの要件定義では往々にして陥る罠があります。それは、パッケージが提供しているデータモデルとしてのオブジェクトと、実現したい機能で扱う論理的なオブジェクトがよく似通っているために、両者を混同してしまうということです。このカテゴリを混同してしまうと本来１つの機能として表現されるべき内容が複数箇所に散在したり、同じような内容が何箇所にも繰り返しでてくるということになったりします。
　オブジェクトに対する操作は、特定の情報が格納されている場所に対して一覧・検索、登録、削除、更新、参照　が考えられます。
　windowsのファイルシステムで言えば、ファイル・フォルダ情報が格納されている場所がＤドライブだとします。Ｄドライブに対しては、Ｄドライブ直下のファイル・フォルダの一覧、ファイル・フォルダの登録、特定のファイル・フォルダの名前などのプロパティ等の更新、特定のファイル・フォルダの名前などのプロパティ等の更新、特定のファイル・フォルダの削除ができますね。切り取りや貼り付けなどの操作も、この５つのどれかの分類に入れられるはずです。ここでポイントになるのは、フォルダのような入れ物のオブジェクトはそれに対してまた一覧・検索、登録、削除、更新、参照の操作ができるということです。
　オブジェクトとそれに対する操作の分類ができて、それに実現機能がきちんとマッピングされていれば、分類をみただけで漏れなくリストアップされていることが分かります。

　表の縦軸、横軸の検証が終わってから、最後に表の中身をチェックします。
　この表は、実現機能の１行１行について、実現したい機能は何々、パッケージ標準機能は何々、（つまりその差は何々）、だから（その差を埋めるための）カスタマイズ内容は何々という論理がきちんと成り立っている必要があります。そのためには、ただ実現したい機能とパッケージ標準機能を書けばよいというわけではなく、その差がひとめで分かるように書いてある必要があります。具体的には、それぞれで違うところだけを違うように書いて、それ以外の同じところはまったく同じに書いてあるかという観点で、２つの文章を比較してチェックすればよいわけです。

　つまり実現機能一覧表のチェックポイントは、「これで全部だという根拠」と「差分の根拠」がちゃんと示されているかということだと思います。