現場で使っている“認識合わせのプロセス”
要件定義の現場では、
- 要望が抽象的
- 手段ベースの依頼だけ来る
- 誰も目的を言語化していない
- 解釈が複数ある
- 関係者内で認識がズレている
といった “曖昧な要件” が頻繁に発生します。
曖昧なまま進めると、後で仕様変更・手戻り・スケジュール遅延につながります。
この記事では、私が実務で行っている
「曖昧な要件を整理し、成功条件まで定義するためのプロセス」
を紹介します。
1. 依頼が“手段ベース”できたときは、目的を言い換えて確認する
現場では、会議の冒頭からいきなり
- 「この画面にチェックボックス追加したいです」
- 「ここ自動化したいです」
など “やりたいこと（手段）” だけが出てくることが多いです。
その場合、私は自分の解釈を言語化して提示しながら確認します。
今回の依頼って、◯◯（例：作業時間の削減）を狙ってる認識で合ってますか？
この対応で △△（例：入力ミスが減る）状態になっていれば成功、というイメージですかね？
こちらから目的を“言い換えてあげる”ことで、相手も回答しやすくなり、会話が整理されます。
2. 目的と手段を分離する
曖昧さの多くは、目的と手段が混ざっている状態 から発生します。
例：
- 「このチェックボックス、任意に変更できるようにしたい」
→ 手段 - 「ミスが多いので入力を制御したい」
→ 目的
整理の基本はシンプルで、
これは目的なのか？
それとも手段なのか？
を分けるだけ。
3. 曖昧な要件は3つの種類に分類する
曖昧さは同じに見えて、実は3種類あります。
分類①：情報不足（質問したら解決する曖昧さ）
例
「自由に設定できるようにしたい」
→ 何を？誰が？どの画面で？どの権限で？
→ 単に質問すれば埋まるパターン。
分類②：定義が曖昧で、複数の解釈ができてしまう
例
「もっと使いやすくしたい」
「簡単に操作できるようにしたい」
→ UI？操作手順？操作時間？
→ “言葉の定義合わせ” が必要なパターン。
分類③：まだ決めていない・決めきれていない曖昧さ（最も厄介）
例
「この判定ロジックはどうしますか？」
「通知はどこまで飛ばしますか？」
→ クライアント内部で未決定の可能性が高い。
→ 情報の整理ではなく“意思決定のサポート”が必要。
4. 整理した内容を“一枚のシート”に構造化する
要件が散らばっていると曖昧さは解消されません。
私は以下の項目で一枚にまとめています
- 目的
- 成功条件
- 対象範囲（今回のスコープ）
- 入力
- 出力
- 前提条件
- 例外
- 未決定事項
- クライアントに確認すべき点
- 次フェーズに回せそうなもの
こうして構造化するだけで、
抜け漏れ・不一致・曖昧点が一気に浮き上がります。
5. スコープ（今回の対象範囲）を明確にする
具体的には、
- 今回の対応に含まれないものはどれか？
- 次フェーズに回しても良いものはどれか？
- 影響範囲に入らない前提はどれか？
これを決めるだけで、会話の迷走が確実に減ります。
6. インナーMTGで事前に認識を揃える
曖昧な要件は、クライアントMTGをいきなり始めると混乱します。
そこで、まず社内でインナーMTGを行います。
- 目的の共有
- 曖昧な部分の可視化
- クライアントに聞くべき質問
- 今回のMTGで“決めたいこと”を整理
- スケジュールとの整合性確認
インナーで整えておくと、
クライアントMTGでの質問が最短距離になり、ズレも最小限にできます。
7. 判断基準を作ると、曖昧さが一気に解消される
意見が割れたり決めきれないときは、まず 判断基準 を作ります。
- 安全性
- 工数
- 運用コスト
- スケジュール影響
- 拡張性
- 他機能との整合性
基準が決まると「A案はこういう理由で合わないね」が自然に導ける。
8. 会議の最後は必ず「決まったこと」と「未決事項」を口頭で確認
会議の最後の1〜2分で必ずやること
- 今日決まったこと
- まだ決まっていないこと
- 次アクションと担当者
これを口頭で整理するだけで、全体の精度が大きく改善します。
9. 情報を1つに集約する
情報が散らばると曖昧さは増え続けます。
- Backlog
- スプレッドシート
- 画面一覧
- 機能一覧
- Slackスレッド
- 議事録
これらを「最終的にどこを見れば正しいのか」を決めて一元化するだけで、
要件の不一致がほぼゼロになります。
まとめ
- 曖昧な要件を扱うときに重要なのは、
- 目的と言葉の定義を揃える
- スコープの輪郭をはっきりさせる
- 曖昧さの種類を分類する
- 情報を構造化して一枚にまとめる
- 未決定事項と判断基準を分けて整理する
- インナーMTGで準備する
- 会議の最後に認識を揃える
- 情報を一元化する
シンプルですが、これを徹底するだけでプロジェクトの安定度が大きく変わります。
曖昧な要件ほど、言語化と構造化の技術が効果的です。