イノベーション管理SaaSの正しい活用法——プロセス標準化と学習管理を両立させる設計

「導入5,000社」のSaaSから事業が生まれる条件とは

イノベーション管理SaaSの市場は急拡大している。リーンキャンバスの記入機能、ステージゲートの進捗管理、審査員のスコアリング機能、ダッシュボードによる経営報告。数千社が導入し、数万人のユーザーが利用していると謳うプラットフォームが複数存在する。

しかし、一つだけ確認したい。 そのSaaSを導入した企業から、実際に収益を生む事業がいくつ生まれたのか。 導入社数やユーザー数は「ツールの普及度」を示しているに過ぎず、「イノベーションの成果」とは何の因果関係もない。Excelの導入数が経営の質を保証しないのと同じことだ。

SaaSの導入は手段だ。その手段を成果に結びつけるには、運用設計が必要になる。プロセスを標準化すること自体は有効だが、標準化の対象を「管理」から「学習」に転換することで、SaaSの投資効果は大きく変わる。

管理画面の充実度と事業化率の関係を検証する

筆者が内部を見た、ある大手製造業の事例を紹介する。同社はイノベーション管理SaaSを全社導入し、年間120件のアイデアが登録された。ステージゲート1を通過したのが40件、ステージゲート2が15件、最終審査に残ったのが5件。ダッシュボードには「ファネル健全率」が緑色のゲージで表示され、経営報告書には「パイプラインは順調に管理されています」と記載された。しかし、翌年までに事業化した案件はゼロだった。

なぜか。ステージゲートを通過するたびに、アイデアの「角」が削られていったからだ。審査基準に「市場規模の根拠」「収益化の見通し」「既存事業とのシナジー」が設定されており、これらを満たすために起案者はアイデアを「説明可能なもの」に修正し続けた。最終的に残った5件は、誰が見ても「無難」で「論理的」で、しかし誰も熱狂しないアイデアだった。

管理の精度と事業化の確率は、別の変数だ。管理設計を見直す必要がある。

プロセス標準化の特性を理解するための3つの視点

ステージゲートは「平均への回帰」を数学的に内包する

ステージゲート法は、各段階で複数の審査基準を設定し、それらをすべて満たした案件だけを通過させる仕組みだ。この構造は、統計学的に「平均への回帰」を招く。なぜなら、複数の基準を同時に満たすアイデアは、どの基準でも「中の上」のスコアを取るバランス型に収束するからだ。

逆に、ある基準では飛び抜けて高スコアだが、別の基準では低スコアのアイデア——つまり「尖った」アイデア——は、トータルスコアでバランス型に負けて脱落する。UberもAirbnbも、「法規制リスク」の基準では確実に落第していた。ステージゲートは、既存事業の改善プロジェクトを管理するには有効だが、非連続な飛躍を持つアイデアを見落としやすい構造的特性がある。

だから、「尖ったアイデア」を別枠で評価する仕組みを併設しなければならない。

「入力可能」と「検証済み」を区別する

SaaSのフォームにリーンキャンバスの各マスを埋めると、データが「登録」される。この「登録」が、いつの間にか「検証」と同義に扱われることがある。顧客セグメントの欄に「30代共働き世帯」と入力すれば、それはシステム上「定義済み」になる。しかし、その30代共働き世帯に実際に会って話を聞いたかどうかは、SaaSには記録されない。

ツールは「入力の有無」を管理するが、「入力された情報の真偽」は管理しない。結果として、デスクリサーチで埋めた仮説がシステム上は「事実」として扱われ、未検証のデータに基づいてステージゲートが「通過」する。「入力」と「検証」の混同を防ぐ運用設計が、ここで問われる。

管理コストと検証活動のバランスを設計する

イノベーション管理SaaSの導入と運用には、ライセンス費用、初期設定、運用ルールの策定、入力作業、レビュー会議、ダッシュボードの報告と、相当な管理コストがかかる。事務局の工数の大半が「SaaSへの入力と管理」に費やされ、肝心の「顧客に会いに行く」「プロトタイプを作る」「市場で検証する」という本来の事業開発活動に割ける時間が激減するケースがある。

筆者が見た企業では、事務局メンバーの週次工数の60%がSaaSのデータメンテナンスとレポーティングに消えていた。管理ツールが検証活動の時間を圧迫する——本末転倒だ。管理と検証のバランスは、意識的に設計しなければ崩れる。

SaaSを「管理ツール」から「学習ツール」に再定義する

SaaSを捨てる必要はないが、使い方を再設計すべきだ。 まず、ステージゲートの審査基準から「市場規模」と「収益予測」を初期段階では外す。 代わりに「検証した仮説の数」「顧客インタビューの件数」「ピボットの回数」など、学習の進捗を評価する指標を設定する。SaaSは「事業の質」ではなく「学習の速度」を管理するツールとして再定義する。

次に、「入力」と「検証」を明確に分離する。 SaaS上のデータに「仮説」と「検証済み」のフラグを設け、デスクリサーチで埋めた項目と、実際に市場で検証した項目を区別する。未検証の仮説がステージゲートの通過基準にならないようルールを設計する。

そして、SaaSの運用工数に上限を設ける。 事務局の工数のうち、SaaSへの入力・管理に費やす時間を最大20%に制限し、残り80%を顧客開発や検証活動に充てる。ダッシュボードの美しさではなく、検証活動の密度がKPIになるべきだ。

SaaSの運用設計を見直したい人

この記事が切実に刺さるのは3種類の人だ。

イノベーション管理SaaSを導入したが、パイプラインの「見える化」は進んだ一方で、事業化率が上がっていない事務局担当者。 SaaSが事業を生む道具ではなく、事業を「見せる」道具にとどまっていないかを点検すべきだ。

ステージゲートの通過率は高いが、最終的に事業化する案件がない事業開発部門の管理職。 ゲートの審査基準が「平均への回帰」を招いていないか、問い直す好機だ。

SaaSの導入を検討しているが、どのツールが最適か迷っている新規事業推進室。 ツールの選定より先に、「何を管理すべきか」の設計がある。管理対象を「プロセス」から「学習」に転換することが先決だ。すでにSaaSを「学習管理」の目的で運用し、検証活動の密度をKPIとしている組織には、本記事は該当しない。

SaaSのダッシュボードと顧客の声を見比べてみよう

来週一週間だけ、SaaSへの入力作業を最小限にしてみてほしい。その時間を、想定顧客への訪問に充てる。一週間後、ダッシュボードの数字と顧客の生の声を並べてみれば答えは出る。事業の方向性を決めるのはダッシュボードの色ではなく、顧客の反応だ。INNOVATION VOYAGEの「実践フレームワーク」カテゴリでは、不確実性の中で事業を前に進めるための具体的な方法論と実装手順を解説している。合わせて読んでほしい。

参考文献

Robert G. Cooper, Winning at New Products: Creating Value Through Innovation, 5th ed., Basic Books (2017)
Eric Ries, The Lean Startup, Crown Business (2011)（邦訳：『リーン・スタートアップ』日経BP）
Francis Galton, “Regression towards mediocrity in hereditary stature,” Journal of the Anthropological Institute of Great Britain and Ireland, Vol.15 (1886)