組み込みエンジニアを業務委託で確保する方法｜IoT開発の発注設計

新製品の量産開始時期は経営会議で決まってしまった。けれども無線通信スタックとクラウド連携のファームウェアを書ける人がいない。正社員の求人は 1 年出し続けても応募がほとんど来ない。組み込みソフトの開発責任者が業務委託という選択肢を検討し始めるのは、たいていこういう場面です。

ところが情報を集め始めると、すぐに壁に当たります。世の中にある「組み込みエンジニアの業務委託」の記事は、フリーランス側が案件を取るための情報か、開発会社に一式を外注するときの費用相場のどちらかに偏っています。発注する側が個人の組み込みエンジニアに仕事を頼むとき、いちばん知りたいのはそこではありません。自社の開発のどこまでなら社外の人に渡せるのか、そして評価ボードもオシロスコープも社内にしかない状態で、その人はどうやって動作を確認するのかです。

この 2 つが決まらないまま募集要項を書こうとすると、「組み込み開発全般」といった曖昧な依頼になり、応募が来ないか、来ても要件がかみ合わずに立ち上がりません。逆にこの 2 つさえ設計できれば、社内に 2 名しかいない体制でも外部人材を戦力にできます。

本記事では、IoT機器開発を 5 つの層に分解して外部委託しやすさを格付けする方法、実機がないと進まない作業を回すための 4 つの運用パターン、公開データに基づく単価レンジと発注側から見た総コスト、請負契約と準委任契約の選び分け、スキルの見極め方、そして機密保持と引き継ぎまでを、発注者の立場で順に整理します。最後に、そのまま社内稟議と募集要項に転記できるチェックリストをまとめます。

組み込みエンジニアを業務委託で確保する企業が増えている理由

まず、業務委託という選択が「正社員を採れなかったから仕方なく」という妥協ではなく、構造的に合理的な手段になっている背景を押さえておきます。ここが整理できていないと、稟議で「なぜ採用ではないのか」を説明できません。

組み込みエンジニアの採用難は求人倍率の数字で見るとどうか

IT人材の不足は個別企業の努力の問題ではなく、母集団そのものが縮んでいる構造的な問題です。経済産業省の「IT人材需給に関する調査」では、IT人材は 2030 年時点で中位シナリオでも約 45 万人、需要の伸びが大きいシナリオでは最大約 79 万人が不足すると試算されています（経済産業省「IT人材需給に関する調査」概要、2019年4月）。

組み込み分野は、この全体的な不足に加えてさらに条件が厳しくなります。理由は 3 つあります。

• 母集団が小さい: Web・業務システムの開発者に比べ、C/C++ でハードウェアを直接触ってきた技術者の絶対数が少ない
• 需要が増えている: 車載の電動化、産業機器の IoT 化、電池駆動デバイスの普及によって、無線通信と省電力制御を扱える人の求人が増え続けている
• 地域が偏る: 製造業の開発拠点は地方の事業所にあることが多く、通勤圏の候補者だけを対象にすると母集団がさらに小さくなる

つまり、求人を出しても応募が来ないのは募集条件の書き方だけの問題ではありません。通勤圏という制約を外さない限り、そもそも候補者が視界に入らない構造になっています。業務委託でリモートを前提にすると、この地理的制約を外せるのが最大の効果です。

正社員採用・受託開発会社・業務委託を立ち上がり速度とコスト構造で比べる

3 つの選択肢は「どれが優れているか」ではなく、何を確保したいかで使い分けます。

業務委託が効くのは「社内にハード設計と製品仕様の知見はあるが、ソフトの特定領域だけが欠けている」という状態です。今回のような、回路は自社で引けるが無線とクラウド連携のファームウェアだけが書けない、という体制はまさにこれに当てはまります。

一方で、社内に仕様を説明できる人が誰もいない場合は、個人への業務委託は機能しません。その場合は受託開発会社への一括外注のほうが安全です。判断の目安は「委託先からの質問に、社内の誰かが 1 営業日以内に答えられるか」です。

業務委託でも「すぐ埋まる職種ではない」という前提

ここは先回りしてお伝えしておきます。業務委託にしたからといって、翌週から人が稼働するわけではありません。組み込みは Web 系に比べてフリーランス人口自体が少なく、募集を出してから候補者が集まるまでに数週間かかることは珍しくありません。

そのうえ、スキルの一致条件が細かい分野です。「組み込みができます」という人でも、車載の制御系が専門の人と、BLE デバイスのファームウェアが専門の人では、任せられる作業の範囲が大きく違います。募集の粒度が粗いほどミスマッチが起きやすく、結果として立ち上がりが遅れます。

だからこそ、次に説明する「切り出し」の設計が先に必要になります。何を頼むかが具体的に書けていれば、母集団が小さくても該当する人には確実に刺さります。逆に曖昧なままだと、母集団の小ささがそのまま応募ゼロにつながります。

IoT機器開発の業務を「外部委託できる単位」に分解する

ここが本記事の中核です。組み込み開発を一枚岩の「開発」として扱っている限り、外部に渡せる部分は見えてきません。まず層に分けて、層ごとに外に出せるかどうかを判定します。

IoT機器開発を構成する5つの層

センサー機器とクラウドが連携する典型的な IoT 機器開発は、次の 5 層に分けられます。

1. デバイスファームウェア（アプリケーション層）: 製品としての振る舞いを決める部分。状態遷移、設定の保持、スリープ復帰の制御、OTA アップデートの適用処理など
2. デバイスドライバ・ハード密結合部: MCU のペリフェラル制御、センサー IC との通信（I2C・SPI）、電源制御、割り込み処理など、回路と一体で動く部分
3. ゲートウェイ・通信処理: BLE・Wi-Fi・LTE-M などの通信スタックの利用、接続再確立、再送とバッファリング、省電力を考慮した送信スケジューリング
4. クラウド連携・バックエンド: MQTT / HTTPS でのデータ送信、デバイス管理、受信データの蓄積・可視化、認証と鍵管理
5. 評価・テスト・量産支援: 試験仕様の作成と実施、治具用ソフト、書き込みツール、認証試験（技適・EMC 等）に向けた確認作業

ファームウェア開発を外注するとき、多くの企業は 1 と 2 をまとめて「ファームウェア」と呼びます。しかしこの 2 つは外部委託のしやすさがまったく違います。分けて考えることが、切り出し設計の第一歩です。

層ごとの「外部委託しやすさ」を3軸で格付けする

各層を、実機依存度（実物がないと作業が進まない度合い）、仕様変動リスク（ハード都合で後から仕様が動く度合い）、社内知識依存度（社内の暗黙知がないと判断できない度合い）の 3 軸で評価します。

格付けの理由は次のとおりです。

• クラウド連携が最も切り出しやすい理由は、インターフェース（送るデータの形式と頻度）さえ決めればデバイスの実物がなくても開発でき、モックのデバイスシミュレータで検証が完結するためです
• 通信処理が次に切り出しやすいのは、評価ボード 1 台を貸与すれば大部分の検証ができるためです。通信規格の知識は社外に蓄積されており、社内の暗黙知への依存が小さいのも利点です
• ハード密結合部が最も難しいのは、回路の意図・部品選定の経緯・過去の不具合対策といった社内の文脈がないと判断できない場面が多く、しかも波形を見ないと切り分けられない不具合が発生するためです

最初に切り出すべき層・最後まで社内に残すべき層

以上を踏まえた実務的な進め方は次のとおりです。

最初に切り出す: クラウド連携・バックエンド（層 4）と通信処理（層 3）。この 2 つは実機依存度が低く、インターフェースを文書で定義すれば独立して進みます。社内の限られた組み込み技術者を、ハードに近い層へ集中させる効果もあります。

次に検討する: デバイスファームウェアのアプリケーション層（層 1）。ここは製品仕様の理解が必要なため、委託先が製品の全体像を掴んだあと、2 期目以降のスコープに広げるのが現実的です。

社内に残す: ハード密結合部（層 2）と、量産に直結する評価・治具まわり（層 5）。この 2 つは回路設計者との距離が近いほど早く回ります。社内の 2 名をここに配置し、外部人材には上の層を任せる形が、限られた体制で最も破綻しにくい配置です。

なお、これは「外部の人にハード密結合部を任せてはいけない」という意味ではありません。委託先が数ヶ月稼働して社内の文脈を掴み、実機がある環境で作業できるようになれば、層 2 に踏み込むことは十分可能です。順序の問題として、最初から一番難しい層を渡さないという話です。

切り出し単位を募集要項の文面に落とす書き方

層の切り分けができたら、そのまま募集要項に翻訳します。組み込み案件で応募が集まらない募集は、たいてい次のような書き方になっています。

【NG例】IoT製品の組み込み開発全般。C言語での開発経験がある方。

これでは、候補者は自分が該当するかどうかを判断できません。次のように、層・ターゲット・環境・成果物の 4 点を具体的に書きます。

【改善例】センサー機器（電池駆動・BLE 接続）のクラウド連携部およびゲートウェイ通信処理の開発をお願いします。

• 担当範囲: MQTT によるデータ送信処理、接続断時の再送・バッファリング、送信スケジューリングの実装
• 想定環境: MCU は nRF52 系、RTOS は FreeRTOS、クラウドは AWS IoT Core
• 実機の扱い: 評価ボードを貸与します（郵送）。試作機での確認は月 1 回の来訪、または開発担当とのリモートセッションで対応
• 成果物: ソースコード、ビルド手順書、単体試験の実施記録
• 稼働: 週 2〜3 日相当、6 ヶ月（延長の可能性あり）

この粒度で書けていると、候補者側は自分の経験が合致するかを即座に判断できます。そして重要なのは、この文面は層の格付け表があれば機械的に書けるという点です。募集要項が書けないのは文章力の問題ではなく、切り出しが決まっていないことの結果です。

実機・治具・ラボの制約をどう発注設計に織り込むか

組み込み開発の外部委託が Web 系と決定的に違うのが、この物理制約です。ここを設計に織り込まないまま契約すると、稼働開始後に「作業が進まない」という形で顕在化します。

組み込み開発でリモート委託が止まる典型的な場面

開発が止まるのは、次のような場面です。

• ファームウェアを書いたが、書き込む実機が委託先の手元にない
• 通信が切れる不具合が出たが、ロジックアナライザやオシロスコープがないと信号レベルで切り分けられない
• 消費電流を測って省電力設計を検証したいが、電流計測環境が社内にしかない
• 試作機が 3 台しかなく、社内の評価担当と取り合いになる
• ハードのリビジョンが上がり、委託先が持っている旧基板では再現しない

共通しているのは、「コードは書けるが、動作を確認できない」という状態です。この状態が続くと委託先の生産性は大きく落ち、結果的に単価に見合わない成果しか出ません。したがって、契約前に「この人は何を使ってどう確認するのか」を決めておく必要があります。

実機制約を回避する4つの運用パターン

現実的な選択肢は 4 つあります。組み合わせて使うのが基本です。

判断の順序としては、まず D で実機なしに進められる範囲を最大化し、次に A で手元検証できる範囲を広げ、それでも残る「波形を見ないと分からない作業」を C で吸収する、という組み立てが無理がありません。B は初期構築の手間が大きいため、試作機の台数がどうしても増やせない場合や、装置が大きくて郵送できない場合の選択肢と考えてください。

なお、A を選ぶ場合は評価ボードの台数を必要数より 1〜2 台多く確保しておくことをおすすめします。委託先の手元で 1 台壊れると、代替品が届くまで稼働が完全に止まるためです。台数の余裕は、単価交渉よりも投資対効果が高い部分です。

機材貸与時に決めておく取り決め

評価ボードや試作機を社外に出す以上、契約書または覚書で次の点を明文化しておきます。ここが曖昧だと、返却時や破損時にトラブルになります。

• 貸与物の特定: 品目・数量・シリアル番号・貸与日を一覧にする（試作機は資産管理台帳に載っていないことが多いため、別紙で管理する）
• 返却時期と方法: 契約終了日から何営業日以内に、どの方法で返却するか
• 破損・故障時の扱い: 通常の使用による故障は発注者負担、故意・重過失は委託先負担、といった線引き
• 持ち出し・第三者への開示の禁止: 貸与機材を第三者に見せない・貸さないこと。分解・リバースエンジニアリングの可否
• 写真・映像の扱い: 試作機の外観や基板の写真を SNS 等に掲載しないこと（意外に見落とされますが、量産前の製品では重要です）

組み込みエンジニアの業務委託単価相場と発注側の総コスト

稟議で最初に問われるのが金額です。ここでは公開データで単価レンジを押さえたうえで、月額単価には表れない発注側のコストを積み上げます。

公開データで見る組み込みエンジニアの業務委託単価レンジ

フリーランス案件の公開データを見ると、組込・制御分野の平均単価は月額 67 万円、最高単価は 185 万円という水準が示されています（レバテックフリーランス「単価相場」）。案件データベース上では、週 5 日・月 140〜180 時間の常駐案件で月額 50〜70 万円台のレンジが多く提示されています（フリーランススタート「組み込み・制御のフリーランス案件・求人」）。

注意していただきたいのは、これらが週 5 日フル稼働を前提とした月額である点です。組み込みの外部委託では週 2〜3 日の部分稼働で契約するケースも多く、その場合の月額はおおむね稼働率に比例します。週 3 日なら平均単価の 6 割程度、つまり月 40 万円前後が出発点の目安になります。

また、これらの数値はエージェント経由の案件が中心です。マッチングプラットフォームでの直接契約では、中間マージンが乗らない分だけ発注側の支払額は下がる傾向がありますが、そのぶん候補者の選定と契約実務は自社で担うことになります。

単価を左右する要因（RTOS・無線・安全規格・量産経験）

同じ「組み込みエンジニア」でも、次の要素の有無で単価は大きく変わります。募集要件を設計するとき、どこまでを必須にするかで予算が決まると考えてください。

予算が限られている場合、「量産経験あり」と「回路図が読める」の 2 つは残し、それ以外は妥協の候補になります。逆に、この 2 つを外して単価を下げると、後工程で社内の負担が増えて総コストは上がりやすくなります。

月額単価に載ってこない発注側コストを積む

稟議書に書くべきは月額単価ではなく、次を含めた総コストです。

とくに見落とされやすいのが社内対応工数です。外部委託は社内工数をゼロにする施策ではなく、社内の技術者の時間を「実装」から「判断と受け入れ」に振り替える施策です。ここを見込まずに社内担当者を別プロジェクトへ 100% アサインすると、委託先が質問待ちで止まります。

個人への業務委託と開発会社への一括外注はどちらが安いか

比較の前提を揃えておきます。開発会社への一括外注では、外注費の市場参考値として小規模な PoC で数百万円程度、本番向けシステム一式では数千万円以上になるケースもあると紹介されています（IoTシステム開発の外注費用と進め方 - LASSIC）。一方で、IoT を用いたシステムを 1 から開発する場合の目安を数十万円〜数百万円とする解説もあり（発注ラウンジ「IoTシステム開発にかかる費用」）、想定する規模と検証範囲によってレンジは大きく振れます。費用の内訳や段階的な進め方については、IoTとは？発注者が押さえる判断軸5つでも整理しています。

金額の絶対値だけを見れば個人への業務委託のほうが小さくなりますが、次の点を含めて比較してください。

「どちらが安いか」の答えは、社内に管理できる人がいるかどうかで変わります。社内担当が週数時間を割ける状態なら個人への業務委託が費用対効果で優位に立ちます。担当者が別業務でふさがっているなら、管理費を払って一括外注したほうが結果的に安く済みます。

請負契約と準委任契約のどちらを選ぶか

契約形態は、法務の形式論ではなく「仕様が動くかどうか」で決まります。組み込み開発はハード都合で仕様が動きやすい分野なので、ここを間違えるとトラブルの温床になります。

請負契約と準委任契約の違いを報酬発生条件で押さえる

2 つの違いは、報酬がいつ発生するかに集約されます。

見落とされやすいのが、準委任契約でも発注者が直接の指揮命令を行うことはできないという点です。「準委任なら常駐させて細かく指示できる」という理解は誤りで、それは後述する偽装請負の問題に直結します。

組み込み開発でどちらを選ぶかの判断フロー

次の 2 つの問いで判断できます。

問1: ハードの都合で仕様が動く可能性が高いか

基板のリビジョンが上がる、部品が変更になる、消費電流の実測値によって制御方針を見直す、といった可能性がある場合は「はい」です。この場合は準委任契約を選びます。請負にすると、仕様変更のたびに契約変更と追加見積が必要になり、スケジュールが止まります。

問2: 成果物を検収基準として文書に書けるか

「BLE 接続の再送処理を実装」ではなく、「電波遮断 30 秒後に再接続し、遮断中のデータを欠損なく送信できること。試験手順は別紙のとおり」というレベルで書けるなら「はい」です。ここまで書けて、かつ問1が「いいえ」なら請負契約が成立します。

実務上、組み込み開発の初期フェーズはほぼ準委任契約が適します。仕様が固まった量産直前の追加開発や、独立性の高いツール開発（治具用ソフト、書き込みツールなど）は請負契約に向きます。IoT を含む開発案件で契約形態を選び分ける具体的な進め方は、IoT開発の外部委託と契約形態でも扱っています。

偽装請負にしないための日常運用

準委任契約や請負契約で外部人材が社内に出入りする場合、実態が労働者派遣に該当していないかが問われます。労働者派遣と請負の区分は契約書の名称ではなく実態で判断され、その基準は「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和 61 年労働省告示第 37 号）に示されています。厚生労働省は具体的な場面に即した疑義応答集も公開しています。

日常の運用で気をつける点は次のとおりです。

• 作業時間を指定しない: 「9 時から 18 時まで在席」といった勤務時間の指定や勤怠管理を行わない
• 作業指示を直接下達しない: 個別のタスクを逐一指示するのではなく、依頼は業務の単位で行い、進め方は委託先の裁量に委ねる
• 業務命令とレビューを区別する: 成果物に対する確認・指摘は問題ありませんが、作業手順そのものを指図すると指揮命令に近づきます
• 社内の朝礼・当番等に組み入れない: 自社従業員と同じ服務規律の対象にしない
• 稼働報告は成果ベースで受け取る: 「何時から何時まで働いたか」ではなく「何を進めたか」を報告してもらう

ハイブリッド稼働で社内のラボに来てもらう場合、この線引きが曖昧になりやすいので注意が必要です。来訪時も「発注者の設備を使い、自らの裁量で作業する」という形を維持してください。

ソースコード・設計資産の権利帰属を契約書でどう書くか

組み込み開発では、成果物の権利関係を曖昧にしたまま進めると、量産後の保守で困ります。契約書で次の点を明記します。

• 著作権の帰属: 成果物の著作権を発注者に譲渡するか、利用許諾にとどめるか。譲渡とする場合は著作者人格権の不行使も併せて定める
• 委託先が持ち込む既存資産の扱い: 委託先が従来から保有しているライブラリやツールを流用する場合、その部分は譲渡対象外として利用範囲を定める（この整理を怠ると、後から使えなくなる可能性があります）
• OSS の扱い: 使用した OSS のライセンスと組み込み箇所を一覧で提出してもらう。GPL 系ライセンスの混入は製品出荷後に致命的になるため、事前に禁止範囲を伝えておく
• 回路情報・仕様書の取り扱い: 発注者が提供した回路図・仕様書の権利は発注者に留保され、契約終了時に返却または消去する旨を定める
• 第三者の権利侵害がないことの表明: 成果物が第三者の知的財産権を侵害していないことを委託先に表明してもらう

なお、フリーランス（従業員を使用しない個人）に業務委託する場合は、2024 年 11 月 1 日に施行された「フリーランス・事業者間取引適正化等法」の対象になります。この法律では、業務委託時に書面等で取引条件を明示すること、成果物を受け取った日から 60 日以内のできる限り早い日に報酬支払期日を設定し期日内に支払うことなどが発注事業者の義務とされています（政府広報オンライン、公正取引委員会・中小企業庁パンフレット）。支払サイトが月末締め翌々月払いになっている企業は、この点を事前に確認しておくことをおすすめします。

組み込みエンジニアの発注チャネル比較とスキルの見極め方

切り出しと契約形態が決まったら、次は探し方と見極め方です。ここは「ソフトが分からないと選べない」と感じられる部分ですが、判断の手順に落とせば発注担当者だけでも進められます。

組み込みエンジニアを探せる5つのチャネルと向き不向き

組み込みの場合、どのチャネルでも共通して効くのが募集内容の具体性です。前述のとおり、ターゲット MCU・RTOS・通信規格まで書いた募集は母集団が小さくても該当者に届きます。逆に「組み込み開発全般」ではどのチャネルを使っても反応が薄くなります。

指揮命令が必要な作業（社内の他メンバーと一体で動く、作業内容が日々変わる）が主体なら、業務委託ではなく技術者派遣を選ぶべきです。契約形態と実態を一致させることが、結局はいちばん安全です。

経歴書から量産経験を読み取るチェック項目

ソフトの技術面接ができなくても、経歴書からは多くのことが読み取れます。次の観点で確認してください。

• 担当フェーズはどこまでか: 「試作・PoC まで」で終わっている経歴と、「量産立ち上げ・出荷後の不具合対応まで」の経歴では、任せられる範囲がまったく違います。量産を経験している人は、歩留まりや個体差といった観点を持っています
• ターゲット MCU が一致するか: STM32・RA/RL78・ESP32・nRF52 など、自社が採用する系列の経験があるか。完全一致でなくてもアーキテクチャが近ければ立ち上がりは早くなります
• RTOS の有無: FreeRTOS・Zephyr・ITRON 系などの使用経験。ベアメタル開発のみの経歴なら、RTOS 前提の設計では立ち上がりに時間がかかると見込みます
• 通信規格の実装経験: BLE・Wi-Fi・LTE-M・LoRaWAN のどれを、どのモジュールで扱ったか。「通信を使った経験がある」と「スタックの挙動を理解して省電力を詰めた経験がある」は別物です
• デバッグ手段の記述: JTAG/SWD デバッガ、ロジックアナライザ、オシロスコープ、電流計測などの使用に触れているか。ここが書かれている経歴書は実機での不具合対応を経験している可能性が高いです
• 認証・規格対応の経験: 技適・EMC・安全規格への対応経験。該当製品を扱う場合は必須の確認項目です
• ドキュメント成果物の記載: 設計書・試験仕様書を作成した経験があるか。引き継ぎの品質に直結します

判定に迷った場合は、経歴書の記述を引用して「この案件では出荷台数はどの規模でしたか」「量産後に発生した不具合で、印象に残っているものを教えてください」と質問してください。量産を通した人はこの問いに具体的なエピソードで答えられます。

技術面接ができない場合の代替手段

社内に技術評価ができる人がいない、あるいは 2 名とも多忙で面接に出られない場合、次の 3 つが実用的です。

1. 短期の有償トライアル: 2〜4 週間の小さなスコープ（既存ファームへのログ機能追加、通信リトライ処理の実装など）を有償で依頼し、成果物とコミュニケーションの質を見ます。無償のコーディングテストより、実案件に近い環境での判断ができます
2. 技術リファレンスの同席: 面談の場に第三者のエンジニアに同席してもらい、技術的な深掘りを担当してもらいます。自社に組み込み経験者がいなくても、外部の技術顧問や取引先のエンジニアに 1 時間だけ協力を仰ぐ形なら実現しやすい方法です
3. 過去案件の関係者への確認: 委託先の了解を得たうえで、過去の発注元に納期遵守やコミュニケーションについて確認します。技術力そのものより、進め方の相性が分かります

なお、製造現場の業務を理解できる人材をどう見極めるかという論点は、業務委託の外部エンジニアで開発を進める手順でも整理しています。

機密保持と引き継ぎ｜属人化させない発注設計

最後の関門が「外に出したまま戻ってこない」という不安です。機密の線引きと引き継ぎの設計をセットで決めておけば、外部人材の活用を単発で終わらせずに継続的な体制にできます。

組み込み案件で守るべき機密の範囲を決める

組み込み開発では、ソフト以外の情報も社外に出ます。何を出し、何を出さないかを先に決めてください。

そのうえで、NDA では次の 4 点を具体化します。秘密情報の定義（口頭で伝えた情報を含めるか）、目的外使用の禁止、再委託の可否と事前承諾の要否、契約終了後の存続期間です。とくに再委託は、個人への委託でも「知人に一部を手伝ってもらう」形で発生しうるため、事前承諾制にしておくと安全です。

作業環境については、私物 PC での作業を認めるか、貸与 PC を用意するかを決めます。貸与 PC は管理負担が増えますが、量産前の製品情報を扱う場合は選択肢に入れる価値があります。工場側の機密や現場システムとの接続を伴う場合の考え方は、製造業の外部エンジニア活用で機密保持の観点を含めて整理しています。

委託終了時に受け取るべき成果物リスト

契約時に「成果物」として列挙しておくべき項目です。ソースコードだけを受け取っても、社内でビルドできなければ意味がありません。

• ソースコード一式（自社管理のリポジトリにコミット済みであること）
• ビルド手順書とツールチェーンのバージョン（コンパイラ・SDK・ライブラリのバージョンを明記。ここが欠けると数ヶ月後にビルドが再現しません）
• 書き込み手順と使用ツール、書き込み時の設定値
• ピンアサインや周辺回路との対応関係を示す資料
• 通信設定・鍵・証明書の管理方法（鍵そのものではなく、発行と更新の手順）
• 単体試験・結合試験の仕様と実施記録
• 既知の未対応事項・暫定対処の一覧（いわゆる残課題リスト）
• 設計上の判断の記録（なぜその方式を選んだかの簡潔なメモで構いません）

最後の 2 つは軽視されがちですが、保守を引き継ぐ社内担当者にとって最も価値がある情報です。契約時に成果物として明記しておかないと、終了間際に「そこまでは聞いていない」となります。

知識移転を契約期間の中に組み込む

引き継ぎは契約終了後に頼むものではなく、期間内に組み込むものです。次の 3 点を最初から設計に入れてください。

1. リポジトリを自社アカウントで管理する: 委託先のアカウント配下にリポジトリを置かないこと。契約終了時のアクセス権の引き上げも、自社管理なら操作 1 つで完了します
2. 定例レビューに社内担当を同席させる: 週 1 回、30 分でもコードレビューや設計の説明の場を持ちます。ここでの会話が、ドキュメントには残らない判断の背景を社内に残します
3. 契約終盤の 1〜2 週間をハンドオーバー期間として明示する: 「最後の 2 週間は新規実装を行わず、ドキュメント整備と引き継ぎに充てる」と契約時に決めておきます。稼働の延長交渉が発生してもこの期間は削らないことを社内で合意しておくと、期限直前の駆け込みを防げます

この 3 つを実施していれば、委託先が変わっても製品の保守は社内で継続できます。逆に言えば、これらを設計に入れないまま進めた場合、その委託先に依存し続けることになります。

発注前に埋める組み込みエンジニア業務委託チェックリスト

ここまでの内容を、稟議書と募集要項にそのまま転記できる形にまとめます。空欄を埋めれば、外部委託の設計が一通り言語化できます。

進め方としては、最初から複数名を確保しようとせず、切り出しやすい層を 1 名の部分稼働で試すところから始めるのが現実的です。週 2〜3 日・3 ヶ月程度の契約で、クラウド連携や通信処理を任せてみる。その過程で自社の切り出し設計・レビュー体制・引き継ぎの型が固まれば、次はより難しい層に範囲を広げられます。

量産スケジュールが決まっている状況では、全部をまとめて解決しようとするほど着手が遅れます。まずはこのチェックリストの上から 3 行、切り出す層・残す層・実機の運用パターンを埋めてみてください。この 3 つが決まった時点で、募集要項はほぼ書ける状態になります。

関連情報

外部人材の活用や発注設計について、社内での検討材料を整理したい方は、関連するお役立ち資料もご覧いただけます。

IoT機器開発の体制づくりや、どの範囲を外部に切り出すべきかの整理をご検討中の方は、お問い合わせフォームからご相談ください。要件の整理段階からご相談いただけます。