「リリースの遅れとして現れる目立った問題がいくつかあります。すなわち、遅すぎる仕事、問題に対する不正確な理解、ユーザーに対応しなければならないことへの不安、非難を受けることへの不安、あまりに多くの異なる事柄に取り組むこと、過度な完璧主義です。幸いにも、かなり早い時期から無理にでも何かを発売するというシンプルな手段によって、この全ての問題に対処できます」 ――Paul Graham『スタートアップを潰す18の間違い』
Y Combinatorを経験しているとき、あなたが受けるアドバイスの一つは「早期に出荷する」こと、つまり準備ができたと自分で思うときよりも、かなり前にローンチするということです。
私のスタートアップでは、このアドバイスに従っただけではありませんでした。私たちはやること全てに対し、ほとんど不条理なレベルまでその考えを染み込ませました。実際に、早期かつ頻繁に出荷することは今や私たちの最も大切な企業としての行動です。それは自分たちの成長に役立ってきたと私が確信している精神であり、採用すればほとんど全ての企業が恩恵を受けられるものです。
今から、これの意味するもの、そしてその実行方法について、戦術面のアドバイスを軽くお伝えしたいと思います。
なぜ早く出荷することが大切なのか
製品を出荷することの利点はきっと誰の目にも明らかなはずです。出荷しなければ、成長はありません。そして定義からして、スタートアップでもありません。
問題なのは、誰もがあまりに遅く、あまりに少ない頻度で出荷しがちということです。プライド、完璧主義、仕様の変更、批判への恐れ、拒絶への恐れ――多くの心理的要因が合わさってあなたの出荷を阻みます。
私は身をもってこれを知りました。思い返せば、私たちの会社のごく早い時期の製品開発は笑えるほどひどいものでした。私たちはユーザーの全くいないものに数か月かけて取り組んでいました。自分たちが開発でき、成長の起爆剤となるような機能セットが存在するという誤った思い込みに基づく行為です。
私たちがYCに参加してすぐに、私たちの開発していた製品は全くうまくいかないことが確実となりました。(1) 生き残りたければ、当初の壮大な構想を捨て去り、何か別のものに挑戦する必要がありました。
v1ではなく、v0に向けて取り組む
私たちは効率性をより重視し、未熟な製品シリーズを相次いで発売しました。ユーザーの獲得に失敗したものを発売するたびに、私たちはさかのぼって考え、それに取り組み、やや異なるものを発売していました。ある製品を捨てるごとに、私たちはそこに費やした時間に対して猛省し、次回は費やす時間をもっと少なくしたものです。
私たちがMVPを立案するまでの時間は短縮し続け、3か月から1週間、1日、さらに数時間にまで減りました。結局、私たちに最大のトラクションをもたらしてくれたのは、1つのファイルと私たち宛てのメールアドレスを提供する単一のページという最低限のリリースでした。
私たちはこのリリースを「v0」と呼ぶようになりました。v0は何らかの製品のフルバージョンを開発するための第一歩であり、自分がやろうとしているものから見て、最低限でおおむね目的に適ったバージョンです。当然ながら、v0では目に見える要素が数多く失われます。いずれそれらの要素を作成するために必要な前提条件が開発するものに含まれている限り、それで構いません。
v0とは「私が作っているものはこれです。どう思いますか? 」と言えるだけの最低限の制作物です。
v0機能を出荷する
新製品では多くが未知数です。あなたはどの機能が重要となるのかわかりませんし、どのような設計や実装がうまくいくのかもわかりません。したがって、ちょうど早期の出荷がプロダクト・マーケット・フィットの獲得に欠かせないのと同じく、新機能の早期リリースもまたプロダクト・マーケット・フィットには欠かせません。
その機能がお話にならないほど基本的過ぎて、私たちがそれをリリースするや否や、その機能不足に誰もが不満を言うことも時々ありました。ですが、これは素晴らしいことでした。私たちは一切の労力を無駄にすることなく、顧客がその機能を欲しがっていると素早く知ることができたのです。
慎重な設計とオズの魔法使いテクニックにより、時間と技術資源というスタートアップとして最も貴重な資産の一部を温存しながら、最低限の機能しかないことを隠せることも多いものです。
このアプローチの主な欠点は、その製品の成熟性と洗練さが期待よりも薄く感じられてしまうことです。ですがv0機能をリリースすることで得られるフィードバック、データ、学びは、早期に招くかもしれない小さな悪評をはるかに上回ります。
ミニデモ
私たちは「社内ミニデモ」と名付けたものによって、このv0という概念をさらに一歩進めました。
私たちの会社では新機能に取り組んでいるときは誰であっても、そのお話にならないほど初期のバージョンを共有することになっています。私たちはオフィスの中央にあるプロジェクターでこれを行います。忙しくない人は誰もがその巨大スクリーンの前に座り、観察し、議論しています。
これは通常、新機能に取り組んでから1日以内にそのデモンストレーションを行うことを意味します。これは新しいインターフェースかもしれませんし、あいまいな技術的機能 (「私がこのボタン1つをクリックすると私たちのインフラ全てが自動的に復元します、凄くないですか? 」といったもの) という場合さえあり得ます。ミニデモはより大きな制作物の始まりだけを目指すものではありません。見せるべき新しい何かが生まれるたびに、何度も発生するものです。
このようなミニデモは数多くの理由から、驚くほど役に立ちます。ミニデモは――
- 人々が長大な道のりを進む前に正しい方向を指し示してくれます。ある人がプロジェクトの初めに少し本筋を離れることも容易になります。
- 私たちのチームの共通体験を一つに積み上げ、各機能の設計にさまざまな視点やニーズを織り込みます。
- 進捗を出すための燃料を定期的に補給してくれるうえ、全員が自分以外の人の取り組みを把握するのに役立ちます。
- 遠い場所や旅行中の人々をまとめ上げます。
- アイデアの紹介に関して、人々が不必要な業務を行うことを防ぎます (例えば、パワーポイント資料を作成する代わりに、数点を箇条書きにすることで済ませられます)。
- あるものを開始させ、使えるようにするための強制力を生み出します。
- 日々に成功と興奮の気持ちを与えてくれます。
ミニデモに関する議論は生産的であることが大切です。最も有用なコメントは具体的であり、データや過去の経験に根差したものです (例えば、「私たちがアイコンだけのインターフェースをリリースした前回は、多くの顧客がそのボタンの機能を知るために多くの助けを必要としました」や、「私たちのセールスチームはその画面一つに対して丸一日を費やしています。セールスチームの選択した設定を記憶させられないでしょうか? 」といったもの)。時間の浪費には気を付けましょう。話し合いがつまらない討論や批評といった深みにはまらないようにしてください。
ちょうど創業者が早期に出荷することに初めは悪戦苦闘するのと同じく、誰もが最初はミニデモの提出を厄介に感じます。感心させたいと思っている同僚たちに対し、みすぼらしくて中途半端な制作物を共有することは直感的に理解しづらいかもしれません。チームに加入したばかりの新入社員の場合は特にそうです。しかし、寛大な励ましと定期的な参加によって、ほとんど全員がこういった仕事のやり方を大いに好むようになることを私は発見しました。
それは技術の枠を超える
早く出荷することはエンジニア以外でも応用できます。ミニデモが技術的機能について成功したことを踏まえ、私たちは全てのチーム内でこの実践を採用しました。人々はプロジェクターに飛びつき、 新しいリード・クオリフィケーションのスプレッドシート、新しい顧客向けヘルプ記事、雇用の供給ルート、最新のZapier統合を共有しています。間違いなく、どのような種類の業務でもミニデモで好転する可能性がありますし、実際に好転します。
ミニデモのプロセス自体がドグマやルールに縛られてしまわないことを確実にするため、私たちはその柔軟性を保っています。ミニデモは特定のフォーマットを強いられません。私たちは極めて小さな変更を「マイクロデモ」と冗談で呼んでいますし、大規模な「マクロデモ」が現れる場合もあります。ミニデモはどんな時でも起こり得ます。よくあるのは、昼食中に人々が数分ずつ、次々とプロジェクターを使っていき、何かに関する午前中の進捗を共有することです。ある機能を出荷して稼働させる直前、私たちは最後に「何か気になる点」のミニデモを行います。重要なのはそれをあらゆる人にとって面白くて生産的なものにし続けることです。
あらゆるものを早期かつ頻繁に出荷することは私たちの会社における最高の慣習です。ミニデモのおかげで、私たちはより良いものをより速く制作しています。他の皆さんも私たちと同様、この実践の有益性に気付くことを願っています。
David Mack氏はSketchDeck (YC W14) の共同創業者およびCTOです。同社は企業がプロのデザイナーにプレゼンテーションを外注できるようにする形により、デザインのオンデマンド提供を行うサービスを手掛けています。 Mack氏はケンブリッジ大学でコンピュータ科学の学士号を、オックスフォード大学では数学およびコンピュータ科学の理修士号を取得しています。彼のその他の記事はこちらで読めます。
注(1) トラクションについて疑問を抱いている場合、3か月間に目立ったユーザーの増加がなければ、それこそが別のことに挑戦すべき時が来たと考えるに足る警告フラグです。↩
著者紹介 (本記事投稿時の情報)
記事情報
この記事は原著者の許可を得て翻訳・公開するものです。
原文: The Art of Shipping Early and Often (2016)
