« RedMineリンク | トップページ | 開発抽象化レイヤーを担う人 »

2007/12/30

ザ・ファシリテーター

ザ・ファシリテーター」という本を読んだ。
メーカーの管理職の女性リョウが新組織のリーダーに着任する時、ファシリテーションを使って組織変革していくというストーリー。

TOCの「ザ・ゴール」に似ている。

内容が非常に興味深かったので、感想を書いてみる。

【1】ファシリテーションとは何なのか?

良く聞かれる質問に対する回答として「会議術の一つだ」というものがある。
だが、それだけではない。
「Facilletate」という言葉には、「助長する」「促進する」というニュアンスも含まれている。

僕は、メンバーの意見を引き出し、自ら聞いた後に、メンバーを動機付けたり、チーム内のコミュニケーションを活性化して、合意形成を導くものだと思う。

この本では、製品開発の知識が無い女性管理職リョウが、部下となる自分より年上の男性メンバーといかに素早く信頼関係を築き、課題を意識付けて、いかにリードするか、というプロセスでファシリテーションを意識的に使っている。

著者の考え方が随所にリョウの口から語られている。
いわく、ファシリテーションは日本人向きだ。協力して合意形成を重んじるので、ディベートで非難し合うのと違うから。
いわく、日本にもQC7つ道具のように昔からファシリテーションの道具を作っていた、と。

確かに、最近流行している理由は、ファシリテーションが内向きな日本人にフィットしている部分が大きいかもしれない。

ファシリテーションの役割を果たすための中心的人物がファシリテーターだ。
リョウは自らを都合ファシリテーターと呼んでいた。

理由は、自分はビジネスリーダーであり、メンバーをリードして結果を出すのが仕事。ファシリテーターは中立の立場にいないといけないのに、プロセスだけでなく、議論し、自らの意見も述べるから、と。

逆にディレクティブ・リーダーが、従来のリーダータイプとも言える。

日本では、集団の和を重んじるという性向があるため、ファシリタティブ・リーダーを好むという特徴もあるのだろう。

【2】会議術として使う

ファシリテーションを使う場としては、会議が多いだろう。

まず、リョウは赴任直後に、リーダーズ・インテグレーションを使った。
つまり、新任リーダーの性格や立場を部下に理解してもらうための質疑応答みたいなもの。
元々は、アメリカで入れ替わりの激しい管理職の導入に使うのが発端だったらしい。

この場面が面白くて、すぐに引き込まれた。
リョウの自己紹介後、リョウは一旦退出して、ファシリテーターの塩崎が会議を先導する。
外部から来た製品開発の経験も無い年下の30代女性リーダーに対する不信感を部室長から本音として引き出す。
その後、リョウが入ってきて、彼らの質問や不信感に対して、プライベートな話にも触れながら、彼らの不信感を解いていき、自らに課せられた責務を解決するための課題洗い出しに彼らの気持ちを引き入れていく。

話がすごくうまく行き過ぎのように思ったが、そこにはきちんとした心理学の理論的背景があった。
「ジョハリの窓」と「4つの懸念」の二つについて、理解するために整理しておく。

リョウは、ジョハリの窓で言えば、プライベートな話で自己開示し、部室長の不信感をフィードバックとして受け取った。
また、リョウは、リーダーズ・インテグレーションで部室長の受容懸念を言語化し、故意に対立を表面化させて、自分の意見を一貫した立場で回答することによって、信頼を築いた。

この2つの概念を意識的に使うかどうかは、確かにファシリテーションによる信頼関係構築の基盤みたいなものだと思う。

ジョハリの窓

ジョハリの窓とは、自分をどのように公開し、隠蔽するか、コミュニケーションにおける自己の公開とコミュニケーションの円滑な勧め方を考えるために提案されたモデル。

人のこころには以下のような4つの領域が存在する。

(1)|(2)
―――――――
(3)|(4)

(1)自分も他人も、よく知っている「公開された窓」
 →Open Self Window
(2)自分だけが知っていて、他人には知られていない「隠された窓」
 →Hidden Self Window
(3)自分では気づいていないけれど、他人には知られている「盲目の窓」
 →Blind Self Window
(4)自分も他人も知らない「未知の窓」 
 →Unknoun Self Window

フィードバック、自己開示で(2)と(3)を縮めていく。

J.R.ギブの4つの懸念
他人との関係を築くために、人は自身の心身を守るために防衛本能が働く。
その懸念が4つある。
その懸念が解消されていく過程は下記の通り。

受容→データの流動的表出→目標形成→統制

これらの過程を通じて、グループもメンバーも成長していく好循環が生まれるという構造になっている。

【3】ファシリテーションに論理的フレームワークは必須

リョウは、社長の目標に対する開発センターの課題を洗い出すために、色んなツールを駆使し、部室長のやる気を引き出していく。
この過程がすごく面白い。

リーダーズ・インテグレーション後、研修所で部室長たちとアクションプランを議論するリョウ。
当然、部室長たちは高すぎる目標に反発する。
でも、本音の議論ができていると感じて意に介さないリョウ。

そして、パレート図、ヒストグラムで会社の現状を説明し、SWOTを使って、会社の長所・短所・対策について話し合い、現実の認識を共有化させる。
SWOTで出てきた課題から、課題と期待のマトリックスにして、アクションプランを作るためのデータを揃えればよいという方向まで持ってくる。

更に、何故課題が解決できないのか、その理由をマインドマップに部室長に書かせるリョウ。
「~できない」ばかり書かれたマインドマップを3日も書かせた後、全てのカードを肯定形に変えて議論し直した。
すると、あら不思議、何を変えなければならないかというアイデアだけでなく行動指針までハッキリしてきた。

リョウはこれを「浮力の原理」と言った。
つまり、「発散→収束→決定」という流れを使って、問題を図式化し、見える化させて、皆のモチベーションを引き出したこと。

マインドマップを議論に使うときのやり方を初めて教わった気がした。

とまあ、他にも色んなツールが出てくるけれど、それらは論理的フレームワークそのもの。
つまり、問題を解決しようとしたり、課題を洗い出す時の論理の枠組みを個人の頭だけでなく、皆の認識方法として共有化させること。
メタ認識とも言える。

例えば、MBAではこういう論理思考ツールが紹介されているが、それらは、MBAを習得した人たちの共通の論理フレームワークでもあるので、MBAホルダーたちでは、ファシリテーションのモデリングツールを意識せずとも自然に論理的に議論できることも意味しているように思う。

IT業界では、UMLやDFDなど、システム分析やシステム設計でお互いの認識を共有し合うモデリング言語が既にある。
それらを一般化したものがファシリテーションのモデリング技術と言えるのかもしれない。


ファシリテーションはコミュニケーション活性化のスキルぐらいしか認識していなかったけれど、問題を図式化して課題を洗い出すプロセスにも使えるという点は非常に新鮮だった。

IT業界では、プロジェクトファシリテーションという概念で更に特化させている。
要注目です。

|

« RedMineリンク | トップページ | 開発抽象化レイヤーを担う人 »

プロジェクトファシリテーション」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/17523575

この記事へのトラックバック一覧です: ザ・ファシリテーター:

« RedMineリンク | トップページ | 開発抽象化レイヤーを担う人 »