バイブス父さんの穴倉
みなさんこんにちは！ヒロポンです！
リプレース案件のキックオフ。客がにこやかに言う。「いやー、難しいことはいいんで、前のシステムと同じでいいですよ」。
ありがたい言葉です。でも、業務SEならここで背筋が伸びる。あれ、ほんまに同じでええん？？って。この「同じ」が、後でいちばん揉めるやつなんですよね。
X 見てると、要件定義のあるあるって、ほんま多い。「やらないこと」を握っとかないと後で都合よく解釈される。客に聞かないと要件が出てこない。固めたつもりが、認識ズレを後出しされる。そんな声をよく見かけます。
ただ、これは客が悪いわけじゃない。意地悪してるんでもない。「前のシステム」を、客自身もうまく言葉にできてないだけなんですよね。だから「同じ」で済ませてしまう。
この記事では、要件定義 で 認識ズレ が生まれるその瞬間を、実際の対話を再現しながら見ていきます。最後に、俺ならこう聞き直す、の質問テンプレも置いときます。
忙しい人向けに最初にまとめ
- 罠1・範囲が曖昧 — その「同じ」は画面の見た目? 機能? 運用フロー? 客の頭では混ざってる。
- 罠2・不具合も含む — 前システムの遅さや不便さも、無意識に「同じ」に入ってる。
- 罠3・仕様が不明 — 作った会社はもういない、動いてるのは見れるが中身は不明。
- 聞き直しの軸: 範囲を「画面・機能・運用」に分けて聞く。
この対話で何が起きていたか
先に結論から。「前のと同じで」の一言には、3つの違う意味が混ざってる。画面を同じにしたいのか、機能を同じにしたいのか、運用の流れを同じにしたいのか。ん？同じやろ、って思うかもですが、客の中で分かれてないだけで、作る側にとっては全部別物です。
ここを分けずに進むと、完成後に「思ってたのと違う」が顔を出す。対話を見ていきましょう。
場面設定
フリーで入った、ある業務システムのリプレース案件。10年以上使ってきた古いシステムを、まるごと作り直す、というやつです。初回のヒアリングで、客先の担当者(業務はベテラン、システムは詳しくない)と、こんな会話になりました。
固有名詞は伏せます。でも業務SEなら、「あー、これな」となるはず。
対話の再現
客「難しいことはいいんで、前のシステムと同じでいいですよ」
俺「ありがとうございます。確認なんですけど、『同じ』というのは、画面の見た目ですか? それとも処理の流れ、運用のやり方のほうですか?」
客「えっ…。うーん、両方? 使ってる感じが同じなら」
俺「なるほど。じゃあ逆に、前のシステムで『ここ不便だったな』っていう所、ありました?」
客「あー、あの検索がめちゃくちゃ遅いのは、なんとかしてほしいかな」
俺「了解です。じゃあその検索は『同じ』じゃなくて、『改善』のほうに入れますね」
客「あ、そうか。そうしてもらえると助かる」
俺「あと、前のシステムの仕様書って、残ってますか?」
客「うーん…作った会社さんがもう無くて。動いてるのは見れるんですけど、中身は、正直誰も…」
この5往復に、最初の罠が全部出てます。
どこで認識ズレが発生したか
対話の中から、3つのポイントを拾います。
罠1: 範囲が曖昧
最初の「両方? 使ってる感じが同じなら」。ここです。客は画面・機能・運用を分けて考えていない。「使ってる感じ」という、いちばん曖昧な言葉で握ろうとしてる。使ってる感じって、何が同じなん？？ってとこなんですよね。
これを「はい同じで」で流すと、作る側は画面を同じにしたつもり、客は運用が同じだと思ってた。そこでズレる。だから最初に、範囲を3つに割って聞く。
罠2: 不具合まで「同じ」に含まれる
「検索が遅いのは何とかしてほしい」。これが出た瞬間、「同じ」の中に“直してほしい所”が混ざってたことが分かります。
客は「同じ」と言いながら、頭の中では「でも不便な所は直って」と思ってる。当然です。口では「同じ」としか言わないだけ。だからこっちから「不便だった所は?」と引っ張り出して、改善対象を「同じ」から引き剥がす。これをやらないと、前システムの不具合まで忠実に再現して、後で「なんで遅いのまで同じにしたの」と言われます。
罠3: 前システムの仕様を誰も覚えてない
最後の「中身は誰も…」。これがいちばん地味で、いちばん重い。正解(前システムの仕様)が、どこにも残ってない。
仕様書がない。作った会社もいない。動いてる画面はあるけど、なぜそう動くのかは誰も説明できない。この状態で「同じ」を目指すのは、見本のない模写と同じです。だから、画面を一緒に見て、1機能ずつ「これは何のため?」を業務担当者に確認していくしかない。地道です。でも、これがいい感じに効くんです。
俺がやり直すならこう聞く
あの時の自分に言うなら、最初の一言を、こう変えます。
「『同じ』で大丈夫です。ただ、ズレると後でお互いしんどいので、3つだけ先に分けさせてください。画面の見た目、機能(できること)、運用の流れ。この3つ、それぞれ『前と同じ』でいいか、それとも変えたい所があるか、一緒に見ていきましょう」
こう言うと、客は「あ、そう言われると、画面は同じでいいけど、承認の流れは変えたいかも」と、自分から分けて話し始める。いい感じに、向こうが勝手に整理してくれるんですよね。客を問い詰めるんじゃなくて、考える枠を渡す。これが要件定義の肝です。
学んだ質問テンプレ
「前のと同じで」と言われた時に、そのまま投げられる質問を置いときます。
- 範囲が曖昧な時 → まず「『同じ』は画面・機能・運用の流れ、どれを指してますか? 一緒に分けましょう」と聞く
- 不具合も含んでそうな時 → 続けて「前のシステムで不便だった所はありましたか? それは『改善』に分けます」と聞く
- 仕様が不明な時 → 最後に「前の仕様書は残ってますか? なければ画面を見ながら1機能ずつ確認させてください」と聞く
この3つを最初の30分で聞くだけで、後の手戻りがごっそり減ります。こんな感じでテンプレにしとくと、初対面の客でも崩れません。覚えるのは「範囲・不具合・仕様の所在」の3つだけ。これが気楽でいいんですよね。
まとめ
「前のシステムと同じでいいよ」は、客の善意の言葉です。決して手抜きじゃない。ただ、その「同じ」には、3つの罠が潜んでます。
- 範囲が曖昧 — 画面・機能・運用を分けて聞く
- 不具合も含む — 前の「不便だった所」を聞いて改善に切り分ける
- 仕様が不明 — 画面を一緒に見て1機能ずつ確認する
客を責めても、要件は固まりません。客は前システムを言語化できてないだけ。こっちが考える枠を渡して、一緒に分解する。それができると、リプレース案件はぐっと事故らなくなります！！
そしてこれは、地味だけど強いスキルです。客の曖昧な言葉を、具体に翻訳できる。そういう業務SEは、フリーランスでも重宝される。技術だけじゃない武器が、ここにあります。
よくある質問
Q1. 客が範囲を分けて答えてくれない時はどうすれば?
こちらから具体例を出します。「たとえば画面はこの色・配置のまま、でも承認は2段階から1段階に、みたいに分けられますよ」と一例見せると、客が「あ、そういう分け方か」と乗ってきます。抽象的な質問より、具体例で選んでもらうほうが進みます。
Q2. 前システムの仕様書が本当に何もない時は?
動いている画面と、実際に使っている業務担当者が最大の情報源です。画面を操作してもらいながら「今、何をしましたか」「これは何のため」を聞いていくと、仕様書がなくても要件は起こせます。時間はかかります。でも、これが一番手堅いです。
Q3. 客に「全部同じでいい」と押し切られたら?
「分かりました。ただ、前システムの不便な点も含めて忠実に再現する形になりますが、それで大丈夫ですか?」と一度確認します。たいていの客は「いや、遅いのは直して」と言うので、そこから「同じ」と「改善」の切り分けが始まります。
Q4. これは要件定義の経験がないと難しいですか?
経験があるほどスムーズです。でも本質は「曖昧な言葉を、範囲を分けて聞き直す」だけ。今日の質問テンプレをそのまま使えば、はじめての要件定義でも認識ズレはかなり防げます。
次に読むべき記事
要件定義で「前のと同じ」に詰まってる同業がいたら、この記事ぶん投げてやってください。どんどんシェア待ってるぜ！！
以上！
執筆者
バイブス父さん — 業務 SE 7 年 (SIer 正社員 2 / フリーランス 5)。現職は SEO 直轄部の AI アドバイザー兼 PL、副業で中小 SIer の CTO。SIer の正社員からフリーランスに転じ、複数のエージェント経由で案件を回してきた経験ベースで「業務 SE 視点」の技術 + キャリア記事を書いています。
🐦 X: @hiro_progra0524 (日々の現場メモ更新中)
📝 About Me で経歴詳細を見る
