「社内システムは内製すべきか、外注すべきか」——この問いに対して、多くの記事が「内製は安い、外注は高い」という前提で書かれています。この前提が、そもそも間違いです。

内製が安く見えるのは、比較表に社内担当者の人件費が入っていないからです。エンジニアでない社員が業務時間の3割を使ってアプリを作れば、それは立派なコストです。にもかかわらず「ツール利用料 vs 開発委託費」で比較され、内製が圧勝する——という表が量産されています。

本記事では、内製と外注を公正に比較し、判断の枠組みを提示します。結論を先に言えば、内製の本質的な価値はコストではなくスピードです。ここを取り違えると、選定も稟議も失敗します。

内製化の全体像は「業務システム内製化ガイド」をご覧ください。

内製のメリットは何か？

①変更スピード——これが最大の価値

外注では、要件の変更に「相談→見積→契約→開発→検収」という工程が挟まります。項目を1つ足すだけで数週間かかることも珍しくありません。内製ならその日のうちに直せます。

この差が効くのは、要件が動く業務です。逆に年単位で安定した業務では、スピードの価値はほとんど生まれません。「内製が有利かどうかは、業務の変更頻度で決まる」——この一点が判断の中心にあります。

②業務への適合——「言語化されていない要件」を拾える

外注の品質は、要件をどれだけ正確に伝えられるかに依存します。しかし現場の業務には、言語化されていない例外処理が必ず存在します。「この取引先のときだけ手順が違う」といった知識は、要件定義書に書かれません。

内製では、業務を知っている人が作るため、この種の暗黙知が自然に反映されます。要件定義の精度が構造的に高くなるのが内製の強みです。

③ナレッジの蓄積——データとノウハウが社内に残る

外注では、システムの内部構造を知るのはベンダーです。担当ベンダーが変われば、引き継ぎコストが発生します。内製なら知識は社内に残ります。

ただし後述するとおり、これは「属人化」と表裏一体です。組織に残るか個人に残るかは、体制設計次第で変わります。

内製のデメリット・リスクは何か？

公正を期すため、こちらも具体的に整理します。3つとも「作るとき」ではなく「作った後」に現れるのが共通点で、だから導入検討時に見落とされます。

①属人化——作った人がいなくなると止まる

最大のリスクです。担当者の異動・退職で、誰も中身が分からないアプリが残ります。皮肉なことに、これは内製化が解決しようとした「既存システムのブラックボックス化」と同じ構造です。経済産業省「DXレポート」が警告した問題が、規模を小さくして再現します。

対策は3点です。①コードやアプリ構成の保管場所を統一する、②作成者以外がレビューする体制を必須にする、③棚卸しの周期を決める。いずれも作る前に決めておかないと機能しません。

②品質保証——契約で守られない

外注なら、品質は契約で担保されます。不具合があればベンダーの責任です。内製ではすべて自社の責任になります。

とくに重大なのがセキュリティです。データベースのアクセス制御（行レベルセキュリティ）の設定漏れは、設定していなくてもアプリが正常に動くため、通常のテストでは発見できません。点検手順は公開前チェックリストにまとめています。OWASP Top 10、IPA「安全なウェブサイトの作り方」、個人データを扱う場合は個人情報保護委員会のガイドラインも確認してください。

③統制コスト——数字に現れない継続負担

権限管理、退職者アカウントの処理、棚卸し、教育。これらは社内工数として確実に発生しますが、見積書に載らないため比較表から漏れます。

アプリが増えるほど、この負担は増えます。市民開発を全社に広げた企業が数年後に直面するのは、たいていこの問題です。

外注のメリット・デメリットは何か？

外注が有利な点は何か？

内製の利点を並べた後は、外注の利点を同じ精度で並べる必要があります。ここを省略した比較表は、結論が先にある資料として扱われ、稟議で信頼を失います。外注が構造的に優れているのは次の点です。

• 品質と納期が契約で担保される——社内リソースの変動に左右されない
• 専門性を調達できる——決済、暗号、リアルタイム処理などの高度領域
• 社内工数が少なくて済む——本業に集中できる
• 継続性がある——担当者の異動で止まらない（ベンダーが存続する限り）

外注の弱点はどこに出るか？

一方、外注の弱点は契約と工程の構造から生まれます。個々のベンダーの能力の問題ではなく、外部に委託するという形態そのものに内在する制約です。

• 変更が高い・遅い——変更契約が必要になる
• 暗黙知が伝わらない——要件定義書に書けない部分が落ちる
• 内部構造が社内に残らない——ベンダー変更時のコストが大きい
• 小さな案件を受けてもらいにくい——最低受注額の壁

最後の点は、日本の中堅・大企業で内製ニーズが生まれる直接の理由です。「数十万円規模の改善は、外注では採算が合わないので誰も引き受けない」——結果として現場がExcelで凌ぎ続けることになります。

判断基準：どう決めるのか？

3軸で切り分ける

判断を担当者の感覚に委ねると、案件ごとに結論がぶれます。軸を決めて社内で共有しておけば、個別の議論が短くなり、判断の理由も説明しやすくなります。実務で機能するのは次の3軸です。

混在する場合は③を優先してください。可用性の要件は後から設計で足すのが最も高くつくためです。

簡易スコアリングで迷いを減らす

会議で意見が割れるときは、次の5項目を各1〜3点で採点し、合計で判断すると議論が収束します。

合計12点以上なら内製、8点以下なら外注、9〜11点はハイブリッドを検討——という目安を社内ルールとして持っておくと、案件ごとの議論が短くなります。数値そのものより、「同じ基準で判断している」という納得感に価値があります。

迷ったときの原則は何か？

「小さく内製して、大きくなったら外注（または共同）に切り替える」です。逆方向——最初に大きく外注して、後から内製に引き取る——は、内部構造の理解が社内にないため、ほぼ確実に高くつきます。

コスト比較表はどう作るべきか？

冒頭で述べたとおり、多くの比較表は不公正です。公正な比較には次の項目が必要です。

人件費単価の水準を検討する際は、経済産業省の「IT人材需給に関する調査」報告書やIPAの企業・IT人材に関する調査が参考になります。また開発工数のばらつきについては、IPA「ソフトウェア開発分析データ集2022」が5,546プロジェクトの定量データを公開しています。

比較で最も重要なのは、金額を並べることではなく「何を比較していないか」を明示することです。上表のうち計上していない費目があるなら、その旨を稟議書に注記してください。後から発覚するより、はるかに信頼されます。

ハイブリッドという第3の選択肢

実務では、二択で決める必要はありません。工程で分けるのが最も現実的です。

この構成が成立しやすくなった理由が、ツール側の変化です。現在の主要ツール（Lovable、Bolt、v0など）は実コードを生成しGitHubと同期できるため、内製した試作をエンジニアが引き取って本番化する受け渡しが、作り直しなしで成立します。従来のノーコード（kintone、Power Apps）では、この受け渡しは困難でした。

契約形態は、探索工程を準委任、本番構築を請負とする二段構えが適します。IPAの「情報システム・モデル取引・契約書」でも、工程の性質に応じた使い分けが示されています。

内製に踏み切る前に確認する10項目

最後に、内製を決める前の確認事項をまとめます。1〜4は判断そのものに関する項目、5〜9は「作った後」のリスクに対応する項目、10は移行に関する項目です。5・6・9が空欄のまま始まったプロジェクトは、2〜3年後にほぼ確実に問題化します。着手時点では誰も困らないため、後回しにされやすい項目でもあります。

5・6・9が「作った後」のリスクに対応する項目です。ここが空欄のまま始まったプロジェクトは、2〜3年後にほぼ確実に問題化します。

業種・企業規模で内製の適性はどう変わるのか？

製造業——現場記録と基幹の距離が論点

製造業では、点検表・作業日報・不良記録といった現場の記録が紙やExcelに残りやすい一方、生産管理や在庫の基幹は既存システムに固まっています。内製の主戦場はこの2つの間にある「転記」の領域です。

現場記録のデジタル化は変更頻度が高く自社固有性も高いため、3軸判定では明確に内製寄りになります。逆に基幹側に手を入れるのは停止許容時間が短く、内製に向きません。境界線を「基幹に書き込むかどうか」で引くと、判断がぶれにくくなります。

情報通信業——社内にエンジニアがいる場合の落とし穴

エンジニアがいる企業では、内製は容易に見えます。しかし実際には「本業の開発リソースを社内システムに割けない」という別の制約が働きます。優先順位で常に後回しになり、結果として何も進まない——これが典型パターンです。

この場合、業務部門が作りエンジニアがレビューする体制のほうが機能します。エンジニアの関与を「作る」から「見る」に変えるだけで、リソース制約が大きく緩みます。

金融・保険業——統制要件が判断を支配する

監査・内部統制の要件が厳しい業種では、3軸のうち停止許容時間と機微データの扱いが判断を支配します。顧客情報を扱う領域の内製は、統制の設計コストが開発コストを上回ることが珍しくありません。

現実的な出発点は、顧客データを扱わない社内業務（会議体の管理、申請フロー、社内問い合わせ）です。ここで統制の型を作ってから、扱うデータの機微性を段階的に上げていく順序が安全です。

なお企業規模による違いとしては、中小企業では中小企業庁の各種支援施策の対象となる場合があり、中堅・大企業では逆に統制コストの比重が大きくなります。業種横断の動向は総務省「情報通信白書」やIPAのDX推進に関する取り組みが参考になります。

よくある失敗パターンは何か？

内製と外注の判断で実際に起きている失敗を整理します。共通しているのは、比較の設計そのものが誤っているという点です。比較表を作る前に、この一覧を確認してください。

2番目が最も根深い誤りです。コスト削減を主目的にすると、変更頻度の低い安定業務まで内製化してしまい、統制コストだけが増えます。内製の価値はスピードであり、スピードが要らない領域では価値が生まれません。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上のCRM導入・活用を支援し、Lovableの日本公式パートナーとして内製と外注の切り分け設計をご支援しています。IPA「DX白書」が示すとおり、DXの阻害要因は技術より組織側にあります。体制設計と社内合意の形成からご相談ください。

よくある質問（FAQ）

Q1. 内製と外注、どちらが安いですか？

比較の仕方によります。社内担当者の人件費と統制コストを計上すると、内製が常に安いとは限りません。内製の本質的な価値はコスト削減ではなく変更スピードです。

Q2. 内製の最大のリスクは何ですか？

属人化です。作った人が異動・退職すると誰も中身が分からなくなります。これは内製化が解決しようとした既存システムのブラックボックス化と同じ構造で、規模を小さくして再現します。

Q3. コスト比較表で見落としやすい項目は？

社内人件費が最多です。次いで統制コスト（権限管理・棚卸し・教育）と移行コスト（ツール乗換時の作り直し）。この3つが抜けた比較表は、内製を実態より安く見せます。

Q4. 内製と外注は二択で決める必要がありますか？

ありません。工程で分けるのが現実的です。要件の探索・検証と日常の小改修は内製、本番構築と基盤・セキュリティは外注または情シス、という構成が機能しやすくなっています。

Q5. 途中から内製に切り替えられますか？

可能ですが高くつきます。大きく外注したものを後から内製に引き取るのは、内部構造の理解が社内にないため困難です。「小さく内製して、大きくなったら外注（または共同）へ」という方向のほうが成功率は高くなります。

Q6. 非エンジニアだけで内製できますか？

社内向けの小規模アプリなら可能です。ただし権限設計とアクセス制御を検証できる人のレビューは必須です。とくにセキュリティの設定漏れは、設定していなくてもアプリが動くため通常のテストでは発見できません。

Q7. 情シスが内製に反対します。

反対の理由は多くの場合「誰が保守し、いつ止めるのか」が不明なことです。情シスの役割を「承認者」ではなく「安全に作れる環境を整える人」と再定義し、審査要件（SSO・データ所在地・監査ログ等）を企画段階でヒアリングすると進みます。

Q8. 小さな改修を外注が受けてくれません。

これは内製ニーズが生まれる典型的な理由です。数十万円規模の改善は外注では採算が合わないため、結果として現場がExcelで凌ぎ続けることになります。この領域こそが内製の主戦場です。

Q9. 稟議ではどう説明すればよいですか？

コスト削減ではなく変更リードタイムの短縮を主軸に据えてください。「現在30日かかっている業務変更の反映が3日になる」という形で示し、比較表では計上していない費目があればその旨を注記してください。