要件定義とは
新しいシステムで、どの業務をどこまでシステムに担わせるかを開発の前に決定し、文書化する工程です。業務の流れをどう変更するかを業務要件として先に定め、それを実現するために画面や帳票で何ができればよいかをシステム要件として定めます。処理の速さや安全性、止めてよい時間帯のように機能以外の条件は非機能要件と呼び、要件定義の中で一緒に定めます。
完成した要件定義書は開発会社が基本設計をし、見積もりを提示する前提になります。完成したシステムを受け入れるかどうかを確認する基準にもなります。
IPA（情報処理推進機構）と経済産業省が2020年に公表した第二版の情報システム・モデル取引・契約書は、システム化の企画と要件定義を合わせて超上流工程と呼び、設計より前に置いています。開発会社の提案書で超上流と記載されていたら、この2つの工程を指します。
なぜ必要か
何を開発するかを決定しないまま開発を開始すると、業務部門は画面ができてから想定との違いに気づきます。その段階で作り直しが発生します。後の工程で発見されるほど、設計、作り込み、テストをやり直す範囲が拡大します。
もう1つの理由は見積もりです。何を開発するかが曖昧なままでは、開発会社は確かな費用と納期を提示できません。曖昧さを解消しないまま固定額で契約すると、確定していなかった部分の扱いを巡って追加費用や納期の争いになりやすいです。
発注側と開発会社の役割
要件を決定する責任は発注側にあります。IPAはユーザのための要件定義ガイドの公開にあたり、システムを使って事業に貢献する役目を負うユーザに責任があると説明しています。モデル契約書も要件定義書は発注側が作成し、開発会社は作成を支援する形を想定しています。
開発会社が担うのは次の作業です。
- 決定が必要な事項の洗い出し
- 進め方の設計
- 技術的に実現できるかどうかと、費用への影響の説明
- 文書化の支援
効果
- 見積もりの精度が向上する。確定したことと確定していないことが区別され、複数の開発会社の見積もりを同じ前提で比較できる
- 手戻りが減少する。業務部門の想定とシステムの仕様の違いを、開発を開始する前に発見できる
- 範囲の膨張を抑えられる。後から生じた要望が当初の範囲か追加かを要件定義書で判定できる
- 受入れの基準になる。納品時の受入れテストで、要件定義書に照らして合否を判定できる
コストとリスク
- 業務部門の時間を取られる。業務担当者と責任者が打ち合わせ、資料の確認、社内の調整に時間を割く。通常業務と並行するため負担は小さくない
- 日程が延びやすい。打ち合わせと確認が業務部門の都合に左右され、部署間の調整が長引くとその分だけ日程が後ろ倒しになる
- 細部まで決めすぎると費用が増加する。利用するか分からない機能まで詳細に定めると開発量と開発費が増える。導入後の保守費用もその分だけ増加し続ける
- 決め切れないまま進行すると、途中で要件が変化する。社内の合意が取れないまま次の工程に移行すると、設計や開発の途中で要件が変更され、追加費用と納期遅延が発生する
- 非機能要件が漏れやすい。性能、セキュリティ、障害時の復旧時間は業務部門の要望に含まれにくく、開発会社から検討事項を提示してもらわないと抜けたまま進行する
- 完了の条件を定めない準委任では、決め残しの多い文書しか得られないことがある。作業は期間の満了で終了するため、要件定義書に何が記載されていれば完了とするかを契約時に定めておく
- システムの移行では現行の仕様が不明な場合がある。担当者の異動や資料の散逸で今のシステムの処理内容を誰も説明できない場合、現行と同じという記述しかできず、後で解釈の争いになる。モデル契約書の第二版公表にあたっても、システムの移行では要件定義の前に現行システムの調査が必要だと注意を促している
よくある誤解
要件定義書が確定したら変更できない
変更はできます。定めた手続きに沿って、費用と納期への影響を確認したうえで変更します。モデル契約書も確定後の変更は契約内容の変更手続きで処理する形にしています。口頭で追加した要望は費用と納期への影響が記録されません。
アジャイル開発なら要件定義を必要としない
アジャイル開発でも要件定義は必要です。全体を最初から詳細には定めず、目的、範囲の大枠、優先順位を先に決定し、細部は開発しながら短い間隔で決定していきます。
決定する責任が発注側にある点に変化はありません。
