エンジニア営業不仲問題って何？
いまこの記事を読んでいる人はおそらく「そういう問題あるよね」と思っているか「エンジニアってクソだよね」と思っているか「営業ってクソだよね」って思っているかのどれかだと思います。なのでまあ、いちから説明する必要はないと思うのですが、念のためこの「営業エンジニアすれ違い問題」を説明します。
基本的に営業とエンジニアが、互いに相手を自分の仕事の障害だと認識することで不仲になる現象です。
ちなみに「営業とエンジニア」と書きましたが、これ別に他の部署間でもよく起きます。
経費精算を早くしてほしい経理部と、事務仕事に時間を割きたくない現場とか。聞いたことありません？ここではわかりやすく「営業とエンジニア」で話を通しますが、本質的にはどの部署・職種・立場でも同じです。
架空のWeb開発受託会社の例
例えば、Web開発受託みたいな仕事であればこんな感じでしょうか。
営業が新しい案件を獲得します。案件はいつもとほとんど一緒ですが、クライアントの希望でささいな特徴があります。例えば、Webサイトの表示を必ず1秒以内にしてくれとか、古いAndroidでも動くようにしてくれとか、IEに対応してくれとか。
新規案件は大事です。新規開発だけじゃなく、運用保守も受注できたら、今後数年間にわたって会社の売上になります。営業としてはまずはミニマムの仕様で受注して、徐々に追加開発を提案することで売上を積んだり、数年後にサイトのリニューアルを受注する売上まで見越しています。
クライアントの担当者と仲良くなって、そこら辺はある程度握っているかもしれません。そうなってくると、クライアントの言っているささいな要求なんて、この時点で断るわけがありません。
受注まで半年。展示会で名刺交換してから長かったなあ、なんて思いながらエンジニアに話を持っていきます。脳内では第一期の最終話のエンディングが流れています。そして案件の説明を始めたところ、開始10分でエンジニアからこう言われるわけです。
「あ、それ無理ですね。受けられないです」
は？なんて？
「だってほら。まずいつも使っているVue3がAndroid 5.0以前の標準ブラウザをサポートしてないのでそれ以前のAndroidのサポートは無理です。それとサイトの表示を1秒って話、そもそもこれの表示、ってどういう定義ですか。ファーストビューだけ？それなら無茶すればできるかもですが。それでも難しいですけど。いずれにせよ普段とかなり違う実装になるので工数は相当増えます。ファーストビューじゃなくてサイト全体を1秒は今の仕様では絶対無理です。阿部寛のサイトならいけますが。あ、知ってます？阿部寛のサイト。そんでIEって。昭和ですか（笑）」
苦笑するエンジニアを見ながら営業氏は頭に血が登っていくのを感じます。こっちが半年かけてとってきた仕事を10分で否定するとは何事だ。仕事っていうのは無理を努力でどうにかすることじゃないのか。そもそも何言ってるか分からねぇ。阿部寛関係ないだろ。●ね。
かたやエンジニア。
営業から新規案件があるから打ち合わせをしたいと会議室に呼び出されます。なんとなく案件の噂は聞いていましたが、ほとんどいつもと一緒だから大丈夫と言われていたので詳しく話を聞くのは初めてです。現在案件を3本抱えていて、脳みその半分くらいは常に今詰まっているバグのことを考えています。
営業が案件の説明を始めました。なにやらクライアントの説明をしていますが、Webサイトの開発でクライアントの社長の孫の話とかどうでもいいです。早く仕様の話をしてくれ。
やっと仕様の話に入ったと思ったら、なにやら「いくつかこまい注文があるんでこれも一応先に伝えておきます」という前置きとともに、営業がすごいことを言い始めました。びっくりして、脳みその半分を占めていたバグが吹き飛びます。
会議がはじまって10分ですが、エンジニアの頭にはこれまでの15年に及ぶエンジニア人生がフラッシュバックしています。この仕様の開発は実現性があるか？大量の技術知識を探索します。結論としては一部は不可能、一部は「技術的には可能」。ただ「技術的に可能」なことをできますと言っちゃいけないのはエンジニアの中では常識です。さらに、この時点でエンジニアの頭には運用と保守のオペレーションまで検討に入っています。最初、無理やり実現したとしても、どこかで必ず無理がきます。外部のライブラリが使えなくなったタイミングで膨大なマイグレーション作業が発生します。それを少ない保守の工数で回すのは不可能です。無理。絶対無理。
というかこの人、さっきなんて言った？「こまい注文」を「一応伝える」とか言ってなかったか？きちんと事実を突きつけないといけないようです。
「あ、それ無理ですね。受けられないです」
……なんか書いてたら楽しくなって長くなりましたが、こんな感じです。
ほら、世界中で毎日起こってそうでしょ？
どうしてこの問題がおきるのか
上の例を読んだみなさんは、おそらく営業もエンジニアももっとうまく立ち回れたんじゃないの？って思ってるはずです。言いたいことがたくさんあるでしょう。分かります。
でも大事なのはそこじゃなくて、ポイントは営業もエンジニアも悪気がないってことなんです。どちらも自分の仕事を全うしようとしているし、別に相手の邪魔をしようとしているわけじゃない。同じ会社に所属してるわけですから、貢献したいと思っている対象も同じです。それなのになんでこんなことが起きるのか。不思議。
最初に載せたツイートにも書いたとおり、この問題が起きる原因は3つです。
- 知識のすれ違い
- ゴールのすれ違い
- コミュニケーションスタイルのすれ違い
それぞれ見ていきましょう。
ちなみにこれらは独立ではなく、1 → 2 → 3の順で因果関係があります。原因 → 結果です。
知識のすれ違い
まずひとつめ、知識のすれ違いです。
自明ながら、営業とエンジニアは持っている知識が違います。これは職能に関する専門知識はもちろんですが、会社の状況に対する知識（認識）や、議題になっている案件についての知識も異なります。会社に対する知識というのは、例えば営業は今期の会社の売上がやばいことが課題だと知っていて、エンジニアは来月発生する大規模改修の工数がやばいことを知っている、みたいな感じです。
簡単のために知識と言っていますが、知識のもととなる経験や、知識に基づく認識も違います。
ポイントは異なる知識にもとづいて下された意思決定は異なって当然、ということです。
ゴールのすれ違い
ふたつめはゴールのすれ違いです。
これは知識が異なることによって、それぞれのゴールが違うということです。優先順位が違うと言い換えてもよいです。
多くの会社では個人ごとに目標みたいなやつが決まってたりします。四半期とか一年とか、MBOとかOKRとか形態はいろいろですが。これが決まってないと上司が評価できないからです。評価制度の話を始めると長くなるので割愛。それで、エンジニアと営業で目標が違うのは想像に難くないと思います。
でも、ここで言っているゴールとか優先順位っていうのはそれとは少し違います。もっと本能的なものです。仕事をしていくうえでのポリシーとか、プライドとか、そういうものです。これを譲ったら自分の存在価値がなくなるよね、みたいな。アイデンティティのことです。
営業は売上を立てることで会社を支えているという自負があります。売上は会社にとって最も大事なものですから（いや利益だろ、みたいな議論はここではしないです）。
一方でエンジニアは……エンジニアはいろんな派閥がある気がしますが、少なくとも共通して、自分たちが作り出すものこそが会社の価値だという自負があるはずです。
ポイントは、異なるゴールを持った人たちが同じ意思決定を下すことはないという点です。
せっかくなのでこのゴールについて、少し私の経験を書きます。
Googleでネット広告の技術営業的な仕事をしていたときの話です。私の仕事のひとつは、クライアントから報告を受けたバグの調査をして、クライアントへの影響を調べて、回避策を検討して、必要に応じてエンジニアといっしょにそれを直すことでした。
御存知の通り世の中のWebサービスは常に山のようなバグリストを抱えていて、それはGoogleの広告製品も同様です。大抵は細かいものですが、時にはクライアントの売上に大きな影響を与えるバグが発生することがあります。
そうすると私は色々調べて「日本のXXっていう超大手クライアントがこのバグの影響を受けてる。すぐ直さないとXX円の売上が吹っ飛ぶ。多分原因はここだからいますぐ直してくれ」みたいなことをエンジニア伝えます。そして、わりと放置されます。エンジニアからするとそれは大量にある「最優先」のバグリストの一つでしかないので。売上なんて知ったこっちゃない。
この優先度をあげてもらう手法の一つとして当時先輩から習ったのが「このバグはGoogleとして恥ずかしいです。Googleの製品はもっとユーザーフレンドリーで高品質あるべきです」みたいなコミュニケーションです。
もちろんエンジニアによりますが、売上の話よりもよっぽどこういった話のほうが琴線に触れる人がいたのが印象的でした。
コミュニケーションスタイルのすれ違い
さて話を戻しますね。さいごがコミュニケーションスタイルの違いです。
表面的には大きな問題です。知識とゴール・優先順位が違うと、コミュニケーションスタイルが変わってきます。同じ日本語だっけ？という空気が流れます。
人は基本的にゴールを念頭においてコミュニケーションを取ります。ゴールを念頭に置く、とは、コミュニケーションで力点を置くべき箇所をどこにするかが各自のゴールに依存するということです。
例えば、多くのエンジニアにとって大事なのは正確さです。Webサイトの表示速度をあげる話が出たら、脳内にChromeの開発者向け画面が浮かんで、表示速度ってどこまでだ？ってなるでしょう。そうしたら「表示の定義はなんですか？」という話になるのは必定です。
想定している仕様のなかでローディングのボトルネックになりそうな部分を考えて、絶対に削れない部分、表示後に回せる部分なんかを脳内で検討します。不用意なことを約束して困るのは営業だと思っているので、これは営業のためでもあると思っています。で
すから「正確なコミュニケーション」を求めます。正確なコミュニケーションにはある程度専門用語が出てきます。Androidのバージョンについて単に「古い端末」ということもできますが、正確さを期すならバージョンの番号を言うべきだし、それが使えない理由を説明するのに使っているライブラリやフレームワークの説明は不可避です。
エンジニアのゴールは仕様通りの製品を作ることですから、曖昧さは将来の問題を引き起こす悪でしかありません。
一方で営業にとって大事なのは売上で、クライアントが満足することです。
営業も、クライアントだって「Webサイトの表示」の定義なんて考えたこともありません。そんな概念あったのか、って感じです。正直、そこはどうでもいいのです。なんなら、1秒っていう数字だって別にマストじゃない。営業が言いたいのは「サクッと見れるサイトにしてほしい」ということです。これだって、実は社長が孫から「最近みたウェブサイトが遅かった」という話をされたのが原因だったりするので、わりとどうでも良い話です。
ただ、エンジニアはおそらく数字を言ったほうが助かるとおもって「1秒で表示されるWebサイトを作ってほしい」と言ったわけです。別に契約書に1秒って書いてあるわけじゃないです。営業のゴールは仕様通りの製品を届けることはなく、クライアントを満足させることです。これはイコールのようで、だいたい違います。
その余地を探るためのコミュニケーションでは必ず曖昧性や冗長性が生まれます。
結果的に「正確で冷酷で何言ってるかわからんやつ」と「曖昧で適当で無責任なやつ」の対立が出来上がるのです。
ちなみにエンジニアとか営業とか関係なく、このコミュニケーションスタイルというのは本当に十人十色です。
どういったコミュニケーションが刺さるのかは人それぞれなので、注意が必要です。自分のスタイルが正しいと思っているとやけどします。
私は素では冗長なコミュニケーション（雑談みたいな雰囲気のやつ）が好きなのですが、相手の好みにや状況よってかなり調整してます。
ここまで長々と書いてきましたが、ポイントは2つだけです。
- すれ違いは避けられない
- どっちも悪気はない
すれ違いは避けられないのか
すれ違いは悪いことではない
よく言われる話として「エンジニアが営業の考えがわかればよい」とかその逆とかが言われますが、それってめちゃくちゃコスパ悪いです。たしかに理想ではあるのですが、これは別に営業とエンジニアだけの話題ではありません。社内にはいろいろな部署、職種があり、互いの立場を真に理解するのは不可能です。
会社というのは様々な専門性をもった人が集まることでひとつの目標を達成しよう、という組織なわけで、そもそも各自が別の視点で物事を考えている事自体は望むところなのです。
ちなみにこれこそが本当に会社に求められる多様性だと思っていますが、多様性の話は長くなるので割愛。
意見がすれ違うこと自体は別に良いのです。それは避けられないし、避ける必要もない。みんな同じ意見だったら複数の人がいる意味ないですから。
大事なのは、相手が別の知識とゴールとコミュニケーションスタイルを持った人だということを認識して、相手の知識とゴールとコミュニケーションスタイルを尊重すること。
これを私は相手をリスペクトすることだと呼んでいて、生きていくうえで最も重要なスキルの一つだと信じています。
相手をリスペクトすること
相手へのリスペクトがない状態というのは、相手が自分と同じ知識とゴールとコミュニケーションスタイルだという前提でコミュニケーションをすることです。そうすると、例えば営業的には「売上がいちばん大事なはずなのにこいつ何言ってるんだ」となるし、エンジニアからすると「技術的な実現性や保守性が大事なのにこいつ何いってんだ」となるわけです。
しかしリスペクトがあればどうでしょうか。そうしたら、少なくとも相手が自分とは違うゴールを持った人だということを想定します。そうであれば、例えば営業視点では「売上は大事だけど、このエンジニアはきちんと責任を果たそうとしてくれてるんだな」となるわけです。
以前どこかで読んだアンガーマネジメントの本に、人と人の対立は互いの「べき」がぶつかるところで生じると書いてあって、とても腑に落ちた覚えがあります。「こうあるべき」ということは人によって違う。客観的に考えたら当たり前のことですが、これを日常的に意識できている人は非常に稀です。
ちなみに念のために言っておくと、まじでただ単純に性格が悪いやつというのはいます。ここまで、営業もエンジニアも悪意がなくて〜と書いてきましたが、職種によらず悪意100％みたいな人はたまにいます。それはもうしょうがないです。諦めてください。ただそういう人って本当に稀で、ある種サイコパスみたいな話なので、あなたが他人に対して「悪意だ」と感じていることの9割はおそらく「知識とゴールとコミュニケーションスタイルの違い」から生じるすれ違いにすぎません。
リスペクトで解決しない問題
やりました！リスペクトがあれば営業とエンジニアは一緒にうまく働けるわけです！！
と、言いたいところですが、世の中はそんなに甘くありません。
リスペクトがあっても「喧嘩にならない」だけで根本的な問題は解決しません。
なぜかといえば、相手が自分と異なる知識やゴールやコミュニケーションスタイルを持った人だということを理解したとしても、相手が考えている内容自体はわからないからです。
これは別に友達同士とかだったら良いのですが、一緒に仕事をするとなると困ります。なにかのプロジェクトを一緒に達成しないといけないわけなので。
だから、仲介役が必要なのです。
仲介役の仕事はなんなのか
仲介役の役割はなんなのでしょうか。
これはよく勘違いされることですが、両者の愚痴を聞くことではありません。緩衝材と呼ばれたりもするので、「ストレスを緩和する役割」みたいなイメージがあるかもしれませんが、そんなのはAIとかアルコールとかに任せればいいんです。
仲介役の主な役割
仲介役の主な仕事は通訳と課題解決です。
通訳というのはわかりやすいと思います。直接話しても互いの意思疎通が難しい場合、互いに何を言いたいのかという真のメッセージを解釈して、相手にとって意味のある内容に変換して伝えるわけです。
注意しないといけないのは、単に分かりやすく説明するのが仕事ではないという点です。エンジニアの言っていることは専門的すぎて分かりづらいので、それをわかりやすい表現に変えて伝える。みたいな話ではありません。
そうではなく、エンジニアの言っていることが営業にとってどういう意味を持つのか（逆もしかり）を考えて、さらに落とし所も考えたうえで話を伝えるのが仲介役の仕事です。
この落とし所を考える、というのが「課題解決」というところです。前述の通り、知識もゴールも違う人達の下す意思決定は異なるのが普通です。そのままでは困るので、互いの言い分を解釈し、最も良い妥協点を見つけて誘導するのが仲介役の仕事です。
仲介役の仕事を具体的に
例えば、前に挙げた例で営業から「古いAndroidでも使えるように」という要望がありました。そしてエンジニアから「いつもの実装方法だとAndroid 5.0以前はサポートできない」という意見が出ていました（ちなみにこの表現が技術的に厳密ではないことはChatGPTに教えてもらっているのですがわかりやすさを優先しているので怒らないでください）。
これを例に仲介役がどんな仕事をするかを書いてみます。
まずこの時点で、最終的な落とし所は「無理にでもAndroid 5.0以前をサポートする」か「Android 5.0以前はサポートしないことをクライアントに飲んでもらうか」の2択です。
ですから、エンジニアには「Android 5.0以前をサポートするのがうちの会社にとってどれだけ大変か」を聞きます。
エンジニアチーム全体で使っているフレームワークが使えないとか、色んな話が出てくると思います。5分も立ち話すれば、これは相当めんどくさそうだぞ、ということが分かります。
一方で営業に、どうして古いAndroidの対応を先方が求めているのかを聞きます。そこで、今回のクライアントはWebメディアで広告でのマネタイズをしているため、少しでもサイトの訪問数を減らしたくないという話を聞きます。なるほど、社長が使っているAndroidが古くてそれに対応しないといけない、みたいな話だとややこしかったのですが、これならなんとかなりそうです。
さらに念のため、ちらっとググって情報をあつめます。いまだったらAIに聞いても良いかもです。
それで営業さんのところに行ってこんなふうに伝えるわけです。
「広告でマネタイズしているメディアということで、できるだけインプレッションを増やしたいという事情はよくわかります。ただ、実はAndroid 5.0以前のスマホの利用率って世界でも1%もなくて、日本ではほぼゼロなんですよ。Android 5.0ってLINEの最新バージョンすら使えないくらい古いんです。それに無理に対応しようとすると工数もかかっちゃうし、古いフレームワークを使うことで結果的にサイトの表示速度も落ちちゃうので、総合的にはクライアントにとってマイナスだと思います。LINE使えないくらい古いやつは流石に対応しなくていいですよね、って感じで一度クライアントさんに確認いただいてもいいですか？必要なら私が直接話すので言ってください！」
これなら営業も「あー、それはたしかにっすね。OKっす。言っときます」って感じで終わります。
一方でエンジニアには「さすがにLolipop（= Android 5.0）対応まではしなくていいと思うんですけど、なんか特殊事情あるかもなんで一応確認しておきます」といった感じで伝えておきます。
最終的にはクライアントのOKが取れたところでエンジニアにも決定事項を伝えて終了です。
ぶっちゃけこれはめちゃくちゃ丁寧に対応している例ですし、このくらいだったら多少勘所のあるエンジニアと営業であれば直接解決しちゃうと思うのですが、イメージは持ってもらえたかと思います。
ただ丁寧といっても仲介役の実働時間としては30分程度ではないでしょうか。エンジニアと営業が喧嘩して無駄に時間を浪費するよりよほどよいですよね。
仲介役って辛いの？
私が冒頭のツイートをしたところ、引用RTで多く見た意見が「この緩衝材はつらい」とか「闇落ちする」みたいなやつでした。意見が対立する人々に挟まれて調整する仕事って普通に考えると辛いのでその通りなのですが、本当は「すべての人から感謝される存在」になれる立場でもあるんです。
営業にとっては「話の通じるエンジニア」ですし、エンジニアにとっては「話の通じる営業」であって、かつプロジェクトの交通整理をしてくれる旗振り役でもあるわけです。感謝されないわけがない。
これを愚痴を聞く役割、とか、怒っているのをなだめる役割、みたいに受け取ってしまうと辛いのですが、そこはあくまで仲介役。仮に営業が「あのエンジニア性格悪くないですか？まじムカつくんですけど」みたいな感じの話をしてきても、適当に受け流せば良いのです。そこで義憤にかられてエンジニアを擁護したり、逆に営業と一緒に怒ったりとしていると、感情がつかれてしまいます。別に学校の先生ではないので、そこまでの役割をする必要はありません。
ただ、もし仲介役の人が「そういうことが好きなタイプ」なら、ついでに二人の仲を取り持ってあげるのもありです。「いやー、あのひとちょっと細かいところもありますけど仕事すごい丁寧ですよ。あと、そういえば営業さんと一緒でキャンプ趣味だって言ってたので、こんど話してみては？」とか。
うちには仲介役がいない？
だいたい書きたいことは書いた気がするのですが、冒頭のツイートの引用で「うちにそんな部署はない」みたいな話をしている方がたくさんいたので、その場合どうするのが良いかを考えてみようとおもいます。
実はそもそも仲介役なんていう仕事はない
正直「エンジニア」や「営業」みたいな役割はいないと困るのは誰の目にも明らかなのですが、「仲介役」が必要なんていうことを理解している経営者の人はあまりいないと思いますし、認識していたとしてもその部署を作るだけの資金的余裕がある会社も少ないのが事実だと思います。受託案件の見積もりに「仲介役」という項目で人件費を入れたらクライアントから怒られそうです。
実は、単なる仲介役という職業はありません。実際には、例えば私が今までやってきた「技術営業」とか「プロダクトマネージャー」とか「制作進行」とかそこらへんが仲介役になることが多いです。
大抵の場合、意図してか意図せずかこの役割を担っているはずです。というか、自分の仕事を完遂するためには「仲介せざるを得ない」という役職の人がいるはずで、その人が仲介役です。例えばプロダクトマネージャーなんかは良い例ですね。
仲介役が幸せになるには
個人的に大事だと思うのは、会社として仲介役という役割を仕事として認めてあげることです。なんとなく両方できるからやってる、みたいな人が多いので、ボランティアっぽくなりがちなのがこの仕事です。
前項で「仲介役は楽しいよ」みたいなことをちらっと書きましたが、とはいえ色んな人と話して調整するのは精神的にも時間的にも辛いことが多い仕事です。
ですから、会社にその働きを認識されずにボランティアでやっていると、それはまあ病みます。あるいは仲介を諦めて、営業かエンジニアかどちらかにベッタリと寄ってしまったりします。
ですから、会社や上司が「仲介はこの人の仕事の大事な要素である」と認めてあげることです。
もちろん大事なのは「仲介をすること」自体ではなく、その結果として良いアウトプットがでることですが、そのときに「君の仲介のお陰でみんなが満足する良いアウトプットになったね」ということを上司が認識していることを示す（さらにそれが評価に反映される）だけで、相当感じ方が違います。
会社やチームによっては「エンジニア/営業だけど仲介役やってる」みたいな人もいると思います。引用RTでもこういう方がたくさんいました。まじでお疲れ様です。
これも会社やプロジェクトのフェーズ的に仕方がないケースは全然あるので、大事なのはそれがボランティアにならないように、きちんと評価につながるようにすることです。実際に、そういう仲介的な動きができるエンジニア/営業の人ってめちゃくちゃ重宝されると思うので、実はかなり評価されているケースも少なくないのでは？と思います。そうだといいな
コメント