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