🏢

チームビルディングに向けて考えたこと

2023/06/17に公開

チーム開発

チームビルディング

心理的安全性

idea

概要

「心理的安全性」という言葉が世に広まり始め、自分の周りでもよく聞かれる言葉となりました。

そうした中で漠然と聞いた、その言葉のそのままの意味でとってしまっていた自分は、
「心理的安全性とは何か？」と聞かれた時に「これ」といったものを言うことができるか？と自問した時に
答えられないなと思い

じゃあ、心理的安全性を担保するために、実際に何を行動しなければならないか、担保するものと不安に感じる人の間の心理、ギャップに興味を持ちました。

まだ「これ」といったものを見つけれてはいないですが、チームごと、会社ごとにそれは変わるものだし、正解はないものというよく聞く言葉で締め括られるだろうということは想像できます。

しかし、その過程の思考を垂れ流す形で当記事を書くことにしました。

自分がEMを目指す工程で、当記事が誰かにとって一つの思考、行動の参考になればという気持ちも込められています。

技術力志向の会社で発生するかもしれないこと

技術志向の高い気質の会社を例に出してみます。

ここでいう技術は、テクノロジーに関連するようなものを指します。例えば、Webフレームワークであったり、サーバであったり、DBなどが当たります。

コンプレックス

技術力が高く、とても高い水準で設計をされていたり、技術の選定を行う会社の中にも当然、技術的にまだ未熟な人もいると思います。

そういった人は、技術力に対して社内でコンプレックスを抱えることになります。
そして、人というのはコンプレックスや問題意識が技術力に行きがちなので、技術的な話題にとてもセンシティブになります。

確固たる自信のある技術の指針がある人にとってはなんでもない一言でも、技術力にコンプレックスを抱える人には多分に大きなダメージを与えることがあると思います。

言葉の力って壮大ですからね。

そういった状況が起こると心理的安全性が個人単位で下がり始めるようになると感じました。

どうするか

では、そうならないためにどういった対応がとれるかについて考えてみます。

まずは

特定の人に対する技術力の低さに対する批判、指摘をしないこと

当然ですが、言われて良い気分になる人はいないと思います。

技術力が低いということは、質問も多くなります。

よく聞く話で、質問する時はちゃんと調べて、段取りを持って質問に挑むべしと言う話がありますが

開発をしてる中で、納期が刻々と近づき、調べても八方塞がりになり追い詰められた状況で冷静にそんな段取りを取ってる余裕がなくなってくるのも技術力が低い人にありがちです。

「調べる」という言葉を、「ある程度全体が見えてる人が細部を覚えてないからググる」のと同レベルで考えてはいけないということです。

なので、調べが甘かったり、調べても分からないということは往々にしてあります。
解決できずに泣く泣く質問してきている場合があります。
そんな時に、「もっとちゃんと調べてください」などと言われたら、傷に塩を塗るような行為になります。

そこで、言葉や行動を選ぶ必要があり

まずは、

やってみせること
一緒に調べて出てきた記事を読んだり、一緒にドキュメントを調べてみること
どこに目をつけているかを口に出したり、その情報を引き出すための行動を見せながらやること
を行い
「今の様な手順で行うと良い」という指標を見せることが重要だと思いました。
まさに思考の垂れ流しを見せて聞かせるだけですね。

それ以上でもそれ以下もなく、それをするだけに留めておくべきです。
余計な一言を言わないために、「自分ならこうする」を見せるだけで良いと思います。

自走する方なら、百聞は一見にしかずでその一見があるかないかで行動が変わります。
そうでなかったとしても、何度か見せ、その工程を質問者にもやってもらうということをすれば、多くの人にとって体に染み込むことになると思います。

デメリット

当然、上記の工程は作業の手を止めて行うことにより、かなり時間もかかるし労力もかかるので
長期的な目線を見据えた行動になると思います。

しかし、それをすることにより心理的安全性が少しでも上がり、長期的な目線での活躍に繋がるのであれば、それはかけて良い労力として天秤にかけてもいいのではないかと個人的に思っています。

1on1で話すこと

1on1は基本的に、仕事の話をするべきではないと思っています。

「仕事の話」というのは、「まさに今手をつけているタスクの話」ということであって、
働く環境についてやこういうことを仕事でしたいという話は歓迎になります。

では、そこで得られた情報をどう使うか、もしくは1on1をしてもらう側としてはどういう情報を提供すべきかについて考えてみます。

1on1をする側

1on1は、基本的にその人の本質を理解するための場であると理解する必要があると思っています。
どんなことをしてきて、それに対してどう思っていて、これからどうしていきたいかの材料を集める場です。

EMとしての立場としてその情報を集めることは一番重要なタスクになると思っています。
なぜなら、そこで得られた情報を基準にキャリアや、タスクを考えることをしないといけないからです。

例えば自分を例に自分自身を1on1したと仮定したシチュエーションを作ってみます。

1on1をする人(レビュアー) 「普段どんなこと（趣味）をするの？」

1on1を受ける人(レビュイー)「ゲームとか好きですね」

レビュアー「へぇ、どんなゲームやるの？」

レビュイー「建築ゲームとか好きですね。地道にコツコツ積み上げていくのが最後の達成感を強く感じれて楽しいです」

レビュアー「なるほどー。でも結構積み上げる途中はいいけど、最初にどんなものを作らないといけないか考えるのとか大変じゃない？」

レビュイー「いや、むしろその時間が楽しいですね。どんなものを作るかを考える時に、それを見せる人の驚く顔とか考えると燃えますね」

レビュアー「あー、なるほどねー。じゃ、大きいものを作ろうとかすごいものを作ろうっていうことが多いの？」

レビュイー「そうですね。よりすごいものを作ってやろうっていう意識でやることが多いです」

ここまでにしましょう。
パッと見、平凡な会話の様に見えます。
レビュイーにとっては好きなゲームの話ができるので楽しいと思っているかもしれません。
では、上記の会話から得られた情報をまとめてみます。

建築ゲームが好き
コツコツ積み上げることに苦がない
モチベーションとして完成後の想像ができている
そのモチベーションを作るものの大きさに比例して高まる
質問に対して、一言で返すのではなく、ちゃんと自分の意思を付け加えて返事をしてくれる
(その時の声の調子によって)ゲームの話をする時は声が高まる、熱が入る

ざっくりとこのような情報が溜まりました。

建築ゲームが好きという情報は、何かに役立つかというと、これは付加価値です。
つまり、別の1on1中などで繋がるところがあれば深掘りするための材料です。
しかし、それ以外に関しては結構仕事にも繋げられそうな感じがありますよね。

ここで注意点として、「これ一回で情報が集まった！よし、じゃそのタスクをアサインしてやろう！」という安易な行動は良くないと思っています。

まだまだこれ一回では情報不足です。
例えば、大きい仕事をやるのが好きなら大きい仕事をいきなり割り振るなんてことをするのはお互い危険なことですね。
それには以下の様な情報が必要になってきます。

その人のストレス耐性
何に対してストレスを感じるか
仕事にした時、それにまつわるバックグラウンドの知識や経験があるか
その人が感じている感情はどこで判断すればいいか
(例えば、進捗が危険となっている時にアラートが出なくても多少なりその雰囲気を感じることができるポイントはどこかなど)
どんな人と働くと良さそうかの相性

ざっくりとこんな感じになります。
これは、この一回の1on1で行う必要はないです。
何度か1on1を通して、上記であげた情報より多くの詳細な情報を集める必要があります。

そのためにも、1on1の頻度というのは重要になってきて
あまりに期間が空いたり、少なかったりすると、そこで得られた情報の鮮度が落ちてきてしまいます。
そうなっては、1on1をやってる価値があるのかどうかさえアヤフヤになってきてしまうので、効果的ではないと思っています。
なので、できれば週に1回、低くても週に2回程度を行うのが良いような気がします。
熟練のエンジニアであれば、そこまで頻度の高い1on1はしなくても良いかもしれません。
そこは調整しても良いと思いますが、いずれにしても熟練とか関係なく、新しく入った人に対してであったり、新しくチームに入ったEMの行動としては、週1くらいが理想のような気がしています。

ここで、情報収集の技量が問われると思っています。
技術的なことであれば、ドキュメントを読むことで情報は得られますが、こと人間相手となると事情は違ってきますし、自分のペースで進めることができないことがあると思います。
いかに、その人のペースで話をしてもらい、そこから情報を収集するかがキーとなってくると思います。

1on1を受ける側が提供すべき情報

上記は、レビュアー側の視点で、情報収集の観点で書きましたが、今度は1on1を受ける側の考えとして書こうと思います。

働くからには、気持ちよく働きたいというのは人間心理としてあると思います。
そのためには、ただその環境を口を開けて待っていてはやってこないと思った方が
期待通りにならないショックは少なくなります。

そのために、自分ができることを考える必要があります。
その一つが、1on1での情報提供になります。

上記の通り、レビュアーは情報を集めようとしています。
それは、気持ちよく働くための環境を作るためにやっているものなので
気持ちよく働きたい側との利害が一致します。
それに対して協力的になった方が、お互いwin-winということになります。

そこで提供すべき情報として

自分のバックグラウンド
何に関心があるか
現在の不安など
仕事の中でやりたいこと
普段の行動

ざっくりとこの辺りから始めるのが良いと思います。
一回で全部を伝え切ることはしなくても大丈夫で、少しずつでいいので、上記にまつわる自分の身の上話などを入れていくといいかもしれません。
自分の話をしたくない！という人にとっては難しいことかもしれません。
そう言う時は、最近読んだ興味のあった記事を共有したり、それを読む中で思ったことなどを共有するのがいいかもしれません。
それを聞いたレビュアーは、この記事のどこに興味を持ったかというところから深掘りすることができます。

よく面接とかで、レビュアーが「最近気になる技術はありますか？」という質問があるかと思います。
その質問の意図は人によると思っています。
例えば、

自分が知らない技術を提供してきた時に得をするから
最新の技術をキャッチアップすることに関心があるか確認したいから
(その技術を仕事で活かすために調べているのであれば)普段から業務に関心があり、より良くしようという意識があるかどうかの確認をしたいから
その技術に興味があるということは、どの領域に興味があって、どういうことをしたいかを知りたいから
などなどがあると思います。
これらの情報は1on1で得る情報としても有益だと考えています。
レビュイーは深く考える必要はありませんが、最近気になった記事を提供するだけでも非常に役に立つ材料になりうるという意識があるだけでも1on1の効力は変わってくると思います。

フィードバックのやり方/頻度について

フィードバックは、どの分野においても非常に重要な工程だと思います。
当然、エンジニアにとってのフィードバックも大事なことで
大々的にフィードバックとしての工程を用意せずとも、振り返りなどを行う工程で小さめのフィードバックを行うことは重要になってくると思います。
それにより、小さいスパンでの心理的安全性の担保に繋がる即効性のある方法だと思っています。

よく言われる話として、「褒める時はみんなの前で、注意する時は個人的に」という話があります。
そのままの意味ではありますが、振り返りで行うような個人のフィードバックはプラスなものが望ましいです。
振り返りの場面でマイナスなフィードバックもあっても良いと思いますが、それは個人に対してではなく仕組みに対してものであるべきというのが理想のように思います。

フィードバックを受けた方は、「このやり方で良いのだ」という確認が取れたり、「あれ、あまり効果が出てなかったのかな。ちょっと次スプリントでこのように改善するのでどう思うかまた教えてください」などの改善を図ることができると思います。

良かった時は続けること、ダメだった時は改善を行えば良いというだけの話になり、手軽に個人単位で試せる改善が増えてくると思います。
それは結果として心理的安全性に繋がります。

コードレビューにおける心理的安全性

コードレビューは、コードの改善のために第三者の目でフィルタリングする作業であると同時に、
仕様に沿っているかのためのチェック作業と僕は思っています。
ですが、僕はもう一つコードレビューを一歩進めたいと思っています。

どういうものか話す前に、どういった指摘がありそうか見てみましょう。

ここの仕様、nullが入ることが考慮されていないみたいですが、バグの原因になりませんか？
このコードだと、仕様書のこことマッチしてなさそうなので確認をお願いします。
このコードはちょっと読みにくいので、処理を分割するなどをして読みやすくしてください。
などなど…。

そのどれもありそうですし、しっかり指摘すべきところを指摘しているものと思います。
しかし、僕はこれだけを行うことはチームとしての結束には繋がらないと思っています。

つまり、「良いところ」はコードレビューでもどんどん褒めましょうということです。

ここのコード、以前の指摘を踏まえて改善されてて良いと思います。
このコード複雑なのに、理解しやすいコメントをつけてくれてありがとうございます。
他の人も参考にできそうなコードですね。
などなど…。

単純にレビュアーが思ったことを書けば良いと思います。
良いものには良いと言って損はないと思いますし、言われた方はもしかしたらそのコードを書くために、裏で勉強を頑張った背景があるかもしれなく、褒められるととても嬉しい気持ちになると思います。
当然コードを書く意欲も上がると思いますし、自分が貢献していると思えるコスパの良い行動の一つだと思います。

ここで変に、「自分の方が良いコード書ける」だとか思ってしまい、思うだけに留まらずコメントに残したり直接言ったりすることはレビュイーからすると気持ちのいいものではありません。

一つ参考になるなと思ったものとして
ちょうどこの記事を書いてる途中に読んだ記事で以下のようなものがありました。

記事自体も素晴らしいのですが、レビューのやりとりがすごく結束力高いなと感じました。
お互いが尊敬の気持ちがないとこういったレビューのやりとりにはならないと思います。
片方が一方的に指摘して、それに従うだけの関係では良いレビューにもならず、指摘内容によっては辛い思いをすることもあるかもしれないです。

指摘と同時に、良いと思ったところは褒めるというのは、その場では少し時間もかかることと感じてしまうかもしれないですが、長期的に見た時にお互いにとってメリットのあるコスパの良い行動だと思います。

まとめ

いろいろ書いたのですが、結論としてみんなが働きやすい環境になればいいよねっていうことが言いたかったです。

組織には、多種多様な人間がいます。
○○が得意な人もいれば、××が得意な人もいます。
そういった環境の中で、1on1を行い、その中でどのような話をするかについて深掘りしたり、コードレビューにおける行動を少し変えるだけで、幾分か誰もが気持ちよく働ける環境になれるのではないかと思っています。

今回は、プロジェクト遂行戦略というよりは、その戦略を行う上での心構え的なところにフォーカスを当てたものになりますが、最近私自身が学習しているアジャイル開発においても、上記のような行動はとても有効に働くのではないかなと思います。

是非、参考にしていただけると嬉しいです。