基礎知識

要件と仕様は何が違うのか。認識のずれを商談の段階で防ぐ

「言った」「聞いていない」という揉め事の多くは、要件と仕様を混同したところから始まります。この記事では、両者の違いと、商談の段階で何を確定させるべきかを整理します。

目的と手段の違い

定義から始めます。

要件とは、何を実現したいかです。「毎月の集計作業を減らしたい」「顧客からの問い合わせに早く答えたい」。これは目的にあたります。

仕様とは、それをどう実現するかです。「この画面でボタンを押すと、CSVが出力される」「問い合わせを自動で分類して担当者に振り分ける」。これは手段です。

顧客が話すのは、多くの場合その中間です。「一覧をダウンロードできるようにしてほしい」。これは手段の形をしていますが、目的が語られていません。

目的を聞かずに手段だけを実装すると、完成しても課題が解決しないことがあります。

混同すると何が起きるか

実際に起きる問題を挙げます。

作ったのに使われない。要望どおりに作ったが、本当の課題は別のところにあった。最も費用の無駄が大きい失敗です。

「思っていたものと違う」。要件は合っていたが、仕様の細部で認識がずれていた。検収の段階で発覚します。

追加費用の議論になる。「当然含まれると思っていた」機能が、仕様に書かれていなかった。

いずれも、確定させる段階を分けていれば防げます。まず目的を合意し、次に手段を合意する。この順序です。

要望を要件に翻訳する

顧客の発言を、目的の形に置き換える方法を示します。

顧客が「一覧をダウンロードしたい」と言ったとき、聞くべきは「それを何に使いますか」です。

回答が「上司に報告するため」なら、目的は報告であって、ダウンロードは手段のひとつにすぎません。報告用の画面を作る、自動でメール送信する、といった代替案が成立します。

回答が「他のシステムに取り込むため」なら、そもそも直接連携したほうが早いかもしれません。

「なぜ」を一度聞くだけで、提案の幅が変わります。そしてこれは、技術知識がなくてもできる質問です。

商談で確定させる5項目

後で揉めないために、商談の段階で決めておくべきことを挙げます。

• ①目的／何が解決すればよいのか。数値で言えるとなおよい
• ②対象範囲／どの業務、どの部署、どのデータが対象か
• ③やらないこと／今回は対象外とするもの。ここを書くのが最も重要
• ④完成の定義／何ができていれば完了とするか
• ⑤前提条件／顧客側で用意するもの、決めてもらうこと

③が最も見落とされます。やることだけを書いた資料は、書かれていないものが含まれるかどうかを曖昧にします。「今回は対象外」と明記するだけで、後の議論が大幅に減ります。

⑤も重要です。顧客側の作業が止まって進まない案件は少なくありません。誰がいつまでに何を用意するかを書いておきます。

記録の残し方

商談の内容をどう残すかで、後の展開が変わります。

決まったことと、決まっていないことを分けて書く。両方を混ぜると、どこが合意済みか分からなくなります。

次に誰が何をするかを書く。持ち帰りの項目と担当、期限。ここが抜けると進みません。

その場で共有する。後日送ると、認識のずれが放置されます。可能なら会議の終わりに読み上げて確認します。

言葉を具体的にする。「対応する」「連携する」「早くする」は、解釈の幅が広すぎます。何をどうするのかまで書きます。

議事録は記録ではなく、認識を揃える道具だと考えると、書き方が変わります。

途中で変更が出たとき

要件や仕様は、進行中に変わることがあります。これ自体は避けられません。問題は扱い方です。

変更を記録する。いつ、誰が、何を、なぜ変えたか。口頭のまま進めると、後で経緯が分からなくなります。

影響を確認してから返事をする。その場で「対応します」と答えると、工数と期限に跳ね返ります。

範囲内か追加かを明示する。曖昧にしたまま進めると、請求の段階で揉めます。

まとめて扱う。変更のたびに調整するより、一定期間ごとにまとめて判断するほうが混乱が少なくなります。

変更を拒むのではなく、扱う手順を決めておくのが実務的な対応です。

営業の役割

最後に、この工程における営業の位置づけを整理します。

営業は、顧客の言葉を目的に翻訳する役割を担います。要望をそのまま伝えるだけなら、間に人が入る意味がありません。

そして、制約を顧客に説明する役割も担います。エンジニアが「難しい」と言う理由を理解し、顧客に伝わる言葉で説明する。ここができる営業は多くありません。

この2つができれば、技術知識の不足はほとんど問題になりません。逆に、技術に詳しくても翻訳ができなければ、認識のずれは防げません。

要件と仕様を区別する習慣は、その第一歩だと考えます。

確認シートの作り方

商談で聞くべきことを、毎回思い出すのは難しいものです。定型の確認項目を用意しておくと安定します。

含めるべき項目は次のとおりです。目的と、それを測る指標。対象となる業務と部署。今回やらないこと。完成の定義。顧客側で用意するもの。期限と、絶対に外せない条件。既存システムとデータの状況。

1枚に収めることが重要です。項目が多すぎると使われなくなります。

そして、その場で顧客と一緒に埋めるのが効果的です。持ち帰って作成すると、確認漏れがそのまま残ります。埋まらない欄があれば、それが次に確認すべきことです。

工程ごとに何が決まるか

要件と仕様は、一度に決まるものではありません。工程ごとに確定していきます。

• 提案・商談／目的と大まかな範囲。金額の概算
• 要件定義／何を作るかを確定。ここで範囲が固まる
• 基本設計／どう作るかの骨格。画面構成、データ構造
• 詳細設計／実装できる粒度まで具体化
• 実装・試験／作って確認する

営業が関わるのは主に最初の2つです。ここでの取り決めが、後の全工程に影響します。

逆に言えば、要件定義が終わった後の変更は、必ず費用と期間に跳ね返ります。この構造を顧客に説明しておくことが、後の交渉を楽にします。

「あとで変えられます」と安易に答えないことが、営業としての誠実さになると考えます。