はじめに
私は趣向を変えまして、コードレビューの質を向上させる方法の中で最難関であり、一番最後になるであろう事について話します。
きっと、これができる組織はほんの一握りであり、もしもできているのであれば誇ってよいことです。
誇るだけに留まらず、そこに至るまでの道のりを是非とも書いてほしいです。
一般的なコードレビューの質を向上させる方法
コードレビューの概念化
コードレビューの実施は、様々な組織やチームによってローカライズされていると思います。
ですので一旦、大きく以下の要素を元に実施されるものであると考えます。
- 書かれたコードに対して、書いた人以外（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と距離を縮めてみませんか？