以下のリンクより、本文、コンテンツ内メニュー、または共通メニューへジャンプができます。

ASTD国際会議

ヒューマンバリューは、1992年からASTD国際会議へ視察ツアーを実施しています。本ホームページには、1998年からの参加報告レポートを掲載しています。

W213バージン・アトランティック航空：変革を加速させるためにラーニング・コミュニティをつくる

モリア・ナングル（バージン・アトランティック航空：バイス・プレジデント、
ヒューマン・リソース）、ポール・トルチンスキー（パフォーマンス・デベロップメント・アソシエイツ：パートナー）

主要トラック：組織的文化と変革

ASTDによるセッション紹介文

あなたの変革イニシアチブは過剰な約束や提供不足ではありませんか。内部的抵抗があなたの変革イニシアチブを衰弱させてはいませんか。同様な状態に直面したバージン・アトランティック航空はGE社の「全体規模的変革との練習」を統合する加速型パフォーマンス改善（API）と呼ばれるプロセスを応用しました。過去五年の経過のなかで、バージン・アトランティック航空は士気改善や、流線型プロセス、そして会社中の給与や特典の価値を最大化までするために数々のイニシアチブやエフォートにAPIを応用してきました。バージン社はビジネスの道として彼らの文化にAPIを統合化してきました。これらの原理やツールを応用するトレーニング担当者とその他の人々は、バージン社が変革のための自己維持型の内部基盤を確立することを可能にしました。それは必要とあらばいつどこでもビジョンを持ち、パフォーマンス/プロセス改善を実施する能力を彼らの労働戦力の中に浸透させてきました。

概要（参加者の人数など）

人数は100人ほど参加していた。最初は多かったが、話が冗長でハンドアウトに載っているプロセスのみを話していたためか、人がどんどん抜け、最後の方は30人くらいしか残らなかった。


内容

API導入の背景

6年前に改革を始めた。200の場所に飛ぶ。２桁の成長をしていて、かなり高い成果を上げていた。
Brand Imageは高かった。
1988年にProduct Develpmentが非常に問題となってきた。
Product Developmentはビジネスプロセスとしては見なされていなかった。ツールとして何かつくる必要が出てきた。
また、その際にOwnershipも必要だった。
たとえば、Drive throughというProductを作ろうとしていた。並ばずに飛行機に乗ることができる仕組み。
新しいProductを開発する、プロセスや仕組みが必要だった。

Large Group Methodologyへの注目

Large Group Methodologyという手法について知った。組織中の多くの人を参加させるメソッドであった。
もしかすると、この形なら、問題を解決するためのWisdomがあるかもしれないと思った。
そして、“MAX、MIX of people across the organization.”
このことで、他の人との働き方を変えるべきだという話になった。

APIの導入について

人がどのように関わっているのをMapにし、現状のプロセスマップができるのではないかと思った。
分析できるマップができるのではないかと思った。
まず、リーダーシップチームとプランニングチームを作った（トップのコミットメントが必ずあることが重要であり、方向性を示し、結果を示してもらった）。
人々は変革に抵抗するのではなく、変革をするときに何も知らないところで行われるのを嫌うのである。
そこで、以下の3つのプロセスに関わってもらうことで成功した。

D（Dissatisfaction）×V（Vision）×F（First Steps Planning）＝R（Result）

Plannning Teamは、プロセスをよく知っている人、あるいは、興味や問題意識をもっている人などが含まれていた。
どのように、何を話し合うべきなのかが次に問題になった。この人たちがその活動をデザインするプロセスに関わった。

Planning Teamのフレームワーク

Data（何を知らなければならないのか、何を知っているのか）
Purpose（何のためにやり、何を達成したいのか）
Plan（どのような活動が、Purposeを達成することにつながるのか）
Evaluate（どのように効率性を測るのか）

Eventについて

最初の夜は160人の人が小さなテーブルの周りにそれぞれ10人位ずつに分かれて座った。プランニングチームの人がそれぞれのグループに参加していた。
すべてのテーブルの人から１人、「この会社で働くことはどういうことなのか」というのを話してもらった。その後は、少しFUNを入れて終わった。
外部のマーケットについて話し合ったり、新しいプロダクトの話をしていた。
最初の夜は、Testing the temperature in the room。
次の日の朝、Leadership Teamが変革へのコミットメントをもっている。
うまく言っていることとうまく言っていないようなことを明らかにした。新しいプロダクトの開発について考えることができない感じがした。
Outline Product of New Product DevelopmentのProcessを考えたかった。
新しい製品の開発を行っている、他のビジネスの人を話してもらった。どのようなことをやっているのかを質問したりして、部屋の中に、考える雰囲気を作りたかった。
最後にProcessがうまく行くかどうかをTestしてみた。アクションラーニングに近いプロセスをとった。

成果と他への適応

結果的には様々な成果を出し、この新規開発のプロセス作りに役立っただけではなく、他の場面でも使えると思った。
これらのグループアプローチのプロセスそのものはどのような規模でもできる。
ただし、キーとなる原理は守らなければならない。
Ownershipを作る。
また、ダイアログをできるような環境を整えることで、自然とコラボレーションが出てくる。
Planning Teamはそのうち、Learning Communityに変わってくる。

APIについて

WorkoutはQuick Turnのもの。
大きなスケールのAction Learningのようなもの。

原理

  1. ダイアログを行うフォーラムを作る
  2. 変化する必要性を増加させる
  3. 官僚的構造や階層構造を超える
  4. 従業員やステークホルダーを関わらせる
  5. システムを全体から出す
  6. 何も崇拝すべきものはない（Nothing is Sacred）
  7. マネジメントされたプロセスと意思決定が行われる。
  8. 成功は承認され、コミュニケーションされている。

何がAPIの特徴なのか

問題を探す。
目に見える効果を求める。
シニアマネジメントが直接意思決定を行い、コミットしている。
バウンダリーがない。
変化のためのインフラストラクチャーを作る。

APIのコツ

30・60・90日後にアップデートセッションを作る。
まずは成功事例を作る。
ダイアログをうまくいくようにするために

  • なるべく多様な人を混ぜる
  • 質問によって、色々な観点を出させ、問題を見つけてもらう

問題に関わる人だけを拾うのではなく、組織全体を参加させる。
参加は自由だったり自由ではなかったりした。（自由ではないのは、なるべく多くの多様な人を参加させたかったから。

所見

目新しい部分は特に見受けられなかったが、組織全体を巻き込んだ大規模な問題に対しての取り組みとしては参考となる成功事例であると考えられる。今回の場合は、このAPIを使って何らかの課題や取り組みに多様な視点を取り入れているところが大きなポイントの１つであり、大きな組織的な問題や課題等に対しては、今後は「多様な視点による取り組み」が重要であることをあらためて再認識させられる。

ページトップへ