まいどおおきに、ASAKURAの朝倉です。

今日は中小企業の社内開発体制について綴っていきます。

「うちもエンジニアを1人採用したほうがいいでしょうか」

ここ最近、この相談が明確に増えました。生成AIでコードが書ける時代になり、内製化という言葉が広まり、外注費の見積を見て「これなら自社でやったほうが」と考える経営者が増えています。

先に結論を書きます。

中小企業にとって、フル内製も完全外注も、どちらも正解ではありません。そして「エンジニアを1人採る」は、多くの場合いちばん危険な選択です。

理由は本文で数字を挙げて説明しますが、要点は「1人目のエンジニアを、社内の誰も評価できない」という一点に集約されます。

現実解は、社内に業務を言語化できる人を1人置き、作る仕事は外に出し、その両者をつなぐ技術的な判断を、作る側とは別の第三者が担う形です。この記事では、なぜその形になるのかを、統計と開発方法論の両面から順に説明します。

アジャイル、スクラム、XP、クリスタル、DevOps、MLOps。これらの言葉も扱いますが、用語解説が目的ではありません。中小企業の規模と人数で、どれが使えて、どれが使えないのかを判断できるようにすることが目的です。

前提：日本の中小企業が置かれている構造

精神論の前に、条件を確認します。

IT人材はユーザー企業側にいない

総務省の平成30年版情報通信白書は、IPAのIT人材白書2017を引きながら、日本のIT人材は72%がベンダー企業に属し、米国は65%がユーザー企業に属すると整理しています。カナダ、英国、ドイツ、フランスでもユーザー企業側が5割を超えており、日本だけが突出してベンダー側に偏っています。

これは「日本企業の意識が低い」という話ではありません。労働市場の構造がそうなっている、という話です。つまり、中小企業が「エンジニアを採用しよう」と思っても、そもそも採用市場にいる人の多くはIT企業に所属しており、そこから引き抜く前提の勝負になります。

中小企業には情シスがいない

kubellストレージが2026年5月に公表した調査では、中小企業の約65%が専任の情報システム担当者を置いていないという結果が出ています。

つまり、多くの中小企業には「ITのことを判断する人」が構造的に不在です。エンジニアを採るかどうか以前に、採ったエンジニアの仕事を評価できる人がいません。

人材不足は改善していない

IPAが2026年7月に公表した「DX動向2026」では、DXを推進する人材の量について「やや不足している」「大幅に不足している」の合計が85.5%で、2024年度、2023年度とほぼ同水準でした。3年間、改善していないということです。

同調査ではAIの導入状況も規模別に出ています。従業員1001人以上の企業では約8割が導入済みである一方、101人以下では16.6%にとどまりました。規模による差が広がっています。

採用市場の温度

厚生労働省の統計をもとにした集計では、2026年5月時点のITエンジニアの新規求人倍率は3.2倍でした。前年同月の3.4倍からはわずかに下がっているものの、依然として売り手市場です。求人統計データによるシステムエンジニアの平均年収は約509万円とされています。

年収509万円は、社会保険料や採用コスト、機材、教育を含めると、企業側の実負担は700万円前後になります。A社の外注見積600万円と比べるとき、この数字で比較しなければ意味がありません。

そして重要なのは、A社が700万円を払ったとして、3.2倍の倍率の市場で、地方の中小企業が経験者を採れるかどうかです。

この節のまとめ

条件	数字	意味
IT人材の所在	日本は72%がベンダー企業（米国は65%がユーザー企業）	採用市場の母集団が薄い
専任情シスの不在	中小企業の約65%	採っても評価できない
DX人材の不足感	85.5%が不足（3年間ほぼ横ばい）	競合も同じ条件で奪い合っている
ITエンジニア求人倍率	3.2倍（2026年5月）	買い手市場ではない

この条件下で「まず1人採る」を選ぶのは、勝ち目の薄い勝負です。だからといって全部外注すれば済むわけでもない、というのが次章以降の話になります。

手法の地図：何がどのレイヤーの話なのか

社内でこの議論をすると、たいてい噛み合いません。理由は単純で、レイヤーの違うものを並べて比べているからです。

まず地図を作ります。

アジャイル：思想であって、手順書ではない

2001年のアジャイルソフトウェア開発宣言が起点です。要約すると、プロセスやツールより人と対話を、包括的なドキュメントより動くソフトウェアを、契約交渉より顧客との協調を、計画に従うことより変化への対応を重視する、という価値観です。

誤解されやすいのは、右側を否定していない点です。宣言は「左側をより重視する」と言っているだけで、ドキュメントも計画も契約も要らないとは言っていません。

「アジャイルだから仕様書は書きません」と言うベンダーがいたら、それはアジャイルの誤読です。発注者として指摘してよい箇所です。

スクラム：短く区切って、動くものを見る

最も普及しているフレームワークです。構成は次のとおりです。

• 3つの責任（プロダクトオーナー、スクラムマスター、開発者）
• 短い期間の区切り（スプリント。1〜4週間）
• 5つのイベント（スプリント計画、デイリースクラム、スプリントレビュー、レトロスペクティブ、そしてスプリント自体）
• 3つの作成物（プロダクトバックログ、スプリントバックログ、インクリメント）

重要なのはチームの規模です。スクラムガイドは、スクラムチームを「通常10人以下」と規定しています。少人数で、コミュニケーションのコストを抑えるための設計です。

XP：どう作るかの技術的な実践

スクラムが「進め方」の型であるのに対し、XPは「作り方」の実践です。

• ペアプログラミング（2人で1つの画面を見て書く）
• テスト駆動開発（テストを先に書く）
• 継続的インテグレーション（頻繁に統合して壊れていないか確認する）
• 小さなリリース
• リファクタリング（動作を変えずに構造を整える）
• シンプルな設計

スクラムには技術的な実践が含まれていません。だから「スクラムを導入したが、品質が上がらない」ということが起きます。進め方だけ変えても、書き方が変わらなければ結果は変わらないからです。

発注者としてXPの用語を全部覚える必要はありませんが、「自動テストは書きますか」「継続的インテグレーションは回していますか」の2つは、見積の場で聞く価値があります。答えられないベンダーは、後の保守で高くつきます。

クリスタル：中小企業に最も示唆がある考え方

アリスター・コーバーンが提唱した方法論群です。ほとんど知られていませんが、中小企業にとっては最も実用的な考え方を含んでいます。

クリスタルの中心にあるのは、「唯一の正しい方法論は存在しない」という立場です。プロジェクトの人数と、失敗したときの重大度によって、方法論の「重さ」を変えるべきだとしています。色で区分されており、少人数はクリスタル・クリア、人数が増えるにつれてイエロー、オレンジ、レッドと重くなります。

つまり、6人のチームに大企業向けの重厚な手順を持ち込むのは間違いだし、逆に人命に関わるシステムを軽い手順で作るのも間違いだ、という主張です。

中小企業の開発体制を考えるとき、この視点が効きます。「大企業がやっているからスクラムを完璧にやろう」ではなく、「うちの人数と、失敗したときの損害から逆算して、どこまで手順を軽くできるか」を考える。これが正しい問いです。

DevOps：作った後の話

開発（Development）と運用（Operations）の分断をなくす考え方と実践です。従来、開発チームは「早く新しい機能を出したい」、運用チームは「変更を減らして安定させたい」と、利害が対立していました。DevOpsは、この対立を組織と自動化で解消しようとします。

Googleが継続しているDORA（DevOps Research and Assessment）の研究では、長らく4つの指標でデリバリー性能を測ってきました。

指標	内容
デプロイの頻度	どれくらい頻繁にリリースできるか
変更のリードタイム	コードを書いてから本番に出るまでの時間
変更失敗率	リリースのうち障害になった割合
復旧時間	障害から回復するまでの時間

この4つが優秀な組織は、速さと安定性を同時に達成しているというのがDORAの一貫した発見でした。速いから雑、ではないということです。

MLOps：モデルは腐る

機械学習をシステムとして運用するための考え方です。DevOpsとの決定的な違いは、機械学習モデルが時間とともに劣化することです。

通常のプログラムは、環境が変わらなければ昨日と同じ結果を返します。機械学習モデルは、現実世界のデータの傾向が変わると、コードを1行も変えていないのに精度が落ちます。これをデータドリフト、あるいはコンセプトドリフトと呼びます。

だからMLOpsには、通常の開発にはない工程が入ります。データの収集と検証、特徴量の管理、モデルのバージョン管理、精度の継続監視、再学習のパイプライン。作って終わりにできない構造になっています。

MLOpsが必要かどうかの判断は第5章で扱いますが、先に結論を書いておくと、自社でモデルを学習させるのでなければ不要です。

中小企業でスクラムはそのまま導入できるか

結論から言うと、そのままでは難しく、しかし考え方の大半は使えます。

数字で見る日本の現在地

IPAのDX白書2021では、日本企業のアジャイル開発の活用が19.3%、米国が55.0%、DevOpsは日本10.9%に対し米国52.6%という差が出ていました。この差はよく「日本は遅れている」と語られますが、原因の一部は第1章の構造にあります。開発チームが社外にいる状態では、アジャイルもDevOpsも成立しにくいのです。

何がボトルネックになるか

スクラムが中小企業でうまくいかない原因は、人数ではありません。専任性です。

スクラムは、スプリントという期間中、チームがその仕事に集中できることを前提にしています。ところが中小企業では、開発に関わる人が全員兼務です。営業と兼務、経理と兼務、社長が兼務。

すると、次のことが起きます。

• スプリント計画で決めた作業量が、突発の業務で崩れる
• デイリースクラムの時間に、誰かが必ず現場に出ている
• スプリントレビューが延期され、フィードバックが遅れる
• 数回崩れると、誰も計画を信じなくなり、形骸化する

これは「意識が低い」のではなく、設計の前提が合っていないだけです。

残すもの、緩めるもの

クリスタルの考え方を借りて、重さを調整します。

スクラムの要素	中小企業での扱い	理由
短いサイクルで区切る	残す。ただし2週間より4週間を検討	兼務前提だと2週間は短すぎることが多い
動くものを実際に触って確認する	必ず残す	ここを飛ばすと外注の失敗が確定する
優先順位を1本のリストで持つ	必ず残す	複数の要望リストがあると必ず揉める
振り返り（レトロスペクティブ）	残す。月1回でよい	改善が回るかどうかの分岐点
役割の厳密な分離	緩める	3人で3役を分ける意味は薄い
デイリースクラムを毎日定時	緩める。週2回でも可	全員が集まれない日を前提に設計する
ベロシティの精緻な計測	当面やらない	兼務前提では数値が安定せず、意味を持たない

必ず残す2つ、「動くものを触って確認する」と「優先順位を1本のリストで持つ」は、外注する場合でも同じです。むしろ外注のときこそ効きます。

なぜなら、外注の失敗のほとんどは「完成してから、想像と違うことに気づく」で起きるからです。2週間ごとでも1か月ごとでも、動くものを触っていれば、ズレは早期に見つかります。

A社が600万円のアプリを外注するとき、契約に入れるべきは詳細な仕様書ではなく、「4週間ごとに動くものを触らせてもらう」という一文です。

DevOpsは中小企業に関係があるのか

あります。ただし、始める順番があります。

AIは増幅装置であって、解決策ではない

2025年のDORAレポート（約5,000人への調査）は、AI支援開発をテーマにしていました。回答者の90%が日常の開発で何らかのAIを使っていると回答しています。

そのうえで報告されている発見が、この記事の主題と直結します。

AIは組織の卓越性を生み出すのではなく、既にあるものを増幅する。基盤のしっかりした組織ではAIは強力な加速装置になり、機能不全の組織では混乱を拡大させる。

さらに、AIの導入はデリバリーのスループット（出せる量）を押し上げる一方で、不安定性の増加とも相関しており、変更の失敗や手戻りが増える傾向が報告されています。テスト、コードレビュー、品質保証といった下流の工程が、加速したペースに追いつけていない、という指摘です。

この発見の実務的な意味は明確です。

「生成AIでコードが書けるようになったから内製できる」は、半分正しく、半分危険です。書く速度は上がります。しかし、書かれたものが正しいかを確認する仕組みがなければ、速く壊れるだけです。そして中小企業には、その確認をする人がいない。第1章の65%がここに効いてきます。

中小企業が踏むべき順番

DevOpsの完全形を目指す必要はありません。順番だけ守ってください。

段階	やること	効果
1	バージョン管理（Git）を必ず使う	誰がいつ何を変えたか追える。戻せる
2	自動テストを最低限書く	直したつもりが壊す事故を防ぐ
3	自動デプロイ（CI/CD）	リリースが属人化しない
4	監視とログ	障害に気づけるようになる
5	頻繁な小さいリリース	変更が小さいほど原因究明が速い

外注する場合も、段階1〜3を「やってもらえるか」は必ず確認してください。ソースコードがベンダーのローカルPCにしかない状態は、実際にあります。この状態で担当者が退職すると、資産がゼロになります。

MLOpsを検討する前に

AIの話が出ると、すぐにMLOpsという言葉が出てきます。判断の前に、数字を2つ置きます。

Gartnerは、生成AIプロジェクトの少なくとも30%が2025年末までに概念実証（PoC）の後に見送られると予測していました。理由として、データ品質の低さ、不十分なリスク管理、コストの増大、ビジネス価値の不明確さを挙げています。

さらに、MITのProject NANDAが2025年に公表した「The GenAI Divide」では、企業が生成AIに投じた金額が世界で300〜400億ドル規模に達する一方、95%の組織では損益への貢献が測定できなかったと報告されています。

IPAのDX動向2026も同じ方向を示しています。AI導入による具体的な効果として「業務が効率化したり迅速化した」が91.6%と最多である一方、「顧客満足度が向上した」は4.5%、「売上や利益が向上した」は3.9%にとどまりました。

つまり、AIは動いているが、事業の数字には届いていない、というのが現在地です。

MLOpsが必要になる条件

判断は単純です。

状況	MLOpsは必要か
SaaSに付いているAI機能を使う	不要
生成AIのAPIを呼ぶだけの機能を作る	ほぼ不要（プロンプトとログの管理は要る）
自社データで独自にモデルを学習させる	必要
予測結果が業務判断に直結し、精度低下が損失になる	必要

中小企業のほとんどは上2つに該当します。その場合に必要なのは、MLOpsの体制ではなく、次の3つです。

• どの業務のどの判断を、どれだけ速くするのかを定義すること
• 入力するデータが整っているかを確認すること（第1章の話と同じで、マスタが汚ければAIも汚い答えを返します）
• やめる基準を先に決めること（撤退基準がないPoCは、永遠に終わりません）

MLOpsの導入を提案されたら、「うちは自社でモデルを学習させるのですか」と1つ聞いてください。答えが「いいえ」なら、その提案は過剰です。

内製か外注か：4つの選択肢

ここが本題です。二択ではなく、4つあります。

形	内容	向く条件	主なリスク
A：完全外注（請負）	仕様を決めて発注し、納品を受ける	要件が固まっている。変更が少ない	変更に弱い。運用で毎回発注が必要
B：準委任・ラボ型	一定期間、外部チームの稼働を確保する	変更が多い。継続的に開発する	発注側に判断できる人が要る
C：ハイブリッド	社内に企画・要件・運用、外部に実装	中小企業の多くがここ	社内側の1人に負荷が集中する
D：フル内製	社内にエンジニアを雇用する	開発が事業の核。継続的な開発量がある	採用・評価・定着のすべてが困難

Dの落とし穴：1人目のエンジニア問題

「まず1人採ってみる」が危険な理由を、3つに分けて説明します。

問題1：評価できない 社内の誰も技術を判断できない状態でエンジニアを採ると、その人の仕事が速いのか遅いのか、書いたコードが健全なのか将来の負債なのかを、誰も判断できません。本人の自己申告がそのまま評価になります。これは本人にとっても不幸です。

問題2：育てられない 1人目には先輩がいません。技術的な相談相手も、レビューしてくれる人もいない。成長が止まり、市場価値の観点から転職を考えるのは自然な流れです。第1章のとおり求人倍率3.2倍の市場ですから、動けば動けます。

問題3：辞めると全部止まる 1人しかいない状態を、開発の世界ではバス係数1と呼びます。その人が明日いなくなったらプロジェクトが止まる、という意味です。仕様が頭の中にしかない、環境構築の手順が本人しか知らない、パスワードが本人のPCにしかない。実際に起きます。

ではCが正解か

多くの場合そうなりますが、Cにも弱点があります。社内側の1人に、要件定義、優先順位づけ、テスト、社内調整、そしてベンダーとの技術的な折衝までが集中する点です。

このうち、最後の「技術的な折衝」だけは、業務に詳しい社員には荷が重い。見積の妥当性、提案されたアーキテクチャの是非、契約に含まれる保守の範囲、AIを使うという提案の実効性。これらを判断するには技術的な素養が要ります。

そして、ここを実装ベンダー自身に判断してもらうことはできません。自分の見積の妥当性を自分で評価してもらうことになるからです。利益相反です。

現実解：4つ目の役割

当社の以前のコラム（中小企業の基幹システム設計）で、必要な役割は3つだと書きました。決める人（経営者）、翻訳する人（社内）、作る人（外部で可）。開発体制を考えるとき、ここに4つ目が必要になります。

役割	内容	誰が担うか	外注できるか
A：決める	投資判断、優先順位、業務変更の承認	経営者	できない
B：翻訳する	業務要件の言語化、テスト、社内調整	業務に詳しい社員	最も外注しにくい
C：作る	設計、実装、インフラ、保守	外部パートナー	できる
D：評価する	技術的な妥当性の判断、ベンダー選定、契約条件の確認	作る人とは別の第三者	できる。むしろ外に置くべき

Dを「作る人」と同じ会社に任せると、評価が甘くなります。分けるべき理由はそれだけです。

大企業はこのDをCTOや情報システム部門が担っています。中小企業でフルタイムのCTOを雇うのは現実的ではないため、技術顧問、あるいは月に数日だけ関わる外部のCTO的な立場（フラクショナルCTOと呼ばれます）という形が取られます。

契約で決めておくこと

Dの役割が担うべき、具体的な確認事項を挙げます。発注前にこれを確認しておくかどうかで、3年後の自由度が変わります。

項目	確認すること
契約形態	請負か準委任か。アジャイルで進めるなら準委任が整合的
ソースコードの帰属	著作権は誰に帰属するか。納品物に含まれるか
リポジトリ	どこで管理し、発注者側もアクセスできるか
アカウント名義	ドメイン、クラウド、各種SaaSの契約名義は誰か
データの所有権	蓄積されたデータを、契約終了時に取り出せるか
保守の範囲	障害対応だけか、軽微な変更を含むか。時間外はどうか
引き継ぎ条件	他社に移す場合、何をどの形式で渡してもらえるか
開発環境の再現性	手順書があり、他者が構築できるか

なお、アジャイル型の開発では、成果物を事前に確定できないため請負契約と相性が悪くなります。この点についてはIPAが「情報システム・モデル取引・契約書（アジャイル開発版）」を公開しており、無償で参照できます。ベンダーの提示する契約書だけで判断せず、一度目を通しておくことをお勧めします。

責任分界点の話を避けるベンダーは避ける

上の表の項目を尋ねたとき、明確に答えられない、あるいは「そこまで決める必要はない」と言う相手は、その一点で判断材料になります。長く付き合うつもりなら、なおさら最初に決めておくべき事柄です。

進め方：最初の1年

段階を置きます。A社を想定していますが、業種を問わず使えます。

期間	やること	誰が
1〜2か月目	対象業務の可視化。今のスプレッドシートで何が回り、何が回っていないかを洗い出す	社内（B）
2〜3か月目	目的を数字で定義する。「工程確認の電話を月30件減らす」まで具体化	経営者（A）＋社内（B）
3〜4か月目	作るか、既存のSaaSで足りるかを判定する。ここで作らない判断になることも多い	第三者（D）
4〜5か月目	作る場合、RFPを作成し複数社から見積を取る。契約条件を確認する	第三者（D）＋経営者（A）
6〜11か月目	4週間ごとに動くものを確認しながら開発。優先順位は1本のリストで管理	外部（C）＋社内（B）
12か月目	運用に移行。保守範囲と、次の改善の優先順位を決める	全員

3〜4か月目に「作らない」という結論が出ることは、失敗ではありません。むしろ最も投資対効果の高い結論です。既存のSaaSで足りるなら、600万円は不要になります。

そして、この判定を実装ベンダーに依頼すると、「作りましょう」という答えが返ってくる確率が上がります。構造上、そうなります。

まとめ

要点を再掲します。

最後の1行が、この記事の結論です。

中小企業が開発でつまずくのは、技術力が足りないからではありません。技術的な意思決定を、作る側とは別の立場で評価する人がいないからです。見積が妥当か、提案されたやり方が身の丈に合っているか、その契約で3年後も自由でいられるか。これを判断する役割が空席のまま、発注だけが進んでいきます。

そして、この役割は社内に置きにくく、実装ベンダーに任せると利益相反になります。だから外に置く、というのが構造から導かれる答えです。

ご相談について

株式会社ASAKURAでは、三重県を中心に、中小企業のITコンサルティング・DX支援を行っています。

当社が主に担うのは、上の表でいうDの役割です。作る前の判断、つまり業務の可視化、要件の整理、そもそも作るべきかの判定、ベンダー選定と見積の比較、契約条件の確認、開発期間中のレビュー。実装そのものより、その手前と横で効く部分です。

「作らないほうがいい」という結論が出ることもあります。既存のサービスで足りるなら、そう申し上げます。それを言える立場にいることが、この役割の価値だと考えています。

社内にエンジニアを置くべきか迷っている、外注の見積が妥当か分からない、契約の内容に不安がある。そうした段階でのご相談を歓迎しています。

お問い合わせは、お問い合わせフォームまたはメールにて承っております（宣伝）。