少人数でスクラム開発をすることが多いのですが、チームによってレビューが効果的に機能するときと、そうでないときがあるように思ったので、レビューについて考えてみました。

レビューの目的

まず、レビューの目的と目的毎の優先順位の定義が必要だと考えました。

目的１：成果物をより良いものにする

人間はミスをする生き物なので、一人だけで作成した成果物はミスを含む可能性が高い。
成果物をリリースするまでの間に、複数人の目を通すことでミスが残り続ける可能性を減らす。

目的２：属人性の排除

レビューを実施するためには、レビュー対象に対する理解が必須条件となる
前提条件を理解したうえで、成果物を確認するので担当者しか知らないという状況がなくなる

目的３：責任の共有

バグが発生した際に、コーダーだけでなくチームメンバー全員のバグとして対応することで、コーダーの心理的な負担を軽減する

目的４：開発者ごとの知見の差を埋める

フィードバックを受け修正の繰返しによる成果物の改善を実施するサイクルの中で知見が共有される

補足

人間はミスをする生き物と記載したが、それはレビューイだけでなくレビュアーにも当てはまる。「バグはレビュアーの責任」というキャッチコピーでレビュー活動を促進したが、冷静に考えると矛盾している。

レビューの対象とレビュー観点

ソースコードに限らず成果物の全てをレビュー対象にするのが良いと考えます。

レビュー対象	観点の例
仕様書	使いやすい仕様になっているか？
設計書	もっと良い方法はないか？整合性はとれているか？
手順書	手順が誤っていないか？手順を見る人が理解できるか？
ソースコード	正常系/異常系は問題ないか？修正しやすいか？読みやすいか？
テストコード	テストケースは十分か？バグはないか？
テスト仕様書	テストケースは十分か？観点に漏れはないか？

レビューのフロー

No	工程
1	開発者は成果物を作成する
2	開発者はレビュアーにレビュー依頼を行う
3	依頼を受け取ったレビュアーは成果物を確認し、改善点などを開発者にフィードバックする
4	開発者はフィードバックの内容についてレビュアーとコミュニケーションをとり修正する
5	フィードバックの内容が十分に消化されるまで３～４を繰り返す
6	（場合によっては）レビュアーが成果物を承認する

レビューを定着させるために工夫したコト

いくつかありますが効果を実感した部分を記載させていただきます。

その１：レビューしなくて良いものを定義する

小規模PoC等を目的とする場合は、「作りは雑でも、正常系がとりあえず動けばOK。（＝レビューなし）」と定義しました。

その２：プランニング時にレビューをタスク化し見積工数を計上する

「レビューの時間が取れない」という課題が上がったことがありました。その時はレビューと未実装機能の実装を比較し未実装機能の実装を優先せざるを得ない状況だったのですが、それを回避するために機能実装の一部としてあらかじめ見積にレビュー工数を計上しておくことにしました。最初は「レビューににどれだけ時間がかかるか分からない！」というところからスタートだったので、実装タスクと同等の長さをレビュータスクの見積り時間としました。

その３：1回のレビュー依頼に複数の目的を混ぜない

「新機能を実装していると既存機能部分のバグを発見してしまった」という経験は、たまにあると思いますが、これらを一つのレビューに含めることを禁止しました。一般的にレビュアーはレビュー対象の前提条件や実装の意図等を理解するところから始めます。それに加え、1つのレビューの中に複数の目的が混ざると、「今見ている部分は何に該当するか？」を常に意識しなくてはならなくなり負荷が増加します。レビュアーが考えることをなるべく少なくするために「1つのレビューには1つの目的の変更のみを対象とする」というルールを作りました。（これにはフィードバックまでの時間を短くするという効果もありました。）

その４：レビューに必要な情報はレビューイが用意する

実装時には様々なことを考慮して作業を行う必要があります。なので実装者は様々な情報を事前に用意します。そして、実装時に気にすべきことはレビュー時にも気にする必要があるはずです。実装者が集めた情報をレビュー時にレビュアーが最初から集めるのは時間の無駄なので、レビュー時に必要となる情報をレビュアー向けに用意することをレビューイの役割としました。

その５：テキストベースのコミュニケーションは2往復まで、それ以降は口頭で実施

テキスト（チャット）ベースの非同期フィードバックは「相手の作業を強制的に中断させることが無い」というメリットがあるものの、相手とのタイミングが合わないとタイムリーな対応が出来なくなることがあります。例えば他の業務を実施しながらレビューを実施する場合、「区切りが良いところまでやってから、レビューを実施する」という選択をすることがあると思いますが、区切りが良くなるまでは直前の質問に対する回答を確認しないことになるためレビュー対象の開発がしばらく進まないことになります。急いでいる場合、長くなりそうな場合等はチャットやチケットでの非同期コミュニケーションより、会話を中心にした同期コミュニケーションを実施することにしました。

その６：分からないことはすぐに質問する。

実装の意図が分からない、フィードバックの意図が分からない等、レビュアー・レビューイともに「何を意図しているのか想像しなければならない」という状況は多々ありますが、そもそも間違っている可能性があるものを見て正しい意図を理解するのに無理があります。「10分悩んでもわからないときは聞いてみる」というルールを作りました。

その７：ツールを使用する

リントやフォーマッターなどの設定をチームで共有することで、レビュアーは自動修正される部分に注意を向ける必要がなくなります。

最後に

レビューを定着させるのに一番大切だと感じたのは「レビューはコミュニケーションなのでレビュアー、レビューイ間の人間関係（チームビルディング）が大切」というところです。レビュアーに間違いを指摘された時に「見つけてくれてありがとう」と思うのが一般的ですが、指摘する側/指摘される側の関係に問題があると、何をフィードバックするかよりどうフィードバックするかばかり考える必要が生まれるかもしれません。指摘するのが面倒になり見て見ぬふりをしだしたらただの時間の無駄です。なんでも言い合える、感謝し合える関係を常日頃から構築しておくことが大切だと思います。