なぜ営業組織と開発組織の仲は悪くなるのか？を考えて体制構築したらBizDevの重要さがわかった話
前提として、私は営業組織でも開発組織でも働いた経験があります。
営業組織で学んだこと
私は新卒でリクルートに入社し、キャリアの最初は「カーセンサー」という中古車メディア（当時からWEBが中心）の広告営業でした。
新規顧客開拓では都内の中古車店にひたすら飛び込む中で辛い経験も味わいながらも、噂に聞いていたリクルートの営業部隊を現場で体感できたのは非常に学びが多かったです。
私が働いていた当時、大規模な顧客向けシステムのリプレイスがありました。当時はシステムのことなど何もわからず、営業の立場として聞いたときには、「なんでこれまで慣れてきた画面を変えるんだ！」と思いましたし、リリース後にバグがあると「なんでこんな品質のものを開発部隊は当たり前に提供するんだ！」と激怒していたものです。「せっかく俺たちが（売上を）作っているのに・・・」と飲みながら話すことがよくありました。
何よりも、今動いているシステムをわざわざ多額のお金をかけてリプレイスする意味もわかりませんでしたし、当時自分が大変な苦労をしてもらってきた申込書（＝お金）を、じゃぶじゃぶシステムに投下され、しかも開発に対して行った機能要望は大して反映されないという状況に常に不満を抱えていました。
※余談ですが、僕の初受注は5万円の商品だったので、その後も1人月100万円と聞くとあの時の申込書20枚分だなと換算して、絶対に無駄に使わないよう気を引き締めなおしてます。
開発組織で学んだこと
その後、リクルートのシステム開発部隊に配属され、現場でコードを書く経験をしたり（こちらの現場では最初、環境構築で躓きまくってコードを書けただけで泣きそうになりました）、プロジェクトマネジメントを学ばせてもらうなど、たくさんの経験ができました。
そんな中で、かつて自分が営業として対峙していたカーセンサーのシステムを担当することになり、今度はシステム開発側の立場として携わることになった時には運命を感じました。
システムを担当する立場になると、今度は「いかに技術的負債を貯めないか」「いかに今後のビジネスに沿った機能開発ができるか」「いかに将来を考えた投資ができるか」といった、まったく違う文脈で頭を悩ませることになり、営業から上がってくる機能要望リストを開くのすら怖くなっていたのです。こちらでは「せっかく俺たちが（システムを）作っていこうとしているのに・・・」と頭を抱えていました。
こうした両面での経験を得られたことに加え、その後いくつかのSaaSプロダクトを開発する部隊（システム開発ではなく、プロダクト開発を指向する部隊）のマネージャーを務めたりする中で、「なぜ営業部隊と開発部隊は仲が悪くなりがちなのか」を考えることが多くなってきました。
両方を経験した後の仮説
自分のこれまでの経験だけでなく、多くの会社において営業部隊と開発部隊が仲が悪くなりがちだと聞きます。営業からすると「全然開発部隊は要望に沿った開発をしてくれない」し、開発からすると「営業部隊の要望に沿った開発ばかりで必要な負債解消もできない」と言うのは、大半の現場であることでしょう。
同じ事業を伸ばしていくというミッションを持っているはずなのに、なぜこんなにも目線が違ってしまうのだろうか？と当時は疑問に思っていました。
また、「受託開発の仕組みをとったからそうなっているのか？」と思ったのですが、すべてを自社開発したプロジェクトでも大きさの違いはあれど似た問題が起こっていたり、自社開発しているベンチャーの友人からも同様の話を聞くことが多くあり、そこだけが原因ではないのだという見解に至りました。
ではなぜ同じ事業を伸ばすという目的を共有しているはずの営業部隊と開発部隊の仲が悪くなるのか？
それは、それぞれが重視するものが「PL（売上/利益）」と「BS（資産）」で違うからです。
※「PL」と「BS」がイメージできない方はこちら
開発部隊は「イケてるBS（資産）を作る」のが仕事であり、営業部隊はそうして作られたBS（資産）から「PL（売上/利益）を作る」のが仕事だととらえています。
実際に、「事業のために作っていこう！」と言われたら、営業時代の自分は売上の話だと捉えるし、開発時代の自分はシステムのことだと捉えていたと思います。
PL（売上/利益）目標を持っている人たちからすれば、カスタマイズも許容してどんどん要望通りの機能を追加して、売上につながる仕様はひたすら入れたくなります。
一方でBS（資産）を作る人たちからすれば、当然イケてる資産にするためにも、資産価値低減につながりそうな個別対応や設計思想に乗っ取っていない機能などは入れたくありません。
この違いこそが、営業組織と開発組織が仲が悪くなる原因ではないか、それが両方を経験した自分の経験からもしっくりきました。
起業したので、仮説をもとに体制構築してみた
現在経営しているGrafferでは、行政に対して営業活動が必要なプロダクトを作っていますが、営業部隊を「Sales」機能と「Business Development」機能に分けてみました。
「Sales」機能はPLに責任を持つ。売上を目標として活動する。主にプロダクトの提供価値が明確になった後のプロダクトのみ担当する。（プロダクトの初期では資産価値向上を目的とするため、Salesはつけない）
「Business Development」機能はプロダクトの資産価値向上にビジネス面から責任を持つ。Product Managerと協働しながらプロダクトの初期の立ち上がりからPMF実現を目指す。
そう明示的に分けて組織してみると、Business Development機能の重要性がよくわかりました。言うまでもなく「ビジネス面からプロダクトの資産価値向上」ができることがとても多かったからです。
例えば、初期顧客と契約をする際のSLA。99.9％で設定されているか、99.99％に設定されているかによって許容できる障害発生時間が変わります。これを99.9%に倒すことができれば、それだけProduct担当はリリースする際の躊躇が少なくなり、リリース回数が増えるため結果的にプロダクトの資産価値向上につながります。
例えば、プロダクト検討初期からプロダクトで想定している現場を体感できるように、顧客と調整して開発部隊が現場を体感できる回数を早い時期から増やすと、一気に無駄な機能の検討が減りました。こうしたビジネス面からプロダクトの資産価値向上ができることが実はめちゃくちゃ多かったのです。
やってみた結果
結果的に、Grafferでは人生で見たことが無いレベルで営業組織と開発組織の仲が非常によい状態です。しかも、慣れあっているわけではなく双方に正直に要望もできるし同じ目線での議論ができる組織になりました。もちろんそのおかげでプロダクト開発も恐ろしく高速です。
組織体制だけではなく、開発担当の現場機会を増やしたり、BizDevを営業ができつつコードも書ける人材を大半にするなど、他の努力もありましたが、特に目線の違いを解決したインパクトが大きく、ここまで変わるものなのかと自分でもビックリしました。
（宣伝）Grafferでは、こうした組織体制にしながら、いくつもの新規プロダクト開発を行っています。いろいろなポジションで絶賛採用募集中で、最近は特にBusiness DevelopmentとProduct ManagerはAssociateも含め力を入れてどしどし募集しております。
近日中にリリース予定でここで出せないのですが、未公開の面白いプロダクト群もたくさんありますので、ぜひ気になった方はお気軽に応募ボタンをポチっていただいて一度話をできますと幸いです。（個別の場であればいろいろ見せられます）
https://graffer.jp/
また、「Sales機能がプロダクト開発とどう絡むべきか？」や「新規事業において経営がBSでなくPLでしか事業を評価できない罠にハマっていく闇」など、このテーマから派生して面白いテーマもいろいろありますので、そのうち書いていければと思います。