皆さんは記載の粗い要件定義書に悩まされた経験はありませんか？
私のいた職場では要件定義書にフォーマットもなく、各ユーザーが好きなように要件定義書を作成していたため、記載の粗いものが多かったです。。。
しっかりと記載された要件定義書であれば質問するまでもないことでも質問しなければわからないということはしょっちゅうでした。。。
ここではダメな要件定義の例を取り上げていきたいと思います。
❌ ダメな要件定義の具体例
ケース①：曖昧すぎる要件
ダメな要件
ユーザーが使いやすい画面にする
👉 問題点：
- 「使いやすい」の定義がない
- 人によって解釈が違う
- テストできない
改善例
・3クリック以内で目的の操作が完了できる
・主要操作は画面上部に配置する
・入力エラーはリアルタイムで表示する
👉 ポイント：具体的にする
❌ ケース②：条件が曖昧
ダメな要件
一定数以上の注文があれば割引する
👉 問題点：
- 「一定数」が不明
- 割引率が不明
改善例
注文数が10個以上の場合、合計金額から10%割引する
👉 ポイント：数値で定義する
❌ ケース③：例外が未定義
ダメな要件
ユーザー情報を登録する
👉 問題点：
- 不正入力時は？
- 必須項目は？
- 重複登録は？
改善例
・メールアドレスは必須
・形式不正の場合はエラー表示
・既に登録済みの場合は登録不可
👉 ポイント：異常系を書く
❌ ケース④：業務理解不足
ダメな要件
注文をキャンセルできるようにする
👉 問題点：
- いつでもできる？
- 出荷後は？
- 返金は？
改善例
・出荷前のみキャンセル可能
・出荷後は返品処理に切り替える
・返金は決済方法に応じて処理する
👉 ポイント：業務ルールを反映
❌ ケース⑤：用語が曖昧
ダメな要件
顧客情報を管理する
👉 問題点：
- 顧客＝個人？法人？
- 管理＝何をする？
改善例
顧客（個人ユーザー）の以下情報を登録・更新・削除できる：
・氏名
・メールアドレス
・電話番号
👉 ポイント：用語を定義する
❌ ケース⑥：UIだけでロジックがない
ダメな要件
ボタンを押したら処理を実行する
👉 問題点：
- 何の処理？
- 成功・失敗時は？
改善例
送信ボタン押下時：
・入力チェックを実行
・エラーがなければDBに保存
・成功時は完了画面へ遷移
・失敗時はエラーメッセージ表示
👉 ポイント：処理の流れを書く
❌ ケース⑦：関係者間で認識ズレ
ダメな要件
レポートを出力する
👉 問題点：
- 営業：売上レポートのつもり
- 経理：請求レポートのつもり
👉 全員違うものを想像している
改善例
月次売上レポートをCSV形式で出力する：
・期間：当月1日〜末日
・項目：売上金額、件数、顧客数
👉 ポイント：誰の要件か明確にする
🧠 ダメな要件の共通点
全部まとめると👇
- 曖昧（ふわっとしている）
- 測れない（テストできない）
- 例外がない
- 用語が不明確
- 業務が反映されていない
🎯 良い要件の条件
逆に言うと👇
👉 「誰が読んでも同じ動きになる」
🛠 実務で使えるチェック
要件を書くとき👇
-
- 数値で定義されているか？
-
- 異常系があるか？
-
- 用語は明確か？
-
- 処理の流れがあるか？
-
- 誰が見ても同じ理解になるか？
🔚 一言でまとめると
👉 ダメな要件 = 解釈が必要な要件
👉 良い要件 = 解釈の余地がない要件