とある医療スタートアップ転職後の絶望10選 【事業開発編】

スタートアップに入社してすぐ「こんなはずではなかった…」と絶望することはありませんか。
少なくとも自分はありました。1回どころか何回も、、、

Ubie Discovery(AI問診ユビー/AI受診相談ユビー) ではそんな絶望を防止すべく、行動指針の中で"やりがちだけど推奨されない行い"をdont’sとしてカルチャーガイドにまとめています。
新入社員にはそのガイドに沿ったアンケートも実施。

今回は社内の集計を踏まえつつ、自身の失敗も交えて踏みがちなdont’sを紹介します。
※あくまでUbie Discovery内のカルチャーが基準となっています。すべてのスタートアップがこの限りではありません。

Don'ts①「発言するときは個の Professional として他のメンバーからも評価されるようにかっこよく動きたい」

「評価される為のムーブ」はスタートアップには不要です。
変化が速く不確実性の高いスタートアップにおいては、学習の為に早く失敗することが推奨されています。
仲間を信じてコミュニケーションのハードルをとことん下げましょう。
心理的安全性が生産性に必要不可欠なのはGoogle Project Oxigenでも触れています。
ちなみにUbie DiscoveryではManager＆人事評価はないので、評価を気にせず事業に集中できます。

Don'ts②「相手の時間を奪わないようにまずは資料を探して、後でまとめてDMしよう」

すぐに聞く。情報は鮮度が命。特に変化が目まぐるしいスタートアップは尚更です。昨日つくられた資料が旧いなんてことはざらでした。
誰に聞けば良いか分からなければそれも聞く。臆せず@here を使い倒しましょう。
またUbie Discoveryでは透明性の観点で社内DMも禁止です。誰かの疑問は貴重なAssetの1つです。

Don'ts③「自分に出来ることを可能な限り色々とやっていく」

「いかにやらないか」に意識を傾けるべきです。
やるべきこと・やりたいことは腐るほどある上に、あちこちから降って湧いてきます…
自分の場合は、一見華やかな仕事(ex.大企業とのアライアンスなど)や緊急度が高い(と思っていた)仕事に振り回されました。しかもそういう時こそ無自覚で、アドレナリンジャンキーの沼にはまりがち。
「マルチタスクは生産性を40%もさげる」という米国の研究結果もあります。フォーカスの鬼になりましょう。

Don'ts④「やりたくない仕事でも責任をまっとうする。組織人として当たり前。」

当事者意識や自己犠牲で頑張れたとしても、継続はしないし健全ではありません。やりたい人を社内で探すか、自ら採用の旗をふりましょう。
Ubie Discoveryではwillも伴った玉突き人事が推奨されています。皆カジュアルに玉突きを呼びかけています。

Don'ts⑤「Manager不在だとフィードバック貰えない」

繰り返しになりますがManagerは1名もいません。
その上でOKRを使った目標設定と、相互フィードバックの機会を仕組みとカルチャーで担保しています。
また、最近は社内向け全員参加の”PMF工場”や”スクラム工場”もスタート。
社内は最高の実験場であり学習の場。アンケートも頻発しています。

Don'ts⑥「失敗しないよう戦略・戦術を練る。その上でチームの総意を確認しながら進める」

報告や合議では遅い。ロール内のことは誰の合意もなく最短の意思決定が求められます。その為Ubie Discoveryではホラクラシー組織を採用しています。（記事はこちら）

また仮説に仮説を重ねた戦略は陳腐化しやすく、
失敗=学習機会なので、さっさと失敗しましょう。
絵ばっかり描いていてもなんの課題も抽出されません。

" Fail fast, fail cheap, and fail smart. "
by エリック・シュミット（元Google CEO）

注意として不可逆性は適切に見積もることが求められます。
　①インベストが大きく後戻りが難しい開発(データ基盤など)をする場合
　②リスクが高い場合（法規制を伴う、患者生命に関わるなど）

前職で治験の企画・開発を担当していたメンバーやProfessionalファーム出身者は特に苦労したポイントだったようです。

Don'ts⑦「検討の段階から最適化や実現性まで考えて開発」

スケールしないことをしよう　by Y Combinator

あのZapposも当初は簡易サイトだけつくって靴は後から買って届けていたそうです。
開発に着手する前にまずは資料や簡単なモックを利用して検証と探索を繰り返すのも有効です。
その際、顧客の「欲しい」という言葉だけを鵜呑みにするのは危険です。
検証精度は「欲しい」<「登録」<「購入」<「利用継続」の順で高められます。

社史に残るとされる失敗事例を1つ紹介します。

顧客要望を元に、看護師問診用タブレット機能を開発しましたが全く使われませんでした。当初の課題仮説としては、「看護師が追加問診を聴取する際、持ち歩けるPCがなく負担が大きいのでは？」というもの。

■まず検証すべきだった課題の前提
看護師が追加問診を実施する割合 
> そのうちPCを利用しない割合
>> そのうち聴取と転記にxx分以上かかる割合

特定の顧客に引っ張られ仮説が正しいと思い込んでしまう確証バイアスにも注意が必要でした。

一方でスケールしない形で検証してうまくいった成功事例もあります。

・ お薬手帳のOCR機能を検証する際に、開発せず画像を裏で手動転記して顧客に提供。
・ 1ヶ月かけず新機能を開発した際は、資料のみの案内でアポ獲得できるかを検証。

Don'ts⑧「満を持して新機能MVPをリリース。あれ？クリックされない…」

「顧客インタビューを重ねてわかった、KSFは機能完成度だ！MVP作り込むぞ！」
結果、全くクリックされずに絶望したという失敗談がありました。
ファネルでいうと認知 > 初回利用 > リテンションの順番になりますが、今回は認知不足が要因。
機能を作り込む前にUIや訴求メッセージの検証を早く進めるべきでした。

Don'ts⑨「PL的に収益が上がる案件を優先しよう」

中長期を見据えた企業価値の最大化 >>>>>>>>> 短期的なPLです。
目先の収益を優先し案件を獲得した結果、開発リソースが大きく割かれ、Assetではなく負債が蓄積する結果に…。
盲目的なPL思考はやった感は出るものの往々にして技術的/営業的負債を残しやすく中長期的な生産性が逓減します。

"有利な条件でVCから資金を調達するために、スタートアップ側がPLを作ることを意識し始めると、投資対効果の悪い施策を打ってでも顧客数を増やして売上を増やそうといった発想に陥ってしまいかねません。"
引用：朝倉 祐介氏　「PL脳」が会社を滅ぼす！アメリカでより深く理解されているファイナンスの付加価値とは？

Don'ts⑩「顧客から疲弊の声があがったので週3リリースを止めよう」

とある日のCS「頻繁な仕様変更でお客様が疲弊しています…」
でもやめません！その理由は

 "ユーザーに価値を届ける上で、何が真に価値あるものなのか、それは結局ユーザーの行動から学習しないと分からないから。"

影響範囲が読めない新機能やレイアウトの大幅な変更は、PoC顧客のみに絞ってリリースしています。
その結果、当初は懸念をあげていた顧客も「こんなにすぐ改善してくれるの！？」と。今では積極的に改善要望をリクエストしてくれるようになりました。

以上、転職後に陥りやすいdont’s事例の紹介でした。
0→1や1→10といった不確実性に向き合うUbie Discovery組織の事例が少しでも参考になったら嬉しいです。

最後に

当初は”30選”というタイトルにしようと思ったほど、社内にはまだまだ沢山の絶望事例があります。
このような絶望にワクワクされる方はもちろん、
「絶望レベルが全然足りないよ！」という方はUbieの事業や組織運営についてもう少し詳しく紹介させてもらえませんか？
（ここでは話せない絶望事例が聞けるかもしれません。）
詳しくはこちらのサイトからご覧ください。カジュアル面談や説明会もあります。

Ubie 採用サイト