モデルをレビューするということ
レビューの場面では、つい細部に目を凝らしてしまうことがあります。
テストケースであれコードであれ、「あれも、これも」とパターンや分岐を一つずつ確認していくうちに、気づけばレビュワー自身が設計をやり直しているような状態に陥る──これは多くの人にとって馴染みのある経験ではないでしょうか。
私自身、テストケースや探索的テストのチャーターをレビューする際、意図せず細部に立ち入りすぎてしまったことが何度もあります。その結果、レビューに非常に時間がかかるだけでなく、深いドメイン知識や仕様の理解が求められるため、他チームや新人が入り込みづらくなるという課題も感じていました。そして気がついたら私しかレビュワーがいないという状態になった経験もありました。
どこまでがレビューの適切な範囲で、どこからが設計の再実施になるのか──今回は、そんな視点から「レビュー文化」について考えてみたいと思います。
設計をやり直してしまうレビューとは何か
まず整理したいのは、「設計をやり直してしまうレビュー」とはどのような状態か、ということです。
テストケースのレビューでは、たとえば次のような振る舞いが挙げられます。
- あらゆるパターンの入力を洗い出そうとする
- チャーターに書かれていない探索ルートを補完しようとする
- 既存の前提条件や入力値のパラメータ設計をゼロから再構成してしまう
コードレビューでも、次のような行動に覚えがあるかもしれません。
- すでに通っている処理を別の方法で書き直す提案ばかりになる
- 変数名や関数の位置など、動作に影響しない部分に過度に注目してしまう
- 設計方針に関わる判断をレビュー時に覆そうとする
これらの行動には、悪意はありません。むしろ「より良くしたい」という思いの表れです。しかし、設計の本質的な意図が共有されていないまま進むレビューは、しばしば「責任の上書き」や「議論の迷走」につながります。そしてレビューイもまた、「レビューのたびに再設計が必要になる」状況に疲弊してしまいます。
モデルは不完全である
George Box の有名な言葉に「All models are wrong, but some are useful.」というものがあります。
モデルとは、現実の近似です。例えば数学の方程式やファッションモデルもそうです。これらは現実を完全に再現するものではなく、あくまで近似的な表現です。地図が現実のすべてを表せないのと同じように、テストケースやチャーターも、システムのすべての挙動や可能性をカバーすることはできません。
テストの世界でモデルに頼るということは、「限られた情報と時間のなかで、現実をどう表現し、どう判断するか」を模索する行為です。
一方で、ソフトウェアの世界では事情が異なります。仕様や設計といったモデルがプログラムを導き、コンピュータはそのプログラム通りに動作するため、モデルが現実を正確に反映していないとコンピュータは正しく動作しません。つまり、ソフトウェアのモデルには近似が許されません。なのにモデルは不完全であるというジレンマを抱えています。
レビューにできること・できないこと
レビューとは、モデル（テストケースやチャーター）を客観的に見直す試みです。ただし、それによってモデルが「完全」になることはありません。
レビューでできるのは、「このモデルは目的に対して十分に役立つか？」という問いに対し、よりよい判断を重ねることです。
つまり、「正しさ」ではなく「有用性」を問い直す行為であり、「漏れをゼロにする」ことを目指すものではないということです。
レビューは「補完」であり「伴走」である
レビューの本来の役割は、「設計の正しさ」を裁くことではありません。それはすでに設計者が責任をもって判断しているはずです。
レビューが果たすべき役割は、次のような補助的かつ対話的なものです。
- テストパターンや入力値ではなく、さらに抽象的なシナリオやテスト観点により良い改善点を見つける
- 設計意図が読み取れるかを確認する
- 読み手・実行者としての視点を提示する
- 設計を他者と共有し、属人性を減らす
レビューとは、完成度を高めるための「磨き」のプロセスであり、ゼロからの「作り直し」ではありません。この考え方は、テストでもコードでも変わりません。
網羅の恐怖と、その先へ
このように、レビューとは完成度を高めるための磨きのプロセスですが、一方で「テストパターンを見逃して不具合を見逃すのではないか」という不安は、ごく自然な感情です。「見落としたくない」「ちゃんと守りたい」という気持ちは、職業的な責任感や誠実さの現れでもあります。
ただし、その恐れが「すべてを網羅しなければならない」という発想に変わると、やがて自分や他者を縛る「正しさのエゴ」になってしまいます。
だからこそ、テストはモデルであり不完全であるという前提を忘れず、その不完全さのなかで最善の問いを立て、最善の判断を重ねる。それが、テスト設計のレビューにおける「磨く」という行為の本質だと考えています。
コードレビューにも通じる視点
この考え方は、コードレビューにも広く適用できます。
たとえば、コードレビューでは以下の点が重視されます。
- 意図が読み取れるか
- 可読性があるか（他の開発者が理解できるか）
- 影響範囲が明確か（副作用や依存関係に気づけるか）
- テストやログ、エラーハンドリングの観点があるか
大切なのは、「自分ならどう書くか」ではなく、「このコードの意図と選択は、チームとして妥当か？」 という視点です。
一方で、コードは、設計や仕様という抽象的なモデルを具体的に表現したものであり、コンピュータがそのまま実行する「実行可能なモデル」です。そのため、コードが設計や仕様を正確に反映していない場合、システムが期待通りに動作しなくなる可能性があります。
コードレビューでは、以下のような観点で「正確性」を確認します。
- 仕様の忠実性: コードが仕様を正確に実装しているか。
- 振る舞い: 振る舞いは要件通りか。
- 設計の意図: 設計者の意図がコードに正しく反映されているか。
- エッジケースの考慮: 想定外の入力や状況に対しても正しく動作するか。
ただし、コードレビューの目的は「正確性」だけにとどまりません。以下のような観点も重要です。
- 可読性: 他の開発者がコードを理解しやすいか。コードが正確であっても、可読性が低いと保守性が損なわれます。
- 効率性: パフォーマンスやリソースの効率が適切か。
- 拡張性: 将来的な変更や機能追加に対応しやすい設計になっているか。
- 一貫性: チームのコーディング規約や設計方針に従っているか。
これらの観点も含めて、コードが「設計や仕様を正確に表現しつつ、実用的であるか」を確認するのがコードレビューの役割です。
テスト設計レビューとコードレビューの違い
これに対して、テスト設計は 「モデルが正確かどうか」ではなく、「モデルが有用かどうか」 を問うものです。テスト設計は、開発の目的を達成するシナリオやシステムのリスクや不安を洗い出し、それを検証するための近似的なモデルです。そのため、テスト設計レビューでは「このテスト設計が目的に対して十分に役立つか？」という観点が重視されます。
一方、コードレビューでは、コードが「仕様や設計というモデルを正確に表現しているか？」が中心的な問いとなります。この違いが、コードレビューとテスト設計レビューの本質的な違いと言えるでしょう。
「誰でもレビューできる」状態を目指す
モデルは不完全であるというレビューの考え方を共有しました。
レビューは、成果物をより良いものにするための重要なプロセスです。しかし、レビューが特定の人に依存してしまうと、属人化が進み、チーム全体の効率や成長を妨げる可能性があります。特に、深いドメイン知識や仕様の理解が求めらるレビューになってしまうと、「特定の人しかレビューできない」という状況に陥りがちです。
そこで目指したいのが、「誰でもレビューできる」状態です。これは、レビューの観点を明確にし、属人性を排除することで実現できます。そして、そのための鍵となるのが、「モデルは不完全である」という前提を受け入れることです。
その前提を元に、レビューの目的を 「完全性の追求」から「有用性の向上」へとシフトさせ、レビューは「すべてを正す」場ではなく、「成果物が目的に対して十分に役立つか」を問い直す場という前提からレビュー観点を設計するのが良さそうです。
そうすると、どんなチームメンバーであってもレビューができる状態になるのではないでしょうか。その結果、レビューイはレビューを通して学びますし、レビュワーも他人の設計から学ぶことで学びが蓄積されるのではないでしょうか。
さいごに…モデルは磨く。レビューは学び合い。
コードレビューとテスト設計レビューは、それぞれ異なる目的を持っています。テストケースやチャーターはモデルであり、モデルは不完全です。そのモデルを磨くことで「限られた情報と時間のなかで、現実をどう表現し、どう判断するか」を模索することができると思います。
テスト設計は、システムの挙動を評価するためのモデルであり、近似的な性質を持っています。そのため、レビューの目的は「有用性」と「リスクの網羅性」に重点が置かれます。
テスト設計がシステムの重要なリスクを十分にカバーしているか、目的に対して適切な観点が含まれているかを確認することが主な目的です。
そしてレビューは対話であり、学びの場です。レビューイはレビューを通して学びますし、レビュワーも他人の設計から学ぶ場であると私は思っていますし、設計者を支え、伴走する場でありたいと私は思います。
レビューを通じて磨かれるべきは「成果物」だけではなく、「レビュー文化」「学びの蓄積」です。
誰かの設計に敬意を払いながらも、問いを投げ、意図を探り、別の視点を持ち寄る。
こうしたレビューを一つ一つ積み重ねていくことで、テストの設計力もチーム力も少しずつ育っていくものだと私は信じています。皆さんはどうお考えになるでしょうか。
Discussion