「順調すぎるデバッグ」は本当に順調？：組み込みエンジニアの現場力養成ドリル（6）（1/2 ページ）
組み込みソフトウェアの開発プロジェクトは工程表に沿って進行します。そこにはデバッグフェーズもありますが、あまりに「順調」である場合、そこには落とし穴が潜んでいるかもしれません。プロマネの立場で「落とし穴」を見つけてください。
はじめに
今回も、問題を解きながら、組み込み系ソフトウェア開発の「現場力」と「開発力」を鍛えましょう。
これまで、仕様書のバグに関する問題が多かったので、今回の問題では、プロジェクトマネジャーの立場で、「デバッグ工程を続けるべきか、終了すべきか」の判断をしていただきます。今回のケースは「順調すぎるデバッグ」です。一見、理想的に進んでいるようですが、落とし穴が満載。厳しい目で分析し、表面上の問題点と、問題の本質を見つけてください。
問題編（制限時間30分）
デバッグ終了宣言をすべきか？
Aさんは、機器制御系の組み込みソフトウェアを新規開発しているプロジェクトのプロジェクトマネジャーです。開発期間は10カ月でC言語を使って開発しています。コーディングフェーズが終了した時点でのソースコードの総ステップ数は、コメント行を除き51KLOC（lines of code）。プロジェクト人員はAさんを含め6人です。
プロジェクトは2週間の机上デバッグを終了し、10週間前に予定通りマシンデバッグ工程に入りました。Aさんが描いたテスト項目消化の「予定」と「実際」、摘出バグ数の「予定」と「実際」は図1の通りです（青い点線は、「予定」で、黒い実線が「実際の数値」です。便宜上、5月の連休はなく、土日以外はデバッグしていると仮定します）。
テスト項目数は5397件。バグの摘出目標ですが、社内平均が3.8件／KLOCであるのに対し、このプロジェクトでは前回までの8回に渡る開発で平均5.9件／KLOCのバグが出ていたので、Aさんはプロジェクトのメンバーに310件以上のバグを見つけるよう指示しました。
デバッグは6月11日に予定通り終了し、バグは273件摘出しました。6月11日現在、図1を見てAさんは、「デバッグは極めて順調に進んだ。目標とした品質を確保できているので、デバッグを完了する」とテスト終了宣言をしてもいいでしょうか？ 問題があるとすれば、どんな問題があり、どんな手段を取るべきでしょうか？
解答編
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
世界最高のIQを持つ女性 vs 数学者軍団
問題を考える上で感覚（直感）の役目も大きなものですが、感覚だけに頼ると論理的な結果が見えにくくなることがあります。有名な問題を例に、組み込みエンジニアとしてどう問題に取り組むべきか、考えてみましょう。
図書館「蔵書分類」のバグ
今回は図書館でおなじみ「本の分類」を取り上げます。情報処理系の本は007（情報学、情報科学）に547（通信工学・電気通信）、548（情報工学）とバラバラに分類されていますが、この分類を「仕様書」と考え、その問題解決に取り組んでみましょう。
将棋「名人位」挑戦規定のバグ
組み込みエンジニアの現場力を上げるドリル、今回は「仕様書のバグ」に挑戦します。将棋界の最高タイトルの1つである、名人位の挑戦規定という仕様書に潜むバグを発見してください。
「仕様に潜むバグ」を見つける、たった1つの心掛け
組み込み開発の「現場力」を上げるには、問題に取り組み解決することが一番です。今回は「仕様のバグ」に挑みます。実は、仕様に潜むバグを見つけるには、たった1つの心掛けさえあれば良いのです。
若き組み込みエンジニア、B君の憂鬱
このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する「小さなトラブルを」取り上げ、演習形式で解説します。今回は機器制御系の組み込み開発に従事する若きエンジニア君の遅れを、プロマネの立場で助けてあげてください。