新規プロダクト(N本目の収益の柱, N>1)立ち上げプロジェクトが失敗する理由
最初に
- この記事は2B向けのSaaSの内製開発や新規プロダクトの立ち上げを経験した筆者が書いています
- この記事は独断と偏見と深夜のノリで書いています
- 筆者は先日の酒の席の会話をまとめてこの記事を作ろうとしています。つまり元ネタは酒の席の話です
- いま筆者は酒が入っています
その点を承知の上でお読みください
想定しているシチュエーション
すでに1本目の収益の柱を持っているスタートアップ企業が「新規プロダクト(N本目の収益の柱, N>1)立ち上げプロジェクト」を想定しています。
主力プロダクトですでに十億円以上のARRがあり、さらに収益の柱を増やそうとしている企業がこの話の想定です。
そういう企業ですから従業員数は100人をとっくに超えており、累計調達金額も数十億円を超えています。
金があれば売上を増やす方法が見つかったので、じゃぶじゃぶ金を調達して人を増やしてガンガン売上を増やすフェーズにいます。
ただしまだ赤字かつ未上場です。
（あるいは上場済みでギリギリ黒字というケースもあるかもしれません。）
なぜ「新規プロダクト(N本目の収益の柱, N>1)」の立ち上げが必要なのか
すでに1本目の収益の柱となるプロダクトはあるわけですよね。
しかもそこで十分な売上があります。
なぜ新たな収益の柱が必要なのでしょうか？
出資者は出資先のスタートアップに対して時価総額を増やすことを求めます。
スタートアップの時価総額には成長率が強く関係するため、時価総額を増やすためには高い売上の成長率が必要です。
将来的に1本目の収益の柱の売上成長率が鈍ってくることが予想されるケースにおいて、N本目の収益の柱が必要になる場合が多いです。
売上成長率が鈍れば時価総額は増えるどころか減るでしょう。
そこで1本目の収益の柱だけでは時価総額を増やせないため、1本目の収益の柱と相乗効果が期待される新たな収益の柱となるプロダクトが欲しいわけです。
理想的な新規プロダクト開発のチーム
次に失敗しなさそうな理想的な新規プロダクト開発のチームの話をしましょう。
新規プロダクト開発においては「必要とされるすべてのスキルをチームに備えること」が重要とされます。
するとこのようなチームができます。
様々な職種の人間がいてプロダクトマネジメント、プロジェクトマネジメント、ソフトウェア品質の管理をチームで完結させることができます。
でもこういうチームは作られません。
では実際にはどういうチームが作られるのでしょうか？
実際に編成されがちな新規プロダクト開発のチーム
次に実際に編成されがちな新規プロダクト開発のチームの例を出します。
おやおやずいぶん人数が寂しくなりました。職種もマネージャとエンジニアしかいません。
エンジニア自体の人数も減っています。
なぜこのようなチームが作られるのでしょうか？
そもそもPdMもデザイナーもSREもどこにいったのでしょうか？
まさかこの会社ではそういう役割の社員は一人もいないのでしょうか？
「実際に編成されがちな新規プロダクト開発のチーム」の外の構成
では開発部全体の組織図をごらんください。
PdMもデザイナーもSREも、チームの外にいてそれぞれのチームを作っています。
今までは複数の主力プロダクト開発チームと１つずつの職種別チームがあったところに、新規プロダクト開発チームが新設されたわけですね。
ふーむ。
2つのチームの構成の違いですがPdMもデザイナーもSREもチームの外にいるか中にいるかの違いしかありません。
他に違いと言えばエンジニアの数でしょうか？
問題とはエンジニアの数が少ないのがいけないということでしょうか。
ひとまずその問題は棚上げしましょう。
なぜ開発部はこんな組織図になっているのでしょうか。
理由は開発部の主力プロダクトのプロジェクト開発推進体制にあります。
開発部の主力プロダクトのプロジェクト開発推進体制
それでは開発部の主力プロダクトのプロジェクト開発推進体制を見ていきましょう。
ビジネス上の要求に優先順位をつけ、たとえば「四半期ごとに実現すべき機能のリスト」の形に落とし込みます。
次に「四半期ごとに実現すべき機能のリスト」を機能ごとに見積り、四半期に収まる形で開発スケジュールをガントチャートとして線を引きます。
このガントチャートが開発部全体が経営陣に対して約束した開発スケジュールである「開発ロードマップ」です。
「開発ロードマップ」ができたらプロジェクトを各開発チームにアサインし、四半期ごとの各チームの開発スケジュールを作ります。
開発チームはプロジェクトを分解した開発スケジュールを四半期ごとに持つわけです。
経営陣は「四半期単位の完成する機能リスト」を持ち
開発部は「四半期単位の開発ロードマップ」を持ち
開発チームは「四半期単位の開発スケジュール」を持つわけです。
もちろん経営陣に対して約束された「四半期単位の完成する機能リスト」は原則として変わりませんが、開発チーム単位の「四半期単位の開発スケジュール」は柔軟に変更されます。
また開発が炎上した場合は開発部が持つ「四半期単位の開発ロードマップ」も最悪経営陣と調整して縮小される場合もあります。
この開発推進体制の利点は２つあります。
１つ目はマネージャーの負荷が低い点です。
- プロジェクトマネージメントの一部しか担当しません（開発ロードマップはCTOや経営陣から降りてくるので自分で作る必要はありません）
- 同じ職種のメンバーしかいないためピープルマネジメントの負荷も少ないです（人事評価はより上のレイヤーと調整して行うため、自分で最終責任を負いません）
- チームの人数も少ないため、プレイングマネージャーとしてタスクの分解と管理をしながら自分のタスクに集中できます。
マネージャーの負荷が少ないため育成の負荷も低く、メンバーからの抜擢が簡単です。
そのため開発組織の拡大を容易にします。
２つ目はリソース効率が極めて高い点です。
開発が計画通り進むのであれば極めて効率的に開発を進めることができます。
開発生産性が高く、低いコストと少ない人数で大きな開発成果を出せるでしょう。
またこの開発推進体制には責任と評価に関する利点が２つあります。
１つ目は各人の責任が明確な点です。
「四半期ごとに実現すべき機能のリスト」は経営陣がステークホルダーと調整しながら作ります。
これを機能ごとに見積もって開発ロードマップに落とし込み、開発チームにアサインするのはCTOとEMの役割です。
開発チームはアサインされたプロジェクトを締切までに完了させることが役割です。
開発チームのメンバーはアサインされたプロジェクトを分解したタスクが個人ごとにアサインされ、開発完了予定日までに完了させることが役割です。
各人の責任が明確な分、失敗があった時にその責任を問われるべき人も明確です。
もし締切までにプロジェクトが完了しなければ開発チームのマネージャーの失敗であり、タスクが開発完了予定日までに終わらないことを頻発させる開発メンバーがいればその開発メンバーに問題があります。
あるいはチーム内でタスクが開発完了予定日までに終わらないことを頻発させる開発メンバーが複数いればそれはアサインしているマネージャーの問題です。
同様にプロダクトマネージャはプロジェクトの要件の具体化に責任を持つべきであり、デザイナーはUIデザインに責任を持つべきです。
「毎四半期ごとに納期スリップが頻発するが、何が問題なのか、誰が問題なのかわからない」 ということが発生しづらい点が魅力です。
２つ目は失敗の責任が明確であるために人事評価が簡単かつ短期間でできる点です。
開発組織が大きくなると人事評価が複雑化し、時間がかかるようになってしまいます。
しかしこのプロジェクト開発推進体制ならば各人の役割が極めて明確であるため、いい意味で責任分界点がはっきりしており、人事評価が簡単に実行できる点が長所です。
どこかで失敗が起きて開発ロードマップが完遂できなかった場合は開発部の中の誰に失敗の責任があるかを明確にすることが簡単であり、開発ロードマップが完遂できたのに目標KPIに未達ならば企画サイドの方に問題があると切り分けられます。
四半期ごとの人事評価や半期ごとの給与改定でも時間をかけずにハイパフォーマーを昇級昇格させることができ、逆に失敗の原因を作ったローパフォーマーに減給や降格などの措置を行うことができます。
このプロジェクト推進体制の問題点
上記の体制には非常に優れた特徴がいくつもあります。
特に開発が計画通り進んだ場合のトップスピードは目を見張るものがあります。
しかし長所の裏返しである短所もあります。
１つは計画が予定通り実行できない場合の変更時のオーバーヘッドコストが高い点です。
一度チームからCTOに戻り、CTOとマネージャ間で再度計画を調整し直す必要があります。
CTOとマネージャは再度タスクテトリスやプロジェクトテトリスに多量の工数を使う必要が生じ、本来必要なチームのマネジメントに手が回らなくなります。
また変更によるオーバーヘッドコストの悪影響が発生するのはCTOやマネージャのようなマネージメントレイヤーだけではありません。
要件定義やデザインの修正、インフラ作業を行う場合にもすでに他のプロジェクトに取り組んでいるPdMやデザイナーやCREに重い差し込みを入れて修正作業を行わせる必要があるため、一度計画を変更すると後続のプロジェクトの進行にも悪い影響が出ます。
もう１つは計画の精度を上げることが難しいため一度計画が予定通り進まなくなると遅れが拡大する点です。
また計画を立てるレイヤーと計画を実行するレイヤーが異なるため、計画に変更が生じた際に計画と実行、いずれに誤りがあったのかを検証する手段がありません。
検証する手段がないために誤った前提に基づく計画立案を何度も行い、何度も手戻りが生じる可能性があります。
「失敗の本質」風に言えば「シングル学習ループ」であるがゆえの問題です。
上記のように一度計画で見落としが見つかり手戻りが発生すると全てが狂い始めます。
すると責任と評価に関する利点の裏返しとなる短所も発生します。
最初から見落としが発生しやすい計画を立てることをCTOやマネージャは嫌がります。
なぜならそれは失敗とみなされて自分の評価が下がるからです。
すると見落としが発生しないように、本質的なゴールの達成とは遠い目標を立て始めるのです。
新規事業にこのプロジェクト開発推進体制を持ち込んだ時に発生すること
あるプロジェクトの実行時に計画とは異なる予想外の見通しが複数発見されることがあります。
新規プロダクトならば特にそうです。
なぜなら新規プロダクトは目的不確実性が高く「上流」の部分で計画時には見落とされていた要素の「発見」がしばしば起きるからです。
この発見された要素を取り込む必要があると判断された場合、計画の変更が生じます。
それはつまりチーム外のメンバーに対して重い差し込み作業を発生させ、同時に彼らが今取り込んでいる作業を終わらせて差し込み作業に入るまでの待ちも発生します。
CTOとチームマネージャはタスクテトリス作業に没頭する必要が生じます。
PdMやデザイナーやCREは重い差し込み作業を差し込まれて後続の予定が狂います。
もし彼らが差し込み作業にすぐ取りかからないなら、それはつまり新規プロダクト開発チームの開発を止めることになるでしょう。
そこでCTOやマネージャは計画や予定を狂わせる「発見」をできるだけしないように目標の方を修正します。
ユーザーからのフィードバックの取り入れの優先度を下げ、とにかく機能の開発を最優先にします。
フィードバックが反映されず、失注理由への対応も後回しになるわけですから当然売上やARRの伸びは芳しくなくなります。
職種ごとの分業制チームと新規プロダクト開発チームの相性が悪いことは分かりました。
ではなぜこんな非効率なやり方を開発部は採用しているのでしょうか？
主力プロダクトの方では、頻繁に計画のし直しは発生しないのでしょうか？
企画や要件定義の誤りはそう簡単に発生しないのでしょうか？
なるほどもっともな疑問です。
それでは主力プロダクトにおけるビジネス上の要求の優先順位のつけかたを見ていきましょう
主力プロダクトにおけるビジネス上の要求の優先順位のつけかた
ある程度以上の規模のプロダクトにおいて定石とも言える顧客の要求の収集方法があります。
１つはカスタマーサポートへの問い合わせです。
しかしこれはCHURN(解約)を防ぐ、いわばバケツに開いた穴を塞ぐ役にしか立ちません。
もう１つは営業が集めてくる受注/失注情報です。
近年のSaaSは2B、特に大きめのSMBやエンプラという大企業向けの案件が多く「DX推進のために新たにSaaSを導入したい。ついては複数企業のコンペにかけて導入先を決める」というケースが多いです。
そこで受注成功した場合は「自社SaaSのどこが強みとして評価されたのか」、コンペに負けて失注した場合は「自社SaaSのどこが弱みとして嫌われたのか」というフィードバックが得られます。
それを機能ごとに整理すると以下の○×表ができます。
この○×表を「星取表」というのですが星取表で×の数を減らす。また受注につながるキラー機能を見極めて強化していくことが強いSaaSプロダクトのキモとなります。
経営陣やPdMがすべきことはあるべき自社プロダクトの姿を見極め、×から○に変えるべき機能、強みを強化すべきキラー機能、それらを見極めてどの順序で機能を変えていくか？を決心することになります。
この変えていくべき順序が優先度であり、「四半期単位の完成する機能リスト」の元となります。
主力プロダクトにおける企画や要件定義の仕方
優先順位をつけたら次は企画や要件定義です。
営業から集めた情報と競合プロダクトを有識者が実際に触ってみた意見をもとに企画や要件定義を決めていきます。
競合プロダクトとはいえ、すでにプロダクトはありますし実際のユーザー体験も競合プロダクト上で成立しているわけですから企画や要件定義も前述の新規プロダクトに比べれば比較的簡単です。
また実際に失注理由や受注理由にユーザーが挙げているわけですから、作ってみたけど使われない、というケースも比較的少なくなります。
主力プロダクトにおける優先順位づけや企画や要件定義は競合プロダクトがあるために比較的失敗しづらいことがポイントです。
ただしこれは「すでに市場に競合プロダクトがあり」「星取表が作れるほど自社プロダクトが競合プロダクトと五分に渡り合える状態にあり」「競合プロダクトを導入したユーザーによってユーザー体験が実証済みであり」「コンペによって営業からフィードバックが収集できる」点という前提があります。
営業からのフィードバックと星取表を使えば失敗の少ない優先順位づけや企画や要件定義ができることは分かりました。
ではなぜ新規プロダクトでは失敗してしまうのでしょうか？
新規プロダクトでは星取表が成り立たない
新規でプロダクトを作る場合、星取表が成り立ちません。
なぜならプロダクトとして若すぎ、機能が少なすぎるからです。
10個の機能のうち、競合プロダクトの○の数は9~10個。自社の新規プロダクトの○の数は2~3個。
そんな状態でコンペは成り立つでしょうか？
まともなフィードバックを得られる前にコンペにすら参戦できないでしょう。
あるいは競合プロダクトが存在しないブルーオーシャン市場をターゲットとした場合はどうでしょう？
競合プロダクトが存在しないので星取表が存在しません。
またユーザーも導入していないので金を出すに値するユーザー体験自体が成立するかどうかも分かりません。
星取表もなく比較すべき競合プロダクトとの比較が成り立たないので営業を通したコンペからの質の高いフィードバックが成り立たないのです。
しかし疑問が生じます。
「新規プロダクトは機能が少なく星取表での競合プロダクトとの比較が成り立たない」
「コンペを通じた営業からのフィードバックによる改善が成立しない」
この仮説は本当に正しいのでしょうか？
主力プロダクトも初期にはそのような時期があったはずです。
でも主力プロダクトは成功しています。
なぜでしょうか？
「星取表が成り立たないから検証サイクルが成り立たず、新規プロダクトは失敗する」という仮説は正しいのか
主力プロダクトの開発の初期は前述のような、PdMもデザイナーもCREもエンジニアもマネージャも、全員が１つのチームにいたはずです。
QAはいなかったかもしれませんが、CSや営業もチームにいたでしょう。
つまり「星取表での比較」「コンペを通じた営業からのフィードバックによる改善」がなくても分業していないためフィードバックを取り込む検証サイクルが成り立ちます。
自分たちで作ったプロダクトを自分たちで触るドッグフーディングによるフィードバックと検証サイクルが成り立つので、主力プロダクトの開発初期には問題はなかったのです。
ところが組織が大型化するにつれて職種ごとの分業チームが成立するようになり全職種が１つのチームにあることによる高速なフィードバックと検証サイクルは成り立たなくなります。
それに代わって「星取表での比較」「コンペを通じた営業からのフィードバックによる改善」を行うように代わっていくわけです。
主力プロダクト開発初期と新規プロダクト開発時の違いその１、チームの構造の変化による変化への適応度の低下
「権限の強いマネージャが率いる全職種を内包するミッション型のチーム」にはドッグフーディングや他職種からのフィードバックを採用する高速なフィードバックと検証サイクルが機能します。
当然フィードバックは計画作りに取り込まれるわけですからダブル学習ループも成立するでしょうし、変化や発見に強い開発プロジェクトの推進ができるようになります。
しかし職種ごとに分業型チームを作ると「権限の弱いマネージャが率いる単一職種によるタスク型のチーム」になります。
チームの壁を跨ぐためにフィードバックを受ける機会は減り、検証はできません。
計画づくりにフィードバックが取り込まれる機会も乏しいわけですからシングル学習ループにならざるを得ず、変化や発見に弱い硬直した開発プロジェクトの推進になります。
主力プロダクト開発初期と新規プロダクト開発時の違いその２、時代と周辺環境の変化
実は主力プロダクト開発初期と新規プロダクト開発時の違いはもう１つあります。
2010年代中盤を思い出してください。
伝統ある会計ソフトだった弥生会計や勘定奉行から、スタートアップによる後発のクラウド会計ソフトがシェアを奪っていた時期です。
モダンで使いやすいUIやクラウド上で提供されるためにアップデートやセットアップの利便性によってクラウド会計ソフトがシェアを奪っていきました。
ですが2025年にクラウド会計ソフトを新しくSaaSで作ったら同じようにシェアを奪えるでしょうか？
ある程度シェアを確保しており機能が揃っている主力プロダクトなら競合と戦えるでしょう。
しかし今から新規で立ち上げるプロダクトでは難しいと思います。
なぜならクラウド上で動作する、アップデート無料のような10年前なら革命的だった要素を今から作ることは難しく、仮にAIフレンドリーのような要素があってもすぐ競合に追いつかれるからです。
最後発のSaaSが市場シェアを奪うには「徹底的な使いやすさ」以外にないと私は考えています。
「徹底的な使いやすさ」を備えたプロダクトを支えるものとはなにか
私は２つあると思います。
１つは主力プロダクト立ち上げ初期のように「権限の強いマネージャが率いる全職種を内包するミッション型のチーム」によって開発を行うこと。
他職種からのフィードバックが開発チームに高速で伝播され、常に計画作りから見直しながら変化に強いチームによって高速で改善されるプロダクトを作ることです。
フィードバックを常に取り込み高速で改善されることで、徹底的な使いやすさを備えたプロダクトづくりを可能にします。
もう１つは顧客との対話をエンジニアが怖がらないことです。
顧客からの話をサポートや営業に取りまとめてもらってサマリや要約情報をもらった方が開発としては楽でしょう。
しかしそれではサマる過程で本質的な要素が削ぎ落とされ当たり障りのない話になります。
それではユーザーのペインに対する芯を食ったソリューションは出てきません。
エンジニアが生のユーザーの要求と向き合い、そこに対してソリューションを考えていくことこそが徹底的な使いやすさを備えたユーザー体験につながると考えています。
もちろんエンジニアそれぞれが放し飼い状態でユーザーと向き合えとは言っていません。
ユーザーヒアリングにはPdM立ち会いが必要ですし、プロダクトの全体の方向を揃えるためにもPdMは必要です。
分業制による職種別チームで新規プロダクトを作って成功させることはできないのか
私は成功させることはできると考えています。
成否の鍵はプロダクトマネージャとプロジェクトマネージャです。
プロダクトマネージャは最後発プロダクトとして、ユーザーのペインに対して芯を食ったソリューションを考え、そのソリューションの実現のために細大漏らさずエンジニアに伝えて「自分が考えた通りの機能」を実装させる能力が重要です。
従来型の分業制による職種別チームでは手戻りによるオーバーヘッドコストが大きいため、作る過程でこのままではうまくいかないと言う発見をして手戻りが出ないよう、完璧な機能を事前に企画する必要があります。
また「俺は完璧なアイディアを考えたが、ソリューションを実装したエンジニアがヘボだった」という言い訳をせずに機能のデリバリーまで責任を持てるプロダクトマネージャが必要とされます。
もう１人重要なのはプロジェクトマネージャです。
従来型の分業制による職種別チームでは手戻りによるオーバーヘッドコストが大きいため、事前にロードマップの各プロジェクトの見積を完璧に行い、また各メンバーへのタスクのアサインと完了日の設定を完璧に行い、プロジェクトを確実に期日までにデリバリーまで持っていけるプロジェクトマネージャが必要とされます。
たしかにこんなプロダクトマネージャとプロジェクトマネージャを見つけるのは簡単ではないかもしれません。
黒い白鳥や唐土の火鼠の皮衣くらい見つけるのは難しいかもしれませんが、分業制による職種別チームの手戻りコストの大きさと最後発の新規プロダクトを成功させることを考えれば必要不可欠と言っていいでしょう。
もう一度結論
さて話を戻しましょう。
想定している企業ではこのようにフィードバックサイクルが変化していきました。
そのため途中で新規プロダクトのフィードバックサイクルが機能不全に陥ることが問題であり、以下の手法で新規プロダクト向けのミッション型チームを編成することでフィードバックサイクルを機能させてはどうかと私は提案しています。
フィードバックサイクルの変化
３つのフェーズを通してフィードバックを得る手段が変化し、組織の体質としてヒットする新規プロダクトが作れなくなります。
（フェーズ１）主力プロダクト立ち上げ初期
「創業社長という最強権限のマネージャが率いる全職種を内包するミッション型のチーム」によるプロダクトの開発。
チームはプロダクトマネジメント、プロジェクトマネジメント、ソフトウェア品質マネジメント、ピープルマネジメントの権限を持つ。
プロダクトに対するユーザーや見込み顧客からのフィードバックが他職種から開発チームに高速で伝播される。
変化に強いチームによって常に計画作りから見直しながら高速で改善されるプロダクト開発を行う。
（フェーズ２）主力プロダクトのシェアがある程度確保された段階
売上やARRが十億円を超える頃。
会社規模の拡大に伴い、営業、CS、エンジニア、PdM、デザイナーなどの職種ごとに分業型チームを作る。
各チームは「権限の弱いマネージャが率いる単一職種によるタスク型のチーム」になる。
チームはピープルマネジメントの一部とプロジェクトマネジメントの一部の権限だけを持つ。
各チームは四半期ごとのロードマップやチーム別スケジュールを締切までに達成することを目指す。
チームは変化に弱くなる。
コンペを通して営業からフィードバックとして受注/失注理由が伝えられ、星取表ベースの優先度に基づいてプロダクト開発を行う。
（フェーズ３）新規プロダクトの開発が必要になる段階
累計調達額が数十億円を超える頃。
ARRの成長率を維持するため新規プロダクトが必要になり新規プロダクト開発チームが組成される。
しかし「権限の弱いマネージャが率いる単一職種によるタスク型のチーム」と変化に弱いロードマップ型スケジュール、機能しないコンペを通して営業から受注/失注理由が伝えられるフィードバックの組み合わせによって新規プロダクトは売上が伸びなくなる。
解決策の提案
フェーズ３において新規プロダクト開発チームに対しては「強い権限のマネージャが率いる全職種を内包するミッション型のチーム」を組成し、貪欲にユーザーからフィードバックを取りながら「徹底的な使いやすさを備えた新規プロダクト」の開発を目指す体制にすることを提案しています。
もちろん主力プロダクトに対しては現状のままで構いません。
質の高いフィードバックを得る手段があり、それでARRの成長率がある程度確保されていて、スケール可能な組織体制なのだからそれで十分でしょう。
新規プロダクト開発チームだけを変えたらどうか、と私は提案しています。
以上
Discussion