SaaSツールでイノベーション管理という幻想——デジタル化が本質的課題を隠す理由

「ツールが変われば行動が変わる」という思い込み

毎年、イノベーション管理ツールの市場は拡大し続けている。アイデアの収集・評価・管理を一元化するSaaSプラットフォーム、新規事業ポートフォリオの進捗を可視化するダッシュボード、社内起業家コミュニティを支援するコラボレーション基盤——このカテゴリの製品に対する大企業の投資は増える一方だ。

しかし、ツールの導入とイノベーション成果の間に正の相関があるという実証的根拠は、ほぼ存在しない。

ツールは行動の容器だ。容器を変えても、中身の行動変容がなければ何も変わらない。

なぜ企業はツールに飛びつくのか

ツールへの投資が繰り返される背景には、組織心理の合理性がある。

ツールの導入は「何かをした」という可視的な証拠になる。経営会議で「今期からイノベーション管理ツールをXXXX社製のものに切り替えました」と報告できる。導入費用がかかれば、それ自体が本気度の証拠として機能する。担当者は「施策を打った」という安心感を得る。

問題は、ツールの導入が構造問題の解決と混同されることだ。アイデア収集のプラットフォームを導入しても、そのアイデアを事業化するための意思決定プロセスが機能していなければ、プラットフォームにはアイデアが積み上がるだけだ。

あるメーカーで実施した調査では、社内イノベーションポータルに蓄積されたアイデアの数は年間で300件を超えていたが、そのうち実際に事業化プロセスに進んだのは2件だった。担当者に理由を聞くと、「アイデアを評価する担当者のリソースがなく、提案したアイデアへのフィードバックが数ヶ月待ち。最近は誰も提案しなくなってきた」という回答が返ってきた。

ツールの問題ではない。評価の仕組みと人的リソースの問題だ。しかしツールを導入したことで、「仕組みを作った」という錯覚が生まれ、本質的な問題が後景に退く。

ツールが課題を隠す3つのメカニズム

メカニズム1：可視化が問題解決を代替する

イノベーションポートフォリオのダッシュボードは、各案件の進捗状況を美しく可視化する。「Explore」「Validate」「Scale」の各フェーズにある案件数、直近の更新日、担当者情報——これらが整然と並ぶ。

しかし可視化は問題解決ではない。ダッシュボードを見て「なるほど、こんな状況か」と理解することと、停滞している案件を前進させることは、まったく別の活動だ。

多くの組織では、ダッシュボードの更新と案件レビューが切り離されており、ダッシュボードは「状況を把握するためのツール」として機能しているが、「意思決定を促すためのプロセス」とは接続されていない。

メカニズム2：量の最大化という逆インセンティブ

アイデア収集プラットフォームの多くは、投稿数・いいね数・コメント数といった量的指標をダッシュボードに表示する。これが担当者のインセンティブを「質の高いアイデアを少数育てること」ではなく「投稿数を増やすこと」に向かわせる。

質の評価は難しく、量の計測は簡単だ。システムが量を可視化し評価すれば、参加者の行動は量の最大化に最適化される。

その結果、プラットフォームには「面白そうだが実現可能性の検討が皆無なアイデア」が大量に蓄積する。評価コストは増大し、評価担当者は疲弊し、システムへの信頼が失われる。

メカニズム3：プロセスの形式化による本質回避

ステージゲートプロセスをツールで管理するケースも多い。「Gate 1通過」「Gate 2承認待ち」という形式的な進捗管理が、担当者の行動を「ゲートを通過すること」に向かわせる。

顧客を深く理解し、仮説を検証し、ピボットの是非を判断する——こうした実質的な活動よりも、「次のゲートに通るための資料を作る」という活動が優先される。

前述の承認プロセスの問題とも重なるが、ツールによる管理が加わることで、この本質回避がより精巧に、より見えにくくなる。

ツールが機能する条件と機能しない条件

ツールを否定しているのではない。ツールが何を解決できて、何を解決できないかを明確にすることが重要だ。

ツールが機能する条件： 情報の整理・共有・記録といった「事務コスト」の削減。コミュニケーションの摩擦低減。分散したチームの同期。これらは本質的に「オペレーション」の問題であり、適切なツールが解決できる。

ツールが機能しない条件： 意思決定文化の変革。リスクへの態度の変容。評価制度が変わらない中での挑戦行動の促進。これらは「文化」と「制度」の問題であり、ツールが届かない領域だ。

端的に言えば、ツールは「摩擦を減らす」ことはできるが、「動機を生む」ことはできない。

「ツール導入前に問うべき5つの問い」

1. ツールが解決しようとしている問題は何か。 「アイデアが集まっていない」のか、「集まったアイデアが評価されていない」のか、「評価されたアイデアが事業化されていない」のか。問題の所在が明確でなければ、ツールは問題を正確にターゲットできない。

2. ツール導入後のプロセスオーナーは誰か。 ツールは維持・運営しなければ機能しない。投稿されたアイデアへのフィードバックを誰が行うのか、週次・月次のレビュープロセスは誰が回すのか。これが決まっていない状態での導入は、使われないツールを生む。

3. ツールが変えようとしている行動は何か。 期待する行動変容を具体的に言語化する。「月1回アイデアを投稿する社員が増える」のか「投稿されたアイデアに経営層がコメントする」のか。行動レベルで定義しなければ、ツールの効果を評価できない。

4. ツール導入なしで小規模に試せないか。 Excelとメールで3ヶ月試して、それでも課題が解決しないならツールを検討する。ツールが解決策に見えるとき、それはツールを求めているのではなく、プロセスの設計を求めているだけのことが多い。

5. 6ヶ月後の成功をどう定義するか。 「導入した」「活用率XX%」ではなく、「ツールを経由して事業化プロセスに進んだ案件数」という事業アウトカムで定義する。

ツールではなく設計から始める

正しい順序は、ツールの選定ではなく、プロセスの設計から始まる。

どんな案件を、誰が、どのタイミングで、どんな基準で評価するのか。評価後の意思決定権限は誰にあるのか。承認後の資源配分のメカニズムはどう機能するのか。

これらが設計され、人と制度がセットになって初めて、ツールは設計を支援する役割を果たす。設計がないまま導入されたツールは、不機能なプロセスをデジタル化するだけだ。

デジタル化は問題を解決しない。ただ問題を見えにくくする。それが、SaaSツール導入がイノベーション管理の解決策として機能しない根本的な理由だ。

参考文献

Liedtka, J. “Why Design Thinking Works,” Harvard Business Review (September-October 2018)
Davenport, T. H. & Westerman, G. “Why So Many High-Profile Digital Transformations Fail,” Harvard Business Review (March 2018)
経済産業省「デジタルトランスフォーメーションを推進するためのガイドライン（DX推進ガイドライン）」（2018年）