成功していたスタートアップが失速する理由。あるいは経営者が何を作るべきかを見失うまで。

前提

今回話す内容はWebスタートアップが上場したあたりでどうして失速するのか？みたいな話をしていきたいと思います。
前提として内製開発をしていてテックドリブンなWebスタートアップです。
上場して時価総額数百億だか数千億だかまではいける、というストーリーで行きます。
それ以前に失速した場合の話はしません。

話の構成

• 最初はP/M-Fitしてイケイケだった組織が、気が付いたら失速している
• なぜそうなるのか？(考察)
• どうすればそれを避けられるのか？(仮説)

という話の構成でいきたいと思います。

アジャイルにおけるプロダクト開発

Henrik Knibergが書いた図ですね。
親の顔より見たことのある人も多いかと思います。
自動車を開発するときに、パーツではなくまずは動くものから作りましょうね、という話をしています。

この図の流れで、途中で「オッ、P/M-fitできるぞ！」と確信できるのは3と4の間くらいじゃないでしょうか。
自転車にエンジンつけたような代物を作って人を乗せて公道走らせて、その反応を見たときくらいですね。

このあと4のバイクを出してみて、問い合わせで電話が鳴り止まなくなり、問合せフォームはいっぱいになり、「もっと人や荷物を乗せたい」という要望がアホほど来るわけですね。

5.の段階でスポーツカーが完成するわけです。
おそらくこの辺りで上場して時価総額数百億円。
社長は何度もメディア取材を受けてはドヤ顔でろくろを回すわけでしょう。

ここまでの流れを「不確定性」と「時間経過」の２軸でグラフにすると

最初はまだ何を作るべきか見えず、手探りで進んでいるフェーズです。
スケボーを作って、ハンドルをつけてみて、いやタイヤの数をもっと増やすべきか？
スピードを出すと安定しないな……。タイヤを大きくしてみるか……。
みたいなことをしている感じです。
不確定性は高く、「探索性の高い開発スタイル」が求められます。

前述の通り、P/M-fitする前後で急速に「自分達は何をするべきか？」への解像度が上がっていきます。
すると一気に不確定性が下がります。

P/M-Fitが完了したと判断できて、事業はイケイケになり順調な成長が続きます。
ついにARRは1億円を超えました。次に目指すはT3D2です！
（※ 3期連続でARRを3倍(TRIPLE)に, さらに2期連続でARRを2倍(DOUBLE)にするからT3D2）

「何が必要とされているのか？」が明確になり、「何を作るべきか？」も同時に明確になるため開発マネジメントの難易度は一気に下がります。
悩むべきは「何から先に作るべきか？」の優先度付だけだからです。
また「かくかくのこの機能を作れ」と開発組織に命令した場合、命令された側も「その機能がどういう使われかたをするか？」が明確にイメージできるため、細かいことを指示しなくてもおおよそイメージ通りの代物が仕上がってきます。
ARRが急速に伸びるのと同時に、開発コストや開発マネジメントの難易度の低さ、最終的なユーザー品質の高さという面においても開発組織の黄金期と言えるでしょう。

ここで多くの開発組織に起きること。あるいは「起こってしまうこと」

最初の段階まではスクラム開発あるいはアジャイル開発で進んでいく組織も多いです。
スクラムほど厳密なやり方でなくても、アジャイル的なアプローチで進む開発組織も「この段階までは」多く存在します。
この段階まではクネビンフレームワークで言う複雑系のプロジェクトが開発チームのタスクの大半を占めます。

ところがP/M-Fitしたあたりで大きな転機が訪れます。

「すでに作るべきものが明確になっているモノ」をいかに高速で製造するか？に重点が置かれ始めます。
つまりこの段階まではクネビンフレームワークで言う煩雑系のプロジェクトが開発チームのタスクの主流に取って代わります。

そうなると多くの企業において開発組織の大改革が行われます。

• 開発チームを細切れかつ小分けにする
• 開発を指示される内容が機能ベースになり、また締切ドリブンになる
• 開発組織が効率を求めて分業化されていく

分業が推進され、職種ごと、プロダクトごとに小さい塊で急速なサイロ化も進みます。
ところがここまではある程度の不満こそあれど問題は出てきません。
なぜならこの段階までは 「作るべきものが明確」 であり 「細かく指示されずとも、ユーザーがどう使うかが想像しやすい」 からです。
「何が必要とされているのか？」が明確なため、プロダクトの未来像や「あるべき姿」への解像度が高く問題は発生しません。

つまり開発組織に何が起きてしまうのか

組織が大規模化するとともに、分業化、サイロ化、そして締切駆動かつ機能フォーカスの開発が進行します。
同時にかつてあった「一丸となって密な開発」「ユーザー体験ベース」「探索性への強い適性」は失われていきます。
トップ層による開発計画のポートフォリオが組まれ、それを締切ベースで分解して開発スケジュールが組まれるためトップダウン色が強くなります。

ただし ここまでは問題がありません。
不確定性が低く、また市場から「何が必要とされているのか？」が明確だからです。

だがいずれ、夏は終わる

すべてのプロダクトには「成熟期」というフェーズがあります。

あなたに質問です。
iPhoneやmacbookにこれ以上付け加えるべきハード寄りの機能を思いつきますか？
ニコニコ動画に付与すべき機能を思いつきますか？
あるいは自動車に「あれば必ず他とは段違いの競争優位性になる！」という機能を思いつきますか？

そうそう思いつきませんよね？

P/M-Fitが完了したと判断できて、事業はイケイケになり順調な成長が続きます。
ついにARRは1億円を超えました。次に目指すはT3D2です！
「何が必要とされているのか？」が明確になり、「何を作るべきか？」も同時に明確になるため開発マネジメントの難易度は一気に下がります。

以前にこう書きました。
では以前にはっきりした「何が必要とされているのか？」の部分。当時はプロダクトに足りなかったけど、未だ存在しなかった機能。
これを作るとある程度までは一つ作るとさらにいくつかの「作るべき機能」が見えてきます。
ところがそれをほぼすべて作ったのに、「これを作ればユーザーにウケる。売り上げも伸びる！」と思える機能が見えなくなってからが「本番」が始まります。

ここまでで市場を取り切っていればいいのですが、競合がいる場合状況は悪くなります。

「とにかく売上を伸ばせ。主要KPIも伸ばせ」

上述の通りすでにこのスタートアップは上場しています。
当然大口株主や機関投資家は売上や主要KPIを伸ばし続けるよう要求してきます。
ところが「これを作ればユーザーにウケる。売り上げも伸びる！」と思える機能はすでに尽きつつあります。
TODOリストの底が見えてきたわけです。

ある機能を作ってもKPIが伸びるかどうか微妙。そういう機能を作っている余裕はありません。
開発力には限りがあるからです。

どうにかして売上や主要KPIを伸ばし続けられる施策でTODOリストを埋めなければいけません。

？？？「私にいい考えがある」

このときに明確な答えを持っている組織があります。
営業組織です。

彼らには膨大な商談の失注リストと失注理由の情報を持っています。
それをもとに彼らはこう言います。
「星取表で○を増やせば、大口先での商談でも勝てます」

事実として星取表で○が増えれば１件受注するだけで大きくKPIを伸ばせる大口契約を獲得しやすくなります。

すでに北極星を見失い始めたプロダクトマネージャーにとってこの発言は福音です。
こうしてそこが見え始めたTODOリストは星取表で○を増やすための開発プロジェクトで再び埋まり始めます。

開発プロジェクトが完了するたび機能が増え、機能が増えるたび星取表で○が増えます。
コンペでも負けることが少なくなり、売上も主要KPIも伸びていきます。

組織はコンペ志向となっていく

もうこうなると、会社組織はプロダクト志向というよりコンペ志向というほうが正しくなります。

商談のパイプラインは星取表で○が増える前提で組まれます。
もし開発プロジェクトが遅れれば機会ロスや機能提供の遅れによるディスカウントが必要になります。

このため営業サイドのパワーが強くなり、開発組織は進捗遅れを避けるために進捗に特化した「社内受託型組織」へと最適化されていきます。

また金で時間を買うと称して金で星取表の○を買う取り組みも進みます。
M&Aの加速です。

消耗戦へようこそ

ここまでで市場を取り切っていればいいのですが、競合がいる場合悲惨です。
たとえどれだけコンペ志向になろうと、「市場が求める機能」は平均するとだいたい同じような形になります。
すると競合企業同士で「(市場に求められる)同じような機能」を開発しあいながら終わりのない消耗戦をすることになります。

つまり相手をシェアや売上で突き放すこともできず、同じものを作る終わりのない消耗戦をすることになります。

そして衰退局面へ

市場は無限には広がらない

消耗戦を続けても、売上や主要KPIが伸びていればそれで十分です。
ところが永遠に伸び続けはしません。

どこかで市場への掘削は「硬い岩盤」にぶちあたります。

人間は本来変化が嫌いな生き物です。
渋谷にいるイケイケスタートアップでは到底考えられないような保守的で伝統志向の人間はどこにでもいます。

システムを変えれば業務フローも変わります。
弥生会計や勘定奉行からマネーフォワードやフリーに変えることに強い抵抗を示す人間も地方には多いのです。
（このへんは inst石野さんのブログに詳しい）

すると売上や主要KPIがどこかで行き詰まり始めます。
星取表でどれだけ○が並んでいようと、彼らが嫌っているのは「変化」なのでどうにもなりません。

格付け機関「お前らには失望したよ」

企業の株価というものは、売上と利益からだいたい決まります。
しかし上場しても赤字上等のスタートアップの株価は主要KPIの伸びによって決まります。

スタートアップの主要KPIの伸びがヘタれ始めた場合、株価は伸び悩むどころか下がりはじめます。
株価も緩降下に入るでしょう。

証券企業などで格付けを発表している企業がレーティングを「弱気」に変え、目標株価をピーク時の1/10に設定するなど「終わり」感が漂い始めます。

どうにかしなければいけない

そう。どうにかしなければいけません。
しかし前述の通り、TODOリストに作るべき機能はもうありません。作ればKPIがついてくる機能ももう見えません。
星取表で○を増やすコンペ志向で補いをつけてきましたがそれにも限界があります。
つまりプロダクトマネージャーはこう言いたいフェーズに入りました。
「この先私は何を作ればいいのか」

[解決編]なぜこうなってしまうのか？

P/M-Fitした際に見えていた「市場から必要になるが、いまだプロダクトには備わっていない機能」が見えなくなってきているのが原因です

不確定性だけに着目すれば、初期と同様に「何を作ればいいのか分からなくなる」時期が再び訪れています

しかし 「初心に返れば解決」 する話ではありません。
開発組織自体が大規模かつ小分けになり、高速で進捗とアウトプットを出すことに最適化されているからです。

このフェーズの特徴

アウトプット≠アウトカム
これが最も大きな特徴になります。

不確定性の低かった頃の「とにかくたくさん高速で」製造するスタイルにはあまり意味がなくなります。
なにがユーザーにウケるのかが不明確であり、探索的かつ機動的にソフトウェア開発を行うことが必要になります。
アウトカムにならないアウトプットを多く作っても、それは「ムダ」に他ならないからです。

このフェーズの難しさ

不確定性の高さは開発初期と変わりありませんが、初期の社員数40人程度で行っていた頃に行うことができた「特に明確に何か言わなくてもできるだろ」というやり方は通じません。
初期ならば経営者との距離は近く、また営業やカスタマーセールスとの距離の近さから「今組織に必要とされているものは何か？自分はそこで何をすべきか？」を各人が理解することは容易でした。

しかし大規模な組織では、現場と経営者の距離は遠く、また他職種組織とは分業化によって目隠しされた上で隔離されています。
「今組織に必要とされているものは何か？自分はそこで何をすべきか？」を各人が理解することは容易ではありません。
開発チームも１つではないため、複数のチームが連携する必要があります。

組織変革の必要性、ふたたび

P/M-Fitしてプロダクトや市場への解像度が上がり、同時に組織が大きくなるに合わせて「高速でアウトプットを出せる組織」に最適化したように
今度はプロダクトが成熟して再度不確定性が上がり始める前に、組織を再び「アウトカム志向で探索的志向が強い組織」に作り替えねばなりません。
PdMやPMMを中心とした、それぞれのプロダクト中心の中〜小サイズの組織に改変する必要があります。

この段階ですべきこと（私の仮説）

前提として

この段階だとこれくらいの組織にはなっているよね？という想定で話をしています。

• 時価総額数千億円
• 社員数は500〜1,000人（あるいはもっとか）
• プロダクトは主力プロダクトを中心に複数あり

勘違いしがちなこと

組織が大きくなり、人数が増えます。
するとあれもこれもやろうとしてもできてしまいそうな気がします。
ところができません。やれないのです。

社内のリソースがいっぱいあるように見えても実際にはやれることはわずかです。
ましてやフォーカスがずれて組織の出力が低下してしまえばさらにやれることは減ります。

トップマネジメントは組織のフォーカスを設定に注力すべき（仮説）

組織全体の優先度は何か？それをブレイクダウンすると何が各個人のすべきことになるのか？
これを統一させることがマネジメントの仕事になります。
組織の優先度への見解がブレていると、組織の出力は一気に低下します。
優先度を統一させ、限りある戦力を１つのことがらに集中させること。これが組織力のフォーカスになります。

トップマネジメントとしてやるべきことは以下です。

• 北極星の設定
• 今期および今後３期でやるべきことの言語化
• 組織の優先度のすり合わせと統一

いずれもフォーカスを設定し、進むべき方角を見失わないためにあります。
あるいはもっとゆるっと、戦術的勝利を戦略的勝利に結びつけるために、戦略策定と作戦術を行えるマネジメント層の育成/拡大が経営層の責務になると言ってもいいかもしれません。
マイクロマネジメントを避けるように、個々のプロダクトの細かい行動には経営陣は口を出さない形にします。
これは機動性を維持したいから、という意味もあります。

プロダクト単位で組織をカットするべき（仮説）

プロダクト単位(全職種合わせてMAX100名)の組織単位で探索的に、「いまユーザーに提供して最もバリューが稼げるものはなにか？」「そもそも今稼ぐべきバリューは何か」を探る形にするべきではないかなと思っています。

なぜ組織をプロダクト単位に分割すべきかといえば、大きすぎる組織を避けるためです。
職種ごとではなく、関係するプロダクトごとに組織をカットするのです。

カットしない場合、経営陣のレイヤーにある「司令部」がすべてを差配する必要があります。
しかしそれは不可能に見えます。
数百人以上も社員がいるのに、現場の営業やカスタマーサポートやエンジニアから肌で感じている内容を拾い上げて、高速で戦略や行動に反映して即座に具体的な指示に落とし込むのは不可能です。
組織のレイヤー数が多すぎて伝言ゲームにすら時間がかかってしまいます

（レイヤー数が多いと伝言ゲームがこうなる）

大きすぎることには問題がある

200階建ての高層ビルが存在しないように、50万トンの船舶が存在できないように、タイヤの直径が4mまでが限界なように。高さ20mの巨大ロボットが実用化できないように。
サイズが大きくなれば全てが困難になります。
同様に「現代の技術」でマネジメントできる組織のサイズには限度があるのです。

組織を小さく留めたい

蜘蛛は身軽で俊敏ですが、蜘蛛が象のように大きくなれば愚鈍な象のようにしか動けなくなります。
私は身軽で俊敏に動けるサイズ程度にまで組織を小さく留めたいのです。

具体的にいうと

だいたいこういう３つのフェーズに分かれると考えています。

最初はこんな感じ（小規模＋探索性高）

まず最初のフェーズがP/M-Fitするまで。
シリーズAまでで、従業員数はMAX40人程度です。
経営陣を中心に各チームが密なコミュニケーションをしています。

カフェスペースなどの雑談を通じて、各チームのだいたいの様子を各メンバーは理解しています。
喧喧諤々の大論戦が発生しても、声が大きければ自然と耳に入ってきます。
なのですり合わせも自然とできていて、経営陣が特にはっきりと言わなくても各人が適応性を発揮していい感じにどうにかしてくれるフェーズです。

P/M-Fitして組織が大きくスケールする（大規模＋探索性低）

上記の通り、P/M-Fitして「市場が求めるプロダクト」への解像度が上がります。
「あれば絶対ウケるけど、いまプロダクトに備わっていない機能」を高速で実装することが求められるフェーズです。

スケールのしやすさを考えて、職種ごとに細かく分業、チームわけするフェーズです。
ポストも一気に増えると同時に、経営陣と現場の距離が一気に離れます。
あるべき未来像への解像度が高いため分業しても問題は発生しづらいです。

作るべき機能を作りきってしまい、再び手探り状態に（大規模＋探索性高）

作るべき機能を作りきってしまい、プロダクトごとにユーザーの価値を増やすことを探求するフェーズです。
プロダクトごとにBizとDevの２組織がぶら下がっているのが分かりますでしょうか。
BizはPMMが、DevはPdMが率いる組織になっています。詳しくはSmartHRの記事が分かりやすいんじゃないかと思います。

本当にそれでうまくいくのか？

考察編までは私の実体験が入ってますけど、解決編の仮説のところは私も現実の組織で強い権限持って試したことないので分からないですね。

あと完全に事業の伸びが止まってエース級人材が流出した段階で 「我々は第二創業期！」 と言ってももう組織の現場には「俺たちではもう無理……」とかいう無力感が漂っているのでこの段階から立て直しは辛いです。
株価が緩降下を始めて株価のレーティングが「弱気」になる前に、組織改革の手を打たないと間に合わないと思います。
ということはまだ伸び続けている段階。できれば上場前に入って組織内でポジションと信頼稼げる位置にいないといけないんだろうなと思っています。

このあたりは知見のある方とお話ししてみたいですね。
そういう話をするためにこの記事を書きました