基礎知識

営業がエンジニアと話すための最低限。技術を学ばずに会話を成立させる

エンジニアと話が噛み合わない。技術が分からないから、と考えている方が多いはずです。しかし実際の原因は、知識量ではないことがほとんどです。この記事では、何を知っていれば会話が成立するのかを整理します。

全部を学ぶ必要はない

最初に前提を示します。営業がエンジニアと同じ知識を持つ必要はありません。プログラムを書けるようになる必要も、技術用語をすべて覚える必要もありません。

必要なのは、相手が何を判断材料にしているかを理解することです。エンジニアが「難しい」と言うとき、何が難しいのか。「できます」と言うとき、どの範囲を指しているのか。

知識ではなく、構造の理解です。この記事では、その構造を扱います。

会話が噛み合わない3つの原因

実際に商談で起きるずれを分解すると、原因は3つに絞られます。

• ①範囲が曖昧／「連携する」「対応する」が、どこまでを指すのか決まっていない
• ②前提が違う／営業は結論を、エンジニアは条件を先に話す
• ③時間の感覚が違う／営業の「すぐ」は数日、エンジニアの「すぐ」は数週間のことがある

①が最も多く、最も影響が大きい問題です。「システムと連携できますか」という質問に「できます」と答えたとして、データを1件送るのか、双方向で同期するのかで工数は10倍違います。

技術用語を覚えても、この問題は解決しません。範囲を確定させる習慣のほうが効きます。

商談で聞くべきこと

顧客との商談で、後から揉めないために確認すべき項目を挙げます。

「いまどうやっているか」。新しく作る話の前に、現在の業務の流れを聞きます。ここが分からないと、何を作るべきか決まりません。

「どのデータが、どこにあるか」。どのシステムに、どんな形式で保存されているか。ここが実装の難易度を大きく左右します。

「誰が使うか」。社内の限られた人か、不特定多数の顧客か。求められる品質と安全性の水準が変わります。

「いつまでに、何が動いていればよいか」。全部が完成する期限ではなく、最低限これが動けばよいという線を聞きます。

これらはすべて技術知識なしで聞けます。そして、エンジニアが最初に知りたい情報でもあります。

避けたほうがよい言い方

社内でエンジニアと話すとき、摩擦を生みやすい表現があります。

「簡単にできますよね」。簡単かどうかは相手が決めます。この前置きは、相手に「難しい」と言わせにくくします。

「とりあえず作ってみて」。何を作るかが決まっていない状態では、作業が始められません。

「顧客が言っているので」。顧客の要望をそのまま伝えるだけでは、判断材料になりません。なぜそれが必要なのかを聞いてくるのが仕事です。

「他社はできると言っている」。条件が違えば結果も違います。比較するなら、条件も一緒に確認する必要があります。

代わりに有効なのは、「どこが難しいですか」と聞くことです。難所が分かれば、顧客に交渉する材料になります。

覚えておくと役立つ考え方

用語を暗記する必要はありませんが、いくつかの概念は知っておくと会話が速くなります。

既存のものを変えるほうが、新しく作るより難しい場合がある。動いているシステムには制約があり、影響範囲の確認が必要になります。

例外処理が工数の大半を占める。正常に動く場合の実装は早く終わります。時間がかかるのは、想定外の入力や障害への対応です。

データが揃っていないと何も始まらない。AI活用の相談で最も多い障害がこれです。

後から仕様を変えると、作り直しになることがある。建物と同じで、基礎に関わる変更は影響が大きくなります。

この4つを理解しているだけで、無理な約束を避けられます。

信頼される営業の共通点

エンジニアから信頼される営業には、共通点があります。

持ち帰る。その場で「できます」と言わず、確認してから答える。速さより正確さが評価されます。

悪い情報を早く伝える。顧客の要望が難しそうなら、早い段階で共有する。手遅れになってから伝えられるのが最も困ります。

顧客の目的を聞いてくる。「この機能が欲しい」ではなく「なぜ欲しいのか」を持ってくる営業は、代替案を提示できます。

制約を顧客に説明できる。エンジニアの説明を理解し、顧客に自分の言葉で伝えられる。これができる営業は少数です。

いずれも技術知識ではなく、仕事の進め方の問題です。

何から学ぶか

それでも技術を学びたい場合、優先順位があります。

第一に、システム構成の読み方。画面、処理、データ、基盤という4層の理解。構成図が読めると、話の全体像が掴めます。

第二に、工数がどう決まるか。見積もりの構造を知ると、価格交渉の材料が増えます。

第三に、要件と仕様の違い。この区別ができると、認識のずれを早期に発見できます。

プログラミング言語の習得は、優先度が低いと考えます。書けるようになっても、商談で使う場面はほとんどありません。それより、構造と進め方を理解するほうが実務に直結します。

実際に起きたずれの例

抽象論だけでは伝わりにくいので、典型的な事例を挙げます。

「既存システムと連携したい」。顧客は1日1回のデータ受け渡しを想定し、開発側は常時同期を想定していた。工数の見積もりが数倍ずれます。

「スマホでも見られるように」。画面が縮小表示されればよいのか、専用の操作性が必要なのか。前者と後者では作業量がまったく違います。

「検索できるように」。完全一致か、部分一致か、表記の揺れを吸収するか。要求水準によって難易度が変わります。

「セキュリティは万全に」。基準が示されないと、どこまでやればよいか決まりません。業界の規制があるのかを確認する必要があります。

いずれも、商談で一言確認すれば防げるずれです。

無理なく知識を増やす方法

業務の合間に技術を学ぶ、現実的な方法を挙げます。

• 自社の提案書を読み込む／過去の構成図と見積もりを見る。実例が最も早い教材
• エンジニアに質問する／分からない用語をその場で聞く。聞かれる側も嫌がらないことが多い
• 失注の理由を追う／技術的な理由で負けた案件を確認する
• 簡単な仕組みを触ってみる／ノーコードのツールなどで、実際に作ってみる

書籍や講座から入るより、自社の実例から入るほうが速いと考えます。使う場面が明確なため、記憶に残ります。

そして、分からないことを分からないと言えるかどうかが最も重要です。知ったふりをして進めた案件は、必ずどこかで破綻します。