エンジニア採用と外注の判断基準｜6軸で決める意思決定プロセス

「次回の経営会議までに、エンジニアは採用で増やすのか外注で対応するのか、方針を一枚にまとめてくれ」。上長から指示を受けて情報収集を始めたものの、Web 上の比較記事を何本読んでも「結局どちらも一長一短」という結論にしか辿り着けず、稟議資料の骨子が固まらない。こうした状況に置かれている情シス・DX 推進担当の方は少なくありません。

判断が難しい根本原因は、エンジニア採用と外部委託のどちらも「一度動き出すと後戻りしづらい」意思決定だからです。採用すれば固定費が積み上がり、外注すればノウハウが社外に流れます。さらに国内のエンジニア人材市場は需給ギャップが拡大し続けており、「採用したくてもできない」状況が当たり前になりつつあります。

必要なのは「採用と外注どちらが得か」という二者択一の答えではなく、自社のプロジェクト特性に照らして、関係部門と経営層が納得できる形に落とし込む「意思決定プロセス」です。コスト単体の比較や判断軸の整理だけでは、稟議の場で関係部門の合意を取り付けるには不十分です。

本記事では、コストの単純比較ではなく「組織で意思決定を進め、稟議に落とし込むまでの手順」に焦点を当てて解説します。具体的には、(1) 比較前に揃えるべき4つの前提条件、(2) 比較を構造化する6つの判断軸、(3) 6軸の評価を1枚にまとめる意思決定マトリクス、(4) 二者択一を超えるハイブリッド設計、(5) 稟議・経営層への提案に落とし込む5要素、という流れです。記事の核心は最終セクションの稟議化プロセスにあり、6軸の比較・マトリクス・ハイブリッド設計はすべて稟議資料の骨子を組み立てるための材料として位置づけています。コスト試算の数値例も提示するため、稟議資料の骨子としてそのまま転用できる構成になっています。

エンジニア採用と外部委託の判断が難しい構造的な理由

判断が難しいのは、比較項目が多いからではなく、市場環境と意思決定そのものに3つの構造的な難しさが潜んでいるからです。

エンジニア人材市場の現状

経済産業省「IT人材需給に関する調査」は、IT人材の不足規模が2030年時点で最大約79万人に達する可能性を示しています（経済産業省 IT人材需給に関する調査）。中堅エンジニアの中途採用は求人公開から内定承諾まで半年〜1年を要するケースが多く、ITエンジニアの採用単価は人材紹介経由で1人あたり200〜300万円に達することもあると報告されています（エンジニア採用単価の相場）。「半年かけても採用できない」「コストが想定の倍になる」状況は、現場の感覚ではなく市場全体の傾向です。

つまり「採用」は、意思決定した瞬間に確定する選択肢ではありません。需給ギャップが構造的に存在する以上、「採用できなかった場合のプランB」まで稟議で問われることを前提に資料を組み立てる必要があります。

なお、採用と外注のコスト比較・4軸での判断フレームワークについては、社内エンジニア採用 vs 外注：コスト比較と4軸判断フレームワークで詳しく整理しています。本記事では、その比較結果を組織の意思決定プロセスに落とし込み、稟議資料として完成させる手順に焦点を当てています。

採用も外部委託も「不可逆性」が高い

採用は、入社後の人件費・社会保険・教育コスト・固定費を積み上げる意思決定であり、業績悪化を理由に即時解消することは現実的に困難です。逆に外部委託は、技術仕様の決定権・コードベース・運用知見が社外パートナー側に蓄積されるため、後から内製に切り戻すには数ヶ月単位の引継ぎ期間が必要になります。

「とりあえず始めて合わなければ戻せばいい」という発想で進められないのが、この意思決定の本質です。だからこそ、感覚的な比較ではなく、複数の観点で評価する必要があります。

判断保留で発生する機会損失

判断を先送りすると、(1) プロジェクト開始遅延による事業機会の損失、(2) 既存エンジニアの疲弊と離職リスク、(3) 単価相場の変動による判断材料の陳腐化、という3つの損失が積み上がります。判断は早ければ良いというものではありませんが、保留にも明確なコストがある前提を共有することが、稟議の場では重要になります。

比較を始める前に揃えるべき4つの前提条件

メリット・デメリットを並べる前に、自社側で固めておくべき条件が4つあります。これが曖昧なまま議論すると、必ず「両方一長一短」で終わります。

前提1: プロジェクトの戦略的重要度

対象プロジェクトを「コア領域（競争優位性の源泉）」「準コア領域（間接的に貢献）」「非コア領域（標準化された機能）」の3区分で分類します。コア領域はノウハウを社内に蓄積する必要性が高く、非コア領域は外部の専門知識を活用したほうが速く・安く実装できます。

前提2: 期間軸

プロジェクトを「3ヶ月以内（短期スポット）」「半年〜1年（中期）」「2年以上（中長期継続）」のレンジで整理します。期間が短いほど採用の固定費負担が重く、2年以上の継続なら採用がトータルコストで優位になることが多くなります。

前提3: 必要スキルの市場希少性

汎用スキル（Web系・業務システム系）であれば採用市場・委託市場の両方に十分な供給がありますが、希少スキル（特定領域の機械学習・金融基幹系の保守等）は採用も委託も供給が限られ、単価が跳ね上がります。

前提4: 予算枠と予算性質

利用可能な予算の総額に加え、「人件費／外注費／投資（資産計上）」のどの枠で計上するかを経理部門と事前確認します。同じ総額でも、会計上の枠次第で採用と外注の組み立てやすさが変わります。

エンジニア採用と外部委託を比較する6つの判断軸

前提条件が揃ったら、6軸で具体的に比較します。各軸では、自社条件ではどちらに傾いたかを1行で記録しておくと、後段のマトリクス作成が滑らかになります。

軸1: コスト（採用TCOと外部委託費の3年シミュレーション）

コスト比較は、初年度の単年比較ではなく、TCO（Total Cost of Ownership）を複数年で見ます。中堅エンジニア1名（想定年収600万円）を採用するケースで3年TCOを試算してみます。

採用コストは人材紹介経由（年収の35%相当）を想定。中途採用1人あたりの平均採用コストは約128万円というデータもありますが、ITエンジニアでは200〜300万円に達するケースも報告されています（エン株式会社 中途採用の採用単価）。

同等スキルの外部委託を月単価80万円で3年継続した場合、3年合計は約2,880万円。差額は約361万円で「採用のほうがやや安い」ように見えますが、稟議で問われるべきは、(1) 採用エンジニアの稼働率を80%以上で見込めるか、(2) 1〜2年で離職した場合の再採用リスク、(3) プロジェクト規模が縮小した場合の人員調整可能性、の3点です。

軸2: 立ち上がりスピード

採用は求人公開から本格稼働まで半年以上が一般的で、希少スキルなら1年以上かかります。一方、外部委託は契約締結まで2〜4週間、即戦力なら契約後1〜2週間で稼働開始可能です。「3ヶ月以内に動き出さなければ事業機会を逃す」プロジェクトでは、採用は現実的な選択肢になりません。

軸3: スキル希少性と人材到達性

汎用スキルは採用市場・委託市場の両方に供給があります。希少スキルの場合、採用市場で半年待っても候補者が現れない一方、フリーランス・専門コンサル・大手SIerの特定チームには経験者が複数存在することがあります。希少スキルが必要な場合は、採用と委託の両ルートで並行探索し、先に到達できたほうを選ぶアプローチが合理的です。

軸4: ノウハウの社内蓄積

採用の場合、設計判断・トラブル対応・運用知見は社員のスキルとして蓄積され、別プロジェクトで再利用できます。外部委託の場合、契約形態にもよりますが、コードベース以外の暗黙知（なぜその設計を選んだか、運用上のクセ）は委託先に残ります。

ただし、外部委託でもノウハウ蓄積は工夫次第で可能です。(a) 設計レビューに社内エンジニアを必ず同席させる、(b) 週次の振り返り会で意思決定の背景を文書化する、(c) コードベース・運用手順書・トラブルシューティングガイドを社内納品物として明示する、といった運用設計が鍵になります。

軸5: 人員調整の柔軟性

採用は人員数を機動的に増減することが困難です。プロジェクトが終了しても、その社員には次の業務を用意する必要があります。外部委託は契約期間と人数を比較的柔軟に調整できますが、希少スキルの場合は委託先側のリソース確保の都合で長期契約が前提になることもあるため、契約条件（最低契約期間・解約予告期間）を交渉段階で明示する必要があります。

軸6: 情報セキュリティと機密性

採用社員は労働契約と就業規則で機密保持義務を負い、入退室・端末・アクセス権の管理対象になります。外部委託でも NDA と業務委託契約で同等義務を課せますが、物理的な作業環境が委託先側にある場合、自社のセキュリティポリシーをそのまま適用しづらいことがあります。金融・医療・公共領域の業界規制で「直接雇用者による作業」が定められている場合は、外部委託の選択肢自体が制約されます。

6軸の判定を1枚にまとめる「意思決定マトリクス」

6軸の評価が済んだら、1枚のマトリクスに集約します。重要なのは機械的な多数決ではなく、軸ごとの重み付けを反映した総合判定です。

マトリクスの作り方と重み付けの考え方

6軸を縦に並べ、「採用優位／外部委託優位／中立」「重み（高・中・低）」「自社条件メモ」の列を加えると、稟議資料として使える形になります。重み付けの基本ルールは次の通りです。

• 戦略的重要度が「コア」なら、軸4（ノウハウ蓄積）の重みを「高」にする
• 期間軸が「短期」なら、軸2（スピード）と軸5（柔軟性）の重みを「高」にする
• スキルが「希少」なら、軸3（到達性）の重みを「高」にする
• 規制業界なら、軸6（セキュリティ）の重みを「高」にする

重み「高」の軸で傾いた方向が、総合判定の主要根拠になります。

事例A: コアシステム刷新で「採用主体＋部分委託」を選んだケース

従業員200名規模のSaaS企業が自社プロダクトの基幹システムを刷新するケースを想定します。

「ノウハウ蓄積」の重みが効き、採用主体の方針が選ばれます。認証基盤の希少スキルは委託で短期補強、という部分委託を組み合わせる形が現実解になります。

事例B: 短期キャンペーン開発で「外部委託全面」を選んだケース

消費財メーカーが3ヶ月限定のキャンペーンサイトを構築するケースでは、「スピード」「柔軟性」の2軸が重み「高」となり、外部委託全面が選ばれます。

同じ6軸を使っても、プロジェクト性質と重み付けによって結論は逆転します。重要なのは「結論そのもの」ではなく「なぜその結論に至ったか」を6軸で説明できることです。

採用と外注の二者択一を超えるハイブリッド設計

多くのケースで「軸ごとに傾く方向が異なる」状況が発生します。これは比較が失敗しているのではなく、現実のプロジェクトでは「採用100%」「外注100%」のどちらかが最適解になることのほうが稀だからです。ハイブリッド設計には3つの代表パターンがあります。

パターン1: コア／周辺の業務分割型

コア領域は社員エンジニア、周辺領域は外部委託に切り出す設計です。「データモデル設計・コアロジック実装」は社員、「管理画面・帳票出力・外部API連携」は委託先、という分担が典型例です。境界が曖昧だと品質と進捗が落ちるため、週次のスコープレビューで境界の見直しをルール化することが運用上の肝になります。

パターン2: フェーズ分担型

要件定義・PoC フェーズを外部委託の専門コンサル・SIerに依頼し、本開発フェーズから社員エンジニアが引き継ぐ設計です。要件定義は過去事例の多い外部パートナーが速く・正確に進められ、本開発以降は技術選定の自由度を社内に残せます。引継ぎ時に「なぜその設計を選んだか」を文書化することが最大のリスクヘッジになります。フリーランスや業務委託エンジニアを短期で活用する設計は、エンジニア人材不足への現実的な対応策として近年注目されています（参考: Workee 発注者向けブログ）。

パターン3: 二層体制（恒久要員＋柔軟リソース）型

恒久要員として少数の社員エンジニアを採用し、繁忙期だけ外部委託で増員する設計です。恒久要員は「アーキテクチャ判断責任者」「委託メンバーへの指示・レビュー責任者」を担います。恒久要員に過度な負荷が集中しないよう、レビュー体制とエスカレーションルートの整備が前提になります。

3つのハイブリッド設計は、関係部門の懸念を吸収しやすい「合意形成しやすい解」になります。「採用一辺倒」は人事・経理の負荷議論で詰まり、「外注一辺倒」は事業部・技術責任者のノウハウ流出懸念で詰まることが多いためです。

稟議・経営層への提案に落とし込む5つの要素

比較と設計が済んだら、最終的に稟議資料に落とし込みます。経営層が判断するために必要な情報は、次の5要素に整理できます。

稟議資料に必須の5要素

1. 意思決定の背景と緊急性: なぜ今この判断が必要か。開始期限、判断遅延による機会損失を定量的に示す
2. 採用／外注／ハイブリッドの選択肢比較: 6軸の評価結果を1枚のマトリクスにまとめる
3. 推奨案と理由: 重み付けの根拠を明示し、なぜその案を推奨するかを構造的に説明する
4. 想定リスクと対策: 採用できないリスク、委託品質リスク、ノウハウ流出リスクと、それぞれの対策を記載する
5. 撤退条件・見直しタイミング: どのような状況になったら方針を見直すか、定期見直しのタイミングを明示する

5番目の「撤退条件」は稟議を通すための要素です。意思決定が不可逆だからこそ、「最初の方針が間違っていた場合の検知メカニズム」を組み込むことで、経営層の心理的ハードルを下げられます。

経営層からの典型的な3つの反論への答え方

• 「コストは本当に安いのか」: 3年TCO・稼働率前提・離職リスクを織り込んだ「楽観／標準／悲観」3シナリオで提示する
• 「ノウハウは流出しないのか」: 設計レビュー同席・週次振り返り会の文書化・運用ドキュメントの納品物指定など、運用で確実に蓄積する設計を示す
• 「品質は担保できるのか」: 委託先選定軸（実績・体制・品質保証プロセス）と契約条件（受入検収・改修対応範囲）を具体化する

撤退条件と見直しタイミングの設計

撤退条件は次のように定量的に設計します。

• 採用方針: 求人公開から6ヶ月経過時点で内定承諾が想定の50%未満なら、外部委託への切り替えを再検討
• 外部委託方針: 委託開始から3ヶ月時点でKPI（コード品質・進捗・コミュニケーション）が合意基準を下回れば、委託先変更または採用切り替えを再検討
• ハイブリッド方針: 6ヶ月ごとに、コア／周辺の境界・人員配分の妥当性を見直す

これらを稟議資料の末尾に明示することで、「方針を決めても後戻りできる安心感」を経営層に提供できます。

まとめ：判断は「比較」ではなく「組織を動かす設計」である

エンジニア採用と外部委託の意思決定は、「どちらが得か」を比較する作業ではなく、自社プロジェクト特性に応じて関係部門と経営層を動かす「組織の意思決定設計」です。

本記事で提示したプロセスは次の通りです。

1. 比較の前提となる4条件（戦略的重要度・期間軸・スキル希少性・予算性質）を揃える
2. コスト・スピード・希少性・ノウハウ蓄積・柔軟性・セキュリティの6軸で構造的に比較する
3. 6軸の評価を重み付き意思決定マトリクスに集約する
4. 必要に応じてハイブリッド設計（業務分割型・フェーズ分担型・二層体制型）を検討する
5. 稟議・経営層への提案に5要素（背景・選択肢比較・推奨案・リスク対策・撤退条件）で落とし込む

このプロセスを稟議資料の骨子に転用できれば、「自分の中での仮の結論」を、関係部門と経営層が納得できる形に構造化できるはずです。

稟議資料の作成段階で「コストの根拠をもっと具体的に示したい」「経営層への説明に使えるテンプレートが欲しい」と感じた場合は、お役立ち資料「外部エンジニア活用のROI・コスト試算ガイド（稟議書テンプレート付き）」が参考になります。3年TCO試算シート・ROI 算出フォーマットに加え、稟議書テンプレートが含まれているため、本記事で組み立てた6軸の評価結果や撤退条件を、そのまま経営層向けの稟議資料に落とし込めます。