欠陥が減ったのか、探さなくなったのか

架空事例：青葉機材が予約システムの公開可否を判断する。試験件数、欠陥数、配信割合、判断規則は説明用に作成した。特定の企業の実績、IPAの採点基準、推奨する合格値ではない。

五十件が五件になった

前の週には五十件あった新規欠陥が、今週は五件になった。累積欠陥数の曲線は、次第に横へ寝ている。報告資料には「品質が収束」と書かれた。

実行した試験は、五百件から二十件へ減っていた。外部サービスとの接続が遅れ、難しいシナリオを試せなくなっていたのである。

発見数が減ったことは事実だ。しかし、その事実を、欠陥が残っていないという結論へ直結させることはできない。調べる機会そのものが減れば、問題が多いままでも曲線は平らになる。原教材第11章のバグ管理図は、曲線の形だけで完成を宣言するための図ではない。1

分母を付けても、比較の条件は残る

単純に割ると、前週は一試験当たり0.1件、今週は0.25件である。見かけ上の発見率はむしろ高い。ただし、この比率だけで品質が悪化したとも言い切れない。試験ごとの範囲や難度、対象版が異なるからだ。

今週の二十件が、意図的に未確認の例外処理へ集中していたなら、欠陥が見つかりやすくても不思議ではない。同じ五百件を繰り返して低い発見率を得る場合と、未知の領域へ進んで高い発見率を得る場合を、数字だけで上下に並べない。

青葉機材では、対象となる要求、実行済み・未実行・実行不能の試験、検出した欠陥の重大度、修正後の確認状況を一緒に示すことにした。全件数を増やすより、出庫確約や請求のような重要な約束について、どの根拠がまだないかを明らかにする。

シラバス12-4と13-2にも、要件のテスト網羅性、期待結果への適合、残存不具合の影響、運用・保守の実現可能性が含まれる。1 一つの曲線では、そのすべてを代弁できない。

直した件数と、確認し直した件数

欠陥管理表の状態が「修正済み」に変わった。だが、修正したプログラムは、まだ結合環境へ配備されていない。

このとき確認できるのは、修正が保存されたという段階までである。期待した不具合が消えたこと、関連する機能を壊していないこと、配備先でその修正が動いていることは、それぞれ別に確かめる必要がある。

本事例では、修正対象の事象を再現する試験と、変更影響に沿った回帰確認を分ける。例えば取消し時の数量復元を直したなら、その取消しが通るだけでなく、二重取消しや途中失敗で確保量が変わりすぎないかを、関連する契約に沿って確認する。無関係な試験を一律に増やすのではない。

対象版の識別が曖昧なら、別の版で通った証拠を混ぜてしまう。ソースコード、設定、データ定義、外部連携条件を、どの組合せで確認したかが品質評価の一部になる。

残っている欠陥を、数式で推定できる条件

既知の人工欠陥を二十件埋め込み、そのうち十五件を見つけた。同じ試験で、自然に存在した欠陥を三十件見つけたとする。

人工欠陥と自然欠陥が同じ割合で検出されるという近似を置けば、検出割合は 15÷20＝0.75。自然欠陥の推定総数は 30÷0.75＝40件、まだ検出していない自然欠陥は 40−30＝10件 となる。原教材第11章のエラー埋込み法を、別の数値でたどった例である。1

この十件は、確実にそこへ存在する欠陥を発見した数ではない。人工欠陥が自然欠陥より簡単に見つかるなら、自然欠陥の残りを少なく見積もる可能性がある。未実施の機能がある場合に、実施済みの領域で得た検出割合を全体へ広げてよいかも検討が必要になる。

さらに、人工欠陥の残り五件と、自然欠陥の推定残存十件は違う。推定した残存数と、そのうち重大なものがどれだけあるかも同じ問いではない。計算結果が小さくても、重要な要求の試験が未実施なら、その不足は消えない。

ミューテーションテストの検出割合も、この式へ無条件に入れない。実装への変異をテストが検出する能力を測ることと、自然欠陥の総数を特定の仮定で推計することは、目的と分母が異なる。

仕様を満たしても、営業が仕事を終えられない

予約検索の応答は二秒以内だった。ところが、営業は顧客と通話しながら検索条件を三つの画面へ入力し、結果を転記していた。一件の受付は、旧システムより長くかかった。

システムの性能効率性と、利用者が目的を達成するときの効率を分けて考える必要がある。原教材第10章が扱うJIS X 25010:2013の製品品質と利用時の品質の区別は、この見方の出発点になる。1 本章では、その教材が指定する版の用語を、現在の別版の分類へ無断で置き換えない。

NASAのシステム工学の公開説明でも、verificationは指定された要求への適合、validationは使用環境で意図した必要を満たすかという異なる目的を持つ。2 両者を、単純に「開発者が行う試験」と「利用者が行う試験」の別名にしてはいけない。

青葉機材では、検索応答を測ることに加え、代表的な受付を利用者が完了するまでを観察する。そこで見つけた転記や確認の重複を、画面の遅さとは別の改善対象として扱う。測りやすい部分の合格が、仕事全体の合格を意味するとは限らない。

受入れの判断を、公開直前に作らない

納期が近付くと、担当者は「この程度なら使える」と考え始める。だからこそ、何を満たす必要があり、何を残したまま開始できるかを、都合のよい結果が出る前に合意しておく意味がある。

本事例では、誤った出庫確約や二重請求に関わる未解決事項と、回避可能な表示上の問題を区別する。ただし、どんな組織でも同じ重大度なら公開できるという一般則を設けるのではない。影響、発生条件、回避策、修正予定、利用者への負担を示し、責任を持つ関係者が判断できるようにする。

受入れは、単に最終テストへ名前を付けることではない。合意した要求と契約、実際の業務に照らした評価が関係する。シラバス15-1の受入れレビュー・テスト支援と、16-5の運用テスト実施は、対象と確認事項を区別して読む。1

「期限が来たから合格」と「残るリスクを理解して条件付きで開始を決めた」は、同じ判断ではない。

一部に公開するなら、一部だけの結果を読めるか

新しい検索処理を、一部の利用へ先行して適用することにした。GoogleのSRE Workbookは、カナリアを部分的かつ期間を限った変更の配備と評価として説明し、比較対象、観測指標、対象集団や期間の代表性を重視している。3

全要求の1%へ新しい版を割り当て、その版だけで10%の要求が失敗したと仮定する。旧版の失敗や共有資源への影響を除いた単純な計算では、全体への追加の失敗は0.1%に見える。全体平均だけを見ていれば、新版の十件に一件が失敗する問題を小さく感じてしまう。

本事例では、新旧の版ごとに結果を分ける。さらに、朝の単純な検索だけを試して、月末の大量出庫照会まで確認したことにはしない。小さな範囲で問題が出なかった結果を、まだ通っていない条件へ広げすぎない。

また、配備範囲を1%にしても、共有DBの誤更新が全利用者へ影響するなら、被害が1%に限定されるとは限らない。段階公開の単位と、障害が波及する単位を合わせて考える。

元へ戻した後に、何が残るか

旧版のプログラムへ戻せば、旧状態へ戻るだろうか。新版が送ったメール、確定した料金、削除したデータは、プログラムの差替えだけでは取り消せない。

そのため青葉機材は、旧版が新版の保存データを読めるか、停止中に受け付けた依頼をどう照合するか、外部へ確定した処理を誰が扱うかを事前に確認する。元へ戻す操作を用意することと、業務を矛盾なく回復できることは違う。

切戻しが困難なら、その事実を公開判断へ含める。より小さい変更に分ける、影響の大きい更新を別時期にするなどの案を比較できる。どの方式も、名前を採用しただけで安全になるわけではない。

公開後の観測を、利用者の結果へ戻す

サーバは動いている。CPU使用率も低い。しかし、顧客は予約を完了できない。プロセスの生存は、提供している仕事の成功とは異なる。

GoogleのSRE書籍では、内部の測定値を使う監視と、利用者から見える振る舞いを確かめる監視を区別している。4 本事例でも、内部の接続数や失敗ログに加え、必要な検索や受付が完了するかを観測する。目的は、数多くのグラフを置くことではない。

監視に使う試験的な予約が、本物の在庫を確保したまま残らないようにもする。観測の仕組み自体が業務へ影響するなら、その範囲を制御しなければならない。

公開前に確かめた要求、公開後に実際に得られた結果、まだ残る問題をつなげて読む。品質は、公開ボタンを押す一瞬だけの採点ではなく、意図した仕事が成立しているかを継続して評価する対象なのである。

知識を答案へ戻す

午前Ⅱ。 検出欠陥数、修正済み数、残存推定数、テストの検出能力を混同しない。品質指標は、分母、対象版、測定範囲、仮定と合わせて読む。

午後Ⅰ。 実施できていない重要な試験、残存不具合の業務影響、切戻しの制約を本文から特定する。曲線が平らになったことだけで、公開可能と断定しない。

午後Ⅱ。 どの要求をどの方法で確認し、残るリスクをどう評価して開始を判断したかを説明する。公開後の業務効果と技術指標を分け、実績と推定を混ぜない。

立ち止まって考える：検出欠陥数が減り、全体のエラー率も低い。それだけで新版を全体公開できるか

試験量の減少や未実施領域、新版だけの失敗率、代表的な負荷を通したかを確認する必要がある。さらに、残存不具合の影響と回復可能性を、合意した受入れ・公開条件へ照合する。小さい数字が、必要な根拠の欠落を補うわけではない。

出典と照合範囲

[1] コンプリートテキスト第10・11・13・25章、IPA「SAシラバス Ver.5.2」4-14、12-4、13-2、15-1、16-5、18-1、19-1：品質、残存欠陥、受入れ、運用・業務の評価を出発点とした。数値と青葉機材の判断は独自の仮定。比率、残存数、先行公開の単純計算はPythonで照合した。公式シラバス

[2] NASA Systems Engineering Handbook, 5.3 Product Verification：指定要求への適合と、利用環境での意図した必要への適合という目的の区別を参照した。宇宙機固有のQualification・Acceptance・Certificationの制度を、そのまま一般のIT調達へ適用していない。公開本文

[3] Google, The Site Reliability Workbook, Canarying Releases：部分的・期間限定の評価と、版別の比較、対象集団・期間の代表性を参照した。1%と10%の例、および共有DBへの波及は本章の独自の条件である。公開本文

[4] Google, Site Reliability Engineering, Monitoring Distributed Systems：内部の情報を使う監視と、外部から見える振る舞いの監視を区別する説明を参照した。具体的な監視項目や閾値を、すべてのシステムへの一律の要求としていない。公開本文