Research
Research

by nicoxz

エンジニアと営業が衝突する構造 日本企業に残る分業ひずみの正体

by nicoxz
URLをコピーしました
#エンジニア #営業組織 #組織設計 #プロダクト開発 #DX

はじめに

営業とエンジニアのもめ事は、個人の相性が悪いから起きるわけではありません。むしろ多くの場合、売る責任と作る責任が組織上きれいに分断され、評価指標も情報の持ち方も違うまま案件が動くことから生まれます。営業は受注と顧客関係で評価され、エンジニアは品質、納期、保守性、障害回避で評価されるため、同じ案件を見ても「急ぐべき」「止めるべき」の判断が食い違いやすいのです。

しかも2026年時点では、営業を取り巻く環境自体が変わっています。HubSpot Japanの調査では、B2B購買検討で生成AIを活用した買い手の52.4％が候補リストにない製品を追加し、55.3％が意思決定に影響したと回答しました。買い手が情報を先に集める時代には、営業は以前より早い段階で技術的な説明や確約を求められます。その負荷が整理されないまま開発へ流れ込むと、社内衝突はさらに起きやすくなります。この記事では、日本企業でこの摩擦が起きやすい理由と、避けるために何を変えるべきかを整理します。

もめ事が起きる三つの構造

受注責任と品質責任のねじれ

営業とエンジニアの最も大きな断層は、成果の定義が違うことです。営業にとっては受注、継続利用、商談速度が重要で、顧客の要望にはできるだけ前向きに応じたいという圧力がかかります。一方、エンジニアは、実装コスト、既存システムへの影響、障害リスク、技術的負債を見ています。顧客が喜ぶ提案でも、設計や運用の観点から無理があるなら止めたくなるのは当然です。

この構図は日本企業特有ではありませんが、日本では部門ごとの役割分担が強く、調整が「案件化した後」に始まりやすい点が摩擦を深めます。McKinseyは、成果の高いプロダクト組織では、事業側、プロダクト、技術、運用などの関数が最初から一つのチームとして動き、依存関係を継続的に解消すると指摘しています。逆に言えば、営業が案件を取ってから開発へ渡す古い受け渡し型では、顧客約束と実装現実がぶつかりやすいのです。

情報の分断と複数の正しさ

Atlassianは、組織のサイロ化が進むと重複作業、認識ずれ、意思決定の遅れが起きると説明しています。これは営業とエンジニアの関係にもそのまま当てはまります。営業は商談メモ、顧客温度感、競合状況を持ち、エンジニアは障害履歴、開発制約、保守負荷を持っています。しかし、その情報が同じ場所に蓄積されず、案件会議の場で初めてぶつかるなら、双方は相手が不誠実だと感じやすくなります。

問題は、どちらか一方が間違っているとは限らないことです。営業には営業の現実があり、エンジニアにはエンジニアの現実があります。サイロ化した組織では、相手の前提条件が見えないため、自分の正しさだけが強くなります。Atlassianが2025年に紹介したデータでも、多くのリーダーがスピード不足と非効率なコミュニケーションを同時に課題として挙げていました。日本企業の営業と開発の摩擦は、しばしば「性格の問題」とされますが、実態は情報設計の失敗です。

AI時代の買い手変化と前倒しされる技術説明

HubSpot Japanの2026年調査は、買い手が生成AIを使って候補製品を比較し、営業接点以前に相当量の情報を集めていることを示しました。これは営業にとって、より早い段階で深い説明を求められることを意味します。要件定義前なのに性能保証を迫られたり、他社事例との比較をその場で返したりする場面が増えれば、営業は技術的に踏み込みすぎた約束をしやすくなります。

この変化に対して、組織がプリセールスやプロダクトマネジメントを十分に挟まず、営業個人の力量に依存すると、後で必ず開発との摩擦になります。GitLabの2025年調査が示した「AI効率のパラドックス」も示唆的です。コーディングそのものは速くなっても、ツールの分断や新しい調整負荷がボトルネックになり、チームメンバーは週あたり約7時間を非効率に失っているとされます。営業と開発の間に整理機能がない組織では、この無駄がそのまま口論や手戻りとして表れます。

解決の鍵になる組織設計

手渡し型から共同責任型への転換

もめ事を減らすうえで最も効果的なのは、「営業が取ってきて開発が作る」という手渡し型をやめることです。McKinseyがいうプロダクト・オペレーティング・モデルの核心は、顧客価値に責任を持つ単位の中に、事業側と技術側を同居させることにあります。営業、プロダクト、エンジニア、カスタマーサクセスが同じ顧客成果を見れば、「売る」「作る」の対立は弱まりやすくなります。

もちろん、全社をすぐにプロダクト型へ変えるのは簡単ではありません。それでも、主要案件だけでも初期段階からエンジニアを入れる、見積もりと提案のレビューを共同で行う、受注後の仕様変更コストを可視化するといった運用は可能です。論点は、善意で仲良くすることではなく、衝突が起きにくい構造へ寄せることです。

共通指標と単一の情報源

もう一つ重要なのは、評価指標を少しでも共有することです。営業が受注額だけ、エンジニアが障害ゼロだけで評価されれば、利害は自然にずれます。受注後の利用継続率、粗利、導入までの手戻り回数、顧客満足など、双方が気にする指標を増やす必要があります。Atlassianが繰り返し強調するように、部門横断で同じ進捗と決定事項を見られる仕組みがない限り、サイロは必ず再生産されます。

日本企業では、案件管理がSFA、要件管理がスプレッドシート、開発進行が別のチケットツールという分断も珍しくありません。これでは誰が何を約束し、どこで変更が入り、何が未確定なのかが追えません。口論の多くは、実は感情ではなく観測系の欠陥です。共通の情報源を持つだけでも、衝突のかなりの部分は減らせます。

注意点・展望

注意したいのは、営業とエンジニアの対立を「営業が無理を言う」「エンジニアが顧客を見ていない」といった人格論へ落とすことです。その見方では再発防止になりません。摩擦が繰り返される組織は、役割定義、情報共有、責任分担の設計が弱いだけです。個々の優秀さで吸収できるうちは見えませんが、案件が複雑になるほど限界が出ます。

今後は、生成AIの浸透で営業接点の初期から技術論点が深く入り込み、逆にエンジニアも顧客理解を求められる場面が増えます。部門間の壁を残したままでは、もめ事は減るどころか増える可能性が高いです。日本企業で営業とエンジニアの衝突が「至るところで起きていそう」に見えるのは、まさにこの移行期に古い分業モデルが残っているからです。

まとめ

営業とエンジニアのもめ事は、珍しい失敗ではなく、受注責任と品質責任が分かれた組織で起きやすい構造問題です。情報が分断され、買い手の期待だけが先に進み、技術的制約が後から発覚するなら、衝突はむしろ自然な結果です。

解決策もまた精神論ではありません。案件の初期から技術を入れること、共通指標を持つこと、情報源を一つに寄せること、そして顧客成果に対する共同責任へ移ることです。日本企業に必要なのは、営業とエンジニアを仲良くさせることではなく、対立が起きにくい仕事の設計です。

参考資料:

関連記事

最新ニュース