要件定義の基礎
要件定義とは
要件定義は、顧客の業務上の課題や要望を分析し、構築するシステムが満たすべき要件として整理・文書化する工程である。開発プロジェクトの最上流に位置し、以降のすべての工程の基盤となる。
なぜ SIer で重要か
SIer の開発プロジェクトにおいて、要件定義は品質・コスト・納期のすべてに影響する最も重要な工程である。ここでの認識ズレや定義漏れは、下流工程に進むほど修正コストが指数関数的に増大する。要件定義の品質がプロジェクト成否を左右すると言っても過言ではない。また、一括請負契約の場合、要件定義書がスコープの基準となるため、契約上も極めて重要な成果物となる。
基本概念
機能要件と非機能要件
システム要件は大きく「機能要件」と「非機能要件」に分類される。
| 区分 | 定義 | 具体例 |
|---|---|---|
| 機能要件 | システムが実現すべき機能・振る舞い | ユーザー登録機能、検索機能、帳票出力機能、データ連携機能 |
| 非機能要件 | 機能以外のシステム品質や制約条件 | 性能、可用性、セキュリティ、運用保守性 |
非機能要件の主な分類
IPA（情報処理推進機構）が公開している「非機能要求グレード」では、以下の6つの大項目が定義されている。
| 項目 | 内容 | 例 |
|---|---|---|
| 可用性 | システムの稼働率、障害時の復旧時間 | 稼働率 99.9%、RTO 4 時間以内 |
| 性能・拡張性 | レスポンスタイム、同時接続数 | 画面応答 3 秒以内、同時 500 ユーザー |
| 運用・保守性 | バックアップ、監視、メンテナンス方針 | 日次バックアップ、24 時間監視 |
| 移行性 | 既存システムからのデータ移行方針 | 過去 5 年分のデータを移行 |
| セキュリティ | 認証・認可、暗号化、監査ログ | 多要素認証、通信の TLS 暗号化 |
| 環境・エコロジー | 設置環境、消費電力等の制約 | データセンターの耐震基準 |
要件定義書の主な記載事項
一般的な要件定義書には以下の項目が含まれる。
| 章 | 記載内容 |
|---|---|
| プロジェクト概要 | 背景、目的、スコープ、前提条件、制約条件 |
| 業務要件 | 現行業務フロー、新業務フロー、業務ルール |
| 機能要件 | 機能一覧、画面一覧、帳票一覧、外部インターフェース一覧 |
| 非機能要件 | 上記の6項目に基づく品質要件 |
| データ要件 | 主要なデータ項目、データ量の見込み、データ移行方針 |
| 運用要件 | 運用体制、障害対応フロー、バックアップ方針 |
SIer での使われ方
要件定義の進め方
SIer の現場では、一般的に以下のような流れで要件定義を進める。
- 現行業務のヒアリング --- 顧客の業務部門にヒアリングを行い、現行の業務フロー、使用しているシステム、課題や不満を把握する。
- 要望の整理 --- ヒアリングで得た要望を一覧化し、優先度を付ける。「必須（Must）」「できれば（Should）」「将来的に（Could）」のように分類する（MoSCoW 法）。
- システム化範囲の決定 --- どの業務をシステム化し、どの業務は手作業のまま残すかを決定する。コストやスケジュールとのバランスで判断する。
- 画面イメージの作成 --- 主要な画面のモックアップやワイヤーフレームを作成し、顧客と「見える形」で認識合わせを行う。これにより抽象的な文章だけでは伝わりにくい仕様の認識ズレを早期に発見できる。
- 要件定義書の作成・レビュー --- 上記の内容を要件定義書として文書化し、顧客と共同でレビュー・承認を行う。
よくある課題
スコープクリープ
プロジェクトの進行中に要件が際限なく膨らんでいく現象。顧客から「ついでにこの機能も追加してほしい」「この画面も少し変えてほしい」といった要望が積み重なり、当初のスコープを超えてしまう。対策として、変更管理プロセスを定義し、追加要件は影響分析とコスト見積もりを行った上で正式な変更手続きを経る運用とする。
暗黙の要件
顧客が「当然実現されるもの」と思い込んでいるが、要件定義書に明記されていない要件。例えば、「データのバックアップは当然取るものだと思っていた」「印刷機能は言わなくても付くと思っていた」といったケースがある。ヒアリング時に業務の前後の流れを丁寧に確認することや、非機能要件のチェックリストを活用することで、暗黙の要件を引き出すことが重要である。
顧客が要件を決められない
顧客側に IT の知識が少ない場合や、社内の意思決定者が多い場合に発生しやすい。SE が選択肢を提示して判断を促す、プロトタイプを作って具体的なイメージを持ってもらう、といった工夫が必要になる。
まとめ
- 要件定義は顧客の要望をシステム要件として整理する最上流の工程である
- 機能要件（システムが何をするか）と非機能要件（どのように動くか）の両方を定義する
- 要件定義書はプロジェクトのスコープ基準となり、契約上も重要な成果物である
- スコープクリープや暗黙の要件への対策が、要件定義の品質を左右する
- 画面イメージやプロトタイプを活用し、顧客との認識ズレを早期に解消することが重要である