今日の最短ルート（15分しかない日）：① 読み手プロファイル（30秒） → ② 4段階の Good と Best を見比べる（5分。Goodは項目が揃っているが「テストしない範囲」が「別途協議」で、4月型の誤りをどの試験が見つけるか書かれていない。Bestは「どこまで試すか」の3案と、各案で見つけられない誤りで書き直す） → ③ 演習の15分版（10分）。着手しないより、3つだけやる方が良い。
今日の文書 — テスト計画書
テスト計画書 — 「何を・どこまで・誰が・いつ・どんな基準で試し、何を試さないか」を、作る人・試す人・受け入れる人の全員が同じ理解で持つための文書。個々のテストケース（テスト仕様書）の前に置かれ、「試験が足りているか」を後で議論できる唯一の基準になる。
ソフトウェアテストの国際規格 ISO/IEC/IEEE 29119-3 のテスト計画書の雛形は、テストする機能と、テストしない機能（その理由つき）を、別々に書く構成を持つ（検索結果の要約で確認。規格本文は未読）。「テストしないこと」を理由つきで書かせるのは、試験は必ず何かを見逃す前提で、見逃しの範囲を承認者に見せるためである。
この文書の勝負どころ: テストしない範囲が明記されているか。 今日はこれを実務の言葉に言い換える。明記されているとは、「やらないこと」の一覧があるだけでなく、各項目に「なぜやらないか」と「やらないと何が見逃されるか」が書かれ、承認者がそれを引き受けるかどうかを選べることである。「全機能をテストする」と書いた計画書ほど、実際には何をテストしないかが誰にも分からない。
| 層 | 例（今日の題材） | 誰が決めるか |
|---|---|---|
| 試す範囲（何を） | 贈り物の判定を、4月の出荷データ27,720件に当てはめて確かめる | 開発・QA・業務の合意 |
| 試さない範囲（理由つき） | 注文後の送り先変更。月数件で、別に決めると要件で合意済み | 承認者（業務の責任者）が引き受ける |
| 合格の基準 | 無作為300件の目視で、誤投入が0件 | 承認者。試験の限界（0件でも言えること）を知った上で決める |
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day015の続き）。
2028年6月19日（月）。Day015の要件確認会（5/30）で、「贈り物」の定義は案B（包装・のしを選んだ注文、または送り先が注文者と違う注文）に決まった。設計は6/5に始まり、長谷川さんの実装は6/23（金）に終わる予定。7/3（月）から、夏のレビュー依頼カードの同梱が始まる。1日約925箱に入る〔導出: Day015の案Bの数〕。
4月の失敗（贈り物の受取人へ約720箱の誤投入〔実測: Day015〕）を繰り返さないために、「判定が正しいか」を、本番の前に誰がどう確かめるかの計画書が要る。長谷川さんの会社の標準は「開発が単体テスト、情報システム部が結合テスト、業務は受入テスト」だが、業務側（今井課長）が受入テストにどれだけ人を出せるかが決まっていない。判定の正しさを一番よく知るのは、物流とCSの現場である。
- 提出: 6/19（月）17:00 までに今井課長と長谷川さんへ。計画確認会は 6/21（水）15:00（30分）。受入テストの日は 6/27（火）〜6/28（水）、リリース判定会 6/29（木）15:00、本番反映 6/30（金）夜、同梱開始 7/3（月）
- 読み手: 今井課長（承認者・受入テストの人員の出し手）、長谷川さん（自動テストの範囲を決める開発リード）。石井さん（品質保証グループ。Day010から登場。助言役）は計画書の「基準」の部分を見る
- カタログの主な読み手（QA・開発・発注者）が、今回の1周目のレベル（他部署＝今井課長）とそのまま一致する。ルール5の工夫は不要
- 制約: 今井課長は6月に別件（梅雨時期の出荷増）があり、出せる人員は最大2名・各半日×2日までと事前に聞いている〔仮定〕
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 今井課長（物流本部 出荷管理課長）と、長谷川さん（情報システム部 開発リード）。石井さん（品質保証）は助言 |
| 何を判断するために読むか | 今井課長: 受入テストに誰を何時間出すか、何をもって「合格」と言うか。長谷川さん: 自動テストでどこまで確かめるか、どの日に何を渡すか |
| 何を知っているか | 4月の誤投入と、5/30に決めた定義B。現場の梱包の実際（今井課長）、判定の実装（長谷川さん） |
| 何を知らないか | 今井課長は「テスト」の種類（単体・結合・受入）の違いと、「0件だったから安全」とは言えない理由。長谷川さんは、業務の人が目で見て何を「贈り物」と思うか |
| 何を気にしているか | 今井課長: 人員の負担、また現場に苦情が来ないか。長谷川さん: 後出しで範囲が増えないか、受入で見つかった問題を誰がいつ直すか |
| 読む時間と場面 | 6/21の確認会の前に、紙に印刷して各自10分。会議は30分 |
この読み手が変わると何が変わるか: 読み手が石井さん（QA）なら、テストの種類と網羅の基準を先に書く。今井課長（承認者）なら、試験で見つかること・見つからないことと、人員の使い方の選択肢を先に書く。
4段階で見る — 「テストの範囲と合格の基準」
以下は同じテスト計画書の 「テストの範囲と合格の基準」 の部分を、4段階で書き分けたもの。
Bad
「全機能をテスト」で範囲が空。
「重大」未定義、人員・日付なし。
「詳細は別途協議」で先送り。Good
対象・対象外・レベル・完了基準の型は完璧。
対象外は理由なしの「別途協議」。
網羅率80%は4月型の誤りに効かない。Better
試すことを要件R-1〜R-4に1対1で結ぶ。
試さない表に理由と見逃しの列。
「0件」の意味はまだ書いていない。Best
冒頭は「決めていただきたい2点」。
人員の3案を「見つかる／見つからない誤り」で比較。
0件でも上限1.0%、決まらなければ6/22に案B。Bad
"All functions will be tested".
"Critical" undefined; no people or dates.
"Details to be discussed".Good
Scope / levels / exit criteria in place.
Out of scope: "TBD", no reasons.
80% coverage misses April-type errors.Better
One test per requirement (R-1 to R-4).
Not tested: Why / What may be missed.
Meaning of "zero defects" still missing.Best
"Decisions requested" first.
Options by what each can / cannot find.
Zero errors still allows 1.0%; default Option B Jun 22.Bad — 妥協して雑に作った状態 ／ 16行
1. 目的
同梱物の対象判定機能の品質を確保する。
2. テスト範囲
本機能に関する全機能をテストする。
3. テスト方法
単体テスト、結合テスト、受入テストを実施する。
テストケースは別途作成する。
4. 合格基準
重大な不具合がないこと。
すべてのテストケースが合格すること。
5. 体制
開発: 情報システム部 受入: 物流本部
6. スケジュール
6月中に実施する。
7. その他
詳細は別途協議とする。Bad ／ 13行
1. Objective
Ensure the quality of the insert eligibility function.
2. Scope
All functions related to this feature will be tested.
3. Approach
Unit, integration and acceptance testing will be performed.
Test cases will be prepared separately.
4. Exit criteria
No critical defects. All test cases pass.
5. Resources
Dev: IT Dept. Acceptance: Logistics
6. Schedule: during June
7. Other: details to be discussed英文としての型
英文では "All ... will be tested" が、何も約束していない文に読まれる。"No critical defects" の "critical" が未定義な点は、英語圏のQAが真っ先に指摘する。受動態のため、誰がやるかも不明。
Good — 型は満たしている ／ 15行
テスト計画書 TP-003（第1版 2028/6/19）
2. テスト範囲
テスト対象: 同梱物対象判定機能（要件 R-1〜R-4）
テストしない範囲: 定期便・法人の注文、注文後の送り先変更、性能試験
（別途協議）
3. テストレベルと実施内容
レベル 実施者 内容 合格基準
単体 開発 判定ロジックの各分岐 網羅率 80% 以上
結合 情報システム部 出荷指示取込〜納品書印字 全ケース合格
受入 物流本部 業務シナリオの確認 重大な不具合 0件
4. 完了基準
全ケース合格、重大・高の不具合 0件、未修正の中・低は承認を得る
5. リスク
判定条件の定義変更、データの欠損
（ISO/IEC/IEEE 29119 の雛形に沿って作成）解説 動いた軸：①結論の位置 ／ ③事実と解釈の分離 ／ ④次の行動
Badから何が変わったか:
- ①結論の位置が動いた。「テスト対象」と「テストしない範囲」が、節の冒頭に分けて書かれた
- ④次の行動が動いた。レベルごとに実施者と内容、合格基準が表に整理された。「受入は物流本部」と所属が分かる
- ③事実と解釈の分離が動いた。完了基準に不具合の重大度（重大・高・中・低）の区分が入った
- テスト計画書の標準の型（対象・対象外・レベル・完了基準・リスク）が揃っている。社内の書式があれば、これで提出できる
まだ足りないもの（ここが今日の本題）:
- 「テストしない範囲」の理由がなく、「別途協議」で閉じている。 今井課長は、見逃されるものが何か分からないまま、承認する
- 合格基準が、4月の誤りを見つけられるかを示していない。 単体テストの「網羅率80%」は、判定の分岐の通過率で、定義と現場の実態のずれ（4月の誤りの原因）は網羅率が100%でも見つからない。基準の数字はあるのに効かない（Day010のGoodと同じ型）
- 受入テストの「業務シナリオの確認」が何件・何分か分からない。 今井課長は、人員を出せるかを判断できない
- 試験で何が分かるのか、分からないのかが書かれていない。 「重大な不具合0件」の意味が、試験をやる前に決まっていない
- 今井課長の問い「現場の負担」への答えがない。
Good ／ 12行
Test Plan TP-003 (v1.0, 19 Jun 2028)
2. Scope
In scope: insert eligibility function (R-1 to R-4)
Out of scope: subscription/corporate orders; ship-to changes after
order; performance testing (TBD)
3. Test levels
Level Owner Content Pass criteria
Unit Dev Each branch of the logic >= 80% coverage
Integration IT Import to packing-slip print All cases pass
Acceptance Logistics Business scenarios 0 critical defects
4. Exit criteria: all cases pass; 0 critical/high; medium/low by approval
5. Risks: rule changes; missing data英文としての型
ISO/IEC/IEEE 29119 の型（In scope / Out of scope / Levels / Exit criteria / Risks）が揃っている。ただし "(TBD)" は英語圏では決めていないことの宣言で、承認者は引き受けない。対象外に理由を書かない点が、英文でも欠ける。
Better — 読み手に最適化されている ／ 12行
2. 何を試し、何を試さないか（今井課長・長谷川さんへ）
試す（要件 R-1〜R-4 に1対1） 確かめ方 誰が
T-1 贈り物と決めた箱に入れない（R-1） 4月全件27,720件を案Bで再判定し、
4月の苦情9件の注文が「対象外」になる 長谷川さん
T-2 作業者に判断させない（R-2） 納品書の印以外を見る手順が無いこと 今井課長（貼り紙確認）
T-3 条件の追加だけで済む（R-3） 試験用の同梱物を1本追加し、所要日数を記録 長谷川さん
T-4 間違いに早く気づける（R-4） 日報の枚数差の表示を確認 長谷川さん
試さない 理由 見逃されうるもの
注文後の送り先変更 月数件。5/30に別に決めると合意済み 変更後の箱に誤って入る（月数件）
定期便・法人 別ライン。同梱対象外 なし（対象外のまま）
性能（取込から判定までの時間） 現行の夜間バッチに足すだけ。4月全件の再判定の所要時間を記録して代える 本番の処理遅れ
合格: T-1〜T-4 が全て合格。不具合は「業務に影響する／しない」で分類解説 動いた軸：②読み手適合 ／ ⑤想定反論
Goodから何が変わったか（★ここが今日の学習の中心）:
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 今井課長が判断すること「人員と合格」 | 試験の単位を、開発の分類（単体・結合）から、要件R-1〜R-4に1対1の「試すこと」に変えた。今井課長は、自分が合意した要件が試されるかを、1行ずつ確認できる |
| 今井課長が知らないこと「テストの種類」 | 「単体・結合・受入」という言葉を本文から外し、誰が何をするかだけを書いた。種類の名前は付録に回せる |
| 今井課長が気にすること「何が見逃されるか」 | 「試さない」の表に理由と「見逃されうるもの」の列を足した。Goodの「別途協議」は、承認者が見逃しを知らずに承認する形だった |
| 長谷川さんが気にすること「後出しで範囲が増えないか」 | 範囲を要件に結びつけ、要件にない試験は計画にないと読めるようにした。範囲の議論が要件のIDで行える |
| 長谷川さんが知りたいこと「何を渡せばよいか」 | T-1は4月全件の再判定と、苦情9件の注文を回帰ケースとして含めることを書いた。既に起きた誤りを再発させない最小の試験 |
| 「0件」の意味 | Betterではまだ書いていない。T-1の「4月全件の再判定」は、判定が定義Bどおり動くことしか確かめない。定義Bが現場の実態に合うかは確かめない |
「網羅率」と「見つけたい誤り」: Goodの「網羅率80%」は、コードの分岐の何割を通ったかを示す。しかし4月の誤りは、コードが正しく動いていて、定義が実態とずれていたために起きた。この種類の誤りは、人が見て判断する以外に見つける方法がない。基準は、見つけたい誤りの種類から決める。
それでも残っている問題（Bestで扱う）:
- T-1は「定義Bどおり動く」ことしか確かめない。 4月の誤りの種類（定義と実態のずれ）を見つける試験が、人員なしでは入らない
- 「どこまで試すか」の選択肢が、今井課長に見えない。 人員を出せば何が分かり、出さなければ何が分からないのかが書かれていない
- 「合格」が何を保証するかが不明。 0件だったとき、本番で何件までの誤りを否定できるのか
- 決まらなかったときの動きがない。 6/21に決まらなければ、6/27の受入に人が集まらない
ここで動いた軸: ②読み手適合（開発の分類から、今井課長の合意した要件に1対1の試験へ）、⑤想定反論（見逃しを理由つきで明示）。
Better ／ 12行
2. What we test and what we do not (for Mr. Imai and Mr. Hasegawa)
Test (one per requirement) How we check Owner
T-1 No insert in gift boxes (R-1) Re-run April's 27,720 orders on Rule B;
the 9 complained orders must be excluded Hasegawa
T-2 No operator decision (R-2) No step other than the mark Imai
T-3 Rule entry only (R-3) Add 1 trial insert; record days Hasegawa
T-4 Early error detection (R-4) Verify the shift-end count difference Hasegawa
Not tested Why What may be missed
Ship-to change after order A few per month; agreed on May 30 Wrong insert after change
Subscription/corporate Separate line None
Performance Nightly batch; record April re-run time instead Delay in production
Pass: T-1 to T-4 all pass; defects classed as business impact / none英文としての型
主語を試験の対象（"No insert in gift boxes"）にし、要件IDに1対1で結んだ。"Not tested / Why / What may be missed" の3列は、英語圏の「リスクの受け入れ」の型で、承認者が見逃しに署名する形になる。
Best — 読み手が意思決定できる ／ 10行
6/21（水）の確認会で、今井課長に決めていただきたいこと（2点）
① 受入テストにどこまで人を出すか（案: B）
案 内容 見つかる／見つからない誤り 物流の工数
A 自動の再判定のみ（4月全件を案Bで） 定義Bどおり動くか／現場の実態とのずれは見つからない 0
B A＋物流・CSが無作為300件を目で見て判定 4月型の誤り（2.6%）は見逃し確率0.04%／0件でも誤判定率の上限1.0%まで 2名×約5時間（6/27〜28）
C B＋7/3〜7/7の初週、毎日92箱を現場で突合 本番の初週の実態／本番に出てから分かる B＋1名×毎日30分
② 合格の基準（案: 300件中、誤投入側の誤判定0件）。0件でも本番の誤りの上限は1.0%（約270箱/月）まで。それを超えたら7/3は延期
試さない: 注文後の送り先変更（月数件）／定期便・法人（対象外）／性能（4月全件の再判定時間で代える）
決まらなかったら: 6/22（木）12:00までに宮田が案Bで人員を確保し、6/27に始める
7/3に間に合わなくなる条件: 6/29の判定会で①誤投入側の誤判定が1件でも出て、②原因が当日中に直らない場合は、同梱を7/10に延ばす解説 動いた軸：①結論の位置 ／ ④次の行動 ／ ③事実と解釈の分離 ／ ⑤想定反論
Betterから何が変わったか:
- ①結論の位置が動いた。冒頭を「決めていただきたいこと」にし、案と推奨を先に出した
- ④次の行動が動いた。決まらなかったときの扱い（6/22 12:00）と、延期の条件（6/29の判定）が決まった
- ③事実と解釈の分離が動いた。0件の意味（誤判定率の上限1.0%）を、試験の限界として書いた
- ⑤想定反論が動いた。案Aの「人員0」が魅力的に見える反論を、「見つからない誤り」の列で先回りした
今回はBestまで作るべきか: Best必要。承認者が人員の負担と、見逃しを引き受ける判断を同時にする文書で、判断を誤ると4月の誤投入が再発する。ただし、同梱物の2本目以降は、案Bの形を雛形にした「Better相当」の1枚で足りる。
Best ／ 10行
Decisions requested at the June 21 meeting (2)
1. How much of Logistics' time to commit (we recommend B)
Opt Content What it can / cannot find Logistics effort
A Automated re-run on April data (Rule B) Confirms the rule runs as written; cannot find gaps between rule and reality 0
B A + Logistics/CS review 300 random orders Would miss a 2.6% April-type error with p = 0.04%; zero errors still allows up to 1.0% 2 people x ~5 h (Jun 27-28)
C B + daily on-site check of 92 boxes, Jul 3-7 Real first-week behavior; finds issues only after launch B + 1 person x 30 min/day
2. Pass criterion (proposal): 0 gift-side misjudgments in 300. Zero errors still allows up to 1.0% (~270 boxes/month). If exceeded, launch moves from Jul 3.
Not tested: ship-to changes after order (a few/month); subscription/corporate (excluded); performance (replaced by April re-run time)
If undecided: Miyata secures staff on Option B by noon Jun 22; testing starts Jun 27.
Delay trigger: at the Jun 29 go/no-go, one or more gift-side misjudgments that cannot be fixed the same day move launch to Jul 10.英文としての型
"Decisions requested" で始め、選択肢の表に "can / cannot find" の列を置いた。英語圏のQAでは、"zero defects" を保証と読ませないために、検出力（p = 0.04%）と上限（up to 1.0%）を数字で書くのが誠実とされる。"We recommend B" の主語（we）の明示も英文の型。
---
日英差分ノート
1. 日本語の「別途協議」は丁寧、英語の "TBD" は未決の宣言
日本語の計画書では「詳細は別途協議とする」が礼儀正しい先送りとして通る。英語で "TBD" や "to be discussed" を承認者に出すと、「決めていない」ことが署名できないので差し戻される。英語版は "If undecided: ..."（決まらなかったときの既定動作）を必ず添える。
2. 「全機能をテストする」は、英語では "100% coverage" の主張に読まれる
日本語の「全テスト」は意気込みの表現だが、英語の "all functions will be tested" は検証可能な約束と読まれる。できない約束は書かないのが英文の基準で、"Not tested / Why / What may be missed" の3列がその代わりになる。
3. "zero defects" と「不具合0件」の重みが違う
日本語の「重大な不具合0件で合格」は、安心の言葉として使われる。英語圏のQAでは "Absence of evidence is not evidence of absence" が通念で、0件の隣に検出力と上限を書く。今日の数字: 300件で0件でも、誤判定率の上限は約1%（rule of three: 3÷300）。
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| テスト範囲 / 対象外 | In scope / Out of scope | 中立。対象外には理由を添える |
| 合格基準 / 完了基準 | Pass criteria / Exit criteria | 強い。数字で書く。"Exit" は試験を終える条件 |
| 受入テスト | User acceptance testing (UAT) | 業務側が合否を決める試験 |
| 別途協議 | To be discussed / TBD | 弱い。承認者には出さない |
| 見逃しうるもの | Residual risk / What may be missed | 中立。承認者が引き受ける内容 |
| 延期の条件 | Go/no-go criteria | 強い。事前に決めておく |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | 「全機能をテスト」で結論がない | 対象と対象外が節の冒頭 | 要件に1対1の「試すこと」が先頭 | 冒頭が「決めていただきたい2点」と推奨 |
| ② 読み手適合 | 想定していない | 開発の分類（単体・結合・受入） | 今井課長の合意した要件のIDで構成 | 人員の負担と見逃しの引き受けを選ぶ形 |
| ③ 事実と解釈の分離 | 「重大」が未定義 | 重大度の区分がある | 試さない理由・見逃しが別の列 | 検出力0.04%・上限1.0%を試験の限界として明示 |
| ④ 次の行動 | 「別途協議」 | 実施者と内容が表にある | 誰が何をするか | 6/22 12:00の既定動作と、6/29の延期条件 |
| ⑤ 想定反論 | 無視 | リスクに一行 | 「別途協議」を理由に置き換え | 「案Aで人員0」への反論を列で先回り |
今回の学習の中心は Good → Better → Best。 Good→Better は 開発の分類（単体・結合・受入）を、合意した要件に1対1の「試すこと」に直し、「試さないこと」に理由と見逃しを書くという読み手最適化。Better→Best は 「どこまで試すか」を承認者が選べる形に開き、0件でも言えること（上限1.0%）と、決まらなかったときの動き・延期の条件を足した。
Best版・全文
日本語版 全文を見る
テスト計画書 TP-003（夏のレビュー依頼カード同梱・判定機能） 2028年6月19日 宮田 宛先: 今井課長（物流本部）、長谷川さん（情報システム部） 写し: 石井さん（品質保証）
1. 6/21（水）15:00の確認会で決めていただきたいこと（2点）
① 受入テストにどこまで人を出すか（案: B）
| 案 | 内容 | 見つかる／見つからない誤り | 物流の工数 |
|---|---|---|---|
| A | 自動の再判定のみ（4月全件27,720件を案Bで） | 定義Bどおり動くかは分かる。現場の実態とのずれは見つからない | 0 |
| B（推奨） | A＋物流・CSが無作為300件を目で見て判定 | 4月型の誤り（2.6%）を見逃す確率は0.04%。0件でも誤判定率の上限は1.0%まで | 2名×約5時間（6/27〜28） |
| C | B＋7/3〜7/7の初週、毎日92箱を現場で突合 | 本番の初週の実態が分かる。ただし本番に出てからの発見 | Bに加え1名×毎日30分 |
② 合格の基準（案: 300件中、誤投入側の誤判定0件）。0件でも本番の誤りの上限は1.0%（月約270箱）まで。これを超える兆候が出たら、7/3は延期する。
2. 何を試し、何を試さないか
| 試すこと（要件と1対1） | 確かめ方 | 誰が |
|---|---|---|
| T-1 贈り物と決めた箱に入れない（R-1） | 4月全件を案Bで再判定。苦情9件の注文が「対象外」になること。さらに300件を目視 | 長谷川さん／物流・CS |
| T-2 作業者に判断させない（R-2） | 納品書の印以外を見る手順が貼り紙にないこと | 今井課長 |
| T-3 条件の追加だけで済む（R-3） | 試験用の同梱物を1本足し、所要日数を記録 | 長谷川さん |
| T-4 間違いに早く気づける（R-4） | 毎シフト終了時の枚数差の表示 | 長谷川さん |
| 試さないこと | 理由 | 見逃されうるもの |
|---|---|---|
| 注文後の送り先変更 | 月数件。5/30に別に決めると合意済み | 変更後の箱への誤投入（月数件） |
| 定期便・法人 | 別ライン。同梱の対象外 | なし |
| 性能（取込から判定まで） | 現行の夜間バッチに足すだけ。4月全件の再判定の所要時間を記録して代える | 本番の処理遅れ |
3. 判定の目視（案B）の約束事
- 判定者は、注文画面を見て「贈り物ですか」と聞かれたと想定して答える。システムの判定は見せない
- 「誤投入側」（人は贈り物と判断、判定は対象）は不合格の対象。「見逃し側」（人は贈り物でないと判断、判定は対象外）は案Bの既知の代償（月最大約220件）として記録のみ
4. スケジュールと不具合の扱い
- 6/23（金）実装完了 → 6/26（月）自動再判定 → 6/27（火）〜6/28（水）目視300件 → 6/29（木）15:00 判定会 → 6/30（金）夜 本番反映 → 7/3（月）開始
- 不具合は「業務に影響する／しない」で分ける。影響する不具合は当日中に長谷川さんが原因を示し、直らなければ延期
5. 決まらなかったら: 6/22（木）12:00までに宮田が案Bで人員を確保し、6/27に始める。 延期の条件: 6/29の判定会で、誤投入側の誤判定が1件でも出て、原因が当日中に直らない場合は、同梱を7/10（月）に延ばす。
English 全文を見る
Test Plan TP-003 (Summer review-request card insert: eligibility function) 19 June 2028 Miyata To: Mr. Imai (Logistics), Mr. Hasegawa (IT) Cc: Ms. Ishii (QA)
1. Decisions requested at the June 21 (Wed) 15:00 meeting (2)
- How much of Logistics' time to commit (we recommend B)
| Option | Content | What it can / cannot find | Logistics effort |
|---|---|---|---|
| A | Automated re-run on all 27,720 April orders (Rule B) | Confirms the rule runs as written; cannot find gaps between rule and reality | 0 |
| B (recommended) | A + Logistics/CS review 300 random orders by eye | Would miss a 2.6% April-type error with p = 0.04%; zero errors still allows up to 1.0% | 2 people x ~5 h (Jun 27-28) |
| C | B + daily on-site check of 92 boxes, Jul 3-7 | Shows real first-week behavior; finds issues only after launch | B + 1 person x 30 min/day |
- Pass criterion (proposal): 0 gift-side misjudgments in 300. Zero errors still allows up to 1.0% in production (~270 boxes/month). If signs point beyond that, launch moves from Jul 3.
2. What we test and what we do not
| Test (one per requirement) | How we check | Owner |
|---|---|---|
| T-1 No insert in gift boxes (R-1) | Re-run April on Rule B; the 9 complained orders must be excluded; plus 300 reviewed by eye | Hasegawa / Logistics, CS |
| T-2 No operator decision (R-2) | No step other than the mark on the posted sheet | Imai |
| T-3 Rule entry only (R-3) | Add one trial insert; record days | Hasegawa |
| T-4 Early error detection (R-4) | Shift-end count difference is shown | Hasegawa |
| Not tested | Why | What may be missed |
|---|---|---|
| Ship-to change after order | A few per month; agreed on May 30 | Wrong insert after change |
| Subscription/corporate | Separate line; out of scope | None |
| Performance | Added to the nightly batch; April re-run time recorded instead | Production delay |
3. Ground rules for the review (Option B)
- Reviewers see the order screen and answer "is this a gift?" without seeing the system's decision
- Gift-side misjudgments (person: gift; system: eligible) fail the test. Miss-side cases (person: not a gift; system: excluded) are the known cost of Rule B (up to ~220/month) and are only recorded
4. Schedule and defects
- Jun 23 build complete -> Jun 26 automated re-run -> Jun 27-28 review of 300 -> Jun 29 15:00 go/no-go -> Jun 30 evening deploy -> Jul 3 start
- Defects are classed as business impact / none. Impacting defects need a root cause the same day or launch is delayed.
5. If undecided: Miyata secures staff on Option B by noon Jun 22; testing starts Jun 27. Delay trigger: at the Jun 29 go/no-go, one or more gift-side misjudgments not fixable the same day move launch to Jul 10.
完成の定義チェックリスト
テスト計画書を出す前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
進捗 0 / 8
今日の演習
15分版（まずこれだけでもやる）
Bad例の「2. テスト範囲」と「4. 合格基準」の2か所だけを、今井課長向けに書き直す。条件は2つ。①「試さないこと」を3つ、理由つきで書く。②合格基準を、「見つけたい誤り」を先に決めて1行で書く（網羅率や「全ケース合格」は使わない）。
60分版
読み手を変えて、同梱物の2本目（9月の誕生月クーポン）のテスト計画書の「範囲と基準」を書く。 読み手は、CSの松本リーダー（問い合わせ対応側。クーポンの誤配布が来たら受ける）。条件: ①Day016のB案を雛形にするが、今度は誤配布の許容件数を松本さんが決める形にする（誤配布1件あたりの問い合わせ対応を〔仮定〕で置く）。②200件の無作為抽出で0件だったとき、上限は何%か自分で計算する（3÷n）。③試さないことを3つ、理由と「見逃されうるもの」つきで書く。
取り組む前のヒント
- 先に「4月型の誤りは何か」を一言で書く。コードの誤りか、定義と実態のずれかで、必要な試験が変わる
- 「0件」の上限は 3÷n（rule of three）。n=300→1.0%、n=200→1.5%。月の対象件数に掛けると「何件まで否定できないか」が出る
- 罠: 案Aを「楽だから」と推奨しない。見つからない誤りの列を先に書くと、案Aの位置づけが決まる
- 罠: 「重大」を使うときは、誰がいつ決めるかも一緒に書く
実務での使いどころ
テスト計画書は、要件定義書（Day015）の次、テスト仕様書の前に置かれる。要件のIDに1対1で試験が結びついていることが、後のテスト報告書（IT-テスト・リリース#3）の「要件ごとの結果」の表に直結する。リリース計画書（#5）の延期条件は、今日の「延期の条件」を拡張したものになる。業務側が受入テストに人を出す場面（基幹システム更新、新サービス開始）で、人員の使い方を選ばせる型として転用できる。次回のIT-テスト・リリース回（#2 テスト仕様書）は、今日のT-1の「300件の目視」の記録表を、期待値が一意に判定できる形にする続編にできる。
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
迷った他案と採らなかった理由
- 全27,720件を人が目視する案 — 27,720件×2分÷60÷8＝約115人日〔導出〕。承認者が出せる人員（2名×半日×2日）の桁を超えるので却下。サンプルの大きさは、人員の制約と上限の許容から逆算する型にした
- 読み手を石井さん（QA）にする案 — QAはテストの種類と網羅を理解しており、読み手が味方に近い。Lv2の「他部署の承認者」である今井課長の方が、「0件でも安全とは言えない」を説明する意味が大きい
- 網羅率（カバレッジ）を合格基準の中心にする案 — Day010で「数字はあるのに効かない基準」として扱い済み。今回は、4月の誤りの原因（定義と実態のずれ）を見つけるのは網羅率ではない、という点に絞った
- Betterで3案（A/B/C）まで出す案 — Bestとの差がなくなるため、Betterは「要件に1対1・試さない理由・見逃し」にとどめた
- Bestで案Cを推奨する案 — 初週の突合は、本番の実態を見られるが、本番に出てからの発見であり、受入の判定には使えない。前提（物流の人員が2名以上出せる、サンプルでの許容上限1.0%）が変わったら、推奨は変わる（人員0なら案A＋初週突合に倒れる）
- 許容誤判定率を統計から決める案 — 許容できる誤りは統計ではなく承認者（今井課長）が決める。Day013の非劣性マージンと同じ考え方
扱わなかった範囲
- テストの自動化の設計、テスト環境の構築、テストデータの個人情報の扱い（社内目的として扱い、法的確認はしていない）
- 欠陥の管理手順（バグ票の書き方は IT-テスト・リリース#4 に回した）
- 負荷・性能試験の本格的な計画（今回は既存バッチに足すだけと置いた）
- 統計的な検定の詳細（rule of three と、見逃し確率の1行の計算にとどめた）
数字と概念の出所
- 会社・人物・日付・金額はすべて架空。〔実測〕は Day015 までに置いたシナリオ内の実績（4月の誤投入約720箱・苦情9件・初回購入27,720件・案Bの1日約925箱・見逃し最大約220件/月）、〔仮定〕は置いた値（物流の人員2名×半日×2日、1件2分の目視、初週の突合92箱×30分、6月の別件）
- 計算は作成時に Python で行った〔導出〕: 4月型の誤り（2.6%）が300件に1件も出ない確率 0.974^300＝0.037%（約0.04%）。rule of three の上限 3÷300＝1.0%、月27,720件に掛けて約277箱（約270）。全件目視 27,720×2分÷60÷8＝約115.5人日。300件×2分＝10時間（2名で約5時間ずつ）。見逃し側の期待 300×220÷27,720≒2.4件（0件になる確率は約9%＝見逃し側を不合格にしない理由）。95%上限を厳密に解くと 1−0.05^(1/300)＝0.994%（rule of three の近似と一致）
- 日付の曜日（2028/5/22月・5/30火・6/19月・6/21水・6/23金・6/26月・6/27火・6/28水・6/29木・6/30金・7/3月・7/7金）は作成時に計算して確認した
- テスト計画書で「テストする機能」と「テストしない機能（理由つき）」を分ける構成: ISO/IEC/IEEE 29119-3。https://wildart.github.io/MISG5020/standards/ISO-IEC-IEEE-29119-3.pdf 、https://vvpatterns.ait.ac.at/vvpat-test-plan-specification/ （2026-09-30（バックフィル時の扱い）に検索結果の要約で確認。規格本文・PDF は未読）
- rule of three（0件のとき95%上限≒3÷n）は一般的な統計の経験則。Day010で使用済みで、出典ページは今回確認していない（記憶による。上の厳密解で数値は検算済み）
- "Absence of evidence is not evidence of absence" の通念、"TBD" の英語圏での受け取られ方、go/no-go の用語は一般的な実務知識として書いた。出典は確認していない（記憶による）
- 分量（行数）は、各コードブロックの行数を作成後にスクリプトで数えた実測値
解説
何が起きているか:
これは怠慢ではなく、「テストを行う」と「何を試すか決める」の区別がついていないことから生まれる形である。書き手の頭の中ではテスト計画はあるが、読み手が使える形になっていない。