 |
||||||||||||||||||
|
||||||||||||||||||
| 1 2 3 次のページ | ||||||||||||||||||
|
||||||||||||||||||
| はじめに | ||||||||||||||||||
|
米国のユーザ企業の情報システム部門には、同じ規模の日本の企業のそれと比べると、約十倍の人数が存在する。ただし、ユーザ企業の情報システム部門とそれに関わるITベンダーの人数を合算すると、日本と米国ではそれほど差がない。 このことから、日本の企業ではいかにうまく外部ベンダーを使いこなすかが問われていることがわかる。 とはいえ、自社業務を外部ベンダーに説明するのはどれほど大変なことか、ユーザ企業の皆さんは経験済みだろう。 また、最初にベンダーから提案された際の期待と、本番稼働後の効果はなかなか合致しないものだ。ソフトベンダーの事例紹介を見ると、△△を導入することによって、どれほどの効果を達成したかという成功例があふれているようだが、実際にやってみるとその通りにならないことは多い。 筆者は、日本のユーザ企業がITベンダーを活用する壁は、以下の3点だと考えている。
表1：日本のユーザ企業がITベンダーを活用する壁
|
||||||||||||||||||
| 外部ソリューションだけではなかなか効果は出ない | ||||||||||||||||||
|
1970年代、アメリカの都市計画学者のリッテル氏は、組織が抱える課題の本質は2種類あると考えた。従順型問題（注1）と、厄介型問題（注2）がそれだ。そして1980年代には、厄介型問題の解決法はソフトウェア工学にもその幅を広げてきた。
表2：「従順型問題」（Tame problem）VS「厄介型問題」（Wicked Problem）
参考："Rational Analysis for a Problematic World Revisted" Johathan Rosenhead, John Mingers）
注1：
「従順型問題」（Tame problem）は、問題点の定義がクリアーに特定され、分析される前に関係者たち（stakeholders）が定義に対して合意することができ、分析する途中に変化なしというような問題だ。関連者以外の分析専門家に情報提供し、隠し部屋で客観的に分析され、結果的に最適なソリューションを関係者に提案することが期待できる。
注2： 「厄介型問題」（Wicked Problem）は、起きている現象に対して各関係者の観点が異なることによって、さまざまな説を立てられ、その説による、異ったソリューションを要求される。ソリューションの評価は関連者以外の外部分析者によって客観的に判断されることができず、関連者たちがそれぞれ主観的に判断し、話し合って部分的に妥協しながらソリューションを決めなければならない。各関係者の行動が複雑な相互の因果関係を持つため、事前にすべての情報を把握して計画するのは非常に困難。本当に論理的なソリューションを立てても、関係者は主観的な理解ができず、計画どおり行動できなければ客観的な効果がでない。 |
||||||||||||||||||
|
1 2 3 次のページ |
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
