はじめに

本記事は、以下の記事の続きです。

心理的安全性の正しい理解を絵でわかるように書いていますので、ぜひこちらから読んでみてください m(_ _)m

さて今日では、テレワークが進み、オンラインミーティングも増えましたね。
そうした中で、皆さんのチームでは、コミュニケーションに壁ができていませんか？

目指した会議の目的が十分に達成できていますか？

シャンシャン会議になっていませんか？

チームから提案や意見がちゃんと出てきていますか？

もしこうした課題感を少しでも感じている場合は、本記事が参考になるかもしれません。

前回記事では、心理的安全性の正しい理解にフォーカスして記載しましたが、今回は心理的安全性の改善にフォーカスして記事を記載します。

参考図書

本記事は、エイミー・C・エドモンドソン教授の著書『恐れのない組織』という本をもとに記載しています。この本は、心理的安全性について多くの誤解に気づくきっかけをくれて、とても勉強になったので、非常におすすめです。

恐れのない組織――「心理的安全性」が学習・イノベーション・成長をもたらす

本記事における引用や表は特に指定がない限り、本参考図書から引用しています。

なぜ私たちは口を閉ざしてしまうのか？

周知の通り、チーム開発現場において質問や提案や意見を言うことは以下のような効果をもたらします。

保守性・性能など、様々な観点でより良い設計
バグや障害の早期検知
チームの学習促進・個々のメンバーのスキルアップ

これらは、チームの生産性・品質の向上を生み出し、顧客からの高い評価ひいては個人の業績アップにつながります。

こうした数多くのメリットがあるにも関わらず、多くの開発現場において沈黙は蔓延しているのはなぜでしょうか？

参考図書によれば、それは「安全第一でいこうとする本能」と「常時評価されていること」に起因します。

安全第一でいこうとする本能:
私たちは、小学校くらいから、他人にどう思われているかが重要であることに気づき、周囲にネガティブな印象を与えないように自身をコントロールしてきました。大人になると、それを無意識で行うようになります。

私たちは常時評価されている:
公式には、上司などが私たちの業績を評価しますが、非公式には同僚や部下が常に私たちについて判断しているということです。変な質問をしたり、ずれたアイデアを提供したりしてしまったら、いつなんどき無知、無能、あるいは出しゃばりという烙印を押されてしまうかもしれないのです。

上述したように、発言することは、たしかに多くのメリット（効果）が期待できます。しかし、それらは不確実であり、効果が表れるのは少し後になることが多いです。一方で、沈黙する場合は、即座に安全をもたらし、自分の身を守るという効果を確実に発揮してくれます。この関係性は、以下の表のように整理できます。

	効果を実感する人	効果が表れるとき	効果の確実性
発言する場合	組織や顧客	少しあと	低い
沈黙する場合	自分	今すぐ	高い

上記のような理由から、発言するか沈黙するかの計算で、沈黙が勝ってしまうのです。

勇気を出せは悪なのか？

沈黙が課題となるとき、必ず、

人々はもう少し気骨、すなわち勇気を持つべきだ

ということが指摘されます。これに対して参考図書においてエイミー氏は次のように述べています。

賛同するが、効果的な主張ではない
"倫理観" に訴えており、確実に良い結果をもたらす "戦略" ではないから
率直に意見を言えるだけの心理的安全性が、制度化・組織化される必要がある

沈黙を解消するためには？

沈黙を解消し率直に発言できる状態をつくるためには、いうまでもなく、心理的安全性を確立することが必要です。参考図書では、心理的安全性を確立するためのリーダーのツールキットとして、以下が紹介されています。

土台をつくる
- 仕事をフレーミング¹する
- 目的を際立たせる
参加を求める
- 状況的謙虚さ²を示す
- 探究的な質問³をする
- 仕組みとプロセスを確立する
生産的に対応する
- 感謝を表す
- 失敗を恥ずかしいものではないとする
- 明らかな違反に制裁措置をとる

以降のセクションでは、これをシステム開発の現場に適用した場合のアクションについて私の理解を説明します。また、リーダーのツールキットとして紹介されていますが、チーム全体としてどうあるべきかという視点で記載します。

土台をつくる

「土台をつくる」とは、システム開発の現場に適用すると、以下の３つに言い換えられると思います。

① 障害、バグ、失敗は、起きて然るべきものと認識を改めること
② 開発対象や開発現場の性質を分析し、率直な発言の必要性を明確化すること
③ 開発システムの意義を理解すること

① は、失敗は起きて当たり前であることチーム全員が確実に理解することです。失敗が起きるのは、能力不足のせいだという思い込みを捨てさせ、失敗の意味と失敗からの学習についてチームで考え認識を改めることが重要です。そのために、「調査する」ではなく「研究する」、「ミス」ではなく「事故」と表現するように用語を変えることも効果的です。

② は、まず開発しているシステムや体制などが、どのような状態であるかを分析します。例えば、顧客や市場動向の変化にいち早く気付き、開発に反映していくことが必要なプロジェクトもあれば、複数のコンポーネントが絡み合う複雑なシステムでバグが発生しやすい状態かもしれません。あるいは、多数の部署から構成される大規模な開発体制で情報共有にリスクがある状態かもしれません。このように現在のプロジェクトの性質を分析することで、率直な発言の必要性を明確化しチーム全員で理解します。

③ は、システムがなぜ顧客や世の中にとって必要なのかをチーム全員が理解することです。これにより、意欲を高め、困難を乗り越えるエネルギーが生まれやすくなります。また、どんな人でも、疲れたりイライラしているとき、何が大切なのか見えなくなったりするときがあるため、これは折あるごとに再認識する場をつくる必要があります。

参加を求める

「参加を求める」とは、システム開発の現場に適用すると、以下の３つに言い換えられると思います。

④ 状況的謙虚さ²を持ちながら、貪欲に学習し続ける姿勢をもつこと
⑤ 発言を求める場では、問いかけを工夫すること
⑥ 発言を求める場をつくること

④は、システム理解の範囲や深度を高めるということではなく、生産性・品質の改善のため周囲から学ぼうとし続ける、という意味です。リーダー含め全員が、自分は完璧ではなくミスをすることを認識し、他者から積極的に意見を求めることが重要です。

⑤について、システム開発においても誰かに発言を求める様々な機会があります。具体的には、顧客から仕様について意見を聞くときや、アーキテクチャについてアイデアを募るとき、あるいは、振り返りで課題を抽出するときなどが考えられます。そのようなとき、私たちはつい、「何か意見ありますか？」と単調に問いかけてしまいがちです。より発言を引き出すためには、以下のような探究的な問いかけが有効であると考えられます。

より総合的に考えたいときや選択肢を広げたいとき
- 「私たちは何か見落としていないでしょうか」
- 「別の見方が必ずどこかにあるはずです。一歩下がって、性能・拡張性なども視野にいれて、懸念点など見当たらないでしょうか」
- 「今回の開発期間で、皆さんが目指した通りに進まなかったことは何ですか？」
理解を深めたいとき
- 「例を挙げてもらえないでしょうか」
- 「なぜそのように考えるようになったのでしょうか」

⑥については、現状でもデイリーミーティングや顧客との打ち合わせ、振り返りなど様々な機会がすでにあると思います。加えて、メンバー同士が学び合う機会を作るのも効果的です。Google では、g2g（Googler-to-Googler）というネットワークを介し、社員同士で自発的に学び合う仕組みがあり、これは心理的に安全な文化の構築にも効果をあげています。

生産的に対応する

「生産的に対応する」とは、システム開発の現場に適用すると、以下の４つに言い換えられると思います。

⑦ 感謝を表すこと
⑧ 賢い失敗は祝い称賛すること
⑨ 複雑な失敗に対して多角的な分析を行うこと
⑩ 回避可能な失敗に対してプロセスを改善すること

⑦は、そのまんまです。誰かが発言してくれたときに、発言する勇気に対して、最初にちょっとした感謝の言葉をかけることが大切です。質問に対して回答したり、意見を述べたりするのはその後です。

⑧～⑩は、失敗の分類（下表）に応じて適切な生産的対応が必要であるということです。

	回避可能な失敗	複雑な失敗	賢い失敗
定義	既知のプロセスから逸脱し、望まない結果が起きる	出来事や行動がかつてない特異な組み合わさり方をして、望まない結果が起きる	新たなことを始めて、望まない結果が起きる
原因	行動・スキル・注意の欠如	慣れた状況に複雑さ・多様性・かつてない要因が加わる	不確実性。試み。リスクを取ること
典型的なコンテキスト	製造業の生産ラインファストフード店	病院での医療 NASAのシャトル計画	医薬品開発新製品の設計

賢い失敗の場合、例えば新しいテストツールを導入しコスト削減を試みたところ、ツールと開発システムの相性が悪い点が見つかり、導入を断念することになったとき、その失敗は称賛されるべきです。これにより、事例を広く共有するとともに、リスクをとってでも新たな次の試みが生まれやすくなります。

複雑な失敗の場合、多角的な分析が必要です。したがって、生じた失敗に関係する全員で気づいたことや疑問や懸念を共有する場を設けることが参考図書では推奨されています。ほかの人が見たもの、感じたこと、したことに、全員が熱心に耳を傾けることで、開発現場における複雑さと相互依存に対して理解が深まります。誰かを責めるためではなく、同様の失敗が繰り返されないように改善するためのアイデアを出す場とすることが重要です。

回避可能な失敗の場合、例えばテスト観点の漏れがあり障害につながってしまったとき、漏れをなくすためのプロセス改善がアクションになるかと思います。まれに、非難されても仕方のないことをして所定のプロセスから逸脱し、回避可能な失敗が生じてしまった場合は、二度と起こらないように罰金などの制裁を科すことも必要だと参考図書では述べられています。

おわりに

今回は『恐れのない組織』を読んで、２回目のアウトプットを行いました。心理的安全性を確立し沈黙を解消する具体的なアクションは、各現場によって違うと思いますし、絶対的な正解はないと思っています。参考図書をもとに、私がシステム開発の現場を想定して考察した内容も現場によっては有効ではないことも多いにあると思っています。それでも、本記事がどこかの開発現場の改善に役立てば幸いです。

フレームとは思い込み、つまり現実について積み重ねていく信念のこと。誰もが事物や状況を無意識にフレーミングする。（参考図書より） ↩
複雑でダイナミック、かつ不確かな世界で仕事している、今日のような状況においては謙虚になる必要があること。（参考図書より） ↩ ↩²
探究的な問いとは、意図的な調査であり、問題や状況や人についてより詳しく知ることを目的とする。その基本は、ほかの人の発言に心から関心を寄せられるようになること。（参考図書より） ↩