こんにちは。テクニカルディレクターのTSUZUです。
最近エンジニアになりたての方と話す機会がありました。
その人いわく「コードレビューされるのが怖いんです」と。
「あぁ……懐かしい感覚だなぁ……」と思いまして、社会人になりたての自分を思い出して遠い目になりました。
コードレビュー、確かに怖い気持ちわかるなぁ……。
自分が心血注いで書いたコードに修正指示が入ると、なんだか自分の人格まで否定された気分になったりしたものです。
あれから幾星霜、コードレビューされる側からする側へ、ときにはプロジェクトをマネージしたり。
思えば遠くに来たものです。
今回の記事では、そんなコードレビューについて、結果を分析してプロジェクトをより良くしていこうぜ！ っていう話を書きたいと思います。
目次 [閉じる]
よくあるプロジェクトの課題
「コードレビューの差し戻し（フィードバック、以下FB）が多く開発のスピードが上がらない」という声、ときどき聞きませんか？
「じゃーコードレビューで差し戻し貰わないように気をつけましょう！」といっても、何に気をつければ良いかわからないですよね。
というわけで、ここからは課題を整理してFB受領率を下げる施策を考えてみましょう。
当社のとあるプロジェクトでは、この施策を半年程度実施したことで、FB受領率を40%程度削減することができました。
プロジェクトの体制
課題整理のためにプロジェクトの座組みを仮定します。
現在LIGではBiTT（Built Team Together）開発というスタイルで、クライアントのサービス開発や、基幹システムの開発などを行っています。
BiTTの詳細な説明は別の記事に譲りますが、開発のざっくりとした座組みは下図の通り。
セブ側が実装したコードレビューするタイミングで、FBが発生してしまうと生産性が下がってしまうわけですね。
フィードバックをカテゴリー分け
コードレビューでもらうフィードバックにはどのような種類が考えられるのか。
思いつくままに挙げるとこんな感じでしょうか？
設計誤り
設計が正しくないなら実装も正しくないじゃん、という元も子もないケース。
意外とあるんですねこれが。
規約違反
コーディング規約の通りに実装がされていないケース。
実装改善
仕様を満たしており、期待通りの挙動をしているが、ソースコードに改善の余地がある。
同じ処理を何回も書くの無駄だから関数化しようよ！ みたいなケースがこれですね。
実装誤り
バグ仕込んじゃったりするやつ。
仕様追加・変更
実装完了した後に、「すみません！ やっぱりここも修正お願いします！」ってなるパターン。
その他
上記のいずれにも該当しないケース。
フィードバックの品質を担保するレイヤーは？
これらのFBが発生した場合、原因はどのレイヤーにあるでしょうか？
上述の座組みに対応させると下記のような感じですね。
| 日本 | セブ | |
|---|---|---|
| 設計誤り | ||
| 規約違反 | ||
| 実装改善 | ||
| 実装誤り | ||
| 使用追加・変更 | ||
| その他 |
集計してみよう
下記のようなスプレッドシートを作成し、FBを受領するたびに起票します。Googleフォームなどを使うのも良いでしょう。
グラフにしよう
上記を基にFB受領の割合をグラフにします。
同時にFBを受領する割合のグラフも合わせて作成しておくと、以後効果を分析する際に役立つでしょう。
ついでに、FB数の平均（1PR毎にいくつ指摘をもらうか）もグラフにします。
さらにさらに、FB指摘数の平均と指摘数の総計グラフも作成します。
月次で振り返ろう
月次で定期的に振り返りを行います。
規約違反が多ければコーディングルールの見直しを、実装誤りが多ければハマりやすいポイントを共有します。
ここで大事なのが、FBの多い人を責め立てないことです。「バグを憎んで人を憎まず」の精神でいきましょう。
おわりに
地道で面倒臭い作業ですが、プロジェクトの課題を洗い出すにはこういった作業もときには必要ですよね。
皆さんのプロジェクトの助けになれば幸いです。
以上、テクニカルディレクターのTSUZUでした。
