はじめに
顧客への進捗報告の前日、こんな数字が手元にあったとします。
| コンポーネント | テストケース数 | 摘出不具合数 | バグ密度 |
|---|---|---|---|
| 画面・API層 | 800件 | 38件 | 4.8% |
| ビジネスロジック層 | 600件 | 14件 | 2.3% |
| 外部連携・非同期処理層 | 60件 | 8件 | 13.3% |
「IPA白書の基準は2〜5%って聞いてるんですが、13%って品質に問題があるということですよね？」
こう聞かれたとき、あなたはすぐ答えられますか？
本記事では、レガシーフレームワークからの移行プロジェクトを題材に、バグ密度をどう評価するか、そしてAIに顧客役を演じさせて鋭い質問を事前に潰す方法を紹介します。
マイグレーション特有の「バグ密度の歪み」
新規開発と根本的に異なる不具合の性質
フレームワーク移行プロジェクトで発生する不具合は、新規開発のそれとは性質が違います。
新規開発の典型的なバグ
- 要件の解釈ミス
- ビジネスロジックの実装ミス
- 境界値・異常系の考慮漏れ
マイグレーションの典型的なバグ
- 移行先フレームワークのAPI非互換・振る舞いの変化
- 環境設定の差分（接続先・タイムアウト値など）
- コード自動変換ツールによる変換の副作用
- 旧フレームワーク固有の暗黙的な挙動への依存
同じ「バグ」でも、原因の構造がまったく異なります。IPA白書の基準値はおもに新規開発を対象とした統計です。マイグレーション専用の公的基準は存在しません。
コンポーネントによって偏りが出やすい理由
マイグレーションでは、不具合の発生がコンポーネントによって大きく偏ります。
外部システムとの連携処理や非同期処理は、フレームワーク依存の設定・接続管理が複雑なため、移行の影響を受けやすいです。一方、シンプルなCRUD処理が中心の領域は相対的に安定しやすいです。
冒頭の例で外部連携・非同期処理層の密度が13.3%と高かったのも、この「マイグレーション特有の偏り」が出た典型パターンです。
IPA白書との比較で「何が言えて、何が言えないか」
IPA白書の目安値
IPA「ソフトウェア開発分析データ集」では、結合試験工程でのテストケースあたり不具合検出率の一般的な目安として 2〜5% が示されています。
冒頭の数値をこの基準に当てはめると次のようになります。
| コンポーネント | バグ密度 | IPA目安 | 一見した判定 |
|---|---|---|---|
| 画面・API層 | 4.8% | 2〜5% | ギリギリ範囲内 |
| ビジネスロジック層 | 2.3% | 2〜5% | 標準範囲内 |
| 外部連携・非同期処理層 | 13.3% | 2〜5% | 大幅超過 |
「13%はアウト」と結論づけたくなりますが、ここで立ち止まる必要があります。
直接比較が危うい3つの理由
理由1：IPA白書は新規開発ベースのデータ
マイグレーション特有の不具合パターン（構成差分・API非互換）は、白書が前提とするバグの性質と根本的に異なります。同じ物差しで測ることには限界があります。
理由2：テストケースの粒度が揃っていない
バグ密度は「不具合数 ÷ テストケース数」です。テストケースの粒度が粗ければ分母が小さくなり密度は上がり、細かければ密度は下がります。自分たちのプロジェクトのテスト設計粒度と、IPA白書に掲載されたプロジェクトの粒度が同じとは限りません。
理由3：サンプルサイズが小さい
外部連携・非同期処理層はケース数が60件でした。このサイズだと数件の増減がパーセンテージを大きく動かします。
8件 / 60件 = 13.3%
7件 / 60件 = 11.7% ← 1件減るだけで2%近く変わる
6件 / 60件 = 10.0%
統計的に安定したバグ密度を算出するには、60件という規模は少なすぎます。
ではIPA白書はどう使うべきか
「合格か否か」の絶対基準としては使えませんが、「相対感のキャリブレーション」 としては有効です。
- コンポーネント間の偏りを見つける：他が2〜3%の中で13%が出ていれば、「そこに何かが集中している」という仮説を立てられる
- フェーズをまたいだ変化を追う：内部結合→外部結合→総合試験と進むにつれて摘出率がどう変化するかの観察指標になる
- 「異常値への感度」を持つ：2〜5%という目安を知っているからこそ、その数倍の値を見て立ち止まれる
「13%はアウトか？」ではなく、「13%が出た領域に何が起きているか？」を問うのが正しい使い方です。
AIで「顧客の厳しい質問」を事前に潰す
ここでいうAIとは、ChatGPTやClaudeのようなLLM（大規模言語モデル）を指します。
なぜ自分で想定問答を作ると失敗するか
報告前に自分で「想定される質問」を考えると、無意識に答えやすい質問ばかり選んでしまいます。これは認知バイアスの一種で、当事者ほど自分の盲点に気づきにくいものです。
AIを「顧客担当者役」として使うことで、この偏りを補正できます。
プロンプトの設計
あなたはシステム移行プロジェクトの顧客担当者です。
以下の進捗報告資料を読み、品質・スケジュール・リスクの観点から
「ベンダーが最も答えに困るであろう質問」を8〜10問生成してください。
【報告資料の要旨】
- 結合試験中。コンポーネントAは4.8%、Bは2.3%、Cは13.3%
- CはIPA白書の基準値（2〜5%）を大幅に超過している
- Cのケース数は60件と少ない
- コード自動変換ツールを使って移行を実施
- リリースまで〇ヶ月。強化試験の実施を検討中だがスコープ未確定
各質問に対して、ベンダー側の模範回答案も作成してください。
「ベンダーが最も答えに困るであろう質問」 というフレーズが肝です。「想定質問を出して」だと当たり障りのない質問しか返ってきません。「困る質問」と指定することで、バグ密度の解釈・自動変換ツールのリスク・スケジュール根拠など、鋭い切り口を引き出せます。
実際に出てくる質問の例
上記のプロンプトに対してAIが生成する質問には、たとえば次のようなものが含まれます。
Q：コンポーネントCの13%はIPA基準の3倍近い値です。品質上の重大な問題があるとは言えないのですか？
A：2点補足します。第一に、ケース数が60件と少なく、数件の増減でパーセンテージが大きく動く規模です。第二に、IPA白書の基準は新規開発を対象とした統計であり、マイグレーション案件への直接適用は適切ではありません。Cで検出された不具合の大半は構成差分起因であり、ロジックの品質問題ではありません。ただし当該領域に集中が見られることは事実であり、後続工程でのリスクとして引き続き管理します。
Q：コード自動変換ツールで変換した箇所に、テストで検出できていない潜在バグが残っている可能性はないですか？
A：ゼロとは言い切れません。自動変換は広範囲に及ぶため、人間によるレビューにも限界があります。この前提のもと、変換影響が大きい機能を優先した強化試験（リグレッション観点）の実施を計画しています。結合試験→強化試験→外部結合→総合試験の多層構造で品質を確保する方針です。
自分では「答えやすい言い方」に逃げていた部分を、AIが容赦なく突いてきます。この経験は、報告資料の「穴」を発見する上でも有効です。
想定問答活用のチェックポイント
- 答えられない質問が残ったら、それが本当のリスク：言葉に詰まる質問は、資料や判断に未整理な部分があるサインです
- 回答が「言い訳」になっていないか確認する：数字の背景説明が防衛的すぎないか、第三者目線で読み直す
- 論点が出たら報告資料に反映する：AIが掘り起こした視点を補足説明として資料に組み込む
強化試験の要否判断フレームワーク
バグ密度の分析とAIによる想定問答を通じて「この領域はリスクが高い」という判断ができたとき、次に問われるのが「追加で強化試験をやるべきか」です。
判断の軸として使えるのは次の観点です。
| 観点 | 実施を支持する | 縮小・見送りを支持する |
|---|---|---|
| 自動変換の影響範囲 | 広範囲・深い変換が行われた | 変換範囲が限定的 |
| 結合試験での摘出傾向 | 特定領域に不具合が集中 | 全体的に低く安定している |
| リリース後の影響度 | 障害時の業務インパクトが大きい | ロールバック・対処が容易 |
| スケジュール余裕 | 後続工程に十分な時間がある | 強化試験が後工程を圧迫する |
「やる/やらない」を二択で即決するより、「いつまでに何を確認したら判断するか」を決めておくことが現実的です。たとえば「〇日時点での修正消化状況を確認してから判断する」というデッドラインを設けることで、スケジュールとリスクのバランスを取りながら柔軟に動けます。
まとめ
本記事で紹介したアプローチを整理します。
| やること | ポイント |
|---|---|
| バグ密度をIPA白書と比較する | 絶対評価ではなく「どこが偏っているか」を見るために使う |
| 高い密度が出た領域を深掘りする | 不具合の性質・ケース数・自動変換との関係を確認する |
| AIに「困る質問」を生成させる | 報告前日に顧客役を演じさせ、盲点を先に潰す |
| 強化試験の判断にデッドラインを設ける | 「いつ何を確認して決める」を事前に決めておく |
マイグレーションのバグ密度は、数字だけ見ると「高い＝悪い」に見えます。しかし文脈を添えれば説明できる数字であることがほとんどです。
AIを使った想定問答作成は、その準備コストを大幅に下げてくれます。ぜひ次の報告前に試してみてください。