開発リソース不足の発注/外注/依頼/委託方法について

開発リソース不足を外部発注で補うには、要件定義を固め、契約形態を使い分けたうえで、ノウハウを社内に残す流れで進めます。

# 開発リソース不足の発注/外注/依頼/委託方法について

社内の採用がうまくいかず、保守だけで日々が過ぎていく企業は少なくありません。また、新規プロジェクトの構想はあるものの、着手できる人員も時間も足りないケースがあります。外部発注の設計は、避けて通れない経営課題になりつつあります。

Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

開発リソース不足を外部発注で補う全体像

開発リソース不足を外部に頼るとき、「人手を借りればよい」と考えると失敗しやすいのが実情です。発注の目的が短期的な工数の穴埋めなのか、中長期的な内製化への橋渡しなのかによって、選ぶ契約形態もパートナーも大きく変わります。

まず、自社のリソース不足の構造を理解したうえで、外部発注をどの位置づけで活用するかを決めることが出発点になります。

リソース不足の構造的な背景

経済産業省の推計では、2030年のIT人材不足は低位シナリオで約16.4万人、中位で約44.9万人、高位で約78.7万人にのぼります。さらに2040年には、AI・ロボット関連の専門人材が約326〜339万人不足するという見立てもあります。需給ギャップを埋めるには、毎年3.54%（中位）から5.23%（高位）の生産性向上が継続的に必要だとされています。

これは個社の採用の悩みにとどまらず、産業全体で達成すべきハードルとして示された数字です。国内企業のIT予算の約80%は、レガシーシステムの保守運用に費やされています。そのため、新規開発や攻めのDXに振り向けられる工数は、構造的に限られています。

「2025年の崖」では、放置した場合に最大12兆円規模の経済損失リスクが指摘されてきました。加えて、AI専門人材は1都3県に偏在しており、1都3県以外では専門職を充足できる地域はほぼないという地理的なハンディキャップもあります。こうした背景を踏まえると、外部発注は一時しのぎではなく、経営戦略の一部として位置づけ直すべきテーマです。

外部発注の主な選択肢と特徴

外部発注の主な選択肢は、受託開発やSESのほか、ラボ型開発・オフショア開発・フリーランス・技術顧問などに分けて整理できます。

• 受託開発：仕様の固まったプロジェクトを一括で任せ、納品責任をベンダーが負う請負契約が基本です。
• SES：技術者を時間単位で確保し、自社の指揮命令下で柔軟に動かせる一方、人月精算が続きやすい方式です。
• ラボ型開発：特定チームを中長期で専属確保する形で、要件が流動的なアジャイル開発や継続的な機能追加に適しています。
• オフショア開発：東南アジアを中心とした海外チームでコストを抑えつつ、ブリッジSEの体制づくりが成功のカギになります。
• フリーランス・技術顧問：フリーランスはスキルを補い、技術顧問やCTO代行は意思決定層への助言に役立ちます。

それぞれ得意な場面と不得意な場面があるため、案件の特性に応じて使い分けることが欠かせません。

発注フローの全体像と各フェーズの設計

外部委託で開発リソース不足を補う場合、発注前の準備が成果の大半を決めると言っても過言ではありません。曖昧な要件のまま発注を急ぐと、後工程で手戻りやスコープクリープが生じ、コスト超過にもつながりやすくなります。その結果、「外注したのに余計に手間が増えた」という事態を招きます。

要件定義から契約締結、稼働開始、ノウハウ移管まで、各フェーズで押さえるべき論点を事前に整理しておくことが欠かせません。

要件定義とスコープ分割

発注の起点となるのが要件定義です。ここでは業務課題と機能要件をひも付けて整理し、「何を解決したいのか」を発注先に正確に伝えます。理想形を一度に作るより、ビジネスインパクトの大きい領域から優先順位を付け、3〜6ヶ月単位のフェーズに分ける進め方が現実的だとされています。

このフェーズでよく起きる失敗は、「要件定義不足のまま見積もりを依頼してしまう」ケースです。RFP（提案依頼書）に業務フロー・データ構造・関係者・期待効果を書ききれないと、見積もりが各社バラバラになり、比較しようがなくなります。典型的な落とし穴と言えます。

スコープを小さく区切ると、初期投資を抑えつつ早期に成果を検証でき、軌道修正もしやすくなります。また、社内に要件を言語化できる人材がいなければ、要件定義の工程だけPM経験者やコンサルタントに支援を頼む選択肢もあります。

契約形態の使い分け

発注時の契約形態は、主に請負契約・準委任契約・ラボ型契約の3種類です。請負契約は、納品物を完成させる責任をベンダー側が負う形態で、要件が明確に固まった開発に向いています。一方、要件が固まりきらず仕様変更が頻繁に起きるアジャイル開発では、稼働時間に対して報酬を支払う準委任契約が適しています。

ラボ型契約は、特定チームを月額固定で確保する形で、中長期的に開発を続けたい場合に有効です。注意したいのは、人月精算ベースの契約をそのまま長期化させてしまうことです。さらに、生成AIによってコーディング・テスト・ドキュメント生成の生産性が飛躍的に向上するなか、人月単価で工数を積み上げる発想は次第に時代遅れになりつつあります。

経済産業省の検討会でも「人月商売からの脱却」が論点として提起されており、発注側も「成果ベース」「価値ベース」の契約設計を模索する時期に来ています。そのため、月次の納品物を明確にし、生産性向上分を発注側が享受できるよう契約条項を組み立てることが大切です。

KPI設計と進捗管理

外部発注の効果は、稼働時間や納品物の数といったアウトプット指標だけでなく、ビジネスに直結するアウトカム指標をKPIに据えて測るのが望ましいとされています。たとえば、「事務作業時間を月◯時間削減」「在庫回転率を◯%改善」「顧客対応リードタイムを◯日短縮」のように、業務側の数字と紐付けて設計します。

経済産業省が示す生産性向上率3.54〜5.23%を、自社プロジェクトのKPIに翻訳して設定するのも有効です。さらに、週次の定例だけに頼らず、共有のチケット管理ツールやコミュニケーションツールで日々の状況が見える状態を作ることが進捗管理の基本です。タスクの遅延が表面化したとき、発注側が早期に気付けるかどうかで挽回の余地が大きく変わります。

月次のレビューでは、進捗・課題・コスト消化率・残工数の見通しを必ずセットで確認します。そのうえで、発注側のPMが「次の意思決定に必要な情報」を主体的に引き出す姿勢が求められます。

失敗パターンとその回避策

外部発注の現場では、似たような失敗パターンが繰り返されています。典型例を知っておくだけでも、回避できるリスクは少なくありません。なかでも発注側が主導権を失いがちな3つのパターンは、それぞれの回避策を押さえておくことが大切です。

ベンダーロックインの回避

長年同じベンダーに任せていると、ソースコード・設計思想・運用ノウハウがすべてそのベンダーに集まり、他社への切り替えが極めて難しくなることがあります。これがベンダーロックインと呼ばれる現象で、ベンダーからの値上げ要請を断れず、機能追加のリードタイムも伸びやすくなります。さらに、品質が劣化しても泣き寝入りせざるを得ない状況が生まれやすくなります。

日本では多重下請け構造のなかで、ユーザー企業にノウハウが残りにくいため、ロックインが深まりやすいとも指摘されています。回避策としては、契約段階でソースコード・設計書・運用手順書・テストコードの所有権を発注側に明記するのが有効です。

また、クラウドサービスやライブラリは業界標準のものに統一し、独自フレームワークへの依存も避けます。さらに、ベンダー側の主要メンバーを発注側の社内勉強会に招き、技術的な意思決定の背景を共有してもらうと、暗黙知が発注側にも残るようになります。

自称DX人材化の防止

発注先の担当者の肩書きが「DXコンサルタント」「クラウドアーキテクト」であっても、実務では実装の指示出しすらできないケースは少なくありません。バズワードに詳しいだけで、コードを書いた経験や本番運用の修羅場をくぐった経験が浅い人材が高単価でアサインされると、プロジェクトは方向性を見失います。

経済産業省のデジタルスキル標準（DSS-P）では、5類型（ビジネスアーキテクト・デザイナー・データサイエンティスト・ソフトウェアエンジニア・サイバーセキュリティ）が示されています。そのうえで、この類型のどの領域で実務経験があるかを確かめることが有効です。

具体的には、面談で過去案件の意思決定の背景を深掘りし、コードレビューや設計レビューに同席してトラブル時の判断軸を尋ねます。さらに、自身が書いたコードや設計書のサンプルを示してもらうのも手です。また、資格やeラーニング修了証だけで判断せず、動かしたシステムの規模・ユーザー数・障害対応経験を数字で語れるかを確かめると、「自称DX人材」を見抜く手がかりになります。

要件定義不足による炎上の防止

要件定義が不足したまま発注を急ぐと、開発が進むにつれて「想定していた業務フローと違う」「画面が現場の使い方に合っていない」といった齟齬が次々と表面化します。仕様変更が膨らみ、当初予算を超えて炎上するのは、外部委託で最も典型的な失敗パターンと言ってよいでしょう。

特に基幹システムや業務システムでは、現場のオペレーションへの理解が浅いまま設計が進むと、リリース直前に致命的な手戻りが生じることがあります。そこで有効なのが、本格開発に入る前にPoC（概念実証）やプロトタイプ開発を挟み、画面イメージや業務フローを現場メンバーと合意してから本開発に移る方法です。

短期間で小さく形にして、現場が触って意見を出し、その意見を開発内容に反映していく反復プロセスを設計しておくと、要件の認識ズレを早期に潰せます。また、生成AIを使えばモックアップ画面や試作データを高速に作れるため、要件定義の解像度を上げる手段としての活用余地も広がっています。

ノウハウを社内に残す発注設計

外部発注の最大の落とし穴は、「人手は確保できたが、自社にナレッジが残らない」ことです。日本のIT業界では、多重下請け構造のもとでユーザー企業にノウハウが蓄積しにくいという指摘が以前から繰り返されてきました。

そのため、外部リソースに頼りつつも、自社の中核となる知識を蓄え続ける仕組みを発注時から組み込むことが、長期的な競争力を左右します。

ペアワークとOJTの組み込み

外部のエンジニアと自社の若手メンバーがペアでタスクを進める「ペアプログラミング」「ペアワーク」を契約に組み込むと、ノウハウ移管が進みやすくなります。外部メンバーが書くコードや設計判断の背景を隣で見ながら質問できる時間を、意図して設けておくことが大切です。

さらに、週に数日でも「ペアで作業する日」を固定すれば、暗黙知が言語化される機会が増え、自社メンバーの実務スキルも急速に伸びていきます。OJTの観点では、外部チームが担うタスクの一部を自社メンバーが主担当とし、外部側がレビュアーやメンターとして支える形が効果的です。

外部メンバーの稼働時間の何割かをこのメンタリングに充てることを契約で定めておくと、人月精算ではなく「人材育成も含めた成果」として価値を測れます。生成AIの台頭で、コーディングの基礎タスクをAIが代替しやすい時代だからこそ、「設計判断のなぜ」を共有する時間を確保する発注設計が若手の成長を支える土台になります。

コードレビュー同席とドキュメント化

もう一つ強力な仕組みが、コードレビューやアーキテクチャレビューに自社メンバーが必ず同席する運用ルールです。外部チーム内のレビューをブラックボックスにせず、次の記録をすべて残します。

• Pull Requestのコメント履歴：レビュー中のやり取りを、自社のリポジトリに保存
• 設計レビューの議事録：議事録の内容を、自社のドキュメント基盤に保存します。

そうして残した記録は、後から振り返るための情報資産として蓄積されていきます。特に、レビュー時に交わされた「なぜこの設計を選ばなかったか」という議論は、後任者にとって最大の学びになります。

NTTデータは、航空券予約システムのJava 8から17へのバージョンアップで、約16,000ステップのうち約5%の非互換箇所に生成AIを活用し、大幅な生産性向上を実現しました。

ドキュメント化のルールは契約書に明文化しておくと運用が安定し、知見を文書に残せば次のリプレースで同じ轍を踏まずに済み、長期的な見返りになります。たとえば、契約書には次のような定義を盛り込むイメージです。

• 設計書・ADR（Architecture Decision Record）：主要モジュールごとに作成し、月次でレビュー
• 障害対応の振り返り：ポストモーテムとして文書化

生成AI活用を前提にした発注設計

2030年に向けた人材不足のギャップを埋めるには、毎年3.54〜5.23%の生産性向上を継続する必要があります。この水準を人海戦術だけで達成するのは現実的ではなく、生成AIをはじめとする新技術の活用が前提になりつつあります。

発注時にも、「AIをどう組み込むか」「AIに任せる工程と人が責任を持つ工程をどこで線引きするか」を契約レベルで設計することが大切です。

AI活用前提でのスコープと工数設計

生成AIによって、コーディング・テスト・ドキュメント作成・データ分析などの工数を大きく圧縮できる時代に入りました。そのため、発注時には「AI活用前提の見積もり」をベンダーに明示的に求め、人月精算で工数を膨らませる慣習から脱却する設計が求められます。

日立製作所は、「生成AI共通基盤」をミッションクリティカル領域の開発フレームワークに組み込み、プロセス全体の効率化を進めています。こうした事例のように、業務クリティカルな領域でもAI活用は現実的な選択肢になっています。具体的には、見積もりの段階で「AIを使った場合の効率化想定」と「使わなかった場合の工数」を併記してもらいます。

そのうえで、生産性向上分を発注側がコスト削減または機能拡張の形で享受できる契約条項を設計します。月次の振り返りでは、「AI活用によって短縮できた工数」と「AIだけでは捌けず人が補った箇所」を洗い出し、次フェーズの計画に反映していくPDCAサイクルを回せば、生産性向上率を継続的に底上げできます。

ハルシネーション・情報漏洩への運用ルール

生成AIの活用が広がる一方で、機密情報をプロンプトに貼り付けて外部サービスに送信してしまう事例が増えています。さらに、ハルシネーションによる誤情報をそのまま納品物に組み込むケースも見られます。そのため、発注の段階で、生成AIを利用する範囲、利用するモデル（公開API/オンプレ）、入力できるデータの種類を契約で明確に定めることが欠かせません。

納品物に生成AIの出力を含める場合は、人によるレビューを必ず通す運用ルールを設けるのが基本です。運用面では、機密情報を入力しないためのプロンプトテンプレートを整え、ローカル環境やプライベートクラウド上で動くLLMの活用も検討します。出力結果のファクトチェック手順も明文化しておきます。

特に金融・医療・公共などの規制業種では、AIの判断根拠が問われる場面が増えるため、生成AIの利用ログを発注者側にも開示できる体制を整えてもらう必要があります。デジタルスキル標準（DSS-P）は2024年の改訂で、プロンプトエンジニアリングや倫理的課題が追加されました。発注先のメンバーがこうした観点を踏まえているかは、パートナー選定で大事な観点になります。

内製化への移行と長期的なパートナーシップ

外部発注を「ずっと外注のまま」で続けるのか、「いずれは内製化する」前提で進めるのかは、戦略として選ぶべき分岐点です。

コア領域は内製し、周辺領域は外注するハイブリッド型が、現実解として多くの企業に採用されています。そのため、内製化への橋渡しを担えるパートナーかどうかは、発注先を選ぶうえで大事な観点になります。

ハイブリッド体制への段階的移行

内製化を急ぐと、社内エンジニアの採用や教育に時間がかかりすぎ、事業のスピードが追いつかないリスクがあります。一方で、外注に頼り続ければノウハウが蓄積されません。長期視点では、外部パートナーが内製化支援を歓迎してくれるかどうかが、健全な関係性を維持できるかどうかの分かれ目になります。

現実的には、3〜5年のスパンで「最初は外部主導・社内学習中心」→「主要モジュールは内製・拡張は外部」→「コア機能は内製・スポット領域のみ外部」と段階を踏むアプローチが取られています。そのうえで、毎年ノウハウ移管の達成度を測りながら、内製比率を徐々に高めていきます。

移行のロードマップでは、「内製で持つべきスキル」と「外部に任せ続けるスキル」を各フェーズで分けて考えます。たとえば、業務理解と要件定義は社内、設計と実装は外部、運用と継続改善は社内という分け方も一案です。発注先を選ぶ段階で「将来的に内製化を進めたい」と伝え、共感してくれるかを確認しておくと、後の関係がスムーズです。

地域ITベンダーとの新しい関係構築

AI専門人材が1都3県に偏在しているという地理的な現実を踏まえると、地方企業ほど外部パートナーの活用が欠かせません。同時に、地域のITベンダーも、多重下請けの一次受けからの仕事を待つモデルから、ユーザー企業と直接フラットにつながる地元のDX支援者へ移りつつあると言われています。

経済産業省の検討会では、生成AIによる従来型ビジネスモデルの崩壊を前提に、地域ITベンダーの立ち位置を再定義する議論が進められてきました。発注側が地理的に近い地域ベンダーを直接パートナーに据えると、現場感の共有や対面でのワークショップが容易になり、要件定義の精度も高まりやすくなります。

NECアカデミーパートナープログラムは、販売特約店やソフトウェアパートナーにDX研修教材と講師育成支援を提供し、地域DXの底上げを図っています。こうした動きは、地域ベンダー再活性化の象徴的な取り組みと言えます。地域に根ざしたベンダーとの関係構築は、長期的なノウハウ蓄積の観点からも有効な選択肢として再評価されつつあります。

まとめ

開発リソース不足を外部発注で補うには、人手を確保するだけでは足りません。契約形態の使い分け・KPI設計・ノウハウ移管・生成AI活用・内製化への移行を組み合わせた発注設計が必要になります。

2030年に最大79万人の人材不足が見込まれ、IT予算の8割がレガシー保守に消費されています。そのなかで生産性向上率3.54〜5.23%という経営上のハードルを越えるには、人月精算を続ける旧来型の発注から、成果ベース・価値ベースの発注へ切り替えるタイミングに来ています。

ベンダーロックインや自称DX人材化、要件定義不足による炎上といった失敗パターンを事前に把握しておくことが大切です。そのうえで、ペアワーク・OJT・コードレビュー同席を通じて自社にナレッジを蓄積する仕組みを契約に組み込み、生成AI活用を前提にしたスコープ設計と運用ルールを整えることが、これからの発注実務に欠かせません。

外部に頼りながらも社内に知見を残し、内製化への橋渡しまで見据えた長期的なパートナーシップを築くことが、リソース不足の時代に勝ち抜く発注設計の本質と言えるでしょう。

▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。

会社紹介