完璧なイノベーションの作成者が、必ずしもいちばん稼げるわけではない。むしろ「未完成のシステム」を市場適合させ、販売・運用・規格化・課金といった補完資産を徹底的に積み上げた組織が利益を持っていく。海外事例と理論枠組みを材料に、この逆説を実務目線で解きほぐす。

なぜ「発明者」より「補完者」が稼ぐのか

1986年にデイビッド・ティースが提示した“Profiting from Innovation”は、誰が利益を獲得するかは発明の優位性よりも、補完資産（販売網、製造、標準化、サービス、契約、データ、規制対応）を誰が握っているかで決まると指摘した。さらにジェフリー・ムーアは“Crossing the Chasm”で「ホールプロダクト（顧客が本当に使い切れる一揃い）」の重要性を、クレイトン・クリステンセンは「十分に良い技術」が主流を取る現象を示した。いずれも「技術の完成度」と「稼ぐ能力」は別物だという共通線上にある。

要するに、未完成なコア技術に対して、

  • 補完資産の内製・提携の最適設計（どこを自前で握るか）
  • 反復的な市場検証（PMF→拡張）
  • 配布・販売・価格の最適化（GTM設計） を実装できる組織が収益を最大化する。

海外の具体例

  • Xerox PARC → Apple/Microsoft: GUIやマウスの着想はPARCだが、稼いだのは「ホールプロダクト化」し、流通・サードパーティ・開発者エコシステムを築いた後発。
  • Betamax vs VHS: 画質で勝るBetamaxよりも、録画時間・ライセンス戦略・流通のしやすさで勝ったVHSが市場を取った。技術の“完璧さ”より、補完資産の設計が勝敗を分けた典型。
  • ARM: 自らは製造せず、IPライセンス＋ツールチェーン＋パートナー網という補完資産で稼ぐ。エコシステムが価値源泉。
  • NVIDIA: GPUそのものよりもCUDAを核にした開発者エコシステム、ツール、サプライチェーン調整が収益力の本体。未完成な計算基盤を“使える形”にした。
  • AWS: 既存のホスティングの延長ではなく、API・従量課金・SLA・運用自動化という補完資産パッケージで世界標準に。コア技術の“完成度”ではなくGTMと運用資産で圧勝。
  • Red Hat: Linuxの作者ではないが、エンタープライズ向けに認証・長期サポート・セキュリティ対応・教育・パートナー制度を整備し稼いだ「補完資産企業」。

これらに共通するのは、1) 未完成のコアを「使い切れる」形に仕立て、2) その利用を加速する補完資産（流通・規格・ツール・運用・価格）を握った点だ。

枠組み：稼ぎに効く要素

  • 補完資産の戦略的配置: 何を内製し、何をパートナーに委ねるか。クリティカルパスは握る、非中核は開放してスピードを得る。
  • ホールプロダクト化: 導入、設定、運用、拡張、課金、サポート…「顧客が成功できるまで」を一揃いにする。
  • 配布と規格化: デフォルト化（デベロッパー体験、SDK、CLI、テンプレ）、標準化、互換テスト、認定制度。
  • データ/学習効果: 使われるほど改善するループを設計し、切替コストを“正の価値”として形成。
  • 課金設計: 価値ドライバー（速度、容量、正確性、可用性）に比例し、利用側に最適化される単価体系（従量、階段、席数、ハイブリッド）。

どのように設計すれば「稼げる」か

  1. 問題の再定義から始める
  • 技術起点ではなくジョブ起点（Jobs to be Done）で「顧客が片付けたい仕事」を定義する。
  • 競合は同じ機能の製品ではなく、現状の回避策（Excel、外注、手作業）。
  1. 補完資産マップを描く
  • 導入（テンプレ、マイグレーション、PoCメニュー）、運用（SRE、監視、SLA、トレーニング）、拡張（API、プラグイン、マーケットプレイス）、販売（チャネル、SI、OEM）を棚卸し。
  • クリティカル経路は内製、スピード源泉は外部と共創。契約・収益分配を早期に定型化。
  1. GTMを選ぶ（単一ではなく組合せ）
  • PLG（無料枠→自己獲得→拡張）、Sales-led（案件設計・見積・調達対応）、Dev-first（SDK/CLI/サンプル）、Channel（SI/OEM/代理店）。
  • ファネルの各段で“阻害要因”を潰す：法務、セキュリティ、稟議、会計処理、運用引継ぎ。
  1. 価格とパッケージ
  • 価値軸に連動した従量を基本に、予算確実性のためのコミットプランを用意。
  • 機能ではなく成果（SLA、レイテンシ、スループット、品質）に紐づける。
  1. エコシステムと標準化
  • 互換テスト、自動バリデーション、認定プログラム、ソリューションカタログ。
  • 公式拡張点（Webhook、プラグイン、データモデル）を明示し、非公式ハックを公式化。
  1. 計測と改善ループ
  • 時間価値（TTFV: first value までの時間）、拡張率、有償転換率、NDR、粗利/GPM、LTV/CACを監視。
  • “早く失敗する”ではなく“安く学ぶ”。変更可能性の高い領域から仮説検証。

AI・OSS・Web3での示唆

  • OSS: 「作った人」より「配った人・面倒を見る人」が稼ぐ。Open Core、Dual License、マネージドSaaS、サポート/認定で補完資産を構築。
  • AI: モデル単体の優位は持続しにくい。データパイプライン、評価、観測性、ドメイン適合、オンボーディング、SLA、TCO最適化が差別化源泉。
  • Web3: プロトコルの“完璧さ”より、流動性、ブリッジ、安全な運用、規制対応、FIATオンランプ等の補完でUXを閉じると回る。

つまずきやすい罠

  • 過度な完璧主義: 仕様の完成は顧客成功の十分条件ではない。まずは“使い切れる”最短経路を優先。
  • IP依存の過信: 特許や秘匿だけでは市場は動かない。配布・契約・データの優位性を設計。
  • 閉鎖的エコシステム: パートナーの収益動機を殺すと拡張が止まる。余白を残す。
  • ミスマッチ課金: コストと価値のズレは解約を招く。測れる価値軸に寄せる。

チェックリスト（実務）

  • 顧客ジョブを1文で言えるか？
  • ホールプロダクトのギャップ（導入/運用/拡張/課金/サポート）は何か？
  • 補完資産のうち“握るべき”ものは何か？委ねるものは？
  • 初期配布の最短経路（テンプレ、試用、自己導入）は？
  • 価格は価値に比例しているか？予算確実性は提供できるか？
  • パートナーが稼げる余白は十分か？
  • 学習ループのKPIは定義され、可視化されているか？

技術は価値の核だが、収益は補完資産とGTMの設計で決まる。完璧な発明者である必要はない。「未完成」を前提に、組織として補完を積み上げ、“使い切れる”形に仕上げた者が稼ぐ。