要件定義が曖昧なまま始まる案件へ──手戻りを止める論点と判断基準の置き方

キックオフは終わった。議事録もある。関係者も多い。
なのに、1〜2週間経つと必ずこうなる。

• 仕様が日替わりで変わる

• チャットで決まった気になって、あとで覆る

• 実装が進むほど、手戻りの量が増える

• 誰も悪くないのに、現場だけが疲弊する

この状態、努力不足じゃない。構造の問題です。
要件定義が曖昧なまま走り出す案件は、だいたい同じところで詰まります。

僕が現場で何度も見てきた結論はシンプルで、手戻りが止まらない案件は、要件そのものが曖昧というより、論点と判断基準が未設定なことが多い。
つまり、何を決めるべきかが揃っていない。だから、決めたはずのことが決まっていないまま進む。

今日はこの構造を、再現できる型に落とします。

1. 手戻りの正体は、要件の曖昧さではなく判断の曖昧さ

要件定義が曖昧に見えるとき、現場ではだいたい次が混ざっています。

• 要求（こうしたい）

• 要件（こうあるべき）

• 仕様（こう作る）

• 判断基準（だからこう決める）

この4つが混線すると、会話が全部ふわっとします。
そしてふわっとした会話は、進捗が出た瞬間に確定したこととして扱われがちです。ここで事故が起きる。

重要なのは、要件を完璧に書くことではありません。
手戻りを止めるには、先に論点を固定し、判断基準を置く。これが本質です。

2. まず固定するべき論点は、たった3つ

要件定義に時間をかけても手戻りが止まらないのは、論点が散らかっているからです。
僕は最初に、論点を次の3カテゴリに畳みます。

論点A：スコープ境界

• 今回やること / やらないこと

• 対象ユーザー、対象業務、対象範囲

• 既存運用で飲むのか、変えるのか

ここが曖昧だと、後から要求がいくらでも増殖します。

論点B：受け入れ条件（Doneの定義）

• 何ができたら完了なのか

• どう検証してOKにするのか

• 誰がOKと言うのか

Doneが曖昧だと、終わらないし、終わった後に戻されます。

論点C：トレードオフ（優先順位のルール）

• 速度 / 品質 / コスト / 体験 / 運用負荷

• ぶつかった時に、どれを優先するか

トレードオフがない案件は、全部を満たそうとして全部が中途半端になり、最後に炎上します。

この3つだけ先に揃えると、要件の文章が多少荒くても、手戻りの量が目に見えて減ります。

3. 判断基準は、要件の文章ではなくルールで置く

判断基準を文章で頑張って書こうとすると、だいたい詰みます。
理由は簡単で、文章は例外に弱いから。

だから僕は、判断基準をルールとして置きます。形式は3行で十分。

• 判断したいこと：何を決める？

• 判断の軸：何を見て決める？

• 判定の境界：どこでYes/Noが分かれる？

例を出します。

例：検索機能を作るかどうか

• 判断したいこと：初回リリースに検索を入れるか

• 判断の軸：対象ユーザーの利用頻度、代替手段、実装と運用コスト

• 判定の境界：検索なしで目的タスクが完了できるなら初回は入れない

こういう判断基準があると、途中で要望が増えても、議論が戻る場所ができます。
判断がブレない案件は、戻る場所がある案件です。

4. 手戻りを止める最小セット：論点メモ＋決め方メモ

現場で今日から使える形に落とすなら、成果物は2つで足ります。

① 論点メモ（A4 1枚）

• スコープ境界（やる/やらない）

• Doneの定義（受け入れ条件）

• トレードオフ（優先順位）

② 決め方メモ（5行）

• 誰が決める（意思決定者）

• 何で決める（判断基準）

• いつ決める（締切）

• 変える時はどうする（変更ルール）

• 記録はどこに残す（決定ログ）

この2つがあると、チャットで決まった気になる事故が激減します。
決めたことが残るから。残るから、揺れない。

5. 1週間の最小実装：明日やる1つ、今週やる1つ

最後に、やることを小さくします。

明日やる1つ

キックオフ議事録から、論点A/B/Cを抜き出して見出し化してください。
中身は空でいい。まず箱を作る。

今週やる1つ

増えた要求を、必ずA/B/Cのどこかに分類してから扱う運用に変える。
分類できない要求は、要件ではなく雑談扱いにする。これが効きます。

よくある失敗：要件を増やして安心しようとする

手戻りが怖いと、要件を増やしたくなります。
でも多くの現場で起きているのは、要件が足りないのではなく、決め方が足りないことです。

要件を増やす前に、論点と判断基準を置く。
ここが整うと、要件はむしろ短くできます。

まとめ

要件定義の勝負は、文章量じゃない。
手戻りを止めるのは、論点（何を決めるか）と判断基準（どう決めるか）を先に置くこと。

あなたの現場で、いちばん曖昧なまま進みがちなのは、スコープ境界・受け入れ条件・トレードオフのどれですか？

次に読む：

はじめての方へ：

マガジンの紹介：

IT業界の「技術×キャリア×整える」を束ねるマガジンを公開中です！
ビジネスや心と体を整える良記事が集まってきていますので、
是非、覗いてみてくださいね。
記事は全て無料記事のみです。
気に入って頂けたらマガジンのフォローもよろしくお願いします！
共同マガジンに参加希望の方も募集中です！

相談したい方へ（ココナラ）

要件が曖昧な案件で消耗し続けると、経験は積んでいるのに評価が伸びない、転職でも強みが言語化できない──そんな停滞に入りやすいです。

僕は、30代エンジニアのキャリア停滞を抜け出すために、

• いま詰まっている状況の言語化

• 強みの棚卸しと方向性整理

• 現職での立て直し/転職の作戦
  を一緒に組み立てます。

▼相談はこちら（ココナラ）：