要件定義を資産とするためには

通常システム開発後のドキュメントと言えば設計書が一般的ですが、その設計書はキングファイル数冊分になるのが普通です。

それはそれで保守の時に使用できますが、大手ユーザ企業のシステム部門は、実際に保守作業を自分たちで行うことはまれで、それらの設計書はあまり使いません。使うとしてもテーブル定義書や伝文フォーマットなど、扱っている情報を確認する時に使う程度です。

そもそもシステム部門は、システムの企画を行いそれを計画し、実行、導入し効果が上がるように保守・改善することが役割です。

そのような場面においては設計段階の情報は細かすぎます。また、設計書はHowの視点（どのように作るか）で書かれているので、何を行っているのかがわかりにくくなっています。従ってユーザ部門と業務改善につながるような打ち合わせの中では設計書はあまり役に立ちません。

要件定義を資産とすることの重要性はそこにあります。つまり、システムの企画や改善などにおいてはWhat視点（何をするのか）の資料が必要になり、それを記述しているのが要件定義書だからです。

システムを改善するときに現場の担当者と打ち合わせする前にそのシステムが何をやっているかを確認することや、ハードウェア更新に伴いシステム再構築の時の新しい要件定義の元資料として使用します。

そのための要件定義書として以下の視点が重要です

　・Whatが示されていること
　　　どのように（How）作られているかではなく　何を（What）するのかが示されていること

　・中程度の粒度で示されていること
　　　現場で使われている言葉や概念で要件定義が記述されていること

　・現場の担当者と話ができるレベルの情報があること
　　　ビジネスルールが記述され　ロジックに関わるルールは含まれないこと

このように要件定義書がエンドユーザとのシステム改善の打ち合わせのもと資料として活用できるようになると、その要件定義書がシステム部門の資産となり、その会社のIT化のノウハウがそこに込められていることになります。