【2026年版】開発リソース不足の解消方法｜採用・受託・SES・AI活用の選び方

開発を前に進める方法は、人を増やす4つの道と、今いる人の出力を上げる道に分かれます。違いは費用よりも、効いてくるまでの時間と、発注側が現場でどこまで指示を出せるかにあります。まず全体像を示します。

3つめの準委任は、エンジニアに一定期間チームへ入ってもらう形で、SESと呼ばれることもあります。呼び方は現場によって揺れますが、この記事では契約の呼び名として準委任を使います。

実務上いちばん誤解が多いのが、表のいちばん右にある「発注側の日常的な指示」です。受託と準委任では、発注側が相手のエンジニアに直接作業指示を出したり勤怠を管理したりすることが原則としてできません。これは商習慣ではなく法令上の区分に関わるもので、後の章で基準を示します。

選択肢を選ぶ前に、何が足りていないのかを切り分けます。実務では、人数・役割・意思決定の3つに分かれることが多く、手を打つ場所がそれぞれ違います。

実務で誤診しやすいのが3つめです。仕様が決まらないことが原因の場合、人が増えても着手できる作業が増えないため、待ち時間が積み上がるだけになりがちです。まず決める人と決め方を用意するほうが早く効きます。人数の不足に見えている状態が、実は判断待ちの滞留であることは珍しくありません。

よく引用される「79万人不足」の読み方

リソース不足の文脈では、経済産業省の調査を引いて「2030年にIT人材が最大79万人不足する」と説明されることがよくあります。ただし、この数値の位置づけには注意が必要です。経済産業省「IT人材需給に関する調査」（平成31年4月公表）の報告書を読むと、次のようになっています。

この3つは、労働生産性が年0.7%上昇するという基本ケースでの試算です。よく引用される79万人に近いのは高位、つまり需要が最も伸びた場合の数字で、真ん中の想定では45万人ほどになります。なお79万人という数値そのものは、この調査ではなく、前回にあたる2016年公表の調査（生産性の向上をゼロとして試算したもの）の高位78.9万人を指していることが多いようです。

そして、この記事の主題に直結するのが次の試算です。同じ報告書は、労働生産性の上昇率を変えた場合の需給ギャップも示しています。

生産性が1995年以降の水準まで戻るだけで、不足は3分の1近くまで縮みます。年3.54%まで上がった場合には、報告書は低位・中位・高位のすべてで需給ギャップが0になると試算しています。生産性が年2.4%で需要の伸びが低位にとどまる場合には、むしろ7.2万人の供給過剰になるという数字も示されています。つまりこの不足は、人を増やす側からだけでなく、一人あたりの生産性を上げる側からも埋まりうるものとして整理されています。

もう一点、同じ報告書は不足の中身が一様でないことも示しています。従来型IT人材（従来型システムの受託開発、保守・運用など）と先端IT人材（IoTやAIを活用したサービス）に分けた試算です。こちらも中位・生産性0.7%を前提に、従来型から先端への人材転換がどれだけ進むか（Reスキル率）で次のように変わります。

転換が進まないほど、不足は先端側に集中し、従来型はむしろ供給過剰になります。報告書はこの点について、従来型IT人材で先端IT人材を代替することは難しいため、需要を上回る従来型の供給が先端の不足を補うことは難しく、実質的にはIT人材の需給ギャップは先端IT人材の需給ギャップになると考えられる、と述べています。つまり「エンジニアが採用できない」の中身は、頭数の問題というより、必要としている領域と市場に出ている人材のズレである可能性があります。自社が探しているのがどちらなのかは、動き出す前に確認しておく価値があります。

2026年のいま、この判断にAIという変数が加わりました。AIコーディング支援ツールが実務で使われるようになり、「人を増やす」以外に「今いる人の出力を上げる」が現実的な選択肢になっています。前章の資料が示した生産性の側から埋めるという道が、以前より具体的に検討できるようになった、という位置づけです。

ただし効果は工程によって偏ります。当社でもAIコーディング支援ツールを日常的に使い、その社内導入の支援も行っていますが、実感として次のような差があります。

注意したいのは、作る速度が上がると、確認しなければならない量も増えるという点です。レビューできる人が足りていない状態でAIの導入だけを進めると、確認されないまま取り込まれたコードが積み上がることがあります。前章の切り分けで「役割・専門性の不足」に当たっていた場合、AIの導入は解決策になりにくく、むしろ負荷が集中する側を悪化させることがあります。

外部に頼む場合もAIの前提が変わっている

外部の会社やエンジニアに依頼する場合も、AIツールの利用方針を最初にすり合わせておくと後の摩擦が減ります。確認しておくと安全なのは、生成AIの利用可否と対象範囲、自社のコードや仕様を外部サービスに送信してよいか、学習に使われない契約形態を使っているか、生成された成果物の権利の扱いといった点です。禁止するか許容するかはどちらでも構いませんが、決めないまま進むと、後から確認する側の負担になります。

外部に来てもらうと決めたあと、実務でいちばん事故になりやすいのがここです。準委任や請負で来ているエンジニアに対して、発注側の社員が日々の作業指示を出したり勤怠を管理したりすると、契約の名称にかかわらず、実態として労働者派遣に該当すると判断されることがあります。いわゆる偽装請負です。

線引きは、厚生労働省の告示（いわゆる37号告示）に定められています。発注側の動きに置き換えると、次のようになります。

実務でいちばん役に立つのは、進捗や稼働状況を把握すること自体は妨げられていない、という点です。告示は労働時間の項目に「単なる把握を除く」と明記しています。線が引かれるのは、把握を超えて発注側が勤怠を管理し始めたときです。同じように、作ってほしいものを伝えることと、担当者個人に手順を指示することも別のことになります。

受託開発とSESの両方の事業を行っている立場から見ると、外部の力で解消しやすい状況と、しにくい状況があります。ここでは後者を挙げますが、いずれも対処の方向があるので、あわせて書きます。

レビューできる人が社内にいない

外部のエンジニアが書いたコードや設計を、社内の誰も判断できない状態で人数だけ増やすと、確認されないまま積み上がったものが後で問題になりやすくなります。AIの導入も同じ構造で、作る速度が上がるほどこの負荷は増します。対処としては、社内のレビュー担当を決めて稼働の一部をレビューに充てるか、レビューや設計の役割まで含めて依頼するかのどちらかです。増やす前に、増えたものを受け取る側の体制を先に決めておくと安定します。

何を作るかが決まっていない

仕様が固まっていない段階で人数を増やすと、待ち時間が増えます。この場合は、作る人を増やすより先に決める工程に人を入れるほうが効きます。要件を固める作業自体を外部と一緒に進める方法もあり、進め方はシステム開発の要件定義の進め方にまとめています。準委任は仕様が動くことを前提にできるため、この段階と相性がよい面があります。

引き継ぐための情報が残っていない

設計の意図や運用の手順が特定の人の頭の中にしかない状態では、外部の人が立ち上がるまでに時間がかかり、その間は既存メンバーの説明工数が増えます。短期で終わる依頼ほど、この立ち上がりの負担が相対的に大きくなります。対処としては、最初の数週間を情報の整理と引き継ぎ資料の作成に充てる前提で計画を組むことです。ここを工数に見込んでおかないと、想定より遅れたように見えます。

人月単価そのものの相場は媒体によって幅があり、同じ職種でも提示額が大きく異なります。金額の目安はシステム開発の外注先の選び方にまとめているため、ここでは金額以外で総額が変わる条件を挙げます。見積もりを比べるときは、単価だけでなく次の項目をそろえないと比較になりません。

とくに精算幅は月々の請求額に直結しますが、見積書の脇に小さく書かれていることがあります。稼働が読みにくいプロジェクトほど、幅が広いほうが振れが小さくなります。単価が同じでも、ここの条件で年間の総額は変わります。

問い合わせの前に次の5点を決めておくと、初回の打ち合わせで具体的な話に入れます。すべてが固まっている必要はなく、決まっていないことを決まっていないと言える状態であれば十分です。

1. 01何が足りていないか（人数・役割や専門性・決める人のどれか）
2. 02いつまでに、どの状態になっていればよいか
3. 03社内の誰が窓口になり、誰が仕様の判断をするか
4. 04レビューを社内で行うか、依頼範囲に含めるか
5. 05生成AIの利用について、範囲と可否をどう考えるか

3つめの窓口と判断者は見落とされやすい項目です。外部の稼働が止まる原因は、技術的な難しさよりも、判断が返ってこないことである場合が少なくありません。窓口を決め、返答にかかる時間の目安を共有しておくと、着手後の進みが変わります。