はじめに

私は趣向を変えまして、コードレビューの質を向上させる方法の中で最難関であり、一番最後になるであろう事について話します。
きっと、これができる組織はほんの一握りであり、もしもできているのであれば誇ってよいことです。
誇るだけに留まらず、そこに至るまでの道のりを是非とも書いてほしいです。

一般的なコードレビューの質を向上させる方法

コードレビューの概念化

コードレビューの実施は、様々な組織やチームによってローカライズされていると思います。
ですので一旦、大きく以下の要素を元に実施されるものであると考えます。

書かれたコードに対して、書いた人以外（AI含）が確認する
確認とは、コーディング規約やロジックに誤りがないか等
ペアプロやマージリクエストの確認など、形態は複数ある

一旦、上記の要素を元に考えてみましょう。

コードレビューの質を向上できる要素

先ほどの要素を元に、質を上げられる要素を出します。

コードを書く人の技術力を上げる
確認する側の観点、人数、技術力を上げる
個人や組織の状態に合致したレビュー形式を利用、改良する

テコ入れできる要素は上記のような感じでしょう。
そして、それぞれの向上方法は、なんとなくでも思いつくでしょう。

コードレビューの質を向上させる、一番難しい方法とは

確認する側の観点、人数、技術力を上げる

この項目にQAを巻き込むことです。
開発組織の中だけで完結しないこの方法は、とても難しいのではないでしょうか。
実は、QAの持ち得る情報の中には、コードレビューにおける観点の質を向上させるものがあります。
しかし、QAにはコーディングのスキルセットがないため、その情報を有効活用できない状態です。

QAから最も遠いコードレビュー

QAはコードレビューをどう思っているのか

「手がまわらなくて考えられない」か「やりたいけどコードがわからない」の概ね2択です。
余程のことが無い限り、QAは「コードレビューだって良くしたい！」と考えています。
コードから遠いQAがそう考えているのは不思議でしょう。
実際、とても遠くて手がなかなか届かないです。しかし、そう考えているのです。
様々な書籍で、触れられていることです。

書籍からの引用

JSTQB Foundarion 第5版

プログラム上のコードの欠陥が混入した真の原因は、プログラミングよりも前のフェーズで欠陥を埋め込んだときのエラーまで遡る必要があります。
～中略～
欠陥を分析し根本原因を明らかにして、根本原因に対する改善を行うと、類似の欠陥が発生しない、もしくは頻度を下げるようにできます。

ソフトウェア品質知識体系ガイド第2版

バグ分析
摘出したバグをその属性から分類し、統計的に解析することで、プロジェクト、プログラム、開発プロセス、開発組織、開発者などの解析対象のウィークポイントをつかむ方法。

など、QA側の文書には、プログラム≒コードにも改善をするべきとされています。
が、できてるでしょうか。

不具合分析とは何か

理想的なQA組織では、検知した不具合やバグに対して「分析」を行っています。

どのような不具合か
原因は何か
その原因が発生する根本原因は何か

そしてそれに対して、

検知する手法の強化
検知タイミングの変更
根本原因を取り除けないか

といったような再発防止策を講じます。
1の不具合に対して、複数の再発防止策を用意することも往々にしてあります。

不具合分析で分析しきれない「コード」

この時、QAには課題が残ります。

根本原因がコーディングにあるのか判別できない
コーディングでの再発防止策を打ちづらい

どうしてもこの分野については、開発者でなければ分析を進めることができません。
ここに入り込んで分析することで、QAはさらに再発防止策の打ち手を増やせますし、その情報を元にコードレビューの観点を強化することができます。

QAを巻き込むことが難しい理由

QAと開発の距離が遠い

スキルセットが違うため、従来の組織構築では別にされがちです。
互いの懐に入り込むような連携を元にしなければならないので、距離を埋めるところから始めなければなりません。

QAと開発のスキルを併せ持つ人が少ない

QA側にコードを読める人がいる、もしくは開発側に不具合分析ができるレベルのQAスキルを持つ人がいれば、この問題はかなり解決します。
しかし、開発のスキルもQAのスキルも、それぞれ専門性の高いスキルであるため、なかなか居ないのが実情でしょう。

QAが不具合分析を実施できていない

おそらくはここが最難関でしょう。
QAのリソースが枯渇しており、不具合分析と再発防止策の実施に手が回っていないケースです。
QAが開発と比較して小さかったり、不具合の数が多すぎてテストしかできていなかったり、そもそもQAが存在していなかったり……

不具合分析によるコードレビューの強化例

私のチームは、全員がフルサイクルエンジニアであるため、それぞれが開発者でありQAです。
シナリオテストで検知した不具合を、再発防止策としてコードレビューにフィードバックした例があるので、挙げておきます。

類似処理の明記

画面上の動作では同じような処理が、内部的には異なる3通りのロジックを利用していました。
再発防止策として、各種テストでは全ロジックを実施するようにしつつ、コードレビューでは各ロジックへの対応要否を確認するようになりました。

設定値名称の変化

ある設定値の名称は「hoge」で登録されており、概ね「hoge」として処理されていました。
しかし、別の処理ではその値を「fuga」に変更して処理していました。
再発防止策として、すべての設定値と処理での名称応対表を作成し、各種テストではそれを元に設計するようにした上で、コードレビューではどの名称で利用しているか確認するようになりました。

文字コードの処理

ファイル読み込み処理を行う際、文字コードによって判別できないケースが発生しました。
再発防止策として、各種テストでファイルを読み込む際は複数の文字コードでテストを実施するようにした上で、コードレビューではファイル読み込み実施時は文字コード判定処理を必須としました。

さいごに

QAの不具合分析には、コードレビューを強化できるお宝が眠っている、はずです。
しかし、それを有効活用するには様々な障害があり、一筋縄ではいきません。

また、各関連書籍に具体的な手法やアクションが載っていないのは、実例が極端に少ないのだと想像しています。
少ないのは、そこに至るまでのコストが多大なのでしょう。そして、そのコストを払った上で釣り合うメリットが本当に出てくるのか、少し判断に困る点もあります。

ですが、乗り越えた暁には、QAの知見も含まれたコードレビューに進化を遂げることでしょう。

コードレビューにQAを巻き込む前に、とりあえずQAと距離を縮めてみませんか？