これはなにか
2019年も、あと残すところ2日という所まで来ました。
個人的には、2019年1月末を最終出社としてメルカリを退職し、中高の同級生である田（でん）と創業した株式会社ドクターズプライムへのフルコミットを開始した、転換点となる年でした。
このポストでは振り返りとして、ドクターズプライムを始める上で、初期から大切にしていた仮説検証の進め方、「作らないものづくり」について書きたいと思います。
3年前の再会
本題に入る前にすこし昔話を。
実はこのDr.’s Primeという事業は、今から3年半ほど前にさかのぼった、2016年5月に田と再開したことをキッカケに始まっています。
私がメルカリに入社したのが2016年の7月なので、実はメルカリに入る前から行っていた事業になります。
チームのバックグラウンドとしては
- 田
- 聖路加国際病院（救命救急医）
- メドレー（Sales）
- 私
- CyberAgent America,Inc.（Producer）
- サイバーエージェント（Director/Project Manager）
- メルカリ（Product Manager）
という構成で、創業チームに技術的バックグラウンドがありませんでした。
医療業界へのパス、セールスの経験は田が持っていて、プロダクトマネジメント、仮説検証の経験は私が持っている。しかし技術バックグラウンドがなく、ものが作れないというのがチームの課題でした。
作らずにどうやって検証するか
このチームでどうやって、サービスを展開し、仮説検証を行っていくか。
そのひとつの形が「作らないものづくり」でした。
「作らないものづくり」とは、必要最低限の開発、ないしは開発を行わない状態で仮説を検証し、検証できたあとに作り込む進め方を指します。
具体的には既存のwebサービスなどを組み合わせて、検証を進めます。
Dr.’s Primeでは、Google Spreadsheet, Google Form, Gmail, Google Apps Script, LINEグループ, LINE@等を利用しました。
HTML, CSSは書きましたが、これも今ではSTUDIOあたりを使えば不要そうです。
プロダクト開発・製品ありきで考えるのではなく、検証したい仮説とその証明ありきで考えることに重きを置いていました。
初期のDr.’s Primeの構成
具体例があったほうがわかりやすいので、実際に初期のDr.’s Primeの構成を見てみましょう。
Dr.’s Primeは医師と病院をつなぐ、非常勤救急医の採用マッチングプラットフォームです。
簡略化した、サービスの利用フローは下記です。
シンプルなTwo Sided Platformのフローです。
これを実現するにあたって、初期のMVPとして、メインループにあたるフローのみを次のような構成で作りました。
- 求人の投稿:
- 病院担当者がGoogle Formsで求人情報を登録
- 求人の掲載:
- スタッフが手作業で応募フォームに転記（運用でカバー！）
- 閲覧・応募:
- iframeで応募用Google Formsを埋め込んだwebページから医師が応募
- 応募の通知:
- 応募が入るとGoogle Apps Scriptが応募テーブルを読み、Gmailを病院に送信
- 採用の判断:
- 病院は採用を判断し、求人案件別の専用メアドに採用する/しないのメールを送信
- 採用の通知:
- Google Apps Scriptで採用判断のメールをパースして読み解き、医師に結果を通知
このように、入力のインターフェースをすべてGoogle Formsに寄せて、そこから自動転記されるGoogle Sheetsをもとにデータベースを作っています。
そのGoogle Sheetsデータベースに対して、Google Apps Scriptで読み書きして、Gmailを出力のインターフェースとして利用者に通知を行います。
また、この図を見ればわかる通り、Google Sheets, Google Forms, Gmail, など非技術者でも直感的に扱えるものを中心に構成されています。
Heroku, HTML, CSS, Google Apps Script, Basic認証などは少し学習する必要はありますが、ググったりProgateを一周やる程度の学習コストで済みます。
サービスを展開する上での機能と利用ツールをマッピングすると下記のようになります。
- 静的ページのホスティング: Heroku
- 静的ページの作成: HTML, CSS
- 入力インターフェース: Google Forms
- データベース: Google Sheets
- サーバー・バックエンドシステム: Google Apps Script
- 認証: Basic認証
- 通知: Gmail
シンプルなマッチングプラットフォームであれば、これらでMVPは成立します。
当然、色んな面で突っ込みどころは満載なんですが、ベータである状況をご理解頂いた、特定の方を対象としたMVPであれば検証は十分進められます。
この「作らないものづくり」で検証を進めて、一定のトラクションを確認することが出来たため、安心して本格的な製品開発に入ることが出来ました。
そのビジネスってスケールするの？に答える
なぜ「作らないものづくり」を選んだか、ということを考えると、理由がいくつかあります。
- 初期のチームにエンジニアリングの能力がなく、ありものでなんとかするしかなかった
- 保守的なので、きちんと市場ニーズがあって、サービスとして成立することを見極めてから進めたかった
このあたりが主な理由です。
しかし、それだけではありません。
新しいサービスを立ち上げる際には、スケールに耐えうるシステムを考える前に、そもそもそのビジネスってスケールするの？という問いに答えなければいけません。
どんなに立派でモダンなアーキテクチャでスケールするシステムを作ったとしても、ビジネスがスケールしなければ、それらは無用の長物になってしまうからです。
その問いに答えるために、自分たちにとって一番最適な進め方がこの進め方でした。
作らないものづくりの利点
作らないものづくりで仮説検証を進めてきて、よかったなと思った点は下記でした。
- 創業チームに開発力がなくてもすぐに仮説検証が始められる
- 仮説検証のサイクルが早くなる
- 提供価値が受け入れられることが証明できてから作るので無駄がない
- ファイナンス的な負債を負わずに仮説検証ができる
4点目はチーム内に開発力があれば問題にならないので、状況によりけりなのですが、私達にとってはとても大きなことでした。
これによって、エンジェルラウンドやシードラウンドで一定比率の株式を放出することなく仮説検証ができ、サービスを本格展開することが出来ました。
作らないものづくりが合わないケース・欠点
一方で、作らないものづくりが合わないケースや、マイナスになる点も勿論あります。
（人間には、自分の決定や仮説をサポートする証拠ばかりを集めてしまう、確証バイアスというバイアスがあります。私の論も多分に確証バイアスを含んでいるでしょう）
- サービスの種類やサービスのコアな提供価値によっては、ちゃんと作らないと検証ができない場合がある
- 創業チームに開発力がある場合は、作ってしまったほうが逆に早く検証ができる場合もある
- 技術的な負債が残る可能性がある
勿論すべては状況によりけりなので、「これこそが唯一至高の仮説検証・MVP作成方法である」とは言いませんが、少なくとも当時の私達にとっては最善の手法だったと思います。
まとめ
ここまでをまとめると、下記の3点になります。
- 「作らないものづくり」とは既存のツールやwebサービスを組み合わせて、仮説を検証する進め方である
- スケールに耐えるシステムの前に、そもそもそのビジネスってスケールするの？という問いに答えなくてはならない
- 作らないものづくりによって、仮説検証のサイクルを早められる場合がある
一方で、チームの保有する能力によっては普通に作ったほうが早く検証できるので、自チームの状況を見極めて、最速の方法で仮説検証を行うのが良いと思います。
採用やってます！
興味を持っていただいた方はコチラからご連絡ください！
とりあえず話を聞いてみたいという方は TwitterのDMを開放しているので、お気軽にどうぞ！