本稿は 要件定義 (RD: Requirement Definition) に関する記事です。要件定義はソフトウェア開発工程の最初期に行われ、「何を作るのか」「なぜ作るのか」を発注者・利用者・開発者の合意としてまとめるフェーズです。ここでの認識合わせの精度が、後工程のコスト・品質・スケジュールを大きく左右します。

要件定義の位置づけ

工程	目的
企画 / 構想	事業目的・投資対効果の整理
要件定義 (RD)	業務要件・機能要件・非機能要件の合意
基本設計 (BD)	外部仕様 (画面・帳票・I/F) の決定
詳細設計 (DD)	内部仕様 (クラス・テーブル・モジュール構造)
実装	コーディング
単体テスト	関数・クラス単位の検証
結合テスト / 総合テスト	システム全体の検証
受入テスト / 運用テスト	利用者視点での合格確認

要件定義で決めること

分類	内容
業務要件	背景・目的・対象業務・あるべき業務の姿 (To-Be)
機能要件	システムが提供する機能。画面・帳票・バッチ・APIなど
非機能要件	性能・可用性・セキュリティ・運用・保守性・拡張性・移行性
制約条件	予算・期間・採用技術・準拠規格・法令
関係者・体制	ステークホルダ・責任分界・意思決定者
前提条件	既存システム・データ・契約・運用フロー

非機能要件の代表例 (IPA 非機能要求グレード)

項目	例
可用性	稼働率 99.9%、計画停止月 1 回・夜間 2 時間以内
性能	同時 500 ユーザ、画面応答 3 秒以内、ピーク TPS 200
運用・保守性	監視項目・障害連絡フロー・パッチ適用方針
移行性	既存システムからのデータ移行方式・期間
セキュリティ	認証・認可・通信暗号化・ログ保管・PII の扱い
拡張性	3 年後にユーザ数 5 倍まで対応など
システム環境	クラウド／オンプレ・OS・ミドルウェア指定

主な成果物

• 要件定義書 (業務要件 / 機能要件 / 非機能要件)
• 業務フロー図 (As-Is / To-Be)
• 機能一覧 (機能ID付き)
• 画面遷移図 / 主要画面イメージ
• データモデル概要 (ER 図のドラフト)
• 用語集 (ユビキタス言語)
• 体制図 / 役割分担
• リスク一覧と対策
• 概算スケジュール / 予算

進め方の典型ステップ

1. ヒアリング (発注者・現場担当者)
2. As-Is 業務の整理 (現状業務を可視化)
3. 課題抽出と To-Be 業務の検討
4. 機能一覧化 (機能ID で管理)
5. 非機能要件のすり合わせ (性能・可用性・セキュリティ)
6. 制約・前提・優先順位の確認
7. 要件定義書のレビューと合意 (関係者承認)

うまくいかない要件定義のサイン

• 機能一覧が「画面一覧」になっている — 目的が抜け落ちている
• 非機能要件が空欄／コピペ — 後で性能問題・運用課題が噴出
• 「あれもこれも」の総花化 — 優先順位と MVP を決めずに着手
• 業務側が決められない — 意思決定者を巻き込めていない
• 合意の形跡がない — 議事録・承認・バージョン管理がない
• 用語の揺れ — 「顧客」「ユーザ」「会員」が混在

注意点

• 非機能要件はテンプレを埋めて終わりにしない。SLA や運用フローまで踏み込む
• 変更管理を最初に取り決める。要件は必ず変わる前提でプロセスを準備
• アジャイル開発でも要件定義はゼロにならない。ビジョン・スコープ・優先順位の合意が必要
• 議事録・決定事項は文書化して関係者に承認させる (口頭合意は後に必ずもめる)
• ROI・KPIを最初に決め、検収条件と紐付ける

関連

• 親カテゴリ: 開発工程
• 次工程: 基本設計
• テスト工程: 単体テスト / 受入テスト/運用テスト