スタートアップの仮説検証におけるエンジニアリング

ガイアックス スタートアップスタジオでスタートアップにチャレンジしたい学生や若手のエンジニアと話してきて、私が知っておいて欲しいなと思ったことを Gaiax AdventCalendar 2018 をきっかけに、ざっとまとめて書いてみました。
すでにスタートアップな人たちにとっては、「それな！」って感じですが、スタートアップに興味があるエンジニアや、これから何人かで起業してその中のエンジニア担当する方には、今後の参考になるかと思います。

定義

本題に入る前に、まず言葉の定義を揃えた上で読み進めてもらった方が理解しやすいと思ったので、超簡単にですが、はじめに言葉の定義を解説します。

スタートアップとは？

スタートアップというのは、単に設立したばかりの新しい企業のことではなく、大きくは二つの要素がある企業のことを「スタートアップ」と呼びます。

• 新しいビジネスモデル
• 急成長を目指した戦略

新しいビジネスモデルというのは、ビジネスとして確立されていない対象又は手段よって利益を生む仮説です。
例えば、

• 従来型のビジネスモデル：
  • 「企業向けWEBサイトの受託開発」
• 新しいビジネスモデル:
  • 「企業向けVRモデルの受託開発」　（対象が新しい）
  • 「企業向けWEBサイトを、AIで自動生成するサービス」　（手段が新しい）
  • 「VRモデルを、AIで自動生成するサービス」 （対象も手段も新しい）

このように、対象がVRなどいままでなかったものであったり、AIで自動生成などいままでなかった手段であったり独自の新しい価値を提供するビジネスです。（※わかりやすくするため、新しい価値がテクノロジーで説明していますが対象も手段もテクノロジーでない場合があります。）

また、急成長を目指した戦略というのは、

• 数十年、数百年や永続的に続けるための戦略ではなくて、短期的に大きく成長することによって成し遂げたい状態やゴールが明確にあり、それを実現するための戦略

よって、スタートアップとはビジネスの対象や手段、又はその両方が確立していないにも関わらず、急成長を狙っているため非常に不確実性が高いのが特徴です。

仮説検証とは？

まだ結果が確立していないことにたいして、「こういう結果になるはずだ」という仮説を立てて、実際にそれがその通りの結果になるというのを検証をすることが「仮説検証」です。 リーンやアジャイルなどでもよく使われるために、IT業界ではかなり浸透しているため一般的な用語になりつつあります。しかし、「仮説検証」という言葉の意味が人によって捉え方が食い違うケースがあるため、私が考える仮説検証の事例を説明します。

• 事例
  • ×
    • 「便利なやつ思いついたので、作ったら使われるはず」 (仮説がないため、単なるギャンブル)
    • 「●●で困ってる人がいる。これを作ってみよう」 （仮説があるが、検証していない）
  • ◯
    • 「●●で困ってる人がいて、このソリューションならお金を払ってでも欲しいという人が10人いたので作ってみる」 (仮説に対して、再現性のあることを証明できる)

仮説検証におけるエンジニアリング

スタートアップにおける仮説検証で、私が意識的に気にしている点をいくつかご紹介します。

いかにコードを書かずに、サービスを検証するか

仮説検証をしていくにあたって、まだ再現性が証明できていない仮説に対していかに低コストに検証できるかがビジネスとしては重要な問題になります。趣味や生涯学習としてサービスを作るのは個人の自由ですが、スタートアップでは短期的な急成長を目指しているため、無駄なことに時間かけててはいつまでもサービスが立ち上がりません。

特に、仮説検証が初期の段階では、まだそのサービスが誰が使うのか、お金を払うほどのものか、利益や急成長を生むほどたくさんのユーザに使ってもらえるのかは不確実です。
そのため「検証するためにプロダクトを作ろう！」とコードを書き始める前に、他に検証方法がないか考えてみましょう。

• 検証手段
  • 顧客となり得る人に、詳しくインタビューしてみる
  • SNSなどで投稿して、リアクションをみてみる
  • 不特定多数にアンケートをとってみる
  • サービスのイメージ画像をつくってみてもらう
  • XDなどで、モックを作ってみる
  • LPで事前登録を募ってみる
  • 既存のプラットフォームやサービスの組みあわせて作ってみる
  • 裏側の仕組みは手作業にして、外枠だけWEBサービスを作る
  • 登録や申し込みや紙で対応して、プロダクトを都度セットアップして利用してもらう

いざプロダクトを作り始めると、数ヶ月かかってしまうこともざらです。だからこそ、作ったプロダクトがお金を払ってもらえるどころか誰にも使われないものを生み出してしまう前に、これなら使ってもらえるという確証を得てからの方が無駄なものを作らずに済みます。

気をつけなければいけないのは、「それ、いいかもね」、「使う人いそうだね」や「良いサービスだね」など、ポジティブフィードバックを鵜呑みにしてしまうことです。ポジティブフィードバックをくれる人は、事業化する際に応援や協力してくれるかもしれない人たちなのでそれはそれで重要な存在ですが、検証では意味をなしません。
「そのサービスが絶対に欲しい」、「いくらなの？使わせて！」や「今すぐ使いたいんだけど、まだ使えないの？」など、本当にそのサービスを使ってもらえるユーザを見つけることが重要です。

詳しく体系的に学んで実践したい方は、こちらの本をお勧めします。

リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)

不確実性の削減と、技術における楽しさの折り合い

エンジニアであれば、いかに可読性の良い綺麗なコードをかけるか、最新の技術トレンドや流行りのOSSを利用していけるか、耐障害性が高く高負荷にも耐えられるスケーラブルなアーキテクチャなど、技術的な課題に対して解決することは楽しいと感じる場面も多いはずです。すでにビジネスとして利益を生み出しているサービスでは重要なことでも、スタートアップの仮説検証では優先度が低くなる要素は多いです。

スタートアップでの仮説検証フェーズでは、なにはともあれ不確実性をできる限り低くして成功確率をあげることができるかが最優先です。その不確実性を削減するためのエンジニアリングとは、私は何を意識していくのかが重要だと考えています。

• ソリューションが受け入れられるかどうかを素早く検証するための開発スピード
• 仮説検証を繰り返すための、変更容易性が高い状態を保つための保守性
• 上記の二つを得るために、改善と振り返りをし続ける開発プロセス

経験もドキュメントもケーススタディも多い息の長い技術を使うかのか、利便性が高まった最新技術を導入していくのかは学習とトラブルシュートのコストとの天秤となるし、テストコードを書くべきかもどうやってリファクタリングしていくかも開発スピードと変更容易性を保つ作業との天秤になります。ビジネスにおける仮説検証と同じようにエンジニアリングにおいても、「こっちの方が良いはずだ！」と判断しチャレンジして結果はどうだったのかを振り返り続けることが良いプロダクトと良いエンジニアリングになると考えています。

エンジニアとしては、そのため技術そのものもとても重要だしそこに楽しさ感じるのは当然ですが、仮説検証するためのプロダクトと開発プロセス（チーム）を磨き上げていくところとの折り合いが必要ではないかと考えます。

要はアジャイルではあるのですが、私にとって本質的な理解を助けたのはやっぱりこの本でした。

アジャイルサムライ――達人開発者への道

スタートアップで技術が事業のアドバンテージになるためには

最後に

もしこの記事をみて、スタートアップをもっと深く理解したいと思った方向けにいくつかの紹介しておきます。

Startup Playbook

Y Combinator のスタートアップの概念的なノウハウが詰まっており、年に数回くらいは時間ができたら読み返しているすごく良い資料です。

日本語訳: https://bfore.hongotechgarage.com/entry/startup_playbook_sam_altman_y_combinator
原文： https://playbook.samaltman.com/

LEAN STARTUP

STARTUP STUDIO

いまガイアックスで私が支援しているで取り組んでいるスタートアップを生み出していく仕組みがこちら。ガイアックスのスタートアップスタジオを理解することができます。

STARTUP STUDIO

FUTURE PROOF

ガイアックスのスタートアップスタジオの一環として取り組んでいるイベント。これから起業やスタートアップへの参加を考えている人たち向けに、アイデアワークショップや、事業アイデアのレビュー、投資判断のピッチイベントなど開催しています。イベントのお知らせを受け取りたい方は、気軽にコミュニティメンバーに参加登録ください。

Doorkeeper : Gaiax STARTUP STUDIO