スタートアップが掲げる事業計画において、惹きつけると期待する顧客の規模、支出の規模、その結果得られる売上と利益の規模などが財務予測として記載されます。
これらはあくまで理想であり、立ち上げ後のスタートアップが直面する現実とは大きく違うのが普通です。
その中でやるべきことは、次の2点です。
- 現状を的確に計測し、評価で明らかになった厳しい現実を直視する
- 事業計画に記された理想に現実の数字を近づける方法が学べる実験を考案する
会計の重要性
多様な部門を集中管理する際に不可欠なものとして、GMのスローンらが導入したのが管理会計です。部門ごとに目標を定め、その目標を達成できたかどうかで部門のトップマネジャーに対して責任を問えるようにしました。
しかし、一般的な管理会計は、スタートアップを評価することはできません。不確実性が高いため、精度のよい予測や目標が得られないからです。
スタートアップに特有の破壊的イノベーションに適した新しいタイプの会計手法が「革新会計」です。
革新会計では、まず、挑戦の要となる仮説から定量的な財務モデルを作ります。このモデルから、将来的に成功した時どのような事業となるかが推測できます。
メーカーであれば、成長速度を左右するポイントは、次の3つです。
- 顧客ごとの利益率
- 新規顧客の獲得コスト
- 既存顧客の購入リピート率
イーベイのような売り手と買い手をマッチングさせる事業の場合、「ネットワーク効果」が重要な役割を果たします。新たに流入する売り手・買い手の定着率からネットワーク効果の強さを計測することができます。
革新会計の機能 − 学びの中間目標
革新会計には3段階の働きがあります。
- MVPから現状のデータ（ベースライン）を得る
- 理想状態に向けてエンジンをチューニングする
- 方向転換するか辛抱するかを判断する
ベースラインを得る
まず、MVPが検証しようとする仮説に基づき、データを得るべき指標を設定します。例えば、コンバージョンレート、サインアップ率、試用率、顧客生涯価値といった指標があります。
MVPを用いたフィードバック・ループの中で、これらの指標を追いかけることによって、学びが進んでいるかどうかを確認できる指標でなければなりません。
これらの指標は、そのMVPが検証しようとする仮説に焦点を絞ったものですから、あくまで「学びの中間目標」に相当するものです。
設定した指標についてデータを取得し、ベースラインとすべき数値を決めます。つまり、チューニングの起点となる数値です。通常、ベースラインはかなり悲惨な数値のはずです。
エンジンのチューニング
次に、ベースラインの状態から理想状態に向けて、エンジンのチューニングを進めます。通常、少しずつ何回も調整します。
チューニングが進んでいるかどうかは、指標のデータがよくなっているかどうかで判断します。
理想状態に向かうために改善すべき製品要素が「エンジン」です。検証すべき仮説にしたがって決まります。例えば、「デザインが顧客を惹きつける要素である」いう仮説があるなら、デザインがエンジンです。製品に実装される特定の機能である場合もあります。
方向転換か辛抱かの判断
チューニングによる最適化が終わったとき、第3のステップに至ります。スタートアップの岐路であり、方向転換（ピボット）するか、辛抱するかの分かれ目です。
理想状態に向かって着々と進んでいるなら、適切に学んでいるということであり、そのまま続けます。そうでなければ、戦略に問題があり、変更すべきであることを認めなければなりません。
定量的成果が悲惨になった結果、失敗だと宣言せざるを得なくなり、それが定性的な研究を行うモチベーションやコンテキストを生みます。定性的な研究の方法は、通常、顧客の話を直接聞くことです。
この研究から検証すべき新アイデアや新仮説が生まれ、方向転換の道が開けます。方向転換すると、さらなる実験の機会が生まれ、3段階のサイクルが繰り返されます。
学習なき最適化の罠
様々な技術の専門家は、それぞれ製品を最適化する手法をもっています。例えば、マーケターであれば反応の違いを計測するスプリットテスト、エンジニアであれば製品の性能を高めるスキル、デザイナーであれば製品を使いやすくするスキルなどです。
ただし、このような方法がうまく行くのは、既存製品の改良など、市場が明確で、作るべき製品がはっきりしているような場合です。
不確実な状況で始めるスタートアップの場合、製品を改善するための手法が役に立つとは限りません。そもそも顧客が不明確で、作る製品自体が間違っていれば、最適化の成果は得られません。
このような場合、従来型のマネジメント手法しか知らないマネジャーは、えてして「エンジニアリングチームは努力が足りない」という評価をしがちです。
計画が間違っているのではなく、計画のとおりに製品が作られていないのだろうと考え、計画を更に精緻化しようとすることもあります。
既存の組織体制の中でスタートアップに取り組んでいると、フィードバック・ループを素早く回そうとするのではなく、通常の業務プロセスの中で機能部門ごとに仕事を進めてしまいます。
エンジニアリングチームが顧客を深く理解することなく、営業部門や上層部から思い思いの機能要望が山のように積まれることになりかねません。
機能要望の一つひとつが顧客にとってどのような意味があるのかを、エンジニアリングチームはまったく知ることもありません。要するに、学習することなく最適化をしようとしているのです。
虚栄の評価基準
従来型の評価基準としてよく利用されるものに、顧客の総数によって全体を評価する基準があります。例えば、登録したユーザーの総数、アプリ−ケーションのダウンロード回数、試用回数、リピート回数、有料契約した顧客の総数などです。
このような総数を、例えば月ごとに集計すると徐々に増加し、ホッケースティックを描いているように見えることがあるため、順調に動いていると錯覚することがあります。その意味で、事実を覆い隠す「虚栄の評価基準」と呼ばれます。
総数による評価では、数字の変化が、開発努力による成果なのか、他の条件が影響しているのか、などの因果関係が曖昧になってしまい、優先順位をつけるのが難しくなります。
短いスパンでフィードバック・ループを回していると、総数の動きは、直近のリリースに触れた顧客の影響なのか、その前のリリースに遅れて触れた顧客の影響なのかもよく分からない状態になります。
行動につながる評価基準
データを見て起こっている現象の意味を知ることができ、その現象が製品の変更によって生じていることを正しく推測できて初めて、正しく学び、次になすべき行動につなげていくことができます。
正しい行動につながる評価基準とは、変更の影響を直接に反映できるような評価基準であり、時間差やその他の影響などのノイズをなるべく受けないような評価基準です。
そのような評価基準として、コホートやスプリット・テストなどがあります。
また、重要な検証がおろそかにされることがないよう、優先順位が正しく守られる仕組みを作ることも必要です。
