WEMEX株式会社 Advent Calendar 2023の21日目の記事です。
※本記事の内容は個人の主観ものであり必ずしも所属する企業や組織の立場、意見を代表するものではありません。

はじめに

本記事はとある「歴史と伝統のある古き良き文化」＋「新規事業にチャレンジする挑戦的な文化」の二刀流な会社における新規事業の開発のお話になります。
技術的な要素は少ないですが、苦労話やエピソードはなるべくリアルな話を書きますのでそこをお楽しみいただけますと幸いです。
今振り返ってみれば良き思い出ですが、荒波に揉まれながらTYR&エラーの繰り返のしんどい日々でした。。、
例えるならばワンピースのグランドライン編のようなイメージでしょうか。

ということで仲間と共に歩んだ航海について備忘がてら綴りたいと思います。

想定読者

新規事業開発に興味関心のあるエンジニア
新規事業開発に興味関心のあるビジネスサイドの方
通りすがりでこの記事に辿りついた方

この記事から得られること

新規事業開発の概要や雰囲気がわかる
新規事業開発について苦労話と学び、つまりナレッジが得られる
1. 目まぐるしく変わるビジネス要件の変更にうまく適応しようとしたけどできなかった事例と学び
2. 予期せぬ問題が起きてもリリース日を厳守しようとしたけどできなかった事例と学び
3. ドキュメンテーションとテストがうまくできなかった事例と学び
4. 関連部署間の調整に苦労した事例と学び

新規事業開発のPoCリード

これまでデータ分析を主戦場としておりWEBシステム開発については「初心者」でしたが、とあるきっかけで小規模の開発プロジェクトのPoCをリードするチャレンジする機会をいただけました。

開発といっても企画フェーズから考えるところからスタートしました。
「ヘルスケアデータを活用した新サービス」という存在するかもわからないワンピースを探すような前線に投げ込まれ、仲間ともに荒波揉まれながら、なんとか目的地にたどり着くことができました。
私のキャリアの中では濃密な1年間でしたのでそこ得られた教訓を綴りたいと思います。

そもそもどんな背景で新規事業やることになったの？

話せば、長くなりますが・・・興味ある人はお付き合いください
※会社の物語に興味がない方はすっ飛ばしてください。

弊社の進化物語：伝統の枠を超えて

5分でわかるWEMEXの進化物語〜

イーストブルー編：古い土壌、新しい風

私が所属する会社は、伝統を大切にしながらも、時代の流れと共に進化し続けています。
5年前まで、新しい取り組みに挑戦する際には様々な試行錯誤がありましたが、それはまた成長への機会でもありました。

アラバスタ編：変化の兆し、新しい仲間とBXセンターの設立と新規事業の推進

時代に適応し更なる成長を遂げるためには
「どげんかせんとあかん」「もっと新しいことに積極的にチャレンジしようぜ！」
という革新の風が吹き始め、令和になったぐらいに革新的な取り組み、つまり新規事業を行うための部門が設立されました。私を含め多くの外部の人材がJOINしたタイミングがその時期になります。

エニエス・ロビー編：アジャイルへの転換、たまに吹き荒れる暴風

新たな仲間と共に風変わりで個性的なリーダーのもと、伝統的な文化からよりアジャイルな文化への移行を図っていました。多様な文化と価値観の中で共通のゴールを目指すことには一定の困難さとチャレンジがあったようです。
一時期は変革期特有の暴風が吹き荒れたそうですが、数年かけて少しずつではありますが今は新しい空気とうまく融合して今風な組織になってきた印象です。

いざ新世界へ：新規事業開発の本格化

ということで、長くなりましたが、ここからが本編となります。

そもそも新規事業開発って何？

３行で説明すると

新規事業開発っていうのは、会社が全く新しい考えや計画を思いついて、それを実際にお金を稼ぐビジネスにすることだよ。
でもね、今の時代はお客さんの好みや必要なものがいろいろあるから、それにピッタリ合った商品やサービスを作ることがすごく大切だよ
そんな中で、MVPっていう考え方が流行ってるらしいよ。これは「最小限できちんと機能する製品」を作るっていう方法で、これを使って、新しいビジネスを始めるときに、お客さんが本当に欲しいものを手っ取り早く見つけることができるよ

MVP（Minimum Viable Product）について詳しく知りたい方は下記を参照ください。

もうちょい説明すると

社内の研修ででリーンスタートアップの研修に参加させていただく機会がありました。
そこでMVPの記載がある書籍を読むと下記のような失敗例が登場し、MVPに必要性について強く説いていました。

「新しいサービスが成功するかどうかなんて誰もわからないし、ものすごい額の投資して大規模な開発をしてドーンとリリースして、結果的に売れませんでした！」

となると会社が傾いてしまう恐れがあるので、そのならないようになるべくお金を掛けずともクイックに新しいサービスが成功しそうか検証する方が理にかなっているのでスモールスタートでやろうぜっというのがMVPです。

恋愛に例えると

恋愛に例えると、相手のことをよく知らないままいきなり結婚するのってリスク高いですよね？程度は違えど考え方は同じですねそれと似ていますね

ってことで比較表にするとこのようになります。

要素	恋愛と結婚	新規事業とMVP
目的	相手を知り、二人の将来を一緒に考えること。	アイデアを試して、それが市場でうまくいくか見ること。
プロセス	デートや会話を通じてお互いを理解し、結婚を考え始める。	アイデアを基本的な形にして早めに試し、人々の反応を見る。
成長	お互いをもっと知り、信頼し合い、結婚へと進む。	市場の意見を聞きながら、製品を良くしていく。
確認	相手と長く一緒にいられるかどうかを確かめる。	製品が実際に役立つか、人々が欲しいかを確かめる。
リスク	うまくいかないこともあるが、お互いを知ることで確かめる。	市場が製品を受け入れないリスクがあり、早期にフィードバックを受けることでリスクを減らす。
成果	上手くいけば、結婚して幸せな未来を築く。	上手くいけば、製品が成長して、会社が大きくなる。

新規事業開発のMVPと一般的なシステム開発におけるQCDの違い

新規事業開発のMVP（Minimum Viable Product）と一般的なシステム開発におけるQCD（Quality, Cost, Delivery）の間には、いくつかの違いがあるようです。これらを比較すると下記になります。

要素	新規事業開発のMVP	一般的なシステム開発のQCD
品質（Quality）	最小限の機能に焦点を当て、ユーザーの基本的なニーズを満たせばOK	総合的な品質管理が重要視され、システム全体の性能、信頼性、耐久性などが考慮される。
コスト（Cost）	なるべくお金をかけずに行う。 ROIよりも仮説の効果検証による学びが重要視される	予算内での開発が重要であり、中長期的なROIが重要視される。
納期（Delivery）	リリースを目指し、なる早で効果検証する。納期はフレキシブルであり、ビジネス事情に応じて柔軟に対応	スケジュール管理が重要であり、計画通りの納期遵守が求められることが多い。プロジェクトのスコープと要件に応じて納期が設定される。

出典：一部生成AIを活用

この比較表から分かるように、新規事業開発のMVPは市場への迅速なアプローチとアイデアの検証に焦点を当てているのに対し、一般的なシステム開発のQCDはより広範な品質管理、コスト効率、および納期の厳守に重点を置いています。

チャレンジの過程とその学び

ということで、新規事業にチャレンジしてみましたが想像以上にうまくいかなかったことが多かったので、後世の反面教師になればいいなと思い事例をなるべくリアルに綴りたいと思います！

どんな新規事業にチャレンジしたの？

ざっくりいうと動画配信サービスになります。
詳しくは書けませんが、一人ひとりにオリジナルな動画をお届けするようなものをイメージしていただければと思います。

1. 目まぐるしく変わるビジネス要件の変更にうまく適応しようとしたけどできなかった事例と学び

課題： 企画を提案しながら開発を同時並行するというスタイルで挑みました。そこで実装中の機能の仕様が、次の週のクライアントミーティングとの企画打ち合わせで大きく変わることがよくありました。PoCを実施させて頂いているいるという立場上、企画を詰める中で合理性のある仕様変更は受けざるを得ない状況でした
学び： 明確な仕様変更の期限を設けて、その後の変更を制限する。顧客要望を鵜呑みにするのではなきちんルールを設けて仕組みで防ぐのがよさそう。

2. 予期せぬ問題が起きてもリリース日を厳守しようとしたけどできなかった事例と学び

課題： 動画配信サービスのリリース日に間に合わせることが必要でしたが、直前にクリティカルな問題が発覚し、納期が1ヶ月程度遅れることになった。1ヶ月前の朝会で一言声かけておけば防げたかもしれないのに・・・という後悔。
学び： リリース判定項目を事前にチーム全体で確認し、暗黙知を減らすことが大切。ビジネスサイドの目線や関心がエンジニアサイドと乖離があるために、指差し確認をすることが事故を防ぐことにつながると痛感。

4. ドキュメンテーションとテストがうまくできなかった事例と学び

課題： 動画配信のコンテンツの中身関わるデータ取得や配信タイミングについての仕様変更が多く、テスト時に正しい仕様が不明瞭でした。タイトなスケジュールの中、課題解決に忙殺されてドキュメンテーションしきれずチーム内でテスト時に正解が何かわかりづらい状況に陥ってしまった
学び： 適切なタイミングでドキュメンテーションをしっかり行い、仕様を明確に保つことが重要であることを痛感。そしてそれができる仕組みが必要。なんとかなるだろうと最低限の人数で開発をスタートすると、不測の事態に対応できないため、PJ開始時に適切な体制を整えることをおすすめします

5. 関連部署間の調整に苦労した事例と学び

課題： 異なる文化や仕事の進め方を持つ部署間での連携に苦労しました。既存事業と連動性があるサービスのために元のデータ仕様や業務知識が前提となることが多く、連携がMUSTでしたがその調整に時間と労力を要したためPMが疲弊した
学び： その部署の人々の立場や目線で物事を深める。また、PJの早期にステークホルダーとはコミュニケーションパスを通しておいて連携しやすい土壌を作っておくことが大事。協力を得やすくなるような人間関係構築もPMの大事な仕事なんだな実感した

最後に

新規事業開発には挑戦が多いですが、それは同時に学びの機会でもあり非常に貴重な経験でした。
最後に私が尊敬する偉人の言葉を紹介したいと思います。

「失敗するなら失敗しきらないと学びはない」
「ノーネガティブ、イエスポジティブ」
Peter O Heita

これからも失敗から学び、今後も成長していきたいます。