今日の文書 — 品質保証計画書（QA計画書）
「何を満たせば、この機能を世に出してよいか」を、作り始める前にチームで決めておく文書。テスト計画書（どうテストするか）より一段上にあり、合格の基準・測り方・判定する人と時期・基準を満たさないときの扱いを定める。これがないと、リリース直前に「どこまでやれば終わりか」を声の大きい人が決めることになる。
この文書の勝負どころ：品質基準が測定可能な形か。
「十分なテスト」「高品質」「バグゼロを目指す」は測れない。一方で「カバレッジ80%」「応答時間3秒以内」のように数字が入っていても、その機能で起きたら困ることと関係がなければ、測れるだけで意味がない。今日は後者——数字はあるのに役に立たない基準——を見分けて直すのが本題になる。
「十分なテスト」「高品質」「バグゼロを目指す」は測れない。一方で「カバレッジ80%」「応答時間3秒以内」のように数字が入っていても、その機能で起きたら困ることと関係がなければ、測れるだけで意味がない。今日は後者——数字はあるのに役に立たない基準——を見分けて直すのが本題になる。
このスキルで使う「測定可能」の定義 — 5点が揃って、誰が測っても同じ判定になること
1. 定義何を1件と数えるか
欠けると：人によって数え方が違い、判定会で揉める
欠けると：人によって数え方が違い、判定会で揉める
2. 測り方データの出どころ・試験の方法
欠けると：「確認した」が口頭だけになる
欠けると：「確認した」が口頭だけになる
3. 閾値合否の線
欠けると：合否が決まらない
欠けると：合否が決まらない
4. 判定する人と時期誰が・いつ
欠けると：誰も決めないまま日付が来る
欠けると：誰も決めないまま日付が来る
5. 未達時の扱い満たさないとき何をするか
欠けると：「今回は仕方ない」で出る
欠けると：「今回は仕方ない」で出る
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day009の続き）。
- 配信基盤の刷新は 2027年10月8日（金）に切替完了。Day009で問題になった「配信停止の反映が翌日午前4時まで遅れる」状態は、旧基盤の停止とともに解消した（新基盤では停止は即時に反映される）
- Day008で承認されたB案どおり、次は LINE配信機能 を新基盤の上に作る。中身は2つ
- 一斉配信：LINE公式アカウントの友だち 182,000人 〔実測：10/1時点〕 へのセール告知
- 個別配信：会員IDとLINEを連携した 64,000人 〔実測〕 のうち、カート放棄した会員へのリマインド。効果は Day008 で決めたとおり 10%の対照群（送らない群）との差 で測る
- 日程：11/16（火）10:00 リリース → 11/26（金）10:00 ブラックフライデーの一斉配信が最初の本番。リリース判定会は 11/10（水）16:00
- LINEでの重複送信は、1通ごとに通数（料金プランの上限）を消費し、ブロック（友だち解除に相当）の原因になる。ブロックされた会員には、その後セールを知らせる手段がなくなる
10月12日（火）、宮田さんは品質保証計画書を書いている。10/13（水）18:00 にチームへ共有し、10/14（木）10:00 のキックオフで合意して開発に入りたい。
- 読み手：実装リードの 佐伯さん（MOps、Day008から登場）と、品質保証グループから兼務で入る 石井さん（QA、新登場）、ほか開発メンバー1名
- カタログ上の主な読み手は「開発・QA」で、1周目の「味方・協力的な読み手」とそのまま一致する。Day007（NDA）に続いて、間接読み手の設定（ルール5）が要らない回
- 面倒な事情：宮田さんは最初、社内の品質保証計画書テンプレート（ISO/IEC 25010 の品質特性ごとに基準を埋める形式）で書いた。表は全部埋まった。しかし佐伯さんにざっと見せたところ、「応答時間3秒って、どの画面のことですか？ この機能、会員が操作する画面ないですよね」と言われた
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | MOps実装リード・佐伯さん、QA兼務・石井さん、開発メンバー1名（計3名）。全員が宮田さんの味方で、良いものを出したいと思っている |
| 何を判断するために読むか | ① この基準に合意して開発に入ってよいか ② 自分は何を・いつまでに測り、何を満たせば「終わった」と言えるか ③ 判定会で自分に何を聞かれるか |
| 何を知っているか | 佐伯さん：新配信基盤の構造、送信ログ・停止ログの場所、Day009の停止反映問題の経緯。石井さん：テスト技法、社内テンプレートの書き方 |
| 何を知らないか | 石井さん：対照群（送らない群）が何のためにあるか、LINE特有のリスク（重複送信のコスト・ブロック）。全員：基準を満たさないとき誰が何を決めるか |
| 何を気にしているか | 開発は実質3週間。テストが際限なく膨らまないか、後から基準を足されないか、ブラックフライデーに間に合うか |
| 読む時間と場面 | キックオフ前に30分、腰を据えて読む。その後は判定会（11/10）まで何度も手元で参照する作業の基準書 |
この読み手が変わると何が変わるか：
読み手が判定者の高梨部長（非エンジニア）なら、基準の一覧ではなく「判定の選択肢（全部出す／一部だけ出す／延期）と、出した場合に残るリスク」の1枚になる（→60分版の演習）。読み手が外部の開発ベンダーなら、同じ基準が契約上の検収条件になり、「満たさないときの扱い」は手直しの期限と費用負担の話に変わる。今回は自分で測って自分で判定材料を出す開発者とQAなので、「どこで・何を数えれば合否が決まるか」を、測る本人が迷わない粒度で書くのが正解。
4段階で見る — 「3. 品質目標と合格基準」
品質保証計画書の本体はこの節であり、ここが測れなければ他の節（体制・日程）がどれだけ整っていても判定はできない。今日は Bad→Good より Good→Better の差が学びの中心（Goodは数字が入っているので、雑には見えない）。
Bad
「十分なテスト」「バグゼロ
を目指す」。測れる語なし。
基準は「別途QAと相談」。Good
規格の品質特性で表を網羅。
数字はあるが「画面3秒」等
この機能のリスクと無関係。Better
「起きたら困る6つ」から。
各基準に定義・閾値・測り方。
外した基準も理由を1行。Best
判定者と A/B/C を冒頭に。
基準ごとの「未達なら」列。
試験0件の限界(3/n)も明記。Bad
"Aiming for zero bugs."
Passive voice throughout;
nobody owns anything.Good
Exit criteria by ISO 25010.
Numbers present, but not
tied to this feature's risk.Better
Six risks, ranked.
Definition / Target / Method
for each criterion.Best
Go/No-Go with an owner.
"If missed" column (A/B/C).
States limits of testing.Bad — 妥協して雑に作った状態 ／ 13行
3. 品質目標
本機能は当社の新たな販促チャネルとなる重要な機能であるため、
高品質なシステムを提供することを目標とする。
・十分なテストを実施し、バグゼロを目指す
・性能面についても問題がないことを確認する
・LINEの仕様に準拠すること
・セキュリティにも十分配慮する
・前回の配信停止の件もあるので、そのあたりも注意する
品質基準の詳細については、別途QAと相談のうえ決定する。
リリース前に最終確認を行い、問題がなければリリースとする。Bad ／ 14 lines
3. Quality Objectives
As this feature is an important new promotional channel for the company,
our goal is to deliver a high-quality system.
- Sufficient testing will be conducted, aiming for zero bugs.
- It will be confirmed that there are no performance issues.
- The system should comply with LINE specifications.
- Adequate attention will be paid to security.
- Given the previous unsubscribe issue, care should be taken there too.
Detailed quality criteria will be determined separately with QA.
A final check will be performed before release, and if there are
no problems, the feature will be released.受動態の連続＝責任者がいない合図
受動態（"will be conducted" "will be confirmed" "will be determined"）が連続し、誰がやるのかが1つも書かれていない。英文では受動態の連続は「責任者がいない」合図として読まれる。"aiming for zero bugs" は英語では基準ではなくスローガンに見える。
Good — 型は満たしている ／ 15行
3. 品質目標と合格基準
ISO/IEC 25010 の品質特性に沿って、以下を合格基準とする。
品質特性 合格基準
─────────────────────────────────────
機能適合性 テストケース合格率 100%
性能効率性 画面の応答時間 3秒以内
信頼性 稼働率 99.9% 以上
セキュリティ 脆弱性診断で重大な指摘 0件
保守性 コードカバレッジ 80% 以上
互換性 LINE Messaging API の仕様に準拠
・リリース時点で重大度「高」のバグが 0件であること
・上記を満たした場合、リリース判定会にてリリースを決定するBadから何が変わったか 動いた軸：③事実と解釈の分離 ／ ④次の行動
- ③事実と解釈の分離が動いた。「十分な」「問題がない」が数字（100%・3秒・99.9%・80%・0件）になり、基準と願望が分かれた
- ④次の行動が「書いてある」水準になった。判定会でリリースを決めることが明記された
- 国際規格（ISO/IEC 25010）の品質特性で網羅性を担保しており、社内の品質保証グループのレビューはこの形で通る
まだ足りないもの（ここが今日の本題）：
- 数字はあるが、この機能で起きたら困ることと繋がっていない。「画面の応答時間3秒」——この機能には会員が操作する画面がない（送信はバッチ）。「稼働率99.9%」——何の稼働率か、どこで測るかがない。測れる形をしているが、測っても合否に意味がない行が混ざっている
- 本当に困ることが1つも入っていない。停止した会員に送る／同じ人に2通送る／対照群に送って効果測定が壊れる／他人のカート商品を送る——どれも「テストケース合格率100%」の中に埋もれ、テストケースに入っていなければ合格してしまう
- 「重大度『高』」の定義がない。佐伯さんと石井さんで判断が割れたとき、決める方法がない
- 満たさなかったときの扱いがない。カバレッジが78%だったら延期なのか。判定会でその場の交渉になる
Good ／ 15 lines
3. Quality Objectives and Exit Criteria
Exit criteria follow the ISO/IEC 25010 quality characteristics.
Characteristic Exit criterion
───────────────────────────────────────────────
Functional suitability 100% of test cases pass
Performance efficiency Screen response time <= 3 s
Reliability Availability >= 99.9%
Security 0 critical findings in vulnerability scan
Maintainability Code coverage >= 80%
Compatibility Complies with the LINE Messaging API spec
- No open Severity-High defects at release.
- If all criteria are met, the release review approves the release."Exit criteria" は正しく使えている
"Exit criteria" は英文のテスト・QA計画で「ここを満たせば終わり」を表す標準の用語で、Goodの段階で正しく使えている。ただし日本語版と同じく、数字の中身がこの機能のリスクと繋がっていない。
Better — 読み手に最適化されている ／ 23行 ← 最長
3. 品質目標と合格基準
このリリースで「起きたら困ること」から基準を作った。上ほど重い。
測る場所: 送信ログ send_log／停止ログ optout_log／割付表 holdout_assign
① 停止後の送信
定義: LINE配信の停止（またはID連携の解除）から5分を過ぎた送信
基準: 0件 測り方: 合成試験200回（停止→5分後に送信ジョブを起動）
② 重複送信
定義: 同じ会員・同じ配信IDへの2通目
基準: 0件 測り方: APIスタブで10万通、タイムアウトを5%注入して再送させる
③ 対照群への送信
定義: 割付表で「送らない」とした会員への送信
基準: 0件、割付比率 10.0%±0.5pt 測り方: 割付表と送信ログの突合
④ 他人向けの内容（カート商品の取り違え）
基準: 0件 測り方: 会員IDとLINE userIdの紐付け 64,000件を全件照合
⑤ 21:00〜翌8:00の送信
基準: 0件 測り方: 送信ログの送信時刻
⑥ 一斉配信の所要時間
基準: 18.2万人へ30分以内 測り方: スタブで18.2万件（500人×364回）
画面の応答時間・稼働率は基準にしない（会員が操作する画面がなく、
送信はバッチのため）。カバレッジは参考値として記録する。Goodから何が変わったか（★今日の学習の中心） 動いた軸：②読み手適合 ／ ③事実と解釈の分離
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 何を気にしているか「テストが際限なく膨らまないか」 | 基準の出発点を「規格の品質特性を全部埋める」から「このリリースで起きたら困ること」に変えた。6項目で閉じており、これ以外は測らなくてよいと読める。範囲の上限が見えることが、開発者にとって最大の安心になる |
| 何を判断するために読むか「自分は何を数えれば終わりか」 | 各基準に定義（何を1件と数えるか）を書いた。「重複送信」を「同じ会員・同じ配信IDへの2通目」と定義したので、佐伯さんと石井さんが数えて同じ数字になる |
| 何を知っているか（佐伯さん）「ログの場所」 | 測る場所をテーブル名（send_log／optout_log／holdout_assign）で書いた。社内の開発者向けだから通じる書き方で、経営層向けなら逆に消す行 |
| 何を知らないか（石井さん）「対照群の意味・LINE特有のリスク」 | ③対照群と②重複送信を独立した基準にした。石井さんはテンプレートの品質特性からは、この2つを思いつけない |
| 読む時間と場面「判定会まで何度も参照する作業の基準書」 | 重い順に番号を振り、1基準＝定義・基準・測り方の3行に揃えた。途中で「②どうなってる？」と番号で会話できる |
削ったものにも理由がある：Goodの「画面の応答時間3秒」「稼働率99.9%」を消し、消した理由を1行で残した。黙って消すと、石井さんはテンプレートとの差を見て「漏れている」と判断して戻してしまう。
順序の変化にも注目：Goodは規格の品質特性の順（機能適合性→性能→信頼性…）だった。Betterは起きたときの重さの順（法令と信頼に関わる①→費用とブロックの②→効果測定が壊れる③→個人情報の④→社内ルールの⑤→性能の⑥）。性能は規格の表では2行目だったが、この機能では一番最後になる。1日のカート放棄は約1,370件 〔導出：月41,000件÷30〕 で、性能が律速になる量ではないからである。
それでも残っている問題（Bestで扱う）：
- 満たさなかったときの扱いがまだない。③が未達のとき、全部延期なのか、一斉配信だけ出せるのかが決まっていない
- 判定する人がいない。石井さんが測った結果を、誰がどの場で合否にするのか
- 「試験で0件」が本番の0件を意味しない。10万通の試験で重複0件でも、本番18.2万通で重複が起きないとは言えない
- リリースした後が入っていない。①停止後の送信は、試験の200回だけで保証できるものではない
- 「カバレッジを参考値にする」に、石井さんは反論しそう。品質保証グループの標準から外れる理由が書かれていない
Better ／ 22 lines
3. Exit Criteria
Derived from what would hurt most if it happened. Ranked by severity.
Data sources: send_log / optout_log / holdout_assign
1. Sends after opt-out
Definition: any send > 5 min after a user opts out or unlinks
Target: 0 Method: 200 synthetic trials (opt out, run job 5 min later)
2. Duplicate sends
Definition: a 2nd message to the same user for the same send ID
Target: 0 Method: 100,000 sends to an API stub, 5% injected timeouts
3. Sends to the holdout group
Target: 0; holdout ratio 10.0% +/- 0.5 pp Method: join assignment and send logs
4. Wrong user's content (cart items sent to someone else)
Target: 0 Method: check all 64,000 member-ID-to-LINE-userId links
5. Sends between 21:00 and 08:00 JST
Target: 0 Method: send timestamps in send_log
6. Broadcast duration
Target: 182,000 users within 30 min Method: stub, 364 calls x 500 users
Not measured: screen response time and availability (no user-facing
screen; sending is batch). Coverage is recorded for reference only.Definition / Target / Method の3語で揃える
各基準を Definition / Target / Method の3語で揃えるのは、英文の QA 文書でスキャンしやすい定型。"Ranked by severity" と冒頭で並び順の意味を宣言している。"pp"（percentage points）は "%" と区別する書き方（10% ± 0.5% だと「10%の0.5%」とも読める）。
Best — 読み手が意思決定できる ／ 22行（Betterとほぼ同じ・入れ替わり型）
3. 品質目標と合格基準（11/10 判定会はこの表だけで判定する）
判定: 宮田（石井さんの測定結果にもとづく）
選択肢: A 全部出す／B 一斉配信だけ出す（個別配信は延期）／C 延期
基準（定義は付録A） 閾値 測り方 未達なら
① 停止から5分を過ぎた送信 0件 合成試験200回 C
本番: 毎朝9時に突合 全配信を即停止
② 同じ配信IDへの2通目 0件 スタブ10万通・5%再送 C
設計条件: 全送信に再送キー（X-Line-Retry-Key）を付ける（レビューで確認）
③ 対照群への送信 0件 割付表×送信ログ B
割付比率 10±0.5pt
④ 他人向けのカート内容 0件 紐付け64,000件を全件照合 B
⑤ 21:00〜翌8:00の送信 0件 送信ログ（試験＋本番） C
⑥ 一斉配信18.2万人の完了 30分以内 スタブ18.2万件 開始を9時に
「試験で0件」の限界: 10万通で0件でも、本番18.2万通で5.5件までの重複は
否定できない（95%の上限。0件のとき上限≒3÷試験数）。だから②は再送キーで
設計として防ぎ、試験はその確認に使う。①⑤は11/16〜12/16、本番でも毎朝見張る。
カバレッジは門にしない。全体の数字は、①②④を担う3モジュールの穴を
隠してしまうため。代わりに、その3モジュールは分岐を全部通す。Betterから何が変わったか 動いた軸：④次の行動 ／ ①結論の位置 ／ ③事実と解釈 ／ ⑤想定反論
- ④次の行動 → 未達時の扱いを、基準ごとに先に決めた。「未達なら」の列を足し、判定の選択肢を A／B／C の3つに固定した。③対照群や④カート内容が未達でも、一斉配信（対照群もカート内容も使わない）だけなら出せる——これを判定会の前に決めておくことで、11/10に「延期か、強行か」の二択の交渉にならない
- ①結論の位置 → 「この表だけで判定する」を見出しに書いた。判定者（宮田）と判定の根拠（石井さんの測定）も冒頭2行で確定させた。読み手の「後から基準を足されないか」という不安に、見出しで約束している
- ③事実と解釈の分離 → 試験で言えることの上限を書いた。0件のときの95%上限は「約3÷試験数」（統計で rule of three と呼ばれる近似）。10万通で0件なら重複率の上限は0.003%、本番18.2万通に当てはめると約5.5件 〔導出：3÷100,000×182,000＝5.46〕。試験だけでは「本番で0件」を保証できないので、②は設計条件（再送キー）に、①⑤は本番の毎朝の突合に、保証の主役を移した
- ⑤想定反論 → 石井さんの「カバレッジを外すのか」に先回り。外す理由（全体の数字が、重要な3モジュールの穴を隠す）と、代わりに何を求めるか（その3モジュールは分岐を全部通す）を2行で書いた。基準を緩めたのではなく、効くところに集中させたと読める
- 削ったもの：各基準の定義文とテーブル名（付録Aへ移した。判定会では番号と閾値だけで足りる）
- 分量：Better（23行）→ Best（22行）でほぼ同じ。足したもの（判定者・選択肢・未達時の扱い・試験の限界・カバレッジの扱い）と、付録へ移したもの（定義文・テーブル名）が釣り合った「入れ替わり型」（Day008と同型）
なぜ②だけ「設計条件」を基準に入れたのか — 宮田さんが迷った点：
最初は、Betterのように全基準を「試験で0件」で揃える方がきれいだと考えた。しかし試験の件数を増やしても「0件」の信頼度は3÷試験数でしか上がらない。18.2万通の本番で1件も起こさない確信を試験で得るには、本番の数倍の試験が必要になり、3週間では無理がある。LINE Messaging API には、同じ送信を2回実行させないための再送キー（X-Line-Retry-Key、24時間有効。同じキーで再送すると409が返り、2通目は送られない）がある。防ぐ仕組みがある事象は、試験で探すより仕組みを使うことを条件にする方が確実で安い。代償として、再送キーを付けたかどうかは試験では見えないので、コードレビューで確認する手間が増える（佐伯さんのPRすべて）。
反証条件（この形が変わる場合）：
- 友だち数が30万人を超えたら、⑥の30分と「500人×n回」の試験量を見直す
- LINE側の送信の制限（1秒あたりの回数など）が変わったら⑥を再試験する（一斉送信の制限は2025年4月にも変更された）
- 本番の毎朝の突合で①が1件でも出たら、試験の設計が間違っていたとみなし、12/16の監視終了を延ばす
今回はBestまで作るべきか：Best必要。品質保証計画書は、判定会で揉めないために、揉める前に決めておく文書であり、「未達なら」の列がない計画書は、判定の直前にもう一度書き直すことになる。加えて、①停止後の送信はDay009で214件の問い合わせと不信を生んだ事象で、個別配信は個人の購買情報を扱う。量（18.2万人）× 誤ったときの重さ（信頼・個人情報）の両方が大きい（Day009で残した判断基準）。逆に、影響が社内に閉じる小さな改修（管理画面の文言変更など）なら、Betterで十分で、判定の選択肢まで作るのは過剰になる。
Best ／ 23 lines
3. Go/No-Go Criteria (the Nov 10 release review decides on this table alone)
Decision owner: Miyata, based on Ishii's (QA) measurements
Options: A Ship all / B Ship broadcasts only, defer personalized / C Delay
Criterion (defined in App. A) Threshold Method If missed
1 Sends >5 min after opt-out 0 200 synthetic trials C
Prod: daily 9:00 check Kill switch
2 2nd message, same send ID 0 Stub 100k, 5% retries C
Design rule: every send carries X-Line-Retry-Key (checked in code review)
3 Sends to holdout 0 Assignment x send log B
Holdout ratio 10 +/- 0.5 pp
4 Wrong user's cart content 0 All 64,000 links B
5 Sends 21:00-08:00 JST 0 Send log (test+prod) C
6 182k broadcast completes <= 30 min Stub, 182k sends Start at 9:00
Limits of "0 in testing": 0 duplicates in 100k test sends still allows up to
~5.5 in 182k production sends (95% upper bound; rule of three, 3/n).
So #2 is prevented by design, and testing confirms it. #1 and #5 are also
checked every morning in production, Nov 16 - Dec 16.
Coverage is not a gate: an overall number can hide gaps in the three modules
behind #1, #2, #4. Instead, those three modules must hit every branch."Go/No-Go" と "If missed" 列で、判定を先に設計する
"Go/No-Go" と "If missed" 列は、英文のリリース判定文書で「判定の選択肢と未達時の扱いを先に決める」ための定型。"Decision owner" を冒頭に置くのは、受動態で責任者を消したBadの真逆。"still allows up to ~5.5" のように言えることの上限を数字で書くのは、英語圏の技術文書で過大な主張を避ける hedging の強い型（"may" より具体的）。
日英差分ノート
1. 「目指す」は、英語では基準にならない
日本語の品質計画では「バグゼロを目指す」「〜に努める」が目標欄に自然に入り、読み手も「意気込み」として受け取る。英語で "aim for zero bugs" "strive to" と書くと、基準（exit criterion）ではなく願望（aspiration）であることが露骨に見える。英文のQA計画では、"target"（目標：未達でも止めない）と "exit criterion" / "must"（基準：未達なら止める）を語で分ける。日本語でも「目標」と「合格基準」を別の見出しにし、合格基準には「〜を目指す」を使わない、と決めておくとBadの型を避けられる。
2. 主語のない文は、英語では「責任者不在」と読まれる
日本語の「確認する」「決定する」は主語がなくても自然で、チーム内では「たぶん自分かQA」と察して読まれる。英語で同じことを受動態（"It will be confirmed"）にすると、誰もやらない文として読まれる。Best英語版の "Decision owner: Miyata, based on Ishii's (QA) measurements" は日本語版の直訳ではなく、英文で最初に問われる "who owns this?" に先に答える型である。
3. 割合の差は「pt / pp」と書く
「10%±0.5%」は日本語でも曖昧だが、英語圏のレビューでは確実に指摘される（10%の0.5%＝0.05ポイントとも読める）。英語では percentage points（pp）、日本語では ポイント（pt） と書き分ける。
頻出表現
| 日本語 | English | トーンの強さ・使う場面 |
|---|---|---|
| 合格基準 | exit criteria | 中立。「ここを満たせば終わり」。テスト・QA計画の標準語 |
| 目標（未達でも止めない） | target / goal | 弱い。基準と混ぜない |
| 〜でなければならない | must / shall | 強い。基準にだけ使う。shall は契約・規格寄り |
| 判定会 | release review / go/no-go meeting | 中立。go/no-go は「出す・出さない」を決める場だと明確 |
| 判定者 | decision owner / approver | 中立。冒頭に置く |
| 未達の場合 | if missed / if not met | 中立。表の列見出しに使う |
| 0件でも最大〜件は否定できない | still allows up to ~N | 強いhedging。may より具体的で誠実 |
| 参考値として記録する | recorded for reference only | 弱い。門（gate）にしないことを明言する定型 |
差分5軸まとめ
| 軸 | 🔴 Bad | 🟡 Good | 🟢 Better | 🔵 Best |
|---|---|---|---|---|
| ① 結論の位置 | ない（基準は「別途相談」） | 表の後に「満たせばリリース」 | 冒頭で「起きたら困ることから作った」と方針 | 見出しで「この表だけで判定する」、冒頭2行で判定者と選択肢 |
| ② 読み手適合 | 想定していない | 規格の品質特性の順（社内QAのレビュー向け） | このリリースのリスクの重い順。測る本人の作業単位（定義・基準・測り方） | 判定会で使う粒度に圧縮し、定義は付録へ |
| ③ 事実と解釈の分離 | 「十分な」「問題がない」 | 数字はあるが、何を1件と数えるかがない | 各基準に定義と測り方（データの出どころ） | 試験で言える上限（3÷試験数）まで明記 |
| ④ 次の行動 | 「最終確認を行い」 | 判定会でリリースを決定 | 測り方が具体的（試験の件数・注入する障害） | 基準ごとの「未達なら」（A/B/C）と、本番での毎朝の突合 |
| ⑤ 想定反論 | 無視 | 触れない | 消した基準の理由を1行残す | 「カバレッジを外すのか」に理由と代替で先回り |
| 分量（実測） | 13行 | 15行 | 23行 ← 最長 | 22行（入れ替わり型） |
今回の学習の中心は Good → Better。Goodは数字が入っているので、雑には見えない。社内の品質保証グループのレビューも通る。それでも、この機能で起きたら困ること（停止後の送信・重複・対照群・他人のカート）が1つも入っていない。「測れる形をしている」と「測る意味がある」は別であり、後者を作るには、規格の表から始めずに「このリリースで起きたら困ること」から始める必要がある。
Best版・全文
ここまでは「3. 品質目標と合格基準」だけを比べてきた。以下は Best 水準の品質保証計画書の全文（合意したいこと・範囲・前提・基準・活動と日程・役割・リリース後の監視・扱わないこと・前提が変わったら・次の行動・付録A 定義）。
日本語版 全文を見る
LINE配信機能（新配信基盤）品質保証計画書
作成: MOps 宮田 2027年10月12日（火） 版: 1.0（10/14 キックオフで合意予定）
読み手: 佐伯（実装リード）、石井（QA・品質保証グループ兼務）、開発メンバー
━━ 0. この計画で合意したいこと（10/14 10:00 キックオフ） ━━
1. 合格基準は「3. 品質目標と合格基準」の6項目で閉じる。これ以外で延期しない
2. 11/10 16:00 の判定会は、3.の表だけで A／B／C を決める
3. カバレッジは門にしない（理由は3.の末尾）
━━ 1. 目的と範囲 ━━
対象: LINE配信機能の2つ
・一斉配信: LINE公式アカウントの友だち 182,000人〔実測：10/1〕へのセール告知
・個別配信: ID連携済み 64,000人〔実測〕のうち、カート放棄した会員へのリマインド
（効果は対照群10%との差で測る。Day008のマーケティング計画どおり）
最初の本番: 11/26（金）10:00 ブラックフライデーの一斉配信
━━ 2. 前提 ━━
・新配信基盤は10/8に切替済み。配信停止は即時反映（旧基盤の午前3時同期は廃止）
・LINEの送信は Messaging API（個別=push、一斉=multicast 最大500人/リクエスト）
・本番の友だちに試験送信はできない。18.2万人規模の試験はAPIスタブ（LINEの代わりに
送信を記録する仕組み）で行い、実際のLINEへの送信は社員200人の検証用アカウントで行う
━━ 3. 品質目標と合格基準（11/10 判定会はこの表だけで判定する） ━━
判定: 宮田（石井さんの測定結果にもとづく）
選択肢: A 全部出す／B 一斉配信だけ出す（個別配信は延期）／C 延期
基準（定義は付録A） 閾値 測り方 未達なら
① 停止から5分を過ぎた送信 0件 合成試験200回 C
本番: 毎朝9時に突合 全配信を即停止
② 同じ配信IDへの2通目 0件 スタブ10万通・5%再送 C
設計条件: 全送信に再送キー（X-Line-Retry-Key）を付ける（レビューで確認）
③ 対照群への送信 0件 割付表×送信ログ B
割付比率 10±0.5pt
④ 他人向けのカート内容 0件 紐付け64,000件を全件照合 B
⑤ 21:00〜翌8:00の送信 0件 送信ログ（試験＋本番） C
⑥ 一斉配信18.2万人の完了 30分以内 スタブ18.2万件 開始を9時に
「試験で0件」の限界: 10万通で0件でも、本番18.2万通で5.5件までの重複は
否定できない（95%の上限。0件のとき上限≒3÷試験数）。だから②は再送キーで
設計として防ぎ、試験はその確認に使う。①⑤は11/16〜12/16、本番でも毎朝見張る。
カバレッジは門にしない。全体の数字は、①②④を担う3モジュールの穴を
隠してしまうため。代わりに、その3モジュールは分岐を全部通す。
基準にしないもの（理由）:
・画面の応答時間／稼働率 … 会員が操作する画面がなく、送信はバッチのため
・脆弱性診断 … 新基盤で10/1に実施済み。今回は外部への新しい入口を作らない
・ブロック率 … 合否ではなく監視（6.）で見る。リリース前には測れない
━━ 4. 品質保証の活動と日程 ━━
10/14（木）キックオフ・本計画の合意 全員
10/20（水）設計レビュー（①②④の3モジュール） 佐伯→石井
各PR コードレビューで再送キーの有無を確認 石井
11/1〜11/5 結合試験（①③④⑤、検証用アカウント200人） 石井
11/8〜11/9 本番相当試験（②⑥、APIスタブ） 佐伯・石井
11/10（水）16:00 判定会 宮田（判定）
11/16（火）10:00 リリース
11/26（金）10:00 最初の一斉配信（ブラックフライデー）
11/16〜12/16 本番での監視（6.）
━━ 5. 役割 ━━
宮田 … 判定。未達時のA/B/Cの決定。高梨部長への報告
石井 … 測定と報告。判定会の前日（11/9）17:00までに3.の表を埋めて共有
佐伯 … 実装。合成試験とAPIスタブの用意。本番の突合クエリの作成
━━ 6. リリース後の監視（11/16〜12/16） ━━
毎朝9:00、前日分を突合（佐伯が自動化、結果は石井が確認）
・①停止から5分を過ぎた送信 … 1件でも出たら全配信を即停止し、宮田へ即時連絡
・⑤21:00〜翌8:00の送信 … 1件でも出たら同上
・③割付比率 … 9.5〜10.5%を外れたら個別配信を止め、宮田へ当日連絡
・ブロック率（参考）… 一斉配信の翌日に記録。判断基準は12/16の振り返りで決める
━━ 7. この計画で扱わないこと ━━
・テストケースの設計（テスト計画書で石井が作成）
・LINEのメッセージが特定電子メール法の対象になるかの判断（法務に確認中）。
ただし、対象かどうかにかかわらず①は0件を基準にする（Day009の教訓）
・ID連携の同意の取り方（個人情報の扱い。法務と会員サービス部の範囲）
━━ 8. 前提が変わったら ━━
・友だちが30万人を超えたら、⑥の30分と試験量を見直す
・LINE側の送信の制限が変わったら⑥を再試験する（一斉送信の制限は2025年4月にも変更）
・本番の突合で①が1件でも出たら、試験の設計の誤りとみなし、監視期間を延ばす
━━ 9. 次の行動 ━━
何を 誰が いつまでに
本計画への意見 全員 10/13（水）18:00
本計画の合意 全員 10/14（木）10:00
付録A（定義）の確定 石井 10/15（金）
合成試験・APIスタブ・突合クエリの用意 佐伯 10/29（金）
3.の表を埋めて共有 石井 11/9（火）17:00
━━ 付録A 基準の定義 ━━
① 会員がLINE配信を停止（またはID連携を解除）した時刻から5分を過ぎて、
その会員に送った件数。optout_log の時刻と send_log の送信時刻で数える
② 同じ会員・同じ配信IDへの2通目以降の件数。send_log で数える
③ holdout_assign で「送らない」とした会員への送信件数と、割付比率
④ 会員IDとLINE userId の紐付けが、会員マスタと一致しない件数
⑤ 送信時刻が21:00:00〜翌7:59:59（日本時間）の件数
⑥ 一斉配信の最初のリクエストから、最後のリクエストの応答までの時間English 全文を見る
QA Plan: LINE Messaging on the New Delivery Platform
Author: Miyata (MOps) | Oct 12, 2027 | v1.0 (to be agreed at kickoff, Oct 14)
Readers: Saeki (dev lead), Ishii (QA, on loan from the QA group), dev team
0. WHAT WE NEED TO AGREE ON (Kickoff, Oct 14, 10:00)
1. The six criteria in Section 3 are the complete exit criteria.
We will not delay the release for anything outside them.
2. The Nov 10 release review decides A/B/C on the Section 3 table alone.
3. Code coverage is not a gate (reason at the end of Section 3).
1. SCOPE
- Broadcasts: sale notices to 182,000 LINE friends [actual, Oct 1]
- Personalized: cart-abandonment reminders to 64,000 linked members [actual];
impact measured against a 10% holdout (per the FY2027 H1 marketing plan)
First production use: Black Friday broadcast, Nov 26, 10:00 JST
2. ASSUMPTIONS
- The new platform went live Oct 8. Opt-outs now take effect immediately.
- Sending uses the Messaging API (push for personalized; multicast,
max 500 users per request, for broadcasts).
- We cannot test-send to real friends. Scale tests use an API stub;
real LINE delivery is tested with a 200-employee test account.
3. GO/NO-GO CRITERIA (the Nov 10 release review decides on this table alone)
Decision owner: Miyata, based on Ishii's (QA) measurements
Options: A Ship all / B Ship broadcasts only, defer personalized / C Delay
Criterion (defined in App. A) Threshold Method If missed
1 Sends >5 min after opt-out 0 200 synthetic trials C
Prod: daily 9:00 check Kill switch
2 2nd message, same send ID 0 Stub 100k, 5% retries C
Design rule: every send carries X-Line-Retry-Key (checked in code review)
3 Sends to holdout 0 Assignment x send log B
Holdout ratio 10 +/- 0.5 pp
4 Wrong user's cart content 0 All 64,000 links B
5 Sends 21:00-08:00 JST 0 Send log (test+prod) C
6 182k broadcast completes <= 30 min Stub, 182k sends Start at 9:00
Limits of "0 in testing": 0 duplicates in 100k test sends still allows up to
~5.5 in 182k production sends (95% upper bound; rule of three, 3/n).
So #2 is prevented by design, and testing confirms it. #1 and #5 are also
checked every morning in production, Nov 16 - Dec 16.
Coverage is not a gate: an overall number can hide gaps in the three modules
behind #1, #2, #4. Instead, those three modules must hit every branch.
Not criteria (and why):
- Screen response time / availability: no user-facing screen; batch sending
- Vulnerability scan: done on the new platform Oct 1; no new external entry point
- Block rate: monitored after release (Section 6); cannot be measured before
4. ACTIVITIES AND SCHEDULE
Oct 14 Kickoff; agree on this plan All
Oct 20 Design review of the modules behind #1, #2, #4 Saeki -> Ishii
Every PR Code review checks for the retry key Ishii
Nov 1-5 Integration tests (#1, #3, #4, #5; 200-user account) Ishii
Nov 8-9 Scale tests (#2, #6; API stub) Saeki, Ishii
Nov 10 16:00 release review Miyata decides
Nov 16 10:00 release
Nov 26 10:00 first broadcast (Black Friday)
Nov 16-Dec 16 production monitoring (Section 6)
5. ROLES
Miyata Decides A/B/C; reports to Takanashi (department head)
Ishii Measures and reports; shares the completed Section 3 table
by Nov 9, 17:00
Saeki Builds; prepares synthetic tests, the API stub, and the daily query
6. PRODUCTION MONITORING (Nov 16 - Dec 16)
Every day at 9:00, check the previous day (automated by Saeki; Ishii reviews)
- #1 or #5: even one case -> stop all sending, notify Miyata immediately
- #3 ratio outside 9.5-10.5% -> stop personalized sends; notify Miyata same day
- Block rate (reference): recorded the day after each broadcast; thresholds
to be set at the Dec 16 retrospective
7. OUT OF SCOPE
- Test case design (Ishii's test plan)
- Whether LINE messages fall under Japan's Act on Specified Electronic Mail
(with Legal). Regardless of the answer, #1 stays at 0.
- How consent for account linking is obtained (Legal and Member Services)
8. WHAT WOULD CHANGE THIS PLAN
- Friends exceed 300,000 -> revisit #6 and the test volume
- LINE changes its sending rate limits -> re-run #6 (the multicast limit
last changed in April 2025)
- Any #1 case in production -> treat the test design as wrong; extend monitoring
9. NEXT STEPS
What Owner By
Comments on this plan All Oct 13, 18:00
Agreement All Oct 14, 10:00
Finalize Appendix A (definitions) Ishii Oct 15
Synthetic tests, API stub, daily query ready Saeki Oct 29
Completed Section 3 table shared Ishii Nov 9, 17:00
APPENDIX A. DEFINITIONS
1 Sends to a member more than 5 minutes after they opted out of LINE or
unlinked their account (optout_log time vs. send_log time)
2 Second and later messages to the same member for the same send ID (send_log)
3 Sends to members marked "do not send" in holdout_assign; and the ratio
4 Member-ID-to-LINE-userId links that do not match the member master
5 Sends timestamped 21:00:00-07:59:59 JST
6 Time from the first broadcast request to the response to the last one完成の定義チェックリスト
品質保証計画書を共有する前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
進捗 0 / 8
今日の演習
15分版 — まずこれだけでもやる
Good版の表から「信頼性：稼働率99.9%以上」の1行だけを選び、測定可能の5点に分解して書き直す。
- まず「この機能で、信頼性が低いと何が起きるか」を1文で書く（例：予約した一斉配信が送られない／途中で止まる）
- その1文から、定義・測り方・閾値・判定する人と時期・満たさないときの扱いの5点を埋める
- 「稼働率」という語を使わずに書く
書き終えたら、Better・Best の⑥（一斉配信の完了時間）と見比べる。「99.9%」という数字が、何の・どの期間の・どこで測った値なのかを自分が説明できなかったことに気づけば、今日の目的は達成。
60分版
同じ計画を、読み手を「判定者の高梨部長（非エンジニア。11/10の判定会の後、本部長に報告する立場）」に変えて、リリース判定基準の1枚に書き直す。
守る条件：
- 20行以内
- 冒頭で「11/10に部長に決めてほしいこと」と判定の選択肢（A/B/C）を示す
- 6つの基準を、技術用語を使わずに「起きたら会員・会社に何が起きるか」の言葉で書く（例：②重複送信→「同じセールのお知らせが2通届き、友だち解除される」）
- 「B（一斉配信だけ出す）」を選んだ場合に失うもの（ブラックフライデーでカート放棄リマインドが使えない）を数字で書く
取り組む前のヒント
考える順序
- 開発・QAと高梨部長の違いを1文で書き出す。開発・QAは「何を数えれば終わりか」、部長は「どの選択肢を選ぶと、何を得て何を失うか」
- 6つの基準のうち、部長が判定に使うのはどれかを選ぶ。全部載せる必要はない。「未達なら」の列が C（延期）の基準と B の基準で分けると、部長にとっての意味が見える
- Bを選んだときに失う売上の見積もりを、Day008の数字（カート放棄 月41,000件）から置いてみる。置いた値には〔仮定〕と書く
陥りやすい罠
- 開発者向けのBestから、テーブル名と定義を消しただけで出す。部長向けでは並び順が「重さ」から「判定への影響」に変わる
- 「試験で0件の限界（3÷試験数）」を部長向けにも説明しようとする。部長に要るのは計算ではなく「だから仕組みで防いでいる、本番でも毎朝見ている」という結論の1行
チェックすべき観点
書き上げたら「部長が判定会の最初の3分でこの1枚を読み、A/B/Cのどれを選ぶかと、その理由を本部長に1文で言えるか」を判定する。これは監査報告書（品質・監査#2）やテスト報告書（IT-テスト・リリース#3）の勝負どころ（判断の材料になっているか）と同じ力である。
実務での使いどころ
品質保証計画書は、開発に入る前に「合格の基準」を合意するための文書。前後の文書との関係を押さえると、何をどこまで書くべきかの判断がつく。
| 関係 | 文書 | この計画書との関係 |
|---|---|---|
| 前 | マーケティング計画書（Day008）・FAQ（Day009） | 対照群10%（③）はDay008で決めた測り方、停止後の送信（①）はDay009の教訓から来ている。品質基準は、前の文書で決めたことと起きたことから作る |
| 下 | テスト計画書（IT-テスト・リリース#1） | この計画書が「何を満たせば合格か」、テスト計画書が「どう試験してそれを確かめるか」。テストケースの設計はこちらに書かない |
| 横 | 非機能要件定義書（IT-要求・設計#3） | 性能・可用性の数字は本来こちらで決まる。今回「稼働率」を基準にしなかったのは、要件定義で数字が決まっていなかったから、でもある |
| 後 | テスト報告書（#3）・リリース計画書（#5）（IT-テスト・リリース） | 11/9に石井さんが埋める「3.の表」がテスト報告書の核になる。「未達なら」の列はリリース計画書の切り戻し判断に繋がる |
| 後 | 是正措置報告書（品質・監査#3） | 本番の監視で①が出た場合、真因分析と再発防止はここで書く |
現場で一番効くのは、テンプレートの品質特性を埋める前に「このリリースで起きたら困ること」を5〜6個書き出すこと。テンプレートは漏れを防ぐ道具としては役に立つので、書き出した後に照らし合わせて「漏れていないか」を確かめる順で使う。順番を逆にすると、Goodの形（全部埋まっているが、どれも効かない）になる。
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
迷った他案と採らなかった理由
- 題材を「10/8の配信基盤切替そのもの」の品質保証計画にする案 — 時系列（Day009は切替直前の9/1）上、切替の品質保証計画はもっと前に書かれているはずで不自然。切替はテスト計画書・リリース計画書・データ移行計画書（IT-テスト・リリース）の題材とも重なるため、次の新機能（LINE配信）にした
- Bestを ISO/IEC 25010 の全9特性を網羅した表にする案 — 網羅は Good の特徴であり、3週間で作る開発者の作業を増やすだけで判定には効かない。Bestでは6項目に絞り、外したものを「基準にしないもの（理由）」で扱った。IEEE 730-2014 が「品質保証計画はその製品が持つリスクに見合ったものにする」を基本にしている点も根拠にした
- 重複送信を確率で基準にする案（「重複率0.001%未満」） — 測定可能に見えるが、3週間の試験では0件でも0.003%までしか言えず、満たしたことを証明できない。証明できない基準は、書いた時点で判定会の揉めごとになるため、設計条件（再送キー）＋試験での確認に切り替えた
- カバレッジ80%を基準に残す案 — 品質保証グループの標準であり、石井さんの立場ではこちらが自然。残すと「全体80%を満たすために、重要でない所のテストを足す」動きが起きやすいため、重要な3モジュールの分岐の全通過に置き換えた。代償として、社内標準との差を石井さんがグループに説明する手間が生じる（Bestで理由を2行書いたのはそのため）
- Bestを Better より短くする案（分量逆転を狙う） — 判定の選択肢と未達時の扱いはこの文書種別の Best の本体で削れない。狙って短くするのはやめ、実測で Better（23行）とほぼ同じ 22行（入れ替わり型）になった
扱わなかった範囲
- テストケースの設計、テスト技法の選び方（IT-テスト・リリース#1・#2で扱う）
- LINEのメッセージが特定電子メール法の対象になるかの判断、ID連携の同意の取り方。このスキルは法的助言ではなく、読み手に伝わる書き方の練習である。本文では「法務に確認中」とし、結論にかかわらず①を0件にする判断だけを書いた
- LINE公式アカウントの料金プランの具体的な金額。重複送信が通数を消費することだけを書き、単価は置いていない
- 抜き取り検査の統計（JIS Z 9015 等）や、ソフトウェアの信頼度成長モデル。今回は「0件のときの上限＝約3÷試験数」の1つだけに絞った
- 石井さんが品質保証グループの標準から外れることを、グループにどう説明するか（組織内の合意形成）
数字と概念の出所
- 本文の数字はすべて架空の設定。〔実測〕はシナリオ内の実績値、〔導出〕は計算値、〔仮定〕は置いた値。導出値（1,370件/日≒41,000÷30、5.46件＝3÷100,000×182,000、0.003%＝3÷100,000、364回＝182,000÷500）と2027年の曜日（10/12火・10/14木・11/10水・11/16火・11/26金）は作成時に計算して確認した
- 分量（行数）は、各コードブロックの行数を作成後にスクリプトで数えた実測値
- LINE Messaging API の再送キー（X-Line-Retry-Key）：対象は push・multicast・narrowcast・broadcast、最初のリクエストから24時間有効、受付済みのリクエストを同じキーで再送すると 409 Conflict：LINE Developers「Retrying a failed API request」（2026-09-25にページを取得して確認）
- multicast の宛先上限（1リクエスト500人）と 2025年4月23日の multicast のレート制限変更：LINE Developers ニュース（2026-09-25に検索結果の要約で確認。変更後の値は未読）
- ISO/IEC 25010:2023 の9つの品質特性（使用性・移植性が相互作用能力・柔軟性に置き換わり、安全性が追加）：ISO、arc42 Quality Model（2026-09-25に検索結果の要約で確認。規格本文は有償のため未読）
- IEEE 730-2014 の「品質保証計画は製品のリスクに見合ったものにする」原則：ASQ の解説記事（2026-09-25に検索結果の要約で確認。規格本文は未読）
- 0件のときの95%上限≒3÷n（rule of three）：Hanley JA, Lippman-Hand A. "If nothing goes wrong, is everything all right?" JAMA 1983;249(13):1743-1745。書誌情報のみ。式（1−p)n＝0.05 から p≒−ln(0.05)/n≒3.0/n は作成時に計算して確認した
何が起きているか