More than 3 years have passed since last update.

「自己組織化」「心理的安全性」って結局なんなのか？

Last updated at 2020-03-05Posted at 2020-03-05

はじめに

アジャイルやスクラムなどに浸かろうとすると出てくる「自己組織化」。
いろんなところで言われ始めている「心理的安全性」。
ちゃんと原典にあたって解釈しているヒトもいれば、自己流解釈してそうなヒトも居る。
自分自身、分かるようでわかってない部分もあったので、真面目に向き合ってまとめてみる。

tl;dr

◆自己組織化とは何か？対する個人的な結論◆

「チームとして最適な方法を自ら判断し行動している状態」

◆心理的安全性とは何か？に対する個人的な結論◆

「学習する組織」に必要な要素。目指すべきは「心理的安全性」ではなく、「学習する組織」。

◆もろもろ含めた個人的な結論◆

「そもそも、何故「自己組織化」「心理的安全性」が必要なのか？」
『「自己組織化」「心理的安全性」を目指すべきだ！』と言うヒトは、この問に答える必要がある。

個人的な汎用回答は「顧客に対して、常に今まで以上の価値を提供し続ける能力を持ったチームを実現するために必要」。
これに、現場特有の要素を加えて、現場ごとに見直す必要がある。
実現のためのアプローチを含めた考え方は以下。（詳細は #個人的解釈で触れます。）

自己組織化の定義

まずは先行研究にあたるのが定石だろう。ということで、まずはいろんな人の定義を集めてみた。

公式の定義
- アジャイル宣言の背後にある原則
- スクラムガイド
- LeSSの定義
- 江端さんの定義
公式とは言い難い人たちの定義
- InfoQの定義
- wikipediaの定義
- 日本の先人たちの考え

アジャイル宣言の背後にある原則

そもそも「自己組織化」って今まで聞いたことなかったのにどこから来たのかと思えば、アジャイル宣言関連だった。

◆日本語版◆
「自己組織化」の言及は「アジャイル宣言の背後にある原則」にある。

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
引用元：アジャイル宣言の背後にある原則

◆英語版◆
細かいニュアンスを確認したいときは、原文（英語）を当たるのが望ましいだろう。

The best architectures, requirements, and designs emerge from self-organizing teams.
引用元： Principles behind the Agile Manifesto

そんなに英語詳しくないのであれだが、ニュアンスはそこまでズレてないように感じる。

スクラムガイド

◆日本語版◆
「自己組織化」の言及はスクラムガイドにもある。
ただ、注意すべきは「スクラムチームは自己組織化されている」と「開発チームは自己組織化されている」の2つの軸がある点。

・スクラムチームに対する定義（抜粋）

スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。
スクラムチームは自己組織化されており、機能横断的である。
自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する。
機能横断的チームは、チーム以外に頼らずに作業を成し遂げる能力を持っている。
スクラムにおけるチームのモデルは、柔軟性・創造性・生産性を最適化するように設計されている。
スクラムチームは、前述した用途や複雑な仕事において、非常に高い効果を自ら証明している。
引用元：スクラムガイド2017

ガイドの中で、自己組織化を指し示すキーワードとしては、以下の2つあたりだろう。

作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自分たちで選択する
柔軟性・創造性・生産性を最適化する

・開発チームに対する定義（抜粋）

開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。
その相乗効果によって、開発チーム全体の効率と効果が最適化される。
開発チームには、以下のような特徴がある。

自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。

機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。

ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバーに肩書きはない。

テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、スクラムは開発チームのサブチームを認めていない。

開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発チーム全体が持つ。

引用元：スクラムガイド2017

後半に提示するが、LeSSで用いられているリチャードハックマンの定義も含めて解釈すると、以下あたりが定義だろう。

プロダクトバックログをリリース判断可能な機能のインクリメントに変える方法は、誰も（スクラムマスターでさえも）教えてくれない。
開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている。
その相乗効果によって、開発チーム全体の効率と効果が最適化される。

◆英語版◆

そんなに英語詳しくないのであれだが、ニュアンスはそこまでズレてないように感じるので折りたたみ

英語だと以下だ。

・スクラムチームに対する定義（抜粋）

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.
Scrum Teams are self-organizing and cross-functional.
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.
The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
The Scrum Team has proven itself to be increasingly effective for all the earlier stated uses, and any complex work.
引用元：スクラムガイド2017

ガイドの中で、自己組織化を指し示す文章としては、以下の2つあたりだろう。

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

そんなに英語詳しくないのであれだが、ニュアンスはそこまでズレてないように感じる。

・開発チームに対する定義（抜粋）

Development Teams are structured and empowered by the organization to organize and manage their own work.
The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
Development Teams have the following characteristics:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;

Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

引用元：スクラムガイド2017

日本語版と同じ箇所を引っ張ると

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Development Teams are structured and empowered by the organization to organize and manage their own work.
The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

そんなに英語詳しくないのであれだが、ニュアンスはそこまでズレてないように感じる。

LeSSの定義

スクラムガイドよりも、LeSSの方が情報量が多いので、個人的に参照することが多い。¹
LeSSの中では、自己組織化とは何かについて、スクラムガイドよりは言及されている。

LeSS implies at least self-managing teams and that means that the monitoring and managing process and progress belongs to the team and not to the manager.
引用元： LeSS - Self-Management

訳すなら、こんなところか？

（自己組織化とは） 少なくとも 「Self-Managing teams」を意味し、プロセス・進捗の監視・管理はマネージャー ではなく チームの責任範囲になります。

開発チームに対する定義なのか、POやSCMを含めたスクラムチームに対する定義なのかは示されてない。

江端さんの定義

※ただし、2018/01以前の定義と思われる。

1: チームのゴールが明確であること
2: チームの仕事や裁量の境界が明確であること
3: チームメンバーが，自分たちのやるべきことを自分たちで 0.1 秒以内に決定できること
引用元：はてなブログ - チームを自己組織化を促進するための「境界」の引き方

InfoQの定義

InfoQってサイトの記事が割とキレイにまとまってる印象があったので、引用してみる。（色んな文献も引用されている様子）
この記事においては、自己組織化自体の定義は、LeSSでも引用されているリチャードハックマンの定義に沿っている。

自己組織化チームがその可能性を最大限に発揮する上で，効果的なインタラクションが必要なことは疑いありません。
Russell Ackoff氏がシステム一般について言っていることが，チームにも当てはまります – パフォーマンスは “構成要素それぞれのパフォーマンスの総和ではなく，それらの相互作用が生み出すもの“ なのです。
しかしながら，すでに見てきたように，自己組織化とは，チームがすべてを自ら決定するようになるという意味ではありませんし，自己組織化チームに境界線がない訳でもありません。
むしろ自己組織化には，期待と責任の明確化が必要なのです。

InfoQは更に進んで、自己組織化を促進するためのサポートを独自定義しています。（これが正しいかはさておき）

自己組織化チームのコンテキスト面でのサポートは，基本的に４つのサブシステムから構成されています。
情報 – メンバが作業の適確なプランを立案して実行する上で，必要なデータをチームに提供するため。
インフラストラクチャ – 適当な物理的空間(共同設置チームの多くが苦労している)や技術的インフラストラクチャ，資金という意味において。
教育 – チームが必要とする可能性のあるすべてのトレーニングやコーチング，技術支援という観点から。
報償 – 肯定的，経済的な意味に加えて，優れたチームパフォーマンスを象徴する結果として。

ただ、概ね違和感は無いように感じます。一言でまとめてしまえば「仕組み化」かな、と思っています。

もともとの定義

wikipediaが妥当かは議論があると思うが、wikipediaから引用する。

自己組織化（じこそしきか、英: self-organization）とは、物質や個体が、系全体を俯瞰する能力を持たないのに関わらず、個々の自律的な振る舞いの結果として、秩序を持つ大きな構造を作り出す現象のことである。自発的秩序形成とも言う。
経済学の分野でもポール・クルーグマンらが自己組織化という言葉を使用している。進化経済学の一部には、技術や市場経済そのものが自己組織化の結果であるという考えがある。
引用元： wikipedia - 自己組織化

要素としては以下だろう。

物質や個体が、系全体を俯瞰する能力を持たない
個々の自律的な振る舞いの結果として、秩序を持つ大きな構造を作り出す

まぁこれを現状の定義に無理に当てはめても困惑するだけなので、参考程度に。

日本の先人たちの考え

SlideshareおよびSpeakerDeckで「自己組織化」で検索し、「LIKE10以上」もしくは「VIEW数が多いモノ（1K以上）」、を対象にしています。
どれも生きた知恵がつまってるため、上手く要約しきれてません！
ぜひ引用元をご覧頂ければと思います！
（順番は、資料が公開された順です。）

「はじめての自己組織化」

slideshare - はじめての自己組織化
view:13.3k、Likes:21、150slide、2012-11-22公開、ScrumBootCampを書いた上田さんの資料

自己組織化した状態とは？
- ＝チームとして最適な方法を自ら判断し行動すること
  - 判断には観点が必要≒インセプションデッキ
なぜ自己組織化が必要か？
- （変化が激しくなってきたため）状況に応じた意思決定が超重要
- だから「答え」ではなく「答えを出す方法」を学んだ状態（＝自己組織化された状態）が求められる
自己組織化するには？
- 認知・判断・行動のどこかでつまづくので、支援が必要。
  - 現場での支援方法：率直な思いを伝えあう、勇気をサポートする、考える時間を作る
  - 根本的な意識改革：神々（上司）の意識改革（信頼・許可・支援）

支援の方法がかなり具体的なので、ぜひスライド御覧ください。

「自己組織的なScrumチームの目指し方」

slideshare - 自己組織的なScrumチームの目指し方
view:12.8k、Likes:97、46slide、2015-3-1公開、RSGT2015にて発表

自己組織化した状態とは？
- ≒ワクワクする組織
- 「メンバーの成長」と「チームの環境」が大事
なぜ自己組織化が必要か？
- 現在の状態と目標の状態を設定するとやるべきことが見えてくる
  - （＝Level5さんでは整理した結果、自己組織化がやるべきことだという判断）
自己組織化するには？
- いきなり成長はしないので、現実的な「自己組織化プラン」を考えよう。

「チームの状況を見える化して、自己組織化されたチーム作り」

speakerdeck - チームの状況を見える化して、自己組織化されたチーム作り
view:1.3k、Likes:3、50slide、2019-02-20公開、2018-02-20のYappli主催イベントで発表

自己組織化された状態とは？
- チームにスキルがある。もしくはチーム自身でスキルを獲得する方法を知っている。
- 自分たちで意思決定できる
- 衝突を内部で解決できる能力を持つ
なぜ自己組織化が必要か？
- 現場で判断し、問題、課題を解決することによって、早いサイクルで改善できる
- チーム内で良い意味での厳しい指摘をフィードバックし合える関係によって視座が上がる
- エスカレーションするべき事を理解しているので、判断待ちを最小にすることができる
自己組織化するには？
- Step：課題の見える化　→　一緒に課題を解決する経験　→　チーム自身で課題を解決する　→　チームで意思決定するのが習慣化
- 具体的アクション例1：振り返りの強化
  - 意見ではなく事実に目を向ける
  - チームのプロセス/状態に対する改善を考える時間を作る
  - 全員が同じ立場で考える
  - 何を発言しても「安全な場」にしなければならない
- 具体的アクション例2：妨害リストの運用
  - チームで共通の課題意識を持つ
  - 他の誰でもない「チームが」改善していく
  - 前提に対しての振り返りができる

「自己組織的な開発チームを如何にして作り上げるか」

speakerdeck - 自己組織的な開発チームを如何にして作り上げるか
view:3.2k、Likes:5、57slide、2020-02-14公開、デブサミ2020にて発表

自己組織化された状態とは？
- 書籍：エラスティックリーダーシップの定義
  - 自己組織化されたチームとは、意思決定の機会や生産的に前進する際に、リーダーであるあなたから独立して機能するチーム
- 発表者の定義
  - 個々人が全体を把握していないとしても、リーダーなしに判断し行動できるチーム
  - チーム＝個人の行動＋個人間の相互作用
  - 環境の変化に対して、個人が相互作用し、チームとして構造化していく状態
なぜ自己組織化が必要か？
- VUCA（Volatility:不安定、Uncertainty:不確実、Complexity:複雑、Ambiguity:不明確）
- 1人がすべてを把握できるほど現実はシンプルではない
- 1人が正しくリードできるほど現実はシンプルではない
自己組織化するには？
- 個人を尊重する＝変化・不安定化を許容する＝変化・不安定化こそが局所最適化を超える力になる
  - 「チームの進む道をリーダーの見識で限定しない」
  - 「集合的にベストな意思決定は意見の相違や意義から生まれるのであって、決して合意や妥協から生まれるのではない」
- 相互作用する場が必要＝形式張らずに議論できる状況を作る
  - 「信頼関係（＝フィードバックしてくれる関係性）」と「心理的安全性」
  - 「学習性無力感」と戦う＝「何をしても意味がない」と学ばせてはならない

結局、自己組織化って？

いろいろ並べてみましたが、個人的な現時点の結論は以下ですね。
（ほぼ、「slideshare - はじめての自己組織化」に同じです。）

「チームとして最適な方法を自ら判断し行動している状態」

この中でもポイントは「最適」と「判断」だと思っています。

「最適」な方法を見つけるために

前提を変える仕組み：前提やプロセスを自律的に変更できるような仕組みづくり
- 「前提　→　行動　→　結果」において、「行動　→　結果」の振り返りだけでなく、「前提　→　行動」の振り返りをする場を用意する
見える化
- 見えないモノを改善することはできない
- 共通認識を持てるようになるので改善サイクルが早くなる
- 必要な情報はいつでも見えるところに置いておくことで意見をしやすい状況を作る
心理的安全性：率直に言い合える関係性
- 「集合的にベストな意思決定は意見の相違や意義から生まれるのであって、決して合意や妥協から生まれるのではない」
説明責任：チーム自身に説明責任を担ってもらう
- 「（チーム外の）◯◯さんが言ったから」では、本当に最適なのかチームで判断できていない。
- インプットとして用いることはあるだろうが、その判断に従うのはなぜか？を整理することを常にチームに求める。
- 結果として、前提やプロセスに目が向くようになることで、最適な方法に繋がる。

「判断」するために

ゴールが明確であること
チームの仕事や裁量の境界が明確であること
十分な権限と信頼を与えられていること

自己組織化を目指すためのアクション

そもそも、なぜ必要なのかを現場メンバーとすり合わせる必要がある。
その上で、どのようにアプローチしていくか具体的に考えていくことになるかと。
前述の資料は比較的具体的なのものが多いですが、「率直に言い合える関係性（≒心理的安全性）」の実現方法だけは、あまり触れられていない。
以降は、その「心理的安全性」に触れていきます。

心理的安全性の定義

そもそも心理的安全性とはどこから来たのか？

以下がキレイにまとまってる。
参考：日経 - 恐れのない職場がトヨタの強み　ハーバードが見る組織

心理的安全性の流行については、かいつまんで言えば、以下のような流れ。

Googleが研究結果として、「効果的なチームにおいて、最も重要なのは心理的安全性である」と示す。
New York Timesがニュース（WEB記事）にする。
海外でバズる。
日本でバズる。

バズる経緯は置いておいて、そもそも「心理的安全性」はGoogleが提唱した概念ではありません。
そもそもは、エイミー・C・エドモンソン博士が提唱したものになります。
エドモンソン博士は「Teaming（邦訳：書籍 - チームが機能するとはどういうことか？）」という書籍で、心理的安全性が必要な背景についても触れています。

一応、両者の定義を置いておきます。

Google(re:work)：チームメンバーがリスクを取ることを安全だと感じ、お互いに対して弱い部分もさらけ出すことができる
エドモンソン博士：チームメンバーがお互いに『このチームでは対人リスクをとっても大丈夫だ』と信じている状態

心理的安全性の背景としての「学習する組織」

（だいぶ個人的解釈入ってます。ちゃんと理解したい方は、「書籍 - チームが機能するとはどういうことか？」をご覧ください。）
端的に言えば、成功するには「実行する組織」から「学習する組織」への転換が必要だと、エドモンソン博士は言っている。

◆「実行する組織」とは？◆

不確実性が低い世界において、有効。（現代においては、有効でない状況が多いだろう。）
人間を「補充可能な資源（リソース）」と見ており、ただひたすら「効率化」を求める。
現場に対する評価基準は「事前定義されたプロセスを、適切に遂行できたか？当初期待した結果通りになっているか？」
失敗は「忌避するもの」という「ネガティブ」な存在として扱う。

◆「学習する組織」とは？◆

不確実性が高い世界において、有効。
人間を「相互作用を生み出す代替不可能な個人」と見ており、「挑戦」を推奨する。
現場に対する評価基準は「挑戦と学習によって、より良い結果に近づくことができたか？」
失敗は「学習機会」という「ポジティブ」な存在として扱う。

書籍の中では、「状況に応じて使い分けるのが適切」と表現はされている。
（ただ、文脈的には「学習する組織」こそが成功の要因であるという主張に読み取れる。）

◆「心理的安全性」と「学習する組織」の関連性◆
そもそも人間は一般的に、「素朴実在論」や「根本的な帰属の誤り」など、適切な議論を妨げる心理的機構を持っている。

それらを乗り越え、対話を通して適切な学習に至るには、「率直に言い合うこと」が必要。
「率直に言い合う」ためには、「心理的安全性」が必要である。

結局、心理的安全性にはどうアプローチすべきか？

実は、「心理的安全性を直接向上させようとするアプローチ」は「失敗に終わった」というエピソードが書籍の中にあります。
必要性は全員理解しているが、直接アプローチしても、心理的安全性の向上にはつながらなかったとされています。
では、どうすればいいかというと、「フレーミング」と「人間心理の理解」が良いとされています。

◆フレーミング◆
端的に言えば、『「リーダー」「メンバー」「チームの目標」の新しい定義を宣言し、そのように行動する』です。
（このフレーミング自体は、「学習する組織」を構築するためのアプローチであり、心理的安全性の向上を直接的に狙うようなアプローチではないですが。。。）

厳密な定義は書籍を参考にしてもらうとして、個人的解釈を以下に載せます。

項目	定義
リーダー	困難な目標の達成に向け、メンバーと相互作用しながらサーバント・リーダーシップを発揮する存在
メンバー	困難な目標の達成に向け、リーダーと相互作用しながら共に活動してくれる代えがたい存在
チームの目標	社会的意義があり、個人の成長にも繋がることが分かるようなワクワクする目標

◆人間心理の理解◆
書籍の中では、フレーミングのプロセスの一貫として表現されています。²
前述したとおり、率直に話し合うには、それを妨げるメカニズムへの理解が助けになります。
「素朴実在論」や「根本的な帰属の誤り」などです。
個人的な解釈は後述します。

日本の先人たちの考え

「心理的安全性を0から80ぐらいに上げた話」

slideshare - 心理的安全性を0から80ぐらいに上げた話
view:92.5k、Likes:146、26slide、2018-10-25公開、Roppongi Product Manager Meetup#6で発表

ポイント（how）
- 1on1：とにかく多くの人から情報を得る（何が問題の核心なのか粘り強く探る）
- 小改革：小さいことから解決していく
- 大改革：1on1と小改革を繰り返していくと根本原因が見えてくる→大改革
目指す姿
- ヒーローになる：心理的安全性の象徴

リーダーとしての動き方的な内容

「心理的安全性とソフトウェア化する社会」

[speakerdeck - 心理的安全性とソフトウェア化する社会](https://speakerdeck.com/hirokidaichi/psychological-safe
view:8.6K、Likes:35、45slide、2019-09-17公開、「エンジニアリング組織論への招待」およびQiitaでも有名な広木大地さん

なぜ心理的安全性が必要か？
- 不確実性（未来・他人）に向き合うために必要
心理的安全性とはなにか？
- 4つの大丈夫
  - ここにいても大丈夫
  - 意見を言っても大丈夫
  - 間違いを認めても大丈夫
  - 助けを求めても大丈夫
心理的安全性を高めるために
- チームの状態に応じてマネジメント方針を変える
- コーチング：悩むから考えるに変換する手伝いをする
- 上記マネジメントを実現する仕組み作り（情報の非対称性の削減）
- などなど

具体的なノウハウが多数

その他有用そうな情報

ちょっとヒット対象が多かったので、説明割愛したもの。

個人的解釈

「そもそも、何故「自己組織化」「心理的安全性」が必要なのか？」
『「自己組織化」「心理的安全性」を目指すべきだ！』と言うヒトは、この問に答える必要があるように感じます。

『「顧客に対して、常に今まで以上の価値を提供し続ける能力を持ったチーム」を実現するために必要だから』が個人的な回答です。
その上で、実現方法は下図のようなアプローチを考えます。
（もっとシンプルにまとめても良かったけど、そうすると情報が減る・・・と思ったら盛り込みすぎた感）

◆「最適」な方法を見つけるために◆
（再掲）

前提を変える仕組み：前提やプロセスを自律的に変更できるような仕組みづくり
- 「前提　→　行動　→　結果」において、「行動　→　結果」の振り返りだけでなく、「前提　→　行動」の振り返りをする場を用意する
見える化
- 見えないモノを改善することはできない
- 共通認識を持てるようになるので改善サイクルが早くなる
- 必要な情報はいつでも見えるところに置いておくことで意見をしやすい状況を作る
心理的安全性：率直に言い合える関係性
- 「集合的にベストな意思決定は意見の相違や意義から生まれるのであって、決して合意や妥協から生まれるのではない」
説明責任：チーム自身に説明責任を担ってもらう
- 「（チーム外の）◯◯さんが言ったから」では、本当に最適なのかチームで判断できていない。
- インプットとして用いることはあるだろうが、その判断に従うのはなぜか？を整理することを常にチームに求める。
- 結果として、前提やプロセスに目が向くようになることで、最適な方法に繋がる。

「判断」するために
（再掲）

ゴールが明確であること
チームの仕事や裁量の境界が明確であること
十分な権限と信頼を与えられていること

◆フレーミング◆

役割に対する期待：各役割 に期待していることについて、共通認識を持つ。（リーダーとは何をする役割なのか、メンバーには何を期待しているのか？）
個人に対する期待：各個人 に期待していること、チームにとって必要な存在であることを伝える。（1on1などで。）
ワクワクする目標：メンバーがワクワクするような チームの目標 を定義し、実行に向けた計画を共に作る。

これらアクションは、リーダーという役割にいたほうがやりやすいですが、メンバーというポジションになったとしても、このようにリーダーに働きかけたいと思っています。

◆人間心理の理解◆
以下のような人間心理が存在することを共通理解とした上で、本能に流されるのではなく理性的に会話する土台を作る。
「定義」は引用がありますが、「省察ポイント」や「改善ポイント」は個人的な解釈から生まれたアクションです。

◇全般◇
率直に言い合える関係の構築のために、以下が必要。

素直に言えないメカニズム（対人リスク、対人不安）に対する理解
- 根拠レスでも懸念を言えることが大事。根拠が必要になってしまうと、率直には言えなくなってしまう。
信念を傷つけられたという誤解から生じる議論対立の存在
- 根拠が薄い結果、信念を傷つける状況は生まれやすくなる。
  - 対立を避けるのではなく、対立を乗り越えて、学習のための議論にする力が必要。
  - 力をつけるには、理論を得た上で、対立にぶつかっていくのが良い。

◇素朴実在論◇
定義：

「自分は認識しうる不変の客観的実在（自分以外の他者も、理性的で道理をわきまえているかぎりにおいて、自分と全く同様に知覚する実在）をよく知っているという動かしがたい信念」³
私たちの「現実」を他者が誤って知覚すると、それはその他者が理性に欠けている、あるいは道理をわきまえておらず、「自己の利益、イデオロギー的偏向、あるいはつむじ曲がりな性格というプリズムを通して世界を見ている」からだと判断する。⁴

省察ポイント：

自分の意見を否定された時に、「相手が理性に欠けている」などと理由付けをし、以下のような行動をとっていないか？
- 相手の指摘内容を正しく理解しようとする前に、「自分の意見の正しさ」を説明しようとする。　←　相手からすると「言い訳」に見える。
他人の意見に指摘をする時や、指摘に対する反応において、「相手が理性に欠けている」などと理由付けをし、以下のような行動をとっていないか？
- 相手の意見の正当性を理解したことを伝えずに、「気になったトコロ」をいきなり指摘する。
- 「言い訳、乙」などと思いながら、相手の主張を聞き流す。

改善ポイント：

自分の意見に指摘を受けた時、「正しさの主張」よりも、「指摘内容の理解」を優先的に行うように意識する。（「指摘を打ち返したい気持ち」をグッと堪える。）
相手の意見を聞いた時、まず相手の意見に「正当性があること」を認めたことを明確に示し、その上で指摘を行う。（一言、ワンクッションあるだけで、だいぶ違う。）
（根本的な主義主張が異なると思われる相手同士の議論など）「言い訳」合戦に発展する可能性が高い場合は、なるべく冷静になれるように、第三者としてのファシリテーターを用意する。（素朴実在論に囚われないファシリテータが望ましいが、単に第三者というだけでも効果はある。）

◇根本的な帰属の誤り◇
定義：

この言葉が指すのは、私たちが事象の状況的要因を認識できず、原因は個人の性質や能力にあるにちがいないと過度に思いすぎるということである。
この認知的誤謬の結果として、私たちはある人の欠点を、その人が直面している状況ではなく能力や姿勢と関連付けて解釈するようになる。
つまり、うまくいかないのは状況ではなく「人」のせいだとするのである。
(中略)
おかしなことに、自分自身の失敗を説明するとき、私たちは全く逆のことをする。
つまり、無意識のうちに、原因は外的要因にあるとするのである。⁵

省察ポイント：

自分のミスに対しては、「外的要因」だけで原因説明を終わらせようとしてないか？「内的要因」は十分に振り返れているか？
他人のミスに対して、「外的要因」を十分に確認したか？同じ状況にあって、誰しもが「正しい行動」が取れるか？

改善ポイント：

自分のミスにおいて、原因を「外的要因」だけにすると学習の要素が無くなる。「内的要因」を「改善ポイント」と解釈し、自己成長につなげる。
他人のミスにおいて、「外的要因」を十分に評価し、「正しい行動を取りやすくする状況」に向けた改善を議論する。
- 「間違った行動を取らないようにする」という方向性は議論が「言い訳」に向かいやすい。
- 「正しい行動を取りやすくする状況」について議論するためには、「問いかけ方」が非常に重要。

◆現場特有◆
「現場特有」と表現したところは、参画するプロジェクトによって変動する要素は存在しうると考えているからです。
「顧客に対して、常に今まで以上の価値を提供し続ける能力を持ったチーム」が本当に目指したいチームですが、現場に応じて注力ポイントは変わるでしょうし、結果としてこの表現も変わってくると思います。

さいごに

精一杯向き合ってみましたが、むっずかしい！
とはいえ、ちゃんと向き合って自分なりの答えを出せたトコロには、少しスッキリしています。
現場の数だけ答えがあるとは思いますので、ご意見あれば優しくコメントいただければと思います！

以上です。

引用・参考

LeSSなのに、情報量が多い（more）とは？ ↩
「登録→準備→試行→省察」というプロセスにおける、「準備」で「人間心理（認知のメカニズム）の理解」が重要であると説明されています。 ↩
L. Ross, "The Intuitive Pychologist and His Shortcomings," in *Advances in Experimental Psychology, Vol. , ed. L. Berkowitz (New York: Academic Press, 1977), p.405. ↩
エイミー・C・エドモンソン（2014）チームが機能するとはどういうことか　英治出版　p.88 ↩
エイミー・C・エドモンソン（2014）チームが機能するとはどういうことか　英治出版　p.89 ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up