「チーム内の心理的安全性」は難しい？
ソフトウェア開発において、心理的安全性が重要であるという認識は広がりつつあります。 少人数、たとえば4～5人、の開発チーム内で心理的安全性を高めるには難しい面もあります。
チーム内には多かれ少なかれ権力勾配が存在します。チームリーダーとメンバーという構造がある限り、対等な関係性で本音を共有することは簡単ではありません。
定期的に雑談をする場を用意しても関係性が硬直することがあります。 同じメンバーで何度も雑談をすると、話すネタが尽き気を使うだけになり、心理的安全性どころかストレスを感じることもあるでしょう。 こういうとき多くの人は定番の雑談（例：趣味のゲームや今期のアニメ）をします。 メンバーが固定の時はいいです。グルーミングコミュニケーションの一種です。 チームメンバーだけに通じる定番のコミュニケーションは、メンバーが増えたときに不要な疎外感を与えることがあります。
チーム内での心理的安全性の構築は、構造的に難しい上に、新しいメンバー受け入れの阻害になることもあります。
エンジニアリングマネージャーの役割
チームリーダーは日々の進捗管理や技術的判断、対外的な調整などを担っています。 心理的安全性まで一人で抱えるのは現実的ではありません。 必要だと理解していてもチームリーダーには時間がありません。 エンジニアリングマネージャーがサポートする必要があります。
エンジニアリングマネージャーは、各チームのプロジェクト成果に直接コミットする立場ではありません。 プロジェクトの状況や人間関係に左右されない公平な立場として、チーム間の連携を自らの責任として介入していけます。
心理的安全性を、チームに閉じずに組織全体の課題とすると、チーム内の権力勾配の影響を薄められます。 他チームのリーダーの機嫌は、自チームのリーダーの機嫌ほどは気になりませんよね？
「組織全体の心理的安全性を設計し支える」をエンジニアリングマネージャーの役割にしましょう。
「面で設計する」心理的安全性のつくりかた
チームリーダーが1つのチームを深く見るのに対し、エンジニアリングマネージャーは組織全体を俯瞰し「面」として心理的安全性を設計できます。
たとえば、朝礼とTimes（例：slackでの分報）と振り返りセッションを組み合わせて設計します。
- 朝礼は、1日5～15分のオンラインミーティングです。単純接触効果を高める場です。毎日お互いの顔を見る、声を聞く、自分の声を出すという繰り返しで信頼の土台を作ります。
- Timesでは、Slackの分報などで業務の進捗や悩みを共有します。関係性のある者同士でアドバイスやジョークを交わせる場になります。
- 振り返りセッションでは、ランダムな組み合わせの4～5人で1時間ほど、KPT（Keep, Problem, Try）などのフォーマットを用いて仕事とプライベートの中間の個人の課題を話します。。1人あたり10〜15分の時間をつかってお互いの考えや性格が自然と表れる会話で親近感を生み出します。
コミュニケーションの方法は多様です。 一つのコミュニケーション支援の手法で完結することはありません。 複数の手法を組み合わせて、色々なパターンのコミュニケーションチャンネルを育てて行く必要があります。 メンバー全員がメンバー全員とそこそこのコミュニケーションをとれることを目指します。
特定のメンバーが高いコミュニケーション能力を持っていたとしても頼らない方がよいです。 短期的に上手く行くことが多いですが、特定のメンバーの負担が大きすぎます。 そのメンバーのキャパシティを越えたときに対応できなくなります。 よほど高いコミュニケーション能力を持つ人間でも、そのキャパシティは10人も無いはずです。
仕組みの継続的な運用を通じて、組織内のメンバー全員の偏りのすくない信頼関係を育てていきます。
コミュニケーションへの温度感
プロジェクトの推進を主な責務とするチームリーダーの立場から見ると、コミュニケーション活動につかう時間が業務効率を下げるものと受け取られてしまう可能性があります。
背景に、エンジニアリングマネージャーとチームリーダーの視点の違いがあります。 エンジニアリングマネージャーはチーム間の信頼関係や組織全体の健全性に重きを置きます。 チームリーダーは自チームのプロジェクトの成果を最優先に考えます。 コミュニケーション活動をプロジェクトの時間を奪う「邪魔なもの」と捉えることがあります。
この認識の違いを乗り越えるには、エンジニアリングマネージャーがチームリーダーの敵ではなく、味方であることを丁寧に伝えていく姿勢が重要です。 組織の心理的安全性はチームリーダーの仕事をやりやすくするために役立ちます。 手を替え品を替え根気強く伝えていく必要があります。
