小さなIT企業での新規事業立ち上げにおける反省点をまとめてみた。
こんにちは、僕です。
今回は、昨年より携わっている新規事業の立ち上げが、恥ずかしながら上手くいっていないので、その反省点を振り返りとともに綴っていこうと思います。
自己紹介
30人規模のIT企業でプロダクトマネージャー兼エンジニアをしています。
Sierから今の会社にはエンジニアとして中途入社して、開発責任者から既存事業の事業責任者を経て、新規事業の立ち上げに従事しています。
今までも既存事業を横展した新規事業の立ち上げは経験してきましたが、既存事業とは関連のないド新規での立ち上げは初めての経験なので日々苦悩してます。
はじめに
本投稿は、あくまでも個人的な反省に基づいてまとめた内容になります。
世間一般に言われる新規事業の立ち上げのベストプラクティスな内容とは異なると思いますがご勘弁ください。
チャレンジしてる事業
トークンエコノミー事業です。
トークンエコノミーについては、ゼロから分かるトークンエコノミーをご覧ください。
今まではトークンエコノミーのプラットフォームを開発して、そのクライアントアプリとしてWebサービスを公開してきました。
このWebサービスは、α版を5月にローンチして、大幅に変更したβ版を8月にリリース、1月10日にサービスを終了しました。
今後の事業としては、Webサービスで得られた情報をもとにトークンエコノミーの仕組みをOEMやASPで展開していきます。
新規事業にチャレンジして感じた留意点
長々と前説してしまいましたが、やっと本投稿の本題になります。
今まで新規事業の立ち上げにチャレンジして感じた反省点や気付きをまとめていきます。
『小さなIT企業での新規事業立ち上げにおける10の反省点』
1. ３つの「ない」が大前提（マインド）
2. マーケットイン？プロダクトアウト？（プロブレム）
3. ペルソナは、遠くの人より近くの人（ターゲット）
4. 紙芝居で確約を得るまで開発禁止（ソリューション）
5. MVPはコアバリューを忘れずに（プロダクト）
6. ピボットの法則を知っておくべし（マネージメント）
7. 最初から有料会員・広告収益はノープラン？（マネタイズ）
8. 良い時こそ、正しい判断が必要（マネージメント）
9. 主観ではなく客観で会話すべし（コミュニケーション）
10. 顧客との接点は確保すべし（その他）
繰り返しになりますが、あくまでも個人的の考えに基づいてのまとめですのでご容赦ください。
３つの「ない」が大前提（マインド）
【反省】
予算（人、物、金）も時間に対する意識が低かったです。
当たり前の話ですが、企業にとって新規事業は投資ですので、時間を掛ければ人件費は嵩みますし、広告を打てば販促費が膨らみます。
その限られた制約に対する意識するが低かったので、『パーキンソンの法則』に陥り、プロダウトで機能を増やす思考になったり、成果が上がらない状況でスケジュールも遅延して、メンバーの熱量も下がり、結果的にグダるプロジェクトになってしまいました。
またマインドとして、自分には「経験（力）がない」と言う事実を自覚することは大事だと感じました。
やはり経験がないと、メディアなどから他人の体験談で情報を得ることが多いのですが、経験を伴わない知識だけが増え、あたかも自分に経験があるかのようなに、あるべき論や正論だけを語る所謂『評論家』がチームに増えていきました。評論家が増えると、評価はするけど、提案がない状況に陥り、チームとしてのスピードが損なわれてしまいました。
マーケットイン？プロダクトアウト？（プロブレム）
【反省】
新規事業では、LINE、メルカリ、Instagramなど誰もが利用するサービスを作りたいと言う思いが強くなります。
でも弊社のような小さいIT企業では、顕在化された大きい市場で戦うには資金がありませんし、画期的なプロダクトで新しい市場（潜在市場）をつくるだけの時間的な余裕もありません。
より不確実性を排除でき、より確実性の高い課題にチャレンジできる小さい市場を探るべきだと感じました。
また「ランチェスター」「PPM」「アンゾフマトリクス」などのマーケティング戦略を正しく使えれば良いのですが、正しく理解して正しく分析できていない状態で中途半端に使っても、社内で体裁を整えてるだけにしか役に立たず、その資料づくりに無駄に時間を割いてしまったのも反省としてあります。
参考）
「機能を売るのではなく、ベネフィットを売る」のは本当に正しいか
ペルソナは、遠くの人より近くの人（ターゲット）
【反省】
ターゲットをよりイメージしやすくするためにペルソナを設定しますが、知らない、知りにくいターゲットではペルソナ設定もあいまいになってしまうので、情報が得やすく、検証が行ないやすい近い存在をターゲットとした方が良いと感じました。
自分から遠いペルソナだと、検証にも時間が掛かり過ぎて、繰り返し検証できる回数も少なくなってしまいますし、ペルソナそのものもが自分たちが望んでいるだけの都合のいいペルソナになってしまいます。
紙芝居で確約を得るまで開発禁止（ソリューション）
【反省】
ここが一番の反省点です。
アイデアベースの企画段階で、事業計画を立て、売上ありきのPL（損益計算書）から逆算してスケジュールを組んでいたので、プロダクト開発にリソースの大半を割いて、本来必要な検証にリソースを掛けることができません。
本来であれば、CPF（カスタマープロブレムフィット）、PSF（プロブレムソリューションフィット）、PMF（プロダクトマーケットフィット）の工程で正しい検証が行うべきですが、検証していない事実に対して「プロダクトに触れてもらわないと分からない！」と正当化して進めてしまっていました。
いくら短期間でプロダクトを開発できたとしても、そもそもの仮説が間違っていると、誰からも求めていないプロダクトになってしまいます。
そんなプロダクトに集客して、ユーザーが登録してくれたとしても、アクティブユーザーにはならず、さらに間違った仮説の上でプロダクト検証を繰り返してリソースを無駄に消費してしまいます。
参考）
スタートアップロードマップ：リーンやグロースハックの概念を俯瞰して整理する
顧客のBurning needsを解決する
MVPはコアバリューを忘れずに（プロダクト）
【反省】
MVP（実用最小限の製品）の機能選定では「コア機能を忘れるな！」と言う反省です。
Webサービスをリリースして、外部の有識者の方に相談した際に「コアバリューは何ですか？」と指摘されました。
そこで改めてプロダクトを見直してコアとなる機能が存在していないことに気付かされました。
事業企画の段階でリーンキャンバスを作成して、差別化ポイントや独自の提供価値を整理していたにも関わらず、MVPの機能選定をコアな機能が漏れてしまったり、α版からβ版でターゲットや課題をピボットしたタイミングでコアがコアではなくなっていました。
参考）
ユーザーに愛されるサービスづくりの話 ～UI/UXデザイン・ユーザー満足度向上の取り組み～
MLP(Minimum Lovable Product)を用いたプロダクトデザイン手法
ピボットの法則を知っておくべし（マネージメント）
【反省】
今回はピボットを2回行い、1回目はターゲット、2回目は課題を変更しましたが、現状の分析や色んな可能性を検証した上でピボットの判断を下したのではなく、悪い状況から回避したいが為のピボットでしたので、ピボットに対する考え方が安易過ぎたと反省しています。
参考）
ピボットとは？ ビジネス的な意味、成功事例、ピボットピラミッド、注意点について
最初から有料会員・広告収益はノープラン？（マネタイズ）
【反省】
ユーザーを獲得できる根拠も不明瞭な状態で、ユーザーが獲得できていることが前提の有益モデルを選択したのはノープランに近かったと反省してます。
計画通りにユーザー獲得ができないと頓挫しますし、ユーザー獲得が広告頼みになってしまっても頭打ちするので、お金にも時間にも余裕のない小さいIT企業には向いていない収益モデルだとと感じました。
良い時こそ、正しい判断が必要（マネージメント）
【反省】
良い時こそ良い原因を正しく分析して正しい判断を行う必要があるという反省になります。
β版をリリースした直後がユーザー獲得も好調だったのですが、「なぜユーザー登録してくれたのか？」「仮説通りに使われているのか？」などの現状分析を怠り、現状のまま継続して良いかの判断をせず、そのまま継続してしまったので、状況が悪化した時には原因を探るのも難しく、手探りで対策を打つ状況に陥ってしまいました。
主観ではなく客観で会話すべし（コミュニケーション）
【反省】
前述の『評論家』にも繋がる話ですが、新規事業では検証や分析が正しく行えていないと、主観での議論が多くなると感じました。
それっぽく話せていても所詮は根拠のない主観なので、主観ばかりでは建設的な議論ができなくなり、生産性が低い時間に生み出していました。
また主観での議論はマウンティング合戦にも発展してしまいます。
自分の考えが正しいと主張するだけで、否定されるとイライラするような状況に陥りました。
α版ではアーティストやクリエイターさんの実際の声、β版では社内インタビューや渋谷でゲリラインタビューを実施して声を集めて、その声を軸に議論するようにしましたが、その他の検証や分析が正しく行えていない状況では、どうしても主観的な会話が多くなってしまいました。
顧客との接点は確保すべし（その他）
【反省】
今回のWebサービスでは、2,000人以上がユーザー登録して頂きましたが、メールアドレスを取得していなかったので、お知らせを送ることもアンケートをお願いすることもできませんでした。
登録だけして離脱してしまったユーザーだとしても、せっかく登録して頂けたユーザーにコンタクトが取れないのは厳しいです。
諸説ありますが、Webサービスではユーザー登録でメールアドレスを取得した方が良いと思います。
まとめ
結局のところ分析と検証が圧倒的に足りていなかったです。
小さなIT企業で新規事業を立ち上げるには、CPFの「顧客の課題は正しいか？」とPSFの「課題に対する解決策は正しいか？」を徹底的に検証して、正しく確証を得られるまでは、下手に進めてはいけないと感じました。
そうなるとCPFとPSFの検証を如何に早く正しく行うかポイントになるので、企業としてはその検証に投資できるかが重要な判断になると思います。
終わりに
長々ととりとめもなく書いてしまいましたが、ここまで読んでいただきありがとうございます。