チームの能力はそのチームが経験することに依存するのでそう簡単に伸ばせない

チームの能力はそのチームが経験することに依存するのでそう簡単に伸ばせない、という駄文を書いてみる。

例えば、テストを書いていないチームにシニアエンジニアがジョインして諸々を整備したり啓蒙したとしても、チームがテストの有用性について経験していないためテスト文化が浸透しづらくテストカバレッジが思ったより上がらない、ということがよくある。

一方でテストコードで防げたはずの手戻りやインシデント、ミドルウェアやライブラリのアップグレード時の苦難をチームが経験するとテストを推進しやすくなる。ビジネスインパクトの面でステークホルダーへの説明もしやすい。

書籍や登壇資料、Web記事を読んでインプットすることは非常に有用だと思う一方で、それよりは経験から学ぶことが大きいし今後のその人の考え方やキャリアに強く影響する。パフォーマンスやセキュリティ、保守性の問題を経験したエンジニアはその問題に対して強い感度や考えを持つ、という感じ。また、個々人が今まで行ってきた経験よりも、そのチームでの歴史的な経験がチームの考え方に強く影響を及ぼしている。そのため、どんなにシニアエンジニアの経験値や実力が凄かったとしてもチームの能力は、そのチームが経験することに依存する。

チームが学習するためには、ただ単純に「経験」するだけではなく「経験」の後の「振り返り」とその次の「アクション」が重要だったりする。どんなに手戻りやインシデントを経験してもそもそも振り返りをしていなかったり、振り返りに対応するネクストアクションが未熟だと何も変わらない。

例えばテストコードで防げる不具合に対する対策として手動テストの項目をむやみに増やしたり（もちろん手動テストも大事なんだけど）、オペレーションミスに対してシステムや運用フローによって認知負荷を下げるような仕組みを考えずにひたすらにダブルチェック・トリプルチェックとやってしまうと（もちろんレビュープロセスも大事だけど）やはり学習機会にはつながりづらい。

シニアエンジニアの振る舞い

シニアエンジニアが環境を整備したり啓蒙することはもちろん大事なのだが、一番大事なのは失敗しやすい土壌を整え、振り返りを促進し、アクションを提案し、チームとして強くなるきっかけを作ってあげることなのではないかと思ったりする。

小さく早く失敗し、振り返り、学習することがチームにとって重要なので、それを整えてあげたり率先してその姿勢を見せるのもシニアとしての振る舞いとしてよいのかもしれない。

余談

チームの状態に依るのだが、コードレビューに関しては個人的な意見はもちろん述べつつも大きな問題がなければ通すことがある。その設計でうまくいけば良いし、もしうまくいかなかったらそれがチームの経験になり、それを振り返り、改善することで学習につなげることができるからだ。意見を矯正しすぎてしまうのは個々人やチームの成長機会を奪ってしまうような気がしている。IMOなので参考にしてね、くらい。もちろんリスクが大きいもの、切り戻しがしづらいものに関してはしっかりとレビューをしている。