2.レビューは品質を保証しているのだろうか

この連載について

品質保証プロセスの改善やQAの役割について考える中で、
いくつかの疑問を持つようになりました。

本連載では、それらの疑問について整理しながら考えていきます。

記事一覧

第１章　品質保証を問い直す

1. QAは品質を保証しているのか？
2. レビューは品質を保証しているのか？ ← 今回の記事
3. AI時代にQAが保証するものは何か？

第２章　品質はどこから生まれるのか

4. レビューの価値は学習ではないか？　
5. プロセスは思考を設計しているのか？（予定）

前書き

私のこれまでの経験と思っていることについて記載しております。
前回は「QAは品質を保証しているのか？」というテーマで記事を書きました。

今回はその続きとして、品質保証活動の代表例であるレビューについて考えてみたいと思います。

今回も最終的な答えには到達できていません。
考えていく中で別の疑問にたどり着いたため、その過程も含めて共有したいと思います。

はじめに

ソフトウェア開発においてレビューは非常に重要な活動です。
要求レビュー、設計レビュー、コードレビュー、テストレビュー。
多くの現場で日常的に実施されています。
品質保証活動を考える際にも、レビューは中心的な存在です。

しかし私は最近、
「レビューは本当に品質を保証しているのだろうか」
と考えるようになりました。

レビューは実施されている。
記録も残っている。
指摘も出ている。

それでも不具合は発生する。
レビューが悪いと言いたいわけではありません。
むしろレビューには大きな価値があります。
ただ、その価値は私たちが思っているものとは少し違うのかもしれません。

レビュー完了と品質が保証されているは同じではない

レビューが実施されたことは確認できます。

例えば、

• レビュー記録
• 指摘件数
• レビュー参加者
• 承認履歴

などです。

しかし確認できるのは、
「レビューを実施した」
という事実です。

一方で、
「レビューが十分に機能した」ことは確認できません。

レビュー完了という状態はあります。
しかし、
「レビュー品質保証済み」という状態はありません。

同じ1時間のレビューでも、議論が活発だったレビューもあれば、
形式的に終わったレビューもあります。

同じ指摘件数でも、本質的な議論が行われた場合もあれば、
細かな表記修正だけの場合もあります。

私はここにレビューの難しさがあるように思います。

レビュー品質とレビュー価値

ここで一つ整理したいことがあります。
レビュー品質とレビュー価値は違うのではないかということです。

レビュー品質とは、

• 適切な人が参加したか
• 必要な情報が揃っていたか
• 必要な観点で確認できたか

といったレビューという行為の品質です。

一方でレビュー価値とは、レビューによって何が得られたかです。

例えば、

• 理解の差が埋まった
• 認識のズレが減った
• 暗黙知が共有された
• 設計上のリスクが明確になった

などです。

私たちはレビュー品質は比較的管理できます。
しかしレビュー価値はほとんど管理できません。
本当に欲しいのはレビュー価値なのに、測定できるのはレビュー品質だけ。

ここに一つのジレンマがあるように感じています。

レビューの本質は学習ではないか

レビューというと、
「不具合を見つける活動」として語られることが多いと思います。

しかし実際のレビューを振り返ると、それだけではないように思います。
作成者はレビュアから過去の失敗事例や経験を学びます。

レビュアは成果物を通して設計意図や要求背景を学びます。

つまりレビューは、指摘を出す場であると同時に、
相互に学習する場でもあります。

そう考えると、レビューの流れは
レビュー
↓
相互学習
↓
認識合わせ
↓
設計改善
↓
品質向上

と考えられるかもしれません。

もしそうであれば、レビューの本質は不具合検出ではなく、
チームの学習活動にあるのではないでしょうか。

レビュー価値は既に仕組み化されているのではないか

ここで別の疑問が生まれました。
もしレビュー価値が、

• 理解の共有
• 認識合わせ
• 暗黙知の共有

であるならば、それは本当にレビュー会議でしか実現できないのでしょうか。
現場には既に多くの仕組みがあります。

• 要求管理ツール
• 不具合管理システム
• Wiki
• 静的解析ツール
• トレーサビリティ管理

です。

例えば不具合管理システムは、過去の失敗から学ぶための仕組みとも考えられます。

静的解析ツールは、ベテランレビュアの観点を自動化したものとも考えられます。

そう考えると、私たちは新しい品質保証活動を作ることばかり考えていますが、
実は既にレビュー価値の一部はツールやプロセスの中に埋め込まれているのかもしれません。

人に任せすぎているのかもしれない

前回の記事では、品質保証活動が人の頑張りに依存しているのではないかという話を書きました。

今回の話もそれにつながるように思います。
例えばコードレビューでは、人が見なくてもよい内容まで人が確認していることがあります。

その結果、本来人が考えるべき

• 設計意図
• 顧客価値
• リスク

に十分な時間を使えなくなります。

人が得意なこと。
ツールが得意なこと。
それぞれに役割を分担し、レビュー価値を仕組みとして実現していく。

そのような方向が必要なのかもしれません。

おわりに

今回の記事を書きながら、レビューとは何かについて考えてみました。

当初は、「レビューは品質を保証しているのか」
という問いから始まりました。

しかし考えていくうちに、
「レビューが生み出している価値とは何か」
という問いに変わっていきました。

そしてさらに、
その価値は本当にレビューでしか実現できないのか、
という疑問にもつながりました。

私自身もまだ答えは持っていません。
ただ、レビューの質を高めることだけではなく、
レビューが生み出している価値をどのように開発プロセスやツールへ埋め込むかを考えることも重要なのではないかと感じています。

皆さんの現場では、レビューの価値とは何だと思いますか。
また、その価値を仕組みとして実現する取り組みがあれば、ぜひ教えてください。

---

次回は、

AIによるレビューや監査が進む中で、
QAは何を保証するのかについて考えてみたいと思います。
3. AI時代にQAエンジニアが保証するものは何か？