技術と魚

技術調査、開発Tips、及びしょうもない文章

スタートアップで注意したいミニマム病について

f:id:norainu234:20180703085433p:plain

初期のスタートアップはリソースが少ないのが常です。リソースの源泉はキャッシュであり、かつ現代のスケールを目指すスタートアップのほとんどがサブスクリプションがベースのビジネスモデルであるので、最初に赤字を掘ることは避けて通ることが出来ません。

このために、スタートアップではある種の病が蔓延してしまいます。それは「無駄」に対する恐怖です。

キャッシュが枯渇すれば、給料や家賃が支払えずに会社が潰れることは、会社にいるどんなメンバーにも察しが付きます。メンバーがB/Sや資本政策について深い理解なんか無くても、容易に考えつくものです。場合によってはメンバーは経営者以上に不安を感じるのではないでしょうか?

そんな状況においては、会社のメンバーにとって「無駄なことをする」=「会社を殺す」ことになるはずです。気の狂ったリスクテイカーでなければ、そんなことは少なくとも会社にとって良くないことであり、したがってなるべく無駄を避けたほうが良いと考えます。自分のせいで会社が倒れたら、責任は計り知れないものですし、キャリアもあるわけですから当然避けたいところです。自分も月に一度はそう頭を巡らせます。

このことだけ見ると、適度な不安感があればメンバーが上手く無駄を避けてリソースを最適活用してくれそうに見えます。ところが、経営側に立ってみて、必ずしもそうではないと感じるパターンがあることに気づきました。

自分がある大きい意思決定をするとき、自分自身にも不安要素というのは内在していて、コントロールしているつもりでも、100%平静を保てるほどではありません。特に、新機能の仕様については不安要素が強く出るときほど、「もっと小さくできるのでは」という発想に固執していることに気づきました。簡単のため、これをミニマム病と呼ぶことにします。

会社にとっての「無駄」かどうかを"推定"するための手法は様々あります。顧客にインタビューしたり、機能を小さく出してみたりするやり方です。このような方法は手軽に始められて、かつ顧客の情報を得ることができるので、まさにリソースの少ない会社にはうってつけです。

ところがある重要な事実を見失うと、間違った判断に繋がります。それは、「無駄は確率的である」ということです。確率的という解釈がいかに重要であるかは、次の2つのケースで数学的に説明が付くことから分かります。

一つは過学習のケースです。もしリリースしたある機能が、最初の3顧客に刺さらなかったら、どうも4人目にも刺さらなそうな気がします。しかし、市場の40%に求められている機能であれば、それにはそれなりの価値がありますが、残りの60%の求めていない顧客を3連続で引く確率はサイコロで1が出る確率よりも大きいです(=約20%)。にもかかわらず、ここで意思決定すれば40%もの顧客にとって価値のある機能はその後日の目を見なくなる可能性が高まります。

もう一つは、"条件的"であるケースです。あるとても有用な機能をリリース済みあって、しかし顧客が全く触れてもいなかったとき、それで機能のニーズがなかったと判断するべきではありません。もし、機能的な問題ではなく、簡単な動線の気づきが影響するのだとしたら、動線を変えるだけで場合によっては多くの人に使われるかもしれないのです。機能のニーズが80%あっても、動線に気づく確率が20%であれば、利用率は16%になってしまいます。動線だけではなく、ある種の大きな機能でさえその利用率は従属確率的である場合もあります。2つの主要機能の片方だけをリリースしてしまったけど、顧客がそれを導入するには最低限両方ないと難しい、というケースにおいては、その2つを作りきるまでそれが無駄かどうか分からないということです。

この両ケースが起きている場合には、実はミニマム病になった人がやろうとする、無駄を減らし、リソースの節約をする行為とは真逆のことを本来やらなければならないのです。すなわち、これらの検証のためには、実は長い時間と改善の工数が必要であり、実は「もっとリソースを使う」のが正解なのです。

こうしたケースは、よく言われる"突き抜ける"という表現の期待が内包する性質に近いのかもしれません。例えば、Dropboxにとって、ドラッグアンドドロップはもしかしたらMVPでは不要な機能だったかもしれません。顧客にインタビューして、「いや、別にファイルアップローダ使えばいいじゃん」と3回言われた場合を想像してみてください。それで、うっかりファイルアップロード&ダウンロードができるだけのMVPを作っていたら、そんなものは無数にあるサービスと何ら変わらず、結果"条件的"確率で判断を見誤ることになり得ます。

自分が誤ってミニマム病になっていないか確認するには、「キャッシュやリソースが無限にあると仮定したら、どうしたいのか?」を考えるのが有効であることが分かってきました。こうすることで、無意識のうちにリソース制限を自分が加味してしまっているかどうかに気づくことが出来ます。もちろん無限に遊び続けるというのはナシですけどね。

スタートアップのメンバーとしては、時間やリソースが多くあったらもっと出来るはずのことがあれば、それを上司に提案するのも良いかもしれません。逆に経営者の方は、無駄の排除を正当化しすぎて中途半端にならないように、柔軟な決定を許容するスタンスをとるのが良いと考えられます。例えば、そのためなら"期限"は遅らせることができる、という態度でいることは一つの柔軟さになるでしょう。