手を動かしたい系エンジニアのための、リーンスタートアップのやり方

ごきげんよう。mofmof inc.のエンジニア兼代表取締役のはらぱんこと原田敦です。

エンジニアの皆さん。例えば自分の作ったプロダクトが成功して、もう働かなくて良くなったら何したいですか？

ぼくはハワイに住んで、イルカの絵を生成しているラッセンさんと談笑しながらOSSにpullreq送る生活が夢でしたね。ぼく「その絵、ディープラーニングで描けるよ」、ラッセンさん「hey、何言ってるんだガイ！暑さで頭がどうかしちまったのかい？haha」みたいに微笑ましいアフタヌーンを過ごしたい。

ちなみに、ピカソより、ゴッホより、ラッセンが好きか？と聞かれると、そうでもないです。

さて、今回のテーマは「エンジニアのためのリーンスタートアップ」です。今となっては起業プロセスの定番中の定番のリーンスタートアップですが、エンジニアがリーンスタートアップをうまく実践するコツみたいな話をします。

リーンスタートアップとは

今更リーンスタートアップとは云々なんて話をしてもアレですし、みなさん知っているとは思うのですが、前提の確認ということで、まずリーンスタートアップとはなんぞやって話を少しだけしておきましょう。

参考までに。

「リーンスタートアップ」─小さな失敗を重ねて育てる：日経ビジネスオンライン

要約すると、可能な限りのムダを排除して、小さい失敗を効率的にたくさん積み重ねることで、机上の空論ではなく事実を元に学習し、新規事業の妥当性を検証しましょうっていう起業プロセスですかね。

昔から新規事業といえば、まずは顧客インサイトを取るってことで、アンケートなどによる定量的市場調査とかが一般的でしたが、それよりもリアルに課題を持っている顧客を探して出して、直接インタビューすることで、定性的に仮説が正しいことを検証するというようなスタートするのが特徴的かな。

エンジニアにとってリーンスタートアップはツラい

で、このリーンスタートアップですが、手を動かすことが主たる業務で、それに慣れているエンジニアにとっては実はちょっとツラい。

起業プロセスの中から徹底的にムダを排除するわけなんだけど、立ち上げ初期のプロダクト作り込み作業もムダとされているわけです。

リーンスタートアップでは、初期において最も重要とされることは、「高速に学習すること」なので、プロダクト開発は優先度が低いのです。代わりにインタビューだったりとかテストマーケティングだったりとかが優先度の高いプロセスになるので、ほとんどそればっかりやることになるんです。

一般論として、日本でいうエンジニアという職種の人間は、要件に基づいてアプリケーションを、実際に手を動かして作り上げるという作業を主たる業務としていて、そこに喜びを見出す人が多いと思う。かくゆうぼくもその1人だし。

そういう人にとって、これはけっこう精神に堪える。モヤモヤする。ヤキモキする。

ストレスの少ないリーンスタートアップ

だからと言って、まどろっこしいから作ってしまえ！作ってから考えるぜ！おりゃ！っていうのはほぼ失敗します。断言してもいい。

誰も使ってくれないんですよ。とりあえずなんとなく作ってみたものなんて（反省）。

WEBアプリケーションだったり、スマホアプリだったり、便利なものが溢れている現在において、なんとなく適当に作ったものでは勝てないです。

なんでもいいけどポケモン捕まえたいから、とりあえずその辺の草むららへんにモンスターボール投げてみたらミュウツーが捕まった！やったあ！ってくらいに現実的じゃない。リザードンでもいいよ。

だから、誰のどんな課題に対して、どうやって解決出来る、どういうものなのか？を徹底的に分析して、グサっと刺しに行かないとなんです。もはやこれは避けて通れない道。

具体的にどうやるのか？

分かっていながらそれが苦しいのがエンジニアなんですけどね。じゃあどうやればいいの？と。ミュウツーの捕まえ方は知らん。聞くな。Yahooでググれ。

1. 動くMVPを3日以内で開発する
2. 作ったものに対して仮説立てして、最低10人以上にインタビューし、随時アップデートする。
3. 課題仮説を確定させて、対応するソリューションの草案を作る
4. ソリューションのデモを作る
5. デモを使ってテストマーケティングをして、お金を払ってくれる顧客を最低1人見つける
6. 顧客が見つかったら、晴れてプロダクト作り込みを解禁

ポイントは、1と2が一般的なリーンスタートアップとは逆なところと、6ですかね。

動くMVPを3日以内で開発する

ちなみにMVPとは(Minimum Viable Product)のことで、詳しい理解は話の軸がずれるので省略しますが、要するに必要最低限の機能を備えたプロダクトとでも言っておきます。

MVPを開発する際に、エンジニアがハマりがちな3つの罠。

1. 作っている途中でイケてる(と思っている)機能を思いついて実装してしまう
2. 細部にこだわり過ぎる
3. バグのない完璧なものを作ろうとする

残念ながらこれらは、MVP開発においてはこれらは全てはムダにあてはまってしまいます。これをやっている限り数ヶ月かけても出来上がらないです。いや下手したら数年かけても出来上がらないかも。

この3つの罠は絶対に肝に命じて、全力で罠を踏まない努力をしましょう。粗いプロダクトを世に出すという、エンジニア美学に反することであることは分かっています。でも自分の心との闘いなのです。負けてはなりません。

おすすめのやり方は、MVP開発は開発合宿でやりきること。これまじ超絶オススメ。

実際に、mofmof inc.のMy-opeという人工知能チャットBotサービスは1泊2日の開発合宿でMVP版を作りました。

www.my-ope.net

お金を払ってくれる顧客が最低1人見つかったら開発開始する

2〜4のプロセスはリーンスタートアップの一般的なプロセスなので省略して、開発をいつ開始するかっていう話を。

ぼくの実体験からすると、開発出来ない期間が長ければ長いほど、台風の日のビニール傘のように心がポキっと折れそうになります。そこで、開発を開始して良いルールを明確にすると良い。

オススメのルールは「お金を払ってくれる顧客が最低1人見つかったら開発開始OK」というルール。

「開発を進めたい」というい欲求を満たすために、先にビジネス的な課題をクリアしなければならないというプロセス構造を作ることで、モチベーションのベクトルをそっちに向かわせるということが出来るのです。

個人でサービス作るときにも使えるやり方なので、こんな感じでプロセスを工夫しながら進めれば「一生懸命作ったのに誰も使ってくれない」っていうのを圧倒的に減らせます。どうぞお試しあれ。

mofmof inc.では経営企画エンジニア募集してます

ぼくがエンジニア出身（しかも手を動かすのが好きなタイプ）ということもあり、エンジニアならではの悩みに向き合いながら日々頑張っております。

「オレもエンジニアだけど将来自分で事業作りたいからスキルを磨きたい」って方とか「自分でチャリンチャリンビジネス立ち上げたいなー」って方とか、ぼくが苦しんだ経験談とか役に立てるかも。応募お待ちしてます。