今日こんなかんじの会話があって、レビュータイム導入した時のことを思い出したので、適当に書こうと思う。
ひさいちレビュー、必ず通すみたいなの良いのか悪いのか
— ひさいち (@hisaichi5518) 2014年3月13日
@hisaichi5518 マジレスすると、そのような体制にしておくとスケールしないので、最初の段階では必ず通すというルールにしつつ、他の人がレビューしても大丈夫に出来るように、レビューの練習を同時にしていってもらうとしないといけなさそう
— 柴崎優季 (@shiba_yu36) 2014年3月13日
@hisaichi5518 今のチームで新人が入った時は、レビュータイムというのを必ず設けてその時間には最低限どれか一つレビューするというのをやってもらってる。でも慣れるまではこれまでチームにいる人がレビューしないとmergeしないということにしてる。
— 柴崎優季 (@shiba_yu36) 2014年3月13日
@hisaichi5518 そうすると同時に新人とベテランがレビューするので、こういうレビューの仕方をすればいいのかという教育にもなるんじゃないかと思ってる
— 柴崎優季 (@shiba_yu36) 2014年3月13日
@hisaichi5518 なんでレビュータイム設けてるかというと、そのほうが新人でもコードレビューに参加する障壁を減らすためでした。うちでは全レビューは負担が大きすぎるけど、そういうの設けないと自分がやっていいのかなっておどおどしてしまうと思うのでって感じ。
— 柴崎優季 (@shiba_yu36) 2014年3月13日
レビュータイムの最初の導入
レビュータイム導入以前は、チームにいるベテランの人がほとんどのコードのレビューを行うという状態になっていた。その結果、レビューがあまりにも負担になってしまっていて、ベテランがコードを書けないという状態になってしまっていた。実際そのころは僕自身もレビューをあんまりできていなかった。
なんとなくこのままじゃいけないなと思って、この問題を解決しようといろいろ考えてた。まずなんでベテラン以外がレビューしないのかなと思っていろいろ考えてみると
- ベテランは自分がコードに一番詳しいので仕方なくレビューをする
- それ以外の人は自分はベテランよりはコードに詳しくないと思って、レビューをためらう
という状況になっているように感じた。
とはいえ、結局レビューしてみないといろいろ詳しくならないだろうし、結局一人がレビューしまくるという体制だとどこかで無理が来るだろうと思ったので、じゃあレビュータイムという「仕組み」を導入して、みんなでレビュー出来る体制をやってみようと考えた。
- 昼休みが終わったあと一人最低 1 Pull Requestをレビューする
- 自分がその部分にあまりにも詳しくなかったら、詳しそうな人にもレビューをお願いする
結果として
- レビューの偏りは前より減った
- レビュワーのコードの詳しさのばらつきによるレビュー精度の低下みたいなのは懸念していたが、特に問題になるほど精度が落ちることはなかった
- レビューによって自分が関わったコード以外も少しずつ詳しくなっていった
という状況になった。問題の解決としてはそこそこうまく機能したかなと思う。
レビュータイムの消滅
導入後数ヶ月くらいして面白いことになった。それはレビュータイム以外の時間で、チームメンバーで少し手が空いた人が積極的にレビューを行うという状態になった。また反対に昼休み終わったあとにレビューをするということをそんなにしなくなっていった。それでもレビューが誰かに偏るということや、レビューが溜まり続けるということは無かった。
僕自身は導入しようと思った時にこういう状況になるとはあまり思ってなかった。けれど実際にはこのような状況になった。
なんとなくこれをみて「仕組み」っていうのはうまく回ると、チームの「文化」になって、「仕組み」自体の役割を終えることもあるのだなと感じた。非常に興味深い。
こうしてレビュータイムは消滅した。
レビュータイムの再導入
その後また数ヶ月くらいたって、今度は新しい人がチームにジョインした。そうするとまた新しい人がレビューをためらうという問題が発生した。
このためらいをなくすようにするため、もう一度レビュータイム導入することになった。その時はまだ新しい人はレビューをすること自体に慣れていなかったので、昔のレビュータイムの仕組みにちょっとだけルールを追加してやってみた。
- レビューの時間は一人一つ必ずレビューする
- 新しく入った人がレビューしたものは必ずこれまでいた人も同時にレビューする
新しく入った人がレビューしたものは、必ずこれまでいた人もレビューを行うようにした理由は、同じものを一緒にレビューすることでどうやってレビューするのかという部分を勉強してもらえるのではないかと思ったからだ。まだ導入してそんなに時間は経ってないので、これがうまく行ったかどうかはよく分かっていないが、レビューのためらいをなくすということと、レビューのやり方に慣れてもらうという観点ではある程度うまく行くのではないかと思っている。
感想
こういうことがあって、仕組みは単に導入していくのではなくてうまく文化にしていけるようにしていけると、チームとしてもうまく回るのかもしれないと思った。文化を醸成する上でうまく機能してくれる仕組みをきちんと考えていきたい。
また、昔は別のところでいろいろ仕組みを導入するということをやった結果、その仕組みの目的が忘れられて、仕組み自体に縛られてただやらされているだけということになったことがあった。実際には目的を見失わず、その目的が他で達成できたならもう仕組み自体も破棄するとか、また似た問題が起こったら少しだけ仕組みを変えたりしながら再導入するとか、ある程度柔軟にやっていかないといけないなと感じた。
結構いろいろ考えることはあるけど、少なくとも僕はチーム内にいるメンバーになんの助けもなく、「なんでレビューしないの?意識低いの?」みたいな圧力をかけてなんとかするというのが好きじゃない。なので、こういう風に最初の方はうまく仕組みでヘルプを出して、ためらいとか障壁がなくなるようにサポートするようにしていきたい。