受入テストの手戻りをなくすための品質ゲート設計
受入テストで手戻りが多発する。業務部門から「これでは使えない」と言われ、稼働直前に作り直す。多くの現場で起きることです。
この事例は、前回のプロジェクトで受入テストの手戻りに苦しんだ会社が、次の案件で品質ゲートを設計し、受入テストの不具合を4.90件/KStepから0.20件/KStepに下げた記録です。会社名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。
■ 会社と案件の前提
項目 | 内容 |
|---|---|
会社名（架空） | ノヴァモバイル株式会社 |
業種 | 通信（MVNO・法人向け回線サービス） |
年商 | 88億円 |
従業員数 | 320名 |
契約回線数 | 62万回線 |
法人顧客 | 4,800社 |
案件名 | 料金計算・請求システムの刷新 |
期間 | 2024年9月2日 〜 2025年11月4日 本番稼働（14か月） |
承認予算枠 | 1億9,000万円 |
当初計画額 | 204人月 × 88万円 ＝ 1億7,952万円 |
新規開発規模 | 96KStep |
料金プラン | 24種（個人8・法人16） |
■ 前回プロジェクトで何が起きたか
この会社は2022年に顧客管理システムを刷新しています。そのときの結果が、今回の設計の出発点になりました。
項目 | 前回（2022年・顧客管理システム） |
|---|---|
新規開発規模 | 84KStep |
受入テストの計画期間 | 6週間 |
受入テストの実績期間 | 14週間 |
受入テストの検出件数 | 412件（4.90件/KStep） |
うち「仕様の認識違い」 | 218件（53%） |
本番稼働 | 2か月遅れ |
受入テストで出た412件のうち、半分以上が「仕様の認識違い」でした。バグではありません。「そういう動きになると思っていなかった」というものです。
これが厄介なのは、直すのに設計からやり直しになることです。しかも受入テストの段階では、業務部門の人が本業と並行してテストしています。手戻りが出るたびに、彼らの時間が奪われます。前回は14週間、業務部門を拘束しました。
振り返りで出た結論はこうでした。「受入テストで初めて仕様を確かめている。それでは遅い」
■ 品質ゲートとは何か
そこで今回の案件では、工程の切れ目に品質ゲートを置きました。ゲートとは、次の工程へ進むための通過条件のことです。
考え方は単純です。不具合は、下流で見つかるほど直すのが高くつきます。だから各工程の出口で「ここで止める」条件を決めておき、満たさなければ次に進ませない。それだけです。
ただし、実際にやろうとすると必ずぶつかる問題があります。「条件を満たしているかどうか、誰がどう判断するのか」です。「品質が十分であること」と書いても、その場の空気で通ってしまいます。
そこでこの案件では、すべての通過条件を数字か、○×で答えられる形で書きました。
■ 5つのゲートと通過条件
ゲート | 時期 | 通過条件 |
|---|---|---|
G0 | 2024/11/29 | ① 業務シナリオ186本すべてに、受入テストのテストケース番号が紐づいている |
G1 | 2025/2/28 | ① 料金計算の計算例が、プラン24種 × 3パターン ＝ 72件すべて手計算で検算済み |
G2 | 2025/6/20 | ① 単体テストケース密度が全サブシステムで20ケース/KStep以上 |
G3 | 2025/8/22 | ① 不具合密度が1.00件/KStep以上（少なすぎないこと） |
G4 | 2025/10/3 | ① 本番同等データ（62万回線・1か月分）での請求計算が、既存システムの結果と全件一致 |
いくつか、意図を補足します。
G0の①「シナリオに受入テストのケース番号が紐づいている」が、この設計の中心です。要件定義の時点で「この要件は、受入テストのどのケースで確かめるのか」を決めておく。受入テストの中身を、要件定義の段階で作ってしまうということです。前回の失敗が「受入テストで初めて仕様を確かめた」ことだったので、そこを逆にしました。
G1の①「計算例72件を手計算で検算」は、料金計算という案件の性質に合わせた条件です。プラン24種それぞれについて、通常利用・上限超過・日割りの3パターンを手計算し、設計書の記述と一致することを確かめます。プログラムを書く前に、紙の上で確かめておく作業です。
G3の①「不具合密度が1.00件/KStep以上」は、少なすぎたら疑うための条件です。結合テストで不具合が出ないのは、品質が良いからではなく、テストが甘いからであることが多いためです。
■ 実際に4回、差し戻しが起きた
ゲートを置けば、当然止まります。今回の実績です。
ゲート | 1回目の判定 | 満たせなかった条件 | 差し戻しによる遅れ |
|---|---|---|---|
G0 | 差し戻し（1回） | ②項目定義の「未定」が14件残っていた | 5営業日 |
G1 | 差し戻し（2回） | ①計算例72件のうち8件が不一致 | 10営業日 |
G2 | 通過 | ― | 0日 |
G3 | 差し戻し（1回） | ②直近2週の発生件数がピーク週の34%（基準20%以下） | 5営業日 |
G4 | 通過 | ― | 0日 |
― | 合計4回 | ― | 20営業日 |
合計20営業日、約1か月の遅れです。それでも稼働日は動いていません。各ゲートの後ろに、あらかじめ5営業日ずつのバッファを置いてあったからです。4ゲート分で20営業日。ちょうど使い切りました。
ここが、ゲート設計でいちばん大事なところです。ゲートを置いたら、止まることを前提に計画する。止まる余地のない計画にゲートを置くと、結局「今回は特例で通す」が起きます。そうなればゲートは無いのと同じです。
特にG1の差し戻し2回は、当時かなり厳しい判断でした。計算例8件の不一致は、設計書の日割り計算の記述が月末締めと締め日変更の両方に対応していなかったことが原因です。この8件を放置していれば、受入テストで数十件の不具合になっていたはずです。
■ 結果：不具合を見つける場所が前に動いた
工程 | 前回（84KStep） | 今回（96KStep） |
|---|---|---|
単体テスト | 680件（8.10件/KStep） | 1,340件（13.96件/KStep） |
結合テスト | 520件（6.19件/KStep） | 610件（6.35件/KStep） |
総合テスト | 245件（2.92件/KStep） | 92件（0.96件/KStep） |
受入テスト | 412件（4.90件/KStep） | 19件（0.20件/KStep） |
稼働後1か月 | 38件（0.45件/KStep） | 3件（0.03件/KStep） |
合計 | 1,895件 | 2,064件 |
注目していただきたいのは、合計件数がほとんど変わっていないことです。前回1,895件、今回2,064件。規模が84KStepから96KStepに増えているので、密度で見ればむしろ同じくらいです。
つまり、作ったものの品質が劇的に良くなったわけではありません。変わったのは、同じ数の不具合をどこで見つけたかです。単体テストで捕まえた割合が35.9%から64.9%に増え、受入テストに届いたものが21.7%から0.9%に減りました。
受入テストの19件の内訳も見ておきます。
種類 | 前回（412件） | 今回（19件） |
|---|---|---|
仕様の認識違い | 218件（53%） | 2件（11%） |
画面表示・操作性 | 96件（23%） | 11件（58%） |
計算誤り | 64件（16%） | 0件（0%） |
性能・応答 | 34件（8%） | 6件（32%） |
計算誤りが0件になったのは、G1とG2で計算例72件を2回（手計算とプログラム）検算しているためです。受入テストに残ったのは、実際に触ってみないと分からないもの（表示の見やすさ、応答の体感）だけになりました。これが本来の受入テストの姿です。
■ 結果（QCD）
観点 | 合格ライン | 実績 | 判定 |
|---|---|---|---|
Q（品質） | 受入テスト 0.25件/KStep 以下 | 0.20件/KStep（19件 ÷ 96KStep） | 達成 |
C（コスト） | 承認枠 1億9,000万円 以内 | 1億8,304万円（208人月・枠の96.3%） | 達成 |
D（納期） | 2025年11月4日 稼働 | 2025年11月4日 稼働 | 達成 |
コストは計画204人月に対して実績208人月、4人月（352万円）の超過です。ゲートの運営と、差し戻しによるやり直しに使った分です。
前回は受入テストが6週間の計画に対して14週間かかり、業務部門12名を8週間よけいに拘束しました。委託費には出ませんが、社内の人件費としては今回の4人月を大きく上回る損失でした。
受入テストは計画3週間（2025/10/6〜10/24）で、計画どおり完了しています。
■ 管理帳票の実物
課題管理表
ID | 内容 | 影響 | 期限 | 状態 |
|---|---|---|---|---|
I-006 | G0の項目定義で「未定」が14件残り、ゲートを通過できない | 基本設計着手 ＋5日 | 2024/12/6 | 完了 |
I-018 | 日割り計算の設計記述が、締め日変更のケースに対応していない（計算例8件が不一致） | 基本設計 ＋10日 | 2025/3/14 | 完了 |
I-019 | 受入テストケース1,240本の期待値記入が62%にとどまる | G1通過の阻害 | 2025/3/14 | 完了 |
I-031 | 結合テストの収束が基準に届かない（直近2週がピーク週の34%） | 総合テスト着手 ＋5日 | 2025/8/29 | 完了 |
I-036 | 受入テストの実施要員12名のうち3名が、月末請求業務と重複する | 受入テスト ＋3日 | 2025/9/26 | 完了 |
リスク管理表
ID | リスク | 発生度 | 影響 | 監視する数字 | 対応 |
|---|---|---|---|---|---|
R-01 | ゲートが「特例」で通されてしまう | 高 | 前回と同じ手戻りの再発 | 特例通過の件数（目標0件） | 通過判定を部長級の会議体で行い、判定結果を議事録に残す |
R-05 | 差し戻しの遅れがバッファを超える | 中 | 稼働延期 | 累計の差し戻し日数（上限20営業日） | 15営業日を超えた時点で、受入テストの範囲を3本に絞る準備に入る |
R-11 | 料金プラン24種の仕様が期中に変わる | 中 | 計算例72件の作り直し | 商品企画部の新プラン検討状況 | 期中の新プランは稼働後の第2期で対応することを、着手前に合意する |
R-15 | 62万回線の請求計算が、総合テストの時間内に終わらない | 中 | G4通過の遅れ | 10万回線での試行時間 | 10万回線で先に計測し、必要なら計算処理を分割実行に変更する |
R-01が、この案件でいちばん重要なリスクです。ゲートを作ることより、ゲートを守ることのほうが難しいからです。監視する数字を「特例通過0件」と置き、通過判定を部長級の会議体に上げました。担当者どうしでは、どうしても「今回だけは」が出ます。
TODO
内容 | 担当 | 期限 | 状態 |
|---|---|---|---|
業務シナリオ186本と受入テストケースの紐づけ表を作成 | 業務リーダー | 2024/11/22 | 完了 |
料金計算の計算例72件を手計算で作成 | 料金企画担当 | 2025/2/14 | 完了 |
受入テストケース1,240本の期待値を記入 | 業務部門12名 | 2025/8/15 | 完了 |
10万回線での請求計算の所要時間を計測 | インフラ担当 | 2025/7/18 | 完了 |
受入テスト実施要員12名の日程を確保 | PM | 2025/9/12 | 完了 |
■ 振り返りと、自分の現場で使うなら
まず反省点です。
ゲートの条件を作るのに、想定より時間がかかった：着手前の2週間で作るつもりが、4週間かかった。特に「数字で書く」のが難しい
G1の差し戻し2回で、現場の士気が落ちた：2回目のとき「何をやっても通らない」という声が出た。判定の場で、何を直せば通るのかを具体的に示すべきだった
ゲートを5つ置いたが、G2とG4は結果的に1回で通った：条件が緩かった可能性がある。次回はG2の密度基準を上げることを検討している
次に効いた点です。
受入テストの中身を、要件定義の段階で作った：G0の条件①。これが最大の効き目だった
すべての条件を数字か○×で書いた：判定の場で議論にならず、5分で終わる
ゲートごとに5営業日のバッファを置いた：止まることを織り込んであったので、止めても納期が揺れない
「少なすぎたら疑う」条件を入れた：G3の①。テストが甘いことを見逃さない
最後に、明日から使える形にまとめます。すべての工程にゲートを置くのが大変なら、まず1つだけ置いてみてください。おすすめは要件定義の出口です。条件はこの3つで十分です。
要件の1つひとつに、受入テストのケース番号が紐づいているか：紐づかない要件は、確かめようのない要件です
項目定義に「未定」「別途決定」が0件か：未定のまま設計に進んだものは、必ず後で手戻りになります
業務部門の責任者が、内容を読んで署名したか：読まれていない要件定義書は、無いのと同じです
そして忘れてはいけないのが、ゲートの後ろにバッファを置くことです。止まる余地のない計画にゲートを置くと、「今回だけは特例で」が必ず起きます。ゲートは、止まれる計画とセットで初めて機能します。