PdMと事業開発って結局何が違うんや

はじめまして！estie（エスティ）取締役の束原です。

現在私は10名程度のチームで新規事業の立上げに奔走しているのですが、本記事ではその中で発生した問いと学びについて書いてみました。元は社内向けに書いた記事ですが、現在PdMや事業開発、事業責任者をやっている方や、今後やっていきたい方の参考になれば嬉しいです。

この記事で分かること

estieにおいてPdMと事業開発が2つ役割として存在する意味
サービス立上げや大規模な機能開発を行う際に、PdMと事業開発がestieで大切にして欲しいポイント

結論

「どこまでがPdMの仕事で、どこからが事業開発の仕事なのか」という問いに答えはなく、必ずしも仕分けすることはできない
従って、あらゆるチームに適用可能な責任範囲を予め設定する必要はなく、アサインされる人の得意分野によって流動的に設定すれば良い
事業の立上げやグロースには、「リーダーシップ」と「プロダクトマネジメントトライアングルの3要素」をしなやかに満たす必要があり、事業責任者、PdM、事業開発と名前のつく人達が中心となって上記の要素を満たす努力をすれば良い
重要なのは「課題の特定と検証」プロセスの進め方であり、細かい役割に囚われる必要はない

課題提起

「PdMと事業開発って結局のところ何が違うんや」

意外とこの質問に明確な回答を持っている人は少ないような気がします。もし回答できる人がいたとしても、かつて所属した組織で”常識”とされていた役割分担をベースとしており、各社において何故そのような棲み分けになっているかを体系的に説明できる人は決して多くはなさそうです。

estieもご多分に洩れず、創業から1年が経過した頃に「Product Manager（PdM）」と「事業開発（Bizdev）」二つのロールができ、それから2年ほど「境界線結構曖昧じゃね？」と社内で会話が発生することがありました。

実際に、estieには全てのロールに対して社内評価のベースとなるJob Descriptionが存在しますが、事業開発とPdMのDescriptionはやや似通ったものになっています。

また、estieでも頻繁に引用されるプロダクトマネジメントトライアングルの記事（こちらはFoundX馬田さんの記事）においても、特にプロダクトマネージャーの職責は「ビジネスモデルや扱う製品によって異なる（べき）」ということが言われています。上記の記事内では事業開発については触れられていませんが、やはりこの2つのロールに関して万国共通で通用する役割分担なんてものは存在しないことが分かります。

恐らく、世間一般的には2つの職種はざっくり以下の通り認識されていることでしょう。

職種	何をする人？	特に誰と関わる？
事業開発（Bizdev）	事業作りをリードする人	社外ステークホルダー
Product Manager（PdM）	プロダクト作りをリードする人	社内メンバー

但し、上記のラベルだけを貼っても、実際の事業作りのプロセスが明確にならないと、大きく以下の問題が生じます。（実際estieの現場では以下のような発言が出てくることは無いですが、下記のような潜在的な意識や構造的な脆さは発生すると考えています）

誰が最終的にPL責任を持つんだっけ？

事業開発の意見をベースに新しい機能作ったはいいけど、ユーザーに使われなかったら、売れなかったら誰の責任になるんだっけ？

事業開発はどの程度直接的にプロダクトチーム（主にEngineer、Designer）とコミュニケーションを取ればいいんだっけ？（直接コミュニケーションをとりすぎると、PdMのマネジメント・キャッチアップコストが増してしまう）

estieでは直近、事業責任者というロールを設けることを契機に、この論点に一旦の終止符を打つことができそうだと思っています。

他方で、事業責任者を置いたところで必ずしも上記の問題が解決されるわけではありません。今回は事業責任者という役割も交えてどのようにestieで整理したかをまとめ、特に事業立上げのタイミングで、どのような点に留意するとチームが有機的に動けるのかを以下に書いてみました。

to Bサービス（特にエンプラ向け）の作り方をベースに、2つのロールの存在意義を考える

最初に、estieはto BのSaaS事業をメインで展開しておりますので、「エンタープライズ向けサービスがどのように創られていくか」という切り口から、そもそもなぜ上記2つのロールがestieで必要になるのかを考えてみたいと思います。

to B、特にエンタープライズ事業の立ち上げは、概ね以下の通り進んでいくと考えています。

	プロセス	説明
1	ビジネス仮説の構築	ユーザー接点をベースとしてビジネス仮説を作る
2	課題の特定	ビジネスとして拡張性が見込める、最初に取り組むべき顧客の課題を特定する
3	プロダクト作り	課題解決の手法を考える
4	契約獲得・オペレーション導入	初期顧客を獲得し、オペレーションを構築・導入する
5	検証	実際にサービスや機能が思った通りの成果を上げているのかを検証する

上記は時間軸を示すために無理矢理1から5まで番号を振りましたが、「1」と「2」、「3」と「4」はそれぞれ順番が逆転したり、並行したりする点がエンタープライズ向けSaaSの難しい（面白い）ところであります。（そしてこれがPdMと事業開発の役割分担を一層曖昧にさせています）

例えば「1」と「2」については、N1の顧客が持っている課題からスタートして、その課題が汎用的なものでビジネスとして成り立つか？と考えるアプローチ（2からスタート）もあれば、海外事例やマーケットのトレンドから着想して、その後に目の前にいる顧客が持っている課題を探しにいくケース（1からスタート）も存在します。

「3」と「4」についても、C向けサービスであれば「4」からスタートすることは中々考えづらいですが、to Bでエンタープライズを開拓していく場合には、先に契約を獲得してしまうケースは往々にしてあります。いずれにせよ、プロダクトアウト的なアプローチよりも、マーケットイン的なアプローチになることが多いはずです。

では、上記プロセスをリード・推進する上で必要となる要素やスキルは何か？

それを表してくれているのが上でも引用させて頂いたプロダクトマネジメントトライアングルの要素です。下記はあまりto C / to Bに偏らない汎用的なものになっていると思います。

ご覧頂ければわかる通り、必要なスキル・要素は多岐に渡り、これを1人で理解して事業・プロダクト作りをリードすることは激ムズです。

特にto Bのエンタープライズ向けサービスにおいては、ドメイン知識や顧客経営層との折衝力等が高い水準で求められ、これを開発側のスキルセットと両立することは困難です。

上述した経緯で、estieではPdMと事業開発が2つロールとして存在するわけです。

ちなみに、プロダクトマネジメントトライアングルの記事は、プロダクトマネジメントに必要なスキルセットを羅列することを目的としているのではなく、このトライアングル内で発生する余白領域（各頂点の合間）や融合領域（例えばデザインと営業の結節点）をどうマネージするかについて、PdMの振る舞いやチーム設計手法の指針を伝えることを要旨としています。（良ければ是非原文(by Dan Schmidt)も読んでみて下さい）

実際の役割分担

ではここから、上記のプロセスを事業開発とPdMがどのように役割分担しながら進めていくかを整理してみます。結論から書くと、以下のイメージが理想だと考えています。

		事業責任者
	プロセス	事業開発	PdM
1	ビジネス仮説の構築	◎	◯
2	課題の特定（同時に5の算段をつける）	◎	◎
3	プロダクト作り	ー	◎
4	契約獲得・オペレーション導入	◎	ー
5	検証	◎	◎

こうして見ると、意外と差分がないことが分かります（というかそう書きました笑）。スキルセットをベースとした役割分担が発生するのは主に「3」と「4」であり、それ以外は殆ど共同作業になりそうですね。

実はここがこの記事で最も強調したいポイントです。

上記「2」については、事業開発とPdMがクリスタルクリアな共通認識を持つことが必要であり、このフェーズまではとにかく2人で顧客に会いにいき、膝を付け合わせて議論を重ねることが重要だと私は思っています。そして「2」の段階で「5」の算段をつける（合意する）、というチェックポイントも肝要です。「3」「4」にはこれを踏まえて分岐していけばいいのです。

上記「2」までのプロセスに不足があると、以下のような問題が生じます。

あるユーザーの課題は解決できたけど汎用的な課題じゃなかった
- 「2」の合意において、トライアングルの「ビジネス」要素が欠けていそうです。estieの場合ここは事業開発としてアサインする人に求めています。課題の特定フェーズで事業開発のスキルに長けている人がいないと、作った後に他の売り先がない・思ったほど事業インパクトが出ないといったようなロスをすることになりかねません。
完成したはいいけどプロダクトがユーザーの課題を何も解決できていない
- 「2」の合意において、トライアングルの「開発者」・「ユーザー」要素が欠けています。エンジニアと連携しながら、手法を考え、優先順位を付けること。N1の顧客と向き合ってその人の持つ課題を特定すること。estieの場合ここはPdMの方に必ず持ち合わせておいて欲しいスキルであり、ビジネススキルに特化した人がドライブすると事故る可能性も高い。
結局売れてないけど、何を直せばいいんだっけ？
- 解くべき課題に合意が取れていれば、Biz（売り方・市場）とDev（売るもの）のどちらに起因して売れていないのかを振り返ることができます。ここの合意が取れていないと、「作りっぱなし」が発生します。作った後の検証は「2」における合意を元に、PdMと事業開発が一緒にレトロスペクティブをしていく必要があります。

「事業立上げにおいては、課題の特定と検証作業をPdMと事業開発が共同で行なってほしい。」

これがこの記事で最も強調したいHowのポイントです。

事業責任者は何するんだ？

さて、最後に事業責任者です。結論から言うと事業責任者はプロダクトマネジメントトライアングルには表れない「リーダーシップ」の部分を要素として補完して欲しいと考えています。

estieでは事業責任者の役割と要件を以下の通り定義しています。

ビビるほどソフトスキルに寄っています（笑）。

けどそれでいいのかもしれません。特に「リーダーシップ」の箇所に記載のある、「チームからの信頼」は何か特定のハードスキルとそれに基づく成果がないと獲得できないものでしょうし、そのスキル自体が固定されている必要はありません。

「この人に最終的なオーナーシップを持ってもらえれば、足りないスキルの調達も含めて目標達成してくれるだろう」という安心感をチーム全体に持たせることができるか、という点が重要なのだと思います。

その意味で、事業責任者に求められるハードスキル要素があるとすると、それは「プロダクトマネジメントトライアングル全要素の必要性を正しく理解し、調達・融合させることができる」ことなのかもしれません。

予想される質問

きっと以下のような質問が出てきそうです。いくつかestieの運用や、私の考えを書いておきます。

Q1. 結局2つのロールは「その時点でのフォーカスが違う職種」ということ？特定の誰かを明確にどちらかに仕分けすることはできない？

恐らくその通りで、得意分野がはっきりしている人もいるけれど、めちゃくちゃその中間にいる人もいるはずです。（弊社PdMの田中もそんな感じです）
ただ、1人でプロダクトマネジメントトライアングルの全要素を充足できる人は世の中に限りなく少ないので、無理矢理にでもロールを分けてあげて一人当たりのRequirementを下げ、確実にトライアングルの全要素を満たしていこう、というのがestieのアプローチです。
個人的に、モチベーションとして事業開発は「顧客の経営課題を解決することに沸き立つ人」、PdMは「目の前のユーザーを大喜びさせることに沸き立つ人」が向いてるんじゃないかなと思っています。

Q2. 新規プロダクト開発するときはどっちのロールがユニットの最小構成に含まれる？

時と場合によると思います。
estieでは今後取り組むどの事業にも事業責任者（最終意思決定権者）を配置するため、その責任者の持つスキルがトライアングルの「ビジネス」に寄っていたら、PdMを1人アサインしてもらえればいいかもしれませんし、逆であれば事業開発1人いれば成り立つ可能性が高い。事業責任者がスーパーマンであれば誰も要らないかもしれません。
ただ、PdMをアサインする場合は必ずPdMがスクラムに出席し、PdMをアサインしない場合は事業責任者が出席することをルールとしています。（逆に事業開発は出席をマストとしません）

Q3. セールスやマーケは誰がやるの？別で採用するの？

事業立上げフェーズにおいては主に事業開発がやります。
estieでは、戦略を練るだけの事業開発は不要と考えており、基本的なビジネスプロセスをおおよそ1人で回し、顧客獲得まで達成できることを採用の要件としています。
そもそも事業開発は、会社としてヒト・モノ・カネを大きく投下するジャッジを下すことができないフェーズや領域を担ってもらう趣旨でアサインしているので、ここでセールスやマーケを別で1人ずつアサインするのは本末転倒だと考えています。

プロダクトマネジメントトライアングルについて（社内に向けた余談）

ずっと思ってたんですが、estieにおいてはプロダクトマネジメントトライアングルの頂点の内、顧客を一番上に置きたい（顧客の声 is King）。

そうすると、上記に書いたことが少しイメージ持ちやすくなりませんか？

「課題の特定と検証をPdMと事業開発が共同で行って欲しい」というニュアンスがよりクリアになる気がします。

但し、あくまでこれは2つのロールにおける役割分担を理解するためのイメージです。

estieで過去に整理されてきた通り、プロダクトマネジメントトライアングルはグループ全体で満たせばいいし、立ち上げフェーズにおいて特に優秀なデザイナーの存在は不可欠です（何なら一番重要かもしれない）。上のように2つに切るよりも、エンジニアリングマネージャーも交えた3人で切った方が分かりやすいかもしれませんし、創業期は大体上記をCEOとCTOの2人で満たすでしょう。

あくまで、スタートアップというヒト・モノ・カネが限られた環境下でサービス立ち上げや大きな機能開発を行う際に、爆速でチーム設計を行い早期の人員確保を行うために、上記のようなペルソナの棲み分けを行い、事業・サービス作りにおける「課題の特定」と「検証」のプロセスをこの2人が共同で行っていこう。という提案です。