この記事は Engineering Manager Advent Calendar 2021（その２） の18日目の記事です。
シナジーマーケティングではいくつかの新規事業開発に取り組んでいます。2021年8月にen-chantリリース時の開発についての記事がありましたが、en-chantと同時期にもう一つ新規事業開発に取り組んでいました。取り組んでいた、と過去形にしているのはすでに撤退判断をしたためです。この記事では、エンジニアリングマネージャー（以下、EM）の私がプロダクトオーナー（以下、PO）として新規事業開発をすることになった経緯や取り組んだプロセス、そしてチャレンジして得た気づきと学びについて書いていきます。
小野寺 俊也（オノデラ シュンヤ）コーヒーが好き
最近のお気に入りは「冷やしピーマン」です。生のピーマンを氷水で一晩冷やしただけで苦味が抑えられて、さらにパリッとした食感もより強くなります。何をつけてもおいしいのですが、一番好きなのは塩です。
目次
新規事業開発をするに至った経緯
はじめに、新規事業開発をするに至った経緯をかんたんに説明します。
私が所属するビジネスクリエーション部では名前の通り新規事業開発をミッションとしています。2020年4月頃に管掌役員から新規事業に関わる技術調査依頼のミーティングがセットされました。このミーティングでアイデアを出してみたところ、POとして事業開発を任せてもらえることになりました。
これまでEMとして働いてきた私が、事業開発にチャレンジしたのには２つ理由があります。
1つはEMとしてメンバーの活躍の場、成長の機会を創りたかったというものです。ありがたいことに私のグループには技術力も一定ありながら事業貢献への意識が強いメンバーが若手からベテランまで揃っており、いま進行中のサービスを3、4年安定して提供できている状態でした。新たな活躍の機会を作り、新しい人を迎えいれながら次の仕事をお願いするようなことをしたいと考えていましたが、当時はいくつか新規事業の種があったもののまだ開発フェーズではなかったため、私も事業開発をすることで開発フェーズに進める可能性を増やせるのではないかと考えたのが１つ目の理由です。
もう１つは個人としての純粋なチャレンジです。同じことをずっと続けるのが苦手な私は機会があればちょっと違う仕事をしてきました。当時はEMになってから3期目で、EMとしてもまだまだ未熟ではありますが、別の領域であるPOにチャレンジしたい思いが勝ったというのが2つ目の理由です。
新規事業開発の顛末
では、どういうことをして、なぜ撤退という判断をしたのか、というのを紹介していきます。
体制
今回の事業開発は私、エンジニア、デザイナーの3人で取り組みました。
最初の事業企画プレゼンまでにやったこと
事業開発を進める最初のマイルストーンとして2ヶ月後の管掌役員プレゼンがありました。どうプレゼンするのか検討もつかなかったため、まずはとにかく世の中の新規事業開発、スタートアップの情報を調べました。幸いなことにいろいろな方がプレゼン資料やその作り方を公開してくださっています。スタートアップピッチの資料をググるとAirbnbなどの海外企業の事例が多く見つかります。ですが、海外企業の事例はどうしても遠くに感じてしまうので日本企業の情報がないか探してみたところ、マザーズ上場企業の「成長可能性に関する説明資料」やTechCrunchのスタートアップバトルイベント、ICCのスタートアップ・カタパルトといったピッチ・コンテストで多くの事例を見つけることができました。最終的に 「Airbnb の初期ピッチ資料は YC の 3 分ピッチテンプレート通り」 に沿って検討・調査をすることにしました。
プレゼンの大筋のイメージができたあとの2週間は、エレベーターピッチやスケッチを書いてあとの2人に壁打ちをするというのを繰り返しました。何度かやりとりするうちに、少し筋の良さそうな仮説ができてきたので社内インタビューを実施して仮説の精度をあげていきました。私以外の2人はUXプロセスの経験があり、あっという間にインタビュー計画ができあがりました。インタビューの結果を受けてアイデアの修正を行い、架空のペルソナをつくりつつメンバー間の認識共有をしました。他にもベンチマークとなりそうなサービスの調査をしたり、仮説検証計画をMVPキャンバスに当てはめて作ったりしました。
どうにか作った資料でプレゼンをした結果、仮説検証を進められることになりました。
仮説検証でやったこと（LPテスト）
いかに本質的な検証をするかが重要、と多くのスタートアップの書籍に書かれていたので私もどんな方法がとれるのかいくつか調べました。（この時点で本質的な検証が重要だとわかっていたつもりだったのに...）
その中で採用したのが、サービスが実在しているかのようなLPをつくり、ウェイティングリストにメールアドレスを登録してもらえるか、という市場の反応を見る検証方法でした。ストーリーマップ、上位下位分析、UXDコンセプトシートなどのコンセプトワークをしながら、どういった訴求にするのか、どうすれば実在するサービスだと思ってもらえるか、検討しました。そして、これらのワークを元に要求と機能を突き合わせて訴求内容を絞っていきました。コンセプトワークは1つ数時間程度で終わるものなのですが、メンバーそれぞれの頭の中にあるイメージは違っていることが多かったのでコンセプトワークを通じてすり合わせるのはとても有効でした。
LPでの検証結果はというと、Twitter広告4万円の出稿でCV 3件でした（CPAは...orz）。これでわかったのはペルソナに近いターゲット層がTwitterにどのくらいいるかというポテンシャルくらいで、他に得られたものはありませんでした。後々ペルソナに近い属性をもつメンバーが1名ジョインしてくれた際に、TwitterよりもInstagramをよく活用していることがわかったので、Instagramで試していたらまた違った学びがあったかもしれません。
蛇足ですが、LPを公開するためにサービス名を考えて商標登録やドメイン取得などもしました。今となっては本質的ではない不要なプロセスだったと反省しています。
仮説検証でやったこと（社内MVPテスト）
今回の新規事業開発ではスマホで使えるツールアプリを作ろうとしていました。今いるメンバーはスマホアプリの開発経験がなかったので、Reactができるエンジニアに加わってもらってReactNative/AWS Amplifyで実現可能性調査を目的とした開発をしつつ、実際に使ってみながらフィードバックをもらえるように社内MVPテストをすることにしました。なんとかReactNativeでの開発ができ、1ヶ月ほど社内MVPテストをしました。アプリならではの仕様に何度もつまづきましたが、結果的にすばやく修正を繰り返すことでテストをやりきりました。
テスト後に実施したアンケートとインタビューから、ユーザーに強い課題・強い要求がないことがわかりました。MVPテストの結果を受けてピボット案を検討していたところ、ふと、既存のアプリを使えば今回のMVPテストと同じ体験の検証ができることに気づきました。すでにあるアプリを使うだけなので社内MVPテストよりもっと早くもっと簡単に。事業開発当初から最小限に、最小限に、と思っていたのにも関わらず、アプリを作って検証してしまっていたのです。もちろん実現可能性の検証をすること自体は良かったのですが、体験の仮説検証自体はもっと早い段階でできたということに気づいたときには内心かなりショックでした。本質的な検証が大事だということは常に意識していたのに、実際にはできていませんでした。
そして撤退判断へ
初期仮説の失敗を受けて別のアイデアをいくつか考えましたが、どれも強いペインではないという結論になりました。また、当初のアイデアがソリューションから考えてユーザーを決めてしまっていたため、ソリューション仮説が外れた状態からピボットすることもできそうにありませんでした。サービスの利用者が一定増えることで成立するビジネスモデルを想定していたのですが、最初のユーザー獲得に対して予算投下したらどうにかできそうだという見込みも立てられませんでした。
振り返り
新規事業としては撤退という結果になってしまいました。それ以上に、新規事業開発のプロセスとしてもかなり失敗してしまいましたが、それでもいくつかの気づきや学びがあったのでご紹介します。
どう仮説を検証するかを考えてすぐ動く
新規事業開発のあらゆる書籍、サイトなど、至るところに「仮説」という言葉がでてきます。事業アイデアを考えているときは作り上げていく楽しさと同時に、本当にこれでいいのだろうかという不安がつきまとっていました。ここで失敗だったのは、アイデアを練り上げるフェーズに多くの時間を使ってしまったことです。もちろんアイデアを考えるには時間がかかってしまうのですが、最初のアイデアの確からしさをすぐに検証できなかったことが問題でした。頭の中でいくら考えて練り上げていっても所詮は自分の頭の中のことなので何一つ進展していないのと一緒なのだと思います。とにかく早い段階で想定ユーザーに持っていくのが大切で、ずさんなモノを見せる勇気が必要だと感じました。どう仮説を検証するかを考えてすぐ動くことの大切さに気づきました。
POは意思決定の連続
世に出したわけではないのでそれほど重要な意思決定はしていないのですが、事業開発は意思決定の連続でした。いままではPOにEMとして情報を渡しつつ最終意思決定をしてもらっていましたが、いざ自分がPOになってみると材料が揃いきらないままに意思決定をすることがとても不安でした。頭ではわかっていたつもりでしたが、POになってみて意思決定の大変さを学びました。
頭の中はかんたんに伝えられない
意思決定をするにあたって自分なりにロジックを組み立てるのですが、その過程は筋が通っているときもあれば、実は四六時中考えているものをこねくりまわしてつなげたものも混ざっていたりします。そして、こねくり回していることはなかなか自覚できないのが厄介で、筋を通して話しているつもりでもなかなか伝わらないということが何度もありました。幸いにしてメンバーがはっきりとわからないと言ってくれるので、齟齬があるまま進むということはありませんでした。こうした状況を避けるために、コンセプトワークはとても有効だと思います。数人が長い時間集まってやるので高コストに感じてしまいますが、ワークを通じて多面的に頭の中をアウトプットしつつ全員で共通認識を作れるのでコスパがいいと思います。
EMがPOとして新規事業開発をする強みと弱み
私がEMからPOになってみて感じた強みと弱みです。あくまでイチEMの例としてご覧ください。
強み
・仮説検証方法の引き出し：これまでの開発経験からどう作れば早くつくれるかというのは考えやすかったです。また、スクラムやMVP開発、UXプロセスなどエンジニアとして学習していたことが新規事業開発でも使えるものが多かったです。
・開発難易度の想定：開発観点での実現可能性の見積もりはこれまでもやっていたことなので、そのまま強みとなりました。
・実装要因：ちょっと開発の手が足りなかったり、LPを作ったり、といった場面で自分も手を動かすことでスピードを上げることができました。
弱み
・社外との関係性の少なさ：BtoBのアイデアについて意見をもらうべく企業にインタビューをしたのですが、私個人としては全くもってアテがなかったので営業社員に協力をしてつないでもらいました。
新規事業開発でPOをやるにあたってはEMだろうが他の職種だろうが、その時々で得意な領域や不得意な領域があるものだと思うので、すぐにヘルプを求めたり、体制づくりで自分の苦手を得意とする人に入ってもらったりするなど、どうにかして取り組むしかないのでしょう。
新規事業開発チャレンジのその後
撤退後、社内で新規事業へのチャレンジを促進するための座談会があり、失敗談として今回の記事に近い発表をしました。当初30分ほどの予定でしたが50分近く話してしまいました。少しでも学びを共有したかったから、というのは言い訳でタイムマネジメントができていなかっただけです。
座談会が終わってから数日後、他部署の方からちらほら開発ではない内容の相談してもらえるようになりました。これまではEMとして開発に関わる話をすることがほとんどでしたが、新規事業開発にチャレンジしたことで開発やEM以外で貢献できるものがあるのかもしれないと思えるようになりました。
この記事全体を通してEMとしての要素はほとんどなかったので最後にEMに関連することを書いて終わろうと思います。 もしPOや新規事業開発にチャレンジするかしないか悩まれているEMの方がいれば、ぜひチャレンジすることをおすすめします。そのままPOとして成功するのも素敵ですし、たとえ失敗してもPOというEMとは少し異なる視点で取り組んだ経験にはきっとEMとして活かせるものがあるはずです。
