from イノベーションゲーム案 ゲームによって失敗体験をするとよいのではないか、という文脈で、失敗例を列挙
- 確実さを求めることでかえって悪化する、という経験をさせたい
- ポジショニングマップ書いてみて、空白地帯だから突撃したら、需要が無いから空白地帯だった
- 逆に作ったものがレッドオーシャン
- できることベースで作るものを決めた結果、プロジェクト着手段階ではブルーオーシャンに見えたが、並列で多くの人が類似のことに着手しており、完成の頃にはレッドオーシャン
- 製品開発にリソースをたくさんつぎ込んだけど需要がなかった
- 逆に研究開発に成果を求めて失敗
- 論文・特許の量を求める→適切でないKPIに最適化される
- ルールを決めると、ルールの穴を突かれる(特許に報奨金を出すと経営上有益でない特許の量産をされるとか)
- 一方で尺度が明確でない場合に社員が、経営上重要ではないことに時間を浪費してしまう
- 「重要でない」かどうかが識別困難
- 知識の必要性が明確になってから知識獲得に投資しても間に合わない
- 知識への投資をしていないと、環境が変化したこと(新しく生まれた投資すべき知識の存在)に気付けない
- 知識が特定の社員の中にしか保管されていなくて、転職によって失われる
- 新しく生み出された知識を収益につなげるまでのバリューチェーンの構築の失敗
- 分野の変化によって制約条件が変わっているのに、前の分野で作られたルールが独り歩きしている
- 自社ライブラリに依存した資産が多すぎてライブラリを切り替えられないセルフロックイン、ガラパゴス化
- それで高い競争力を保てている間はよいが、周辺技術の進歩などによって「その自社ライブラリを使わなくても、広く調達できる公開ライブラリを使ったもので顧客が十分満足する性能をだせる」となった瞬間に、そっちの方がエンジニアの調達コストなどが安くて競争力を失う。