私が勤務していた客先では、要件定義のフォーマットもなく、各ユーザーが好きなように要件定義書を作成していました。
そのため、いわゆるふわっと要件と呼ばれるようなあいまいさに満ちた要件定義が多く、たびたび炎上していました。。。
ここでは炎上する要件定義について取り上げていきます。
🔥 事例①：ふわっと要件で爆発
📄 状況
- 顧客：「使いやすい在庫管理システムが欲しい」
- SE：深掘りせずそのまま設計
- 開発：UIをそれっぽく作る
💥 結果
- 納品後：「全然使いにくい」とクレーム
- 大幅な作り直し
- スケジュール崩壊
🧨 原因
- 「使いやすい」の定義なし
- 業務フロー未整理
- 現場ヒアリング不足
🛠 防ぐ方法
- 操作手順を具体化（例：何クリック？誰が？）
- 実際の業務フローを図にする
- プロトタイプで早期確認
🔥 事例②：関係者の認識ズレ
📄 状況
- 営業：「売上レポートが欲しい」
- 経理：「請求ベースで」
- SE：1つの仕様として定義
💥 結果
- 納品後：「これ違う」と双方から指摘
- 作り直し
- 信頼低下
🧨 原因
- 「売上」の定義が人によって違う
- 関係者間のすり合わせ不足
🛠 防ぐ方法
- 用語定義書を作る
- 関係者全員でレビュー
- サンプルデータで確認
🔥 事例③：例外未定義で地獄
📄 状況
- 要件：「注文を登録する」
- 正常系だけ設計
💥 結果
- 本番でエラー多発
- NULL、重複、通信失敗でバグ祭り
🧨 原因
- 異常系・例外系の未定義
- 「普通に動く前提」で設計
🛠 防ぐ方法
- エラーケースを列挙
- 「壊れる前提」で設計
- 入力チェックを明文化
🔥 事例④：後出し要件で崩壊
📄 状況
- 開発中に顧客が追加要望
- 「これも必要」「あれも欲しい」
💥 結果
- スコープ肥大化
- 納期遅延
- 開発チーム疲弊
🧨 原因
- 要件確定前に開発開始
- 変更管理なし
🛠 防ぐ方法
- 要件確定フェーズを明確にする
- 変更は別管理（追加見積もり）
- 「今やる / 後でやる」を分ける
🔥 事例⑤：業務理解不足で不適合
📄 状況
- SEが業務を理解せず設計
- 「理論上正しい」システムを作る
💥 結果
- 現場が使わない
- Excelに逆戻り
🧨 原因
- 現場ヒアリング不足
- 実際の運用を無視
🛠 防ぐ方法
- 現場を見る（これ最強）
- 実際の操作を観察
- 仮説 → 確認を繰り返す
🔥 事例⑥：パフォーマンス未考慮
📄 状況
- 要件は機能中心
- 性能要件なし
💥 結果
- 本番で激遅
- 大量データでタイムアウト
🧨 原因
- 非機能要件の未定義
- データ量想定不足
🛠 防ぐ方法
- レスポンス時間を定義
- 想定データ量を明確化
- 負荷テストを事前に実施
🔥 炎上する要件定義の共通パターン
全部まとめると👇
❌ 失敗の本質
- 曖昧なまま進める
- 認識を揃えない
- 例外を考えない
- 業務を理解しない
- 変更を管理しない
🎯 成功する要件定義の本質
逆に成功するのは👇
👉 ズレ・抜け・想定外を先に潰すこと
🔚 一言でまとめると
👉 炎上の原因 = 「曖昧・未確認・未定義」