エンジニアとしていくつものチームを経験してきましたが、どのチームにも「これが当たり前」と思っているルールがあります。スクラムのやり方だったり、コードレビューのフローだったり。ルールが暗黙化し、その妥当性が見直されないことが多いと感じます。
ルールは陳腐化する
エンジニアは日々成長し、チームも新しいメンバーが入ってくればできることも変わります。プロダクトも進化すれば、取り巻く技術も刻々と変化していきます。このように、ルールの陳腐化は避けられません。システムと同様に、ルールも定期的なアップデートが必要だと考えるようになりました。
例えば、「PRのレビューは必ず2人以上」というルール。かつての品質課題への対応として作られましたが、今ではチームの習熟度も上がって、もっと柔軟なやり方があるかもしれません。
借り物のルールは根付かない
他のチームで上手くいってるプラクティスを取り入れたくなる気持ちはわかります。でも、そのまま持ってきても上手くいかないことが多いです。理由は単純で、同じ人がいないように同じチームも存在せず、どのチームにも独自の文化や特性があるためです。
隣のチームでの「当たり前」が、うちのチームでも「当たり前」になるとは限りません。むしろ、その「当たり前」の差こそが、チームの個性や強みだったりします。
例えば、あるチームではモブプログラミングが素晴らしい成果を上げているとしても、それはそのチームのメンバー構成や、培ってきた対話の文化があってこそなのです。安易に真似するのではなく、私たちだったらどんなやり方が合うのか。そこから考え直す必要があります。
制約が創造性を育む
面白いのは、適度な制約があることでチームの創造性が高まるケースがあるということです。例えば「PRのレビューは2時間以内に」というルール。これを単なる制約として捉えるのではなく、「どうしたら自分のタスクを処理しながらレビューの時間を捻出するか」「どうすれば素早く質の高いレビューができるか」という創造的な課題として考えます。
すると「レビュー依頼を見落とさないように可視化するツールを導入しよう」「レビューしやすいPRの粒度について考えてみよう」といった具合にチームから面白いアイデアが出てきたりします。
自分たちのルールを育てる
最初から完璧なルールが思いつくことはないので、まずは暗黙的なルールを挙げてみたり変えてみたりするところから始めました。私たちのチームでは週次の振り返りの時間でルールのアップデートを行っています。まだチームとしても伸びしろがありルールも発展途上ですが、列挙されたルールがそのままチームの状態や成長を表しているように見えて興味深いです。
結局のところ、大切なのは「このチームらしさ」を見つけていくことです。他のチームのプラクティスは、あくまでもインスピレーションの源として捉えます。そして、チーム独自のリズムやルールを、メンバーと一緒に育てていきます。
そうやって育んだ「自分たちらしいルール」は、チームの文脈に根ざしていて、メンバー自身が必要性を実感できるチーム文化となります。このように自分たちでルールを育てていくプロセスが、それぞれのチームメンバーとして探究を続けられる土壌作りにもなっているのではないかと思います。