新規事業の0→1で大切にしていること
新規事業の立ち上げ初期(0→1)のミッションは、次の1→10のフェーズに進む判断をするための期待感・希望の光を見つけることだと思っています。
期待感・希望の光はトラクションという形で現れるかもしれないし、もっと定性的なチーム内外の感覚の場合もあります。
いずれにせよ、チーム内外のステークホルダーが「このプロダクトの次のステージにBetしてよさそうだ」と判断できる状態を作ることが至上命題だと認識しています。
この状態が作れないと、このプロダクトに追加のリソースは投下されず、ゲームオーバーになってしまいます(例外として、チームが強く、今回のプロダクトで希望の光が見えずクローズしてしまったとしても、そのチームであれば別のプロダクトへのチャレンジが期待できることによる追加投資はあると思います)。
兎にも角にも「このプロダクトはいけるぞ」というモメンタムを作ることがプロダクトの存続を握るので、最も重要です。
モメンタムから生まれる社内の活力は「きっと次のチャレンジでも勝てる」という思いを生み、更なる大きな挑戦と成長を促してくれます。逆に、モメンタムを失ったら負のスパイラルに落ちていき、スタートアップは死んでしまいます。
スタートアップはモメンタムによって生き延びる
新規事業の0→1フェーズでは、毎日が仮説検証の繰り返しです。仮説を定義し、それのファクトを集め、想定されるインパクトを考え、優先度が高いものから検証していきます。
めちゃくちゃ真剣に仮説を考えるし、そのために様々な手法で根拠を集め、仮説が正しさやユーザー/事業へのインパクトを判断するわけですが、7-8割は外れます。真剣に考えたアイデアを検証したら、想定と違ったなんてことはザラです。
例えば、estieさんのPMFに関する記事でも、仮説やアイデアは簡単に外れるから、そこで一喜一憂しないように、絶対に揺るがない抽象度の高い未来への確信を持つことが重要だと説明されています。
「絶対に揺るがない抽象度の高い未来への確信」を持ち、それ以外の仮説は全部外してもいい、外野から何て言われても構わないくらいの気持ちの強さを持つようにしています。
(中略)
何故一定の抽象度を担保する必要があるかというと、具体の仮説やアイディアなんかは簡単に外れ、その具体に意識を載せすぎると外した時に船頭がブレ、チームがブレるからです。
事業を進めていくと、想定と異なることは無数に発生しますが、それを一々「失敗」などと表現しているとブレッブレになります。なので3年後の姿に抽象度の高さを担保しておけば、具体のアイディアなんかは外したとしても、「3年後の信念に一歩近づいたぜ」と前向きに捉えることができます。
つまり、新規事業においてまず0→1を成功させるためには、次のフェーズに進めるというモメンタムの形成が最重要だが、そのモメンタムを形成するための仮説検証の打率は3割あって良い方、ということです。
しかもその3割の内訳はポテンヒットでなんとか1歩進んだということもあれば、一気にスリーベースみたいなこともあるので、仮説検証による進み具合はバラバラです。
かつ、当たり前ですが新規事業やスタートアップには予算が決まっています。スタートアップであれば、調達した資金が尽きるまでに社内・投資家を巻き込んだモメンタムを作り、次の調達に繋げないといけません。社内での新規事業においても、与えられた予算内でまず次のフェーズへの活路を見出さない限り、プロジェクトへの追加予算が与えられることはありません。
限られた予算内で、打率2-3割の仮説検証を繰り返し、1つずつ成功を重ねて社内外へのモメンタムを形成し、全員が次のフェーズへ「I'm in」と言える状態を作ることが0→1でやらないといけないことです。
0→1はこれに尽きるので、それ以外のことは優先度を下げる必要があります。
完璧な品質を担保することより、行けるぞという自信を作ることが大切
Webサービスの開発において品質にどこまでこだわるのかという問題があります。
QCD(品質とコスト、デリバリー)はトレードオフの関係にあります。
0→1フェーズにおいては、仮説検証ができる最低限のクオリティで、低いコストで早いデリバリーが必要です。
この考えは、施策の企画から要件定義、基本設計、UIデザイン、システム開発、プロダクト開発のほぼ全てのプロセスにおいて同じです。
仮説検証ができて、このプロダクトは伸びそうだ、ユーザーに価値が届けられそうだという成功体験さえチームで得ることができれば、品質は最低限で良いと個人的に思っています。
なぜかというと、そもそも仮説検証の打率が2-3割だとして、それを検証するためのプロダクトの品質を70%から100%にしても、2-3割の打率は5割にはならないと思っているからです。
また、品質を70%から100%にすることは0%から70%にするよりもコストがかかることも多く、その観点からも品質にこだわりすぎることは避け、本来の目的である仮説検証をスピーディに行うことを優先した方がよいと思っています。
プロフェッショナルな意識をもっている人だからこそ、目の前の自分のアウトプットのクオリティを高めたくなるはずです。逆に言えば、そのような向上心・素質がプロフェッショナルに繋がっているのだとも言えるのだと思います。
「もっと良いコードにできないか」「もっと素晴らしいアーキテクチャを考えられないか」「もっと精度の高いモデルやロジックを作れないか」「もっといいUI設計はできないか」「抜け漏れのない完璧な要件定義が作れないか」「もっと細かく分析して、精度の高い仮説が立てられないか」など。
ただ、0→1においては制約条件があります。仮に予算や期限がない場合だったら、時間もコストも考えず、品質にこだわり抜いていいと思います。
UIデザインであれば、1pxへのこだわりに何時間かけても、ボタンの問題1つにチームを巻き込んでアイデア出しをしても問題ないです。
ソフトウェア開発であれば、保守性の高いシステムを作るための設計やリファクタにじっくり向き合って時間をかけたり、テストコードのカバレッジを上げるために丁寧な設計をすることに問題ありません。
残念ながら新規事業やスタートアップの0→1にはその余裕はありません。予算(期間)は限られているので、イテレーションが短いほど、数多くの仮説検証ができます。
こだわり抜いたデザインやソフトウェア設計が完成したとしても、仮説検証の結果、機能や施策自体の見直しが入り、rollbackされることも多いです。
"Done is better than perfect"というフレーズがありますが、私は上記のようなコンテキストでこのフレーズを自己解釈しています。
多少粗い部分があっても全然いいし、担当した当人はもっとこだわってやりたいという想いがあるのも重々承知なんだけど、検証したい部分を満たす最小限の粒度でまず試してみよう(≒MVP)、という感じです。
0→1に向いている人(向いていない人)ってどんな人ですか？という質問をいただくことがありますが、上のスタンスが受け入れられるかどうかが1つ目安としてわかりやすいかもしれません。
仮説検証のために優先度を落とした品質は、どこかでカバーする時間を設ける
とはいえ、デリバリーのスピードを優先したことで担保されなかった品質を放置していると、回り回ってデリバリーのスピードが落ちてくることになります。いわゆる負債です。
負債は運用コストの肥大やメンバーのデモチベーションを引き起こします。
UIデザインでもソフトウェア開発でも言えることですが、スピードを優先したばかりに整理がされていない状態になると、負債によって次のアクションのコストが肥大していきます。
例えば、デザインで言うと、Figmaのデザインが散らかっていて、どこになにがあるかわからなくなってきたり、コンポーネント化されていないので変更に弱く、修正する時に時間を要してしまったり。
開発の面では、その場しのぎで書いたコードのせいで、見通しが悪く、エンジニアの開発スピードも落ちるし、バグを生む可能性も高くなって結果的にQAコストが上がる、とかですね。
つまり仕事をする上で「やりづらい」と感じるシーンが増えるので、仕事をする人のデモチベーションに繋がりやすいです。
いくら0→1だとはいえど、そこまであっさり割り切って仕事ができるわけではありませんし、後から入ってきたチームメンバーも嬉しい状態ではないはずです。
なので、ステップを分け、各メンバーと認識を揃えておくことが大切なのかなと思います。
例えば、以下のようなケースを想定します。
検証したいIssueがあり、それを検証するための機能をデザイン・開発したとします。検証した結果、その機能はプロダクトにとって非常に価値が高く、プロダクトに残ることになりました。ただ、この機能はスピードを優先したため、デザインもソフトウェアも品質は70点です。このまま放置するとそれぞれ負債が残り、次のデザイン・開発の足を引っ張ることになります。
さて、この負債解消はどこでやるべきでしょうか？
この問いは非常に難しいと私は感じていて、プロダクトやチームの状態によってベストなタイミングが違いすぎるので、先に述べた通りまずはチームで認識を揃えておくということが最低限必要なのかな、と思います。
例えば、「次の資金調達が見えてきたタイミングで負債を解消する期間を取ろう。資金調達をする=チームメンバーも増えるので、ぐちゃぐちゃな状態だと次のスタートダッシュが遅くなるから。」のようにチームで合意が取れていればいいと思います。
言うは易く行うは難し
いつまでスピードを優先し、いつまで負債を我慢するのかという判断は、非常に難しいと思っています。教科書的にプロダクトマネジメントやスタートアップの正攻法が語られていたとしても、実際やってみるとそんなにうまくいかねえよって感じることもしばしばあります(笑)
もしエンジニアの1人が品質をとても重視したい考えを持っていた場合、チームメンバーとしてその考えは尊重しないといけないですし、とはいえアジリティ高く、短いサイクルで検証を進めていき、プロダクトの成長にチーム全体で向かわないといけません。
チームによって人も事業も状況も全く違うので、それに合わせてうまくやっていくことはとにかく難しいわけですが、意識している/していないでは全然違うので、少なくともそういった意識で取り組もうと心がけています。
次のフェーズでも勝負ができる自信を得る
長くなりましたが、改めて整理すると、0→1のフェーズにおいては「このプロダクトはいけるんだ」という自信をチーム全体が持つことがミッションであり、そのためにはユーザーに価値を届けるためのトライをできる限り多くやっていくんだというスタンスを個人的には大切にしています。
現時点において、プロダクトの成功確率を最も上げるための選択肢はどれなんだ？という問いを常に考えて意思決定していくことが重要なのかなあと考えています。
色々模索中ですが、このような考え方で今0→1のプロダクトを立ち上げていて、色んなチャレンジをしています。一緒に新規事業やりたいと思っていただける方はぜひご連絡ください。
この記事が気に入ったらサポートをしてみませんか？