バイブス父さんの穴倉
みなさんこんにちは！ヒロポンです！
「要件は固まってます」。
客にそう言われて、よし着手だ、と意気込んだ3ヶ月後。「実はこうしたかった」と仕様変更が降ってくる。あれ、固まってたんちゃうん？？ってなるやつ。業務SEなら一度は通る道なんですよね。
X 見てると、ほんまに多い。「認識ズレがあれば言ってください」と頼んだのに、後から本音が出てくる。「やらないこと」を握っておかないと、都合よく解釈されて揉める。そんな声をよく見かけます。
ただ、ここで「客が甘えてる」とは思わないでほしい。客は意地悪してるわけじゃなくて、何がしたいか、自分でもまだ言語化できてないだけなんですよね。だから「固まってる」と言う。本人に嘘をついてる自覚はない。
今回は、要件定義 の段階で 仕様変更 を 防ぐ ために、客を責めずに先に潰しておく3つの抜けを出します。相手の事情を分かった上で、どう確認するか。そこに降ろします。
忙しい人向けに最初にまとめ
- 客が「固まってる」と言うのは嘘じゃない — 上司への説明責任・早く着手してほしい・本当に固まってると思い込んでる、のどれか。悪意じゃない。
- でも「固まってる」のは“やること”だけ — やらないこと・例外時・承認者は、たいてい未確定のまま残ってる。
- だから先にこの3つを握る — 1.やらない範囲の線引き / 2.例外・エラー時の挙動 / 3.最終承認者と変更プロセス。
客が「固まってます」と言うのは、なぜか
最初に、相手の事情を分かっておきましょう。責めるためじゃない。こう言う背景を知っておくと、確認の仕方がぐっとやわらかくなるからです。
客が「固まってます」と言う理由は、だいたいこの3つ。
- 上司への説明責任: 客の担当者だって、社内では「要件は固めました」と報告してる。今さら「実はまだ」とは言いにくい立場なんですよね。
- 早く着手してほしい: 納期が決まってる。ヒアリングで止まると間に合わない。だから「固まってる、進めて」と背中を押してくる。
- 本当に固まってると思い込んでる: これがいちばん多い。やりたいこと(正常系)は頭にある。でも「やらないこと」や「異常時どうするか」は、考えたこともない。本人の中ではもう“完成”してるんです。
3つめが肝。客は嘘をついてるんじゃない。「やること」だけ見れば、確かに固まってる。抜けてるのは、客がそもそも意識してない領域なんですよね。
ん？じゃあ俺らがそこを補えばいいだけやん、って話になります。そう、それでいい。客を責めるより、抜けてる部分をこっちから先に出すほうが、よっぽど早い。
固まった要件の裏に、未確定が残る構造
「固まってる」と言われた要件を分解すると、こんな感じになってます。
「固まってる」の中身は、固まってる部分と未確定の部分が混ざってる。客から見えてるのは上の C だけ。下の3つ(D E F)が、後の仕様変更の正体です。
だったら、この3つを着手前に拾えばいい。順番に行きます。
だからこう確認する — 3つの抜けを先に潰す
ポイントは、客を問い詰めないこと。「固まってないですよね?」と言うと、客のメンツを潰して防御に回らせてしまう。狙いはそこじゃない。「念のため」「こちらの確認のため」と、あくまでこっちの都合として聞く。
| 抜け | こう確認する(セリフ例) | 放置すると |
|---|---|---|
| 1. やらないことの線引き | 「今回やらない範囲を先に握らせてください。ここから先は次フェーズ、で合ってますか?」 | 都合よく解釈され、後から「これも入ってるはず」と追加要望が来る |
| 2. 例外・エラー時の挙動 | 「正常時はこれでOKですね。異常データや途中で失敗した時はどう扱いますか?」 | 正常系だけ作り、本番の変なデータで全部手戻り |
| 3. 最終承認者と変更プロセス | 「最終OKを出す方と、後で変更が出た時の進め方を確認させてください」 | 承認者が不在で堂々巡り・無限に変更が来る |
抜け1: やらないことの線引き
いちばん効くのがこれ。やることよりやらないことを先に握る。
人は「やること」は喜んで話す。けど「やらないこと」は嫌がる。線を引くと、できないことを認める感じがするから。とはいえ、ここを曖昧にしたまま進むと、後で「これも当然入ってますよね」が来る。
危ないのは、こっちが気を遣って曖昧にすること。「まあ、その辺は追々」で流すと、追々のときには手遅れ。
抜け2: 例外・エラー時の挙動
客の頭にあるのは、たいていうまくいった時の画面だけ。データが変だったら? 途中で止まったら? 二重で押されたら？？ ここは客が考えてない領域なので、こっちから具体例で出す。
「たとえば金額がマイナスで来たらどうします?」と一個ぶつけてみる。すると客が「あ、それは…」と考え始める。これで未確定が1つ、表に出ます。
抜け3: 最終承認者と変更プロセス
地味だけど最重要。誰がOKを出すのか、そして変更が出た時にどう進めるのか。ここを決めずに進むと、後から別の偉い人が出てきて「聞いてない」となる。
「変更が出るのは前提です。出た時に、誰がどう判断するか先に決めときましょう」。変更が来ること自体を、最初から織り込んでおく。これがいい感じに効きます。
俺の現場で実際こうだった
フリーで入った案件で、客が「要件はもう固まってるんで、すぐ作ってもらえれば」と。駆け出しの頃の俺なら、そのまま着手してたと思います。
実際、昔それでやらかしました。正常系だけ作り込んで納品したら、本番で想定外のデータが来て画面が固まる。客は「そんな話は聞いてない」、こっちは「要件になかった」。お互い悪気はないのに、誰も得しない手戻りでした。原因をたどると、結局「例外時どうするか」を誰も握ってなかっただけ。
でも一回痛い目に遭ってからは、最初に「やらない範囲」と「例外時」を握るのを習慣にしてます。その案件でも「念のため」で3つ確認したら……案の定、例外処理のところがまるっと未確定だった。客も「あー、確かに決めてなかった」と。あの時こっちから出してなかったら、また同じ手戻りを踏んでたはずです。
ここで大事なのは、客が悪びれなかったこと。責めなかったから、客も素直に詰めてくれた。もしあそこで「固まってないじゃないですか」とやってたら、たぶん防御に回って、話が進まなかった。相手の事情を分かった上で聞く。それだけで、要件定義はいい感じに楽になります。
まとめ
「要件は固まってます」は、嘘じゃない。客には客の事情があって、そう言うだけ。
- 客の心理を分かる — 上司への説明責任・着手を急ぎたい・本当にそう思い込んでる
- 未確定が残るのは3箇所 — やらないこと・例外時・承認者
- 責めずに先に握る — 念のため・こちらの確認として、こっちから出す
要件定義で仕様変更を防ぐコツは、客を変えることじゃない。こっちが先回りして抜けを拾うこと。これができると、揉める案件がぐっと減ります！！
しかもこれ、地味だけど強いスキルなんですよね。相手の心理を読んで先回りできる業務SEは、フリーランスでも引っ張りだこ。技術だけじゃない武器が、ここにあります。
よくある質問
Q1. 客に「固まってないですよね?」と聞いてはダメですか?
避けたほうがいいです。客のメンツを潰して、防御に回らせてしまいます。「念のため」「こちらの確認のため」と、自分の都合として聞くほうが、客も素直に詰めてくれます。同じことを聞くにも、立て付けで結果が変わります。
Q2. 客が「やらないこと」を決めたがりません。どうすれば?
「できないことを認めさせる」のではなく、「次フェーズに回すこと」として整理すると通りやすいです。「今回はここまで、続きは次回」と前向きな線引きにすると、客もメンツを保ったまま握れます。
Q3. 例外パターンを全部洗い出すのは大変では?
全部は要りません。代表的な異常(不正な値・途中失敗・二重操作)を2〜3個こちらから出すだけで十分です。客が「それは考えてなかった」と気づけば、残りも一緒に洗い出す流れができます。
Q4. 結局、客が悪いのでは?
そう捉えると詰みます。客を悪者にしても要件は固まりません。客は意地悪なのではなく、言語化できていないだけ。こちらが選択肢を出して言語化を助ける、と考えたほうが、仕事として前に進みます。
次に読むべき記事
要件定義で揉めてる同業がいたら、この記事ぶん投げてやってください。どんどんシェア待ってるぜ！！
以上！
執筆者
バイブス父さん — 業務 SE 7 年 (SIer 正社員 2 / フリーランス 5)。現職は SEO 直轄部の AI アドバイザー兼 PL、副業で中小 SIer の CTO。SIer の正社員からフリーランスに転じ、複数のエージェント経由で案件を回してきた経験ベースで「業務 SE 視点」の技術 + キャリア記事を書いています。
🐦 X: @hiro_progra0524 (日々の現場メモ更新中)
📝 About Me で経歴詳細を見る
