LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

組込み/ファームウェア開発の外注とは

組込みシステム・ファームウェア開発の外注とは、マイコン（マイクロコントローラ）や産業機器・車載システムなどに搭載されるソフトウェアの設計・実装・検証工程を、専門知識を持つ外部パートナーに委託する形態です。Web系やモバイルアプリ開発と異なり、C/C++言語やRTOS（リアルタイムOS：マイコン上でタスクをミリ秒単位で制御するOSの総称）、コーディング規約（MISRA Cなど）への対応が求められます。

組込みソフトウェアとファームウェアの違い

「組込みソフトウェア」は産業機器・医療機器・車載システムなど特定ハードウェアに搭載されるソフトウェア全般を指します。「ファームウェア」はその中でも、ROMやフラッシュメモリに書き込まれてハードウェアを直接制御するプログラムを指します。

外注の実務では両者を明確に区別することが重要です。ファームウェアはハードウェア仕様と密結合しているため、回路図・データシートの共有なしに開発を外注することはできません。委託先が「ハード寄りの低レイヤー開発」と「OS上のアプリケーション層開発」のどちらを得意とするかを事前に確認する必要があります。

外注が増える背景 — IoT普及と人材確保の課題

IPA（独立行政法人情報処理推進機構）が2022年11〜12月に国内組込み/IoT関連企業1,214社を対象に実施した「2022年度組込み/IoT産業の動向把握等に関する調査」（2023年6月公開）によると、事業上の課題として「人材の確保・強化」を挙げた企業は68%に上りました^*1。

同調査で「外部専門家の活用」を実施中と回答した企業は26%にとどまっており^*1、人材確保に課題を感じながらも外部委託を十分に活用できていない企業が多いことがわかります。IoT機器の普及と製品の高機能化でファームウェア規模が拡大している一方、組込みエンジニアは希少であり、外注によって開発力を補完する動きが加速しています。

費用相場の目安と見積もり構造

組込み/ファームウェア開発の外注費用は「人月単価 × 工数 × 期間」で算出します。Web系開発との大きな違いは、ハードウェアとの密結合・リアルタイム性・安全性要件により専門性が高く、エンジニアの市場単価が上振れしやすい点です。

人月単価の目安（市場参考値）

以下は開発会社向け情報サイト等を参考にした市場参考値です。一次資料ではなく目安として活用してください。

上表は開発情報サイト等の掲載値を参考に整理した市場参考値であり、一次統計資料ではありません。実際の発注では複数社から相見積もりを取り、要件規模・規格対応・保守範囲を明確にしたうえで比較することが大切です。

規模・フェーズ別の工数と費用イメージ

開発規模によって費用は大きく変わります。少規模なマイコン制御（センサー読み取り・LED制御程度）であれば数名・数か月で完結しますが、ASIL（自動車安全度水準）対応が必要な車載ファームウェアや、通信スタック・OTAアップデート機能を含む複雑な開発では、長期にわたる体制が必要になります。

費用の計算式は「人月単価 × 人数 × 期間（月）」が基本です。たとえばSE1名＋プログラマー2名の3名体制で6か月間開発する場合の試算は、上記単価を参考にすると相当の費用規模になります。実際のプロジェクトでは、上流設計・実装・テスト・ドキュメント整備の各フェーズに人員が分散するため、総費用は事前の詳細見積もりで確認することが不可欠です。

費用を左右する5つの要因

• 規格・認証対応の有無：MISRA C準拠・ISO 26262 ASIL認証が必要な場合、テストエビデンス作成・静的解析ツール費用が加算されます
• ハードウェアとの連携深度：回路設計から一貫して委託するほど調整コストが増え、独自ペリフェラル（周辺回路）が多いほどドライバ開発工数が積み上がります
• リアルタイム性・安全性の要求水準：RTOSの有無・割り込み処理の複雑さ・フェイルセーフ設計の有無が工数を変動させます
• ドキュメント成果物の範囲：仕様書・テスト仕様・コードレビュー記録まで納品物に含める場合、工数が増加します
• 保守・サポート体制：量産後のOTAアップデート対応・バグ修正の長期サポートを含めるかで総コストが変わります

規格・品質基準が委託先選定の鍵

組込み/ファームウェア開発の外注において、Web開発とは異なる重要な確認事項が規格対応力です。安全性・信頼性が求められる機器に搭載されるソフトウェアには、業界固有のコーディング標準・機能安全規格が適用されます。委託先がこれらを正しく実装できるかどうかが、納品物の品質を大きく左右します。

MISRA C:2012とIPA ESCRの役割

MISRA（Motor Industry Software Reliability Association：英国の自動車ソフトウェア業界団体）が策定した「MISRA C」は、セーフティクリティカルな組込みシステムにおけるC言語コーディングのガイドラインです。1998年の初版から改訂が重ねられ、現行版は2012年改訂のMISRA C:2012です^*2。自動車のみならず航空宇宙・医療機器・産業制御など幅広い組込みシステムで採用されており、「コードの堅牢性・保守性・移植性の向上」を目的としています。

国内では、IPA（独立行政法人情報処理推進機構）のソフトウェア・エンジニアリング・センター（SEC）が「組込みソフトウェア開発向けコーディング作法ガイド ESCR Ver.3.0」（2018年改訂）を公開しています^*3。MISRA Cと並んで国内組込み開発の品質基準として参照されており、CERTコーディング標準・脆弱性対策ルールも取り込まれています。委託先がこれらのガイドラインに準拠した開発ができるかを確認することが大切です。

機能安全ISO 26262が求める開発プロセス

自動車用電気・電子システムを対象にした機能安全規格「ISO 26262」は2011年に国際標準化機構（ISO）により制定されました^*4。安全機能の不全によるハザード（危害要因）のリスクを、仕様定義から廃棄まで全ライフサイクルにわたって管理するプロセスを規定しています。

ISO 26262の核心は「ASIL（Automotive Safety Integrity Level：自動車安全度水準）」という4段階のリスク分類です^*4。重大度・曝露確率・制御可能性の3変数に基づいてA〜Dの4段階で分類され、エアバッグやABSはASIL D（4段階中で最も厳格な水準）、ヘッドライト制御はASIL B相当とされています。ASILが上がるほど開発・検証の厳格さが求められ、外注先のISO 26262対応実績は車載向けファームウェア発注の重要な確認事項です。

テストエビデンスとトレーサビリティ

組込み開発の品質保証では、要件から実装・テストケースまでを追跡可能にする「トレーサビリティ」が重要です。規格対応プロジェクトでは要件定義書・設計書・テスト仕様書・静的解析レポートが一貫して対応付けられたドキュメント一式が成果物として求められます。

HIL（Hardware-in-the-Loop：実際のハードウェアを接続したシミュレーションテスト）やカバレッジ計測ツールの活用実績も委託先選定の参考になります。テストエビデンスが不十分なまま量産に移行すると、後から不具合が発覚した際の原因追跡と是正が困難になります。

委託先選定で確認すべき7つのポイント

実績のある委託先を選ぶ際には、技術力だけでなく契約・体制・コミュニケーション面の確認が不可欠です。以下の7点を事前に確認することで、外注後のトラブルを予防できます。

技術・実績面の確認事項

1. 対応言語・RTOS・マイコンの実績：C/C++はもちろん、プロジェクトで使用するRTOS（FreeRTOS・TOPPERS・μITRONなど）やマイコンファミリー（Renesas RL78/RXシリーズ・ST STM32・NXP i.MXなど）の開発経験を確認します。特定プラットフォームの経験がないベンダーに委託すると、習熟コストがそのまま見積もりに乗ってきます。

2. 規格対応・認証取得実績：MISRA C準拠経験・ISO 26262対応プロジェクト実績・静的解析ツール（PC-lint・Polyspace等）の使用実績を確認します。IEC 62443（産業用制御システムのサイバーセキュリティ規格）対応が必要なIoT機器開発では、その対応実績も確認が必要です。

3. 同業界への納入実績：自動車・医療・産業機器・家電など、同業界への納入経験があるベンダーは業界固有の制約・規制を理解しています。十数年にわたる取引実績がある場合は品質の安定性の参考になります。

契約・知財・体制面の確認事項

4. ソースコードの帰属と開示範囲：開発委託では「ソースコードの著作権が委託先に残るのか、発注者に帰属するのか」を契約で明確にする必要があります。保守・改修を将来自社で行う場合や別ベンダーに引き継ぐ場合、ソースコードの開示・譲渡条件が定まっていないとベンダーロックインが発生します。

5. 秘密保持契約（NDA）の範囲：ファームウェア開発では回路図・製品仕様・製造プロセスなど機密性の高い情報を共有します。NDAの対象範囲・期間・再委託先への適用可否を事前に確認します。再委託先（孫請け）の管理体制も発注者が把握できる状態が望ましいです。

6. プロジェクト管理・進捗報告の方法：週次の進捗報告・課題管理ツールの共有・マイルストーンごとのレビュー実施などを契約前に合意します。組込み開発は仕様変更や部品変更が発生しやすく、変更管理プロセスが機能していない委託先では工期超過のリスクが高まります。

7. 瑕疵担保・保証期間の範囲：量産後に発覚したバグへの対応範囲・期間をあらかじめ定めておきます。量産後の不具合は影響範囲が広く、修正費用・リコール対応コストが大きくなるため、保証条件の明確化は発注者保護の観点から特に重要です。

内製と外注の失敗コスト比較

組込み/ファームウェア開発を内製するか外注するかは、技術スタックの保有状況と開発スケジュールによって判断が変わります。内製・外注それぞれに固有のリスクがあり、正確に把握したうえで意思決定する必要があります。

内製リスク — スキルギャップと工数超過

組込み開発を内製しようとした場合、まず必要なのはC/C++・RTOS・低レイヤーデバッグ・規格（MISRA C・ISO 26262等）に精通したエンジニアの確保です。前述のIPA調査^*1では、組込み/IoT業界の企業の68%が「人材の確保・強化」を課題としています。

採用に着手してから即戦力が確保できるまでの期間は、専門性の高い組込みエンジニアでは半年以上を要することがあります。開発スケジュールが決まっている製品リリースに間に合わせるには、採用ではなく外注で迅速に体制を整えることが現実的な選択肢になります。

また、自社エンジニアが組込み開発を初めて経験する場合、規格対応やデバッグ手法の習熟に時間が取られ、当初の工数見積もりを超過するリスクがあります。特にリアルタイム処理のデバッグは難易度が高く、経験の浅いエンジニアが担当すると解決までに多大な時間を費やすことがあります。

外注リスクと回避策 — 仕様の曖昧さとベンダーロック

外注の失敗要因として最も多いのは「要件・仕様の曖昧さ」です。組込みソフトウェアはハードウェア仕様と密接に結びついているため、回路の変更・センサー仕様の更新・動作環境の変化が発生するたびにソフトウェアへの影響を評価しなければなりません。仕様変更の都度、発注者と委託先間での認識合わせが不十分だと、手戻りが発生して費用・工期が膨らみます。

回避策は「仕様凍結のタイミングと変更管理手順を契約前に定める」ことです。変更要求の都度、影響範囲・追加費用・工期への影響を文書で合意するプロセスを確立しておくことで、予算超過を防止できます。

ベンダーロックインは「ソースコードを委託先が保持したまま保守継続を余儀なくされる」状態です。初期費用を抑えるために契約条件を曖昧にしたまま発注すると、後から高額な保守費用を請求されるケースがあります。前節で触れた「ソースコード帰属の明記」と「ドキュメント一式の納品」が対策の基本です。

まとめ：外注判断の3つの軸

本稿では、組込み/ファームウェア開発の外注について費用相場・規格対応・委託先選定の注意点を整理しました。要点を3つの軸にまとめると次のとおりです。

第一に、費用は「人月単価 × 人数 × 期間」で試算できます。規格対応・ハードウェア連携の複雑さ・ドキュメント範囲によって大きく変動するため、複数社から詳細見積もりを取ることが重要です。

第二に、委託先の品質を見極める核心はMISRA C:2012・ISO 26262（機能安全）・IPA ESCRへの対応実績です。セーフティクリティカルな用途では、規格対応力と静的解析ツールの活用実績を確認することが大切です。

第三に、契約段階でソースコード帰属・NDA範囲・瑕疵担保を明確にしておくことで、ベンダーロックインや納品後トラブルを防止できます。外注成功の鍵は技術選定だけでなく、契約設計にあります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA（独立行政法人情報処理推進機構）「2022年度組込み/IoT産業の動向把握等に関する調査」（2023年6月公開、n=1,214）
2. *2　出典：Synopsys「MISRAとは？ガイドラインと準拠のポイント」（2024年参照）
3. *3　出典：IPA SEC「組込みソフトウェア開発向けコーディング作法ガイド ESCR Ver.3.0」（2018年改訂）
4. *4　出典：マクニカ組込み技術ラボ「自動車機能安全規格ISO 26262とは」（2024年8月30日公開）および Synopsys「ISO 26262機能安全規格とは」（2024年参照）

Tweet