ブログ

IT業界の

あるある的

な組織の課題として、

「営業と開発の仲が悪い問題」

があります。

ITに限らず、メーカーの販売部門と製造部門の間には溝があるといった話もよく聞きます。両者の距離が遠いから（職能別の組織構造だから）なのかというとそうとも限らず、製販一体の部門でも同様の問題はあります。

いずれにせよ、IT企業のセールスとエンジニアは犬猿の仲だと言われることが特に多いように思います。いったい何故なのでしょうか？

営業側からよく聞く声

エンジニアに対して、こういう批判をするセールスがよくいます。

• 努力して営業して受注決めてきたのに全然喜ばない
• 「できない」の一点張りで非協力的
• お客さんの気持ちを全然汲み取ってくれない
• システム障害を発生させておいて危機感が足りない
• 売上を作っているのは自分たちだ、売上がなければ会社は食えない

開発側からよく聞く声

一方でエンジニアからは、セールスに対してこういう批判を耳にします。

• 売上優先で納期の短い大変な仕事を取ってくる
• お客さんにいい顔して無理難題を簡単に「できます」と言ってしまう
• 技術のことを何も分かっていない（最低限の仕組みは理解して欲しい）
• 「品質を上げろ」と言うばかりでコスト等の現実を見ていない
• 開発がいなければ（売るモノがなければ）、会社は売上を作れない

One Teamになるために

どちらの言い分が正しいのでしょうか。

答えは、

「どちらも正しい」

です。どちらの言い分も正しいが故に、放置すればいつまでも平行線であるばかりか、悪循環に陥って対立がどんどん深刻化します。

つまり会社は、両者の溝を解消する仕組みを積極的に採り入れていかなければ、営業と開発が密に連携し
One Teamとしてパフォーマンスを発揮できる組織になることはできません。

「One Team」

はアイリッジのバリューのひとつで、職種や組織の垣根を越えてひとつのチームとして機能することを会社として重視しています。

この機会に、営業と開発の溝を解消する取り組みを整理してみました。

相互理解の重要性

One Teamといっても、仲良くしましょうとか相手の言うことを聞きましょうという話ではありません。それでは何も解決しません。

• 営業の言うことに従って無茶な顧客要望に対応するエンジニア
• エンジニアの言葉を鵜呑みにして顧客の要望をどんどん断るセールス

上記が優秀なセールスやエンジニアかというと、それもまた違いますよね。

組織全体としてパフォーマンスを発揮するという観点では、やはり結局は営業と開発の

相互理解を深めることが重要です。

相互理解のための施策は、以下のとおりです。

1. 情報（両者の活動状況）の可視化
   • コミュニケーション量を増やす
   • ツールを活用する
2. 両者の機能の一部移管
   • チーム型営業（開発 → 営業）
   • ものづくりへの積極的参加（営業 → 開発）

それぞれ、見ていきます。

１．情報（両者の活動状況）の可視化

相互理解のためにまずやるべきことは、両者の

コミュニケーション量を増やすことで、情報共有を促進する

ことです。コミュニケーション不足は、溝を深くする最大の原因になります。したがって接点を増やすこと、よく会話することは非常に重要です。

１−１　コミュニケーション量を増やす

コミュニケーション量を増やすためによくやるのが、営業定例にエンジニアが（開発定例にセールスが）参加する、ランチやレクリエーション的なイベントで接点を増やす等、です。

しかし、単に定例に参加するだけでは内容が分からなくて次第に発言しなくなり、いずれ内職し始めて取り組みは形骸化していきます。マネジメント層としては、より踏み込んだ対策をしたいところです。

２−１　ツールを活用する

ツールを使って簡単にできる施策があります。それは、それぞれの活動状況をシステムで共有してしまう
ことです。アイリッジのアサイン最適化ツール「Co-Assign（コーアサイン）」は、営業と開発のそれぞれの状況を可視化し、両者の橋渡しになるソリューションです。

Co-Assign（コーアサイン）を導入すると、

・商談／受注情報

どんな引き合いが来ていて、それぞれ売上見込や受注確度はどの程度か

・開発の稼働状況

メンバーがどのプロジェクトに取り組んでいて、いつ頃空きそうか

をクラウド上に一元管理することができます。

商談／受注情報はSalesforce等のSFAから、開発の稼働状況は勤怠管理システムから、それぞれ取り込むことができます。

それにより営業側は、

開発リソース状況を踏まえた提案活動

（ex. 稼働が空いてくる時期を狙って、普段なら追いかけないような案件も積極的に提案すること）ができるようになります。

一方、開発側は前もって体制の検討ができるようになります。
適材適所な精度の高いアサインは、プロジェクト炎上防止の第一歩です。

また、メンバーのスキルをタグ付け管理し、過去のプロジェクト経験も可視化されるので「誰が何をでき、何が得意で、何に詳しいのか」という情報も、部内に閉じることがありません。

Co-Assign（コーアサイン）は、営業と開発の連携を深め、組織としてのパフォーマンスを最大化できるソリューションです。

Co-Assignの資料請求はこちらの「問い合わせフォームを開く」からお願いします。

問い合わせフォームを開く

とはいえ、情報を可視化・共有するだけでは、表層的な相互理解にとどまるかも知れません。

相手の立場（なぜそう考えるのかという背景、それぞれが持っているミッション等）や業務の具体的な内容まで含めて、双方向へ深い理解を促進させましょう。

部門の壁を越えてアサイン管理を実現する方法についてはこちらの記事を確認ください。

部門の壁を超えてアサイン管理を仕組み化する方法

２． 　両者の機能の一部移管

深い理解のためには、相手の業務を実際にやってみることです。やってみるレベルではなく一部機能を移管するぐらいが理想です。

そもそも、前工程から後工程への投げっぱなしは、諸悪の根源です。

「売れたから作ってね」「作ったから売ってきてね」（要するに、「あとはよろしく」）の感覚で仕事をするセールスやエンジニアに、ハイパフォーマーは少ない印象です。

もちろん職種ごとに分業していてそれぞれの役目がありますし、すべての業務を一緒にやる訳にはいかないので、仕組みとして

バリューチェーンの境目

（つまり、仕事の受け渡しのポイント）で、共同作業を組み込むのが良いと考えます。

２−１　チーム型営業（開発 → 営業）

エンジニアが商談の現場へ出ていくことは、あらゆる面でメリットがあります。コンペには、積極的に
エンジニアも提案担当チームにアサインすることをおすすめします。

単に営業の立場を理解するためではなく、開発者にとってシステムの改善や新機能開発において顧客目線は欠かせません。

また、営業が勝手に決めたことではなく自らも参加していた場で顧客と握ったことに取り組むのであれば、仮に負荷が高くても納得感が違います。

さらに言えば、成果に反映するウェイトは低くても良いので、評価制度に組み込む等してエンジニアにも営業の数字（売上目標達成）を意識させたいところです。

２−２　ものづくりへの積極的参加（営業 → 開発）

営業も「受注したらあとは開発にお任せ（顧客窓口だけやればいい）」の姿勢は良くありません。
要件定義や設計に積極的に参加しましょう。

技術的な知識がなくても、ブレストで新機能のアイデア出しをするとか、ワイヤーフレームのラフ案を作るとか、できることはいくらでもあります。
要件定義ミーティングをファシリテートするだけでも十分だと思います。

また評価制度における施策でいえば、粗利に責任を持たせる（顧客に要件を押し込まれたらコスト増になり、粗利が圧迫される）のもひとつです。

さいごに

「営業と開発の仲が悪い問題」は、一朝一夕で解決する課題ではありません。

また王道の解決策もないと考えています。アイリッジは風通しがよくギスギスした雰囲気のない会社でいまのところ深刻な問題にはなっていませんが、これからも溝を作らないように工夫し続けたいと思います。

本記事が、セールスやエンジニアの皆さんはもちろん、組織を運営する営業部長・開発部長・CTO・VPoEなどの責任者、あるいは両者連携のジョイントとなるようなポジション（開発部内のPMリーダーや、見積り担当＆アサイン担当マネージャー等）の方の、ご参考になれば幸いです。

アサイン管理、要員管理ツール「Co-Assign」の資料請求はこちらから

そして、そんな組織に自分もジョインしてみたいと思っていただけた方、採用関連情報ページや、求人情報もぜひご覧ください！