今回は大企業での新規事業開発の失敗体験談をご紹介します。
今回のテーマは「完璧を目指す」です。
新規事業プロジェクトの概要
私は、これまで複数の新規事業の立ち上げに関わってきました。上司から新規事業プロジェクトのメンバーとしてアサインされたケースもありますし、プロジェクトの立ち上げに責任者として携わった経験もあります。
今回、紹介するのは私が新規事業プロジェクトの立ち上げにマーケティングの責任者として携わった時の経験からご紹介します。
この新規事業プロジェクトは、当初は複数の部署で検討されていた新規事業でした。私は、その複数のプロジェクトの1つで事業開発(BizDev)をメインで担当しており、外部企業との折衝や社内調整などを主担当として担当していました。
事業の詳細はお伝え出来ませんが、事業コンセプトとしてはIoT×シェアリングエコノミーなどと当時作成した企画書などには書いていました。
IoTとは
IoTとは、「Internet of Things」の略で従来インターネットに接続されていなかった様々なモノ(センサー機器、駆動装置(アクチュエーター)、住宅・建物、車、家電製品、電子機器など)が、ネットワークを通じてサーバーやクラウドサービスに接続され、相互に情報交換をする仕組みのことです。
シェアリングエコノミーとは
シェアリングエコノミーとは、個人や企業が持つ資産(場所やモノ、リソース(スキル)など)を、インターネット上のプラットフォームを介して取引するビジネスモデルのことです。さまざまな資産を共有することで成り立つビジネスであることから、「共有経済」とも呼ばれます。
シェアリングエコノミーは、取引される試算によって、主に下記の5つに分類できます。
プロジェクト組成の成り立ち
私が所属しているのは、大きな組織なので、複数の部署で同じような事業の企画を進めているようなこともあります。私が事業開発(BizDev)担当として、外部企業と折衝していると、「御社の●●事業部からも同じような提案がありましたよ」との情報を得ました。
1ヵ月の間に3社から同じような情報があり、このまま交渉をすすめると会社としての信用にかかわるなと思い、担当役員に相談して、他事業部の担当役員に相談してもらうことにしました。
プロジェクトの合併
担当役員から「他の事業部で検討している事業内容が、かなり近いので一緒にやってみたらどうか」と提案されました。単独事業として検討をすすめたいとの思いもありましたが、他の事業の方が検討が先行している部分もあり、話し合いの結果、一緒に事業検討をすすめることになりました。
開発は外注
私たちのプロジェクトと他の複数事業部との最も大きな違いは、開発を内製するか、外注するかと言う点でした。私たちはもともとエンジニアを複数人抱えておりシステム開発は内製するつもりでした。※IoT機器の開発は外注するつもりで、深圳で開発する予定でした。
しかし、他プロジェクトでは開発予算を潤沢に確保していたこともあり、システム開発は外注することとしました。新チーム内で必要な機能を洗い出して提案依頼書(RFP)に落とし込んで開発会社に見積もりを依頼しました。
複数の開発会社から見積もりを提出してもらいましたが、どこも億以上の見積もりでした。
複数の事業部から集まった新チームでは、それぞれがやりたいことを提案依頼書(RFP)に落とし込みました。「こんな機能必要か?」と思うものも、他の事業部の優先順位が高いことを理由に削ることができませんでした。
開発予算が潤沢だったことと、各事業部が互いに遠慮しあった結果、必要以上の機能を盛り込んだシステムの開発を発注することになりました。
機能追加が続く
システム開発の発注をおこなった後も、提携候補企業やクライアント候補企業との折衝が行われ、必要な機能が、次々に追加されました。
機能追加の見積もりを取っていくと、とうとう予算が底をついてしまいました。ここにきて未着手分の仕様の優先順位を精査して開発対象外とする機能もでました。
開発は無事にスケジュール通りに完了しましたが
開発会社の協力もあり、無事にスケジュール通りに開発は完了しました。
しかし、シェアリングビジネスの場合は、提供者と利用者をバランスよく集めていなければ利用者の満足度は高められませんが、提供者も利用者も計画通りに集めることが出来ません。。。
営業リソースもマーケティング予算も新規事業としては潤沢にある状態だったので、提供者は法人を中心に獲得活動を強化しました。ビジネス条件を有利な内容にして獲得活動を実施したところ、提供者数は右肩上がりに増えていきました。
法人顧客(提供者)の声が大きい
法人顧客(提供者)の獲得はすすみましたが、獲得を優先したため各法人からは、様々な要求をもらいました。結果、優先順位の高くない機能でも交渉力の強い法人顧客の要望にはこたえなければならなくなりました。
利用者がつくことで機能開発ニーズが出てきた
また、利用者も増えてきてユーザーヒアリングなども行った結果、追加したい機能なども出てきました。この時点では、開発に使える予算が底をついており、開発しようとしても、元のシステム規模が多きく、ちょっとした機能追加も工数が膨らみました。
反省点
このプロジェクトでの学びは
- 新規事業でのシステム開発はウォーターフォール型よりもアジャイル型の方が向いている。
- 新規事業では必要最低限の機能で価値をテストして価値を磨きこむリーンスタートアップ型が向いている。
- 新規事業ではサービスリリース後に必要な機能要求が出てくると考えるべし
などです。
この時の反省を活かして、それ以降の新規事業開発では「リーンスタートアップ型」でMVP(Minimum Viable Product)を制作して、プロダクトの価値を検証してから本格的な開発に入るようにしています。
リーンスタートアップに関しては「リーンスタートアップを徹底解説! | 現役イントレプレナーが教える新規事業のヒント」で詳しく解説しています。
コメント