「言われた通りに作ったのに、『こういうことじゃない』と言われた」
システム開発に関わったことがある人なら、一度は味わったことのある場面だと思います。発注側から見れば「要望は伝えたのに、全然違うものができてきた」。受注側から見れば「書いてある通りに作ったのに」。どちらも嘘はついていません。それでも、ずれる。
私はIT業界で25年、COBOLの時代からPL・PMとして現場に立ってきました。その中で、プロジェクトのつまずきを遡っていくと、かなりの割合で最初の要件定義にたどり着きます。
この記事では、要件定義がうまくいかない根本の原因と、私が現場で実際にやっている進め方をまとめます。
要件定義がずれる、たったひとつの原因
結論から言うと、ずれる原因は「言葉だけを聞いている」ことです。
お客様が口にする要望は、たいてい本当に求めていることの一部でしかありません。しかも多くの場合、ご本人の中でも整理できていない。正しく言語化できていないのです。
それは相手の能力の問題ではありません。業務の当事者ほど、自分の業務は「当たり前」になっていて、言葉にする必要を感じていないからです。
だから、言葉をそのまま書き写して仕様にすると、言葉にならなかった部分がまるごと抜け落ちます。それが後から「こういうことじゃない」として表に出てくる。
「要求定義」と「要件定義」は別の仕事
ここで、私が現場で区別している2つの工程を整理しておきます。
| 工程 | やること | ゴール |
|---|---|---|
| 要求定義 | 言葉の背景、言葉にできていないが求めていることを拾い、落とし所まで含めて具体的にイメージしてもらう | 「どのレベルで解決できれば許容範囲か」を確認できている |
| 要件定義 | 要求をもとに、やる／やらない、やるならいつ頃までにやるのかを決める | 実現する範囲と時期が合意できている |
多くの現場では、この2つが混ざったまま進んでいます。要求がはっきりしないまま「何を作るか」の議論に入るので、議論が空中戦になる。
順番は必ず、要求を掘り当ててから、要件として線を引くです。
「許容範囲」を確認するのがポイント
要求定義で見落とされがちなのが、「どのレベルで解決できれば許容範囲か」の確認です。
たとえば「入力の手間を減らしたい」という要望があったとします。
- 完全に自動化しないと意味がないのか
- 入力項目が半分になれば十分なのか
- 月末の繁忙期だけ楽になればいいのか
どれも同じ「入力の手間を減らしたい」です。でも、作るものもコストもまったく違います。ここを確かめないまま進むと、作りすぎるか、足りないかのどちらかになります。
本音を引き出す「仮の言語化」という進め方
では、相手自身も言語化できていない要求を、どうやって拾うのか。
私が一番効果を感じているのは、こちらが先に仮で言語化して、違うところを相手に指摘してもらう進め方です。
白紙で聞くより、たたき台を出す
「何かご要望はありますか？」と白紙で聞いても、出てくるのは表面的な言葉だけです。人は、ゼロから言葉にするのは苦手でも、目の前にあるものの「ここが違う」を指摘するのは得意だからです。
だから、ヒアリングで聞いた断片から、
「つまり、こういうことで困っていて、こうなれば解決という理解で合っていますか？」
と、あえて言い切った形で返します。外れていても構いません。むしろ外れたところに、言葉になっていなかった本音が出てきます。
表面ではなく「内面の課題感」に触れる
もうひとつ大事なのは、何を聞くかです。
「どんな機能が欲しいですか」ではなく、
- いま、何に一番困っているか
- それが起きたとき、どんな気持ちになるか
- 誰に、何を言われるのがつらいのか
と、困りごとから、怒りや焦りといった感情につながる部分まで触れていきます。
機能の話は表面です。感情の話は本音です。「この作業のせいで毎月残業になって、上からは『まだ終わらないのか』と言われる」──ここまで聞けると、本当に解決すべきことが見えてきます。
いくつか聞くと、共通点が浮かび上がる
内面の課題感を2つ、3つと聞いていくと、その間に共通点や関連性が見えてきます。
「Aの困りごと」と「Bの困りごと」が、実は同じ根っこから出ている。そういうことが本当によくあります。その根っこを整理して言葉にし、また相手に返す。この往復が、要求定義の本体です。
要件定義でよくある失敗3つ
ここからは、現場でよく見る失敗パターンです。
失敗1：完成イメージを先に作ってしまう
「こんなシステムが欲しい」という完成イメージから入ると、議論が「何を実現したいか」ではなく「どう見えるか」になります。結果として、本当に必要な機能が抜け、不要な機能が盛り込まれます。
失敗2：画面イメージが、かえって邪魔をする
親切のつもりで用意した画面のスケッチに、受注側は引っ張られます。「この画面を作ればいい」と解釈してしまい、画面の裏にある「本当にやりたいこと」が読み取れなくなる。画面イメージは、要件が固まってから作るものです。
失敗3：半端な開発知識が、議論を早送りしてしまう
社内に少しだけ開発経験のある人がいると、一見心強く見えます。ただ、上流工程の経験がないと、「何を決めるべきか」より先に「どう実装するか」の議論に入ってしまいます。土台がないまま設計が進み、あとで「そういう意味じゃなかった」が頻発します。
3つとも、根っこは同じです。要求を掘り当てる前に、作るものの話を始めてしまうこと。
要件定義の進め方：5つのステップ
ここまでの内容を、実際の手順に落とします。
- 困りごとを聞く
機能ではなく「何に困っているか」から入る。感情に触れるところまで聞く。 - 仮に言語化して返す
「つまり〇〇という理解で合っていますか？」と言い切りの形で返し、違うところを指摘してもらう。 - 共通の根っこを見つける
複数の困りごとの共通点を整理し、本当に解決すべきことを言葉にする。 - 許容範囲を確認する
「どのレベルで解決できれば十分か」を、具体的な状態で合意する。ここまでが要求定義。 - やる／やらない／いつやるを決める
要求に優先順位をつけ、今回の範囲と時期に線を引く。ここからが要件定義。
言葉の定義をそろえる
もうひとつ、全工程を通して意識してほしいのが言葉の定義です。
「承認」「確認」「完了」「通知」。同じ言葉でも、発注側と受注側、部署ごとに意味が違うことは珍しくありません。用語の意味をそろえるだけで、認識のずれはかなり減ります。
決めたことは、理由と一緒に残す
最後に、決めたことは必ず書いて残します。それも「何を決めたか」だけでなく、「なぜそう決めたか」まで。
後から仕様の議論が蒸し返されたとき、助けてくれるのは決定事項ではなく、決めた理由の方です。残し方は、課題管理表の運用ルールとも共通する考え方です。
まとめ：要件定義は「聞く技術」より「返す技術」
- ずれの原因は、言葉だけを聞いていること
- 要求定義（本音と許容範囲を掘り当てる）と、要件定義（やる／やらない／いつを決める）は別の仕事
- 白紙で聞かず、仮に言語化して返し、違うところを指摘してもらう
- 機能ではなく、困りごとと感情に触れる
- 決めたことは、理由と一緒に残す
要件定義というと「よく聞くこと」が大事だと言われます。それも正しいのですが、私の実感では、それ以上に大事なのはよく返すことです。相手の言葉にならない部分を、こちらが仮の言葉にして差し出す。その往復の中でしか、本当の要求は姿を現しません。
要件が固まったら、次は作業の分解です。進め方はWBS作成のコツにまとめています。
あわせて読みたい
西村 幸一 / Open Field
IT業界25年。PM支援・要件定義・Excel業務効率化。
X：@kn_246
