組み込みエンジニアの現場力養成ドリル（1）

若き組み込みエンジニア、B君の憂鬱（1/3 ページ）

このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する「小さなトラブルを」取り上げ、演習形式で解説します。今回は機器制御系の組み込み開発に従事する若きエンジニア君の遅れを、プロマネの立場で助けてあげてください。

公開 2018年02月08日 09時00分

更新 2018年03月07日 09時20分

著者

山浦恒央　東海大学大学院組込み技術研究科非常勤講師（工学博士）

[TechFactory]

印刷する連載新着通知を受け取る

はじめに

　今回から「組み込みエンジニアの現場力養成演習ドリル」と題し、コラムを開始することになりました。このコラムにより、組み込み部門の開発エンジニア、プロジェクトマネジャー、品質保証エンジニアの開発作業が、少しでも楽になり、効率が上がれば幸いです。

　このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する小さなトラブルを取り上げ、演習形式で進めます。組み込み系ソフトウェアの要求仕様定義、設計方式、コーディング、デバッグ、テスト、保守、見積もり、そしてデスマーチをテーマにして行く予定です。

　ではいきなり、演習問題に入ります。今回の問題は、新人エンジニアがデバッグ工程で行き詰っている状況を取り上げました。プロジェクト・マネジャーの視点で現状を冷静に分析し、対策を考えて、新人君を助けてあげてください。

問題編（制限時間30分）

若き組み込みエンジニア、B君の悩み

　Aさんは、機器制御系の組み込みソフトウェアを新規開発しているプロジェクトのプロジェクトマネジャーです。開発期間は1年で、C言語を使ってソフトウェアを開発します（ソースコードの総ステップ数は、コメント行を除き103KLOG）。プロジェクトはAさんを含め10人の陣容です。

　プロジェクトは6週間前に予定通りデバッグ工程に入りました。3カ月のデバッグ工程では、単体デバッグに6週間、組み合わせバッグに3週間、統合デバッグに3週間を見込んでいます。本日が単体デバッグの終了日です。

　B君はこのプロジェクト唯一の新人エンジニアなので、担当する量は、新人であることを考慮して他のベテラン技術者の半分以下にしてあります（B君が開発したソースコードの総行数は4247LOGで、全部で11モジュールを作りました。詳細は、下記の表1を参照してください）。単体デバッグ終了予定日の本日、B君の進みは以下の通りで、3日遅れとなっています。

　この表からB君の現状を分析して問題点を推測、プロジェクトマネジャーのAさんが取るべき対策を考えてください。なお、ステップ数にはコメントを含まず、命令語は1行に1つ書くだけとします。

■表1.B君のデバッグ進捗

プログラム名称	ステップ数	テスト項目総数	実施済テスト項目数	検出バグ数	修正済みバグ数
モジュール_01	352	31	31	4	4
モジュール_02	299	35	35	0	0
モジュール_03	1227	481	481	3	3
モジュール_04	584	24	2	13	6
モジュール_05	207	85	85	0	0
モジュール_06	306	68	68	37	37
モジュール_07	471	11	11	0	0
モジュール_08	392	9	9	0	0
モジュール_09	227	35	5	0	0
モジュール_10	82	9	9	0	0
モジュール_11	102	10	10	0	0
合計	4247	798	746	57	50

解答編

　表1.を見るといろいろな問題点が浮かび上がります。問題点は幾つか挙げられますが、「モジュール分割の適切さ」「テスト項目設計の適切さ」「品質の推定」「遅延の原因」「実際の進捗状況」と各所について、診断と対策をセットに解説します。

モジュール分割の適切さ

診断：モジュールは、プログラムの最小構成であり、通常、1つのモジュールは50ステップから200ステップになるといわれています。この表を見て、最初に気になるのは、「モジュール_10」「モジュール_11」以外、モジュールのステップ数が平均値よりかなり多いことです。特に「モジュール_03」は1227行もあり、大きすぎます。正当な理由があって大きいのなら問題ではありませんが、不適切なモジュール分割の結果だとしたら、バグの素になりますし、バージョン2以降で、保守性や可読性を低下させます。

対策：モジュール分割が適切か、「モジュール_10」「モジュール_11」を含めて全てのモジュールを見直します（「モジュール_10」と「モジュール_11」は、妥当な範囲内に収まっていますが、モジュール分割が正しくないのに、偶然、この値になった可能性が非常に高く、他のモジュールと同様に、分析する必要があります）。

　モジュール分割が不適切であると判明した場合、B君にベテラン技術者をしばらく張り付けて、モジュールを再分割するといいでしょう。コーディングフェーズの前の「設計フェーズ」まで戻るため、B君の遅延日数は一挙に2カ月になりますが、B君の担当分は全体の4％ですので、ベテラン技術者の援助により、遅れは取り戻せると思います。

次ページへテスト項目設計は適切か？

印刷する

組み込みエンジニアの現場力養成ドリル

このコラムでは、組み込みエンジニアが日々の開発で実際に遭遇する「小さなトラブルを」取り上げ、演習形式で解説します。

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

山浦恒央　東海大学大学院組込み技術研究科非常勤講師（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科准教授、2016年より非常勤講師。主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。

若き組み込みエンジニア、B君の憂鬱（1/3 ページ）

はじめに

問題編（制限時間30分）

若き組み込みエンジニア、B君の悩み

解答編

モジュール分割の適切さ

組み込みエンジニアの現場力養成ドリル

この記事の著者

新着ホワイトペーパー PR

関連記事

若き組み込みエンジニア、B君の憂鬱（1/3 ページ）

はじめに

問題編（制限時間30分）

若き組み込みエンジニア、B君の悩み

解答編

モジュール分割の適切さ

組み込みエンジニアの現場力養成ドリル

この記事の著者

新着ホワイトペーパー PR

関連記事

ソフトウェア品質のためにテストが「できること」「できないこと」

ソフトウェアの品質は「制御」できるか

計測で組み込みソフトウェアの「品質」を丸裸にする

組み込みソフトウェア品質の「特異性」と付き合い方

組み込みソフトウェアの「品質」とは何か――品質の始まりからその実態まで