はじめに

こんにちは。廣瀬です。
突然ですが、みなさん！レビューしてますかー！？（してもらっていますかー！？）
プロジェクト管理の重要な一項目である品質管理の基本のキとも言える「レビュー」ですが、意外となんとなくでやっていないでしょうか？そんな簡単なようで実は奥が深いレビューをより良く実施するためのポイントを確認してみたいと思います。
内容は入門編になります。あまり目新しい発見は無いかもしれませんが、一方でちゃんとできているかと問われると、自信をもってYesとは答えられない点もあるのではないでしょうか？初心者の方も、ベテランの方も、この記事を読んで一度自分のレビューのやり方を振り返ってみてください。

そもそもレビューとはなにか

システム開発の文脈におけるレビューとは以下のような意味になります。

情報システムやソフトウェアの開発で、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。
引用：IT用語辞典 e-Wordsより

レビューをしてもらう人のことをレビュイー（reviewee）、レビューする人のことをレビュアー（reviewer）と呼びます。
打ち合わせの場で成果物の読み合わせを口頭で説明をしながら議論する対面レビューや、一堂に会さずにレビュイーの任意のタイミングで成果物を見てまとめて指摘を返す回覧レビューなど、やり方も色々あります。（各現場の文化によって呼び方は色々あるので各自読み替えてください。）
適切にレビューを実施することで以下のような効果が期待でき、成果物の品質向上につながります。

認識齟齬の是正・すり合わせ（網羅性、正確性）
表現の分かりやすさの改善（標準化、表示ブレ）
設計観点の抜け漏れ、考慮漏れの検知
知見の継承
凡ミスのダブルチェック

実践すべきポイント

多くの人の目を通してレビューをすれば、不具合や考慮漏れなどを世に出してしまうリスクを抑えられます。その一方で100点を目指してずっと時間を費やすわけにもいきません。
限られた時間の中でポイントを抑えて効率的に品質向上を目指しましょう！

レビューの目的を明文化しよう

「○○が完成しました。レビューをお願いします。」

よく見るレビュー依頼のコメントですが、ここにどんなレビューをしてもらいたいか、観点を一緒に伝えるとより良いでしょう。
「○○についての記載が足りない」「誤字がある」「記載内容に誤りがある」「先日の××の仕様変更が反映されていない」「ここの処理はこうしたほうが処理効率がいい」……etc
余力が充分にあれば良いのですが、思いつくままに指摘をもらうと時に収集がつかなくなることもあります。

レビュー対象の成果物のステータスによっても見てもらいたい内容は変わると思います。

たたき台（3～5割）の段階：
- 状態： ドキュメントであれば章立て、システムであればアーキテクチャや大まかな処理フローができた段階のイメージです。
- 観点： 全体の方向性は問題ないか？大きな認識違いはないか？アーキテクチャレベルでの冗長さはないか？、など
8〜9割完成の段階：
- 状態： ドキュメントであれば文章や図表が大体埋まったところ、システムであればだいたい動きそうなコードが出来たところくらいのイメージです。
- 観点： 仕様の抜け漏れはないか？（網羅性）、実装レベルで非効率な処理になっていないか？、など
最終版の段階：
- 状態： ドキュメントであれば公開する直前、システムであればリリース直前の状態でしょうか。
- 観点： 誤字脱字や表記ゆれ、計算ミスはないか？、など

レビュイーはレビュアーに今回のレビューの目的を伝えることで、指摘内容の軸がブレずに効率的に進めることができます。例えば

「○○が完成しました。レビューをお願いします。主に処理対象に過不足がないかの網羅性を確認いただきたいです。エラーメッセージは仮置きで入れているので別途見直す予定です。」

こういう依頼であれば、レビュアーは何を気にするべきか集中すべきポイントが定まり、メッセージの誤字脱字や日本語まで細かく見なくて良いことが分かります。

レビュー指摘は文章にして残そう

回覧レビューの場合は必然的にテキストコミュニケーションになると思いますが、対面レビューであっても指摘内容を文章に残しながらレビューを実施することをおすすめします。
レビュイー、レビュアーどちらが文章化するかは事前に取り決めを交わしておきましょう。個人的に主なレビュアー・レビュイー以外に書記も参加してもらうか、レビュアーが文章化することをおすすめします。
指摘されながら正確にメモを残すのはけっこう大変です。人手の都合で書記が確保できないとしたら、指摘される側よりする側が文章を書いたほうが細かいニュアンスの齟齬も防げるので効率的です。
せっかく記録を残しても本人にしか解読できないメモでは、(他の人はおろか、書いた本人ですら)後から正しく振り返ることができません。大変ですがレビュアーはひと手間かけてでも、ちゃんと意味が通る日本語の文章を残しましょう。

ちゃんと意味が通る日本語の文章を残しましょう！（大事なことなので2回言いました）

出来れば指摘は一覧化出来るようにしよう

文章で残すだけではなく、出来れば一覧化することが望ましいです。
全ての指摘に対応することが望ましいのですが、時間制約などによってはそれが難しいことも多々あります。そのため、指摘内容に応じて影響度などを加味した対応優先度付けをする必要があり、指摘毎に対応ステータスも変わってきます。
一覧化しておくことで優先度を誤った順に対応してしまったり、優先度を下げたまま忘れ去られて対応漏れになる事態を避けることができます。
Excelやスプレッドシートのような表計算ソフトでも、Redmineなどのチケットでも、GitHubのIssueでも、どのような形式でも構わないのですが、指摘内容は面倒でも1単位（1行、1チケット、1Issue…）に1つにするのが原則です。複数を盛り込んでしまうと優先度や対応状況を正確に管理できなくなり、一覧管理の意味が薄れてしまいます。
「対応しないと期待した仕様を満たせない指摘」であれば対応優先度は高になりますが、「画面に表示されるエラーメッセージの句読点があったり無かったりする。」というレベルの指摘は、対応しなくても機能自体には問題がないので対応優先度は下がります。（もちろん余力があるなら直したほうがいいです）
プロダクトオーナーの判断で、時には納期との兼ね合いで目をつぶるべき場面も出てきますが、一覧管理していれば申し送りにした対応も後日漏れなく対応することが出来るようになります。

「優先度高までは要件に影響があるから全部対応しよう。優先度中～低は初回リリース時は目をつぶってもらって、優先度中はエンハンス対応で改修しよう。優先度低はそれ以上の対応すべて終わってから、保守の中でゆっくり直していこう。」

納期に問題がない（余裕がある or 延ばせる）のであれば、わざわざ優先度付けをするまでもなく、すべて対応すればよいのですが（指摘された内容を理解した上で「修正はしない」と判断するのも対応の一種だとして）、現実は常にうまくコトが運ぶとは限らないのが世知辛いです。

成果物のノイズを除いておこう

例えば設計書の誤字脱字、細かい表記ブレ、フォント・段落がめちゃくちゃでも、本質的な記載内容とは直接関係ないことがほとんどです。
しかし、いくら事前にレビュー観点で「本質的な記載内容についてだけ確認してください！」と伝えていても、あまりにも体裁が整っていないとノイズになってしまい、肝心の内容がレビュアーの頭に入ってきません。
レビュイーはレビュー依頼を出す前に、最低限の体裁は整えるようにしましょう。

SNSやブログで同業者の「誤字脱字とかフォントとか、本質的にどうでもいいレビュー指摘しかもらえない。」なんてボヤキを見かけることがありますが、原因はレビュアーではなく、レビュイーのレビューに挑む心構えにあるのかもしれませんよ。

レビューにありがちな間違い

実践すべきポイントがある一方で、やってしまいがちな間違いも多々あります。
慣れていないと（あるいは慣れていても）陥りがちな間違いなので、定期的に基本に立ち返りましょう。

主体は成果物であってレビュイーではない

レビューの主体は成果物であって、レビュイーでもレビュアーでもありません。
レビュー指摘はレビュイーの人格について言及するものではないので、どんな指摘をもらってもレビュイーはいちいち落ち込む必要はありません。
また、レビュアーは絶対にレビュイーを攻撃するような態度をとってはいけません。
レビュアーとレビュイーは敵対関係ではなく、共に成果物をより良いものにブラッシュアップするパートナーであるという意識を持ちましょう。

レビューはダメ出しをする場？

違います。
成果物の品質向上を目指すという特性上、良くない所を挙げて改善を目指す場になりがちですが、本来レビューは肯定的なコメントも積極的にあげるべきです。
ダメ出しだけでは修正箇所が断片的になりがちですが、肯定的なコメントによって 「ここは良いから残そう」「この方針で進めよう」という共通認識が生まれ、 一貫性のあるより良い成果物に仕上げることができます。
言うまでもなく、シンプルに人は褒められた方がやる気が出るという要素もあります。

指摘は必ず取り込まないといけない？

違います。
レビュアーは全知全能の神様ではありません。レビュアー側の認識相違で指摘そのものが誤りの場合もあれば、どちらを採用しても好みの問題でしかない場合もあります。
一般的に上司やお客様がレビュアーになることが多いため、すべて取り込まないといけない気がしてしまうのですが、レビューの目的は成果物の品質を向上させることです。
合理的な理由があれば、リジェクトするのもまた立派な指摘対応の一つです。その場合はレビュイーは「なぜ取り込まないのか？」をレビュアーに伝えて、お互いが納得できるようにしましょう。

指摘は少ないほうがいい？

違います。
レビュイー（やその上長）はレビュー指摘が少なければ少ないほうがいいと思っているケースも少なくありませんが、それは明確に誤りです。
指摘件数と成果物の品質は直接の比例関係にはありません。レビュー指摘が多すぎる場合、レビュー指摘が少なすぎる場合、どちらも危険信号です。
ちょっと掘り下げてみます。

指摘が多すぎるケース

レビュー指摘が多い場合は指摘内容を分析してみると、成果物以前の課題が浮かんでくる場合もあります。また、指摘の内容によっては知見の共有はチーム全体の開発力の底上げに繋がるため、指摘が多いことが悪いこととはいえません。

記載誤りや認識齟齬が多い
- →事前の情報共有・すり合わせが不足していたかも。前提が共有できていない可能性。
観点の抜け漏れ
- →物事は常に多面的。得意分野の異なる人が色んな角度から物事を捉えるのは当然。
知見の継承
- →他の人の知見を得ることができる大事な機会。誰かの当たり前は別の誰かの新発見かもしれない。
凡ミスのダブルチェック
- →多すぎる場合は潜在的な別の問題がある可能性が高い。納期は的確か？担当者が過度な負荷に追い込まれている可能性は？

指摘が少なすぎるケース

マネジメントの観点からすると、むしろこちらの方が警戒したほうがいいシグナルです。

レビュアーが不適格の可能性（スキルセットアンマッチの可能性）
- 指摘をする側のアサインが不適格だった可能性があります。（能力不足という意味ではなく）
- インフラ観点のレビューをアプリエンジニアに依頼したり、お客様しか分からない要件の優先順位を受託開発チーム内で確認しても有意義な指摘は出てきません。
レビュープロセスが不適切な可能性（頻度や進め方）
- レビュー対象のボリュームに対してレビューに割ける時間が短すぎたり、いきなり巨大な完成品を提示されると、レビュアーが集中できずに必要な観点での指摘ができないことがあります。
隠蔽の可能性
- 最悪です。一番マズいやつです。
- レビュー指摘が多いと当然ながら指摘対応をする必要があり、後続の作業が止まってしまいます。余裕がない時にレビュアーが（あるいはレビュイーと口裏合わせをして）気になる箇所を見なかったことに……なんてことも。

品質是正は後工程になればなるほど大変なのは皆さんがご存じの通りなので、管理者としては絶対に見逃してはいけない兆候です。

まとめ

入門編の内容ということもあって、実践すべきポイント、ありがちな間違いともに改めて言われても「うんうん、まぁそうだよね。分かる。」くらいの感想かもしれません。
とはいえ冒頭にも書いた通り、基本的なことほど忠実に丁寧に実践するのは難しいです。（私も実践出来ているとは自信をもって言えないです）
まずは一つでも意識して、次のレビューから実践してみてください。この記事が、皆さんのレビュー活動をより良くするための一歩となれば嬉しいです。