アジャイルチームでコードレビューを実施する上での障害と対策
このエントリは アジャイルCasual Advent Calendar 2014 の 3 日目のエントリです。
前日はa_suenamiさんのPDCAに関するお話でした。
"アジャイルチームでコードレビューを実施する上での障害と対策"
ということで、現場で自分が今まで試行錯誤をさらしてみようと思います。
プロジェクト中にコードレビューを行って、実際に困った事とそれに対して試行錯誤しながら行ってきた対策をあげていきます。
どのようなレビューを行っているのか
いきなりレビューがうまくいかない話をする前に、どんなコードレビューをしているのさ？って話を少々。
- チケット駆動で開発する
- タスクはコーディングチケットとレビューチケットの二つがセット *1
- レビューはコードを書いた本人以外が行う
他にも細かく書くと色々あるけれど、ざっくりいうとこんな感じになります。
障害その1 『レビューの工数が取れない』
『レビューをしていたら遅れちゃうよ。』とか 『そんなコストかけてられないよ。』といった事態です。
対策：見積の時点でレビュー工数を見積もっておく。
最初からコードレビューは必ずやるって決めていればその分も見積もるし、スケジューリングするよね。という話。
レビューはコーディングと不可分というスタンスが必要になります。
実際、レビューをケチるのはテストをケチるのと同じくらい負のインパクトがあると思います。
障害その2 各自のレビュー内容がバラバラ
仕様やコーディング規約といった物差しがあっても、各個人の技量や経験のウェートが大きいとこの問題が発生します。
あと、メンバーがチームにとけ込むまでの時期にも発生しがち。
対策：コードレビューのチェック項目表をプロジェクトメンバーで共有する。
その上で、設計面や名前付けなど技量の上乗せがある分には構わないというスタンス。
*2
障害その3 『レビューの粒度が大きくなってしまう』
チケット登録時に規模があまり見えてない場合におこってしまいます。
例えば、『10クラスを新規で作って、10クラスに修正入ってます。全部で20クラスのレビューよろしく。』みたいな場合。
正直、レビューする方は見る範囲が広すぎて見切れません。
また、レビューで指摘事項があるとまた大修正になってしまったりする事も…。
対策：粒度を小さくする。
大きいから問題なので小さくする。
言うは易し行うは難しですね。
具体的には
- タスク分割
- 中間レビュー
- 3クラス以上手を入れたらそのタイミングでレビュー等の基準を設ける
というのを組み合わせつつ、対処することになります。*3
障害その4 『レビューが後回しになる』
緊急の障害対応や納期間際に起こりがちな問題です。
対策：『後回しにしても必ずやる』
対策か？これ？って感じですけど…。
チケットを必ず残す事でやりはぐれることが無いようには出来ます。
それだけでも意味があるはず。*4
結論
結果から見るとコードレビューがチームに浸透するには段階があると思います。
そして、その段階ごとでコードレビューを妨げる障害が異なります。 *5
チームと個人の成熟度に合わせてベストな対応が何かと考える際にこの記事が参考になれば幸いです。
