スタートアップにおけるBizDevの働き方～「何でもやる」は間違い？～

こんにちは、UbieでBizDevをしている細川（@sh____hs）と申します。

このnoteはなに？

スタートアップのBizDev、言葉は聞いたことあるけど具体的にどんな働き方をしているの？と疑問を持つ人も多いと思います。ぼくもそうでした。
このnoteでは実際に働いてみて分かった、スタートアップにおけるBizDevの働き方と、「何でもやる」けど「何でもやらない」ことの重要性、そしてBizDevが力を発揮しやすい組織の仕組みについて、思う所を纏めてみました。

こんな人に読んで欲しい

以下の様な方の参考になれば幸いです。
・スタートアップのBizDevに興味があるけど、どの様な仕事をしているか分からない
・スタートアップのBizDevへの転職を検討しているがどの様な環境か分からず自身がフィット・貢献できるか不安に感じている
・スタートアップのBizDevとして実際に働いている

入社時の想いと勘違い

改めて自己紹介を。
新卒で日系の総合コンサルの会社に入社。その後、外資系の戦略コンサルを経て2020年6月にUbie株式会社にJoinしました。
コンサル時代に携わったプロジェクトは産業・テーマの両軸でバリエーションに富んでおり、また採用などのオフィスロールも複数担う、いわゆる「何でも屋」でした。そんな中、もっと自分で手を動かしたりコンテンツの中身に関わりたい、事業会社で直接的に社会貢献したいという想いが強くなり、たまたま縁があったUbieに入社を決めました。
正直なところ、入社前はスタートアップでBizDevとして働くことに対する解像度はだいぶ低かったと思います。「何でもやる必要があって大変なんだろうな」という程度のイメージ。だからこそ、「何でも屋」として様々なことを前に進めるのは性にもあっているし割と得意なので価値を出せるのでは、くらいに考えていました。
いま思うと、そこに勘違いがあったかなと。「何でもやる」はある意味正しいですが、正しくない部分もありました。

BizDevとしての仕事

ここで、話の前提となるUbieの事業について簡単に説明したいと思います。
Ubieは医療機関向けのSaaS「AI問診ユビー」と症状から疑われる病気や対処法を調べられる生活者向けWebサービス「AI受診相談ユビー」の2つのプロダクトを軸に、医療機関向け（病院・クリニックそれぞれ）、製薬向け、患者向け、の4領域で事業を展開しています。
各事業の細かい説明は省きますが、超おおざっぱに言うと医療機関向け事業は「AI問診ユビー」を、製薬向け・患者向け事業は両プロダクトを用いて各種ステークホルダー（製薬企業、保険企業、etc.）にソリューション提供をしています。
入社後は、製薬向け事業からスタートして、現在は患者向けに軸足を置いています。両事業とも主に0→1フェーズに当たり、顧客からお金を払ってでも使いたい、と思われるソリューションを作る段階にあります。
具体的には、
・マーケットを理解し顧客が抱える、解くことが出来そうな課題の把握の為にデスクトップ調査や有識者へのヒアリング
・実際にソリューションを企画して顧客への提案・サウンディング（プロダクト開発のチームとも連携）
・それを踏まえて企画の練り直し
などなどを行っています。
BizDevとは何か、という解説は既にたくさんあるので調べてみて頂ければと思いますが、Ubieでは「アセットを創る」という表現が良く使われます。試行錯誤しながら顧客の課題を解決できるソリューションをつくり、事業として成長していくための基礎を固める仕事です。

「何でもやる」けど「何でもやらない」のが大事

必要なことは何でもやるぞ、という意気込みで入社しました。スタートアップのBizDevとして働くにあたり「何でもやる」ことは確かに重要です。しかし「何でもやらない」ことも同じくらい重要であると分かってきました。
どういうことか。

「何でもやる」べきことは当然ある

まず、やはりスタートアップである以上「何でもやる」は、一定真だと思っています。具体的には以下の様なことです。

「何でもやる」べきこと
① ミッション達成のために、必要なことをやる
② 組織のミッション達成の為に、状況に応じてやるべきことを変える
③ 組織の出力最大化の為に、マッチする人材を採用する

① ミッション達成のために、柔軟に、必要なことをやる
スタートアップは世の中にないものを創り出そうとしており大きな不確実性の中にいます。当然、ミッション達成に確立された道筋はありません。
有望そうなソリューションAを確立させようといざ前に進めてみると顧客の期待に応えるのが難しく、意外と別のソリューションBをSellingする活動に軸足を移したり、逆にAはセールスではなくソリューション開発（既存ユーザーへのヒアリングやプロトタイプによる仮説検証など）にフォーカスを充てるなど、やるべきことを見直して対応します。また、顧客との取引にあたっては業界や顧客について学習することはもちろん、経験のない審査・発注・契約に至るプロセスを自分で見る必要があったりもしました。（もちろん周りの協力を得ながらですし、今は以前より体制が充実してきました）

② 組織のミッション達成の為に、状況に応じて自分のやるべきことを変える
各チーム、個人のミッションは当然ながら組織全体のミッションに紐づきます。社内外の状況に応じて組織として短期で目指すゴールや注力領域は変化するので、個々が取り組む仕事の重要性も結構ドラスティックに変わります。時にはその時の仕事を寝かせて重要度の高い別な仕事にピボットすることも求められます。チームが変わることも珍しくないです。
Ubieでは「玉突き人事」が奨励されていて、各人が組織視点で重要なミッションに必要なリソースをはる様に動くことが求められています（後述しますがその指針として、OKRを採用しています）。そしてリソースが薄くなる部分はやることをミニマイズ・引継ぎして上手く前に進める様にする。ぼく自身も製薬向けの事業から、より人手が足りない患者向けの事業に軸足を移しましたし、元々持っていた役割は他のメンバーに移譲し新しい仕事に注力できる様に切り替えています。

③ 組織の出力最大化の為に、マッチする人材を採用する
通常業務に加えて誰でも採用に力を割くのはスタートアップの特徴と思います。取り組み方は会社により異なりますが、採用も重要な仕事の一つです。
知名度も限られる中でマッチする人材と出会い、そして入社頂くまでには結構なハードルがありますが、Ubieでは人材の紹介や面談まで全メンバーがコミットして取り組んでいます。ミッション達成のために人が足りなかったり、必要なケイパビリティがなければ採用しろ、という考え方です。患者向けの事業はBizDevが超限られていた（というか一人だった）ので、カジュアルや本選考含め面談をしたりアトラクトに参加したり、より魅力を伝えるためにメンバーを巻き込んだり積極的に行い、晴れてこの1月から強力なメンバーを迎えて一緒に仕事が出来ています。

「何でもやらない」ことこそ意識すべき

ここまで述べてきた「何でもやる」ことはある種イメージ通りかも知れません。一方で、裏返しの様な部分もありますが、「何でもやらない」ことが「何でもやる」ことの質を上げるために非常に重要と日々痛感しています。そして難しい。はっきり言ってぼくは苦手です。苦手だからこそ以下の3点を仕事上で意識する様にしています。

「何でもやらない」こと
① 仕事の領域を広げようとしすぎない
② ありとあらゆる可能性を検討しすぎない
③ 自分の頭だけで考えすぎない

① 仕事の領域を広げようとしすぎない
スタートアップにおいて、やった方がいいことは探せば無限に見つかります。面白そうなこと・気になることはめちゃくちゃある。でも無理にあれもこれも、とやると個々の出力は落ち、中々成果がでない状況に陥ります。ただでさえチャレンジをしているので、どの仕事も片手間では出来ない。
ぼくも製薬向け事業を主にしていた際に、人手が足りないクリニック向けの事業にサポートのつもりで工数を少しの期間割いてみたりしました。が、一か月くらいでやめました。少ない工数だと大した役に立てないし、やることは貯まる一方で消化が追いつかず焦りを感じたりする。どちらの事業にもポジティブな影響がなかったなと。
新たな仕事の領域に手を出さざるを得ない場合は、その時の仕事との優先度を考え優先度の低い方を思いきって後回しにする、または別の人に引き継ぎ、集中する領域を絞るのが重要と痛感しています。フォーカス。

② ありとあらゆる可能性を検討しすぎない
よりミクロな観点でもフォーカスが重要です。顧客が解決したい課題はいくつかあり、そのhowも複数の選択肢が思いきますが、まずは一つ実現可能で有望そうなものを選択し検証すること。
一度に検証出来ることは限られるので欲張らずに一つずつやることが必要ですし、背伸びした解決方法はそれだけ不確実性が増すので現実的でない。顧客の要望にはできるだけ応えたいですが、そのために不確実性の高いものを提案するのは本末転倒です。プロダクトを活用したソリューション提案なので、自分だけが頑張ればなんとかなる世界でもないし、下手をすれば活用できない機能を他のメンバーの工数を奪ってまで作ることになる。明らかに不確実性が大きいものに関してはその検討の時間すらももったいない。

③ 自分の頭だけで考えすぎない
「自分で何でもやる」マインドになると陥りがちですが、自分が責任を持つ仕事＝自分だけで完遂する仕事ではないです。プロダクト開発やその他事業開発も並行して進む中で、社内の状況も刻々と変化していきます。分からないこと、悩みがあればすぐ知ってそうな人と話す、それが結局全体の進め方として最適なことが多いです。各プロダクト・事業開発が連動しながらも同時並行で進んでいくので、情報の透明性の意味でも抱えすぎは良くない。
こう書くと自明なことの様に感じますが、それぞれが多忙だと思うとためらいが生じたりすることもあります。色々な職種の人が集まってワンチームで仕事をしているのもスタートアップの面白さですし、頼るところは頼るのが大事です。

力を発揮するためには組織的な仕組みも必要

ここまでBizDevとして働く上で意識すべきと思うことを書いて来ました。一方で、どの様な業界から来る人でもおそらく働き方や考え方はかなり変わるため、頭で分かっていても一朝一夕にはいきません。組織としてどの様なサポートがあるかで、順応の速さや最大出力が変わってきます。
Ubieでは様々な仕掛けが恒常的に実装・Updateされてきており、必要な考え方の変化やアクションを後押ししてくれていると体感しています。BizDevとしてどの様に恩恵を受けているか、一部をご紹介したいと思います。

Ubie株式会社の組織的な仕掛け（一部）
１．OKRとHolacracyの採用
２．体系的なカルチャーの整理・言語化
３．not 評価 but 相互フィードバック

１．OKRとHolacracyの採用
Ubieは全社およびチーム単位でOKR（Objectives and Key Results）を設定し、四半期単位でUpdateしています。また、組織構造としてHolacracyを採用しています。あまり聞きなじみのない言葉かも知れませんが、簡単に説明すると組織が必要なRole（役割）の集合として規定され、各Roleに人がアサインされる仕組みです。Roleの中に更に複数のRoleがある場合には上位のRoleはサークルと呼ばれ、それがいわゆるチームに該当します（会社自体も一つのサークルです）。個々のRoleにはPurposeとAccountabilityが設定されており、その達成に向けて仕事を推進していきます。
OKRにより目指す方向性がアラインされ、自身の担うRoleとしてやるべきことに集中することで事業が進捗する。そこが分かりやすく担保されているからこそやるべきことに心置きなくフォーカスできる環境になっています。「これやった方が良さそうだな～」と思ってもむやみに手を出したり、安易に仕事を引き受けたりといったことが減らせます。

２．体系的なカルチャーの整理・言語化
会社として目指す姿から逆算して、カルチャーのガイドラインも作成されています。ミッション・事業戦略・事業特性に紐づける形で行動指針も規定されており、どういった行動が推奨されるのか、それはミッション実現の上でどう重要なのか、読めば頭で理解できるガイドです。
Do / Dont'sの事例で整理されているのでスタートアップ初心者でも具体的なアクションに繋げることができる。そういう拠り所があるのが個人としても大きいですし、チームで働く上でも重要な役割を果たしていると感じます。

３．評価ではなく相互フィードバック
前提としてUbieでは評価がないのですが、フィードバックは積極的にしあうことが奨励されており、自分からフィードバックを求めることも出来ます。具体的にはSlack上でbot（下図）が作られており、それを利用して気軽にフィードバックをお願いできる形です。

これまでのキャリアと働き方が大なり小なり変わる中で、自分の働き方に客観的な視点からフィードバックがもらえるので、「これでいいんだ」とか「もっとこうしよう」とか、改めて自信を持ってその後の仕事に向き合えます。

各社の哲学や事業特性などにより組織の仕組みは異なりますが、Ubieでは上記含め諸々が上手く噛み合って働きやすい環境が整っていると思います。

最後に

Ubieで働いてきた半年超で感じたことを基に書いてみました。
スタートアップのBizDevという職種について、少しでも理解する助けになれば幸いです。

なお、Ubieでは積極的に採用活動を行っています。
各種カジュアルにお話をする場も設けていますので、ご興味あればUbie Dev採用サイトからご応募ください！