新規事業に持ち込んではいけない、既存事業の成功法則　実体験から見えた、利益を生まない仮説検証の重要性

「ガチガチの既存事業脳」で新規事業に参加

池谷昌大氏：はい、アディッシュの池谷と申します。よろしくお願いします。ちょっと（スライドの）枚数が多いので、かなりスピーディーに進めます。

アディッシュは「つながりを常によろこびに」という企業ミッションのもと、SNSの目視チェックのサービスやカスタマーサポート、学校向けのネットいじめ対策サービス、SNSの運用代行といったオペレーションのサービスを主に提供している会社です。

クライアントはいろいろなんですけど、最終的に人間の判断が必要な課題について、最適な運用設計をして、オペレーションとシステムで自動化と効率化とを提供するサービスをしています。

最初に自己紹介をさせていただきます。趣味はスティールパンという、ドラム缶からつくられた楽器の演奏をしています。また、「全脳アーキテクチャ若手の会」というAI関連のコミュニティなどに参加しています。

仕事では、チャットボットサービスのプロダクトオーナーを担当しています。自身の経験についてなんですが、営業歴が12年です。ここ2年で、プロダクト開発に関わったというかたちです。ゼロイチの新規事業への初参加と、あとは開発プロジェクトへの初参加、会社にとって初のSaaS事業などがありました。

そこで1番インパクトがあったのが、ゼロイチの新規事業への参加です。既存事業で実績があった人の「落とし穴」に、見事にはまってしまいました。

今日の話ですが、（スライドを指しながら）この「ガチガチの既存事業脳」というのは自分自身のことです。「予測が当たるのが大事」という価値観があって、そこから新規事業を通じて「学習の仕方が大事」という価値観を学び、「新規っぽい進め方」と「既存っぽい進め方」とでモードを切り替えられるようになったというところです。自分たちが学んだ視点を、他のメンバーにも広げられたら、というのが現在のフェーズです。

「（落とし穴に）はまった話」「トライした話」「今後していくこと」「始めたこと」の順にお話をします。共感してもらえそうな人としては、すでに基盤となる事業がある企業で新規事業を担当している方や、新たに作りだす必要のある方、組織の運営や変革に携わっている方を想定しています。

既存事業の成功法則を新規事業に持ち込む危険性

すでにいろいろと経験済みで、「そんなの当たり前じゃない！」と感じた方は温かく見守ってください。この話における「新規事業」と「既存事業」なんですが、「新規事業」はまだ安定的な収益発生の再現性を作れていない事業、「既存事業」は安定的な収益発生の再現性を築けた事業ということで、社内でどちらに認識しているかという程度のザックリした意味合いで使用します。

プロダクトライフサイクル的には「ゼロイチ」とか「イチニ」とかの、まだ不安的なものを「新規事業」と呼んで、「イチジュウ」とか「ジュウからそれ以上」を「既存事業」と呼ぶことにします。

まず、「（落とし穴に）はまった話」なんですが「既存事業でうまくいった視点をそのまま持ち込む」ということをしてしまいました。チームのスタートから2年間の経緯ということですが、1年目は漂流してしまって、2年目はチームの成長という感じでした。

1年目は「わかりやすく漂流した」ということです。まず「スクラムって何？」ってところから始まって、たくぼんさん（注： 合同会社カナタク 代表社員の木村卓央氏）にスクラムを初めて教わりました。それで始めたのはいいんですけど、過去の成功法則から、「有人運用サービスを売るためのツール」ということでスタートしたんです。しかし、想定よりぜんぜんニーズが弱かったということで、漂流してしまいました。

のちにツール提供に方向転換できたのは良かったんですが、その後も個別の顧客要望にいろいろ対応してうろうろしてしまうという漂流が、さらに半年間続いてしまいました。

原因としては、いきなり売上や利益を追い、かえって遠回りをしたってことがありました。当初の価値観として、まさに自分が「ガチガチの既存事業脳」というようなかたちで「利益をすぐに出せないのって、ダメでしょう」っていう価値観とか「顧客のさまざまな機能要望に応じたくなる」みたいな感覚があって、既に事業化できたプロダクトでしか成立しないような感覚を引きずって動いていた面がありました。

「自社の過去の成功法則」とか「強み」から製品開発をスタートしてしまって、いきなり売ろうとしていたという失敗があって、空振りを認識するまでにかなり時間がかかっちゃいましたし、別のアプローチをとるまでにも時間がかかってしまいました。

反省点としては、この場面だと顧客の機能要望に応じるより、顧客の課題と背景を確かめていくとか、学習していくことに専念していくことが1番大事で、あるべき姿でした。残念ながらこの1年目は新規事業のプロダクトの責任者として、適切に機能していなかったなと振り返っています。

「前提」の確認を大事にする

2年目なんですが、「漂流からの脱出」ということで、自分も成長したし、チームも成長しました。（スライドを切り替えながら）「トライした話」ですが、更新されていく「前提」の確認を大事にしました。チームで「新規事業に適したプレースタイル」を得ることができました。

更新されていく「前提」のマネジメントです。ちょっとふわっとするんですが、「前提」というのは、「解決策」以前の話ですね。例えば、顧客ターゲットとか、顧客が置かれている状況とか、最も解決すべき課題とか、目指すべき価値とかです。これを「前提」と呼んだとして、「解決策」っていうのを、実際の解決方法とか機能だとします。

「前提」っていうのは「事実」と「仮定」から成り立っていて、「前提」は「仮定」が何かをしっかり宣言して作るようなかたちでやります。

「既存事業」の場合は「前提」を比較的、固定しやすいかなと思っています。そうするとメンバー内で意識統一しやすいですし、変数となっているものが「解決策」の1個だけで、「解決策」についていろいろスケジュールが変わっちゃっても調整できるでしょう。スクラムの定例でわりと認識合わせができるようなレベル感になるかなと思っています。

「新規事業」の場合は、放っておくと変数が「前提」と「解決策」の2個になるという酷い状況がありまして、もしかしたらよくあることかもしれないんですけど、プロダクトの責任者の頭の中では、情報が更新されて「前提」が変わっているんですけど、それがメンバーの中でちゃんと共有できていないということが起こります。

それでも例えば2人ぐらいだったら大丈夫なんですけど、3人以上のチームになると、たぶんもうタイムリーにわかり合うのは無理です。話がかみ合わない回数が増えるかなと思っています。

メンバーとの情報共有のための工夫

それで理解したのが、「新規事業」は変数の1個である「前提」を仮止めする必要があるなっていうことです。その方策が、例えば可視化。「この前提でやっているよ」っていうのを、見える場所に貼っておくことが必要です。

あとは「前提」が更新された場合、少し変わる場合にも、「前提は少し変わるけど、これで良い？」っていうのを、参加しているメンバーにちゃんと伝えるのが大事だなっていうのを理解しました。この伝達のための表現の時には、チーム外の人に話しても理解できるレベルで言語化するようにしています。

「新規事業」は、限られた時間内でのチャンスメイクの質と量が重要だと思っていまして、社内のステークホルダー、チームメンバー、プロダクトオーナーのどれが崩れても継続できなくなります。わりと、サッカーっぽいなって思っています。

限られた得点チャンスで点が決められないとチームの勢いは下がりやすいですし、時の運を含めてそれが現実だと思っています。限られた時間で、効率よく大胆な実験をすることが必要です。

それで2年目なんですけど、コンセプトを変更し、機能数を減らしてシンプルな利用体験を重視するようにしました。当然、機能数を減らすと失うこともあるんですけど、トレードオフを受け入れて進めました。そうするとやっと得点できた！という感じで、顧客の反応は変わりました。

チーム内、営業のメンバーも含めてその課題はこういった背景で、という話し方をするのが当たり前になり、チーム内の意思疎通のスピードが速まりました。チームが洗練されてきて、変化していく「前提」の認識合わせの重要性をメンバー全員が理解し、それを組織全体へ展開していきたいなという段階になりました。

課題によって「モード」を使い分ける

（スライドを切り替えながら）「今後していくこと」ですが、仮説検証型のチームを増やしたいということと、それを会社の当たり前にしていきたいと思っています。

（スライドを指しながら）雑に、左側が「新規事業」で、右側が「既存事業」だとします。「新規事業」だと探索とか仮説検証の比重が大きくなって、「既存事業」だと確実性とか高い効率に対しての業務が多くなるのかなと思います。

それで「既存事業」ですが、勝ちパターンがわかっている状況の人から見るとけっこう、仮説検証って別に利益を生まないので非効率に見えるんですね。でも一方で実際に、「既存事業」にも仮説検証を重視すべきタスクが一定数あるのかなと思っています。

解くべき問いによって「モードの使い分け」をすることが大事だと思っていて、問いによって最適なモードが異なるということを全員が知っているとか、そのモードの切り替えが可能な人が複数のチームでちゃんと育っているっていう状態にしたいなと思っています。

（スライドを切り替えながら）それで「始めたこと」なんですが、スクラムイベント等の自チームのミーティングへのオブザーバー参加を、全社オープン化しています。1週間スプリントなので毎週やっています。

あと、仮説検証過程を全社オープン化しています。（スライドには）実際のフォーマットみたいなのを貼っているんですけど、『LEAN UX』なんかを参考にして、自社で作りました。仮説検証過程を組織として、組織の学習として残すのが重要かと思っています。

それであとは、焼き肉ランチへの参加も全社オープン化して毎週木曜に行っているんですけど、そういう場でどうでもいい会話をすることも、けっこう大事だと思っています。

最後に、「だからこう言ったじゃない」みたいなセリフは社内から絶滅させたいなと思っています。問題になることは、表面的な知識としては最初から理解しているようなことが多いんです。スポーツの教則本をいくら読んだところでそのスポーツができるようにはならないのと同じように、結局は「実際にやってきた人たち」が本当に理解できるんだなと思っています。

以上となります。ありがとうございました。

（会場拍手）