システム開発を発注・外注する進め方は、契約形態に応じて手段を選び、7段階の流れを発注側が主導して設計することが基本です。
経済産業省の試算では2030年に最大約79万人のIT人材が不足するとされ、こうした状況のなかで、外部に発注・外注する以外の選択肢を持たない企業は今後さらに増えていきます。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
- IT人材不足の構造：外部発注の戦略が必要になる理由
- 外注手段の選び分け：請負、準委任、ラボ型など、案件に合う手段を選びます
- 失敗の回避：RFP、候補選定、契約の段階で起きやすい問題を避けます
- 活用策：生成AI、補助金、ナレッジの社内残存を発注に組み込みます
IT人材不足の全体像と発注戦略が必要な理由
IT人材不足は、採用が難しいという現場の感覚にとどまらず、国の将来予測でも具体的な数字で示されています。発注・外注に踏み切る前に、なぜ外部への依存を高めざるを得ないのか、その構造的な背景を理解しておくことが、発注戦略の前提になります。
2030年79万人不足という前提条件
経済産業省の試算によれば、2030年時点でIT人材は低位16.4万人、中位44.9万人、高位78.7万人の不足が予測されています。さらに2040年には、AI・ロボット関連の専門人材だけで約326万人から339万人が不足するという厳しい見通しが公表されています。
この需給ギャップをゼロに近づけるには、IT業界全体で毎年3.54%から5.23%という極めて高い生産性向上が継続的に必要だと示されています。このため、採用や育成だけで自社の人材を充足するのは現実的ではなく、発注・外注を一時的な救済策ではなく、IT投資の恒常的な構成要素として再設計する段階に入っています。
また「2025年の崖」と呼ばれる課題では、対応が遅れた場合に最大12兆円規模の経済損失リスクが指摘されています。レガシー保守と新規DXの両立は、内製だけでは事実上不可能に近い水準です。発注先を選ぶ前に、この構造を経営層と共通認識として持っておくことが成功の出発点になります。
地方偏在とIT予算硬直化による発注の加速
もう一つ見落とされやすいのが、AI専門人材の地理的な偏在です。経産省関連の分析では、1都3県を除くと、AI・データサイエンス領域の専門職を充足できる地域はほぼ存在しないという結果が出ています。
そのため、地方拠点を持つ企業や、本社所在地が首都圏以外の中小企業では、現地採用での内製化はほぼ不可能です。必然的に、リモート分散開発が可能な外部パートナーへの発注が中心戦略になります。
加えて、国内企業のIT関連費用の約80%は、既存システムの維持やレガシー保守に費やされているとされます。新規DXや競争力強化に振り向けられる予算は2割しか残らないため、社内エンジニアの工数を新規開発に割く余裕は限られます。だからこそ、保守は外部委託に集約し、新規開発は生成AIを併用した発注で生産性を底上げするといった、明確な発注戦略の設計が欠かせません。
発注・外注・委託の主要な手段と選び分け
IT人材不足に対して取り得る発注手段は、受託開発、SES（システムエンジニアリングサービス）、ラボ型開発、オフショア・ニアショア、フリーランス活用、技術顧問・CTO代行の6種類に整理できます。それぞれコスト感や契約期間、ノウハウ移管のしやすさ、品質管理の難しさが異なるため、自社の課題と組み合わせて選び分けることが重要です。
特に発注実務で迷いやすいのは、契約形態と案件規模に応じた使い分けです。
請負・準委任・ラボ型の使い分け
請負契約は、成果物の完成責任を発注先が負う形態で、要件が明確な業務システムや改修案件に適しています。一方、準委任契約は業務の遂行そのものを委託する形態で、要件が流動的なアジャイル開発や新規プロダクト開発と相性が良く、近年は準委任を選ぶ発注者が増えています。
両者の中間に位置するのがラボ型開発です。一定期間チームを確保しつつ開発の範囲を柔軟に調整でき、継続的な機能追加が必要なSaaSやWebサービスで活用が広がっています。
選び分けの目安は、初回の業務システム刷新や1回限りの開発なら請負、要件が固まらないMVP開発やUI改善の繰り返しなら準委任です。半年から1年以上にわたって機能追加と改修を続けるなら、ラボ型を選ぶと契約上のトラブルを減らしやすくなります。経産省の検討会では「人月商売」からの脱却が議論されており、長期的には成果や価値に応じた契約も視野に入れておくとよいでしょう。
オフショア・フリーランス・技術顧問の役割
オフショア開発は、東南アジアやインドの開発拠点を活用する手段で、ベトナム・フィリピン・インドなどが挙げられます。人月単価を国内の3〜6割程度まで抑えられるケースが多く、大規模で仕様が明確な開発に向いています。ただし、ブリッジSEの質や時差・言語によるコミュニケーションコストが品質を左右するため、要件定義は国内で固めてから渡す役割分担が欠かせません。
フリーランスは、即戦力の専門スキルをスポットで補う用途に適しており、短期間の高単価でも投資対効果が見合う領域に活用するのが基本です。技術顧問やCTO代行は、社内にエンジニアがほとんどいない企業が、外注先の選定や技術判断を中立的に行うためのアドバイザーを置くサービスです。
月10〜30万円程度の費用感で、ベンダー丸投げを防ぐ「翻訳機能」と「監査機能」を持てるため、初めてシステム開発を発注する企業ほど効果が高いです。さらに、これら6種類を組み合わせ、戦略レイヤーは技術顧問、コア機能は国内ラボ型、定型実装はオフショアという三層構造を組むケースが増えています。
失敗しない発注フローの設計
発注フローは7段階で進めるのが基本です。前半は課題定義、要件整理、RFP作成、候補選定で、後半は提案評価、契約締結、キックオフです。
IT人材不足を理由に発注する企業ほど、社内に要件をまとめきれる人がいないという問題に直面します。ここを曖昧にしたまま見積依頼を出すと、後工程で必ず追加費用と納期遅延が発生します。発注の成否はベンダー選定よりも発注側のフロー設計で7割が決まるため、準備はこの段階から進めるべきです。
要件整理とRFP作成のポイント
要件整理では、まず「達成したい業務成果」「現状の業務フロー」「制約条件（予算・期間・既存システム連携）」の3点を整理します。RFP（提案依頼書）には、これら3点に加えて「絶対要件」と「希望要件」を明示的に区別して記載することが重要です。
すべてを必須要件にすると見積額が膨らみ、削れない機能との境界も曖昧になって、後の交渉余地を失います。RFPに含めるべき基本の8点は、前半と後半に4点ずつ分かれます。前半では、プロジェクトの背景と目的、現状業務と課題を伝えます。続けて、対象範囲とスコープ、機能要件と非機能要件を示します。
後半は、発注の条件と提案の進め方に関わる項目です。
- 既存システム連携要件：連携する既存システムと、つなぐ範囲を明記します
- 提案ステップと評価方法：提案の進め方と、比べる基準を決めておきます
- 契約形態・予算レンジ・希望スケジュール：契約の形、予算の幅、希望時期を示します
- 情報セキュリティ要件：扱うデータと守るべき水準を明記します
社内にRFPを書ける人材がいない場合は、技術顧問やコンサルティング会社にRFP作成の支援だけを依頼するという選択肢もあり、結果として全体のコストを下げる効果があります。
候補選定と提案評価のチェック項目
候補選定では3〜5社に絞って提案を受けるのが現実的です。多すぎると比較の工数が膨大になり、少なすぎると交渉条件が不利になります。
評価項目は6つの観点で点数化して比較します。技術力や業務理解度、プロジェクト管理体制に加えて、ノウハウ移管姿勢、契約柔軟性、トラブル時の対応力を見ます。特に「バズワードに詳しいだけの人材か、課題を根本から解決できる実力者か」は、類似案件の失敗とその対処を具体的に語れるかで見分けられます。
また、提案フェーズではあえて「自社では何ができないか」を率直に語る会社を加点評価するのがおすすめです。何でもできると主張する会社より、得意と苦手を切り分けて説明できる会社のほうが、実プロジェクトで誠実に対応する傾向があります。さらに、提案書だけでなく担当予定のエンジニアと面談して現場の人物を確認すると、契約後のミスマッチを大きく減らせます。
失敗パターンとベンダーロックイン対策
IT人材不足下での発注で頻発する失敗は、要件定義不足による「使えないシステム納品」、ベンダー任せの「丸投げ運用」、特定ベンダー以外が手出しできなくなる「ベンダーロックイン」の3つに集約されます。
これらは個別の失敗というより、発注側がコントロール権を放棄したときに必ず発生する構造的な問題です。契約段階で対策を盛り込めるかどうかが、分かれ目になります。
よくある失敗と回避策
失敗パターンは大きく4つに分けて押さえておくと、契約交渉の論点が明確になります。一つ目は、要件定義が不足したまま着手し、後工程で大量の追加要件が発生して予算を超えるケースです。二つ目は、現場へのヒアリングが足りず、使われないシステムが納品されるケースです。
三つ目は、発注側のPMが不在で進捗を管理できず、ベンダーの言うままに納期遅延を受け入れてしまうケースです。四つ目は、受け入れテストとレビューの機能が形骸化し、品質問題が本番稼働後に噴出するケースです。これらを防ぐ回避策の核心は、発注側に決裁できるPMと、業務を語れる現場リーダーを必ず配置することです。
社内にPM経験者がいない場合は、外部のPMOサービスやプロジェクトマネジメント代行を併用します。月数十万円のコストがかかっても、数千万円規模の案件であれば、失敗時の損失と比べて投資対効果は高くなります。あわせて、要件定義と開発を別契約にして、要件定義の成果物を見てから開発の発注先を最終決定する「二段発注」も有効です。
ベンダーロックインを避ける契約条項
ベンダーロックインの本質は、「ソースコード・設計書・運用ノウハウが特定ベンダー側にしか存在しない状態」を放置してしまうことです。契約段階で必ず盛り込みたい条項は、次の4点です。一つ目と二つ目は、成果物の著作権を発注側に帰属させることと、ソースコードと設計書を月次もしくはマイルストーンごとに納品させることです。
三つ目は、サードパーティの汎用フレームワーク・ライブラリを優先して採用し、独自実装を最小限にすることです。四つ目は、運用ドキュメントとAPI仕様書を常に最新の状態に保つ義務を課すことです。加えて、発注先と自社メンバーによる共同コードレビュー、ペアプロ枠の月数時間の設定、定例の技術勉強会での実装意図の共有を、「ナレッジ移管の機会」として契約上の責務に明文化しておくと効果的です。
また、日立製作所が整備した生成AI共通基盤の事例のように、開発フレームワーク自体を社内資産化する動きが大手企業で広がっています。中小企業も、規模を縮小して同じ考え方を取り入れるべき段階に来ています。
生成AIと外注のハイブリッド活用
2024年以降、生成AIを前提とした発注設計が現実的な選択肢になりました。NTTデータは、航空券予約システムのJava 8から17へのバージョンアップで、約16,000ステップのうち非互換が含まれる約5%の作業に生成AIを活用し、手作業と比べて大幅な生産性向上を実現しています。
日立製作所も、ミッションクリティカル領域のナレッジと生成AIを掛け合わせた共通基盤を整備し、開発プロセス全体の効率化を進めています。こうした事例から分かるのは、生成AIは外注の代わりではなく、外注と組み合わせて生産性を倍増させる手段だということです。
生成AIを前提としたスコープ設計
発注時に「どの工程で生成AIを使うか」をスコープに明示的に組み込むと、見積額を圧縮しつつ品質も担保できます。具体的には、コード自動生成、テストケース作成、既存コードのリファクタリングといった定型タスクは、生成AI活用を前提に、人月単価ではなく成果物単価で発注する設計が現実的です。ドキュメント自動生成とデータ移行スクリプト作成も定型タスクに含まれます。
経産省の検討会でも「人月商売」からの脱却が議論されており、生成AIで生産性が倍増する作業を従来の人月で発注し続けると、発注側にとって明確な不利益になります。一方で、要件定義やアーキテクチャ設計、複雑な業務ロジックの判断などの高度な意思決定の領域は、引き続きシニアエンジニアの人月で発注すべき領域として残ります。
発注者は、スコープ表に「AI活用前提タスク」と「人月発注タスク」を区別して記載し、それぞれの単価の考え方を分けて示すことで、妥当な総額を交渉しやすくなります。
生成AI活用時の運用ルール整備
生成AIを外注先が活用する前提では、機密情報の取り扱いとハルシネーション（誤情報生成）への対応が必須の論点になります。具体的には、プロンプトに自社の機密情報や個人情報を入力させないことと、商用利用可能なエンタープライズ版を契約することです。出力されたコードや文書は、必ず人間がレビューします。
これら3点は、契約書と運用ガイドラインに明記しておく必要があります。実際に、生成AIへの業務プロンプトの入力で機密情報が外部に漏洩するインシデントは複数報告されています。そのため、契約段階で運用範囲を限定することが、リスクマネジメントとして欠かせません。
また、生成AIの出力をそのまま納品物として受け取らないよう、契約書には3つの条項を盛り込みます。利用範囲の成果物単位での明示、レビュー責任者の明確化、品質基準を満たさない場合の手戻り条項の設定です。生成AIで生産性が上がる時代だからこそ、AIに任せきりで人がチェックしない発注を避けるガードレールの設計が、成果の安定に直結します。
補助金活用とナレッジ社内残存の戦略
IT人材不足下での発注は、単発の取引で終わらせず、補助金で実質コストを下げつつ自社にノウハウを蓄積していく中長期の戦略として設計するのが理想です。発注総額の3分の1から2分の1を補助金で賄えるケースもあり、同じ予算で得られる成果を最大化できます。
同時に、ナレッジが外部に流出したまま戻ってこない状況を避けるための「社内残存設計」が、次の発注を有利にする土台となります。
主要な補助金・助成金の組み合わせ
発注と相性が良い制度としては、IT導入補助金、ものづくり補助金、事業再構築補助金が代表的です。加えて、人材開発支援助成金とキャリアアップ助成金も挙げられます。このうちIT導入補助金は、中小企業がITツールを導入する際に費用の最大2分の1から4分の3を補助する制度です。
この補助金は業務システムの導入と相性が良く、認定IT導入支援事業者を通じて申請します。人材開発支援助成金は、社内人材のリスキリングに使えるため、外注と並行して社内エンジニアを育成する場合の追加の原資として有効です。補助金申請は事業計画書の作成に想像以上の工数がかかり、社内で完結しにくい場合は、申請代行サービスや認定支援機関を活用するのが現実的です。
なお、代行費用は採択額の10〜20%が相場ですが、採択確率を高め、申請工数を減らす点で投資対効果は十分あります。公募開始から採択までは2〜4ヶ月かかるため、発注計画と補助金スケジュールを逆算し、要件定義と並行して申請準備を進めると、機会損失なく実装に進めます。
ナレッジを社内に残す具体プロセス
外部発注のたびに自社にナレッジが蓄積されないのは、日本企業が多重下請け構造の中で長年抱えてきた構造的な問題です。これを発注プロジェクト単位で解消する具体策は4つあり、社内メンバーを最低1人専任でプロジェクトに配置することと、コードレビューと設計レビューに社内メンバーが必ず参加することです。
残る2つは、設計判断の議事録と決定根拠を社内ドキュメントに集約すること、月次でベンダーから技術勉強会を実施してもらうことです。この4つを実装するだけでも、効果は大きく変わります。一歩進めた施策として、ペアプロ枠を契約に明文化すること、引継ぎ研修を成果物として納品させること、保守運用マニュアルを動画で残してもらうことも有効です。
これらの積み重ねが、3年後5年後の発注交渉力を決めます。外部発注をコストではなく、自社の技術資産化への投資という観点で設計することが、IT人材不足の時代における持続的な競争力につながります。
まとめ
IT人材不足の発注・外注・委託は、2030年に79万人が不足するという前提のもとで、企業のIT投資戦略に恒常的に組み込むべき段階に入っています。発注手段は6種類あり、受託開発、SES、ラボ型開発を含め、案件の特性に応じて使い分けます。残る3種類は、開発拠点、専門スキル、技術判断を外部から補う手段です。
- オフショア・ニアショア：開発拠点を活用して、コストを抑える手段
- フリーランス活用：即戦力の専門スキルを、スポットで補う手段
- 技術顧問・CTO代行：外注先の選定や技術判断を、中立的に行う手段
発注側が主導して、課題定義から候補選定までの前半と、提案評価から契約締結、キックオフまでの後半からなる7段階の発注フローを設計することが、成功の起点になります。
失敗の大半は発注側のコントロール権の放棄から生じるため、PMの配置とベンダーロックイン回避の契約条項を、契約段階で必ず組み込んでおきましょう。生成AIを前提としたスコープ設計と、補助金を組み合わせた実質コストの削減が、これからの発注成果を大きく左右します。加えて、ナレッジを社内に残すためのレビューやペアプロ、引継ぎを実装することも欠かせません。
外部発注をコストではなく自社の技術資産化への投資と捉え、3年後5年後の発注交渉力を高める長期戦略として、今回紹介したフレームを自社の状況に合わせてアレンジしてください。IT人材不足を逆手に取って強い発注体制を作り上げる企業こそが、これからの10年で競争優位を築いていきます。
RFP作成前に、Webサービス開発の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックをご活用ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。