この記事では、最後は新しい教訓を得て終わる体験学習を含め、読者の皆さんに今考えている事例の判断を仰ぎたいと思います。前回は失敗につながった主な事実を示して終わりました。私はそれを「運用上の原因」と呼びます。当然それらを知るのは大事ですが、次の疑問には答えてくれません：
そもそも、そんな否定的な結果を招いた運用上の原因は、なぜ生じたのだろう？
次のステップ：間違いのあるコアのパラダイムを突き止める
調査チームは、「そもそも何故？」という質問をすべき極めて重要な2つの運用上の原因があると結論付けました。
- そもそも何故、最初の仕様が極めて包括的な表現でしか述べられなかったのか？
- そもそも何故、プロジェクトチームはシステムの「欠陥」を経営陣に報告しなかったのか？
調査チームは、考えられる原因すべてが正当だったかどうかチェックしました。経営トップとプロジェクトメンバーの両方が、その質問に隠し立てせず答えてくれたので、ほとんどの原因・結果は直接的に確認できました。
間接的な検証が必要だったのは、「プロジェクトチームはプロジェクトのビジネス要件を完全には理解しておらず、そもそも何が重大な欠陥か気付かなかった。」という原因でした。それについては、画面を監視する者が誰もいなくても完璧な対外部防護能力を有すことのビジネス／マーケティング上の潜在的価値をプロジェクトチームは理解していなかったので、それが技術的に実現不可能に見えることを彼らはあえて経営陣に報告しなかったことが分かりました。
次のステップ：修正した中心的パラダイムを言葉にする
専門家や科学者、技術者は技術を理解している、しかし多くの場合、それをどうユーザーが使うべきか、市場に対する必要なメッセージ、その他ビジネス的な側面をよく理解していない。
この新しいパラダイムは、TopSecurity社をどう運営すべきかにどんな影響を及ぼすでしょう？
次のステップ：未来ツリー（FRT：Future Reality Tree）を作る
では、この新しいパラダイムを受け入れることで分かる、これから起きそうな結果をいくつか大雑把に描いてみましょう：
修正後の新しいパラダイムから一般的なメッセージへ拡張する
この新しい認識を一般化する方法は少なくとも下記の2つがあります。
- 厳密な言語化は守り続けるが、この事例に特有な運用上の原因を超えた他の影響や結果を探す。
たとえば、新しい製品やプロジェクトのアイデアを立ち上げる方法をどこか変えるのを考えてはどうでしょう？ 会社の事業が最先端の技術を基盤にするものなら、技術的アイデアとユーザーが現在抱える制限とがぴったりマッチすることを保証しなければなりません！ 技術系の人々は、技術の可能性についての優れた直感があります。一方、事業開発に近い人々は、ユーザーの今現在のニーズをよりよく理解しています。
- 「専門家や科学者、技術者」というところを、プロの人々まで範囲を広げて言語化する。会社の事業とその戦略、顧客を獲得したい様々な市場セグメントへの正確なメッセージについてビジネス上の問題をきちんと理解しておく必要性は、会社に勤める様々な人々に当てはまる。
最後のステップ：学んだ教訓を言葉にする
ここで重要なのは、部下が新しいプロセスと新しいパラダイムの背後にあるものを理解し、以前他の人が犯した過ちから教訓を学び取れるようにすることです。
それには以下のものが含まなければなりません：
- 本当のストーリーの要約。
- 問題にしているギャップの定義 － 検討したい議論とその代替案を超える詳細に立ち入らないもの。
- そのギャップの原因となった運用上の事実の要約。
- 誤りのあるパラダイムとそれがどのように問題のギャップを引き起こしたかを突き止める因果関係を示した論理ツリー。
- 新しいパラダイムの言語化。
- 新しいパラダイムから構築される新しいプロセス。
この事例と特に経験から学ぶプロセスの提案に対して、どうかご自由にコメントやご意見をください。
著者：エリ・シュラーゲンハイム
飽くなき挑戦心こそが私の人生をより興味深いものにしてくれます。私は組織が不確実性を無視しているのを見ると心配でたまりませんし、またそのようなリーダーに盲目的に従っている人々を理解することができません。
