内製化とは？メリット・デメリットと外注との判断基準5つ

引っ越しのとき、夜10時に段ボールを組み始めて、勢いに乗って明け方には食器も本も服も全部詰め終わっていました。自分の段取りの良さに、少し感心したのを覚えています。

そこから、段ボールの壁の中で11日暮らしました。

歯ブラシがどの箱に入っているか分からないので、コンビニで買い直しました。早く終わらせたのは事実です。ただ、早く終わらせて手に入ったものは、11日間の待ち時間と、2本目の歯ブラシだけでした。

退去日は、動かなかったからです。

先に一行だけ置きます。内製化とは、外部に発注していた開発を自社の側に取り戻すことです。エンジニアを採用して自社で作る形もあれば、少人数の共創チームで作る形もあります。

題材は、大企業との共創プロジェクトです。現場にアプリを入れて、滞在客が自分の端末から手続きできるようにする。少人数で、内製に近い形で作りました。

前置きはさておき、本題に入ります。

今日は、この内製化で実装が3日になったのに、プロジェクトが動かなかった話をしていこうと思います。

① 教科書どおりに、内製化して速くする

先に、内製化を教科書どおりに整理しておきます。何を指す言葉なのか、何が得られて何を失うのか、外注との線をどこで引くのか。

内製化とは

内製化とは、これまで外部に委託していた業務を、自社の中で行うように切り替えることです。システム開発、運用保守、広告運用、制作、採用など、外に出していたものを内側へ戻す取り組み全般を指します。

「作れるようにすること」だと理解すると、範囲を見誤ります。実務で内製化と呼ばれているのは、作る作業だけでなく、決める作業と直す作業を自社に持つことです。この違いは、後の判断基準のところで効いてきます。

インハウスとの違い

ほぼ同じ意味で使われますが、使われる場面が違います。

	主に使われる領域	ニュアンス
内製化	製造、情報システム、業務全般	外注していたものを戻す過程
インハウス	広告、制作、デザイン、マーケティング	社内に機能を持っている状態

社内で言葉が割れているときは、たいてい対象領域が違います。同じ会議で「内製化」と「インハウス化」が飛び交うなら、何を内側へ戻す話なのかを先に揃えてください。

アウトソーシング（外注）との違い

	誰が実行するか	費用の出方	変えたいとき
内製	自社の人員	人件費として固定的にかかる	その日のうちに直せる
アウトソーシング（外注）	委託先	案件ごと・期間ごとの委託費	見積もりと調整が要る

比べるべきは金額ではなく、変えたいときに何が起きるかです。外注は1件あたりの費用が見えますが、変更のたびに手続きが挟まります。変更の頻度が高い業務ほど、この差が効いてきます。

内製化が注目されている背景

• 変更の頻度が上がった — 作って終わりではなく、動かしながら直す仕事が増えた
• 外注費が上がった — 委託の単価が上昇している
• ノーコード／ローコードが普及した — 専門の技術者でなくても作れる範囲が広がった
• 生成AIで実装の負担が下がった — 作る工程の時間が短くなった

4つ目が、いまの局面をつくっています。作ることが速くなった結果、速さの制約が「作る工程」から別の工程へ移りました。どこへ移ったのかは、この記事の後半で扱います。

内製化の目的｜3つに整理する

目的	狙うこと	成立の条件
業務効率化・スピードアップ	依頼から反映までの時間を縮める	決める人が社内にいる
経費削減（中間マージンのカット）	委託費のうち、管理費相当を減らす	一定量の仕事が継続してある
ノウハウの蓄積	判断の根拠が社内に残る	担当が入れ替わっても引き継げる形にする

2つ目だけを目的に置くと、たいてい失敗します。人件費は仕事量にかかわらず発生するため、仕事の量が読めないうちに人を抱えると、単価は下がっても総額は上がります。

内製化のメリット①｜外注コストを削減できる

委託費には、作業そのものの費用に加えて、管理費や中間マージンが含まれます。継続して一定量の仕事があるなら、内側に持つほうが安くなります。

境目は件数です。月に何件発生しているかを数えてから判断してください。

内製化のメリット②｜迅速かつ柔軟に対応できる

見積もり、発注、検収の手続きが要らなくなるため、小さな変更をその日のうちに反映できます。

効くのは「1件あたりは小さいが、頻繁に起きる変更」です。大きな改修は、外注でも段取りの中に収まります。

内製化のメリット③｜品質が安定する

自社の事情を知っている人が作るため、前提の説明をやり直す必要がありません。担当が固定されるぶん、出来上がりのばらつきが減ります。

内製化のメリット④｜ノウハウ・ナレッジが蓄積される

外注では、判断の過程が委託先に残ります。内製にすると、「なぜそうしたか」が社内に残ります。

ただし、自動的には残りません。書き残す手順を決めていないと、担当者1人の頭の中に溜まるだけで、その人が抜けた日に外注していたときより悪くなります。

内製化のメリット⑤｜セキュリティとガバナンスを強化できる

社外にデータを出す経路が減り、アクセス権限を自社の規程の中で管理できます。個人情報や未公開情報を扱う業務では、これが主目的になることもあります。

内製化のメリット⑥｜人材育成と採用に効く

実際に手を動かす仕事が社内にあると、育つ場も、入社したい理由も生まれます。外注一辺倒の組織では、技術者を採用しても任せる仕事がありません。

内製化のデメリット①｜初期コストと設備投資がかかる

採用、教育、開発環境、ツールのライセンス。動き出すまでの費用は、外注していたときには発生していなかったものです。

内製化のデメリット②｜人材育成に時間とコストがかかる

採用しても、自社の業務を理解して動けるまでには時間が要ります。その間、外注も並行して続くので、費用は一時的に増えます。

この重複期間を計画に入れていない見積もりが、いちばん多い失敗です。

内製化のデメリット③｜人材の流出と定着の問題

内製の体制は、少人数に依存しがちです。1人抜けると、その業務が止まります。

最低2人が触れる状態を、体制の条件にしてください。1人で回っているうちは、内製化が完了したとは言えません。

内製化のデメリット④｜コスト意識が薄れ、費用の把握が難しくなる

外注では請求書という形で費用が見えます。内製にすると、費用は人件費の中に溶けます。

対策は、工数を記録することです。記録が無いと、内製化が得だったのかを後から検証できません。

内製化のデメリット⑤｜リソース不足で業務が止まる

社内の人員は、他の仕事も抱えています。繁忙期が重なると、内製した業務から先に止まります。外注なら、相手の体制で吸収できていた部分です。

内製化のデメリット⑥｜専門性の高い領域では、技術の幅が狭くなる

外注先は、複数の会社の案件を通じて知見を得ています。内製の担当者は、自社の事例しか見ません。

専門性が高く、変化が速い領域を全部内側に抱えると、数年で古い作り方のまま取り残されることがあります。

内製化か外注かを判断する5つのポイント

判断軸	内製に寄る	外注に寄る
1. コストの比較	継続して量がある。総額で内製が下回る	量が読めない。突発的
2. 業務の継続性・頻度	毎週・毎月ある	年に数回。一度きり
3. 難易度・専門性の高さ	自社の業務知識のほうが効く	専門性が高く、外の知見が要る
4. 内製化する範囲	決める工程と直す工程	大規模な構築の工程
5. コア事業かどうか	自社の競争力そのもの	代替がきく周辺業務

5番目が最終判断になります。競争力の源になっている業務は、安くても外に出さないという判断があり得ます。逆に、周辺の業務を全部内側に抱えると、人員が足りているのに肝心の仕事が進まなくなります。

内製化に向いているケース・向いていないケース

	内製化が向く	内製化が向かない
変更の頻度	小さな変更が頻繁に起きる	ほとんど変わらない
業務知識	自社の事情を知らないと決められない	一般的な手順で足りる
量	継続して一定量がある	波が大きい／単発
人	最低2人が触れる体制を作れる	1人しか確保できない
技術の変化	枯れている	変化が速く、追い続ける必要がある

4行目を満たせないなら、内製化は先送りしてください。1人で回す内製は、外注より脆い体制です。

進め方①｜内製化の目的を明確にする

コスト削減か、スピードか、ノウハウの蓄積か。3つ全部を掲げると、判断が割れたときに決められなくなります。優先順位を先に決めてください。

進め方②｜範囲と優先順位を決める

業務を工程に割り、工程ごとに内製か外注かを判定します。「この業務は内製」ではなく「この工程は内製」まで下ろすのが要点です。

いちばん先に内側へ戻すべきなのは、決める工程です。作る工程だけを内製にすると、決める工程が外にあるままで、待ち時間は変わりません。

進め方③｜人材の確保と体制・育成計画

• 採用するのか、社内から異動させるのか、委託先から引き継ぐのか
• 育成にかかる期間と、その間の外注費を含めた見積もり
• 最低2人が触れる形にする
• 相談できる外部の相手を残しておく

4つ目を切り捨てないでください。完全に切り替えるより、難しい部分だけ外に相談できる形のほうが、実務では止まりにくくなります。

進め方④｜費用対効果を検証する

比べるもの	外注のとき	内製にしたとき
直接の費用	委託費	人件費＋ツール＋環境
重複期間の費用	—	切り替え中は両方かかる
変更1件あたりの時間	見積もり→発注→反映	着手→反映
止まったときの復旧	委託先の体制で吸収	社内の人員次第

2行目を入れずに比べた試算は、必ず内製が有利に出ます。切り替え期間を含めた年額で比べてください。

進め方⑤｜ノーコード・ローコードを活用する

専門の技術者が確保できなくても、業務側の人が自分で作れる道具を使えば、内製化の範囲を広げられます。ワークフローや業務アプリの領域では、これが現実的な入口になります。

ただし、作った人しか直せない状態が生まれやすい点に注意してください。誰が作ったかと、どこにあるかの一覧を、最初から残しておきます。

進め方⑥｜ガバナンスとセキュリティを先に決める

• 誰が作ってよいか、どこまで自由に作ってよいか
• 個人情報や機密情報を扱ってよい範囲
• 作ったものの一覧と、保守の担当
• 外部サービスと接続してよい条件

後から決めると、すでに動いているものを止める話になります。内製化は進むほど分散するので、規程は先に置いてください。

注意点①｜内製化を目的にしない

「内製化率◯%」を目標にすると、外に出したほうが安く速い業務まで内側へ戻すことになります。

測るべきは、依頼から反映までの時間と、年額の総費用です。内製化はその手段の1つでしかありません。

注意点②｜社内のパワーバランスで意思決定しない

「うちの部でやる」「外に出すべきだ」の議論が、業務の性質ではなく、部署の都合で決まることがあります。

先に判断軸を文章にして、合意してから当てはめてください。判断軸が無いと、声の大きさで決まります。

内製化でよくある課題

• 作る工程だけを内製にして、決める工程が外に残っている
• 担当者1人に集中し、その人が抜けると止まる
• 工数を記録しておらず、効果を検証できない
• 切り替え期間の重複費用を、見積もりに入れていない
• 作ったものが一覧化されておらず、保守の担当が決まっていない

1つ目が、この記事の後半の主題です。

内製化の事例｜業種ごとの型

業種の型	内側へ戻したもの	効いたところ
製造業	外部委託していた保守・運用	止まったときの復旧が速くなった
医療・公共	帳票と申請ルールの作成	制度改定に自社で追随できるようになった
小売・EC	広告運用と制作	施策の入れ替えが週単位になった
サービス業	運用委託していた定型業務	委託費が減り、変更の反映が速くなった

並べると、効いているのは費用より「反映までの時間」だと分かります。実名の事例を集めるときは、削減額ではなく、変更が反映されるまでの日数がどう変わったかを見てください。

内製化のよくある質問

Q. 内製化とインハウスは何が違いますか。
ほぼ同義ですが、使われる領域が違います。内製化は製造や情報システムを含む業務全般で、外注していたものを内側へ戻す過程を指します。インハウスは広告や制作の領域で、社内に機能を持っている状態を指すことが多い言葉です。

Q. 内製化のメリットとデメリットは何ですか。
メリットは、外注コストの削減、迅速で柔軟な対応、品質の安定、ノウハウの蓄積、セキュリティの強化、人材育成の6つです。デメリットは、初期コスト、育成の時間、人材の流出、費用が人件費に溶けて見えなくなること、手が回らず業務が止まること、専門領域で技術の幅が狭くなることの6つです。

Q. 内製化と外注は、どう判断すればよいですか。
コストの比較、業務の継続性と頻度、難易度と専門性、内製化する範囲、そしてその業務がコア事業かどうかの5点です。最終判断は5番目で、競争力の源になっている業務は、安くても外に出さないという判断があり得ます。

Q. 内製化はコスト削減になりますか。
継続して一定量の仕事がある場合に限ります。人件費は仕事量にかかわらず発生するため、量が読めないうちに人を抱えると、単価が下がっても総額は上がります。また切り替え期間は外注費と人件費が重複します。この期間を入れずに比べた試算は、必ず内製が有利に出ます。

Q. 内製化はどこから始めるとよいですか。
業務を工程に割り、まず決める工程から内側へ戻してください。作る工程だけを内製にすると、決める工程が外にあるままなので、依頼から反映までの時間は変わりません。

Q. 内製化で失敗しないために、体制で押さえることは何ですか。
最低2人がその業務に触れる状態を作ることです。1人で回っているうちは、内製化が完了したとは言えません。あわせて、工数を記録すること、難しい部分だけ相談できる外部の相手を残しておくことをおすすめします。

内製化の教科書には、こう書いてあります。外部への発注をやめれば、伝言が減り、意思決定から実装までの距離が縮む。

そのとおりでした。

ある3日間の実装量について、こういう報告が出ています。

「この3日間で実装した分（チャット機能・多言語対応・レビュー修正一式）だけでも、SI見積もりなら15〜25人月に相当します」

3日です。

チャット機能、多言語対応、レビューで挙がった指摘の修正一式。従来の目盛りに当てると15〜25人月。数千万円規模の実装量です。

作り方も変わりました。デザインの工程について、こういうやりとりがあります。

「Figma、一切使っていないんです。時間がなかったので、全部直接AIでデザインしました…。」

「Figma使ってない！？ 一体、、」

中間成果物が消えています。 設計書もモックも作らず、動くものが直接出てくる。内製化とAIが重なると、こういう速度になります。

ここまでは、教科書どおりです。

ここまでが、内製化の教科書どおりの整理です。目的を1つに絞り、工程で切り分け、5つの軸で判断し、体制を作る。この手順で、内側へ戻すところまでは進みます。

この記事の後半で扱うのは、その先です。作る工程を内側へ戻して、実際に速くなったあと、全体の速さは何で決まっているのか。

② そのとおりに進めて、0件に詰まる

ところが、同じ日にこういうやりとりがありました。

「はい、0件ですね…。」

トランザクション、0件です。

念のため書いておきますが、これは別の月の話ではありません。数千万円規模を3日で積んだと報告した、その同じ日の実績です。

片方には数千万円相当の実装量があり、もう片方には0がある。

この2つが同じ日に並んでいる状態を、私はきれいな言葉で説明できません。

引っ越しと同じでした。荷造りを一晩で終わらせても、退去日は動きません。動かないどころか、一晩で終わらせたおかげで、退去日までの11日間がまるごと待ち時間として見えるようになっただけです。

「速くなった」の最初の成果物は、成果ではなく、待ち行列の可視化でした。

③ そして、原因が紙だと分かる

0件の原因を追いました。

技術的な不具合ではありませんでした。アプリは動いています。決済も通ります。利用が始まらないのは、QRコードを刷った印刷物が現場に置かれていないからでした。

置かれていないだけではありません。置くべき場所が空かない。 部屋の中の限られた面積に、何を置くかという話は、こちらの権限では決まりません。

ここで多くのチームは、こう考えます。

「印刷物の展開は現場のタスクだから、こちらは仕様を整えて待つ」

これは正しい判断です。役割の線引きとして、間違っていません。

ただ、この正しさを守った場合、プロダクトは正しいまま0件のままになります。

④ 原因は「制約を解除したら、制約が移動していた」こと

原因を一つに絞ると、これでした。

私たちは、実装という制約を外すことに成功しました。そして外した瞬間に、制約は別の場所へ移動しました。

移動先は、プロダクトの中ではありません。

→ 印刷物が現場に届いていない
→ 置く場所が空かない
→ 決裁の予定表が空かない

どれも、コードでは解けません。そしてどれも、私たちの担当範囲の外にあります。

速くなる前は、この3つは見えませんでした。実装が最も遅かったので、外側は「まだ待てる」状態だったからです。実装が3日になった瞬間に、残っていた遅さが全部むき出しになりました。

⑤ 直してみる — 速い側が「作る以外の仕事」を取りにいく

律速が自分の外に出たとき、選択肢は3つしかありません。

→ (a) 待つ
→ (b) 相手に依頼して待つ
→ (c) 自分で取りにいく

(a) は、荷造りを終えて段ボールの壁の中で11日過ごす選択です。(b) は、相手の予定表を動かせない限り (a) と同じ結果になります。

(c) を選びました。

現場に必要なのは印刷物でした。誰も作れる状態になかった。そこで、依頼されていないA4のチラシと、A3のプラカード3種類を作って、現場に投げ込みました。

もう一つ。チラシを部屋のドアノブに掛けるための袋が、どこにも売っていません。100円ショップを巡っても見つからない。そこで、こうなりました。

「ドアノブ用の袋は、ハンドルバッグタイプがないなら透明のOPP袋にパンチで穴開けて、紐通して作るとかでいいと思います」

開発会社が、袋に穴を開ける話をしています。

引き受けたくて引き受けたわけではありません。0件のままだと、3日間の実装がまるごと存在しなかったことになるからです。

⑥ あとで知った — 制約が移動することには、名前がついていた

素朴な対処のつもりでしたが、調べると同じものを指す理屈は、すでにありました。

物理学者のエリヤフ・ゴールドラットが1984年の著書『ザ・ゴール』で提示した制約理論（Theory of Constraints）です。組織の目標達成を妨げている、ただ一つの最大の制約を特定して、そこに集中する、という考え方です。

手順は5つに整理されています。制約を見つける／制約を活用しきる／他を制約に合わせる／制約を引き上げる／繰り返す。

要点は5つ目です。

制約を引き上げて解消したら、手順1に戻れと書かれています。そして、そこにこう付いています。「惰性によって、それがシステムの制約であり続けることを許すな」。

制約は、解消すると消えるのではありません。次の場所へ移動します。

私たちがやったのは、実装という制約を引き上げたことでした。引き上げた瞬間に、制約は印刷物と決裁へ移った。 それだけの話です。

そして、もう一つ。制約を引き上げる前に活用しきれ、という順序も書かれています。設備投資が要るからです。内製化は「引き上げ」にあたります。 だから費用がかかる。にもかかわらず、引き上げた先に別の制約が待っていることは、40年前から知られていました。

新しい理屈は、ひとつも要りませんでした。

⑦ 何が変わったか — 速さの証拠は、タイムスタンプにしか残らない

「作る以外の仕事」を取りにいくようになって、変わったことがあります。速さの示し方です。

提案書に「アジャイル」「高速リリース」「並走型開発」と書くのは誰でもできます。書いた文字と実力に相関はありません。

証明になったのは、時刻の記録だけでした。

→ 31分。現場から「アプリから配送が押せません」の報告。原因を切り分けて、復旧の報告まで31分
→ 12分。現場から「規約でこの機能が使えないことが分かりました」の報告。外部の規約で機能が丸ごと死んだ状態から、代替設計に差し替えるまで12分
→ 8時間。決済の3Dセキュアが、お客さんの目の前で止まった。同じ日のうちに恒久対応まで完了

障害の報告時刻と復旧の報告時刻の差は、後から書き足せません。 12分で代替設計に差し替えた記録は、偽造できない。

内製化の効果を説明するとき、人月削減額を並べても伝わりませんでした。タイムスタンプの密度を見せると、一度で伝わります。

⑧ 現場で使うなら、この2枚

表1：制約の移動先を、先に書き出す

工程	速くなるか	誰が持つか	空かないと何が起きるか
実装	なる	内製チーム	—
印刷物の作成・配布	ならない	不明になりがち	利用が0件で始まらない
設置場所の確保	ならない	現場	同上
決裁	ならない	決裁者の予定表	公開日が動く
オペレーション変更	ならない	現場	使われない

「誰が持つか」が空欄の行が、次の制約です。 内製化を始める前にこの表を書くと、投資対効果の議論が変わります。

表2：速さを証明する記録の取り方

記録するもの	粒度	なぜ効くか
障害報告の時刻	分	後から書き足せない
復旧報告の時刻	分	同上
仕様変更の依頼〜反映	分	伝言が減った証拠になる
上申日の変更履歴	日	決裁の待ち行列が可視化される

⑨ この考え方が効き続ける理由

実装は、これからも速くなります。そして、速くなるほど外側の遅さがむき出しになります。 これは技術の進歩で解決しません。制約が移動するという構造だからです。

このプロジェクトについて、こういう言葉が残っています。

「情熱と制度（投資承認）は時間軸が異なる」

半年動かして、起案の枠は20分でした。決裁の四者会議は30分で、しかもそれは、すでに他に6つ予定が入っている時間への割り込みとして設定されたものでした。

そして、18か月のあいだに上申日が4回動いています。

4回動いた理由に、技術やプロダクトが挙がったことは一度もありません。

片方は31分で動き、片方は18か月で4回滑る。この2つが、同じプロジェクトの中に同居しています。

つまり、内製化とAIが生産性に与えた本当の帰結は、「開発が速くなった」ではないと思います。速い側が、もう「言われたものを作る人」の位置に立てなくなった、ということです。

外側の律速を自分で外しにいかない限り、3日間の実装は、存在しなかったことになります。

ただし、正直に書いておきます。速く作れるということは、速く事故を起こせるということでもあります。 そして、この「範囲の外まで取りにいく」動きは、人数を増やすと途端に成立しなくなります。範囲の外側の仕事は、担当が決まっていないから外側にあるのであって、人を増やすと「それは誰の仕事か」の議論が先に立つからです。

関連して、アジャイル開発をAIで並行させたときの衝突話と、AI駆動開発で自作基盤とネイティブ機能を分ける話を別に書いています。AI時代の要件定義話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。

この判断を実際の案件で使う場面については、AIプロダクト開発のページに整理しています。

---

3日でできる、といえば、年賀状はいつも3日で書き終わります。

出すかどうかを、11月から悩んでいるだけです。手が遅いわけではありませんでした。

以上です。