スタートアップとして成功するために。

2019年2月22日 10:09

スタートアップを始めるにあたり、最初期のごく小規模の状態で意識することにフォーカスして、全体を俯瞰できるように整理しました。スクラムや仮説検証など、それぞれ深掘りすることもできますが、まずは全体を知ることを優先しています。詳細が気になる方はコメントしてください。

共有されているべき大前提

スタートアップは限られた資本で最大の価値を提供する組織

スタートアップを一言で表現すると、“新しいビジネスモデルを開発し、ごく短時間のうちに急激な成長とエクジットを狙う事で一獲千金を狙う人々の一時的な集合体”である。これは、市場においてある程度受け入れられると確信が得られたビジネスモデルを適用して事業展開を行う事で、日々の安定した収益と長期成長を目指すスモールビジネス的ベンチャー企業と比べても大きな違いがある。

https://blog.btrax.com/jp/startup-2/

LinkedInの創業者リード・ホフマンの名言の1つに、「スタートアップとは、崖の上からから飛び降りながら、飛行機をつくるようなものだ」という言葉がある。

https://hiromaeda.com/2014/05/06/cliff/

スタートアップは、お金も人も時間も限られた中で、指数関数的に、想定しうる最大の成果を生み出すことに注力する組織です。急激な成長とexitを狙うために、"やるべきこと"と"やらないこと"を決めて、極端な成長を目指を目指します。無駄なことをやる時間はなく、チームで一丸となって取り組む必要があります。
一方で、お金も人も時間も余裕があるなら、攻め方は変わってきます。極端な話、開発は完全に外注してもいいでしょう。ただし、費用は膨らむ、改善のサイクルは別見積もりでスピード感も出づらい、開発に関する貴重なノウハウが外にある状態など、弊害も生まれます。そういった弊害をコントロールできるような、外注先との適切なコミュニケーションができる人材が社内にいる必要もあるでしょう。なお、このパターンについてはスタートアップではなくなるので以降特に扱いません。

「プロトタイプ」と「プロダクト」は別物

仮説を検証するための「プロトタイプ」と、顧客に提供する「プロダクト」は全く異なります。
試しに作ってみると言った場合、その対象がプロトタイプであれば、それはあとでプロダクトとして作り直す前提です。おそらくですが、なにか仮説を検証するための物なので、その実験が終われば役目は終了するはずです。一方、最初からプロダクトを作るのであれば、それは作り直す前提ではなくなります。つまり未来永劫使われ続けることを前提に、様々なことに気を配りつつ作ることになります。小さな機能、ちょっとした改善一つとっても、それを実現するために様々な思考実験と設計と検証が行われています。時間がかかる上に、容易に破棄していいものではないでしょうし、破棄には苦痛を伴う場合も多々あります。

“あったらいい”機能と”あるべき”機能の違い

無駄なものは作れない。では“あったらいいかも”と”あるべき”ものとは？その境界は難しいですが、重要な点は2つです。

・その機能が提供する価値について、検証を行った後か
・機能のリリースによって、どんな数字が改善される見込みなのか

この2点の有無は大きな違いです。納得感を持って実装したとして、数字として結果が出ているかは別なので、そこまで見る必要があります。価値の検証が後回しだったとしても、その機能により改善したい数字の目標がない状態で、機能を作るべきではありません。多くの場合無駄な機能を生むだけです。そのコードが負債になることも往々にしてあります。余計なリファクタリング作業が生まれるかもしれません。

最も有限なのは”時間”、特に貴重なのが開発リソース

小規模なうちは、全員が (質の差はあれど) あらゆる役割を横断的にできる方が効率的です。誰かが体調を崩していなくなると、スピードはどうしても落ちますが、それでもチームで支えられる状態、問題が発生したら誰もが柔軟に対応しようとする状態。そういった状態は理想的ですし、それを作ろう維持しようとする意識を、最初から持つことが心理的安全性のある組織であることにも繋がります。
また、その体制の中でも開発リソースは特に貴重です。開発の時間を最大限に確保すること、無駄な開発を減らすことが、結果的にプロダクトの開発スピードを最も高速にするという共通認識を持つことが大切です。エンジニアが無駄なく、高速に、開発するべきものを開発できるように、チーム全体で取り組むことが、最もスピードを生みます。その上で、リーンスタートアップは、無駄なものを作らないために時間を使う手法です。仮説の検証もドキュメンテーションも一見回り道に見えますが、無駄なものを作ってしまうことに比べれば大したことではありません。
ファイナンス、採用、広報など、会社としての体裁や社会的信用 (多くの場合は思い込みですが) を考えていろんなことに手を出したくなりますが、全てはプロダクトあってこその話です。優先順位を間違えないようにしましょう。つまり、スタートアップの最初期では、全員がプロダクトに向き合う必要があります。それ以外にやることは何もありません。「自分はコードが書けないから…」と思っても心配はいりません。何を実装するべきか、そのプロダクトでどんな価値を提供するべきか。本当に提供するべき価値を考え、仮説を立て、それを検証する作業にはプログラミングは不要です。むしろプログラミングが必要な検証は、検証方法自体が間違えている可能性を疑いましょう。その上で、自分の手札で作ることができるMVPを考え、仮説の検証を全員でやっていきましょう。

以上の前提が共有された、全員で一丸となってプロダクトに向き合える組織こそがスタートアップであると言えます。同時に、スタートアップが容易でないことは想像できるかと思います。その、難しい挑戦を一緒にやりたいと思える人物とはどんな人物でしょうか。ここで一般的な尺度を考える前に、「自分たちにとって必要な役割とは？」と言うシンプルな問いに答えられるようになりましょう。それがそのまま、必要な人を口説くメッセージになります。
人に関して。特に重要なのは一人目のエンジニアです。周りに知り合いがいない？いいエンジニアがいない？話しても共感してもらえない？それは説明が悪いか、もしくはプロダクトやビジョンに魅力がないからではないでしょうか。そうでない場合、単なる努力不足です。世の中には大勢のエンジニアがいます。自分が一緒に働きたいと思うエンジニアを見つけ、口説くことは、プロダクトを作る以前の、越えるべき最初の壁でしょう。

開発の体制

スクラムをやりましょう。
不確実性が高い中での開発になるので、仮説の検証と実装は並行して進むこともあります。柔軟に動ける、フットワークの軽い開発組織を作ることが大事です。細かい作法はありますが、なによりやってみることが大切です。以下に簡単なやり方と注意点を書いておきます。

役割を明確にしましょう。
プロダクトオーナーは誰か、スクラムマスターは誰か。プロダクトオーナーは多くの場合社長になるかと思います。スクラムマスターは特定の人でもいいし、持ち回りでもいいかもしれません。自社プロダクトの開発なので、スクラムマスターの実際の役割は会議のファシリテーション程度です。

イテレーション期間は2週間。
水曜日を開始日、火曜日を最終日としましょう。これは変更してもいいですが、週末を区切りにすると週後半が大変になっていく傾向があります。

会議体は3種類あります。

スタンドアップミーティング (15分)
「昨日やったこと」「今日やること」「困っていること」の3点を手短に共有。共有された内容のうち、ちゃんと話した方がいい話題はあとで話す。

スプリントレトロスペクティブ (1時間)
火曜日の午後に実施。KPTを行う。

スプリント計画ミーティング (3時間)
スプリントレトロスペクティブのあとに実施。次のイテレーションで取り組むべきIssueをリストアップし、それぞれについて作業量を見積もる。二部構成。

第一部:
開発の詳細な見積もりは一旦無視して、優先度高く取り組みたいものたちを並べる。
参加者) プロダクトオーナー、スクラムマスター、その他のメンバー。

第二部:
第一部で選んだIssueについて、ひとつづつ作業量を見積もる。このとき、どうしても溢れるものが出てくることが多いので、その場合はプロダクトオーナーも交えて検討する。
参加者) スクラムマスター、その他のメンバー。最後にプロダクトオーナーを交えて確認。

タスクの管理は、特にこだわりがなければGitHubのIssueとPorjectで十分です。必要以上に複雑なことをやろうとしないことが大切です。スクラムはもともと、ホワイトボードとポストイットでも十分運用できるはずの仕組みです。ただしエクセルやスプレッドシートは辞めましょう。ウォーターフォール的になりがちです。また、場所は1つに集約し、分散させるべきではありません。
Inbox、Icebox、Backlog、InProgress、Doneの5カラムを作りましょう。

- Inbox: 優先順位を決めていない、新しいIssueをとりあえず入れる
- Icebox: 2週間以内にやる予定のないIssueを入れる
- Backlog: 直近のイテレーションで消化予定のIssueを入れる
- InProgress: 現在進行中のIssueを入れる
- Done: 完了したIssueを入れる

IssueとPull Requestには、テンプレートを用意しましょう。項目はシンプルで構いません。ただ、事前に共有すると話がスムーズになる項目については、極力埋めるようにみんなで努力しましょう。

ISSUE_TEMPLATE.md
Issueのタイトルは「(ユーザーは)XXXができる」という、ストーリー形式、ユーザーはそのissueが実装されることによって何ができるようになるのかを記述します。

## What


### Goals


### Non-Goals


## Why


## Ref


## Todo

PULL_REQUEST_TEMPLATE.md

## What


## How


## Why


## Refs

仮説と検証

リーンスタートアップ！仮説検証！と言われても、実際のところ何をどうすればいいかはわかりにくいですよね。基本的なステップは以下の6段階です。

1. どんな価値をユーザーに提供するべきか、という仮説を作る
2. 1で立てた仮説の価値を、可能な限り短期間・低コストで検証するための方法を考える
3. 2で考えた方法で実際に検証してみる
4. 3で得た結果と、考察をまとめる
5. 実際にプロダクトへ反映するべきかを決める
6. 具体的な機能要件を固める

ポイントは、最初に仮説を立てる際、価値についての仮説は立てますが具体的な機能についてはそこまで掘り下げません。そして実際に実装するのは最後の手段で、多くの場合実装するよりも簡単な手段で検証できます。つまり、エンジニアでなくとも仮説の検証はできます。
価値があることが検証できた段階で、ようやく機能として実装してもいい段階がやってきます。
ただ、実装した後にも重要な作業は残っています。

1. 機能の要件を固めて、Issueに追記する
2. リリース後、その機能によって改善されるであろう数字の指標と、目標数値を設定してIssueに追記する
3. スプリント計画ミーティングで、実際の作業を細かく見積もる
4. 実装する
5. リリースする
6. リリース後、2で設定した目標を達成しているか計測する
7. 6の結果次第で、rollbackするかそのまま残すかを決める

価値が検証できても、その結果として実装されたソリューションである機能が正しいかどうかは別の問題です。その機能は価値を正しく体現できているか、確認し、できていなければ作り直す必要があります。

早めに課金して、楽をするべきサービスたち

基本的な足回り、使うべきツールや手法などは (多少選択肢はあっても) 大きく違いはありません。ただ、ないと極端に無駄が生まれます。そういったジャンルのツールを導入していて、かつちゃんとチームで運用できるようにしていくことは、スピードを維持する上でも重要です。
各会社であまり考える必要がない、ここは最低限入れておくおくべきという基本的なカテゴリのサービスへの投資は、時間の節約になり、開発リソースを確保することにも繋がります。

基本 (使わない方が珍しい)

管理・バックオフィス系

パスワード
後からやると大変なので、最初から導入して利用を徹底したほうがいいでしょう。

契約書
紙の契約書は管理コストが増えていくので極力クラウドサインに。

労務
細かいことはツールにお任せ、SmartHR対応の労務士さんと契約するとお互いが楽です。

会計

チャット
hangouts chatでもいいかもしれないですが、他社とのshared channelを作ることで、相互に情報共有しやすい環境が作れます。やり取りはslackに集約していきましょう。

ドキュメント管理
とても重要です。急いでいるとどうしても後回しにしがちですが、簡単でもいいので習慣を作っておくことは、将来自分たちを助けてくれるでしょう。
自由度高く、自分たちが使いやすい状態を自分で作りたい、メンテナンスをするのが好きだったり余裕がある場合にはNotionを、少しクセはあるけどレールを敷いてくれていてそれに乗っかって簡単にドキュメント共有をしたい場合はBasecampをオススメしています。

ドキュメントとして記録する情報の例

議事録
定例、スポット、外部との打ち合わせ、など口頭で決まったことも全て簡単でもいいのでメモとして書き残す。

プロダクトの仕様書
フォーマットはプロダクトごとに異なる。Issueに書くことが多い場合はそちらでも可。
繰り返し参照するような情報、例えばAPIの仕様などは整理しておく。

仮説検証の計画や成果
どんな仮説を立てたか、MVPは、検証目標数値は、結果は、学んだことは、次のアクションは、などを記録する。

サービスの障害報告レポート
何が発生したか、いつからいつまで、原因は、どんな対応をした、再発防止策は。
複数人で一緒に書く。一人で書くと大変だし辛い。

日報
作業記録というより、困っていることや所感などを重視。問題の早期発見と、メンバー同士を知ることによるチームビルディングが目的。

その他

外部とのスケジューリングツール
内部はGoogleカレンダー十分ですが、対外的な予定調整ではそれだけだと不便です。

リモート会議があるなら課金しておきたい
Slackのvideo callやgoogle hangoutでもいいですが、zoomは低速回線でも安定していて、録画ができるのでミーティングに参加できなかったメンバーへ録画をそのまま共有できて便利です。

カスタマーサポート
小規模のうちからシステム化しておくと、将来的に引き継ぎが楽になります。

最後に

ここまで読んでいただいた方にはわかると思いますが、この内容は非常に偏った主張であり、反論の余地が多々あるかと思います。ただ、単に否定されるだけでは辛くなるので、この内容を基準として、

「私の考える、より良い取り組み方」
「ハードウェアやR&D要素の強いスタートアップでは？」

などなど、より現場で参考になる情報が量産されることを願っています。

追記:
この記事を誰が書いたのかは、重要なことではありません。わかりますね？

この記事が気に入ったらサポートをしてみませんか？