News & Columns

ニュース&コラム

学習する組織入門(9) 「学習する組織の実践事例(2)」

2008年08月06日

自動車部品メーカーUTC社が迎えた危機

「学習する組織」を展開した企業の事例をもうひとつ紹介します。

ハーネスなどの自動車部品や、航空機のエンジンを作るメーカーのユナイテッドテクノロジー(UTC)社は、1990年代大変な危機にさらされていました。大口の顧客から、「今のままでは、取引先を替えざるを得ない」と言われていたのです。

顧客が新車を開発するときに、新しい部品の見積もりを請けますが、UTC社は、見積もりに五〇日間かかっていました。ところが、競合の日本企業が、一七日間でその見積もりを出していたのです。

BPR、コンサルタントの提案導入でも解決に至らず

大口の顧客を一気に失うかもしれない――そんな危機感にUTC社のマネージャーたちは、必死になって対策を図ります。最初に行ったのは、当時流行となっていた「ビジネス・プロセス・リエンジニアリング」(BPR)という手法でした。プロセスの分析に基づき、ITシステムを導入し、プロセスのフローに従って仕事をすることによって、見積もりが大幅に改善できると考えたのです。

このBPRをまず自分たち自身でやってみたところ、当初五〇日かかっていた見積もり日数がかえって増え、六〇日かかってしまいました。焦った経営陣は、「これは外部の助けを借りないといけない」と、BPRで実績のある、外部のコンサルタントを雇いました。

外部のコンサルタントは、マネージャーたちの話を聞きながら情報を整理し、一つの提案にまとめました。コンピュータシステムの導入と併せて、「仕事をこのように設計すべきだ」とプロセスのフローチャートを見せて、「これによって見積もりが大幅に改善できる」と宣言したのです。

経営陣はその提案を受け入れ、全社的な実行を試みました。ところが、実際にそのコンピュータシステムを稼働させて、コンサルタントたちの言ったとおりのプロセスを実行したところ、日数は減るどころか、かえって七〇日に増えてしまったのです。

BPRの落とし穴

経営陣はいよいよ焦りました。BPRの手法を使っても改善できず、その専門家たちを頼ったところ、かえって結果が悪くなってしまっている。顧客には今にも見放されそうになり、困り果ててしまいました。

実は、BPRの八割は失敗に終わっているといわれています。失敗の原因は、プロジェクトの構造にあったのでした。リエンジニアリングはしばしば、ITシステムによる新しいワークプロセスの導入を考えますが、その導入は一見効率的なことを狙っているようでいて、実は人間の内にある変化を見逃しているのです。

コンピュータによって仕事を指図されるのは、人の仕事の楽しみ、面白さを大幅に奪ってしまいます。仕事が面白くなくなった従業員は、ただコンピュータに言われるがままに仕事をするだけに変わっていきます。創造的な仕事は何一つできなくなります。もし、システムの想定外の事態が起こったときに、コンピュータからどうすればいいのかという指示がない限りは、何も新しいことを考えようとしないのです。

さらに、仕事の現場というのは暗黙知に満ちています。そういった暗黙知を知らないまま、ただ形式的な知識だけを持ってプロセスをデザインしても、そのほとんどはうまくいきません。外部から、あるいは経営陣から解決策を与えられる――この構造がすでにリエンジニアリングの失敗を規定していたのです。

「学習する組織」導入:まず、輪をつくって話し合う

さて、いよいよ困り果てた経営陣は、フォードで「学習する組織」を導入したマネージャーに依頼し、一縷の望みを託します。学習する組織のファシリテーターがとったアプローチは、BPRのコンサルタントたちとはまったく違ったものでした。

まず、関係する現場の担当者やマネージャーたちを一堂に集め、みんなで輪をつくって話し合うところから始めます。今何が起こっているのか? どのような傾向があるのか? それがどんな構造から起きているのか? その根本のメンタル・モデルは何なのか? 現場の人たちと対話によって、氷山モデルにしたがって、思考を深めていきます。こうして、なぜ今、五〇日かかっているのか、その構造や自分たちの考え方の前提にどんどん気がついていくのでした。

そもそも、なぜ、こんなに見積もり日数がかかるのか?

たとえば、価格の見積もり日数は、実は年々増えていました。そしてその間、見積もりの質もどんどんと悪くなっています。当然のことながら売り上げは伸びず、顧客との関係や信頼も悪化していたのです。

なぜ、そもそも、こんなに日数がかかるのでしょうか? 当時、UTC社は、極めて機能別の組織となっていました。見積もりを取るにも、エンジニアリング部門、営業部門、品質保証部門など、あらゆる部門がそれぞれ、ばらばらに関与していたのです。しかも、現場の担当者がやった結果に対して、マネージャーやチェック係がいちいちその結果をチェックするプロセスを経ないと、見積もりを出すことができませんでした。この縦割りの組織や、がんじがらめのルールが、見積もりの期間を大幅に、必要な日数以上に延ばしていたのです。

なぜ、このような構造になるのか?

では、なぜこのような構造になっていたのでしょうか? 話し合いでは奥深いレベルまで問いを立てていきます。メンバーたちの話し合いで出てきたのは、「自分たちが自部門の仕事を終えれさえすればいい」というスタンスでした。自分の責任さえ果たせればいいと考えていたのです。

同時に、ほかの部門や上長は担当者に対してあまり信頼をしていませんでした。ちゃんとチェックをしてやらなければ、この人は仕事ができない、という前提ですべてのことを見ていたのです。そこには、適切な情報共有の仕組みも、育てようという意気込みもありません。加えて、ほとんどの人は顧客への対応を重視していなかったのです。その結果、問題が起こると、それぞれの部門は「自分たちはきちんとやっている。ちゃんとやっていないのはほかの部門だ」と言って、責任のなすり合いをしていたのです。

共有ビジョン:「10日間か、それとも廃業か」

真の問題に気がついたチームは、新しいビジョンと目標を設定することにします。「競合が一七日間ならば、一挙に一〇日まで縮めよう。そうでなければ、われわれの未来はない」と考えました。「一〇日間か、それとも廃業か」――これがチームの合い言葉になりました。そうして、どのようにすれば一〇日間が達成できるかについてダイアログを続けます。

こうすればできるというプロトタイプを発見すると、すぐにそれを形にしました。以前のような縦割り意識や、警察のようにチェックするというような意識はもはやありません。顧客の要求に応えるためにはどうすればいいか。それを一丸となって考え、新しい関係性の中でプロセスの再設計が行われていったのです。

"自らの手による見直し"で、見積もり日数が劇的に改善

そのプロセスを実行するに当たっても、ルールやコミュニケーションの仕方、情報共有の仕組みなどについて、大幅な見直しがされました。こうして、学習する組織に基づいたプロセスの、自らの手による見直しが進められていったのです。

自分たちで開発した新しいプロセスの結果は、目覚ましいものでした。当初五〇日、リエンジニアリングをした時には六〇日から七〇日かかっていた見積もりが、学習する組織のプログラムを導入した結果、何と五日間でできるようになったのです。その目覚ましい成果のおかげで、UTC社は顧客とのビジネスを維持し、競合に取られる危機から逃れることができたのでした。

まさに、内発的な動機付けとチームのコミュニケーション、そしてそれを可能にする組織構造がいかに重要であるかを示す事例といってよいでしょう。


関連記事

学習する組織入門(1) 「学習する組織とは?」

学習する組織入門(8) 「学習する組織の実践事例(1)」

学習する組織入門(10) 「学習する組織の実践事例(3)」

関連する記事

Mail Magazine

チェンジ・エージェント メールマガジン
システム思考や学習する組織の基本的な考え方、ツール、事例などについて紹介しています。(不定期配信)

Seminars

現在募集中のセミナー
募集中
現在募集中のセミナー
開催セミナー 一覧 セミナーカレンダー