2020年に制したいゲーム。コーチングの源流になった『インナーゲーム』を代わりに読む

はじめに

まずは私がこのブログを書いている時、
頭中で鳴り響いた声の数々をご紹介します。

• どうせ誰も読んでくれないよね
• こんな地味なテーマじゃダメだよ
• 46年前の本なんて誰が興味を持つんだ!?
• 最近SNS更新してないから、スルーされるかも...
• 新年感ないね
• 真面目な人って思われないかな
• 詳しい人からがマサカリ飛んでくるぞ
• もっと詳しい解説を誰かがもう書いてるよ、ムダだ
• もっとうまく書きたいな

『インナーゲーム』の用語を使えば、上記のダメ出しや不安な声を絶えず掛けているのがセルフ1で、ダメ出しや不安を受けながら健気にブログを書くのがセルフ2です。
インナー・ゲームとは、このセルフ1とセルフ2が心の中で繰り広げるゲームであり、テニスなどの現実で起こっているアウター・ゲームの対比語です。本書の主張を私なりに一言でまとめると以下となります。

セルフ1を静かにさせ、セルフ2を信頼し任せる

当記事では、大先輩のアジャイルコーチが「原点」ともいうT・ガルウェイの『インナーゲーム』を代わりに読んでいきます。テニスを題材に書かれた本ですが、テニスを知らなくても十分楽しめますし、他のスポーツだけではなく、ビジネスや様々なことに応用可能な理論です。読んでいる途中も素晴らしいと感じましたが、第8章が自身の悩みともリンクしていたことで、私にとってもかけがえのない本の一冊となりました。

インナーゲーム（inner game）とは、勝負において、競技者の外側の世界で実際に行われるアウターゲーム（outer game）に対して、競技者の心中で行われるもうひとつの勝負のこと。テニスコーチのティモシー・ガルウェイ（英語版）が、レッスンを通して考案し、1974年に著作 "The Inner Game of Tennis" の中で発表した考え方。ガルウェイは、心の中のインナー・ゲームに勝つことが、アウターゲーム（実際の勝負）に勝つための近道であるといている。

テニス競技において発案されたものだが、現在ではスキーやゴルフなど他の多くのスポーツの上達に、さらに音楽演奏や、ビジネスにおいても有効であるとされ、ガルウェイによる関連書籍が出版翻訳されている。また、コーチングへの影響も大きい[1]。(Wikipediaより)

新インナーゲーム (インナーシリーズ)

インナー・ゲームとは

インナー・ゲームとは自分を絶えずダメ出しし、励まし、不安がらせる「小うるさい上司」のようなセルフ1と、実際に行動するセルフ2が心の中で繰り広げるゲームです。
私なりに、対比をさせると以下のようになります。

• セルフ1.....思考、意識、大人
• セルフ2.....肉体、本能、子供

これはガルウェイが「いつもいつも、肝心なところで必ず失敗する。お前はダメだ」などの心の中のダメ出しや「ラケットを引くのが遅すぎる」などのアドバイスをすることで逆効果になっていったテニスプレーヤーを見ながら発案した理論で、ダメ出しやアドバイスをする自分をセルフ1、実際に行動する自身をセルフ2と名づけ、セルフ1のダメ出しやアドバイスが(本当はそのままで出来るはずの肉体や本能である)セルフ2が萎縮し、本来のパフォーマンスが発揮できないことから、どうやってセルフ1の思考や批判や激励を静め、セルフ2を活性化させるかという観点からのさまざまなプラクティスが紹介されています。

冒頭でブログを書く私に話しかけるセルフ1の声をご紹介しましたが、テニスに限らず、あらゆる場面でセルフ1が語りかけてくるのを感じます。
みなさんも身に覚えがないでしょうか?

セルフ1が出しゃばる理由

さて、なぜセルフ1はこれほどまでに幅を利かせるのでしょうか?
なぜこれほどまでにでしゃばるのか?
ガルウェイは「我々の文化の根幹部分と、無関係ではない」といいます。

説明の前に、深く共感した文章を引用します。

いわゆる「真剣」なプレーヤーの多くが、このスポーツにのめり込んだ当初の動機如何に関わらず、最終的には上達志向のいずれかのゲームに属するようになる。多くは、週末のいい汗をかきに、あるいは日常のストレスから逃れるためにテニス・コートに通い始めるのだが、次第に自分ではとうてい到達不可能な高い目標を設定するようになり、その結果コートの内でも外でも、継続的な欲求不満や緊張に苦しみ始める。(太字は著者)

さて、上記はテニスに限らず様々なことに当てはまるのではないかと思います。みなさんはいかがでしょうか? お恥ずかしいことに私は当てはまりまくりです。

• 社会人から習っているジャズピアノ、ちょっとした趣味が欲しいという動機が、次第に「このクラスで一番上手くなりたい」や「プロになりたい」などの「自分ではとうてい到達不可能な高い目標を設定」して勝手に苦しんでいました。
• Twitterを最初は仲間との交流や気晴らしに利用していたのですが、次第に「いいねの数」「フォロワー数の増減」などが気になり、有用なことをつぶやかねばと勝手にプレッシャーになっています

さて、私たちがなぜ楽しみや気晴らしで始めた(たかが)テニスのような物事でさえ次第に「自分ではとうてい到達不可能な高い目標を設定する」ようになってしまうか? ガルウェイの考えでは、私たちは「評価されなければ価値がない」という文化圏の中で育っているからです。

競争社会では、愛や尊敬の度合いは勝つことや、ものごとを巧みに成し遂げられるかどうかにかかってくる。ただし、勝者は敗者によってその地位を獲得し、能力が高いという評価は、低い者があって初めて成り立つ。そうなると必然的に、愛や尊敬を十分に得ていないと感じる人々の数は、多くなる。当然、それらの人々は尊敬を得ようと懸命に努力することになり、勝者も、獲得した尊敬を失うまいとさらに賢明になる。だから、(たかが)テニスに上達することが、信じがたいほどに我々には重要になってくる。

この説に、私は深く納得しました。また、私だけではなくとうてい到達不可能な高い目標を設定し苦悩するアマチュア・ピアノ・プレーヤーをたくさん見てきました。

アメリカは極端な競争社会だから、という意見もあるかもしれませんが、私は日本も負けず劣らず競争社会であり、昨今は多様性や働き方改革が言われているものの社会保障への不安や終身雇用の実質的崩壊の不安から、より隠微なカタチで競争が激化していると感じます。

私たちは競争社会から降りるべきなのか?

競争社会が、私たちのセルフ1を肥大化させ、セルフ2が純粋に楽しくやりたかっただけのテニスやTwitterでさえも不健全な上達志向の渦の中に取り込んでいきます。
では、私たちは競争社会から降り、『スター・ウォーズ/最後のジェダイ』のルーク・スカイウォーカーのように引きこもるべきなのでしょうか?
セルフ2だけを静かに育てていけばそれでよいのでしょうか?

ガルウェイの答えは、Noです。

なぜならば、セルフ2は「隠れた自分の可能性を探り」「自分の能力の上限を確認」したい存在だからです。セルフ2は自身の可能性を十分に発揮したい欲求があり、その欲求が一番満たされる可能性があるのは「障害」が大きい時です。お互いの能力の限界を探るための最大の「障害」を与えあうことが競争する意味だとガルウェイはいいます。これは私がこれまで接してきた競争についての矛盾なくかつもっとも美しい定義です。

おわりに

今回は、『インナーゲーム』を代わりに読んできました。
さて新年ということもあり、「健康になりたい」「もっと収入を上げたい」「英語を身につけたい」などの目標を立てた方も多いのではないでしょうか!?(←といいつつこれ私の目標ですね。すみません......)正直これらのアウター・ゲームを制する今までありませんでした。このアウター・ゲームを制するためにも、今年まずは内面で起こるインナー・ゲームを制したいと思っています!

最後までお読みいただき、ありがとうございました!

チームは問題解決を見てはいけない、夢と理想を見る

はじめに

この記事は森さんの素晴らしいブログに触発され、(私は行けなかったのですが)Agile Talks vol.1のセッションで話題に上がった「チームは問題解決を見てはいけない」という命題について私なりに向き合った考察です。

qiita.com

この問いには正解はなく、その人それぞれの答えがあるはずで、そもそも「この考えが間違っている」と考える人もいるでしょう。しかし、非常にいい命題だと思いますので、この場で提起し、アジャイルコーチ・スクラムマスターとしての思考を深めるために皆さんに使っていただければと考えています。

とあるアジャイルコミュニティにてのやりとり

まずはイントロとして、とあるアジャイルコミュニティで「認定スクラムマスター資格を取得したものの、スクラムマスターでない私がどう資格を活かせば良いか？」ということに悩むAさんと私のやりとりです。

私「Aさんはどんな風に資格を活かせると思いますか?」
Aさん「私は下っ端なので、チームのレトロスペクティブのファシリテーションに活かすくらいしかイメージできません」
私「では、あなたがもし権力があり、何をやってもいい立場ならどうしますか?」
Aさん「経営層にアジャイルを浸透させたいです」
私「では、それを踏まえ、今のあなたがそれに向かってできることは何かありますか?」
Aさん「上司に相談する、かな」

問題解決を見ることのデメリット

さて、森さんのブログには以下とあります。

問題にフォーカスすることは悪いことではありませんが、「問題のみ」にフォーカスすることはよい状態ではありません。

今回はさらに、「「問題にフォーカスすること」に問題はないか？」について考えを推しすすめていきます。もちろん「問題にフォーカスすること」はアジャイルの根幹の一つだと思いますし、日々のカイゼンを繰り返すためにはとても有効な考え方です。しかし、経験上、問題も多い考え方です。

「問題にフォーカスすること」の問題

マイナスを0にするだけ

問題にフォーカスすることは、長所を伸ばすのではなく欠点を直す、つまりマイナスを0にするだけに終わりがちです。いわばモグラ叩き。個人もチームも欠点を直しただけでは平均的な存在になれても偉大になることはできません。欠点を直す以上に大切なことは長所を伸ばすことではないでしょうか。さらに欠点はしばしば長所の裏返しなので欠点をやみくもに直すことは長所をなくすことにもつながりかねません。

「問題解決」の根底にある受動性

問題への対策(Try)が、どんなに合理的で納得いくものであってもいつの間にか「やらなくてはならない」という重荷になり、結果やらず仕舞いになるケースを多く観察してきました。スプリント中に対策を実施する時間がないという理由も多いですが、さらに大きな理由は発生した問題に対応するという「問題解決」という行為の根本的な受動性にあるのではないかと考えています。たとえ、ふりかえりがどんなに盛り上がり自ら選んだ対策であっても、多くの場合、チームにとって発生した問題への対応は義務であり、「心からやりたい」という積極的なタスクになりづらいのです。

モチベーションの減退

さらに問題にフォーカスすることの問題点は、問題を見ただけで気分が萎え、モチベーションが減退することです。たとえば、以下はチームビルディング上の問題のサンプルリストですが、見ただけで気分が萎えてしまわないでしょうか？

1. 陰口が多いなどの、部署内の雰囲気の悪さ
2. 責任のなすりつけ合い
3. ほかのメンバーが何をしているのかわからない
4. 問題点が共有できていない

「自分たちで対応できる問題だけを選んでしまう」問題

ここからは「問題にフォーカスすること」の問題ではありませんが、今までさまざまなチームを観察してきて、チームで解決可能な枠内で問題設定をするチームが多いことも問題だと考えるようになりました。

これは組織上力がなかったり、パートナー中心に構成されるチームにありがちな事象ですが「自分たちではどうすることもできないさまざまな問題を深く諦めながら、自分たちで対応できる問題に一生懸命対応する」というマインドセットに陥るチームをよく見かけます。もちろん、これは一見現実的に見えますが、しばらくすると部分的なカイゼンは進み、チームの雰囲気は良いもののプロジェクトが深い停滞感に包まれることになります。

なぜこうなるのでしょうか?

もちろん、組織上の立場、心理的安全性といったさまざまな原因が考えられるものの、最近は根本的な原因は私たち日本人が「組織に従うこと」「自分たちのできる範囲で考えること」「可能性を追求してはならない」ように教育されているからと考えるようになりました。この問題は根深いのでまた別の機会に考察したいと思います。

解決可能な問題にフォーカスし続けた先に待つもの

前項でも書きましたが、自分たちの解決可能な問題解決にフォーカスし続けていると、部分的なカイゼンが進み、チームの雰囲気はよくなるかもしれません。しかしチームは次第に無限の可能性を追求する姿勢と、チームが描く理想の未来に向かっていく姿勢を失っていきます。そして、深い閉塞感にプロジェクトが包まれます。

ゴールにフォーカスすれば良いか?

では、チームは中長期的なゴールにフォーカスし、ゴールを実現するための課題を設定し解決していけばよいのでしょうか?
答えはゴール次第です。
つまり「チーム自らが可能性を追求して設定したゴールであれば」YESであり、「チームが妥協して設定したり、ただ会社から与えられたゴール」であればNOです。
理由は「チームが妥協して設定したり、ただ会社から与えられたゴール」では結局チームは受け身の姿勢になり、モチベーションが減退していき、推進力を失っていくためです。
もちろん現実ではチーム目標が勝手に設定されることも多いと思います。
その場合も、チームが目標について議論を重ね、納得いくまで調整することが大切ではないかと考えます。

チームが見るべきは夢と理想である

「チームは問題解決を見てはいけない」
では、チームは何を見るべきでしょうか?
今の私の答えは「問題解決」を見る前に、「夢と理想」を見るです。

コーチングでは、「組織に従うこと」「自分たちのできる範囲で考えること」「可能性を追求してはならない」という魔法を解くためによく「原因(Why)」ではなく、以下のような問いかけをします。

• あなたは何(What)がしたいか?
• あなたはどんな風(How)になりたいのか?
• もしも魔法の杖があるならば、何をしますか?

そうして引き出された夢と理想には、人を積極的に行動にかりたてる力があると経験してきました。こうしたコーチングで人の可能性を追求する力をチームにも活かせないかと最近よく考えます。自分たちが納得する「夢と理想」を見出したら、あとはそこに対する問題を解決していけば良いのです。

おわりに

今回は考察上、「問題にフォーカス」することの問題点を挙げていきましたが、今後ともKPTに代表される問題解決フレームワークや「カイゼン」などの考え方は重要であり続けます。

しかし、森さんのブログにあるように現状のビジネス環境では「問題解決」や「カイゼン」というだけでは対応することは難しく、個人やチームで「夢や理想を追求し」「課題を創出する」こともまたとても重要になっていくと私は思います。

ただ、昨今の「アジャイル」「スクラム」などで行われるビジネスの多くは、課題創出型です。顧客のより大きな発展のために、顧客に寄り添いながら、少しずつ前に進みながら（漸進的に）課題を見つけていき、企業成長を目指すアプローチ。または、「顧客の顧客」に向けて、市場の「課題」を見つけ、そこに切り込み、大きな利益を生もうとするアプローチ。

今回は、私なりの「チームは問題解決を見てはいけない」の答えを書きました。
もし良ければみなさまの考えもぜひ聞かせてください!

最後までお読みいただき、ありがとうございました!

『組織パターン』プロジェクトマネジメントのためのパターン言語を代わりに読む

はじめに

今回は『組織パターン』第II部から「4.1 プロジェクトマネージャーのためのパターン言語」を代わりに読みます。第II部でパターンの羅列に入ることで、「パターン言語についての概説を読み進めた第I部の興奮がどうか冷めませんように」と祈りながら読みましたが、杞憂でした。第II部もめちゃくちゃ面白い、よかったー! まずは、めちゃくちゃ面白いという以外の「4.1 プロジェクトマネージャーのためのパターン言語」を読み終わった気づきをシェアします。

組織パターン (Object Oriented SELECTION)

• 第I部の感想はこちら

norihiko-saito-1219.hatenablog.com

全体的な気づき

1. 邦題は『組織パターン』ですが、原題『Organaizational Petterns of Agile Development』とある通り一般的な組織論ではなく、"アジャイルソフトウェア開発のための"組織パターンであること(そのため、私自身が無自覚に経験したパターンも多い)
2. 「プロジェクトマネージメントのためのパターン言語」という意味は「どうやってプロジェクトマネージャーがプロジェクトマネージメントをするか」ではないこと。
   1. 「どうやってプロジェクトマネージメントするか」が主題であり、開発者がプロセスの主役で、プロジェクトマネージャーは開発者を下支えすることが役割であること。
3. 本書がスクラムの源流の一つということ

• ※参考 「プロジェクトマネージャーのためのパターン言語」のつながり

最大の制約

さて、前項で本書は「アジャイルソフトウェア開発のための」組織パターンと書きましたが、単なるソフトウェア開発ではなく「アジャイル」がついているのは、本書の背景、さらに私たちの世界を取り巻く最大の制約(フォース)にあるためと思います。それは以下です。

もしスケジュールを緩くしすぎると、開発者は安心するだろうが、マーケットの機会を失ってしまうだろう。だからといって、スケジュールがあまりにきつすぎても、開発者は疲弊してしまい、やはりマーケットの機会を失ってしまうだろう。さらに、スケジュールがきつすぎると、プロアクトの品質が下がってしまう。(p. 40)

私なりに言い換えると、「開発者が疲弊しないように、高品質なプロダクトを、マーケットの機会を失わずにリリースするにはどうすれば良いか？」という制約を念頭におくと、本章のパターンは非常に読みときやすいと感じました。

私なりの要約

というわけで「開発者が疲弊しないように、高品質なプロダクトを、マーケットの機会を失わずにリリースするにはどうすれば良いか？」という制約の下、本章のパターンの構造を乱暴ですが私なりに簡単にまとめてみます。

マーケットの機会を失わないためには、プロダクトを速く開発する必要がある
→ そのために開発者向けのスケジュールを若干厳しくしたり、プロトタイプを作る必要がある
→ 速く開発するためには開発者がプロセスをコントロールするのが一番効率的だ
→ それでも開発スケジュールは遅れる。けれどいちいちリスケしてたら効率的じゃないためリスケは一度にする
→ さらに開発には問題がつきものだ。新人も入るだろう。問題や新人に対応するチームと実プロジェクトを推進するチームに分けるなども工夫のひとつだ。

印象に残ったパターン

さてここからは印象に残ったパターンについて感想を書いていきます。

4.1.1. 信頼で結ばれた共同体

さて、各パターンが機能するために最初になくてはならないいわばスペシャルなパターン、それが「信頼で結ばれた共同体」です。

...いったん組織ができあがると、各メンバーの人間関係がチームの効率に多大な影響を与える。よい影響であることもあれば、悪い影響であることもある。

チーム内の人間が互いに信頼しあうことが欠かせない。そうでなければ、何かをやりとげることは難しいだろう。

これは今年の5月に転職した私にもよーく身に覚えがあります。今は解消したのですが、コンサルタントという職種への一般的な理解もなかったということもあり、はじめの内は同僚や上司と働くのがとても苦しかったです。ちょっとした言動にも敏感に反応し、「あの人は自分を嫌っているのだろうか」と週末まで悶々と悩んだり。今思えば、相手の背後にあるロジックや信念の構造がわからなかったため、信頼が成りたっていなかったと感じます。

なので、信頼がないと疑心暗鬼のため余計な仕事を増やしてしまい効率的ではないというのもありますが、単純に働けなるくらいとてもつらいんですよね。だからこのパターンがあらゆるパターンが成りたつ前提というのはとても納得できます。

閑話休題。

では、「信頼で結ばれた共同体」は具体的に一体どうやって構築するものなのでしょうか？ 著者は言います、「信頼していることを明示的に表現する行為をしよう。たとえばマネージャーは、組織が目標を達成するために自分たちが手助けをしているのだということを、極端なくらいはっきりと示さねばならない」。ここで面白いのは、とりわけ上位層に明示的に相手への信頼を表現せよ、と伝えていることです。

そして部下を信頼しそれを表現することが、従来型のコマンド&コントロール型マネージャーにはどれだけ難しいことか! ということは他社支援をしていて痛感するところです。なのでこちらのパターンは前提ではあるのですが、実際は徐々に適用していくのが現実的かと思いました。組織パターンを適用するためには従来型のマネージャーはマインドセットを変える必要をこのパターンは示唆しているようにも読めました。

4.1.4 名前付きの安定した基盤

ソフトウェアを頻繁に統合して、基盤が陳腐化しないようにしなければならない。ただし、頻繁に統合しすぎて、機能がどのようなものかという共通理解や、育ちつつあるソフトウェアの基盤に対する信頼を損ねてはならない。

それゆえ：
システムのインターフェース(アーキテクチャ)を週に一度は安定させよう。安定したシステムには名前を付けよう。そうすることで、そのバージョンの機能に関する共通理解を開発者たちが指を指して確認できるようになる。

最初に本書を「一般的な組織論ではなく、"アジャイルソフトウェア開発のための"組織パターンである」と先述しましたが、このパターンは典型的です。

先に引用した文章に続けて「その名前に凝る必要はない。たとえば、単純に連番であってもよい。ただし、その名前は覚えやすく、ソフトウェアの正しいバージョンを簡単に指差すことができて、それぞれを簡単に区別できなければならない」とありますが、この文章は若干矛盾しているように私は見えます。著者を責めたい訳ではありません。むずかしいんですよね。連番は覚えづらいし、コードネームは頻繁な変更で崩壊しがちですし...個人的にはあまりうまくいった記憶がありません......

4.1.15 開発エピソード

あらゆる開発に対してグループの活動としてアプローチしよう。全員がそこに取り組んでいるかのようにするのだ。その活動がいわゆるエピソード(物語)の通常の流れに従うようにしよう。意思決定というクライマックスに向けてエネルギーが集められ、そして、発散するのだ。

最初に「本書がスクラムの源流の一つ」と述べましたが、たとえばこのパターンは典型的で、スクラムのスプリントゴールを設定する起源なのではないかと感じました。個人的な経験からも「あらゆる開発に対してグループの活動としてアプローチしよう。全員がそこに取り組んでいるかのよう」になっているチームはフロー状態に入り、生産性が高いだけではなくとても楽しいです。それには物語と、チーム全員で物語を推進している感覚を共有することが欠かせません。

4.1.17 開発者がプロセスをコントロールする

他のあらゆる文化と同様、開発文化もプロジェクトの方向性とコミュニケーションの焦点を認識することで恩恵を受けられる。(中略)なぜなら、開発者たちはエンドユーザーから見える成果物を直接作り出すのであり、プロダクトの説明責任を果たすうえで最善の地位にいるからだ。プロダクト開発において、開発者ほど多くを費やし、また多くのフェーズに関わるロールは他にはない。そして、コントロールができなければ、説明責任を果たせないのだ。
(中略)

それゆえ：
開発者がプロセスに関する情報の焦点にしよう。組織はマーケットに従う(5.1.9)の精神に従い、所定のフィーチャーを作るプロセスのハブとして開発者というロールを位置づけよう。

「開発者がプロセスをコントロールする」というと従来型のマネージメントに慣れている方にはぎょっとするかもしれません。ですが本章を読み進め、「高品質なプロダクトを、マーケットの機会を失わずにリリースするにはどうすれば良いか？」という制約に応えるには、直接成果物を作る開発者が情報のハブとなることがとても効率的なのだと納得できるのではないでしょうか。

もちろん権限と責任はセットです。

著者が「そして、コントロールできなければ、説明責任を果たせないのだ」と責任を強調しているのを看過してはいけないと思います。

おわりに

今回は『組織パターン』第II部から「4.1 プロジェクトマネージャーのためのパターン言語」を代わりに読みました。私が読んで特に面白いと思ったところだけを抜き出し高速で駆け抜けるという『グッドフェローズ』スタイルで書いてるためどれだけ本書の面白さを伝えられているか不安ですが、もし本書に興味が出てきたならば、原書にあたってみることを是非オススメします!

今回は「日本語版への賛辞」からアジャイルコーチの高江洲睦氏の賛辞で締めくくります。私が拙い文章で今回書きたいと思ったことがすでにシンプルな言葉で書き尽くされているからです。

最後までお読みいただき、ありがとうございました!

当然なのですが、すでに現場で見たことがあるようなものが多いはずです。そして、そこからさらに組織をより良くするためのヒントも散りばめられています。ただし、適用前に6章はしっかり読んでください。それから、なによりも一番大事なのは「信頼で結ばれた共同体」です。これなしでは始まりません。
ーー高江洲睦　アジャイルコーチ/プログラマー

はじめてコーチング講座に参加して

はじめに

12月9日から通っている「Deep Coaching -共感コーチング6週間講座」というコーチング講座の初回感想レポートです。Deep Coachingとは、CNVC認定トレーナーのマーサ・ラスレー氏による「NVC（非暴力コミュニケーション）の学びを統合した深いつながりの質をもたらすコーチング」のことです。

nvc-japan.net

NVC（共感コミュニケーション）のもたらす、共感の深いつながりの質。そして、コーチングのもたらす、気づきをうながし明確さをもたらす力。それらを統合することで、NVC・そしてコーチングそれぞれの質が劇的に深化する—。

海外のNVCトレーナーの多くがインスピレーションを受けているプログラム「Coaching For Transformation」をベースとしたこの講座では、NVCの精神性を踏まえつつ、コーチングという新たなエッセンスを深める実践的かつ体感的な学びを提供します。

対象読者

はじめてコーチングを学んだ際の感想を新鮮なままお伝えしたいです。
これからコーチングを学ぼうとされる方やスクラムマスターやアジャイルコーチ、マネージャーの方々も読んでいただけるとうれしいです。

概要

今回は「聴く(リスニング)」を中心に、必要に応じて講師や受講者がコーチやクライアント役を演じながらコーチングの練習をしました。具体的におこなったことは以下です。

1. コーチングの5つの原則からひとつを意識してリスニング/コーチングする
2. 3つのレベルを使い分けてリスニング/コーチングする

ちなみに3つのレベルとは以下のことです。

1. 自分自身にフォーカスした聴き方（Self-focused listening）
2. クライアントにフォーカスした聴き方（Client-focused listening)
3. 変容にフォーカスした聴き方（Transformation-focused listening）

これまでもNVCワークショップでディープリスニングを体験したのですが、3つのレベルを意識しながら聴くことで、これほど意識的に「聴く」ということを体験したのははじめてでした。

「聴く」という日常的な行為に目を向け、光をあてることの新鮮さ

今回の演習ではふだん無意識にしていた「聴く」という行為を、相手の言葉やニュアンスやエネルギーを、また、自分自身に生まれる反応をひとつひとつ味わいながら行いました。その結果、世界にあらたな光があたり、目の前にあったけど見えなかったものが浮かびあがるような感覚を覚えました。

いかに私が無意識に自分にフォーカスして聴いているか

そしていかに私が自分にフォーカスして他者の話を聴いているか(=つまり、他者の話を聴いていないか)に気づかされました。今回の演習ではたまたま相手が、私もとても強い関心があることを話していたため、その際「わかる!」「自分のエピソードも話したい!」という感情で心が埋めつくされるのをはっきり自覚することができました。

コーチングにおいて自分自身にフォーカスすることの重要性

ちなみにコーチングにおいて自分にフォーカスしながら聴くことが悪いように誤解されせてしまったかもしれませんが、自分にフォーカスすることは悪いことではなく、むしろ大切なことだと考えています。短い演習でも、自分自身に生まれた素直な感想(e.g. さっき声が大きくなりましたが、ここは大切ではないでしょうか?)や浮かんだメタファーを伝えることは相手にとっても役に立つことが多いと実感することができました。

重要なことは「意識」して聴くこと

前項で自分にフォーカスしながら聴くことは悪いことではない、と書きましたが、ではコーチングにとってよくない聞き方は「無意識」に聴いてしまうことだと感じました。コーチングにおいて重要なのは「意識」して聴くこと。さらに、自分自身、クライアント、変容に同時にフォーカスできたり、フォーカス対象を素早く切り替えたりできることが必要になってくるのだと考えています。

自分の言葉のインパクトに注目する

私はつい、本業でもプライベートでも的確な言葉や質問を投げかけたいと思ってしまい、的外れという反応を相手が示すと凹んだり動揺してしまいがちですが、コーチングで重要なのは自分の言葉が相手にどのようなインパクトを与えるかを観察することと教わったのはとても新鮮でした。正解を探す、のではなくそれが正しかろうが間違っていようが、自分の言葉が相手にどのようなインパクトを与えたかどうかを観察して、それをもとにコミュニケーションを続けていく。こちらが間違ったことを話してしまっても、それが相手が正しさを発見する手掛かりになればそれで良いのです。(とわかっていても難しい.....)

(おまけ)アジャイルコーチングと一般的なコーチングのちがい

今読書会で読んでいる『Coaching Agile Teams』でも個人の可能性を追求することはアジャイルチームの目的を覆い隠してしまうため、一般的なコーチングの意図をアジャイルコーチングに全て持ち込むことはないという旨の記述があります。
これは私もよくわかります。個人の可能性を追求する個人へのコーチングと、常にカイゼンし良いプロダクトを届けることを追求するアジャイルチームへのコーチングは同じ「コーチング」でもかなり毛色が異なる活動と言えます。
...ただし、全く無関係かといえばそうではないと思います。こちらについては時間があるときに別途考察します。

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

we don’t bring the full intent of work/life coaching to agile teams because pursuing each person’s individual agenda would overshadow the purpose of an agile team

おわりに

散漫になってしまいましたが、コーチング講座をはじめて受けた感想です。これからもコーチング講座については引き続きシェアしていきたいと思います。
先生もコーチングテクニックを増やすことは「お手玉を増やす」ようなことで、一個ずつテクニックを参考にしたり盗んだりして行けばよい、とおっしゃってました。大切なのは、日々の練習と、一緒に練習する仲間がいることなのはアジャイルもNVCもコーチングも同じです。
もし一緒に練習したい、という方がいればぜひ声をおかけください!
最後までお読みいただき、ありがとうございました!

『組織パターン』第1部を代わりに読む(パターンは疎結合、スクラムは密結合)

ずっと積読していた『組織パターン』を読み始めた。
難解でもあるが、なんて楽しくエキサイティングな本だろう。

組織パターン (Object Oriented SELECTION)

エキサイティングなのは本書のテーマが私の関心領域である組織変革ということだけではありません。本書ではパターン言語やソフトウェアアーキテクチャ、文化人類学に社会学といったさまざまな事柄が高度に統合されており、様々なインスピレーションを与えてくれるからです。

今回も敬愛する友田とん氏の『『百年の孤独』を代わりに読む』にならって、本書をちびちびまとめながら、読みながら思い浮かんだインスピレーションを書いていこう。ですので、正確なまとめを期待する読者のみなさまには先に謝ります。今日は「第一部 歴史と導入」から、パターン言語やスクラムについて思うところを書いていきます。

seikosha.stores.jp

パターンとライブラリ、パターン言語とフレームワークの共通点と相違点

本書を読んで、私はパターンをプログラミング言語におけるライブラリと、パターン言語をフレームワークとそれぞれ対比させて理解しました(比較対象として適切かどうかわかりません......!)。

まずは本書で示される「パターンについての短い、それゆえ必然的に不完全な定義」を引用します。

繰り返し発生する構造的な形で、あるコンテキストにおける問題を解決するもの。なんらかの全体の全体性あるいはシステムに寄与し、美的あるいは文化的な価値を反映する

共通点

独立した問題に対する解決策という意味でパターンとライブラリは近く、複数の解決策を組み合わせることでひとつの構造を作るという意味でパターン言語とフレームワークは近い。

相違点

ただし、多くのライブラリがコンテキストに依存しない汎用的な解決策を指向するのに対し、パターンはある特定のコンテキスト下で発生する問題に対する解決策であるという点が異なる。
また、フレームワークが組み合わせる解決策が強く規定されていのに対し、パターン言語は組み合わせる解決策について、示唆はされるものの基本的に利用者にゆだねられている点で異なっている。
また、フレームワーク中の解決策同士の依存性は高く、ひとつの解決策を除去するとフレームワークとして成りたたなくなるが、パターン言語内の各パターンは独立し相互依存性が低いのも異なっている点である。

上記した"コンテキスト依存"であることがフレームワークとパターン言語を大きく分かつと著者は感じる。フレームワークがもたらす構造は静的であることに対し、パターン言語がもたらす構造は動的である。複数のパターンの組み合わせ方はコンテキストに依存するが、パターンを適用したり追加すると、そのコンテキスト自体が変化するからだ。

パターンは疎結合、スクラムは密結合

前項で「パターン言語内の各パターンは独立し相互依存性が低い」と書いたが、本書に以下の言葉がある。

適用に際して、パターンは疎結合なのだ

これを読んで、私はまっさきに「パターンは疎結合、スクラムは密結合」という言葉が浮かんだ。私の観測範囲では最近スクラムに対する批判が多いが、上記が批判のひとつの根拠になっていると感じる。つまり、スクラムのイベント、ロール、成果物といった構成要素が密結合すぎて、現実に変化していくコンテキストににうまく対応できないという問題である。(もしかしたら上記問題を解決するためにスクラムをパターン言語に再構築する試みが「スクラムパターン」であり、その集積が『A Scrum Book』かもしれませんが、著者はそこまでわかっていません)

A Scrum Book: The Spirit of the Game

疑問

本書でパターン言語は「パターンを組み合わせるための構造」と定義されますが、その際いくつかの疑問が浮かんできます。
ただし、これは本書を読んでいく中で解消されると想定されますので、期待を持って読んで行こうと思います!

• あらかじめ何らかの構造が想定されているのか？　それともパターンを組み合わせることで構造が生じるのか？
• あらかじめ何らかの構造が想定されていない場合、パターンを組み合わせる際はどのような指針で組み合わせればよいのか？
• パターンがもたらしたコンテキストの不具合やフォースを解決するために別のパターンを適用していったら「ツギハギ」の構造になってしまわないか？

まとめ

というわけで、今日は「第一部 歴史と導入」についてライブラリやフレームワークと対比させながらパターン言語をまとめ、スクラムについても言及しました。
他にもいろいろ書きたいと思うことは多いのですが、残念ですが時間切れです。
今後もちょくちょく『組織パターン』についてこんな感じでまとめて行きたいと思いますので、ご興味ある方、楽しみにお待ちください!

最後までお読みいただき、ありがとうございました!

「あー、それわかる〜!」は共感か？ NVCにおける「他者共感」を考える

はじめに

NVC(非暴力コミュニケーション)における他者共感について語る前に、私がNVCに触れる以前に私が「他者に共感する」際にやっていたことを言語化してみよう。
一言でいえば、私は、自分の経験や心理学的知識を動員させ、相手の感情にマッチング(当たりそう)しそうな感情を探していた。
相手の感情が見つかったら、「わかる〜!」といって自らの経験を語りだした。

簡単な例をあげよう、

• 妻「上司の話が長くて、しかも話があっちこっちに飛ぶから、何を言っているかわからない」
• 私「わかる〜! 辛いよね。自分の上司もさ......(自分の上司について語り出す)」

さて、上記は何が間違っていたかがわかるかい？

素晴らしい。すべて間違っている

『スター・ウォーズ／最後のジェダイ』よりルーク・スカイウォーカーの台詞

ーーNVC的観点からいえば上の短い会話の中で3つも間違っている。

1. 相手よりも自分にフォーカスしていた
2. 相手の感情が「わかる」と思い込んでいた
3. 相手の感情を「当てよう」としていた

※NVCを知る以前の他者共感のイメージ

NVCにおける他者共感とは？

さて、NVCにおける他者共感とは、「相手の感情を"推測"することである」。

ちょっとまって、最初の例と同じじゃないか、と思ったかもしれません。
けれど、字面は一緒だけど大きくちがうのです。
前項に挙げた3つの誤りと対比させて、NVCにおける共感の特徴をあげます。

1. 相手にフォーカスする
2. 相手の感情は「わからない」ことを認める
3. 相手の感情を「当てない」

相手にフォーカスする

前項で私が共感している際に「自分の経験や心理学的知識を動員させて」と書きましたが、その瞬間、相手へのフォーカスが外れていることに以前の私は気づいていません。

ワークショップではその状況を「懐中電灯を相手から自分に向ける」と表現されていました。もしあなたが相手に共感したい際は、相手に対して懐中電灯を向けつづけること、「わかる〜!」と言って無自覚に自分に懐中電灯を向けてしまうことに注意する必要があります。

個人的には、他者に共感する上で自分の類似経験を探すことや心理学の知識で分析することよりも「相手に懐中電灯を当てつづけること」がはるかに役にたったと実感します。

マーシャル・ローゼンバーグ(NVCの創始者)は共感について語る際、「言葉を聞くな、ハートを聴け」と語っていたそうです。

相手の感情は「わからない」ことを認める

NVCを習う中で、相手を共感する際に「その人のことは、その人にしかわからない」「相手の感情は「わからない」」「相手には相手の世界があることを尊重する」ことが繰り返し強調されました。

「その人のことは、その人にしかわからない」......当たり前のように聞こえるかもしれませんが、当時の私にとっては共感のイメージを大きく覆すほどショッキングな一言でした。

相手の感情を「当てない」

「その人のことは、その人にしかわからない」......では、NVCではどのように、そしてなんのために相手に共感するのでしょうか？

具体的には、相手に懐中電灯を当てつづけ＝感情を聴きつづけて浮かんだ言葉を「イライラしていますか？」「悲しいでしょうか？」とYES/NOで答えられるような疑問形にして相手に伝えます。

これは、「その人のことは、その人にしかわからない」という尊重からです。
相手の感情を「当てたい」からではなく、相手が相手の感情に気づく手助けをしたいから、という意図がそこにはあります。

※NVCにおける他者共感のイメージ

おわりに

今回はNVCにおける他者共感について語りました。
参考になる部分が少しでもあれば、とても嬉しいです。
さて次回はいよいよ、私が本当に書きたかった「NVCにおける自己共感」について語っていきます! お楽しみに!

最後までお読みいただき、ありがとうございました。

問いかける際のたったひとつの冴えたやり方〜『問いかける技術』を読んで感じたこと

NVCにハマっていると言ったら「これもいいかもよ」と先輩に教えられたエドガー・H・シャインの『問いかける技術』を読んだので、感想や感じたことをつらつら書いてみます。

問いかける技術――確かな人間関係と優れた組織をつくる

はじめに

コーチという仕事をしていると一方的にアドバイスするのは逆効果であることが多く、「問いかける」方が適切な場面が多い、ということが直感的にわかってきました。
しかし、具体的にどのように質問をすれば良いかがわかりませんでした。

アジャイルコーチになって３ヶ月で学んだこと from Graat（グラーツ）

www.slideshare.net

また、コーチングの文脈では質問を「相手の中にありながら、本人がまだ気付いていない答えを引き出し、気付かせること」というように定義されることが多いです。その定義にふれるたびに、共感する一方で、「気付かせる」という表現の中にかすかな傲慢さを感じてしまい胸がざわついていました。*1

引用: コーチングの質問スキル：プロが実践する効果的な質問集 | コーチ塾

そんな中、本書のシンプルだけど確かな「問いかける技術」は、上記のモヤモヤをいっぺんに吹き飛ばすような爽快さをもたらしてくれました。

失敗例

さて、私自身も「問いかける」ことの重要性に気づき、仕事でも見よう見真似でアドバイスではなく問いかけをしてみたのですが、本書を読むまでは、見事に本書でのアンチパターンのような問いかけを数々してしまいました。

自分では質問しているつもりでも、それは単に言葉づかいが変わっただけで、結局は自分の言いたいことを質問の形式に置きかえただけか、あるいは自分が正しいことを確かめるために相手に聞いているにすぎない場合が多い。

問いかける際のたったひとつの冴えたやり方

......と大袈裟に書きましたが、本書にはさまざまなシチュエーションや実際の質問例がいくつも書いてあります。ですが、本書を最後まで読めば、結局ひとつのことしか書いていないことに気づかされます。それは、技術というより姿勢。

すなわち、当書での「問いかける技術」とは、

「謙虚に問いかけること」

という姿勢に尽きるのです。

「謙虚に問いかける」とは、本書の言葉を借りれば「相手に対して興味や好奇心を抱」き「自分が知らないということを積極的に認め」相手に尋ねることです。
ただ、それだけ。

なぜ「謙虚に問いかけること」はむずかしいのか？

「謙虚に問いかける」とは「知らないことを、好奇心を持って、素直に質問すること」と言いかえることができます。しかし、なぜそんな単純なことを実践するのがむずかしいのでしょうか？　なぜわざわざ本書は書かれたのか？

それは米国文化(これはアメリカに限らず日本もそうだと思います)は「話す力を過大評価されて」おり、また「リーダーたる者は賢くなければならず、はっきりと方針を決め、価値観を明確に示すべき」とされているため「地位が高くなればなるほど、人に物を尋ねることは難しくなるから」です。

つまり、偉くなればなるほど、自分が知らないことを認め、相手に素直に聞くことがむずかしい文化の中で私たちは育ち、存在するのです。だからこそ「謙虚に問いかける」ことの重要性を認識し、学習する必要があると著者は言います。

なぜ「謙虚に問いかける」ことが必要なのか？

まずは著者の言葉をそのまま引用してみます。

世界は今、目に見えて複雑になり、文化の多様性が増し、人々が互いに依存し合うことによって成り立っている。だからこそ、良好な人間関係を育む適切な質問をすることは、きわめて重要である。相手の考えを聞く、その人と互いに尊重し合う気持ちを大切にする、相手は自分が必要とする知識を持っているであろうことに気づくーー。こうした心がけがなければ、国籍も職業も経歴も異なる相手を理解するこはできないし、ましてや一緒に仕事をしていくことなどかなわない。

現在の複雑な世界に、自分の知っていることだけで立ち向かうのは限界があります。その時その時に必要な知識を持ったメンバーに立場を超えて「謙虚に問いかける」ことができるかどうかは、組織の命運を握るほどの大きなスキルとなるのです。

おわりに

いかがでしたでしょうか？

駆け足で説明してきましたが、本書はこんな単純ではなく、複雑かつニュアンス豊かに「謙虚に問いかけること」が説明されています。マネージャーやアジャイルコーチに限らず「問いかけること」や良好な人間関係や強い組織づくりと言ったテーマに興味があればぜひご一読をおすすめします。

私も本書を読んで、「謙虚に問いかけること」を早速実践するようになりました。

"知らないことを、好奇心を持って、素直に質問すること"

ーーそれこそが最良の質問術であり、「問いかける技術」なのです。

*1:とコーチングでの質問をディスるような書き方をしてしまいましたが、これはこれでとても重要であり、今後きちんと学びたいと思います!