結合テストでバグが収束しないプロジェクトを立て直した事例

結合テストを始めて8週間、不具合が毎週55〜63件のペースで出続け、未解決が214件まで積み上がった。この事例は、そこから立て直した記録です。

やったことは、結合テストをいったん止めて、455件の不具合を原因別に分けることでした。分けてみると、結合テストで出るべき「モジュール間の連携の不具合」は4%しかありませんでした。会社名・数字はすべて架空ですが、記事の中で辻褄が合うように作っています。

■ 会社と案件の前提

医療機器の保守は、法令で点検の記録を残す義務があります。点検予定を組み、実施記録を残し、部品を交換したらその履歴を製品ごとに追えるようにする。この「追えること」が、この案件でいちばん大事な要件でした。

■ 何を「成功」とみなしたか

この案件では、Qが最優先でした。だからこそ、後で「結合テストを止める」という判断ができています。何を優先するかを先に決めておくと、苦しいときの判断が速くなります。

■ 2025年1月〜2月：不具合が減らない

結合テストは2025年1月6日に始まりました。計画は8週間、2月28日完了です。

ところが、週ごとの発生件数が減りません。ふつう、結合テストの不具合は前半に山を作り、直していくうちに減っていきます。このプロジェクトでは、8週間ずっと横ばいでした。

2月末時点で、テストケースの消化率は78%、未解決が214件。ここでよく出る意見は「人を増やして直す速度を上げよう」です。実際、ベンダーからは修正要員2名の追加が提案されました。

しかし、その前に確かめるべきことがあります。「なぜ減らないのか」です。直す速度が足りないのか、それとも出続ける理由が別にあるのか。前者なら人を増やせば解決しますが、後者なら人を増やしても同じことが続きます。

■ 455件を原因別に分けた

3月の第1週を使って、それまでに出た455件を1件ずつ見直し、「本来ならどの工程で見つかるべき不具合だったか」で分類しました。

この表を見た瞬間に、方針が決まりました。結合テストで結合の不具合が4%しか出ていないということは、このテストは結合テストとして機能していないということです。単体テストの代わりをさせられている状態でした。

人を増やして直す速度を上げても、196件の後ろに控えている単体レベルの不具合が次々に出てくるだけです。直す速度の問題ではなく、入ってくる量の問題でした。

さらに、サブシステム別に見ると偏りがありました。

部品在庫だけが、他の3倍近い密度で不具合を出しています。理由もはっきりしました。部品在庫だけ、別のチームが担当していたのです。9月の増員時に加わった要員で構成され、そのチームには単体テストのケース作成基準が共有されていませんでした。他が18〜22ケース/KStepなのに対し、部品在庫は6ケース/KStepしか作っていません。

悪意でも手抜きでもなく、単に伝わっていなかっただけです。こういうことは、増員のタイミングでよく起きます。

■ 打った手：結合テストをいったん止めた

3月7日で結合テストを止め、次の4つを4週間で行いました。

1. 部品在庫サブシステムの単体テストをやり直す（3/10〜4/4）：他と同じ20ケース/KStepの水準まで引き上げる。28KStep × 20 ＝ 560ケースに対し、既存が168ケースなので392ケースを追加作成。この4週間で187件を検出し、結合テストに出る前に潰した

2. 設計書のあいまい箇所を確定させる：118件の原因になった記述を洗い出し、仕様確認票にまとめて業務部門と64項目を確定した

3. テストデータを本番同等データに差し替える：82件の原因だった、件数不足・パターン不足のテストデータを入れ替えた

4. 移行リハーサルを前倒しで実施する：テストが止まっている間、インフラ担当と業務部門の手が空くため、6月予定のリハーサルを3月に実施した

4つめが、この事例の工夫です。止めるという判断は、止めている間に何をするかとセットで出す。「止めます」だけでは、関係者は不安になります。「止めて、その間にこれとこれをやります」なら、話が通ります。

■ 4週間止めたのに、稼働日が動かなかった理由

総合テストと受入テストを2週間だけ重ねました。当初は順番に行う計画でしたが、総合テストの後半で扱う範囲と、受入テストの前半で扱う範囲が重なっていたためです。合計13週の予定を7週にしています。

注意していただきたいのは、これは「急いで雑にやる」短縮ではない点です。テストケースの本数は1本も減らしていません。前倒しと並行で、時期を動かしただけです。もし本数を削っていたら、Qの合格ラインを守れなかったはずです。

■ 再開後：不具合は収束した

再開第1週の発生が71件と多いことに、驚かれるかもしれません。これは正常な姿です。単体テストをやり直しても、モジュール同士をつないだときに初めて分かる問題は残ります。それがこの71件でした。

大事なのは、そこから48件、29件、17件、11件ときれいに下がっていることです。これが「収束している」状態です。前半8週間は、この下がり方がまったく出ていませんでした。

解決件数が発生件数を大きく上回っているのは、停止前に溜まっていた214件を並行して処理していたためです。7週目に未解決が0件になり、総合テストへ進みました。

■ 結果（QCD）

コストは計画236人月に対して実績248人月、12人月（1,032万円）の超過です。単体テストのやり直しに使った分です。この12人月を惜しんでいたら、総合テストで同じことが起き、そちらのほうが高くついたはずです。

総合テストの不具合密度0.61は、社内基準0.80以下に収まりました。結合テストがきちんと効いた証拠です。1回目の結合テストのまま進んでいたら、この数字は2倍以上になっていたと見ています。

■ 管理帳票の実物

課題管理表

リスク管理表

R-08に注目してください。「再開第3週の発生件数が40件を超えたら再判断」と、判定の時期と数字が入っています。実績は29件でしたので、この線は使わずに済みました。打った手が効かなかったときの次の手を、先に書いておくと、現場が落ち着きます。

TODO

■ 振り返りと、自分の現場で使うなら

まず反省点です。

• 増員時に、単体テストの基準を渡していなかった：9月の増員から1月の結合テストまで4か月あったのに、誰も気づけなかった

• 単体テストの完了を「終わった」という報告だけで確認していた：ケース数や密度という数字で確認していれば、11月の時点で分かった

• 横ばいの3週目・4週目で動けなかった：8週間見てから動いています。あと3週間早く動けていれば、やり直しに使った4週間はもっと楽でした

次に効いた点です。

• 「なぜ減らないのか」を先に調べた：人を増やす前に原因を分けたことで、打つ手が変わった

• 不具合を「本来どの工程で見つかるべきか」で分類した：この切り口だと、テストの設計が悪いのか作りが悪いのかが分かれる

• 止める判断を、止めている間の予定とセットで出した：移行リハーサルの前倒しが、後で納期を救った

• 優先順位を先に決めてあった：Q最優先と決めていたので、止めるという判断ができた

最後に、明日から使える形にまとめます。結合テストで不具合が減らないと感じたら、次の3つを見てください。

1. 週ごとの発生件数に山ができているか：山ができず横ばいなら、直す速度の問題ではありません。3週続いたら調べ始めてください

2. 出た不具合を「本来どの工程で見つかるべきか」で分ける：結合テストなのに結合の不具合が2割を切っていたら、前工程に戻る判断を検討します

3. サブシステムごとの不具合密度を出す：偏りがあれば、その担当チームに何が起きているかを見に行きます。たいていは「伝わっていなかった」だけです

そして、いちばん伝えたいことを書きます。前工程に戻る判断は、遅れを生むように見えて、実は遅れを減らします。この事例では4週間止めましたが、止めなければ総合テストで同じことが起き、そこで止まるほうがずっと長くかかったはずです。戻るなら、早いほど安く済みます。