 |
||||||||||||
|
||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||
|
||||||||||||
| 厄介問題の本質 | ||||||||||||
|
「厄介型問題」の本質は、経営や中間管理、現場、IT部門といった複数の関係者グループの異なった考え方、立場および知識を、社内の他のグループや外部コンサルなどがすべて把握することは不可能なことにある。これを解決するためには、関係者たちが主導的にソリューションのモデリングに参画し、各関係者グループが主観的な合意を得るプロセスに重心を置く必要がある。それがなければ、どれほど客観的な分析から編み出された素晴らしいソリューションでも役に立たない。 プロジェクトの種類にもよるが、ITを活用する際のほとんどの課題は「厄介型問題」だ。既存システムの置き換えや現行業務の効率化、業務改革、新ビジネスモデルの実現など、事業部や経営層、情報システム部門のトップ、中間管理職、現場ユーザといった各関係者グループで、共通認識や相互関係の複雑さのレベルが異なる。 一般論として、投資効果が高く期待される「攻め」のITプロジェクトは、未知の領域にイノベーションを起こすものであることから、共通認識のズレが起こりやすい。そのため、関係者グループの間に相互不信が生まれやすく、「厄介型問題」に該当する場合が多い。 ユーザ企業がITを活用できていない大きな理由は、すべての問題を「従順型問題」の解決プロセスで対応しようとする考え方にあるだろう。つまりITが難しいから、IT部門または外部の専門家に任せ、必要な情報だけを提出すればあとは結果を待つだけという形態になっているのだ。 |
||||||||||||
| プロセス自体こそが最も重要な成果物 | ||||||||||||
|
端的な例をあげよう。以前、筆者が経験した大手のSIベンダーのコーポレートWebサイト構築プロジェクトでの話だ。 当時、筆者は外部コンサルという立場で、戦略コンサルが会社のビジネス戦略と競争相手の分析から作成したWebサイトの方針に基づいてプロジェクトを進めていた。その際、ユースケースやサイトのモデル、各ページのデザインメッセージなどの詳細について、全社の各事業部の関係者から異なった要件をまとめる必要があった。しかも、これは同社にとって初めてのWebプロジェクトで、要件が複雑で固めにくい典型的な「厄介型問題」と考えられた。 そこで、基本設計では米国で定着しているJRD（Joint Requirement Definition）という手法を使うことにした。 その第1ステップとして、3日間連続で会社外のホテルに部屋を借り、関係者を召集。共同でWebのモデルをブレインストーミングしながら作成することにした。すると、2日後に広報部の部長がミーティングルームを訪れ、筆者に「あなたたちはコンサルタントでしょう。どうして、わが社の社員にこんな仕事をやらせているのか」といいだした。結局、筆者側の社員と半日掛けて説明したが、関係者たちが参加するプロセス自体が最も重要な成果物だということを、その部長に理解してもらうことはできなかった。 そして、プロジェクトは中断することになった。部長が「従順型問題」の解決プロセス、つまり外部コンサルに情報提供すれば、あとは分析結果を待つ、というやり方しか受け入れられなかったことが原因だった。 |
||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
-
-
連載
