これまで2回にわたり、営業と開発のそれぞれの部門別にプロジェクト管理に関するテーマをとりあげてきましたが、プロジェクトは本来多くのメンバーが関わるため、一つのチームの努力だけでは成立しません。

そこで今回は、プロジェクトを成功させるために、営業と開発が協力していく状態をつくるにはどうするのが良いのかをテーマにとりあげたいと思います。

営業と開発は立場が違う？～よく言われる対立の要因

営業と開発の部門のチーム形成を考えるにあたり、まず、昔からよく指摘される営業と開発のそれぞれの立場や関係について考えてみたいと思います。
営業部門は、開発だけでなく、製造や制作など現場でプロジェクトを実行する部署と対立しがちという点は、昔からよく指摘されています。
では、なぜそのような関係になってしまうのでしょうか。

理由１：目標（見ている指標）の違い

まず、大きな原因が、それぞれの部署にとっての目標や見ている指標が異なる点です。

営業は、いかに案件を受注するかといった成約数や、売上金額を業績目標として課せられています。
一方で、開発現場の目標は、依頼されたシステム（または製品やサービス）を一定の品質で期日通りに完成させることです。
この両者の目標は、残念ながら相関関係になっておらず、ときとして相反する方向に動いてしまいます。

営業では、成約をとるために、競合他社より価格を下げたり、顧客の要望に沿って急ぎの案件を受注したりといったこともあり得ます。ときには自社のリソースや経験を見合わない規模の案件を受注することもあるかもしれません。
しかし、営業が受注した案件が本来必要なリソースに見合っていなければ、開発現場としてはリスクが高く、責務を全うできないのではと考えます。

営業は、いかに案件を受注するかといった成約数や、売上金額を業績目標として課せられています。成約をとるために、競合他社より価格を下げたり、顧客の要望に沿って急ぎの案件を受注したりといったこともあり得ます。
また、ときには自社のリソースや経験を見合わない規模の案件を受注することもあるかもしれません。

一方で、開発現場の目標は、依頼されたシステム（または製品やサービス）を一定の品質で期日通りに完成させることです。よって、営業が受注した案件が本来必要な工数に見合っていなければ、開発現場としてはリスクが高く、責務を全うできないのではと考えます。

営業としては、「せっかくとってきた案件を現場が受けてくれない」となり
開発としては、「なぜ営業はこんな案件を受けたのだろう」となり、双方が不満を抱くという結果になります。

理由２：情報の共有不足

情報の共有不足も対立構造を生む原因です。具体的には、顧客の要望や前提条件などが営業から開発へ十分に共有されていないというケースです。
クリティカルな内容ほど、実現可否や期日に影響が出るため、開発側では「もっと早く共有をしてくれれば」といった営業への不満につながります。

共有不足の背景には、単なる伝え漏れもあれば、顧客へのヒアリングが不十分だったり、そもそもヒアリグすべき重要事項との認識が、営業と開発の間でなされていなかったりといったことも考えられます。

理由３：仕様・要望の変更に伴う対応

実際にプロジェクトが進むにつれて、当初の金額や期日では実現できないとなることも、プロジェクト案件では珍しくありません。
よくある理由の一つは、要望が膨らんできたり、途中で仕様変更が発生したりといったケースです。営業としてはクライアントの意向をできるだけ叶えたいと考えますが、納期の延長や追加発注をせずに安易に受けてしまうと、開発現場に無理な稼働が発生し、質の低下や事故にもつながり兼ねません。

開発側もなんとか対応しようと判断したものの、予想以上に時間がかかり期日に間に合わないとなった場合、営業がクライアントとの調整に入ることになるため、結果的には双方に信頼感を損なう結果となってしまいます。

営業と開発のチームビルディングを成功させるには

それでは、このような対立構造を解消し、両者がチームとなってプロジェクトを進めるには、どのようにすれば良いでしょうか。

営業と開発が同じ目標をもつ

チームとしてプロジェクトを進めるためには、第一に、営業と開発現場のチームが同じ目標を共有することが重要です。
営業は売上、開発は質や納期といった異なる目標ではなく、同じ指標にフォーカスすることで、お互いに協力しやすい体制が生まれます。
わかりやすい数値目標としては、プロジェクトの利益率です。

利益率を両者の目標とすれば、営業側でも工数ギリギリに抑えた値下げ交渉をして受注を取ることもなく、開発側も質を担保しつつ数字を意識しながらプロジェクトを進めていくことになります。

利益率を可視化するには、原価や外注費など工数の算出も必要のため、目標として設定をするには難しいと考える企業もあるかもしれませんが、システムを使うことで効率的に算出することが可能です。（詳細は前回の記事「プロジェクトが気づいたら赤字に～そんなPMの方にSalesforceをお勧めしたい理由」をご覧ください。）

ただ、利益率をあげるために人件費などのリソースを抑えた結果、開発側に無理な稼働を強いることになっては根本的な解決にはならないため、目標設定とあわせて注意が必要です。

社内ルールを決める

二つ目は、見積もりや提案段階において、社内ルールを設定することです。

例えば、値下げが必要になった場合、一定の割合までなら現場で判断して良いがそれ以上は上長の判断を仰ぐといったルールや、売上以外に会社としてのメリットがある場合（実績として欲しい案件、将来的に拡大が見込めるなど）は値下げを了承して良い、といったようなルールです。

ルールを設定することで、属人的な判断に偏らず、営業や開発の両者にとって納得感をもって進めやすくなります。

ただし、ルールを設定した結果、一部にメリットが偏ったり、しわ寄せがきたりする結果では意味がありません。単に値下げの行うかの判断基準だけでなく、実績づくりへの貢献が評価される、開発メンバーのスキル向上に繋がるというように、会社にとってのメリットが個人にも還元される仕組みにすることで、双方が協力しあえる体制づくりにつながります。

営業・開発が互いにフィードバックをする

一つのプロジェクトの開始から完了において、営業は主に受注までの前工程、開発は納品までの後工程と役割が分かれます。そのため、営業は受注をして案件を渡してしまえば終了となり、開発も納品が完了した後に、営業への報告をしていないケースが多いのではないでしょうか。

チーム内での振り返りや上司からのフィードバックはあっても、部門間でフィードバックをする機会はあまりないでしょう。

しかし、これまでの説明の通り、プロジェクト単位の仕事というのは、営業や開発を含めた複数の部署が関わっているため、プロジェクトごとに担当営業と開発のメンバーで振り返りの場をもつということも重要です。案件の選定や提案内容、プロジェクトの進め方、良かった点や苦労した点を互いに振り返ることで、プロジェクトをより進めやすくするための改善点や協力しあうマインドの形成に繋がります。

共有の仕組みを持つ

4つ目は情報共有の仕組みや勉強の場を持つということです。
顧客の要望などプロジェクトに関する日々の進捗をタイムリーに共有することはもちろん、互いの業務に関するナレッジ共有が重要です。開発現場のエンジニアが営業に同行したり、営業向けに技術的な勉強会を開いたりといったことを実施している企業もあるでしょう。
特に、提案段階でヒアリングしておくべき前提条件など、開発案件の営業には高度な知識が要求されます。
開発に連携すべきことをあらかじめ把握しておくことで共有もスムーズに進みますので、日頃から技術的なナレッジを身につけられる場があると良いでしょう。

チームビルディングの構築に役立つSalesforce

以上のように、営業と開発が互いに協力し合う体制をつくるには、業務ルールや日々の運用などの仕組みづくりが重要ですが、それを可能にするのがシステムの活用です。

Salesforceでは、見積もりからプロジェクトの利益率を算出したり、進捗をダッシュボードとして可視化・共有したりというように、営業と開発が同じ目標を軸としてコミュニケーションをすることが可能です。また、Salesforceを基盤としたサービスを組みあわせることで、商談、契約、プロジェクト、請求といったあらゆるデータを連携し、顧客に紐づけて一元管理ができます。

また、日々の顧客とのやり取りや営業の活動記録、議事録といった社内外のやりとりもチャット機能「Chatter」やコラボレーションツールSalesforce Anywhere（Quip）を活用することで複数の部門やグループ間で共有・共同作業がしやすくなります。

これにより、情報を探す手間やデータの二重管理といったムダを省き、作業の高速化・精度向上、成果物の品質向上につながっていきます。

プロジェクト単位の仕事に限らず、部署を横断した業務をチームとして円滑に進めるために、Salesforceのようなシステムの活用を検討してみてはいかがでしょうか。

▼プロジェクト管理パッケージについての詳細はこちらをご覧ください
プロジェクト管理パッケージサービスページ

▼サービスに関しての詳細やご質問はこちらまで
プロジェクト管理パッケージ　資料請求・お問い合わせ