検証に入る前に「目的」を確認するだけで、手戻りはかなり減る (はず？)

はじめに

前回、「複雑な情報を行動に変えるには、判断基準まで絞ることが大事」という話を整理しました。

そこから思い出したのが、検証前の目的合わせです。

開発現場では、同じチケットを見ているはずなのに、メンバーごとに微妙に違うものを見ていることがあります。

• 開発者は「仕様どおり動くか」を見ている
• QAは「壊れていないか」を見ている
• POやPdMは「ユーザーの課題が解けるか」を見ている
• 運用担当は「リリース後に問い合わせが増えないか」を見ている

どれも間違いではありません。問題は、検証に入る前に「今回の検証で何を確かめたいのか」が揃っていないことです。

この記事では、検証前にチームで目的を確認するための実務メモをまとめます。

なお、この記事では「検証」を、テストケースの実行だけでなく、レビュー、ログ確認、リリース判断、運用影響の確認などを含む広い意味で使います。

※本記事は個人の整理メモです。

検証のズレは、観点の違いではなく「目的の違い」から起きる

検証観点が多いこと自体は悪くありません。

ただし、目的が揃っていないまま観点だけを増やすと、次のようなことが起きます。

• QAは境界値を見ていたが、POは業務フロー全体の妥当性を見てほしかった
• 開発者はエラーが出ないことを確認したが、CS（カスタマーサポート）はエラーメッセージの分かりやすさを気にしていた
• レビューではコードの変更範囲を見ていたが、リリース判断では既存ユーザーへの影響が重要だった
• 検証完了後に「で、これは何が大丈夫になったの？」という話になる

これは、誰かがサボったという話ではありません。

同じ「確認する」という言葉の中に、複数の意味が混ざっているだけです。

「何を確認するか」より先に「何のために確認するか」を置く

検証前の会話では、ついテストケースや確認手順から入りがちです。

しかし、手順は目的の後に決まります。

たとえば「ログインできることを確認する」という手順があっても、その目的によって見るべきものは変わります。

• 新規実装の正しさを確認したい
• 既存機能のデグレードがないことを確認したい
• 障害対応後の再発防止を確認したい
• ユーザーが迷わず使えることを確認したい
• リリースしてよい状態かを判断したい

同じ操作でも、目的が違えば、必要な証拠も、見るべきログも、巻き込む相手も変わります。

だから、検証前にはまず次の一文を揃えます。

今回の検証は、〇〇を判断するために行う。

この一文がない検証は、頑張っているのに判断につながりにくくなります。

既存のフレームワークでも「目的」や「成功条件」は重視されている

これは個人的な感覚だけではありません。既存のフレームワークや公開情報を見ても、目的や成功条件を先に揃える考え方は繰り返し出てきます。

ISTQB: テスト目的は「テストをする理由や目的」

ISTQB Glossary では、test objective は「テストをする理由や目的」と説明されています。

つまり、テストは単に手順を実行するものではなく、何らかの理由や目的に向かって行われるものです。

「とりあえず一通り確認しました」ではなく、「この判断のために、この確認をしました」と言える状態にする。ここが検証前の目的合わせの出発点になります。

Scrum Guide: Sprint Goal はチームを別々の活動から引き戻す

Scrum Guide では、Sprint Goal が Sprint の単一の目的であり、チームに一貫性と集中をもたらすものとして説明されています。また、Definition of Done は、成果物が Done と言える基準について共通理解を作るものとされています。

これは検証にもそのまま応用できます。

検証が「各自の観点の寄せ集め」になると、チームは別々の活動をしているような状態になります。そこに「今回の検証で判断したいこと」を置くと、確認観点が同じ方向を向きます。

Atlassian Team Playbook: キックオフでは目的・役割・成功条件を揃える

Atlassian の Project Kickoff Play では、プロジェクト開始時に目的、役割、責任、成功条件（成功の目印）を揃えることが重要だと説明されています。

検証も小さなプロジェクトと考えれば同じです。

特に、複数人で見る検証、リリース判断に関わる検証、障害対応後の検証では、最初に「成功とは何か」を揃えないと、終わったあとに判断が割れます。

検証前に確認したい5つの問い

長い会議は不要です。

検証に入る前に、5分だけ次の問いを確認します。

その前に、この記事で出てくる用語を簡単に整理しておきます。

• 目的: なぜ検証するのか。何を判断したいのか
• OKの主語: 誰の視点でOKと言うのか
• 終了条件: 何が分かれば検証を終えられるのか
• 対象外: 今回の判断に含めないものは何か
• 判断者: 結果を見て最終判断するのは誰か

これらは別々の問いというより、1つの判断を支える5つの面と捉えると、後のテンプレートが使いやすくなりそうです。

1. 今回、何を判断したいのか

最初に確認するのは、検証の目的です。

今回の検証は、リリース可否を判断するために行う。
今回の検証は、障害の再発防止策が効いているかを判断するために行う。
今回の検証は、ユーザーの主要導線が壊れていないかを判断するために行う。

ここが曖昧なままだと、検証結果も曖昧になります。

2. 誰にとってのOKなのか

「OK」の主語を確認します。

開発者にとってOK
QAにとってOK
ユーザーにとってOK
運用にとってOK
リリース責任者にとってOK

たとえば、機能としては正しくても、問い合わせが増えるUIなら運用上はOKではないかもしれません。逆に、内部実装に改善余地があっても、緊急修正としては十分な場合もあります。

OKの主語が違うと、同じ結果に対する判断も変わります。

3. 何が分かれば終わりなのか

検証は、無限に広げられます。

だからこそ、終了条件を先に決めます。

主要3導線で正常完了できる
既存の正常系が落ちていない
対象エラーが再現しない
想定ログが出力される
問い合わせ時に説明できる証跡が残る

「全部見る」ではなく、「今回の判断に必要な証拠は何か」を決めるのがポイントです。

4. 今回見ないものは何か

検証前に「見ないもの」を確認しておくと、後からのすれ違いが減ります。

今回は性能検証は対象外
今回は文言改善は対象外
今回は管理画面だけを見る
今回は既存データ移行までは見ない

これは手抜きではありません。範囲を明確にするための合意です。

もちろん、重大なリスクに気づいたら別途扱います。ただし、それは「今回の検証に混ぜる」のではなく、「追加で判断する」形に分けた方が混乱しにくくなります。

5. 結果を誰がどう判断するのか

最後に、検証結果の受け手を決めます。

QAが結果をまとめ、POがリリース可否を判断する
開発者がログを確認し、SREが運用影響を判断する
CSが問い合わせ観点を確認し、PdMがユーザー影響を判断する

検証する人と判断する人が違う場合、ここを曖昧にすると「確認は終わったが、誰も判断していない」という状態になります。

そのまま使えるミニテンプレート

チケットやSlackに貼るなら、これくらいで十分です。

## 検証前の目的確認

### 目的
今回の検証は、〇〇を判断するために行う。

### OKの主語
誰にとってOKか:

### 終了条件
- 
- 
- 

### 今回見ないもの
- 
- 

### 判断者
検証結果を見て、最終的に〇〇さん / 〇〇ロールが判断する。

重要なのは、きれいなフォーマットを作ることではありません。

検証前に、メンバー間のズレを表に出すことです。

なお、このテンプレートを毎回きっちり埋める必要はありません。軽微な文言修正や、影響範囲が明確な修正では、形式化が逆に負担になります。複数ロールが関わる検証、リリース可否に関わる検証、障害対応後の検証では、最初に数分だけでも目的を揃える価値があります。

例: 「保存ボタンの不具合修正」を検証する場合

たとえば、保存ボタンを押してもデータが保存されない不具合を直したとします。

目的が曖昧だと、各メンバーはこう見ます。

• 開発者: 修正した条件で保存できるか
• QA: 関連する入力パターンで壊れていないか
• PO: ユーザーの主要業務が完了できるか
• CS: 問い合わせ済みユーザーに説明できるか

ここで、検証前に次のように揃えます。

## 検証前の目的確認

### 目的
今回の検証は、保存失敗の再発防止と、主要業務フローのリリース可否を判断するために行う。

### OKの主語
ユーザーが主要入力パターンで保存を完了でき、CSが問い合わせに説明できる状態をOKとする。

### 終了条件
- 障害発生時の入力条件で保存できる
- 通常の新規作成・編集・再保存ができる
- エラー時の表示とログが確認できる
- CS向けに確認結果を説明できる

### 今回見ないもの
- 保存処理の性能改善
- 入力フォーム全体の文言改善
- 管理画面側の一覧表示改善

### 判断者
QAが結果をまとめ、POがリリース可否を判断する。

この状態なら、検証結果がそのまま判断材料になります。

目的合わせで起きる「よい衝突」

目的確認をすると、たまに意見が割れます。

QA: 既存導線の回帰も見たいです。
PO: 今回は障害条件だけ確認できれば出したいです。
CS: 問い合わせが来ているので、説明用の証跡は必要です。

これは悪い衝突ではありません。

むしろ、検証後に起きるはずだったズレが、検証前に出てきただけです。

目的合わせの価値は、全員を同じ意見にすることではありません。違う前提を早めに見つけて、今回の判断基準を決めることです。

まとめ

検証前に目的を確認するだけで、検証の質はかなり変わります。

• 同じチケットを見ていても、メンバーごとに見ている「OK」は違う
• 検証手順より先に、検証の目的を置く
• 「誰にとってのOKか」を確認する
• 終了条件と今回見ないものを決める
• 検証結果を誰が判断するかまで決める

検証とは、作業を消化することではなく、判断に必要な証拠を集めることです。

だからこそ、始める前に一度だけ問いを置きます。

今回の検証は、何を判断するためにやるのか。

この一文が揃うだけで、チームの検証はかなり強くなります。

参考・関連情報

• ISTQB Glossary: テスト目的（test objective）
• Scrum Guides: The 2020 Scrum Guide
• Atlassian Team Playbook: Project Kickoff