機能一覧の使い方

機能一覧の使い方

　機能一覧のフォーマットは、こちら（http://www.thinkit.co.jp/images/article/140/1/14012.zip）からダウンロードできます（14012.zip/5.18 KB）。フォーマットは図3のようなものです。この中で特に重要なのは「要件番号」「プログラムID」です。この2項目については、先のトレーサビリティの観点で設けている項目です。

　「要件番号」項目は要件一覧の番号に対応しており、その要件を具体的にどのような機能群を用いて実現するかのひも付けがされています。つまり、要件と機能は1：Nの関係で結びついているわけです。

　「プログラムID」項目は実際のプログラムに落とし込んだ時に、ソースに付番されるIDです。こうすることで、万一の仕様変更やバグが発生したした場合も、その仕様変更に対応する機能のソースまでをすぐに把握することができるのです。

　そのほかに「備考」という項目がありますが、ここはどのようなことを記載すればよいのでしょうか？

　筆者はよく「旧帳票名」を記載する項目として利用しています。顧客は手書であれ旧システムであれ、業務を行う上で帳票を出力し利用しているはずです。システムを導入する場合、以前使っていた帳票が、新しいシステムから出力されるのか、なくなるのか、別な帳票に変わるのかといったことは、顧客が業務を行う上で非常に関心が高い点です。

　したがって、このように明示することで、既存帳票からの漏れがないかという確認を含め、顧客に安心感を与えることができるのです。網羅性という意味では別途「新旧帳票対比表」を用意するとより効果的でしょう。

テンプレート利用による意識改革

　今回は業務システム開発ドキュメントテンプレートを紹介する第1回として、システム開発におけるトレーサビリティの重要性を解説し、それを実現するためのテンプレートとして、特に上流工程における要件一覧と機能一覧について説明しました。

　ただ、このようなトレーサビリティの考え方は特に斬新なものではなく、実は最近ではツールによって実現できるものもあります。例えば筆者が実際に紹介を受けたものでは、Borland社のCaliberRM（http://www.borland.com/jp/products/caliber/rm.html）やStarTeam（http://www.borland.com/jp/products/starteam/index.html）といった製品群です。

　これらはツールの画面上で、要件がツリー形式で登録でき、その要件1つ1つに設計書、ソース、障害表といったファイル自体を直接リンクすることができるため、そのツールだけで要件管理、ソース管理、障害管理ができてしまうという代物です。きちんと使えば非常に威力を発揮するツールだと感じました。

　しかしこれらは単なる道具であり、導入するにあたっては、それを使う人たちの意識改革を実行してこそ最大の効果を発揮するのではないでしょうか？

　意識改革のきっかけとしては、まずは高価なツールでなくとも、標準化ドキュメントを利用することでも十分に有効だと思います。皆さんの職場でも上流工程が属人的なのは仕方ないとあきらめず、ぜひテンプレート利用による意識改革を進めてみてください。その際、「なぜこのドキュメントが必要なのか？」という背景を知ってもらうために、DUNGEONテンプレートと併せて本稿を参考にしていただければ幸いです。次回は上流工程の続きとして基本設計書をテーマにお届けします。