要件定義の読み取りで一番多い失敗は
👉 「聞いたつもり」「分かったつもり」です。
私も分かったつもりになっていて、本来の要件を理解できていなかったことがありました。
SEが要件を正しく読み取るには、単に聞くのではなく
👉 構造化して・疑って・検証することが重要です。
👉 要件は“そのまま受け取るもの”ではなく“解釈して検証するもの” です。
🧠 ① 用語・前提を揃える（最初にやるべき）
同じ言葉でも意味が違うことがよくあります。
例：
- 「顧客」＝法人？個人？
- 「完了」＝保存？承認？
やること：
- 用語集を作る
- 曖昧な言葉は必ず定義する
👉 ここをサボると全部ズレます
🔍 ② 「なぜ？」を必ず聞く
表面的な要望だけでは不十分です。
例：
- 「この機能が欲しい」
→ なぜ必要？
→ 何を解決したい？
👉 本当の目的（業務課題）を掘る
🧩 ③ 業務フローで理解する
文章だけで理解しないこと。
やること：
- 業務の流れを図にする
- 入力 → 処理 → 出力を整理
👉 流れで見ると抜けや矛盾が見える
⚠️ ④ 曖昧な部分を放置しない
危険なワード：
- 「いい感じに」
- 「普通に」
- 「適当に」
👉 すべて具体化する
🧪 ⑤ 具体例で確認する（超重要）
質問例：
- 「具体的にどんなデータですか？」
- 「実際の画面でいうとどこですか？」
👉 抽象 → 具体に落とす
🔄 ⑥ 逆に説明して確認する
理解したつもりを防ぐ方法です。
👉 「つまりこういうことですよね？」と説明する
これで：
- 認識ズレを即発見
- 誤解をその場で修正
🧨 ⑦ 例外・異常系を必ず聞く
ここが抜けやすいです。
確認すべき：
- エラー時の動き
- データがない場合
- 不正入力
👉 バグの温床はここ
📊 ⑧ 境界・条件を明確にする
例：
- 何件まで？
- いつから？
- 誰が対象？
👉 「範囲」が曖昧だと事故る
👥 ⑨ 関係者ごとの認識を揃える
人によって言ってることが違うことが多いです。
やること：
- 複数人に確認
- 矛盾を洗い出す
👉 「誰の要件か」を明確に
🧠 ⑩ 仮説を持って聞く
ただ聞くだけではダメです。
👉 「たぶんこういう仕組みでは？」と仮説を持つ
→ 質問の質が上がる
→ 理解が速くなる
🛠 実務チェックリスト
これを満たせばOK👇
-
- 用語の定義がある
-
- 業務フローが整理されている
-
- 目的（Why）が明確
-
- 入力・出力が明確
-
- 異常系が定義されている
-
- 境界条件が決まっている
-
- 関係者で認識が一致している
🧠 よくある失敗
- 言われたことをそのまま仕様にする
- 分からないまま進める
- 異常系を聞かない
- 業務を理解しない
👉 これ全部「後工程のバグ」になります
🎯 本質まとめ
👉 優秀なSEは何をしているか？
- 聞く
- 疑う
- 分解する
- 確認する
👉 「要件を聞く」のではなく「ズレを潰す」