こんにちは。スマートバンクで事業開発を担当しているtakeshiです。
SmartBank Advent Calendar 2024、23日目の記事となります。
昨日は、kanekoさんの「シリーズBの資金調達後、現在のモバイルアプリ部を紹介します」という記事でした。
今日はBizDev dayと題して、スマートバンクに所属する事業開発担当3名それぞれが記事を書いております。他2名の記事もぜひご覧ください！
ushiroさん：「急成長SaaSスタートアップを退職し起業したら、いつの間にかスマートバンクにいた件」
chihayaさん：「スマートバンク流 新規事業開発の虎の巻 🐯📜 < 事業機会を見つけるためのフレームワーク編 >」
今回は、スマートバンクの事業開発チームにおけるミッションを再定義したので、その内容について書いていこうと思います。
後半では、この取り組みを通じて感じた事業開発職としてのミッションをまとめているので、 Fintechのみならず、事業開発を担当されている方の参考になれば嬉しい限りです。
新しく定義した事業開発部ミッション
結論ファーストということで、先に今回新しく定義した事業開発部のミッションを紹介しちゃいます。
Before
After
そんなに変わってなくない？、リードするって弱くない？という声が聞こえてきそうですね、、、w
ただ、議論を重ねた上でワーディングに意思を込めたので、どういった経緯で定義していったのか紹介していきます。
そもそも事業開発とは？
事業開発ってなんだっけ？というところから入っていきます。
AIチャットボットに投げかけたところ、以下のような返答が返ってきました。
よく耳にするような回答が返ってきました。構造としてはカバーされていそうな印象ではあります。
「非連続な事業成長」みたいなワードはよく聞きますよね。
👇のようなイメージです。
こういった構造で事業開発ミッションを定義されている組織も少なくないのではないでしょうか。
今までのミッション
冒頭で紹介した通り、以前まで事業開発部のミッションは下記のように定義していました。
前述した一般的なフレームで整理されているものに近いですね。
（今は組織編成を若干変えていますが）以前までは、コンテポラリーなPJチームが機能や事業の立ち上げを担当しており、その中で事業開発担当としてアサインされているという形態でした。
他方、PJチームでもカバーしきれていない事業領域の探索や検証については部門チーム（事業開発部）のミッションとして整理されてきました。
ミッション再定義のきっかけ
再定義した方がいいと思ったきっかけは、スマートバンク全体の組織体制がアップデートされたことです。
以前のコンテンポラリーなPJチームでの推進体制では、機能をリリースした後はPJチームを解散し、次のPJにそれぞれアサインされていました。
より多くの機能をリリースしていける利点はある一方で、リリース後のメンテナンスやグロースまで責任を持ちにくいことに加えて、ドメインごとのナレッジが分散して蓄積されにくい構造が生まれており、中長期的に見て生産性に懸念がある組織構造となっていました。
そういった構造を変えるべく、4月からはミッションチーム制という組織体制にチャレンジしています。
各事業領域ごとにチームを組成することで、機能や事業の立ち上げとグロースまで一気通貫で責任を持ったり、ナレッジを蓄積しやすい構造に変えようとしています。
一般的に事業部と言われるものとイメージは近しいかもしれません。
それぞれのチームには、チームオーナーと呼ばれる、その領域の責任者（少しニュアンスは異なりますが、一般的な会社における事業責任者）をアサインしています。
主な責任範囲は以下の通りです。
職種は特に限定されておらず、その領域の特性に応じて、BizDevやPM（PdM）、リサーチャーなどがアサインされています。
私も、1つのミッションチームのオーナーとして、既存サービスのグロースと新規サービスの企画・立ち上げを担当しています。
ミッションチームの中には、新規事業領域の探索をミッションに置くチームが組成されてアクションしています。
当然、そのチームにも事業開発メンバーがアサインされており、大きく2つの種類のミッションチームの中で事業開発アクションを担っています。
ミッションチームの大きな区分
- 既存市場 x 新規サービス立上及び、既存サービス拡大を担当するチーム
- チーム新規市場 x 新規サービス立上を担当するチーム
マトリクス型の組織体制になって、ミッションチームとは別に部門としてのミッションも考えていく必要がある中で、「既存領域も新規領域もミッションチームでカバーされていて、事業開発部としてのミッションはどう定義すべきなのか、、、🤔」という課題が顕在化してきました。
再定義するまでにやったこと
1. 定義に向けた大枠の方向性を定める
まず、ミッションを再定義するにも大枠の方向性を定めることとしました。
アイデアとして出てきたのは2つで、後者を採用しました。
- ミッションチーム以外の領域で事業開発部としてのミッションを定義する
- ミッションチームの中における事業開発アクションへのコミットを最大化していくことを、事業開発部のミッションとして定義する ✅
前者だと、ミッションチームで定義されていない領域 = 会社として優先度が低い領域ではないか？という懸念もあり、あくまで会社として優先度を高く置いている領域にフォーカスしようという観点で判断しました。
2. ミッションを整理する上での切り口を洗い出す
後述でも詳細を解説しますが、担当領域における非連続な事業成長を実現していくことに対して、事業開発メンバーが全ての責任を持ちづらいという大前提があります。
- 担当事業領域における全体の責任はチームオーナーが担っている
- 事業・プロダクト・システムそれぞれの観点での検討が必要である
なので、ミッションチームを推進していく中で限定的に事業開発のミッションを定義していくべきという着地になり、どういった切り口で整理していくのか議論することにしました。
こちらもアイデアとしては大きく2つ出た上で、業務フローの切り口で整理を進めることとしました。
- 業務フロー：ミッションチーム内における業務フローの中での事業開発が担当する領域を対象とする ✅
- KPIツリー ：事業をKPIツリーで分解した際の特定のKPIを対象とする（議論の中では収益という案が出てました）
3. 実務レベルから考え、抽象化する
業務フローで整理するという着地になったため、実務をイメージしながら事業開発メンバーがどういった役割を担っているのかを洗い出し、そこから抽象化する形で事業開発ミッションとして定義することとしました。
観点としては、大きく2つです。
- 事業開発 vs チームオーナー
- 事業開発 vs 他の職種
1つのミッションチームでは、自分自身がチームオーナーとしてのボールと、事業開発担当としてのボールを両面担っており、かつもう1名事業開発メンバーがアサインされています。
なので、このチームの中でどういった分担をしていくべきなのか？を考えながら抽象化していくアプローチを取りました。
また、事業成長をさせていくための企画と、その立ち上げに向けた検証について、事業開発メンバーがどういった業務を担っているのかを考えました。
こうしてフローごとに各職種がどういった業務を推進しているのかをプロットしてみると、事業開発メンバーが事業課題や事業機会を提議し、検証をスタートさせているケースが多いことが分かりました。
一方で、プロダクトやユーザー観点での検証や、システム上の実現可能性についての検証は、PM（PdM）やリサーチャー、エンジニアがそれぞれ担当してくれており、事業開発メンバーが関与する範囲はある意味限定的です。
よって、非連続な事業成長自体にミッションを持っているのではなく、事業課題や事業機会（= 成長仮説）を発見し、全体の検証をリードしていくことが事業開発メンバーが担っているミッションである、という整理に行き着きました。
完成版のミッション（再掲）
toCサービスにおけるBizDevとは
当社における事業開発部のミッションを考える上で、大切にしたことはtoCサービスとして事業開発とはどうあるべきか？という観点です。
まず、一般的なBizDevの定義は冒頭のチャットボットが答えてくれた通りかなと思っています。
一方で、その事業ドメインやサービスモデルの特性に応じて、形をチューニングしていく必要があります。
その最たる例でいくと、toBなのかtoCなのかという違いでしょう。
前職ではtoBサービスの事業責任者を担当しており、toB・toC両面を経験した立場から整理していきます。
まず、大きな違いとしては、セールスという機能・ポジションが存在するかということだと考えています。toBサービスの場合は相対が法人になるため、明確にセールスというポジションが存在します。
また、今までのサービスモデルでは営業と、カスタマーサクセスなど運用担当とに分かれる組織が大半だったと思いますが、SaaS型のサービスモデルの台頭によりtoBサービスでもPM（PdM）をアサインするケースが増えてきました。
一般的にPM（PdM）が顧客に向き合ってプロダクト企画するポジションですが、toBサービスではセールスという機能があることで、ビジネス側の方が顧客課題に日常的に触れやすく、顧客価値のキャッチアップをする機会も多いということになります。
対して、toCサービスの場合には、顧客が個人であり、日常的に顧客課題に向き合うのは主にPM（PdM）が担っているケースが多く、スマートバンクもそのような責任分解になっています。
そのため、主に顧客課題や価値仮説の立案、及びニーズ検証のアクションを、BizDev・PM（PdM）どちらがオーナーシップを負うか、という点においてtoBサービスとtoCサービスに大きな違いがあります。
実務レベルでは、ここまで明確に分けずお互いにオーバーラップしながら進めることになると思いますが、ここでは分かりやすさを重視しています。
よって、toBサービスの方がよりBizDevが事業全体の責任を負いやすく、対してtoCサービスはプロダクトの中における事業観点での仮説立てが中心となるため、よりミッション領域を細分化して定義する必要が出てきます。
さいごに
いかがでしたでしょうか。
意外とtoCサービス観点で事業開発組織について語られるケースも少ないかなと思っているので、みなさんが所属している会社やプロダクトを推進する上で参考になっていたら嬉しいです。
じゃあ、今後スマートバンクは何を成し遂げていくの？という点については、Recruiting Deckに掲載していますので、ぜひチェックお願いします。
もし詳細聞いてみたいということであれば、SNSなどでお声がけください（X、facebook）
話は変わりますが、この度スマートバンクはシリーズBラウンド1stクローズで40.8億円の資金調達を実施しました🎉🎉🎉
全職種採用強化中でして、採用特設サイトも公開されております！
少し気になるな〜、今すぐに転職は考えてないけど情報収集しておきたい、、、といった温度感でも大歓迎ですので、ぜひお気軽にご連絡ください！！！
