初めに
入社して四ヶ月が経った。
私の部はチーム形成にかなり気を使っているように思えた。
おかげで、チーム全体の雰囲気が良いし議論も遠慮をせずに活発に行われているように思える。
そんな私のチームだが、どうやらTeamGeekという本がチームのあり方の考え方の一つになっているらしい。
そこで、TeamGeekを読んでみて実際に感じたことや私のチームが行っている行動を併せて書いていこうと思う。
チーム開発を行う意義
TeamGeekで初めに書かれていたことはチームで開発することの意義についてだ。
まず、元来プログラマは1人で開発したがるということを次のように述べている。
プログラマは人にバカだと思われたくないからコードを隠したがる。
研修当初の自分はまさにこの考えだった。
完璧なコードが書けていないことを自覚しているものの解決方法が分からない。
しかし、こんな単純なことで質問したら失望されるのではないかという思いから手が止まってしまい、無駄に時間を使ってしまってそれを指摘されていた。
ただ、私のチームの心理的安全性の高さに気づいてからは質問をためらうことが減ったと思っている。
心理的安全性とは、組織の中で自分の考えや気持ちを誰に対してでも安心して発言できる状態を指す。
私のチームが心理的安全性を保つためにどのような施策を取っているのかについては後述していく。
ではなぜ、対人的リスクを負ってでもチームで開発する必要があるのかということを、この本では1人で開発することの問題点を挙げて次のように述べている。
1人でコードを書いていると失敗に気づけないためリスクを孕む。そのためにチームを組む必要がある。
至極当然であるが大切なことだ。
1人ですべてのミスに気づき、その解決策を完璧に考えられる人間はそうそういない。だから私たちはチームを組む。
私のチームではこのリスクを避けるためにコードレビューを毎回行っている。レビューされていないコードは現場では使われない。
また、このコードレビューはミスの防止だけでなくコードの書き方の改善にも役立っている。よりシンプルな書き方を知っている人からはその知識を吸収できるし、レビューしている側も他の人のコードを読み解くことで新たな知見を得られる。
このように、失敗のリスクを避けたりより良いものを作っていくためには多角的な視点を持つ必要がある。
そして、そのためにはチーム開発というものは避けて通れない関門なのである。
チーム開発で気をつけること
チーム開発のメリットは判明したが一方で、対人関係が付きまとうというデメリットも抱えている。1人での開発ではなかった新たな悩みの種だ。
TeamGeekではその悩みの原因を以下のように述べている。
あらゆる人間関係の衝突は、謙虚、尊敬、信頼の欠如によるものだ。
チーム開発の一番の問題点はこの3つの欠落に起因するというのだ。
というのも、より良いものを作ろうとする中で批判というものは避けられないが批判をする側もされる側も「謙虚、尊敬、信頼」を持って接することでチームの和を保てるとのことだ。
具体的な例として次のような言葉を述べている。
君は君の書いたコードではない
この言葉の意味するところは、自分の書いたコードが批判されたからと言って自分の人間性を攻撃されたと誤認してはいけないということだ。
レビュワーのコードへの批判はより良いものにするための提案であるので、レビューをされた側はレビュワーを信頼して批判を受け止めなければいけないし、レビュワーは謙虚に指摘をすることでチーム内の軋轢をなくすことができる。
私はいまだにレビューで指摘を受けると身構えてしまうが、レビュワーへの信頼を深めることで批判に対し真摯に対応していきたいと思う。
また、チーム内でのコミュニケーションのあり方については以下のように述べている。
コミュニケーションの原則は同期コミュニケーション(MTG等)を減らし非同期コミュニケーション(チャット等)を増やすことである
この理由は、非同期コミュニケーションはログが残るため以前なされた議論を無駄に再度行ってしまうことがないためである。
私のチームではTeamsなどでの非同期なツールのやりとりが活発であり、口頭などのやりとりで決まったことなどは非同期なものに上げておくことが推奨されている。
おわりに
現代においてチーム開発というものは必要不可欠なものである。
そして、よりよいチームを作るためにはチームリーダーだけでなくメンバー1人1人が意識をする必要がある。
それは小難しい原理などではなく、メンバーと接する際に"謙虚、尊敬、信頼"を忘れないという単純な試みで達成できることだ。
この単純だが簡単ではない課題を胸に留めておくことで、これからもチームを形成する一員として働きたいと思う。