組み込み開発の工数見積もり

代表的な見積もり手法を整理する

工数見積もりの手法は、大きく三つに分類されます。まずはそれぞれの内容を整理しておきます。手法の特徴を理解しておくと、自社のプロジェクトにどこまで適用できるかを判断しやすくなります。

• 類推法：過去の類似プロジェクトの実績をもとに、工数を見積もる手法です。IPA（独立行政法人情報処理推進機構）の資料でも、過去実績を基礎とする手法として紹介されています。着手のしやすさが利点ですが、類似案件の選び方によって精度が左右されます。参考にする案件の規模や条件が実際のプロジェクトとかけ離れていると、見積もりの誤差が大きくなります。
• パラメトリック法：工数を目的変数とし、規模や複雑さなどの要因を説明変数とする数式で見積もる手法です。代表例がCOCOMO（Constructive Cost Model）です。COCOMOは1981年にバリー・ベーム氏が発表したモデルで、実プロジェクトの実績データに基づく回帰式から工数を導きます。規模だけで算出する基本モデルのほか、開発特性を加味する中間モデル、モジュール単位まで踏み込む詳細モデルが用意されています。ファンクションポイント法も、同じくパラメトリック法に分類されます。
• ボトムアップ法：WBS（Work Breakdown Structure、作業分解構成図）などで成果物を要素分解し、要素ごとの工数を積み上げる手法です。積算の根拠は明確になりますが、要素の洗い出しに漏れがあると総量が不足します。要素を細分化しすぎると、見積もり作業そのものに多くの時間がかかる点にも注意が必要です。

これらの手法は、IPAの「ソフトウェア開発見積りガイドブック」など、エンタープライズ向け受託開発の文脈で整理が進んできました。しかし組み込みソフトの開発では、同じ手法をそのまま当てはめても精度が上がりません。ハードウェアと密接に結びついた開発プロセスならではの不確実性があるためです（「組み込みソフトと汎用ソフトの違い」参照）。次の章から、その不確実性の中身を具体的に見ていきます。

ハードウェアの試作スケジュールに引きずられる工程

組み込みソフトの開発では、ソフト単独で計画を完結できない場面が数多くあります。試作機や評価用基板が完成しなければ、実機での動作確認に着手できないためです。ここに、エンタープライズ系の見積もり手法があまり触れてこなかった難しさが集中しています。

• 試作スケジュールへの追随：ハードウェアの試作が遅れると、ソフトウェアの結合や検証の開始時期も後ろ倒しになります。ソフト側の見積もりを厳密に立てても、ハード側の遅延がそのまま工数の遅延につながります。ソフトとハードの進捗が別々に管理されていると、この遅延に気づくタイミングも遅れがちです。
• 試作基板の入手時期の不透明さ：試作基板は部品調達や基板製造の都合に左右され、事前に正確な日程を読みにくいという事情があります。見積もり段階では、確定できない前提が数多く残ります（「組み込み開発における制約事項」参照）。使用する部品の供給状況によっては、入手時期がさらに読みにくくなることもあります。
• ハード仕様変更による設計の後戻り：ハードウェアの仕様変更が発生すると、完了済みの設計や実装のやり直しが必要になります。回路変更に合わせてドライバやレジスタ設定を書き直す作業は、見積もりに織り込みにくい典型例です。変更の影響範囲が広いほど、やり直しにかかる工数も膨らみます。

こうした制約は、組み込み開発ならではの事情です。ハードとソフトの開発が並行して進む前提を、見積もりの段階から明記しておく必要があります。前提を共有しておけば、遅延が発生した際にも見積もりを見直す判断がしやすくなります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

評価・検証工数が最も読みにくい理由

コーディングが終わった後の評価・検証工程は、組み込み開発の見積もりの中でも特に不確実性が高い領域です。ここを甘く見積もると、後工程全体に影響が広がります。

• 実機不足によるテストの直列化：試作機の台数が不足していると、複数のテスト項目を並行して進められず、テストが直列に並びます。台数が少ないほど、評価工程全体の所要期間は長くなります。複数のチームが同じ実機を使い回す場合は、順番待ちの時間も見積もりに含める必要があります。
• 不具合の再現条件の特定に時間がかかる：特定のタイミングでしか発生しない不具合や、温度や振動といった環境条件に依存する不具合は、原因究明に想定以上の時間を要します。再現条件を絞り込む作業自体が、評価工程の工数を押し上げます。
• デバッグ工数は経験に依存する：デバッグに必要な工数は、担当者が似た不具合を過去に経験しているかどうかで大きく変わります。このため、デバッグ工数は見積もり項目の中でも最も外れやすい部分です。経験の浅い担当者が多いプロジェクトほど、この不確実性は大きくなります。

評価・検証工程で何を確認するかは、工程ごとに整理すると見通しがよくなります（「V字モデルで学ぶテスト工程と品質保証」参照）。工程を分けておくと、どこに不確実性が集中しているかを把握しやすくなります。

コーディング工数だけを見積もる典型的な失敗

工数見積もりで見られる典型的な失敗は、コーディングにかかる工数だけを積み上げてしまうことです。開発の初期段階では、コーディング以外の工程が見えにくいことが背景にあります。

• テストの工数を軽視する：テスト設計や実施の工数を、コーディングに付随する軽い作業として見積もるケースが目立ちます。組み込みソフトでは、実機を使った試験に想定以上の時間がかかります（「自動テストのメリットと役割分担」参照）。手動での確認に頼る項目が多いほど、この傾向は強まります。
• デバッグの工数を過小に見込む：デバッグは、不具合が見つかってはじめて発生する作業です。事前に件数や深刻度を正確に予測するのは難しく、過小に見積もられがちです。過去のプロジェクトで発生した不具合の傾向を参考にすると、ある程度の見当はつけられます。
• ドキュメント作成の工数を見落とす：仕様変更のたびに設計書やテスト仕様書を更新する作業には、地味ながら一定の工数がかかります。更新を後回しにすると、次のプロジェクトで過去資料を参照できなくなります。
• レビューの工数を省略する：コードレビューや設計レビューを省略すると、後工程での手戻りが増え、結果として総工数が膨らみます。レビューにかかる時間は短く見えても、手戻りの防止効果は大きいものです。

コーディング以外の工程を軽視すると、見積もりと実績の差が大きくなります。工程ごとに工数を分けて記録しておくと、抜け漏れを防ぎやすくなります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

見積もり精度を上げる実務のポイント

見積もりの精度を高めるには、手法の選択以上に、日々の運用が重要です。ここでは、明日から実践できる四つのポイントを挙げます。

• 過去実績を記録する：類推法やパラメトリック法は、いずれも過去実績のデータがあってはじめて精度が高まります。プロジェクトごとの実績工数を、工程別に残しておきます。記録が蓄積するほど、次回以降の見積もりの根拠が明確になります。
• 工程別に分けて積み上げる：設計、実装、評価・検証、ドキュメント作成、レビューといった工程ごとに分けて見積もります。一括りで見積もると、どの工程で差異が生じたかが分からなくなります。工程別に分けておけば、次のプロジェクトへの反映もしやすくなります。
• 不確実性の高い項目にバッファを置く：ハードウェアの試作スケジュールや評価工程は、特に不確実性が高い項目です。これらの項目に優先してバッファを確保しておきます。バッファを設けた根拠もあわせて記録しておくと、次回の見積もりに活かせます。
• 前提条件を明記する：試作基板をいつ入手できるか、実機を何台用意できるかといった前提を明示しておきます。前提が崩れた際に、見積もりを見直す判断がしやすくなります。前提を関係者と共有しておけば、認識のずれも防げます。

見積もりは「当てる」ものではなく「前提を明示した仮説」

工数見積もりを、実績と完全に一致させる作業だと捉えると、無理が生じます。組み込み開発では、ハードウェアの都合による不確実性を排除できないためです。見積もりの精度だけを追い求めても、根本的な解決にはつながりません。

見積もりは、その時点で判明している前提条件のもとで導き出した仮説として扱う姿勢が現実的です。前提が変わった時点で見積もりを見直し、関係者と共有しなおすことが、精度を維持するうえで欠かせません。仮説として扱う姿勢は、見積もりの誤差を非難の対象にしないという点でも有効です。

評価・検証の工数を圧縮する余地は、テスト環境の整備によって生まれます。実機を使った試験の一部を、テスト自動化や疑似的な検証環境に置き換えれば、実機不足によるテストの直列化を緩和できます。単体テストのしやすさを設計段階から意識しておくことも、評価工数の見通しを立てやすくします（「開発に求められる品質と信頼性」参照）。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

組み込み開発の工数見積もりは、コーディング工数の積み上げだけでは精度が上がりません。ハードウェアの試作スケジュールや評価・検証工程の不確実性を前提条件として明示し、不確実性の高い項目にバッファを織り込むことが実務の要点です。見積もりを仮説として扱い、前提の変化に応じて見直す姿勢が、精度向上につながります。