いいチームとはどういう状態か。

2021-12-10

この記事は、ryokatsu Advent Calendar 2021の10日目の記事です。

今年1年振り返るとあまり仕事でリードをするような仕事はなかった。。リードのスキルを保つためにも自分の考える「いいチーム」について書こうと思います。

いいチームとは

色々ありそうですが、自分は「余計なことを考える必要がなくコーディングに集中できること、いいコードが書けること」が出来ていることがいいチームだと考えます。

余計なことを考えることの障害

「心理的安全性」というやつです。よく言われるのが、「共通認識をチームメンバー全員で揃える」「謙虚、尊敬、信頼」などでしょうか。特に「謙虚、尊敬、信頼」の一つでも欠けているといいチームとは呼べなそうです。このあたりは、Team Geekという本を読むと理解が深まります。

エンジニアというか人間は、途中のものを人に見せることが不安だと思うことがあります。何故不安になるのかと言うと、完成する前のコードを人に見せたときに、見せた人が自分のコードを見て言葉には発しないけど「勝手に各付けされれしまう」という不安を持つことが原因にあるなと思います。心の中で「あーここの処理ちょっと複雑すぎるし何書いてあるかわかんないな。。」とか「このメソッド使ったら楽に書けそうだけど知らないのかな」と思うことはよくあります。

これは別に間違った感情ではないので問題ないと思いますが、常に相手に見せるのが不安だと思う人がいるとチーム開発のコストは高くなってしまいます。

不安と思ってしまう。
完成するまで見せない
仕事の進捗が不明瞭になる

と言った感じでどんどんリカバリーが難しくなるのでチーム間で「謙虚、尊敬、信頼」をしっかり定着させることが大事です。とりあえず途中まででいいからdraftのPRを出すというのは実はとても大事なことだなと思います。

ペアプロ

ペアプロ自体はとても良いことだと思います。しかし時にはエンジニア同士のペアプロは避けた方が良い場面があるなと思っています。エンジニア同士のスキルのばらつきがある場合は、お互いのスキルを知った上で行うことで成功する可能性は高くなります。これが知らない状態でスタートすると失敗するケースが多いです。なのでチーム間ではスキルセットをお互い把握することが何よりも重要だと思います。

そもそもスキルセットの把握がない状態でペアプロするケースはあまりないかも知れませんが、お互いの思考が異なるタイプのペアプロも避けた方が良いです。こういう場合は、あえてペアプロはせずに

まず実装内容をお互い確認する
お互いの持つ「観点」でそれぞれ実装をする
実装完了のタイミングで集まって議論する

のようにした方がペアプロの時間で失敗するコストを事前に避けれそうです。議論する時間のコストは個人的には、チーム開発にとって一番重要な時間だと感じるので納得がいくまで時間を取ってしまっていいと思っています。

知識の共有

単一障害点というのがあります。例えば「この実装は他の人が実装するより自分がやった方がはやいから実装しちゃう」みたいなケースです。これは短期的にみると効率がよく最適化されていますが、長期的にみるとナレッジが共有されていないのでボトルネックになってしまいます。なのでチーム間での技術的な共有は、ドキュメント（Wikiのようなもの）があると良いと思います。メンテされないあるあるが発生しないためにリーダーがサポートすると良いと思っています。

細かい言葉遣い

チーム間でも言葉遣いを気をつけることが大事です。よくあるものだと以下でしょうか。

驚いたこと「え！？マジで？」のようなふりは心理的安全性を下げるのであまり言わないようにする
MTGの際に会議の決定権や責任がないのにも関わらず口出しして腰を折ったりすることはしない
「簡単じゃん！〇〇だってできるよ！」のようなバイアスがかかった発言は心理的安全性を下げる可能性がるので言わないようにする

錯覚

「自分のスキルを発揮でき学びもあるいいチームだ！」ではなく「スキルを発揮できるけどぶっちゃけ楽ができるいいチームだ」と捉えていないかをチームメンバーで確認することも必要かなと思います。少しでも違和感があると長期的にみるとボトルネックになると感じます。

リーダーとして

自分は、楽しくコードを書けることを第一に考えるので、それができていないメンバーが仮にいたとしたら、全ての優先度の中で最重要として取り組むと思います。どう取り組むかケースバイケースなので省きます。また、リーダーだから全てできるとは全く思わず「分かんないことばっかり教えて！」と素直に質問しまくれる関係性も作ることも大切です。