こんにちは、NutmegLabs JapanのMoeです。
最近ようやく「僕のヒーローアカデミア」のアニメを1話から見始め、キャラクターたちの成長っぷりに毎話涙しています。

このnoteは「BtoB事業開発アドカレ vol2」の20日目の投稿です。ぜひハッシュタグ「#BtoB事業開発アドカレ」をつけてシェアをお願いします！

はじめに

Bizdevって何なんだ？という点について、今日はめちゃくちゃ具体的かつ実態的なお話をしたいと思います。

Bizdevの仕事内容を説明する時、仕事範囲が多岐にわたるため「セールス」「CS」「マーケ」などあらゆる職種を組み合わせて説明されていることが多いかなと思っていて、今回はそういった枠組みを全て取っ払って、わたしがNutmegで実際にやっていることを書き連ねていこうと思っています。

このnoteは、読む人によってはおそらく「ああ、これってうちで言うと〇〇バックグラウンドのBizdevなんだな」と、〇〇に入る文言が変わった形で解釈されると思います。事業開発というのは、それを推進する人がどんなバックグラウンドを持っているか、また、その会社の事業思想やフェーズにより求められているスキルが異なることから、全然手法や成果の出方が違うので、世間一般で共通化された業務がないのが面白いところですね。何でも屋さんとはよく言ったものです。

今日はそんなお話をしていきますので、よろしくお願いします！

Bizdevのお仕事範囲について

🐶あなたは何バックグラウンドのBizdev？

まず、わたしはセールスバックグラウンドのBizdevで、事業フェーズはシリーズAのPMF真っ只中、チームもスタートは一人という前提をお伝えしておきたいと思います。

各社事業フェーズが進んでいくと、組織化や型化をしていくものと思いますが、NutmegのBizdevは遊撃隊、ピープルマネジメントの役割を持たずにどんどん実例を打ち立てていく部門という位置付けなので、フレームワーク化などは少し隣に、得意な方にお任せして道を切り開く魁（さきがけ）をやらせてもらっています。

そして、リードジェネレーションはやっていませんでした。わたしが入社した時にはすでに、見込み客とのコンタクトが複数あり、それらをいかにCVさせるか、また、いかにしてNutmegを通しての取引高を伸ばすか、が命題だったからです。

現在はほんの一部、マーケティング活動のサポートに入ったり、導入が決まった会社からグループ会社の紹介を受けて案件化させたりして、常時10~15社前後の企業の案件を走らせています。

👀BizdevとSales、仕事内容の違い

ちなみに、NutmegのBizdevは明確に売上目標を持っています。そこで、一般的なSales職であるAEと異なる業務内容を太字にして書き出してみました。

1. 採用の検討テーブルにのせるための営業的交渉

2. 新機能開発要素を抽出

3. 既存開発タスクとの照合とプライオリティの再定義

4. BRD作成後、その要件通り・あるいはBizサイドの本質的要望に沿って開発されているかの進捗・仕様確認

5. 採用を意思決定させる

6. 新機能リリースを伴っての導入がほとんどのため、その機能が期待値通りに動作するかのテスト

7. プレリリースによるフィードバック収集および開発への連携・修正依頼

8. 本番環境リリース後の最終Biz側テスト

9. 採用決定後の導入で絶対に転けさせないためのあらゆるサポート

10. その会社での最適な使い方を設計しオンボーディング

11. 本採用がスタートしてからの開発面での小さな改善サイクルの実行

12. 振り返りmtgによるさらなる利用促進提案

Nutmegでは、新規開発予定の機能のアイディアはすでに結構な数積み上がっていて、その機能にマッチするお客さまをBizdevが見つけてきて案件化すると、一気にその開発プライオリティが最上位になり、即座にBRDが作成され音速で開発着手されるという流れをとっています。
機能アイディアの源泉はTakashiさん（CEO）にあり、全ては彼の頭の中に入っていて、Bizdevはそれを具現化する部分を担っている、というのが一番実態に即した表現かもしれません。

ログラス浅見さんのnoteでは、事業開発は市場分析等からのトップダウン型と顧客要件からのボトムアップ型があると述べられていましたが、Nutmegの場合はその両輪がうまく交差するところを最重要プライオリティとして推進しているようなイメージですね。

事業開発の型についての詳細はこちらで詳しく解説されています。

Bizdev部門の組織編成

😎Nutmegの特異なBizdev組織

NutmegのBizdev部門はわたしと、元々はCS職で入社してくれた若手女性の2名という人数の少なさで、それぞれが社長直下で仕事に従事しています。両者にレポートラインは存在しないため、わたしたちは自由度がかなり高い環境に身を置いています。
営業的側面の強い仕事はわたしが担っていますが、わたしは彼女の先輩ではあっても上司ではないので、関係値でいうと「パートナー」が一番しっくりくるかもしれません。

この体制が機能しているのは、以下の条件が揃っていたからかなと考えています。

PMFしたプロダクトを扱い、かつ会社規模が200名などになっているようなフェーズでは、レポートラインの存在しない組織というのはなかなか維持するのが難しいと思います。

また、その新規機能開発に関わる人の数が多いと、行き違いや認識のすり合わせに時間と工数がとられてしまい、今のようなスピードでは動かせないでしょう。

最終的なプロダクト開発のプライオリティはCEOが強いリーダーシップを持って決定するため、あちこちで開発要件が上がって「どっちを先にやるんだっけ？」みたいな時間が発生しませんし、Nutmegのエンタープライズ向け新機能開発はETAもかなり厳しく定められるため、「全然開発進まないぞ？これだれがやってるんだっけ？」みたいなことも発生しません。

プロダクト開発に関わったことのある方なら、これがいかに凄いことかお分かりいただけると思います。

エンジニアにとって、正確なETAを見積もるのは非常に難易度が高く、まさに熟練の所業になります。これが成せる所以はひとえに、元ベルトラでゴリゴリ機能開発に従事していたベテランエンジニアが在籍しており（VPoE）、さらに元Microsoftで天才エンジニアの異名を持っていたCTOが盤上を固めているからだと思います。そう、うちはCTOもコード書いてます。すごない？

もし今後、NutmegのBizdev部門所属の人数が増えていくとしたら、それはきっとピラミッド型ではなくアメーバのような組織編成になるのかなと思います。
その人ごとの役割が定義され、定めたゴールに向かっての道順は各人が決める。Howは定義しない。みんな部下ではなくパートナーとして一緒に仕事をすることになるんだろうなと思っています。

Bizdevとして大切にしていること

🚴‍♀️仮説の再構築祭り

大切にしていることの一つは、ゴールまでの道順を状況に応じて再構築し続けることです。
初めに描いた通りの、予定調和な案件進捗などこの世に存在せず、都度その時起きた事象や外部要因、登場人物、社内リソースなど、影響を受ける要素は多岐に渡ります。

もちろん仮説は立てます。このときリスクも見積もります。現状を正しく把握し、そこから要素分解をして、やるべきこととやらないことをはっきり決め、スタートを切れば都度新しく手に入った情報を元に、仮説を再構築し続けてゴールまで走り切ります。

じっくり腰を据えてというより、結構なトップスピードで走りながら時折休憩所で軌道修正する、みたいなイメージです。

LayerXのushiroさんのnoteで紹介されていたjobgramをやってみましたところ、まさに「とにかく生き急ぐ行動超人タイプ」だったのでいやもう本当にそうですよねハイ、という感じでした。

jobgram面白かったので、みなさんもぜひ試してみてください！

🤝他部門との信頼関係

開発陣へのリスペクトを決して忘れないことも、大切です。

これまでも、機能開発の伴うプロダクトセールスはやってきましたが、その時経験した歯痒さや、なかなかすり合わない期待値、共通言語の構築など悩みも多かったので、それらを経験した今だからこそ、ミスコミュニケーションの発生を最小限にできるよう、開発陣の負担にならない情報共有の仕方を模索したり、前提認識の齟齬がないかの確認を怠らないなど、全然まだまだではありますが取り組んでいます。

ビジネスサイドは、価値貢献できるプロダクトがなければ、ビジネスができません。
プロダクトサイドも、価値を顧客に正しく伝え、届ける人がいなければ、せっかく作った素晴らしいプロダクトも日の目を見ません。

我々はまさに持ちつ持たれつです。そういった信頼関係の元、世の中に新しい価値を提供する仕事をやらせてもらっています。

Nutmegの事業に少しでも興味を持っていただけましたら、ぜひカジュアル面談やセミナーにご参加ください！DMもお待ちしています。