Ubie株式会社で、病院向け事業のプロダクトオーナー（PO）を務めている、まつむら（@matsumura_ubie）です。

私は今でこそ開発チームにいますが、前職でプロダクト開発に関わった経験はほとんどなく、入社時は「事業開発（Biz-Dev）」というポジションでした。最初の半年間は「事業開発」や「カスタマーサクセス」という肩書で、セールス・サクセスとその業務型化を中心に活動していました。

Biz-Devとして活動していた当時、また開発チームにいる現在もなお残っている疑問があります。それは「開発経験のないBiz（ビジネス）メンバーは、プロダクト開発にどのように関わればいいのか？」ということです。

経営コンサル出身の私のようなbizメンバーが、どうやってプロダクト開発に貢献できるのか。

今回は、プロダクトの立上げから拡販に至るフェーズの中で、Ubieのbizメンバーがどのような役割を担っていたのかを簡単にまとめてみます。その中で、結果的によかった点・工夫の余地があった点を振り返りました。

なお、本記事では、手を動かして開発を推進する、エンジニア、デザイナー、ドメインエキスパート（医師）といったメンバー以外を、bizと括ります。

【特にこんな人に読んでほしい】
・全社一丸でのプロダクト開発に悩むスタートアップの人
・開発経験がなくプロダクトとの関わり方に悩むbiz出身の人
・事業開発やBizevという言葉が指す役割に悩んでいる人
・ビジネス⇔エンジニアという言葉に心の壁を感じている人

0-Ubieのプロダクトと、その開発における前提

まずはUbieのプロダクトの特徴と、開発体制の前提をお伝えします。

プロダクトはUbieの最重要アセットの一つ、という共通意識で活動

Ubieは顧客に価値を提供するため、ビジネスの最重要アセットであるプロダクトを皆で作ることを全社で重視しています。その中で、開発そのものは行わないbizメンバーがどう関わるか？という疑問が出てきます。

リーンなプロダクト開発のためにスクラムを採用している

リーンにプロダクトを開発していくための方法論として、途中からスクラム開発を採用しています。フォーカスすべきテーマ・プロダクトが流動的で、メンバーが顧客やプロダクトの学習を進めやすい方法論です。

1-AI問診ユビーがアーリーアダプターに受け入れられるまでのフェーズ

まずは、会社創業後から2019年夏頃までの期間に遡ります。この頃、私はまだUbieに参加していなかったので詳細は割愛しますが、開発スキルのないbizメンバーは当時1~3名程でした。

海のものとも山のものともつかないAI問診ユビーを、共感してくれた医療機関になんとか使ってもらうのが重要なフェーズです。この最初の時点ではまだ本格的なスクラム開発ではなく、数少ないメンバーが一丸となって順次開発・導入をしていたと聞いています。

bizメンバーの役割分担は、主に営業提案、医療現場やユーザーの課題探索やプロダクトへのフィードバック収集でした。

このフェーズについて詳しくは、biz出身で当時POだった riho nishimura の記事をご覧ください。

2-AI問診ユビーの拡販が始まり、PMFを達成するまでのフェーズ

アーリーアダプターに次々と契約・導入してもらえる状態になり、導入数や事例を増やしていくフェーズが、2019年の夏から冬にかけて訪れました。私が入社したのもちょうどこの頃です。

この時点で、病院チームには「カスタマーサクセス」の肩書を持って病院に往訪する役割のbizが4名所属していました。1名がプロダクトオーナーになり、私を含む残り3名は病院にて営業・導入を行っていました。

（なお他にも、マーケティングをメインに担うbizメンバーも数名いましたが、開発へ関与するウェイトが高くなかったため、この記事では詳細は省きます。）

bizがやっていたこと①：セールス・サクセス活動とその検証

このフェーズでは、チームは拡販のため、より多くの顧客と向き合っていく必要があります。プロダクトの改善とマーケット拡大方法の検証が同時に走ります。

bizメンバーのミッションの一つは、リードを獲得できた全国津々浦々の病院に往訪し、契約して稼働にこぎつけることでした。また、その最適なやり方を模索し、チームでナレッジを溜めていくことも大切です。例えば、院長・理事長へ訴求しやすいプレゼンパターンを模索する、などの実験を繰り返していました。

私も入社から数ヶ月は、実際に全国の病院を回り、セールスやオンボーディングを手なりで試しつつ、様々なパターンを試してナレッジを集約したり、マテリアルやプロセスを作る活動をしたりしていました。

また、病院業務に特化したSaaSであるため、現場の準備・利用開始・業務への定着をサポートするいわゆる「カスタマーサクセス」活動にも相当のエネルギーを傾けていました。bizメンバーは、いわば業務コンサルのような形で、外来業務を理解し、ワークフローの変更を提案したりしながら、サービスの稼働にこぎつける活動を行いました。

この時期、厚生労働省の補助金の追い風などもあって拡販が進んでいき、セールスやサクセスプロセスの型化、スケール化をさらに急ぐ必要が出てきます。bizメンバーは次第にこの活動に重きを置いていくことになります。

【タブレットに管理タグをつけるという、病院の工夫を社内に持ち帰る】

bizがやっていたこと②：顧客の業務を理解し知見をフィードバック

利用する病院・医師が拡大するにつれて、問診を取り患者さんを診察室に案内するまでの、外来業務の様々なパターンの理解が深まっていきます。それまで「問診に使えるプロダクト」として開発をしていましたが、「業務で使えるプロダクト」にするための様々な課題が明らかになり、それらへの機能開発も必要になります。例えば、問診は患者さんが答えて終わりではなく、看護師が確認したり情報を追記したり、緊急性を判断して診察室へ伝えていたりすることが分かり、これらの業務も何らかサポートする必要が出てきました。

bizメンバーは、導入支援をしながら現場で得た業務上の課題をPOに伝え、開発チームに情報をフィードバックする、という役割も担っていました。また、新機能を病院に紹介し、使ってもらって反応を得る活動もしていました。

【bizの病院往訪がなくオフィスに集まれたら、課題を洗い出して整理】

3-結果的によかった、bizメンバーの役割や活動

PMFまでの事業フェーズにおいて、様々な知見を活用しつつも、bizは半ば手探りで活動をしてきました。結果としてプロダクトは成熟し、契約ユーザーも順調に伸びており、早期から活動していたメンバーには敬意しかありません。結果としてよかったことを整理します。

業務の理解と、ビジネスを並行して進める役割を担えた

先述の通り、業務に入り込んでフィットさせて初めて効果を発揮するSaaSでは、現場の業務を深く理解する必要があります。その意味で、bizメンバーやUXデザイナーなどが、現場に寄り添いながら業務の課題、すでに提供しているプロダクトの課題を理解していったのは効果的でした。

さらに、プロダクトの改善は実際に契約を結んだ医療機関で進めていく必要があります。意思決定者に、ビジョンや効果を語り期待値も調整しながら契約を結びつつ、現場の導入支援をしながら業務やプロダクトの課題も抽出する。この2つを並行で進める上で、bizメンバーは活躍できたと思います。カスタマーサクセスや法人営業、業務系のコンサルティング経験があれば、なお活きそうです。

スキルではなくチームに必要な役割から、やるべきことを考えられた

よくスクラムの解説書には、POやUXデザイナーを中心に、顧客の課題理解を進める、というパターンが典型として記してあります。これを読み、自分でも「デザインのスキルやお作法を身につけて、UXデザイナーとしてスクラムに参加して活動したほうがいいのか？」と思うことはありました。もちろん、中期的にそういうキャリアやジョブチェンジはありえるかもしれません。もっとも、活躍できるほどのスキルが一朝一夕で身につくわけもなく、ド短期適には宙ぶらりんな立場になってしまうかと思います。

大切なのは、どんな人であるかではなく、どんな役割を担うかです。スクラムではどの役割が何人必要、という決まった解はありません。プロダクトの特性やフェーズ、今やるべきことに対してチームとして出力が上がればよく、bizメンバーは手薄になりがちなところや比較優位がある役割を担うのもいいかと思います。

たとえばUbieの場合、当時はデザイナーが少ないために個別病院の導入支援を推進しながら課題を抽出するにはパワー不足でしたので、bizメンバーがリードして進めるのは結果的によい役割分担でした。コードが書けなくても、UIデザインが出来なくても、開発に貢献する方法はあります。

4-いま振り返って工夫の余地があった点

一方で、いま振り返ってもう少しこうしておけば、という「たられば」も見えてきました。

課題を全員で共有する

PO以外のbizメンバーは直接スクラムには参加しておらず、セレモニーもスプリントレビューに出るくらいでした。往訪が多くミーティングに出にくいという理由もありました。そのため、bizメンバーが洗い出した現場の課題はまずPOに共有し、それをPOがセレモニー等でスクラムに伝える、という流れを経ることが比較的多くなりました。

今振り返ると、可能な限り課題はチーム全体で一元管理して、biz、スクラムチーム双方が常に確認できる状態が望ましかったと思います。バックログを管理しているJIRAというサービスにbizが課題を書き込むことも、Slack上でPOへと連携されることもありました。課題が必ずしも全てタイムリーに共有は出来ていなかったかもしれません。

スクラムが課題を深く理解するほど、それだけよい解決ができる可能性が高まります。課題を皆で共有するのが一体的なプロダクト開発チームを作る第一歩だな、と今は思います。

リリース後の検証にも目を向ける

bizメンバーは営業・契約と導入、および課題抽出に注力していました。一方で理解した課題を、新しい機能リリースでどれくらい解消できているのか、その検証は後手に回りがちでした。今回取り上げたフェーズの数カ月後、リリースが全く医療機関に認知されず利用されず、という深刻な状況が起き始めます。リーンなプロダクト開発では、作るところまでが半分、作った後検証し次に何をすればいいか考えるまでが半分ですので、現場に届けて確認する役割をもう少し意識したほうがよかったと思います。

「プロダクトチームに属して活動している」意識を全員が持つ

bizメンバー含め、皆でプロダクトを作っていく機運は共有していましたが、プロダクト開発の一翼を担っている強い意識は持っていなかったのでは、と思います。どちらかと言うと、先述の通りエネルギーと時間がかかる、営業・導入に意識が向いていました。

プロダクト開発は、終わることのない課題探索と解決、改善の連続です。したがって、チームは常にプロダクトを第一に考えつつ、活動するべきです。でなければ、目の前の顧客への提案や解決、あるいは営業件数など個人のミッションに引っ張られてしまうからです。「自分はスクラムには属していないが、プロダクトチームの一員である」と意識を持ち続ける仕組みが必要だと思います。

その意味では、”biz”という呼び方もあまり適切では無いのかも知れません。biz（や事業開発）は役割を指し示すにはかなり曖昧ですし、どちらかというとスキルや出自を示しているようにも思えます。プロダクトチームの中でどんな役割を担っているのか、が分かる名前があると良さそうです。

5-最後に

ここまで、過去の活動を振り返ってきました。全て今だから言える後出しジャンケンですが、少しでも成功・失敗の知見を共有できればうれしいです。

bizメンバーが、過度にスキルや経験を意識することなく、チームの必要な役割を柔軟に担えれば開発に貢献できる、ということが伝われば、なおうれしいです。

今回の話よりさらに事業のフェーズが進むとまた異なる課題が出てくるわけですが、それはまた別の機会に書きたいと思います。

一緒に働きましょう！

Ubieは、複数のプロダクトを複数の事業で作る、同時多拠点突破的なアプローチを取っています。この記事で触れたような0→1に近いプロダクト、1→10の改良を行っているプロダクトなど、様々なフェーズの開発に取り組むチャンスが今後も広がっています！

開発未経験だけど...ぜひプロダクト開発に携わってみたい！と思ったかた、一緒に働きましょう！　カジュアルなご連絡をお待ちしています！

合わせて、関連するこちらの記事もどうぞ！