こんにちわ @kawanamiyuu です。今回は私の所属する楽楽労務の開発チームで運用しているコードレビューガイドラインとコードレビューにまつわる少し変わった取り組みについて紹介しようと思います。
楽楽労務の開発体制
- チーム
- ツール
コードレビューガイドライン策定の背景
開発規模拡大のための人員増とそれに伴う複数チーム体制への移行により、
- チームごとにコードレビュー指摘の重要度や観点にばらつきがある
- 開発メンバーが自身の成長を測る指標として、Merge Request の差し戻し回数より細かい粒度の情報を収集しづらい
といった課題が出てきていました。
コードレビューガイドライン策定の目的
これらの課題を解決するためのコードレビューガイドラインを策定し、次の実現を目指しています。
- 開発チーム全体で同じ基準でコードレビューを行い、修正要否を判断できるようにする
- 開発メンバーがレビュー指摘を重要度や観点ごとに分析し、自身のふりかえりに活かせるようにする
- 観点を明文化することで、レビューイーのセルフチェックやレビュアー育成のインプットとして使えるようにする
レビュー指摘の重要度
コードレビューで発生する指摘には必ず優先度を付け、プロダクト品質に対する重要度を表現します。
| 重要度 | 説明 |
|---|---|
| MUST | 必ず修正すべき。われわれが期待する当たり前品質に達しておらず、そのままではリリースできない。今放置するとあとで大きな負債になる |
| SHOULD | 可能なら修正すべき。リリーススケジュールを優先するため戦略的に修正を見送ることもできるが、その場合は次バージョンで修正を検討すべき |
| IMO | 修正判断はレビューイーに委ねられる。別解の提案や現時点では判断が難しい課題など、レビュアーの意見に過ぎない |
レビュアーはこれらの「重要度」に「観点」*5を加えて、Merge Request 上のコードに対してレビュー指摘を記述します。
＜レビュー指摘の記述例＞
コードレビューの工夫
MUST レベルのレビュー指摘はリリース品質を満たしていないことを意味するため、必ず修正する必要がありますが、SHOULD レベルのレビュー指摘の修正判断には裁量があります。
私がリーダーを担当するチームでは「SHOULD レベルのレビュー指摘はすぐには修正せずいったん負債として積み上げる」という運用を試みています。平たくいうと、未修正の SHOULD レベルのレビュー指摘が残っていても Merge Request をマージしてよいことにしています。
これは、
- まずはリリース可能品質到達を最速で目指すことで、開発の後工程のスケジュール上のリスクを減らしたい
- コードの問題を「いつ」「どの程度ちゃんと」修正するかという意思決定によって開発速度と品質のバランスを調整したい
という考えが背景にあり、担当チームメンバーと開発チーム全体に説明のうえ、このような工夫を試しています。
この運用によって後回しにした負債タスクも Trello 上で管理しています。
その名も「SHOULD」レーン（まんま）です。
このレーンのタスクは、実装タスクのレビュー待ち時間やスプリントの切れ目など、主に開発業務のリードタイムが発生したときに、開発業務の箸休め的なタスクとして、各自が自主的に取って解消していく運用としています。
「おやつ」という発明
さて、いよいよ本題ですが、最近のスプリント終了時の振り返りで、私のチームのあるメンバーが「今回のスプリントはタイミングよく負債タスクを消化できた。おやつ感覚だった。」と発言しました。その瞬間、メンバー全員が「これだ！」と思いました。
そして爆誕したのが「おやつ」レーン（名前変えただけ）です。
この並びに「おやつ」の文字が並ぶのは面白いですね。
プログラマーにとって名前付けはとても重要です。その対象の特徴を適切に捉えた良い名前が与えられることで、非常にすっきりとその世界観を理解することができます。
また、今回、負債タスクに「おやつ」という名前がついたことで、負債というネガティブなイメージがポジティブなイメージに変わり、負債解消に前向きに取り組むことができるようになりました。
おわりに
今回紹介したコードレビューに対する取り組みは、現状うまく回っています。開発中に発生した一部のレビュー指摘を負債として一時的に後回しにはするものの、「おやつ」感覚で適宜消化し、負債を溜め込まない状態をキープできています。
私たちの取り組みが、開発速度と品質を両立し、技術的負債に対して前向きに取り組みむためのアイデアとなれば嬉しいです。
--
P.S. その後、次のような名言（迷言）も生まれています。
- おやつの鮮度が落ちると背景理解に時間がかかる
- ＝ 負債を放置すると、実際に修正しようとしたときにどんなコンテキストでの指摘だったのか思い出して理解するのに時間がかかる
- おやつを食べすぎた
- ＝ メインの実装タスクよりも負債の解消を優先してしまい、実装タスクの完了が遅れた
