新規事業はゼロから作らない。OSを替えても価値を残す再発明の技法

その製品は、本当に同じ製品なのか

スマートフォンのOSがAndroidから別のOSへ置き換わっても、利用者は同じアプリを使い続けられるかもしれない。新規事業が既存サービスの置き換えとして始まっても、顧客はそれをまったく新しい製品だとは感じないかもしれない。

この二つは、一見すると無関係な話に見える。片方はソフトウェア基盤の話であり、もう片方は事業開発の話だ。しかし、両者の核心には同じ問いがある。

製品の本質は、その製品を支える内部構造にあるのか。それとも、利用者が受け取る価値と、解決される問題にあるのか。

GoogleのFuchsiaでは、アプリ開発にFlutterというソフトウェア開発キットが使われる。ここで重要なのは、OSが変わる可能性があるにもかかわらず、アプリ開発の接点を共通化できることだ。利用者が見る画面や操作体験を保ったまま、下層の仕組みを入れ替える余地が生まれる。

新規事業でも、似たことが起きる。既存の何かを別の名前で模倣するのではなく、その製品が属するカテゴリ、解決している課題、対象顧客、そしてまだ解決できていない不満を分解する。そのうえで、顧客が価値を感じる接点を維持しながら、内部の仕組みや提供方法を組み替える。

つまり、再現性のある新規事業とは、既存製品をゼロから発明することではなく、顧客に見える契約と、企業側の実装を切り分けることなのだ。

新規事業が属人化する本当の理由

新規事業は属人化しやすい。経験豊富な担当者が顧客の言葉にならない不満を読み取り、既存市場の構造を見抜き、まだ存在しない価値を形にする。その過程は、しばしば本人の勘や人脈や執念に依存する。

しかし、属人化の原因は、創造性が神秘的だからではない。多くの場合、チームが最初から問題を大きく扱いすぎているからだ。「新しい市場を作る」「画期的なサービスを考える」と言った瞬間、観察対象が無限に広がる。何を比較し、何を捨て、どの不満を優先するのかが曖昧になる。

ここで有効なのが、既存の製品を逆向きに説明する方法である。通常のエレベーターピッチは、自社の製品を短く魅力的に説明する。しかし逆エレベーターピッチでは、まず誰かが作った既存の製品を、次のように解剖する。

1. その製品名は何か
2. どのカテゴリに属するか
3. どの課題を解決しているか
4. 誰を対象にしているか
5. どの条件のもとで解決策を提供できるか
6. 何を解決できていないか
7. 顧客は何に不満を持っているか
8. どの決定的な差別化によって置き換えられるか

この手順の価値は、アイデアを出しやすくすることだけではない。既存製品を、完成品ではなく、複数の設計判断が積み重なった仮説として見ることにある。

たとえば、ある企業向けチャットツールが「チーム内の情報共有」という課題を解決しているとする。しかし、その解決は「パソコンを頻繁に確認できる社員」に向いているかもしれない。通知が多く、重要な情報が流れ、後から検索しにくいという不満も残っているかもしれない。

この場合、競合製品を作る出発点は「もっと便利なチャットを作ろう」ではない。より正確には、「情報共有というカテゴリの中で、緊急性の低い情報を蓄積し、後から発見できる状態を作る」という未充足の課題を定義することになる。

問題をこの粒度まで下げると、発想は担当者の才能から、チームで検討できる仮説へ変わる。

OSの変更と事業の再定義に共通する設計思想

OSは、アプリケーションの下にある基盤だ。アプリ開発者は、端末の内部構造をすべて理解しなくても、一定の部品やルールを使って製品を作れる。開発者が依存するのは、OSの細部そのものではなく、OSが提供する機能への接点である。

Flutterのような開発環境は、この接点をさらに抽象化する。画面をどう描画するか、入力をどう受け取るか、異なる環境でどう動かすかという複雑さを、開発者が扱いやすい形にまとめる。下層が変わっても、上層の設計をある程度維持できるようにするわけだ。

新規事業にも、同じく三つの層がある。

1. 顧客が認識する仕事

これは「会議の予定を調整する」「遠隔地のチームに情報を伝える」「購入後の問い合わせを解決する」といった、顧客が片づけたい仕事である。顧客は通常、特定の技術を買いたいのではない。仕事が終わる状態を買いたい。

2. 顧客との接点

画面、通知、営業担当、料金体系、導入手順などがここに当たる。顧客が製品を評価するのは、主にこの層である。使いやすいか、早いか、安心できるか、既存の習慣に入るかが問われる。

3. 企業内部の実装

データベース、組織体制、業務フロー、配送網、機械学習モデル、契約構造などである。競争優位になることもあるが、顧客が直接望んでいるとは限らない。

既存製品を置き換えるとき、失敗する企業は三つの層を一度に変えようとする。顧客の仕事も、接点も、実装も変えるため、顧客は学習コストを負い、社内チームは検証対象を失う。

一方、成功する置き換えは、しばしば次の形を取る。

顧客が慣れた仕事と価値の約束は残し、顧客が我慢している接点と、企業側の非効率な実装を変える。

これは、OSを差し替えてもアプリの体験を維持する考え方に近い。製品の表面をそのままコピーするのではなく、何を互換にし、何を破壊的に変えるかを意図的に決めるのである。

「同じカテゴリ」は、発想を狭めるどころか広げる

新規事業を考えるとき、「まったく新しいものを作らなければならない」という思い込みは強い。しかし、完全な新規性は、顧客にとって理解不能であることが多い。

既存のカテゴリに属することは、弱さではない。顧客がすでに持っている理解、予算、導入目的、比較基準を利用できるからだ。顧客は「これは何か」を学ぶ必要がなく、「なぜこちらを選ぶべきか」だけを判断すればよい。

たとえば、紙の申請書を電子化するサービスを考えるとする。「申請」というカテゴリは既存だ。顧客は申請の必要性を説明されなくても理解している。新しい価値は、申請という仕事を消すことではなく、入力の重複をなくす、承認状況を見えるようにする、入力ミスを減らすといった、既存プロセスの未解決部分に置ける。

ここで大切なのは、未充足ニーズを単なる不満のリストにしないことだ。不満には、頻度、深刻さ、代替手段の有無、支払い意欲がある。顧客が「面倒だ」と言っていても、月に一度しか起きず、手作業で十分なら、事業機会とは限らない。

未充足ニーズは、次の四つの条件で評価できる。

頻度: その問題はどれくらい繰り返されるか。

損失: 放置したとき、時間、売上、信用、心理的負担の何を失うか。

代替の弱さ: 顧客は現在、何でしのいでいるか。その方法はなぜ不十分なのか。

切り替えの容易さ: 顧客は既存の習慣やデータを、どれほど簡単に移せるか。

最後の条件は、特に重要である。差別化が強くても、移行コストが高ければ置き換えは進まない。逆に、機能差が小さくても、既存データを取り込める、操作を覚え直さなくてよい、社内説明が簡単であるなら、顧客は動く。

差別化とは、機能の追加ではなく制約の再設計である

新規事業の議論では、「機能を一つ増やす」ことが差別化として扱われがちだ。しかし、機能は簡単に模倣される。より長く効く差別化は、既存製品が成立するために受け入れている制約を見つけ、その制約の置き方を変えることで生まれる。

既存サービスが安価である代わりに設定を顧客に任せているなら、導入支援を組み込む。既存サービスが高機能である代わりに学習コストを要求するなら、機能を削って初日から使えるようにする。既存サービスがリアルタイム性を重視する代わりに情報が流れてしまうなら、検索と蓄積を中心に設計する。

ここでは、製品を次の式で考えるとよい。

顧客価値 = 解決される仕事の大きさ × 利用される確率 × 継続される期間

機能追加は、解決される仕事の大きさを増やすかもしれない。しかし、利用される確率や継続期間を下げることもある。設定が難しくなれば利用開始率は下がり、通知が多すぎれば継続率は下がる。

したがって、差別化の決定的な理由は「何ができるか」だけではなく、「なぜ実際に使われ続けるのか」で定義すべきだ。

この視点は、OSの移行にも当てはまる。新しい基盤が技術的に優れているだけでは不十分である。開発者が既存の知識を活かせるか、アプリを移植しやすいか、利用者の体験が壊れないかが重要になる。優れた基盤とは、内部を誇示する基盤ではなく、上にある価値を壊さずに新しい可能性を開く基盤である。

事業を発明する前に、互換性の境界を決める

新規事業の初期チームが最初に決めるべきなのは、機能一覧ではない。何を変えず、何を変えるかという互換性の境界である。

この境界を決めるために、既存製品を次の表で整理するとよい。

その後、逆エレベーターピッチを一文に圧縮する。

「この製品は、誰に対して、どの課題を、どの条件で解決している。しかし、誰にとって、どの場面では不十分であり、何に不満がある。私たちは、既存の理解を壊さずに、どの制約を取り除くことで置き換えるのか」

この一文に答えられないなら、アイデアはまだ早い。競合の機能表を作る前に、競合が顧客に要求している我慢を特定するべきである。

そして、検証では「この機能が欲しいですか」と聞かない。顧客が現在どのように問題を回避しているか、最後に困ったのはいつか、何人が関わったか、どれほどの時間や損失が発生したかを聞く。未来の希望より、現在の代替行動のほうが、支払い意欲を正確に示す。

Key Takeaways

1. 新規性を、ゼロからの発明と定義しない。既存カテゴリを起点にし、顧客がすでに理解している価値の約束を利用する。
2. 既存製品を三層に分ける。顧客の仕事、顧客との接点、企業内部の実装を分離し、どこを維持しどこを変えるか決める。
3. 不満を未充足ニーズに変換する。頻度、損失、代替の弱さ、切り替えの容易さで評価する。
4. 差別化を機能数で測らない。顧客が受け入れている制約を一つ見つけ、それを取り除く方法を設計する。
5. アイデアより先に互換性の境界を定める。何をそのまま使えるようにするかが、導入率と事業の再現性を左右する。

最初から完全に新しい製品を作ろうとすると、チームは毎回、未知の市場、未知の顧客、未知の使い方を同時に扱うことになる。これでは、新規事業が属人化するのも当然である。

反対に、既存製品を解剖し、顧客の仕事と接点と実装を分ければ、創造性はより狭い場所に集中できる。どの我慢を取り除くのか。どの習慣を壊さずに済ませるのか。どの内部構造を変えれば、同じ価値をより確実に届けられるのか。

革新的な製品とは、必ずしも新しい仕事を発明する製品ではない。人々がすでに行っている仕事から、これまで仕方なく受け入れてきた制約だけを取り除く製品である。

OSの名前が変わっても、アプリが価値を届けられるなら、利用者は基盤の交代を意識しない。同じように、事業の実装が大きく変わっても、顧客が大切にする仕事がより簡単に終わるなら、それは別物ではなく、よりよい同じものとして受け入れられる。

新規事業を考えるとき、問うべきなのは「何を新しく作れるか」ではない。顧客が価値だと思っているものを守りながら、どの制約だけを大胆に捨てられるかである。再現性は、アイデアを量産する能力ではない。価値と実装のあいだに境界線を引き、その線をチームで何度も引き直せる能力なのだ。