レビュー（Review）

レビュー（Review）とは、作った成果物を、本人以外の目で確かめて問題を見つけ出す作業のことです。システム開発では、プログラムのコードだけでなく、仕様書や設計書、画面の案なども対象になります。

現実世界に例えると、レビューは手紙を投函する前に誰かに読んでもらうことのようなものです。自分では何度読み返しても気付かない書き間違いが、別の人にはすぐ見つかります。書いた本人は、頭の中で正しく補って読んでしまうからです。

レビュー図解

※画像をクリックすると拡大表示します。

理由ははっきりしています。不具合は、後の工程で見つかるほど直す手間が増え、テストや本番で見つかった場合の手戻りは、レビューで見つけた場合とは比べものになりません。作った直後の段階で一度でも他人の目を通しておくと、全体の作業量はかえって減ります。

いまの開発現場で中心にあるのがこれです。変更したコードをそのまま本体へ反映させず、いったんプルリクエストという形で提出し、他の開発者の承認を得てから取り込む流れが標準になりました。GitHubやGitLabには、行ごとにコメントを付けられる画面が用意されています。

やみくもに読むと見落とします。仕様どおりに動くか、例外や境界の値を考えているか、他の場所へ悪い影響が出ないか、半年後の人が読んで分かるか、という順で見ていくと抜けが減ります。字下げや命名の細かな指摘は、自動の検査ツールに任せてしまうほうが効率的です。

運用でいちばん大切な心構えです。指摘の言葉が人格に向いてしまうと、指摘そのものを避ける空気が生まれ、レビューが形だけのものになります。「この書き方は分かりにくい」ではなく「ここはこう書くと読みやすい」と、物そのものと代替案に向けて話す習慣を作ります。

意外と効果が大きいのがこれです。数百行を超える変更をまとめて出されると、読む側の集中が続かず、細かい問題が素通りしてしまいます。目安として数百行までに区切り、機能ごとに分けて出すようにすると、見る側の負担が減り、指摘の質も上がります。

人が見るべきことに絞るための工夫です。書式の統一や明らかな書き間違いは、コードを解析するツールが自動で拾えるため、あらかじめ仕組みに組み込んでおきます。人は、設計の考え方が妥当か、要件を取り違えていないかといった、機械に判断できない部分に時間を使います。

見落とされがちな効果があります。なぜこの実装を選んだのかというやり取りが残るため、後から経緯をたどれる資料になります。新しく加わった人にとっては、チームの判断基準を知る手がかりにもなり、レビュー自体が知識を広げる場として働きます。