健全で実践的な「2チーム制」モデルプログラマーの永遠の課題「プログラム中の残存バグ数の推定」に迫るシリーズ。第2回では、前回紹介したトンデモ推定法「キャプチャー・リキャプチャー・モデル(別名:ソフトウェア版『池の中の魚』モデル」の改訂版である、「2チーム制」モデルを取り上げる。});コーディングが終わり、コンパイルエラーも消え、いざデバッグ工程に突入——。考えるのは何もプログラマーだけではありません。プロジェクトマネジャーも、プロジェト管理や品質制御の観点から、バグ総数を高精度で予測することを夢見ています。前回は、ソフトウェア中の残存バグ数の予測法として、「キャプチャー・リキャプチャー・モデル(別名:ソフトウェア版「池の中の魚」モデル)」を取り上げました。この方法は、動物学で用いられる「母体数推定モデル」を応用した面白い発想の「残存バグ数予測モデル」ですが、“人工的にバグを埋め込む”という一種のトンデモ推定法でした。今回は、キャプチャー・リキャプチャー・モデルの改訂版である「『2チーム制』モデル」を解説します。こちらは、健全であると同時に、極めて実践的な方法といえます。動物学の世界では、ある地域に生息する動物の個体数を推定するのに、キャプチャー・リキャプチャー・モデルと呼ばれる技法が用いられます。池の中の魚の数を予測する場合、以下のような手順を踏みます。魚を大量に捕まえて、目印を付ける(尻尾を赤く塗る)捕獲した魚をリリースする数週間たって、再び魚を大量に捕獲する2回目に捕獲した魚の中に、尻尾の赤い魚が何匹含まれているかで母体数を推定するこれをソフトウェア中の残存バグ数の予測に応用すると、以下のようなステップになります。デバッグ工程に入る前に、プロジェクトマネジャーが各プログラマーのソースコードを集めるプロジェクトマネジャーが、ソースコードに人工バグを埋め込むプログラマーが、バグ入りソースコードをデバッグする人工バグの比率から、残存バグ総数を予測するこの方法は発想として非常にユニークなのですが、人工的なバグを埋め込む行為は、“品質向上”を基本姿勢とするソフトウェア開発技術者にとって、大きな心理的抵抗があります。今回紹介する2チーム制モデルは、キャプチャー・リキャプチャー・モデルをベースにしていますが、“人工バグを埋め込まない”改訂版モデルです。それでは、その詳細を見ていきましょう。2.2チーム制モデルこのモデルは、人工バグを埋め込む代わりに、2つの独立したチームがテストを実施し、摘出されたバグのうち、両チームで共通したバグの数をカウントして、残存バグ数を推定するモデルです。以下に、具体的なステップを示します。テストチームAが摘出したバグが、池の中の魚モデルにおける「最初に捕獲した魚(尻尾の赤い魚)」であり、もう一方のテストチームBが見つけたバグが、「2回目で捕獲した魚」に相当します。テストチームBが摘出したバグの中に、テストチームAが見つけたバグ(尻尾の赤い魚)が何件あるかによって、残存バグ数を予測します(図1)。2チーム制モデルにおける全バグ数の推定値(Ep)の算出3.2チーム制モデルの適用可能性2チーム制モデルは、池の中の魚モデルを応用していますが、人工バグをソースコードに埋め込むようなことはしません。このため、ソフトウェア開発技術者の心理的な抵抗がなく、現在の品質レベルを保持できるため、極めて現実的で、実践的な方法といえます。「オフショア開発」と「部分的テスト」において、効果を発揮してくれます。世界で最もソフトウェア開発技術者の人件費が高いのは、日本とアメリカです。両国では、安くて優秀なソフトウェア開発技術者を求め、インドや中国などの開発会社に発注するオフショア開発を盛んに行っています。一般的に、オフショア開発を行うには幾つかの事項を検討しなければなりません。「海外で担当してもらえるように、独立性が高く、分かりやすい作業を切り出す必要がある」「仕様書や設計書を日本語と英語のどちらで記述するか?」「コミュニケーションのミスが発生しないよう、双方の拠点にリエゾンエンジニア(連絡役の技術者)を配置する必要がある」などです。中でも、独立性が高く、分かりやすい作業を切り出すことは、オフショア開発が成功するか否かの大きなカギを握っています。2チーム制による残存バグ数の推定は、オフショア開発との相性が抜群です。同じプログラムを海外でテストしてもらう作業は、非常に手離れが良く、作業のゴールや目的が明快で、相手国のソフトウェア技術者に細かく指示しなくても理解しやすい作業といえます。日本チームと海外チームではなく、ソフトウェア開発技術者の人件費が日本の半分以下であるインドや中国で、2つのテストチームを編成すれば、日本で行うよりも安価にテストを実施できます。両チームのテスト品質を保証するため、それぞれのチームが設計したテスト項目の内容を日本でじっくりとチェックする必要があります。3.2.部分的テスト2チーム制モデルは、開発するソフトウェア全体に適用する必要はありません。重要性の高いモジュールやバグの多い機能など、部分的に2チーム制モデルを適用すれば、モジュールごとの残存バグ数を予測できますし、品質の分析が可能となります。モジュールが十分に小さければ、“1チーム=1人”とし、2人で2チームを組織できますし、短期間での作業が可能になります。この部分的テストは導入を検討すべきでしょう。繰り返しになりますが、オリジナルの池の中の魚モデルに比べ、改訂版である2チーム制モデルは、人工バグを埋め込む必要がありません。このため、現状の品質を維持したままで、残存バグ数の推測が可能となります。前回、池の中の魚モデルの評判が悪い理由として挙げられた「残存バグの推定値が、実際のバグ数よりもかなり小さい」については、2チーム制モデルでも改善されていません。ある研究によると、2チーム制モデルでも、推定値は実際の値の40%前後になるそうです。独立した2チームが別の視点で同じソフトウェアをテストすることは、品質制御の観点からも非常に有効であり、バグ数推定の他にもいろいろな効果が期待できます(実際、適用・活用している企業もあります)。筆者はオフショア開発で積極的に導入を検討すべきだと考えます。Curve(ゴンペルツ曲線)」を適用した、残存バク数の予測法について解説します。55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」(以上、日経BP社、翻訳)。MONOist編集部では組み込みソフトウェアの品質管理をテーマにしたゼミナール「組み込みソフトウェア開発で問われる品質力」を開催。組織における品質管理の考え方や、実際の開発現場におけるツールの活用・導入に関する事例などが披露された。強く求められる組み込み業界。SNSfacebooktwitterITmediaはアイティメディア株式会社の登録商標です。