もう一度0からARR一億円を目指すなら

畠中翔一 | メディカルフォースCTO

メディカルフォースCTOの畠中です。

『medicalforce』という美容クリニック向けのVertical SaaSを昨年の三月にリリースし、約一年が経とうとしています。

現在、『medicalforce』は下図のように、昨年10月から今年2月までの月次平均成長率は75%という強烈な伸びを見せており、来月末(2022年4月末)にはARR一億円に達しようとしています。

SaaSとしてはまだまだ道半ば、これからT2D3を達成するべく猛進していくつもりですが、一つ壁を超えたのではないかという自負があります。

しかし、決してこの一年間満点を出せていたわけではなく、反省するべき点やもう少し工夫すればもっとスピードをあげれていたのではないかと思う点は多々あります。一年間工夫し続け、様々な変遷を辿った過程で誇れる点も多々あります。

今回はリリースからの一年間を時系列に沿って辿りながらSaaS開発における良否をまとめ、もう一度リリースから一年でARR一億円を目指すならどうするかという形で文章にしたいと思います。

以下、目次です。

medicalforceの着想(2020年9~10月)

時は遡って2020年の9月、起業すべくエンジニアを探していた現CEOの大嶋さん(@tusbasadaniel)と出会いました。実はこの時すでに大嶋さんの中では構想があり、最初はクリニック向けのCRMを作ろうというアイデアでした。その後すぐにプロダクト開発開始のためにもう一人エンジニアを探し始め、高校時代からの友人であった現COOの組田(@reus_k95)に参画してもらいました。(詳しくは大嶋さんのnoteを読んでください)

まずは今持っているアイデアがターゲットに刺さるかどうか検証するために、クリニックで院長をされている方々にアポをとり、現場へ赴きました。

その結果、クリニックの業務においては想像よりはるかに複雑かつ膨大なデータを扱う必要があることが判明し、また多くのクリニックはまず現場のデータを整頓し施術などの業務に集中することを求めている様な印象を受けました。しかし、プロダクトに対しての共感は得ることができたため、方向性は変えずに優先度のみを変更し開発に取り掛かりました。

ここで開発に取り掛かる前に現場へ赴いた点は非常に良かったと感じています。特に、創業メンバー三人で出向いたこと、開発者が出向いたことは今でもかなり影響が大きいと思っていて、僕達に業界経験者不在、ドメイン知識が全くない状態でスタートしているにもかかわらず早い段階でPMFに近づけました。

ただ、このタイミングでより多くの現場に赴くことで多角的なフィードバックをもらい、仮説の精度を高めることができれば、もう少しスピードは上がったと思っています。また、この段階でプロダクトを直感的に理解してもらうための紙芝居（Figma等で簡易のものを作成）を用意しておくと、なおフィードバックは貰いやすかったと思います。

いざ、プロダクト開発(2020年11月~2021年2月)

ということで、この頃にはすでに作りたいものの構想は三人の中で共有されており、開発が本格的にスタートすることになりました。この頃の構想は一年経った今でも完了しないほど壮大、かつ一年経っても変わらないほど強固なものです。

まずは、技術選定に取り組みました。実は、この技術選定には二週間という膨大な時間をかけて取り組みました。組田との方針の違いで朝から終電まで永遠に議論していた日も少なくありませんでしたが、技術選定がその後の開発スピードに及ぼす影響は計り知れないので、ここに時間をかけたことは正しかったと思っています。(詳しくは後日また記述します)

ここからの数ヶ月はひたすらMVPを作るという作業に充てられました。この頃は僕も組田もまだ学生であり、卒論をこなしながら開発を進めていたため、かなりハードだったことを覚えています。

この段階でも、技術選定に時間をかけた点・MVPといえど基盤であるインフラやDB設計は作り込んだ点は後になってかなり良かったと感じています。SaaSは、“フィードバックをもらい、開発や改修を繰り返す“というループとなりますが、そのループが始まってしまうともう後戻りはできません。あとでリファクタリングしよう、インフラは時がきたらきちんと作り直そうは不可能だと言えると思います。

ただ、MVPが出来上がるまでのこの段階では、どうしても開発メンバー以外の手が空いてしまうことが多いです。現在ではノーコードやローコードでプロダクトを作ることができるため、この様なツールを用いて実装予定の機能について紙芝居を作ってフィードバックをもらうというような仕組みを用意しておけば、さらに高速なフィードバックループが回せたかもしれません。ただし、先にも述べた通り、ノーコードやローコードで作成したプロダクトを提供することはSaaSにおいてナンセンスな気がしています。中長期的なスピードという点ではコードを用いた開発の方が確実に優れているため、検証のために用いるに留めておくべきだと思います。

いざ、リリース(2021年3月)

2021年3月時点ではMVPという名のなんとか動くプロダクトが完成しかけていました。この時点で数名の医師の方々から定期的にフィードバックをもらえる状態にはなっており、なんとか人に見せられる状態にはなっていました。とてもβ版リリースもできないほどの完成度だったはずですが、ここで思い切ってリリースすることにしました。

理由としては、早い段階で多角的なフィードバックを得たかった、実際に市場に受け入れられるかの検証が必要だと感じた、あるいは社内開発メンバーの閉塞感が高まっていたことあるかもしれません。結果的にこれは一年経ってみてかなり良い意思決定だったと感じています。

売れるためにはたくさんのフィードバックをプロダクトに反映することが大切なので、フィードバックを多角的に貰う状態にする事がなによりも大切な為です。ただし、これは絶妙なタイミングだったと思っています。フィードバックを貰うためには期待をプロダクトにかけてもらう事が大切だと感じており、そのような状態にあったことはよかったと思っています。

また、この段階で数件導入が決定しプロダクト開発のモチベーションと期限ができたことは良かったです。

MVPからMSPへ（2021年4月〜2021年7月）

前述したように、いざ世に出してみると思ったよりも商談での反応は悪くありませんでした。
当初の仮説通り、既存のオペレーションやシステムに対するペインは深かったためこの段階でかなりPSFはしているのかなという所感でした。

この段階では「〜という機能があれば入れたい、〜が出来れば良いんだけどね」といったような反応がかなり多かったと記憶しています。単なる営業の断り文句だったのかもしれませんが、僕達は全部片っ端から実装して持っていきました。

というわけで、ここから突然にとんでもない量の開発タスクが降ってくることになりました。この時期は実際にまだプロダクトが現場で使われることはなかったため、開発環境しか存在せずひたすら毎日開発しまくっていましたが、導入も迫っていた事・前述したように商談が一種の期限になっていた（商談駆動開発とか言ってました）ことから、既存の開発オペレーションが崩壊し、やっとスプリントごとにスコープを定め実装しQAも行うという仕組みが誕生しました。

またちょうどこの頃、下記のpodcastを聴き一人目のCSとして入社目前だった秋田さんにQAを任せるという決断をとれたのはかなり大きかったと思います。
この仕組みは今でもかなりワークしており、10月以降の伸びに確実に寄与しています。(詳しくは秋田さんのnoteをお待ちください)

このあたりで、暴走列車のように開発し、カオスを生み出していた開発チームが仕組み化されたのは良い点でした。ただし、この仕組み化はリリースと同時に作り出しておくべきでした。

また、この時期は失敗も多くしたと感じる時期です。特に機能要望が増えていくにつれて優先順位の付け方とプロダクトに本当に実装するかどうかはかなり判断が難しかったです。

まず前者ですが、前述した通り元々プロダクトの構想が壮大だったため、商談時に上がってくる要望とやりたい事がマッチしているからといって、必ずしもそれがMSPへの近道ではないという事は大きかったと思います。例えば、7月を丸一ヶ月用いて実装した機能は現在ほとんど使われていなかったりと優先順位を変更するべきであったところは多々あります。ただ、この時点で当初想定していた構想へのリサーチや土台ができていたことが今後生きて来る可能性は十分にあるので一概には失敗とはいえませんが、最速でARRを短期的に伸ばすという観点では優先順位の変更が必要でした。

また、後者においても同様にプロダクトの構想が壮大だったため基本的に機能は実装しまくるという意思決定をしていました。「機能は実装しすぎてはいけない」というSaaSのセオリーが頭の片隅にずっとあり、かなり迷っていた時期でもありました。ここは海外Vertical SaaSの成功事例として挙げられるSquireやToastの多機能さなどから一定の裏付けはあったこと、また『medicalforce』が解決する課題が「現場のバラバラになったデータ・ツールを一元管理できる」であったことなどからとにかく機能は増やしました。SaaSの管理SaaSなどが出てきている今、特にVertical SaaSではこの様に一元管理・業務が全て一つのプロダクトで完結するというところに価値が置かれるという事は現在も強く信じており、これからも機能は積極的に充実させていくつもりです。

運用開始から急成長(2021年8月~2021年12月)

商談での機能要望をいそいそと実装している間についに本番での運用開始が本格的にスタートし始めました。本当に現場で使われて大丈夫なのかとかなりヒヤヒヤしていましたが、大きなインシデントはなく動いているのを見て安心したのを覚えています。

電子カルテは医療現場におけるプラットフォームであるので、その性質上リプレイスのコストが高く、新規開業での導入は進みそうな一方で、乗り換えに対しては消極的かつスイッチングコストを払ってでも導入してくれるための魅力がないと難しいということは、当初から理解していました。
実際、伸び悩んでいることを相談した先輩方には厳しそうとピボットを勧められたこともありました。

ところが、この時期から既存のペインへの解決に加えて『medicalforce』でしかできないことを積極的に実装してきたこともあり、徐々にリプレイスができそうな雰囲気がありました。特に9月以降の商談では、以前同様「〜という機能があれば入れたい、〜が出来れば良いんだけどね」と言われるものの多くは実装済み・近々実装予定であったため、明らかに商談での先方の反応が変わり始めていました。

またこの頃から「KPT」を導入し、開発チームとして強くしていくということを意識し始めたのはかなり良かったと思います。

実際のKPT

しかし、ここでも多くの失敗はしています。結論、この時期はプロダクトに対して機能を増やしすぎたことが失敗でした。

前述したメリットとしての“機能を増やす“とこの時期の失敗としての“機能を増やす“は別物で、ここで述べる機能は同じ業務を行うのに様々なフローや導線を追加したりといった細かい機能のことを述べています。

急成長に耐える為に(2022年1月~現在)

前述のように細かい機能の充実で、様々な問題が噴出しました。具体的には設定オプションの増加によるプロダクトの操作難易度の上昇・フローの細分化によるCSの方々の負担が増加した事、設計の難易度の上昇・細分化したフローそれぞれに要望が上がることによる要望のコンフリクトにより保守の難易度が上がったこと、それに加えてフローの細分化によりQA表の項目増加などです。

社内全員、特にCS/エンジニアの負担が大きくなっていっているのを感じましたし、このまま進むと体感、成長速度の二乗に比例して負担が増加しそうだったので早急に対策をする必要がありました。そこで、社内で議論した結果、プロダクトのベストプラクティスを確立しそれ以外のフロー・機能を取り除くことにしました。

これは結果的にかなり功を奏し、顧客からの質問数/オンボーディングコストの減少によるCSの方々の負担の減少、システム設計がスッキリしたことによる内部品質の向上、QA表の項目の肥大を止めれたことによるプロダクト品質の向上など様々な指数において良い方向に向かいました。

もう一度0からARR一億円を目指すなら

最後にもう一度0からARR一億円を目指すなら、どうするかということをまとめたいと思います。

  • 開発を取り掛かる前に過度になるくらい仮説検証（必ず創業者とエンジニアは同席）

  • 仮説が固まったらエンジニアはMVP開発開始(この時に初期のインフラ・設計は手を抜かない)

  • MVP開発中はノーコードツールやローコードツールを用いて将来の構想も先取りで仮説検証して、機能実装の優先順位をつける

  • プロダクトではベストプラクティスを作ることを意識


これらに加えて、一年間全員がやるべきことを貫き通したこと、セオリーを無視しまくるパンクさがあったこと、とにかく顧客と向き合い続けたこと、良いメンバーに恵まれ、チームで戦う意識があったことが何よりも重要な要素だったと思っており、コアバリューにも落とし込まれています。

コアバリュー

弊社では当初の壮大な構想を実現するべくこれからも積極的・野心的にプロダクトを成長させていきます。
まだまだ仲間を募集しているので、是非ご連絡ください。


この記事が気に入ったらサポートをしてみませんか？