『謙虚なコンサルティング クライアントにとって「本当の支援」とは何か｜エドガー・H・シャイン』

https://gyazo.com/6a37eee013d115c8610484fc215a2fd7

クライアントが

問題の複雑さと厄介さを理解し

その場しのぎの対応や反射的な行動をやめて

本当の現実に対処する

この段階にまで至れば、気兼ねなく「医者」の役割を演じ、助言することができるのだ。

プロセス・コンサルテーションが全編に渡ってというわけではない。

「クライアントが語るところの問題」と「その問題を語るところのクライアントが抱く懸念」

後者を語ってもらうためにはそれ相応の関係性が必要

彼らに必要なのは、共通のマーケティング・プログラム（当初語られた問題）ではなく、もっと基本的なレベルでまず互いを知ることだったのである

「内容の誘惑」に駆られることなく、クライアントとの間に生まれるさまざまなプロセスに集中し続けるという逆説的な力

意図的とは限らない解決策を引き出すダイアローグ

コンサルタントとクライアントの双方が、この先の進み方を知らないことを相互に認め合う

診断作業やそれを第三者が行うことによる、時間的情緒的棄損を認める

それだったら、ダイアローグという開放的な関係性のもとで、当事者同士が話し合う方がオーバーヘッドがない

やはり古典はひとつひとつの言葉が力強い

“「人間関係」とは、過去の付き合いに基づいた、互いの未来の行動についての、一連の相互期待のことである”

支援の文脈なので、心理契約的だし、課題ドリブン

片思いは「関係」にならない

関係における非対称性

組織や文化を診断することは、往々にして支援につながらない。

クライアントが語る問題と、クライアントの懸念は一致しないことが多いため。

クライアントの懸念という文脈抜きにしてシステムを分析しても支援につながらない。

分析にはさまざまな切り口があり、どの切り口にするかをクライアントと決めないといけないから。

科学者であることと支援者であることは別

誰かの無知をテーブルの上に出すことが、プロセスに目を向けさせる

自らの無知を利用する

自分の中の「正しい」モデルではなく、目の前のグループが持っている行動計画を見出し、それを達成するよう支援する

全編にわたって耳が痛い

DECでの事例

失敗例が紹介されるので、成功例との対比でもって、何が本当に重要なのかがよくわかる

ITシステムの導入についての事例

/icons/hr.icon