要件と機能の関連を保つテンプレート

要件定義で使用するドキュメント

　上流工程は、主に要件定義フェーズと基本設計フェーズに分けられますが、基本設計フェーズは次回お話しますので、今回は要件定義フェーズでのドキュメントについて述べていきます。

　要件定義フェーズで使用するドキュメントにはどのようなものがあるでしょうか？

　要件定義の進め方としては、顧客の行っている業務、例えば「見積業務」「調達業務」「請求業務」単位で打ち合わせ日程を決め、それに従って構築するシステム要件のヒアリングを進めていきます。

　顧客とのヒアリング時に打ち合わせ内容を記録する「議事録」や、出てきた課題をリスト化して管理する「課題一覧」などももちろん必要です。ただ、こちらはいずれ「プロジェクト管理」について紹介する機会があれば、その時に説明させていただくこととし、「開発ドキュメント」という切り口では、「要件一覧」「機能一覧」についてクローズアップします。

　要件一覧はユーザーからヒアリングした中で出てきた要望をリスト化し、それぞれに対してどのような対応を行うかを簡潔にまとめたものです。また機能一覧は顧客の要件を満たすためには、どの画面、帳票にどのような機能を実装するかを具体的に列挙したものとなります。

　まずは要件一覧のフォーマットおよび、その使い方から見ていきましょう。要件一覧のフォーマットは、こちら（http://www.thinkit.co.jp/images/article/140/1/14011.zip）からダウンロードできます（14011.zip/5.46 KB）。

要件一覧の使い方

　DUNGEONのテンプレートでは、図2のようなフォーマットを使用しています。この中で特に重要なのは「RFP番号」「対応方法」「背景」の3項目です。

　まず「RFP番号」項目ですが、これは前述したトレーサビリティの観点で設けている項目です。通常、SIerが要件定義前に顧客から入手している資料として「RFP」（Request For Proposal：提案依頼書）があります。このRFPの精度がよいと、SIerも要件定義がスムーズに進むのですが、これまでの経験では冗長でわかりづらいものが多いのが実情です。

　しかし、ここに顧客要件が盛り込まれていることは間違いないため、無視はできません。このRFP番号は、要件一覧がRFPに対して漏れがないことを証明し、かつRFPのどこに記載してあったかを明示するものです。

　次に「対応方法」項目について説明します。普通に考えればシステム化に際してどのような機能で実現するかを記載する欄ととらえると思います。しかし、ここで注意すべきなのは要件一覧がシステム化する／しないにかかわらず、ユーザーの要件を記載していくものだということです。

　つまりこの対応方法では、システム化しない場合でも、運用でどのように回避するか、2次開発の対象とするのか、別システムに任せるのかといったことを記載する欄として使用するのです。

　最後は「背景」項目についてです。よく開発のリーダーをしていると、メンバーに設計やプログラムの実装方法について相談を受けることがあります。その際「お客さんはこういうことをしたいのだから、こう動かないといけないよね」と指示すると、「よく議事録も見ないで覚えていますね」と感心されることがあります。

　しかし自分にしてみれば人より記憶力があるわけでも、覚える努力をしているわけでもありません。なぜその顧客要件が出てきたのかという背景、理由を理解しているからです。すべての要件には必ず理由があるのです。逆をいえば、理由のない要件はシステム化の対象から外して構わないですし、作ったところで無駄なシステムになるということです。

　続いて機能一覧についても、フォーマットを見ながら解説します。