創造的なチームと礼儀正しくすることについて

この記事は Engineering Manager vol.2 Advent Calendar 2019 の3日目の記事です。ちょっとまとまってないですが、何かの足しになれば。

礼儀正しくすること

個人間の社会的儀礼は、一般的に文脈を異にする人同士のコミュニケーションでは重要なものだ。儀礼を尊重することでお互いが相手にとって危険ではないことを伝えることができる。

相手のスキルの低さや成果物の品質の低さを指摘することは無礼なことと感じる人が多い。これはマウンティングと一緒で、「お前は弱く、無能で、自分の言うことを聞かなければならない」というメッセージを受け取ってしまっているからだろう。人は多分、本能的に自分を支配しようとする人、支配できる人には脅威を感じる。

マウンティングメッセージは送り手が意図的に込めることもあるし、防衛のため、無意識に込めることもある。また、メッセージの送り手がマウンティングを意図していなくても、受けて側が勝手にそう受け取ることもある。だから、礼儀正しく、相手を批判しないことは安全なコミュニケーションになる。

また、礼儀正しさは、他人の想定外の行動や期待と大きく外れた行動や反応をしない、ってことでもある。自分は研修の仕事をしているけど、例えば、講師が丁寧に説明しているのに、話を聞かずに別のことをしていたり、演習中に泣き出してしまったりするのは「礼儀正しくない」。

礼儀正しくすることのリスク

礼儀正しさは、社会的期待に合致した行動をとること、もしくは、そうできる能力を示すことで「安全に、不安なく」コミュニケーションをとる方法であるといえると思う。ただ、それは多くの場合、本当に起きている生の出来事を多少歪ませることで達成していることが多い。初めて取り引きする取引先にも「お世話になっております」と必ずつけるメールのマナーなんかは、その典型。

こうした礼儀正しさは、切迫した、創造的な思考や行動を阻害する可能性がある。現実と乖離したコミュニケーションが増えると、複雑な場では人々は現実をコントロールする力を失う。上位マネージャは儀礼的なコミュニケーションからは全く現実が把握できなくなり、何が起こっているか分からなくなる。

マイケル・チェーホフという演技教師のメソッドを学んだとき、ファシリテーターだった方はワークショップの場で愛想笑いや、儀礼的なハグのようなものを徹底して排除していた。参加者たちは非常に集中して、今場に起きていることや自分自身に起きていることに自覚的になり、学び易い環境になったと思う。

チーム内コミュニケーションの心理面の不安などに対処するために、礼儀正しさを強調すると欺瞞が増える可能性があるのだ。もちろん、例えばサッカー選手が年上の選手のことを「~君」と呼ぶように、特殊な礼儀を導入することでそれに対処する方法もあるだろう。

起きている現実に対処すること

レビューなどを含むチーム間のコミュニケーションで問題が起きているのであれば、それを礼儀正しさを強調することで対処して現実を隠すのではなく、現実に起きている事象に試行錯誤しながら取り組んでいった方が益が多いと感じる。

例えば、レビューなどの場でチームで期待された水準に達していない成果物であることが判明したときに、レビューイが「傷ついた」場合、いくつもの対処しなければならない事象がある。レビュー以前にスキル不足やリソース不足が判明しなかったのはなぜか、判明しても対処できなかったのはなぜか、そのほか、レビューの結果を個人的に受け止める必要はない、ということやプロとして仕事の評価を受けることは当然である、という認識の不足。チームとしての結果にフォーカスできていない環境などなど。

高スキル者が強い言葉で相手を批判する場合なども、何が起きているか、どうしてそのような行動パターンをとるのか、を理解すれば大抵の場合対処は可能だし、対処方法が分からなかったとしても、現実の問題を高スキル者と共有すれば改善してもらえるものだ。単に言葉の選び方を知らなかったり、問題を認知できていなかったりするだけの場合も多い。

例えば先に挙げた、講義を聞かない受講者の場合、かなりの確率で話についていけず、理解できていないことが原因だ。自分としては、話を聞かなくてもいいから、相当初期の内容を復習するように指示することが多い。（わが身を反省しつつ。。。）ここで、分からなくても聞け、というのは学校の教師がよくやることだが、学習に何のメリットもない。

礼儀正しさを強調して、表面上の心理的安全性を達成しても、「見えないルール」や「欺瞞的なコミュニケーション」が増えればチームの能力に悪影響を与えるリスクがある。

儀礼はコミュニケーションを密にできない人々や複雑性に対処する必要のない場合には有効だ。店頭での商品の売買などは儀礼を適切に使えるシーンだ。ソフトウェア開発はその真逆の状況だと思う。

ちなみに、原因を理解しようとして分からない場合は、分からない、ということを認めてパッチワークをすればいい。原因は大抵複合的だから、対処法はやってみないと分からないことも多い。問題の定義をすることの方が何倍も重要だ。