mofmof inc.では「開発チームレンタル」という月額制の開発サービスをやっているのですが、当然、出来るだけ関わったサービスは成功して欲しいと思ってやってます。

新規事業の成功率は一般的に5%とか10%とか言われていて、何か一念発起して作ってみても大抵は失敗してしまうわけです。体感ではむしろ5%,10%なんてけっこう優秀な数字なんじゃないですかね。実際にはもっと低い気がします。

ともすると、我々が関わったからには少しでも成功率を上げたい。

しかしながら、開発部分を担当するという参画の仕方をしていると、それ以前の部分で失敗パターンを踏んでいるなーと気付いたとしても、時既に遅しだったりすることもあり、歯がゆさを感じることがあったりします。

そこで、今まで見聞きした、新規事業の開発で失敗しがちなパターンを共有します。

パターン1 顧客の課題やソリューションを十分に検証していない

最も致命的なパターン。新規事業の立ち上げ手法である「リーンスタートアップ」の考え方は新規事業関係者の中では市民権を得つつあるので、詳しい説明は書籍に任せるとします。

ここで言う「顧客」とは実際にサービスを使う「エンドユーザー」を指しています。超デフォルメして言ってしまうと「オレが考える最強のサービス」を作るのではなく、作り込むより先に「顧客が本当に欲しいと思っているサービス」を追求せよ、という考え方なのですが、これを出来る限りやらないと成功率は上がらない。

価値のあるものを作ってローンチさえすれば、きっと使ってもらえるだろう、というのはハッキリ言って甘えです。それ失敗しますよ、言い切れるレベル。新規事業のコンセプトを10本以上はリーンスタートアップ的に検証してきましたが、事業化判断したものなんてごく一部です。それくらい振い落さないといけない。

かつて、ぼくがいちエンジニアとして仕事していた頃、一人で振り返りができる「Kptodo」というツールサービスを作ったことがありました。懸命にSNSシェアしたり、コンテストに出してみたり、思いつく限りのPR施策を実行したにも関わらず、登録ユーザー数は50人(アクティブはほぼゼロ)程度という散々な結果になったことがあります。

Kptodoのユーザー獲得がうまくいかなかった最大の理由は、「自分が欲しいのなら他に欲しがる人がいるはず」という根拠のもと開発をしてしまっていたことです。「顧客が本当に欲しかったもの」を見つけようとしていなかったのです。本来であれば作り込むより先に、エンドユーザーにインタビューしたり、プロトタイプを触ってもらって反応を確かめたりすべきところを、ただ開発だけ進めてしまったのです。

パターン2 作り過ぎ問題

なぜ顧客が本当に使ってくれるかも分からんものをそんなに機能モリモリするのか。いいか、まず使ってもらうんだ。最速で使ってもらうんだよ。それが新規事業だ。

大規模なクライアントに多い印象ですが、MVP(Minimum Viable Product)を作りたいです！と言いながら、これも必要あれも開発が必要という流れで、機能過多になっていたりする。

MVPにはこの部分は必要ないのでは？という提案をしても「そこは既に作ると関係者で決めてしまっているので動かすことは出来ません」と返されてしまったり。

コアなバリューを満たすための最小限の形はどんなものか？

突き詰めていくとびっくりするほど小さくなったりします。本当にこんなにシンプルにしちゃっても良いの？と不安になりますが、MVPを導くには不要なものをそぎ落とす勇気を持つ必要があるのです。

パターン3 開発計画を厳守し過ぎる

計画を守るのはいいことだろう？と思うでしょうが、実はこれ落とし穴。

システム開発という仕事は、昔の昔から非常に失敗事例の多いものでした。現在でも上手くいく開発手法の研究は盛んで、特にスクラムやXPなどアジャイル開発の分野が発展し続けています。逆に言えばそれだけ失敗しやすいということなのです。

システム開発は、

• 作りたいプロダクトの定義が曖昧になりやすい
  
• プロダクトの定義が変更されやすい
  
  という特性があります。
  
  製造業的なメソドロジーでは、定義を明確にし、計画に従って進めることが一定の成功をおさめてきました。システム開発でもそれに倣って同様のアプローチが取られてきましたが、残念なことに多くの失敗を重ね、結果は散々なものになりました。
  
  プロダクトの定義を一定に保つことが難しい(特に新規事業は)以上、どこからどこまでをいつまでに作る、という計画を絶対的なものにしてしまうと大きな失敗を呼ぶことになります。
  
  アジャイル開発の手法では、
  
  
• スケジュール
  
• 予算
  
• スコープ(開発範囲)
  
  の3つはトレードオフの関係にあるという説明をしています。
  
  例えば、計画した開発範囲を満たすということを重視するなら、スケジュールを遅らせたり、予算を増やしたりしなければならない。リリースを早くしたいのであれば、予算を増やしたり、スコープを狭めたりしなければならないということです。
  
  計画を厳守して、決められた通りにものづくりするよりも、計画を細かく見直して、顧客から得られた新しい知見を組み込んで、プロダクトの定義を変化させながら作っていけるやり方の方が圧倒的に上手くいきます。
  

その他にも

失敗パターンはまだまだ他にたくさんあります。例えば、

• 初期ユーザーを確保していない
  
• 完成度にこだわってリリースしない
  
• バグだらけでリリース出来ない
  
• 作った人がいなくなる
  
• プロダクトオーナーが不在
  
• マーケティング全く考えてない
  
  などなど上げればキリがありません。
  
  我々は開発を最も得意としている企業ではありますが、もとより我々がつくったもので世の中に価値を届けたい、ということを組織のビジョンに持っています。
  
  だから開発だけでなく、我々自身も知識をアップデートして、少しでも新規事業が上手くいくように寄与したいと願っています。
  

あなたのビジネスの構造がわかる 一枚のテンプレート【無料】

ダウンロード　→

インセプションデッキの要点を解説 テンプレート付き実践ガイド【無料】

ダウンロード　→