リリース後のバグを減らすテスト体制の作り方

「テストはちゃんとやったはずなのに、リリースした途端にバグの報告が次々と上がってくる」。受託開発のPMであれば、一度はこの胃の痛む状況を経験しているのではないでしょうか。クライアントからの問い合わせ、エンジニアの緊急対応、原因究明の会議。せっかく納めた成果物が、信頼の貯金を一気に取り崩していく感覚は、何度味わっても慣れるものではありません。この記事では、そうした事態を繰り返さないために、リリース後のバグを減らす体制をどう設計すればよいのかを掘り下げていきます。

この記事は、そうした本番障害を「気合いとレビューの強化」で乗り切ろうとしてきたPMに向けたものです。結論から言えば、リリース後のバグを減らすために本当に効くのは、個人の頑張りではなく「体制の作り方」です。なぜなら、本番でバグが多発する原因の多くは、特定の担当者の能力不足ではなく、テストの進め方そのものに埋め込まれた構造にあるからです。本記事では、リリース後にバグが集中する現象の正体を解きほぐし、その構造的な原因を整理したうえで、専任のテスト担当者を置きにくい受託開発の現場でも実践できる、現実的な体制づくりの手順を解説します。

なお、リリース「直前」に時間が足りなくなる局面の乗り切り方については、リリース直前にテストが間に合わない時の判断軸を整理した記事で詳しく扱っています。本記事は、その一歩手前——「そもそもリリース後にバグが出にくい体制をどう作るか」という平常時の設計に焦点を当てます。

リリース後にバグが集中する現場で何が起きているのか

まず、多くのPMが「うちだけかもしれない」と感じている本番障害の風景を、いったん言語化してみましょう。問題を直視することが、構造を変える第一歩になります。

「テストは通った」のに本番で落ちるパターン

社内のテストでは問題なく動いていた機能が、本番に出た途端に不具合を起こす。これは決して珍しいことではありません。よくあるのは、テスト環境と本番環境のデータ量や設定の違い、想定していなかった操作順序、複数の機能が同時に動いたときの干渉といった、「単体では再現しないが、実運用では起きる」タイプのバグです。

ここで重要なのは、これらのバグが「テストをサボったから」出ているわけではない、という点です。むしろ真面目にテストケースを消化したうえで、それでもすり抜けている。つまり、消化したテストの「量」ではなく、テストが見ていた「観点」に穴があったということです。本番障害を防ぐうえで、この区別はとても大切です。量を増やしても、抜けている観点は埋まりません。

障害対応がPMと開発チームを疲弊させる

本番障害がやっかいなのは、バグそのものの修正コスト以上に、周辺で発生するコストが大きいことです。クライアントへの一次報告、影響範囲の調査、暫定対応とリリース、恒久対応、再発防止の説明資料。これらはすべて、本来は次の案件に投じるはずだった時間を食いつぶしていきます。

しかも、こうした障害対応は予測できないタイミングで降ってきます。複数案件を並行で回しているPMにとって、突発的な火消しはスケジュール全体を狂わせる最大の要因です。エンジニアも、集中していた開発作業を中断して過去の案件に引き戻され、生産性とモチベーションの両方を削られていきます。

バグは「均等に散らばらない」という事実

ここで一つ、テストの世界で古くから知られている経験則を紹介します。ソフトウェアのバグは、コード全体に均等に散らばるのではなく、特定の箇所に偏って存在するという「バグ偏在の法則」です。高橋寿一氏は著書『知識ゼロから学ぶソフトウェアテスト』の中で、「バグの47%はプログラムの4%の部分に偏在していた」という例を紹介しています。

同氏が引くG.J.マイヤーズの言葉に「プログラムのある部分でエラーがまだ存在している確率は、すでにその部分で見つかったエラーの数に比例する」というものがあります。つまり、バグが見つかった箇所には、まだ見つかっていないバグも潜んでいる可能性が高い。逆に言えば、本番でのバグを減らすためには、闇雲に全体を薄く見るのではなく、リスクの高い箇所を狙い撃ちする発想が欠かせないということです。これは後ほど、体制づくりの具体策にも関わってきます。

リリース後のバグを減らすために知るべき3つの構造原因

本番障害の風景を確認したところで、いよいよ核心に入ります。リリース後にバグが多発する現場には、ほぼ共通して見られる構造的な原因が3つあります。担当者を責めても解決しないのは、原因が個人ではなく仕組みの側にあるからです。

構造原因①：開発エンジニアがテストを兼任している

少人数の受託開発では、テストを専門に担当する人を置く余裕がなく、作った本人や同じチームの開発エンジニアがそのままテストを担うケースが大半です。一見すると合理的ですが、ここに最初の構造的な弱点があります。

開発者は「自分が作ったものは正しく動くはず」という前提を無意識に持ってしまいます。これは能力の問題ではなく、人間の認知の自然な傾向です。自分の書いたコードに対しては、「こう使われるはず」という想定の範囲でしか操作を試さない。結果として、想定外の使い方や異常系——空欄のまま送信する、極端に大きい値を入れる、戻るボタンを連打する——といった、ユーザーが現実に行う操作が抜け落ちます。高橋氏も「エラーは見つからないだろうという仮定のもとにテストの計画を立ててはいけない」というマイヤーズの戒めを紹介していますが、自作物のテストはまさにこの罠に陥りやすいのです。

さらに、テストは本来まとまった工数を要する独立した工程です。『ソフトウェアテスト自動化の教科書』では、開発工程全体に占めるテストの割合は45%に達するという数値が示されています。ソフトウェア開発の工数や品質に関する定量データは、IPAが公開するソフトウェア開発分析データ集でも確認できますが、いずれにせよテストが開発全体に占める比重は小さくありません。開発で手一杯のエンジニアに、これだけの比重を持つ工程を「ついで」で兼任させれば、納期のプレッシャーの中で真っ先に圧縮されるのがテストになるのは避けられません。

構造原因②：テスト観点が属人化している

2つ目の原因は、「何をどこまでテストするか」という観点が、担当者の頭の中だけにあって共有されていないことです。テスト項目がドキュメント化されておらず、その人の経験と勘で都度組み立てられている状態を指します。

属人化したテストには、いくつもの問題が生じます。まず、担当者によって見る観点がばらつくため、品質が案件ごと・担当者ごとに不安定になります。次に、その人が別案件で忙しいときや退職したときに、テストの質が一気に落ちます。そして何より、「今回どこまで見たのか」がPMにもクライアントにも説明できません。本番でバグが出たとき、「ここはテスト範囲に入っていなかった」という事後説明しかできないのは、観点が形式知になっていないことの典型的な症状です。

属人化の怖いところは、平常時には問題が顕在化しないことです。優秀な担当者がいる間はうまく回っているように見えるため、誰も体制の問題だと気づきません。本番障害の芽を摘むという観点では、この「見えない依存」を放置することが最も危険です。

構造原因③：観点が偏り、異常系・連携部分が手薄になる

3つ目は、テストの観点そのものが正常系に偏りがちだという点です。「仕様どおりに操作したら仕様どおりに動く」ことを確認するテストは作りやすく、達成感もあります。一方で、本番障害の多くは正常系ではなく、異常系・境界値・機能間の連携といった「作りにくく、見落としやすい」領域から発生します。

たとえば、入力値の境界(0件のとき、上限を超えたとき)、複数ユーザーの同時操作、外部システムとの連携が失敗したときの挙動。これらは設計時に明示されていないことが多く、テスト項目に落とし込むには意識的な努力が必要です。先ほどのバグ偏在の法則と合わせて考えれば、リスクの高い「偏在の震源地」はまさにこうした複雑な箇所であり、そこを薄くしか見ていないことが本番障害に直結します。

これら3つの原因は独立しているのではなく、互いに絡み合っています。兼任だから観点を整理する時間が取れず(①→②)、観点が属人化しているから偏りに気づけず(②→③)、偏ったまま本番に出てバグが多発し、その対応でさらにテストの時間が削られる。この悪循環こそが、リリース後のバグが減らない本当の正体です。

兼任体制でも品質が崩れる仕組みを断ち切る

原因が「兼任・属人化・観点の偏り」という構造にあるなら、打ち手も構造に向けるべきです。ここで強調したいのは、「専任のテストエンジニアを採用しなければ解決しない」という話ではない、ということです。採用は有力な選択肢の一つですが、それ以前に、今の体制のままでもできる構造的な手当てがあります。社内にテスト専任を置けない場合の選択肢を整理したテストエンジニアがいない開発会社が取れる選択肢の記事も、あわせて判断材料にしてください。

「作る人」と「テストする人」を分ける小さな工夫

最も効果が大きく、コストの低い対策が「クロステスト」です。作った本人ではなく、別のメンバーが互いの担当機能をテストし合うだけの仕組みです。専任を増やさなくても、担当をローテーションするだけで「自分の作ったものは正しいはず」という思い込みのバイアスを外せます。

完全に分離できなくても構いません。少なくとも、リリース前の最終確認だけは作った本人以外が触る、というルールを一つ決めるだけでも、異常系の抜けはかなり減ります。重要なのは、テストする目を「作った人の視点」から意図的にずらすことです。これは設計変更ではなく運用ルールの変更なので、明日からでも始められます。

クロステストには、副次的な効果もあります。他人のコードを触ることで、メンバー同士がお互いの担当機能を理解し合うようになり、特定の人しか分からない「ブラックボックス機能」が減っていくのです。これは属人化そのものへの対策にもなります。最初は「お互いの粗探しをするようで気が引ける」という心理的な抵抗が出ることもありますが、「バグを見つけるのはチームの成果であって個人の失点ではない」という文化をPMが言葉にして共有すれば、健全なレビュー文化として定着していきます。

テストの「負のサイクル」を理解しておく

兼任体制が崩れる仕組みを、もう少し構造的に捉えておきましょう。『ソフトウェアテスト自動化の教科書』では、「テストの負のサイクル」という考え方が示されています。工数削減の圧力でテストが不十分になり、その結果として市場（本番）で不具合が出て、その対応に工数を取られ、それが次の案件のテスト工数を圧迫し、さらに不具合を生む——という悪循環です。

この図式が示すのは、本番障害は「単発の事故」ではなく、放置すれば自己増殖する負債だということです。逆に言えば、どこか一点でこのサイクルを断ち切れば、好転も連鎖します。たとえばクロステストで本番バグが減れば、障害対応の工数が浮き、その時間を次案件のテスト設計に回せる。リリース後のバグを減らす取り組みは、一度軌道に乗れば、自分自身の時間を生み出す投資になるのです。この好転のサイクルを作れるかどうかが、複数案件を抱えるPMの時間的な余裕を左右します。

テスト観点を「形式知」にする

属人化への直接的な対策は、観点をドキュメントに落とすことです。とはいえ、いきなり完璧なテスト仕様書を作る必要はありません。現実的なのは、「テスト観点リスト」という軽量な形から始めることです。

機能ごとに「正常系」「異常系」「境界値」「他機能との連携」「権限・状態による分岐」といった切り口を並べ、各機能でそれぞれ何を確認するかを一行ずつ書き出す。最初は粗くても、案件をまたいで再利用し、本番で見つかったバグの観点を都度追記していけば、自社の現場に合った「効くチェックリスト」が育っていきます。これは、担当者の頭の中にあった暗黙知を、チームの資産に変える作業です。テスト観点をリスト化するアプローチは、テストケースを体系的に作る考え方とも地続きなので、まずは粒度の粗いリストから着手し、運用しながら精度を高めていくとよいでしょう。

リスクの高い場所から守る——観点設計の現実解

形式知の器ができたら、次は「限られた工数をどこに集中させるか」です。すべてを均等にテストする余裕がない現場こそ、メリハリの設計が品質を左右します。

バグ偏在を逆手に取る優先順位づけ

先に紹介したバグ偏在の法則は、テスト設計の武器になります。バグが特定箇所に偏るなら、テストの労力もそこに偏らせればよい。具体的には、次のような箇所を「重点監視エリア」として優先します。

• 仕様が複雑で分岐の多い機能(料金計算、権限制御、ワークフローなど)
• 直近で改修・追加が入った箇所(変更はバグの主要な発生源)
• 過去に本番障害を起こした機能(同じ場所は再発しやすい)
• 外部システムやデータ連携が絡む部分

これらに工数を厚く配分し、変更の入っていない安定機能は軽く流す。この「広く薄く」ではなく「狙って厚く」という発想が、限られたリソースで本番障害を防ぐ鍵になります。

具体例で考えてみましょう。ある画面の改修で、表示ロジックだけを変えたつもりが、実は同じデータを参照している別画面の集計にも影響していた——というのは、連携バグの典型です。改修箇所そのものはテストしても、「その変更が波及する先」までは観点に入りにくい。だからこそ、変更を加えた箇所については「この変更は、どの機能のどのデータに影響するか」を一度書き出してから、その影響先も含めてテスト範囲に含めるという習慣が効きます。影響範囲を機能の一覧として可視化しておくと、改修のたびにどこを見るべきかが機械的に決まり、属人的な勘に頼らずに済みます。

異常系・連携を意図的にテスト項目へ

観点の偏りを直すには、テスト項目を作る段階で「異常系と連携を必ず一定数入れる」というルールを設けるのが有効です。正常系だけで項目が埋まってしまわないよう、たとえば「各機能につき異常系を最低2項目」といった下限を決めておく。機械的なルールに見えますが、意識しなければ抜ける領域だからこそ、ルールで強制する価値があります。

なお、こうした観点を体系的に学び直したい場合は、JSTQB（ソフトウェアテスト技術者資格認定の公式団体）が公開しているシラバスが参考になります。同値分割や境界値分析といった標準的なテスト設計技法は、属人化したテストを共通言語に置き換えるうえで土台になります。チーム内で観点の認識を揃える際の、共通の物差しとして活用できます。

「全体像の理解」を最初の工程に組み込む

もう一つ、現場の経験から見えてきた重要な観点があります。あるBtoBアプリのテスト案件の振り返りでは、テスト開始時にアプリの全体像を把握しきれていなかったために、無駄な操作が増えて時間がかかってしまった、という反省が共有されました。逆に、最初に全体像を理解する時間を意図的に設けることで、結果的に作業全体の時間が短縮されることも確認されています。

これは「急がば回れ」の典型です。機能間の連携バグは、全体像が頭に入っていなければそもそも観点として思いつけません。テストに入る前に、チーム全員で一つの画面を見ながら一緒に操作し、システムの全体像と業務の流れを共有する。この小さな投資が、連携部分の見落としを大きく減らします。

進め方はシンプルで構いません。テスト着手前に30分から1時間ほど、主要な業務シナリオを最初から最後まで一通り操作してみる時間を取るだけです。「このアプリは誰が、何のために、どういう順序で使うのか」をチームで言葉にしておくと、個々の画面を単体で見ていては気づけない「業務としての不整合」が見えてきます。ユーザーが実際にたどる導線に沿ってバグを探す観点は、機能単位のチェックリストだけでは決して埋められません。とくに後述する外部の力を借りる場合には、この情報共有フェーズの設計が品質を大きく左右します。

上長とクライアントを動かす——体制改善を通すための説明

ここまでの打ち手は、現場の運用だけで始められるものが中心でした。しかし、テスト工数の確保や外部リソースの活用となると、上長やクライアントの理解が必要になります。受託開発のPMにとって、ここが最後の、そして最大の関門です。

「障害コスト」を数字で見せる

品質投資の話は、「品質が上がります」という定性的な訴えだけでは予算化されません。経営層が反応するのは、コストの言語です。そこで効くのが、本番障害が実際にいくらの損失を生んでいるかを可視化することです。

完璧な試算は不要です。直近で起きた本番障害を一件取り上げ、(調査・修正に費やしたエンジニアの工数)+(PMの対応工数)+(緊急リリースの工数)を時間換算するだけで、一件あたりの障害がいかに高くつくかが見えてきます。

たとえば、ある障害でエンジニアが調査と修正に2人日、PMが報告対応と社内調整に1人日、緊急リリースの検証に0.5人日を費やしたとしましょう。合計3.5人日です。これに会議や手戻りで失われた他案件の進捗遅延を加えれば、体感としてはさらに大きくなります。こうした障害が四半期に数件発生しているなら、年間ではまとまった工数が「火消し」に消えている計算になります。これらはあくまで自社の実績値から積み上げる試算であり、根拠のない数字を作る必要はありません。手元の障害記録から拾えるはずです。

この一件あたりの障害コストと、テスト体制を整えるためにかかる工数(クロステストの追加時間、観点リスト作成の初期投資、必要に応じた外部リソース費用)を並べて見せれば、どちらが安いかは一目瞭然です。そこに「クライアントの信頼を損ねたことによる、次案件への影響」という定性的なリスクを添えれば、「テスト体制への投資は、障害コストの先払いである」という構図を示せます。これは、上長への説明にも、クライアントへの工数交渉にも使える共通の言語です。「品質のため」ではなく「コスト削減のため」という切り口に変換することが、稟議を通すうえでの実務的なコツです。

スポット外注という「採用しない」選択肢

「テスト体制を強化したいが、専任を採用する規模でも予算でもない」。これは多くのPMが直面するジレンマです。ここで現実解になるのが、必要な局面だけ外部のテストリソースを使う「スポット型」の活用です。常時雇用ではなく、リリース前の重点期間や、自社に知見の薄い領域だけをピンポイントで補強する使い方です。

外部の目を入れることには、観点の属人化と兼任バイアスを同時に解消できるという構造的なメリットがあります。作った本人でも社内の事情に染まった人でもない第三者がテストすることで、想定外の操作や異常系が自然と入ってくる。ただし注意点もあります。先述の現場振り返りでも指摘されていたように、外部にテストを委ねる場合は、開発の経緯や裏仕様といった情報が自然には伝わりません。この情報格差を埋めるフェーズを意図的に設計しないと、表面的な動作確認に終わってしまいます。外注を成功させるかどうかは、丸投げではなく「全体像をどう共有するか」にかかっています。

なお、外部リソースを使う場合のコスト感や費用相場については、テスト代行の費用相場を整理した記事で実際の見積もり感を解説しています。予算化の検討材料としてあわせてご覧ください。

月曜から始められる3ステップ

ここまでの内容を、明日から動ける形に落とし込みます。大きな体制変更を一度に行う必要はありません。次の順序で、小さく始めるのが現実的です。

1. クロステストのルールを一つ決める：少なくともリリース前最終確認は、作った本人以外が触る。コストはほぼゼロで、異常系の抜けに即効性があります。
2. テスト観点リストを粗くでも作る：機能ごとに正常系・異常系・境界値・連携の4観点を一行ずつ。本番バグが出るたびに追記し、自社の資産に育てます。
3. 直近の本番障害を一件、コスト換算する：体制改善を上長やクライアントに提案するための、数字の根拠を手に入れます。

この3つはどれも、専任採用や大きな予算を前提としません。本番障害を構造的に減らす取り組みは、こうした小さな構造改善の積み重ねから始まります。

まとめ：リリース後のバグを減らすのは「人」ではなく「仕組み」

本番でバグが多発する現場を、私たちは「テストが甘かった」「もっと気をつければ」という個人の問題として捉えがちです。しかし本記事で見てきたとおり、その根っこにあるのは、開発エンジニアのテスト兼任、観点の属人化、そして観点の偏りという、3つの構造的な原因でした。これらは気合いでは解消できず、放置すれば負のサイクルとして自己増殖していきます。

逆に言えば、構造に手を入れれば品質は構造的に底上げできます。作る人とテストする人を分けるクロステスト、観点を形式知にするテスト観点リスト、リスクの高い箇所への重点配分、全体像を共有する工程、そして必要な局面だけ外部の目を借りるスポット活用。どれも専任採用を前提とせず、少人数のテスト体制でも始められる打ち手です。本番障害を防ぐという目標は、こうした仕組みづくりの先に、着実に近づいていきます。

クライアントの信頼を一度損ねてしまうと、その回復には大きなコストがかかります。だからこそ、火が出てから消すのではなく、火が出にくい体制をあらかじめ設計しておくことに価値があります。外部リソースの活用も含めて体制を検討したい方は、中小規模の開発会社に向けたテスト代行の選び方を整理した記事もあわせてご覧ください。自社に合った無理のない進め方を見つける手がかりになるはずです。

第三者の視点を交えることで、これまで属人化していた観点が見えてくることもあります。自社のテスト体制の見直しを検討されている方は、現状の課題整理の段階からでもテスト体制づくりについて相談することができます。