スタートアップの「死の谷」を乗り越えるためのプロダクトマネジメント

 

スタートアップとは「アイディアの製品化」によって急速な事業成長を目指す試みのことですが、それを実現するには少ないリソースで適切な製品開発を行う必要があります。

多くのスタートアップがシード期の「死の谷」でアイディアを実現させる前に倒れてしまう中、どうやって MVP(Minimum Valuable Product,アイディアの評価ができる製品)を製作してビジネス開発のフェーズに移行させればよいか。

そのノウハウについて、弊社の4年間の経験から得た知見をご紹介します。

 

MTW2_landing_head2

これから商用版としてリリースされる弊社のサービス「マンモスプロジェクト」。個別タスクやコミュニケーションだけでなく、プロジェクト全体を可視化できるB向け SaaS サービスとして6月中旬に提供予定。弊社では自社サービスを使ってプロジェクトマネジメントを行っています。(クリックで画像拡大)

 

事業アイディアはオリジナルか模倣か

スタートアップの核となるアイディアは独創的であればあるほど、その実現には多くの試行錯誤が伴います。これはプロジェクトの複雑さに反映され、またその実行に必要なリソース(時間や労力)にも反映されます

既にシリコンバレー等で確立されたサービスや他分野のアイディアを転用すれば「お手本」があるため、製品化までの試行錯誤は減らせますが、参入障壁が低いことから競争が激化しビジネス環境がレッドオーシャンとなる可能性もあります。

また、圧倒的な資金とサービス力を持つ本国からの「黒船来襲」や、大規模ローラー作戦を展開する国内大企業の参入の可能性もあるでしょう。さらに、事業アイディアの選択は自分たちの競争環境と収益構造にも反映され、「大きな時価総額を見込める企業になれるか」という将来性にも影響します。

 

このように事業アイディアの軸を「オリジナル」とするか「他者の模倣」をベースとするかは極めて重要なポイントですが、その判断に伴う「アイディアの革新性とその実現に必要なリソース」のジレンマを乗り越えるには、適切な製品開発のマネジメントが求められます。

 

弊社の経験では、事業アイディアをビジネスへと形成するには大きく分けて3つのフェーズがあり、そのフェーズごとにマネジメントのスタイルを最適化していく必要があると考えています。

 

死の谷のフェーズと乗り越え方

死の谷のフェーズと乗り越え方、技術的負債の返済タイミング。(クリックで画像拡大)

 

 

 1. 「アイディアの具体化」フェーズ

まず「独創的なアイディア」が本当に既存の技術で製品化できるかを確認するのがこのフェーズです。この段階ではまだビジネス化が見えていないため、チームを少人数としてコストを抑え、できるだけ「枯れた技術(web の場合は LAMP など)」を採用することが重要なポイントとなるでしょう。

 

「新規性で戦うスタートアップ」と「枯れた技術」は一見イメージが一致しない印象がありますが、プロトタイピングの段階で枯れた技術を採用するのは、新技術を採用した際は実装中に想定外の限界が見つかることが多いからです。

確かに新しい言語やフレームワーク、ライブラリは多くの実装コストを減らしますが、アイディアを実現するために独自の拡張を行おうとすると、減らせた分を上回るコストがかかる傾向があり、バグも出やすくなります。また、内部構造が未熟なため、場合によっては自分たちで触れないコア技術のアップデートを待たないと問題が解決しないこともあります。これは生存期間が限られているスタートアップにとってはまさに「致命的な影響」をもたらす可能性があります。

また、新技術は情報リソースが少ないことが多く、学習コストも軽視できません。こうした状況を総合的に検討すると、プロトタイプの段階ではこなれている枯れた技術を採用することが合理的な選択となることが多いのです。

 

プロジェクトマネジメントのスタイルはアジャイルも有効ですが、このフェーズでは十分な資金的・時間的リソースが確保できないスタートアップがほとんどであるため、一定の稼働量を前提としたスクラムは実施が困難であることが多いでしょう。

仮に都内で最低限生きるのに必要な月20万円を一人あたりで確保するにしても、チームで一定期間動くとなるとそれなりの資金が必要となり、この段階でまとまった資金を獲得するのはなかなか難しいことでしょう。また、各自が生業を持って副業としてプロジェクトを行う際は逆に安定した稼働量が確保できなくなるため、スクラムをプロジェクトのベースとするのは困難となるのです。

 

エンジニアのみでプロトタイピングを行う場合はエクストリームプログラミング(XP)の採用も可能ですが、技術ドリブンのプロダクトはどうしても「商品」としては理解されづらいため、UX やマーケティング要素を専門性として持つ人材をチームに入れなければうまくいかない場合もあるでしょう。

そうした非エンジニアを含む複数人のチームでは「クリティカルパスマネジメント(タスクの前後関係を正確に把握してマネジメントする方法)」が適切だと考えています。

短期間で稼働を確保して一気呵成にプロトタイプを作り上げるというよりは、チームで常にプロジェクトの状況を共有し柔軟性を確保した上で、実装タスクを積み上げて検証可能な状況まで持っていくという考え方です。

 

図表2

弊社プロダクトのプロトタイプフェーズ。各タスクのクリティカルパスを共有して進捗を共有した。(クリックで画像拡大)

 

2. 「プロダクトのブラッシュアップ」フェーズ

プロトタイプを製作して、アイディアの製品化が可能そうだと判断できるところまで来たら、今度はそれを MVP(Minimum Valuable Product, アイディアの評価ができる製品)として他者が評価できるところまで持っていくのが目的となります。

 

スタートアップを語る上で見過ごされがちな点ですが、スタートアップが置かれている環境は数年前と比較して、「サービスに求められる品質基準」と「ビジネス構造の複雑性」が飛躍的に上昇しています

スマホアプリやWebメディアが隆盛した時代はアプリやサイトのプロトタイピングと製品化を一気に行い、プラットフォームが提供する課金モデルでビジネスを形作ることが可能でしたが、現在はそうした既存のプラットフォームもレッドオーシャン化しており、ビジネスとして成立させるために必要な開発費や広告費、営業費用も大幅に跳ね上がっています。

 

また、大企業でも徐々に「リーンスタートアップ」やアジャイルの方法論が取り入れられるようになり、少ない自己資金で運営するスタートアップはそうした巨大なリソースを持つ企業が無償もしくは安価で提供するサービスの品質レベルと戦っていかなくてはなりません。

つまり、一旦事業アイディアが検証可能な状態になったとしても、数年前と比べて他者が評価できる MVP まで持っていくハードルが飛躍的に上昇しているのが現在のスタートアップ環境なのです。

 

したがって、このプロダクトのブラッシュアップも数年前より大幅に試行錯誤の量が求められることになり、場合によっては機能の作り直しなども含まれます。

運良くこの段階の初期に一定額の資金調達が可能となれば、安定した稼働量を見込んだスクラムを実施して短期間でブラッシュアップすることが可能となりますが、それが不可能な場合は引き続きクリティカルパスマネジメントを行い、「実績を積み上げること」を目的とするのが有効でしょう。

 

弊社プロダクトのブラッシュアップフェーズ。初期α版からβ版までのタスクのクリティカルパスを可視化している。(クリックで画像拡大)

 

 

3. 「プロダクトの製品化」フェーズ

MVP を製作することができたら、プロダクトを品質面でも「世の中に出せるレベル」に持って行き、課金システムなどのビジネス上の要求を組み込んでリリースすることが目的となります。

このフェーズに入れば、アイディアは多くの人に理解してもらえる状態になるため、資金調達なども以前のフェーズよりはスムースに進めることができます。欧米と異なり、日本の資金調達環境で出資の窓口と審査を担当するベンチャーキャピタルや政策金融公庫の担当者は製品開発のプロであることが少ないため、事業アイディアや製品の理解を得るには、自分たちだけでこの段階まで持っていくことが必要なことが多いという事情もあります。

 

「新しいモノを作る」ことは、それ自体がエンジニアやデザイナーなど多くの専門家にとってモチベーションにつながる営みですが、製品化のフェーズでは細かいバグ取りや UI/UX のブラッシュアップが必要とされます。

資金調達を行い稼働を確保することで、これらの「つまらないけど大事な大量の仕事」を片付けていくことが可能となるため、スクラムを実施できるようになるのです。1-2週間程度の短期間のイテレーション(反復)をベースに、大量の細かいタスクを片付けていくことを目的にプロジェクトを進めます。

 

これをやり切って製品化にたどり着ければ、「死の谷」も好転の兆しが見えてくるため、セールスやマーケティングといったビジネス開発に取り組んでいくことができるようになるのです。

 

弊社プロダクトの製品化フェーズ。リファクタリングと新規開発の部分をクリティカルパスマネジメントで管理し、ブラッシュアップをカンバンで行っている。(クリックで画像拡大)

 

 

経営課題としての「技術的負債」をどう解消するか

プロダクトの製品化によってビジネス開発を行うことができるようになると、プロダクトには新規性や一定の品質に加え、システム上の安定性や拡張性が求められるようになります。

この時に課題となるのが「技術的負債」、すなわち「行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす負の遺産」をどう解消していくかです。

 

技術的負債の解消に最も有効なのはリファクタリングで内部構造を作り直すことですが、リファクタリングそのものはプロダクトの表面的な機能には寄与しないため、多くのスタートアップ経営者が不要な開発コストとして認識し忌避してしまいます。

しかし、技術的負債は不要な開発コストを垂れ流すことに繋がり、さらに開発者のモチベーション低下を引き起こすことで、中長期的に経営面で大きなコストとリスクをもたらします。これを自動車に例えると、本来はエンジンを向上させるためにエンジニアリソースを投入するべきなのに、構造が複雑なためにパンク修理に時間がかかって一向に良い自動車が作れない、というような状況です。

したがって、「実装優先」となってしまう製品化までのプロセスで、いつこの技術的負債を解消するかが非常に重要な経営課題となります。

 

長い「死の谷」の間に「作り直し」を入れることは非常に勇気の要る判断ですが、やはりビジネス要件が増える前に「製品のバージョンアップ」として早期に導入することが重要でしょう。

 

シリコンバレーでは92%のスタートアップが3年以内に消えると言われています。日本でもその苛酷さは変わらないでしょう。

志を高く持って過酷な環境でチームで生き残りプロダクトを形作っていくには、確かなマネジメント技術が必要とされます。

本稿が独創的なアイディアをビジネスにするという高い志を持つ方の参考になれば幸いです。

 

(本稿は Agile Japan 2016 で配布された EM Zero というフリーペーパーに寄稿した論考を加筆改訂したものです)

 

Masayoshi Hashimoto

「フロントライン通信」編集長。業務経験は15年を超え、メディアサイトから数千万人規模の会員システムまで、10社で80件以上のプロジェクトのマネジメントを実施。2011年にスタートアップを立ち上げ、多くの人がプロジェクトをより成功できるためのツール「マンモスプロジェクト(Mammoth Project)」を開発。世界中の現場で戦うチームを応援することを人生の使命とする。

You may also like...

コメントを残す

メールアドレスが公開されることはありません。