「開発を外注していて、毎回『レビュー済みです』と報告は来るんです。でも、それでもバグは出るし、後から直そうとすると『そこは触ると壊れるので大掛かりになります』と言われる。レビューって、本当に効いているんでしょうか」——システム開発を発注している事業者の方から、こんな相談を受けました。「レビューしています」という報告は、品質が担保されている証拠のように聞こえます。しかし、レビューの回数や指摘の多さは、品質とは必ずしも一致しません。
ある現場で、3ヶ月分のレビュー指摘を一件ずつ分類したところ、はっきりした結果が出ました。バグを実際に防ぎ、後の保守を楽にしていた指摘は2種類だけで、残りの大半は好みの押し付けや些末な表記の話でした。本記事では、この「効く2種類」が何かを説明したうえで、発注側が「うちのレビューは機能しているか」を見抜くための問い方を、実務目線で整理します。
レビュー指摘の多くは、品質を上げていない
まず直感に反する事実から。指摘の数と品質は比例しません。むしろ、指摘が多いレビューほど、中身が「好みの表明」で膨らんでいることがよくあります。
3ヶ月分を分類して見えたのは、指摘の大半が次のようなものだったことです。変数の名前の付け方の好み、括弧やインデントの流儀、「自分ならこう書く」という書き方の提案、動作に影響しない細かな表記。これらは一見「丁寧にレビューしている」ように見えますが、直しても製品の挙動は1ミリも変わらず、バグも減りません。しかも、こうした指摘への対応でレビューのやり取りが長引き、本当に見るべき点が埋もれてしまう。数が多いレビューが良いレビューだ、という思い込みは、まず外す必要があります。
効くのは「壊れる指摘」と「後で困る指摘」の2種類
では、実際にバグを防ぎ保守を楽にしていた2種類とは何か。整理すると、次の二つです。
一つ目は、動作が壊れることを指摘するものです。ここでこの入力が来たら落ちる、この条件が抜けているとデータが二重に登録される、この処理は同時に実行されると結果が狂う——要するに「放置すると実際に不具合になる」指摘です。これはそのまま、客先で起きるはずだった事故を一つ潰しています。二つ目は、後で保守できなくなることを指摘するものです。この作りだと次に機能を足すとき全部作り直しになる、この部分は同じ処理が三ヶ所にばらけていて片方だけ直すと不整合が起きる、ここは半年後に誰も意味が分からなくなる——今は動くが、将来の変更コストを跳ね上げる作りへの指摘です。
| 指摘の種類 | 効くか | 発注側にとっての意味 |
|---|---|---|
| 動作が壊れる・バグにつながる | 効く | 客先で起きる事故を事前に潰す |
| 後で保守・変更ができなくなる設計 | 効く | 将来の改修費と「塩漬け」を防ぐ |
| 名前・表記・書き方の好み | ほぼ効かない | 自動整形ツールに任せるべき領域 |
| 動作に影響しない細かな指摘 | ほぼ効かない | やり取りを増やし本質を埋もれさせる |
この二つに共通するのは、「今」ではなく「これから」に効くという点です。バグの指摘は出荷後の事故を、設計の指摘は将来の改修費を、それぞれ前もって減らしている。逆に言えば、この二つが薄いレビューは、報告上は「レビュー済み」でも、発注側が本当に払っている保守費や事故対応費を減らしてはいません。AIが量産するコードをどうレビューするかという新しい論点はAI生成コードのレビュー記事で扱っていますが、人が見るべき芯はこの2種類で変わりません。
好みの指摘は「人」ではなく「道具」に任せる
「では名前や表記はどうでもいいのか」というと、そうではありません。それらは人が指摘する仕事ではなく、道具が自動でやる仕事だ、というのが正しい整理です。
コードの整形や表記の統一は、自動整形ツールや静的チェックの仕組みを入れれば、人の手を介さず機械的に揃います。これを仕組みに寄せておくと、人間のレビューは「壊れる指摘」と「後で困る指摘」の二つに集中できる。テストで品質を機械的に担保する考え方はテスト品質を保証する記事にまとめていますが、レビューも同じで、機械に任せられる部分を機械に寄せ、人は人にしか見えない設計と挙動を見る——この分業ができている開発チームは、少ない指摘で効いています。
発注側が投げるべき、三つの問い
品質を発注側が確認するのに、コードを読める必要はありません。次の三つを開発会社に問うだけで、レビューが機能しているかはかなり見えます。
一つ目、「表記や書き方の統一は、自動ツールでやっていますか。人が手で指摘していますか」。手で指摘していると答えるなら、人の時間が本質でないところに使われている疑いがあります。二つ目、「レビューでは主に、どういう不具合や将来の作り直しを防いでいますか。直近の具体例を一つ教えてください」。ここで「壊れる指摘」「後で困る指摘」の実例がすぐ出るなら、レビューは芯を押さえています。三つ目、「レビューで防げず、後から出た不具合はありますか。それはなぜレビューで拾えなかったのですか」。失敗を隠さず原因を語れるチームは、レビューを改善する回路を持っています。レビューを速く回す仕組みそのものはPR分割の記事も参考になります。
「指摘の数」ではなく「防げた事故」で見る
コードレビューは、外注した開発の品質を支える重要な工程です。ただ、「レビューしています」という報告や指摘の多さは、品質の証明にはなりません。実際に効いているのは、動作が壊れることを防ぐ指摘と、将来の保守が効かなくなることを防ぐ指摘の2種類で、残りは道具に任せるべき領域です。発注側は、指摘の数ではなく「どんな事故と作り直しを防いでいるか」で品質を測るとよいでしょう。
まずは今の開発会社に、先の三つの問いを投げてみるのが手軽な一歩です。「レビュー済みと言われるがバグが減らない」「後から直そうとすると毎回大掛かりになる」「品質が担保されているのか外から確かめられない」——そうしたお悩みがあれば、グリームハブの開発・AI・自動化のご相談からお気軽にお問い合わせください。既存の開発体制のレビューが芯を押さえているかの点検から、機械に任せる部分の切り分けまで、発注側の立場でご一緒します。
