要件定義とは「構築依頼とそのための依頼書づくり」

ITで難しいプロセスの1つに要件定義がある。

要件定義とは何をすることなのか。それを一言で言えば「どのようなシステムを作って欲しいのかを明らかにして構築依頼すること」となる。
この構築依頼に使われるものが「要件定義書」であったり、「RFP」と呼ばれるもの。
構築依頼に基づいて、ベンダーは開発すべき対象を見積り、顧客側がその見積もりをもとに予算を確保し、最終的に発注を行う。この一連の活動が要件定義において行うこととなる。

「依頼」とあるとおり、依頼者と依頼を受ける構築側がここでは登場する。
要件定義をはじめるに際には依頼者側が「こんなものを作りたい」「こんなものを実現してほしい」という要望からはじまる。
例えば「今後増える社員数といろんな社員の形態の給与を正しく即座に計算できてほしい」であったり、「顧客からの受注と自社の生産状況、および販売計画を比較・確認できるようにしたい」という要望。
ただ、これをそのまま構築側に伝えても、開発すべき対象が見積もれないし、構築にかかれない。これでは「要件定義」でなく「要望伝達」である。
「要件定義」とは、要望を出す依頼者と要望を実現する構築側が、構築していく対象・条件を合意することでもある。
①依頼者は何をしたいのか正しく伝達し、②構築側はこうすれば実現できる・これは実現できないを回答し、③依頼者はその回答をもって依頼するか、内容を見直すかを行う。

この3ステップをすっとばすと「そんなことなら早く言ってよ」と発注者側も受注者側ものちのち泣きを見る。

依頼者「給与計算は1時間でX万人できる想定でした」→構築側「そんなことなら早く言ってよ、それなら見積もりも変わるのに…」

構築側「この要件は実現できますが、クラウドでなくオンプレである前提が付くことになるんです」→依頼者「そんなことなら早く言ってよ、インフラの運用・保守費用も考慮に入れないといけないのに…」

システム開発の失敗理由の大半が要件定義と言われるが、それは①の段階で依頼者が言ったつもりになっていたり、構築側からの実現要否を重要視せず「なんとかしてくれるだろう」と鷹をくくったりする要因も多い。

構築側も受注がほしいために②の段階で精査をせず、なんでも「できます。できます」を繰り返すことも原因の1つにある。

それを防止するためには、①―③の正しいプロセスと要件や実現性をはっきり定める枠組みに沿って要件定義を進めていく必要がある。