これなら残存バグ数を予測できる？ 健全で実践的な「2チーム制」モデル：山浦恒央の“くみこみ”な話（49）

プログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第2回では、前回紹介したトンデモ推定法「キャプチャー・リキャプチャー・モデル（別名：ソフトウェア版『池の中の魚』モデル」の改訂版である、「2チーム制」モデルを取り上げる。

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），MONOist]

　コーディングが終わり、コンパイルエラーも消え、いざデバッグ工程に突入――。このとき、「プログラムの中に隠れているバグの総数を正確に推定できたらなぁ……」と考えたことはありませんか？ こう考えるのは何もプログラマーだけではありません。プロジェクトマネジャーも、プロジェト管理や品質制御の観点から、バグ総数を高精度で予測することを夢見ています。

　前回は、ソフトウェア中の残存バグ数の予測法として、「キャプチャー・リキャプチャー・モデル（別名：ソフトウェア版「池の中の魚」モデル）」を取り上げました。この方法は、動物学で用いられる「母体数推定モデル」を応用した面白い発想の「残存バグ数予測モデル」ですが、“人工的にバグを埋め込む”という一種のトンデモ推定法でした。

　今回は、キャプチャー・リキャプチャー・モデルの改訂版である「『2チーム制』モデル」を解説します。こちらは、健全であると同時に、極めて実践的な方法といえます。

1．キャプチャー・リキャプチャー・モデルの復習

　動物学の世界では、ある地域に生息する動物の個体数を推定するのに、キャプチャー・リキャプチャー・モデルと呼ばれる技法が用いられます。例えば、池の中の魚の数を予測する場合、以下のような手順を踏みます。

1. 魚を大量に捕まえて、目印を付ける（尻尾を赤く塗る）
2. 捕獲した魚をリリースする
3. 数週間たって、再び魚を大量に捕獲する
4. 2回目に捕獲した魚の中に、尻尾の赤い魚が何匹含まれているかで母体数を推定する

　これをソフトウェア中の残存バグ数の予測に応用すると、以下のようなステップになります。

1. デバッグ工程に入る前に、プロジェクトマネジャーが各プログラマーのソースコードを集める
2. プロジェクトマネジャーが、ソースコードに人工バグを埋め込む
3. プログラマーが、バグ入りソースコードをデバッグする
4. 人工バグの比率から、残存バグ総数を予測する

　この方法は発想として非常にユニークなのですが、人工的なバグを埋め込む行為は、“品質向上”を基本姿勢とするソフトウェア開発技術者にとって、大きな心理的抵抗があります。

　今回紹介する2チーム制モデルは、キャプチャー・リキャプチャー・モデルをベースにしていますが、“人工バグを埋め込まない”改訂版モデルです。それでは、その詳細を見ていきましょう。

2．2チーム制モデル

　このモデルは、人工バグを埋め込む代わりに、2つの独立したチームがテストを実施し、摘出されたバグのうち、両チームで共通したバグの数をカウントして、残存バグ数を推定するモデルです。以下に、具体的なステップを示します。

1. 2つの独立したテストチームを組織する　
   この2チームは、同じ会社でも、海外他社でも構いません
2. 2チームが別々に、同じプログラムのテストを実施する　
   互いのチームがどんなバグを摘出済みなのか、分からないようにします
3. 2チームが摘出したバグの中で、共通するバグを数え、残存バグ数を推測する　
   テストチームAが摘出したバグが、池の中の魚モデルにおける「最初に捕獲した魚（尻尾の赤い魚）」であり、もう一方のテストチームBが見つけたバグが、「2回目で捕獲した魚」に相当します。テストチームBが摘出したバグの中に、テストチームAが見つけたバグ（尻尾の赤い魚）が何件あるかによって、残存バグ数を予測します（図1）。例えば、テストチームAがE1個、チームBがE2個のバグを摘出し、両チームに共通するバグがEc個ある場合、全バグ数の推定値Epは、式1のように求められます

図1　2チーム制モデル

式1　2チーム制モデルにおける全バグ数の推定値（Ep）の算出

3．2チーム制モデルの適用可能性

　2チーム制モデルは、池の中の魚モデルを応用していますが、人工バグをソースコードに埋め込むようなことはしません。このため、ソフトウェア開発技術者の心理的な抵抗がなく、現在の品質レベルを保持できるため、極めて現実的で、実践的な方法といえます。特に「オフショア開発」と「部分的テスト」において、効果を発揮してくれます。

3．1．オフショア開発

　世界で最もソフトウェア開発技術者の人件費が高いのは、日本とアメリカです。両国では、安くて優秀なソフトウェア開発技術者を求め、インドや中国などの開発会社に発注するオフショア開発を盛んに行っています。

　一般的に、オフショア開発を行うには幾つかの事項を検討しなければなりません。例えば、「海外で担当してもらえるように、独立性が高く、分かりやすい作業を切り出す必要がある」「仕様書や設計書を日本語と英語のどちらで記述するか？」「コミュニケーションのミスが発生しないよう、双方の拠点にリエゾンエンジニア（連絡役の技術者）を配置する必要がある」などです。中でも、独立性が高く、分かりやすい作業を切り出すことは、オフショア開発が成功するか否かの大きなカギを握っています。

　2チーム制による残存バグ数の推定は、オフショア開発との相性が抜群です。同じプログラムを海外でテストしてもらう作業は、非常に手離れが良く、作業のゴールや目的が明快で、相手国のソフトウェア技術者に細かく指示しなくても理解しやすい作業といえます。日本チームと海外チームではなく、ソフトウェア開発技術者の人件費が日本の半分以下であるインドや中国で、2つのテストチームを編成すれば、日本で行うよりも安価にテストを実施できます。ただし、両チームのテスト品質を保証するため、それぞれのチームが設計したテスト項目の内容を日本でじっくりとチェックする必要があります。

3．2．部分的テスト

　2チーム制モデルは、開発するソフトウェア全体に適用する必要はありません。重要性の高いモジュールやバグの多い機能など、部分的に2チーム制モデルを適用すれば、モジュールごとの残存バグ数を予測できますし、品質の分析が可能となります。

　モジュールが十分に小さければ、“1チーム＝1人”とし、2人で2チームを組織できますし、短期間での作業が可能になります。この部分的テストは導入を検討すべきでしょう。

4．2チーム制モデルの課題

　繰り返しになりますが、オリジナルの池の中の魚モデルに比べ、改訂版である2チーム制モデルは、人工バグを埋め込む必要がありません。このため、現状の品質を維持したままで、残存バグ数の推測が可能となります。

　ただし、前回、池の中の魚モデルの評判が悪い理由として挙げられた「残存バグの推定値が、実際のバグ数よりもかなり小さい」については、2チーム制モデルでも改善されていません。ある研究によると、2チーム制モデルでも、推定値は実際の値の40％前後になるそうです。

　しかしながら、独立した2チームが別の視点で同じソフトウェアをテストすることは、品質制御の観点からも非常に有効であり、バグ数推定の他にもいろいろな効果が期待できます（実際、適用・活用している企業もあります）。特に、筆者はオフショア開発で積極的に導入を検討すべきだと考えます。

---

　さて、次回は「Gompertz Curve（ゴンペルツ曲線）」を適用した、残存バク数の予測法について解説します。お楽しみに！ （次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 准教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。