派遣エンジニアと複業エンジニアの違い｜発注者の使い分け判断軸

「SES・フリーランス・ラボ型開発の比較記事は読み終えた。基礎的な3形態の違いは理解できた。しかし今回の案件は、なぜかその3形態のどれにも当てはまらない――」。外部エンジニア調達の意思決定を任されている方の中には、こうした「3形態を学んだ次の壁」に直面している方が少なくないのではないでしょうか。

「自社の正社員エンジニアと机を並べて、PMが直接タスク指示を出しながら開発を進めたい」「逆に、データ基盤の設計レビューだけ著名な現役CTOに週1日で見てほしい」。こうした追加要件が加わると、SES・フリーランス・ラボ型のいずれを選んでも違和感が残ります。エージェントから「派遣がいい」「複業エンジニアでどうですか」と提案を受けても、両者の使い分けが整理できず社内会議で根拠を示せない、という状況に陥りがちです。

こうしたケースで残された選択肢が「派遣エンジニア」と「複業エンジニア」です。前者は労働者派遣法に基づき発注者の指揮命令下にエンジニアを置く形態、後者は本業を別に持つエンジニアが業務委託契約で週1〜2日関わる形態であり、両者は同じ「外部エンジニア」と呼ばれながら法的性格も活用パターンも大きく異なります。

本記事では、SES・フリーランス・ラボ型の知識を前提に、派遣エンジニアと複業エンジニアの違いを発注者目線で整理し、3つの問い（指揮命令の必要性・稼働密度・契約期間）で使い分けを判断するフレームを提供します。さらに派遣特有の法的要件（抵触日・3年ルール）と複業特有の契約論点（競業避止・本業との利益相反）を実務レベルで解説し、5形態を組み合わせた人材調達ポートフォリオの視点までを提示します。

SES や請負だけでは収まらない「派遣」「複業」という選択肢

外部エンジニアの調達経験がある発注者ほど、SES・フリーランス・ラボ型の3形態を「契約形態」「指揮命令の所在」「稼働形態」の3軸で整理できているはずです。一方で、すべての案件がこの3形態で綺麗に収まるわけではない、という実感もお持ちかもしれません。本セクションでは、3形態では収まらない要件のパターンを言語化し、なぜ派遣と複業が「次の選択肢」になるのかを示します。

既存3形態（SES／フリーランス／ラボ型）で対応できないケース

SES・フリーランス・ラボ型の3形態は、いずれも「準委任契約」または「請負契約」をベースとし、指揮命令権は受注側（ベンダーやフリーランス本人）にあるという共通点を持ちます。この前提が崩れる案件、または前提とは別の制約が加わる案件で、3形態は機能しなくなります。

代表的なのは以下の2パターンです。

• パターンA: 指揮命令が発注者側に必要なケース: 自社の開発標準・コーディング規約・チケット運用に完全に従わせたい。自社PMが朝会・夕会で直接タスクを差配したい。チャットツールで都度「これを先に対応してほしい」と指示を出したい――こうしたケースでは、準委任・請負契約の「指揮命令権は受注側」という原則と衝突します。無理に進めれば偽装請負のリスクが生じます。
• パターンB: 週1〜2日だけ特定スキルが欲しいケース: データ基盤のアーキテクチャレビュー、セキュリティ設計の意見出し、AI/MLパイプラインの方針助言など、専門領域の意思決定支援を月4〜8日だけ依頼したい。SES・フリーランスの一般的な稼働単位（週3〜5日）では稼働率が合わず、ラボ型の月額固定モデルでは費用対効果が見合いません。

3形態の基礎比較に立ち戻りたい場合は、自社既存記事のSES・ラボ型・フリーランスの違いを併読してください。本記事は、その記事の知識を前提とした「次の一歩」として位置づけています。

なぜ「派遣」と「複業」がそれぞれの解になるのか

パターンAに対する解が「派遣エンジニア」、パターンBに対する解が「複業エンジニア」です。

派遣エンジニアは、労働者派遣法に基づき派遣会社と雇用契約を持つエンジニアを、発注者（派遣先）の指揮命令下で就労させる形態です。準委任・請負と異なり、発注者が直接タスク指示・労働時間管理を行えるため、自社チームと一体運用したいケースに適合します。

複業エンジニアは、別の本業を持つエンジニアが業務委託契約で週1〜2日（または月4〜8日）だけ関わる形態です。本業で第一線の経験を積んでいる現役エンジニア・CTO層が候補となるため、「非常勤だが高スキル」という稀少な要件に応えられます。プラットフォーム（複業クラウド・Lotsful・Offers等）の登場により、こうした人材へのアクセスも容易になっています。

本記事の到達点

本記事では、派遣・複業それぞれの定義と発注者視点での違いを整理し（次のセクション以降）、それぞれが選ばれる発注シナリオと実務要件を解説します。記事後半では「3つの問い」で派遣か複業かを判断するフレームを示し、最後に5形態（SES／フリーランス／ラボ型／派遣／複業）を組み合わせた人材調達ポートフォリオの視点を提示します。

派遣エンジニアと複業エンジニアの定義と発注者にとっての違い

派遣エンジニアと複業エンジニアは、契約相手・指揮命令権の所在・稼働密度・典型期間のすべてで対照的な存在です。本セクションでは、両者の定義を発注者視点で確認し、SES・フリーランスとの境界を明らかにした上で、5観点での早見表を提示します。

派遣エンジニアとは

派遣エンジニアとは、派遣会社（派遣元）と雇用契約を持つエンジニアが、派遣先（発注者）の指揮命令下で就労する形態を指します。労働者派遣法に基づく契約であり、以下の特徴があります。

• 契約の三者構造: 派遣先（発注者）と派遣元（派遣会社）は労働者派遣契約を結ぶ。派遣元はエンジニアと雇用契約を結ぶ。発注者とエンジニアの間に直接の雇用契約はない
• 指揮命令権は派遣先にある: 業務の進め方・労働時間・タスク差配は派遣先が指揮命令する。これが準委任・請負との最大の違い
• 雇用責任は派遣元にある: 給与支払・社会保険・有給管理は派遣元の責任。派遣先は労働時間の適正管理など派遣先責任者としての義務を負う

派遣の基礎をSES・業務委託との比較でより広く知りたい場合は、自社既存記事のSES・派遣・業務委託の違いを参照してください。

複業エンジニアとは

複業エンジニアとは、本業を別に持つエンジニアが、業務委託契約で副次的に関わる形態を指します。「副業」と混同されがちですが、文脈上の意味合いが異なります。

• 副業（ふくぎょう）: メインの本業の傍らで行うサブの仕事。所得が少額・補助的なニュアンス
• 複業（ふくぎょう）: 複数の本業を並行する働き方。それぞれが本業相当の重みを持ち、専門性を活かして複数社にコミットする

エンジニア領域では、現役CTO・テックリード・専門領域のスペシャリストが、本業の所属企業に加えて週1〜2日だけ別の企業に業務委託で関わるパターンが「複業エンジニア」と呼ばれます。and HiProは複業について「メインのサブではなく、複数の本業」と整理しています（and HiPro: 複業とは？副業との違いやメリット・デメリットを解説）。

発注者から見た最大の特徴は、「フルタイムでは採用できない高スキル人材に、非常勤でアクセスできる」点です。本業を辞めずに副次的に関われる枠組みであるため、フリーランス独立を選ばない第一線エンジニアにも依頼の門戸が開きます。

派遣 vs 複業 早見表

両者を発注者視点で対比すると以下のとおりです。

派遣の単価相場については「派遣エンジニアの平均は月額約67万円前後（20日稼働換算）」とされ、PM・PMOクラスでは時給5,000〜8,000円超のレンジも報告されています（type IT派遣: エンジニア派遣の単価）。複業エンジニアの単価は、CTO経験者・テックリード経験者で時給1万円以上が相場とされます（Workship ENTERPRISE: エンジニアの時給単価と相場）。

SES・フリーランスとの境界線

派遣・複業をSES・フリーランスと混同しないために、決定的な違いを整理します。

• 派遣 vs SES: 両者とも「人月単位でエンジニアの稼働を購入する」点では似ているが、指揮命令権の所在が逆である点が決定的な違い。SESは準委任契約のため指揮命令はベンダー側にあり、発注者が直接タスク指示することは偽装請負リスクとなる
• 複業 vs フリーランス: 両者とも業務委託契約だが、本業の有無が異なる。フリーランスは独立した個人事業主で複数社の業務委託で生計を立てる。複業エンジニアは別の本業（多くは正社員雇用）を持ちながら副次的に関わる

SES・フリーランス・ラボ型の3形態を含めた境界整理はSES・ラボ型・フリーランスの違いで詳しく扱っています。

「派遣エンジニア」が選ばれる発注シナリオと運用要件

派遣エンジニアが最適解になるのは、指揮命令を発注者が握る必要があるケースです。本セクションでは、派遣を選ぶべき具体的なシナリオを類型化し、選定後に押さえるべき法的要件と社内手続きを整理します。

派遣を選ぶべき発注シナリオ

派遣エンジニアの活用が適しているのは、以下のようなケースです。

• 自社PMが直接タスクを差配する開発体制: 自社の正社員PMが日次でタスクを割り当て、進捗を確認し、優先順位を入れ替える運用。準委任ベースのSESでは指揮命令を委託先に集約する必要があるため、PMの直接差配が必須なら派遣が適合する
• 自社の開発プロセスに完全に従わせる必要があるケース: 自社固有のチケット運用ルール、コーディング規約、レビュー手順、リリース承認フローに完全準拠してもらう必要がある場合
• 3年以内の期間限定プロジェクト: 派遣は個人単位で3年の上限があるため、もともと3年以内に終わる期間限定プロジェクト（基幹システム刷新の集中フェーズ等）と相性が良い

逆に「3年以上にわたり継続的に同じエンジニアを抱え続けたい」「指揮命令は不要で成果物だけ受け取れればよい」場合は、派遣ではなく直接雇用・SES・請負を検討すべきです。

労働者派遣法の発注者視点要点

派遣を受け入れる発注者（派遣先）が押さえるべき要点は以下のとおりです。

• 指揮命令権は派遣先に移る: 業務指示・労働時間管理・休憩取得指示は派遣先が行う。これが派遣を成立させる法的要件
• 雇用責任は派遣元のまま: 給与支払・社会保険・有給管理は派遣元の責任。派遣先が直接雇用責任を負うことはない
• 派遣契約書の必須記載事項: 業務内容、就業場所、指揮命令者、派遣期間、就業日・就業時間、安全衛生に関する事項などを明記する必要がある
• 派遣先責任者の選任: 派遣先は派遣先責任者を選任し、派遣労働者の指揮命令・苦情処理・教育訓練の窓口とする義務がある

抵触日と3年ルール — 事業所単位／個人単位の違い

派遣を語る上で避けて通れないのが「抵触日（ていしょくび）」と「3年ルール」です。これは2つの単位で別々に管理する必要があります。

事業所単位の抵触日

同一事業所（オフィス）で派遣受け入れを開始してから3年を迎える日を「事業所抵触日」と呼びます。事業所単位の3年を超えて派遣を継続したい場合、抵触日の1ヶ月前までに過半数労働組合（無い場合は過半数代表者）への意見聴取手続きを完了する必要があります（マンパワーグループ: 派遣の抵触日とは？、厚生労働省: 労働者派遣事業関係業務取扱要領）。

個人単位の抵触日

同一の派遣労働者が、同一事業所の同一の組織単位（課・グループ等）で3年を超えて働くことを禁止するルールです。3年経過後は、同じ派遣労働者を別の組織単位（別の課）に異動させるか、直接雇用に切り替える等の対応が必要となります。

運用上の意味

事業所単位は「事業所として何年派遣を受け入れているか」、個人単位は「特定の派遣労働者を特定の課で何年使っているか」をそれぞれ別に管理することになります。発注者の人事・総務部門は、両方のカレンダーを把握しておく必要があります。

派遣受け入れ時の社内手続き

派遣を受け入れる際、発注者が踏むべき社内手続きを時系列で整理すると以下のとおりです。

1. 派遣会社の選定・労働者派遣契約の締結: 派遣元（派遣会社）を選定し、業務内容・期間・指揮命令者を明記した労働者派遣契約を結ぶ
2. 派遣先責任者の選任: 派遣労働者の指揮命令・苦情処理の窓口となる派遣先責任者を社内で選任する
3. 指揮命令者の指定: 業務上の指示を行う指揮命令者を派遣契約書に明記する
4. 意見聴取手続き（事業所単位3年到達前）: 抵触日の1ヶ月前までに、過半数労働組合または過半数代表者に対し、派遣可能期間の延長について書面で意見を聞く
5. 抵触日通知: 派遣元に対し、事業所単位の抵触日を書面で通知する

コスト構造の特徴

派遣エンジニアのコスト構造は以下の特徴を持ちます。

• 時給ベース + マージン: 派遣先が支払う派遣料金は、エンジニアへの賃金 + 派遣会社のマージン（一般的に25〜30%）の合計
• マージンの中身: 社会保険料、教育訓練費、福利厚生費、営業・管理費等が含まれる（アデコ: 派遣会社のマージン率）
• 残業精算: 派遣労働者の残業発生時は別途精算となる
• 福利厚生負担なし: 派遣先は社会保険・有給等の直接負担を持たない

派遣エンジニアの単価相場は、開発エンジニア（PG/SEクラス）で時給2,800〜5,000円、PM・PMOクラスで時給5,000〜8,000円超とされています（type IT派遣: エンジニア派遣の単価）。

「複業エンジニア」が選ばれる発注シナリオと活用パターン

複業エンジニアが最適解になるのは、非常勤の高スキル人材を、特定の意思決定支援や設計レビューに当てたいケースです。本セクションでは、複業ならではの活用パターンを4類型に整理し、出会いのルートとコスト構造を解説します。

複業エンジニアを選ぶべき発注シナリオ

複業エンジニアの活用が適しているのは、以下のような状況です。

• 非常勤の高スキル人材を活用したい: 第一線で活躍するCTO・テックリードクラスを、フルタイムではなく週1〜2日で関わってもらいたい
• 意思決定支援が中心の業務: 実装そのものより、設計レビュー・技術選定の助言・経営層への技術アドバイザリーなど「意思決定の質を上げる」業務が中心
• 特定領域のスポット依頼: セキュリティ設計・データ基盤・MLOps・SREなど、社内に専門家がいない領域だけ外部の専門家に見てもらいたい

これらの要件は、フルタイム前提のSES・派遣でも、フリーランス独立を前提とした業務委託でも対応しづらく、複業エンジニアならではの解になります。

代表的な活用パターン4類型

複業エンジニアの活用は、おおまかに以下の4パターンに分類できます。

A. アドバイザリーCTO（週1日・経営に近い意思決定支援）

シリーズA前後のスタートアップや、内製化を始めたばかりの事業会社が、現役CTOクラスを週1日アドバイザリーとして迎えるパターン。技術戦略・アーキテクチャ選定・採用面接などに関わる。月額契約で時給1万円超〜が一般的な単価レンジとされ、週2日でも月70〜90万円規模の契約が現実的に存在すると報告されています（Zenn: ソフトウェアエンジニアの単価）。

B. 設計レビュー専任（領域特化・スポット）

データ基盤・セキュリティ・SRE・MLOpsなど、特定領域の設計レビューだけを依頼するパターン。プロジェクトの設計フェーズで月2〜4回のレビューに入ってもらい、実装は社内エンジニアが行う。

C. 正社員候補の試用（採用前提の業務委託）

将来的に正社員として迎えたいエンジニアを、まず複業として関わってもらい相互の適性を見極めるパターン。エンジニア側もリスクを取らずに新しい環境を試せるため、近年採用市場で広がりつつある。

D. 立ち上げ期のキャパシティ補強（PMFまでの開発加速）

PMF（プロダクトマーケットフィット）到達前の事業立ち上げフェーズで、複数の複業エンジニアを並行して稼働させ、リソース不足を補うパターン。フルタイム採用のリスクを取らずにスピードを確保できる。

複業エンジニアと出会うルート

複業エンジニアと出会う主なルートは以下のとおりです。

• マッチングプラットフォーム: 複業クラウド（Another works）、Offers、Lotsful、Workship など、複業エンジニア専門のマッチングサービス。経歴・スキル・希望稼働日数を検索して直接スカウト可能
• 知人紹介・リファラル: 自社の正社員エンジニアや過去のフリーランスからの紹介。スキルと人柄の事前検証が利く
• コミュニティ・勉強会: 技術コミュニティで活躍する登壇者・OSSコミッターへの個別声かけ

導入事例の幅広い活用パターンはAnother works 複業クラウド 導入事例で確認できます。

コスト構造の特徴

複業エンジニアのコスト構造は、派遣とは異なる特徴を持ちます。

• 時間単価ベース: 月の上限・下限稼働時間を定めた時給契約が一般的（例: 時給1万円、月稼働下限60h・上限120h）
• スキル特化型の高単価: CTO経験者・テックリード経験者で時給1万円以上が一般的。中堅エンジニアでも時給5,000円程度から（Workship ENTERPRISE: エンジニアの時給単価）
• 業務委託契約のため社会保険等の負担なし: 発注者は時間単価以外のコストを基本的に負担しない
• 稼働下限の設定: 週1日稼働でもエンジニア側の事務工数（コミュニケーション・キャッチアップ）が発生するため、月の最低稼働時間を設けるのが一般的

派遣と比較すると単価そのものは高めですが、稼働日数が週1〜2日に収まるため、月額総コストでは派遣・SESより安価になるケースが多い点が特徴です。

派遣 vs 複業の意思決定軸 — 発注者が答える3つの問い

ここまでの整理を踏まえ、自社の今回の案件で派遣・複業のどちらを選ぶべきかを決める判断フレームを示します。発注者が答えるべきは、シンプルに3つの問いだけです。

問い① 自社PMの指揮命令が必要か

最初の問いは「自社のPMが、外部エンジニアに対して直接タスク指示を出す必要があるか」です。

• Yes（指揮命令が必要） → 派遣エンジニアが候補。準委任・請負ベースのSES・フリーランス・ラボ型では指揮命令を発注者が握れず、無理に進めれば偽装請負リスクとなる
• No（指揮命令は不要、成果物だけ受け取れればよい） → 複業エンジニアまたは既存3形態（SES・フリーランス・ラボ型）が候補

「指揮命令が必要かどうか」は、業務の性質よりも社内の開発体制と意思決定スタイルに依存します。自社PMが日次でタスク差配する文化なら指揮命令が必要、成果物単位で発注する文化なら不要、という整理が実態に合います。

問い② 必要な稼働密度はフルタイムか、週N日か

次の問いは「必要な稼働密度はフルタイム（週5日）か、週1〜2日か」です。

• フルタイム（週4〜5日・常駐相当） → 派遣エンジニアまたはSESが候補
• 週1〜2日（月4〜8日程度） → 複業エンジニアが候補

注意すべきは、「稼働密度の低さ = 単価の安さ」とは限らない点です。複業エンジニアは時給ベースで派遣・SESより高単価のことが多い反面、稼働日数が少ないため月額総額では安価になります。

問い③ 期間は3年以内か、それ以上か

3つ目の問いは「外部エンジニアに関わってもらいたい期間は3年以内か、3年を超える継続的な関与か」です。

• 3年以内・期間限定プロジェクト → 派遣エンジニアが適合（個人単位3年の制限内で完結）
• 3年を超える継続関与（特に非常勤） → 複業エンジニアが適合（業務委託のため期間制限なし）

派遣で3年以上同じエンジニアを抱える場合、別の組織単位への異動か直接雇用への切り替えが必要となり、運用の柔軟性が下がります。「数年単位で同じ専門家にゆるく関わってほしい」要件には複業が向きます。

回答パターン別の推奨マトリクス

3つの問いに対する回答パターンと推奨形態をまとめます。

判断に迷うケース

3つの問いで綺麗に分かれないケースも実務では存在します。代表的な迷いどころと対処は以下のとおりです。

• 指揮命令も必要だが、稼働は週2日: 派遣の短時間派遣（週20時間未満も契約上は可能）を検討。または業務範囲を「指揮命令が必要な部分」と「アドバイザリー部分」に切り分け、前者を派遣、後者を複業で構成する
• 指揮命令は不要だが、3年超でフルタイム稼働: SES・ラボ型・直接雇用が候補。派遣・複業はいずれも構造的にミスマッチ
• 専門領域のスポット依頼で、社内に依頼ノウハウもない: まず複業から始めて関係性を作り、必要に応じてフルタイム化（直接雇用）を検討する段階的アプローチが有効

複業エンジニア活用時の契約・運用の注意点

複業を選ぶと決めた発注者にとって、最大の関心事は「本業を持つ人材を扱うことで生じる固有のリスク」をどう管理するかです。本セクションでは、契約条項と運用ルールの両面で発注者が押さえるべき論点を整理します。

本業との利益相反・競業避止条項の設計

複業エンジニアは別の企業に本業を持っているため、本業先と自社の事業領域が競合する場合、利益相反が発生する可能性があります。これを防ぐ条項設計が必要です。

• 競業避止条項: 「本業先または自社のいずれの競合事業に直接従事することを禁じる」「契約期間中および契約終了後一定期間、競合企業への業務委託受託を制限する」等の条項を契約書に盛り込む
• 本業先の競業避止義務との整合性: 多くの企業は就業規則で副業・複業時の競業避止を定めている。複業エンジニア側が本業先のルールに違反していないかを発注前に確認する
• 業務範囲の明確化: どこまでが委託業務でどこからが利益相反かを明文化することで、後日の紛争を予防する

副業・兼業における競業避止・秘密保持の法的設計は、弁護士法人森重法律事務所の副業・兼業をどう扱うか｜許可制、秘密保持、競業避止の設計が体系的に解説しています。

秘密保持契約（NDA）の範囲設計と情報アクセス権の最小化

複業エンジニアは本業先でも別の機密情報を扱っているため、双方向の情報漏洩リスクを意識する必要があります。

• NDAの締結: 業務委託契約とは別に、自社情報の取り扱い範囲・期間・違反時の損害賠償を定めたNDAを締結する
• 情報アクセス権の最小化: 業務に必要な情報のみアクセス可能とし、社内の機密度の高い情報（顧客情報・財務情報・人事情報等）からは隔離する
• デバイスとアカウントの分離: 本業先で使うデバイス・アカウントとは分けた環境で自社業務を実施してもらう。社用PCの貸与またはVDI環境の提供を検討する

稼働時間・成果物定義の業務設計

複業エンジニアの業務は「時間ベース」と「成果物ベース」のいずれで定義するかで運用が大きく変わります。

• 時間ベース: 「週8時間以内」「月60〜120時間」など稼働時間で契約。アドバイザリーやレビュー業務に向く
• 成果物ベース: 「○○の設計書を月内に納品」「△△の実装を完了する」など成果物で契約。明確なアウトプットがある業務に向く
• ハイブリッド型: 月の最低/最大稼働時間と、その範囲で達成すべき成果物を併記する。実務では最も柔軟

業務設計の段階で「何をどこまで期待するか」を明文化することが、複業活用の成否を分けます。

本業先への配慮

複業エンジニアは本業の所定労働時間外で自社業務を行うため、過重労働防止と健康管理は発注者の責任範囲にも入ってきます。

• 本業の所定労働時間の確認: 「本業フルタイム + 自社業務週20時間」だと労働時間が過大になる。月の稼働上限を健康的な範囲に設定する
• 健康管理の配慮: 厚生労働省は副業・兼業時の労働者の健康管理について事業者の配慮義務を示しています（厚生労働省: 副業・兼業と労働条件）
• 本業先の許可制への確認: 本業先が副業・複業を許可制としている場合、複業エンジニア側が許可を取得済みであることを業務開始前に確認する

経済産業省 関東経済産業局の外部人材活用ガイダンスでは、受け入れ企業視点での契約・運用の留意点が解説されています。

複業人材の評価・継続判断

複業エンジニアの業務は稼働日数が少ないため、成果の見えにくさが課題になりがちです。

• 短期で成果が出ない場合の打ち切り条項: 月次・四半期ごとの成果評価ポイントを設け、期待値に届かない場合の契約見直し条件を明文化する
• コミュニケーション設計: 週1日稼働の場合、稼働日外のSlack・チャットでの応答可否を明確に定める。「週1日の出社日のみ対応」か「稼働日外も24時間以内に返信」かで運用負担が大きく変わる
• 継続判断の指標: アドバイザリー型なら「意思決定の質」「社内の納得感」、設計レビュー型なら「指摘事項の数と質」、キャパシティ補強型なら「アウトプット量」と、パターンに応じた評価指標を事前に定義する

派遣・複業を含めた人材調達ポートフォリオの設計

ここまで派遣と複業を個別に深掘りしてきましたが、実務では単一形態に絞らず複数形態を組み合わせることが、外部エンジニア調達の成熟形です。本セクションでは、SES・フリーランス・ラボ型・派遣・複業の5形態を組み合わせる視点を提示します。

なぜ単一形態に絞らず組み合わせを考えるべきか

プロジェクトのフェーズや業務の性質に応じて、最適な形態は変わります。一つのプロジェクトの中でも、「コア開発はラボ型」「現場PMは派遣」「設計レビューだけ複業」のように役割ごとに調達手段を分けることで、各形態の強みを最大化できます。

• フェーズによる最適形態の違い: 立ち上げ期は複業による意思決定支援、開発期はラボ型・SESによるキャパシティ確保、運用期は派遣による日次運用、というように時期で必要な形態が変わる
• 役割による最適形態の違い: 意思決定支援は複業、実装は SES・ラボ型、現場運用は派遣、特定領域のスポットは複業と、役割ごとに強みのある形態は異なる
• リスク分散効果: 単一ベンダーへの依存を避け、複数形態を組み合わせることで、人員交代・契約終了時のインパクトを最小化できる

組み合わせの具体パターン3例

実務でよく見られる5形態の組み合わせパターンを3例紹介します。

パターンA: 内製化推進フェーズ（事業会社のDX推進）

• アドバイザリーCTO（複業・週1日）が経営層との橋渡しと技術戦略策定を担当
• 自社の正社員エンジニアが内製化のコア部分を実装
• ピーク時のキャパシティ不足をSESでスポット補強
• セキュリティ・データ基盤の設計レビューは別の複業エンジニア（領域特化）に依頼

パターンB: 期限ありの大型刷新（基幹システム刷新等）

• プロジェクトマネジメントは派遣の現場PMが自社プロセスに従って実行
• 開発のコア部分はラボ型で安定したチームを確保
• アーキテクチャ意思決定は複業のアドバイザリーCTOが伴走
• 移行期のテスト工数はSESでスケール

パターンC: PMF前のスタートアップ的開発

• 初期実装はフリーランスを機動的に活用
• 技術選定・採用面接の助言は複業のテックリードが担当
• PMF後の本格開発フェーズでラボ型またはSESにスケール

調達ポートフォリオを社内標準化する意義

案件ごとに「今回はSESで」「今回は派遣で」と都度判断していると、判断のばらつきや属人化が生じます。「3つの問い」のような判断フレームを社内標準化することで、以下のメリットが生まれます。

• 意思決定の速度向上: 案件発生時に毎回ゼロベースで検討せず、フレームに沿って即座に判断できる
• 組織知化: 過去案件の成功/失敗パターンを「どの形態を選んだか」で振り返り、フレームを継続改善できる
• 社内説明の容易化: 「なぜこの形態を選んだか」を経営層・財務部門に説明する根拠が一貫する

関連お役立ち資料の紹介

本記事で提示した「3つの問い」と「5形態の組み合わせ」の考え方を、自社のDX推進戦略・内製化戦略にどう落とし込むかは、より体系的なフレームでまとめた資料があります。

「外部エンジニア活用の戦略立案ガイド（DX推進・内製化ハイブリッド戦略）」では、外部人材を単発の調達ではなく「DX推進と内製化を両立させる戦略の一部」として位置づけ、人材ポートフォリオ設計の事例とフレームを掲載しています。本記事の判断軸を社内の戦略文書に組み込みたい方は、あわせてご覧ください。

まとめ

派遣エンジニアと複業エンジニアは、SES・フリーランス・ラボ型では収まらない発注要件への解として機能します。本記事の核となる判断フレームを再掲します。

• 問い① 自社PMの指揮命令が必要か → Yes なら派遣、No なら複業 or 既存3形態
• 問い② 必要な稼働密度はフルタイムか、週N日か → フルタイムなら派遣、週N日なら複業
• 問い③ 期間は3年以内か、それ以上か → 3年以内なら派遣、3年超の非常勤継続なら複業

派遣を選ぶなら抵触日・3年ルール・意見聴取手続きが運用要件として加わり、複業を選ぶなら競業避止・本業との利益相反・稼働時間管理が契約・運用要件として加わります。さらに、5形態を組み合わせて人材調達ポートフォリオとして設計することで、案件ごとの選定判断を組織知化できます。

外部エンジニア活用を「単発の調達」から「戦略的な人材ポートフォリオ」へ進化させる第一歩として、本記事の3つの問いを社内会議の共通言語として活用していただければ幸いです。