目次
- 要件定義とは
- 基本原則
- 進め方（標準プロセス）
- 要件の種類
- 良い要件の書き方
- 優先順位付け
- 要件定義書のテンプレート（構成例）
- よくある失敗と対策
- 合意形成・コミュニケーションのコツ
- 品質チェックリスト
- 参考になる体系・資料
1. 要件定義とは
要件定義とは、「何のために」「誰が」「何を」できるようにするのか、そして「どの水準で」実現するのかを、関係者の合意のもとで明文化する工程。設計や実装の前提になる「正解の定義」であり、ここでの漏れや曖昧さは後工程で何倍ものコストになって返ってくる。
要件定義のゴール
- 関係者全員が「作るもの」と「作らないもの」について合意している
- 設計者・開発者・テスト担当者が、それぞれの判断の根拠にできる
- 完成したかどうかを客観的に判定できる
2. 基本原則
| 原則 | 内容 |
|---|---|
| 目的から始める | 機能から考えず、「解決したい課題」「達成したいビジネス成果」から逆算する |
| Why を残す | 各要件に「なぜ必要か」を書く。理由のない要件は優先度判断も削減判断もできない |
| What と How を分ける | 要件は「何を実現するか」。実現手段（画面レイアウト、DB構造など）は原則として設計で決める |
| 検証可能に書く | 「速く」「使いやすく」ではなく、測定・判定できる基準で書く |
| スコープ外を明記する | 「やらないこと」を書くことで、期待値のズレと後からの追加要求を防ぐ |
| 合意を記録する | 誰が・いつ・何を承認したかを残す。口頭合意は合意ではない |
| 完璧より反復 | 一度で全部決めようとしない。不確実な部分はプロトタイプや段階リリースで検証する |
3. 進め方（標準プロセス）
3.1 準備：背景・目的の把握
- プロジェクトの背景、現状の課題、達成したい目標（KGI/KPI）を整理する
- 予算・期限・体制などの制約条件を確認する
- 成功の定義を数値で合意する（例：「問い合わせ対応時間を30%削減」）
3.2 ステークホルダーの特定
- 決裁者、業務担当者、実際の利用者、運用・保守担当、情報システム部門、法務・セキュリティなどを洗い出す
- それぞれの関心事・影響力を整理する（ステークホルダーマップ）
- 最終決定者を明確にする。意見が割れたときに誰が決めるのかを最初に決めておく
3.3 要求の収集（ヒアリング・調査）
- 現状業務（As-Is）を先に把握する。現場を見る、実データを見る
- 手法を組み合わせる：インタビュー、ワークショップ、業務観察、既存資料・既存システムの調査、アンケート
- ユーザーの「こうしてほしい」は解決策であることが多い。その裏にある課題を「なぜ？」で掘り下げる
- 例外ケース・繁忙期・エラー時の運用など「普段は起きないこと」を意識的に聞く
3.4 分析・整理
- あるべき業務（To-Be）を描き、As-Is との差分からシステム化範囲を決める
- 要求を「業務要件」「機能要件」「非機能要件」に分類する
- 重複・矛盾・抜け漏れをチェックする
- 優先順位をつける（後述の MoSCoW など）
3.5 文書化
- 後述のテンプレートに沿って要件定義書にまとめる
- 図（業務フロー、ユースケース図、画面遷移、データモデル概要）で補足する
- 用語集を作り、言葉の定義を統一する
3.6 レビュー・合意
- 業務側・開発側・運用側それぞれの観点でレビューする
- 未決事項（TBD）は担当者と期限をつけて一覧管理する
- 承認者のサインオフを取得し、ベースラインとして版を確定する
3.7 変更管理
- 確定後の変更は、影響範囲（コスト・スケジュール・品質）を評価してから承認する
- 変更履歴を残し、要件とテストケースの対応（トレーサビリティ）を維持する
4. 要件の種類
4.1 業務要件
業務として何を実現したいか。業務フロー、業務ルール、対象業務の範囲、関係する組織・役割。
4.2 機能要件
システムが「何をするか」。
- ユーザーが行える操作（ユースケース／ユーザーストーリー）
- 入力・出力・処理内容・帳票
- 外部システム連携
- 権限・ロールごとにできること
- 業務ルール・計算ロジック・バリデーション
4.3 非機能要件
システムが「どの水準で動くか」。漏れやすく、後から変えにくいので特に注意する。 IPA の「非機能要求グレード」の6分類がチェックリストとして有用。
| 分類 | 確認項目の例 |
|---|---|
| 可用性 | 稼働時間帯、稼働率目標、計画停止、障害時の復旧目標（RTO/RPO） |
| 性能・拡張性 | 同時利用者数、応答時間、処理件数、データ量の将来予測 |
| 運用・保守性 | 監視、バックアップ、ログ、問い合わせ対応、リリース手順 |
| 移行性 | 既存データの移行範囲、移行方式、並行稼働の有無 |
| セキュリティ | 認証・認可、暗号化、監査ログ、脆弱性対策、個人情報の扱い |
| システム環境・エコロジー | 利用端末・ブラウザ、設置場所、クラウド/オンプレ、法令・規格 |
これに加えて、ユーザビリティ・アクセシビリティ、法令・コンプライアンスも確認する。
4.4 制約条件
予算、期限、使用必須の技術・製品、社内規程、既存システムとの互換性など、選択の余地がない前提条件。
5. 良い要件の書き方
5.1 良い要件の条件
- 明確：1通りにしか解釈できない
- 検証可能：テストで合否を判定できる
- 完全：必要な条件（誰が・いつ・何を・どの範囲で）がそろっている
- 一貫：他の要件と矛盾しない
- 実現可能：技術・予算・期間の中で実現できる
- 必要：目的に紐づいており、なくても困らないものではない
- 追跡可能：一意のIDがあり、出典と後工程（設計・テスト）に紐づけられる
5.2 曖昧な表現を避ける
| 悪い例 | 良い例 |
|---|---|
| 検索は高速に応答すること | 検索結果は、通常時（同時利用100人以下）に95%のリクエストで2秒以内に表示されること |
| 使いやすい画面にする | 初めての利用者が、マニュアルなしで3分以内に申請を完了できること |
| 適切に権限管理する | 「承認者」ロールのみが申請の承認・差戻しを行えること |
| 必要に応じて通知する | 申請が承認された時点で、申請者に登録メールアドレス宛てに通知メールを送信すること |
| 大量データに対応する | 5年間で想定される最大100万件の取引データを保持し、検索できること |
要注意ワード：「適切に」「柔軟に」「など」「等」「必要に応じて」「できるだけ」「高速」「簡単」「十分な」「原則として」
5.3 ユーザーストーリー形式（アジャイルの場合）
<役割> として、<目的> のために、<機能> がしたい。
受け入れ条件は Given / When / Then で書くと検証可能になる。
例：
経費申請者として、立替精算を早く受け取るために、スマートフォンから領収書を撮影して申請したい。
受け入れ条件：
- Given ログイン済みの申請者が申請画面を開いている
- When 領収書を撮影して金額・日付・用途を入力し、申請ボタンを押す
- Then 申請が「承認待ち」状態で登録され、上長に通知が送られる
5.4 ユースケース記述の要素
- ユースケース名 / アクター / 事前条件 / 事後条件
- 基本フロー（正常系）
- 代替フロー・例外フロー（エラー、キャンセル、タイムアウト等）
例外フローの網羅が品質を左右する。正常系だけの要件定義は、実装時に開発者の推測で埋められてしまう。
6. 優先順位付け
MoSCoW 法
| 区分 | 意味 |
|---|---|
| Must | なければリリースできない |
| Should | 重要だが、回避策があれば後回しにできる |
| Could | あると良い。余力があれば対応 |
| Won’t (this time) | 今回はやらない（スコープ外として明記） |
ポイント
- Must が全体の6割を超えるなら優先度付けが機能していない可能性が高い
- 優先度は「価値」と「コスト・リスク」の両面で判断する
- 判断理由を記録しておくと、後の変更時に議論を蒸し返さずに済む
7. 要件定義書のテンプレート（構成例）
1. はじめに
1.1 文書の目的
1.2 対象読者
1.3 用語集
1.4 参照資料
2. プロジェクト概要
2.1 背景・現状の課題
2.2 目的・成功指標（KGI/KPI）
2.3 スコープ（対象範囲 / 対象外）
2.4 前提条件・制約条件
3. ステークホルダーと利用者
3.1 ステークホルダー一覧と役割
3.2 利用者（ペルソナ・ロール・利用規模）
4. 業務要件
4.1 現状業務フロー（As-Is）
4.2 あるべき業務フロー（To-Be）
4.3 業務ルール
5. 機能要件
5.1 機能一覧（ID・名称・概要・優先度）
5.2 機能詳細（ユースケース / ユーザーストーリー・受け入れ条件）
5.3 画面・帳票の概要
5.4 外部インターフェース
5.5 データ要件（主要エンティティ、保持期間）
5.6 権限・ロール
6. 非機能要件
6.1 可用性
6.2 性能・拡張性
6.3 セキュリティ
6.4 運用・保守
6.5 移行
6.6 システム環境
6.7 ユーザビリティ・アクセシビリティ
6.8 法令・規程
7. リスクと対応方針
8. 未決事項（TBD）一覧（内容・担当者・期限）
9. 承認記録・変更履歴
8. よくある失敗と対策
| 失敗 | 原因 | 対策 |
|---|---|---|
| 作ったが使われない | 目的が曖昧、実際の利用者を巻き込んでいない | 成功指標を数値で定義し、現場の利用者をヒアリング・レビューに入れる |
| 後から要件が次々に追加される | スコープ外が明記されていない、決定者が不明確 | 「やらないこと」を書く。変更管理プロセスと決定者を決めておく |
| 非機能要件の漏れで本番障害 | 機能の話ばかりで性能・運用を詰めていない | 非機能要求グレード等のチェックリストで網羅確認する |
| ユーザーの要望をそのまま実装 | 要望を要件と取り違えている | 「なぜ必要か」を掘り下げ、本当の課題に対する解決策を検討する |
| 解釈の違いによる手戻り | 曖昧な表現、用語の不統一 | 数値・条件で書く。用語集を作る。図や画面モックで認識を合わせる |
| 例外時の挙動が未定義 | 正常系しか検討していない | 代替フロー・例外フローを要件として明記する |
| 要件定義が終わらない | 全部を一度に確定しようとする | 不確実な部分はプロトタイプやMVPで検証し、段階的に詳細化する |
| 現行機能の漏れ（リプレース時） | 「今と同じ」で済ませている | 現行システムの機能・帳票・バッチ・暗黙の業務ルールを棚卸しする |
| 承認したはずが「聞いていない」 | 合意が口頭・議事録のみ | 文書としてレビュー・承認を取り、版管理する |
9. 合意形成・コミュニケーションのコツ
- 見える形で確認する：文章だけでなく、業務フロー図、画面ワイヤーフレーム、プロトタイプを使う。人は具体物を見て初めて違和感に気づく
- 言葉を揃える：同じ言葉が部署ごとに違う意味を持つことは多い（例：「顧客」「受注日」）。用語集で定義する
- 議事録は当日中に共有する：決定事項・未決事項・宿題（担当と期限）を明記する
- 反対意見を早めに出してもらう：レビューでは「問題なし」より「懸念点」を聞く問いかけをする
- トレードオフを示して判断を仰ぐ：「A案はコスト小・機能限定、B案は高コスト・柔軟」のように選択肢と影響を並べる
- 開発側も早期に参加する：実現可能性やコスト感を要件定義の段階でフィードバックしてもらう
10. 品質チェックリスト
目的・スコープ
- 背景・課題・目的が明記され、成功指標が数値で定義されている
- スコープ（対象 / 対象外）が明記されている
- 前提条件・制約条件が整理されている
ステークホルダー
- 関係者が洗い出され、最終決定者が明確になっている
- 実際の利用者の意見が反映されている
要件の質
- すべての要件に一意のIDと優先度がある
- 各要件に「なぜ必要か」が書かれている
- 曖昧な表現（適切に・など・高速に 等）が残っていない
- 各要件がテストで合否判定できる
- 正常系だけでなく例外系・エラー時の挙動が定義されている
- 要件間に矛盾・重複がない
網羅性
- 非機能要件（可用性・性能・セキュリティ・運用・移行・環境）が確認されている
- 外部連携、データ移行、権限が定義されている
- 法令・社内規程・個人情報保護の観点が確認されている
- （リプレースの場合）現行機能の棚卸しが済んでいる
合意・管理
- 用語集がある
- 未決事項に担当者と期限が設定されている
- 関係者のレビューと承認が記録されている
- 変更管理の手順が決まっている
11. 参考になる体系・資料
- IPA「ユーザのための要件定義ガイド」：業務側（発注者）視点での要件定義の進め方
- IPA「非機能要求グレード」：非機能要件の網羅的なチェックリスト
- BABOK（ビジネスアナリシス知識体系ガイド）：要求の引き出し・分析・管理の国際的な知識体系
- ISO/IEC/IEEE 29148：要求工学のプロセスと要求仕様書の国際規格
- ISO/IEC 25010：ソフトウェア品質特性モデル（非機能要件の観点整理に有用）