「内製化を進めたい。だが、どこから手をつければいいのか分からない」——中堅・大企業のDX推進部門から最も多い相談です。

この問いが難しいのは、「内製化」という言葉が指す範囲が人によって違うからです。ある人は「エンジニアを採用して開発部門を作る」ことを想像し、別の人は「現場が自分でツールを作る」ことを想像している。この2つは必要な投資も期間もまったく異なります。

加えて、この2年で前提が変わりました。従来は「作れる人がいるか」がボトルネックでしたが、いまは「何を内製すべきかを決められるか」がボトルネックです。作れる範囲が広がったぶん、作らない判断の重要性が上がったのが現在地です。

本記事は、業務システム内製化の全体像を1本で把握できるように設計した総論です。個別テーマは関連記事で深掘りします。

無料資料｜全37ページ

Lovableを企業で使うための全体像と注意点を、1冊にまとめました

個人で試すのと、会社で使うのは別です。後から変更できない設定、プランによって使えない統制機能、向かない業務、過去のセキュリティ事案といった注意点を先に整理し、そのうえで最初の1本の選び方、既存システムとの接続、料金、社内展開の90日までを9章で解説しています。

ガイドブックを無料でダウンロード

業務システムの内製化とは何を指すのか？

内製化には3つのレベルがある

会議で「内製化」の議論が噛み合わないとき、原因はたいてい言葉の指す範囲の違いにあります。ある人はエンジニアを採用して開発部門を作ることを想像し、別の人は現場が自分でツールを作ることを想像している。この二つは必要な投資も期間も一桁違います。まず段階に分けて、自社がどこを目指すのかを合意してください。

会議で「内製化」が噛み合わないときは、たいていL2とL3を混同しています。L3は組織づくりの話であり、数年単位の投資判断です。一方L2は数か月で着手でき、費用対効果も測りやすい。まずL1・L2で成果を出し、必要性が実証されてからL3を検討する——これが現実的な順序です。

なぜいま内製化が現実的になったのか？

背景は人材の需給にあります。経済産業省の「IT人材需給に関する調査」報告書は、2030年時点で最大約79万人規模のIT人材不足を推計しています。「DXレポート」が警告した既存システムのブラックボックス化と合わせると、「外注先を探せば解決する」という前提そのものが揺らいでいます。

そこへ、ノーコード基盤（kintone、Power Apps）に加え、自然言語からアプリを生成するAI型ツール（Lovable、Bolt、v0など）が実用域に入りました。結果として、「予算が付かないから作らなかった小さな業務アプリ」の経済性が変わった——これが構造変化の中身です。

誤解を避けるために明記します。大規模基幹システムの置き換えが内製でできるようになったわけではありません。

内製化＝全部自社で作る、ではない

内製化の目的は自給自足ではなく、「変更したいときに、自社の判断で変更できる状態」を作ることです。したがって成功の指標は「自社で作った割合」ではなく、「業務の変更からシステム反映までのリードタイム」になります。

この定義に立つと、外注を減らすことが目的ではないと分かります。外注していても変更が2週間で反映されるなら、それは内製化の目的を達成しています。契約形態の選び方はIPAの「情報システム・モデル取引・契約書」が参考になります。

何を内製し、何を内製しないのか？

判断は3軸で行う

内製と外注の切り分けは、案件ごとに感覚で決めると担当者によってぶれます。判断軸を先に決めて社内で共有しておけば、個別の議論が短くなります。実務で機能する軸は次の3つです。多くの企業は自社固有性だけで判断しがちですが、それだけでは可用性の要件を見落とします。

3軸すべてが「内製に向く」側なら迷わず内製、すべて逆なら外注または既製品。混在する場合は③を優先してください。可用性の要件は、後から設計で足すのが最も高くつくためです。

内製に向く典型領域はどこか？

3軸に照らすと、内製が有利になる業務にはある共通点が見えてきます。いずれも「他社と同じにはならず」「頻繁に変わり」「止まっても即座に事業が停止しない」領域です。具体的には次のような業務が該当します。

• 部門固有の申請・承認フロー（他社と同じにはならない）
• 台帳・マスタ管理（Excelで運用されている領域）
• 既存データの可視化ダッシュボード
• 現場の点検・報告・記録
• 顧客への情報提供ポータル（要セキュリティ設計）

内製に向かない領域はどこか？

逆に、次の領域は無理に内製化しないほうが賢明です。作れないわけではなく、作った後の維持が困難になります。とくに法改正への追随が必要な領域は、既製品を使うこと自体がリスク管理になります。

• 会計・給与・人事の基幹（法改正対応が必要で、標準化されている）
• 可用性が事業継続に直結する処理（受発注の基幹、制御系）
• 大量データの複雑なバッチ処理
• 高度な専門知識が必要な領域（決済、暗号、リアルタイム通信）

脱Excelはどこから手をつけるべきか？

なぜExcelは残り続けるのか？

「脱Excel」が進まない理由を「現場の抵抗」に求めるのは誤りです。Excelは、変更したいときに即座に変更できる唯一のツールだからです。列を1つ足したいとき、システムなら申請と開発が必要ですが、Excelなら3秒で終わります。

つまりExcelが残るのは、システムの変更リードタイムが長すぎることの症状です。ここを直さずにシステムだけ導入しても、現場は必ずExcelに戻ります。

置き換えるべきExcelはどう見分けるのか？

すべてのExcelを置き換える必要はありません。置き換えるべきは次の条件を満たすものだけです。

逆に、1人が自分用に使っている計算シートは、置き換えなくてよいのが原則です。ここまで手を出すと現場の反発を招き、本丸の置き換えまで止まります。

二重運用をどう避けるか？

内製化で最も多い失敗が二重運用です。新システムを入れたのにExcelも残り、現場の作業がむしろ増える状態。これは効果がゼロではなくマイナスです。

避ける方法は1つしかありません。移行日を決めて、旧Excelを共有フォルダから消すことです。「使いたい人は使ってよい」という運用では絶対に切り替わりません。そのため、成果指標も「導入したか」ではなく「旧手段を廃止できたか」に置いてください。

👉 関連記事：「脱Excelの選択肢を全比較」（※公開後に内部リンクを設定）

内製化はどう進めるのか？——6ステップ

内製化を「ツールを導入すること」として始めると、たいてい2件目で止まります。効果を説明できず、次の予算が取れないからです。以下の順序は、1件目で確実に実測値を取り、それを2件目以降の原資にすることを狙っています。とくにステップ1と3は、後から取り返しがつきません。

1. 変更リードタイムを測る——現状、業務の変更がシステムに反映されるまで何日かかっているか。これが内製化の効果を測る基準線になります
2. 対象業務を1つ選ぶ——3軸で内製に向き、かつ効果が数値化できるもの。社内限定・読み取り中心が最も安全です
3. 現状の作業時間を計測する——推定ではなく実測。後から遡って測ることはできません
4. 小さく作って現場で使う——完成度より、実データで使ってもらうことを優先
5. 旧手段を廃止する——移行日を決めて実行。ここまでやって初めて効果が出ます
6. 効果を実測し、横展開の判断材料にする——「月80時間が15時間になった」という実数が、次の予算を取る唯一の方法です

ステップ3を飛ばす企業が非常に多い領域です。導入前の測定なしに始めると、効果を説明できず、翌年度の予算計上で必ず詰まります。

体制はどう作るのか？

誰が担うのか

現実的に機能する構成は、「業務部門が作り、情シスがレビューする」です。業務を理解している人が作らなければ要件が正しくならず、統制を理解している人が見なければ事故が起きます。

ここで重要なのは、情シスの役割を「承認者」ではなく「安全に作れる環境を整える人」と定義し直すことです。承認者に置くと、審査待ちが新たなボトルネックになり、内製化の目的（リードタイム短縮）が失われます。

情シスと事業部門の役割分担はどうするか？

役割分担で失敗するのは、権限の線引きが曖昧なまま始めるケースです。「情シスも見ます」という合意は、実際には誰も見ていない状態を生みます。どちらが主担当かを項目ごとに明示してください。以下は多くの企業で機能している分担です。

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

費用と効果はどう見積もるのか？

費用は①ツール利用料 ②社内人件費 ③統制コストの3層で構成されます。内製と外注を比較する際、②を計上しない比較表が非常に多く見られますが、これでは公正な比較になりません。

効果側は、次の3つで測ります。

• 作業時間の削減（導入前後の実測値の差）
• 旧手段の廃止率（二重運用が残っていないか）
• 変更リードタイムの短縮（内製化の本来目的）

なお、開発工数の相場については、IPAの「ソフトウェア開発分析データ集2022」が5,546プロジェクトの定量データを公開しています。ここから読み取るべきは個別の金額ではなく「同種のプロジェクトでも工数に大きな幅がある」という事実です。人件費の水準については経済産業省のIT人材需給に関する調査やIPAの企業・IT人材に関する調査が参考になります。

👉 関連記事：「業務アプリ開発の費用相場【2026年版】」（※公開後に内部リンクを設定）

内製化を阻む3つの壁と、その越え方

予算の壁——「効果が示せないから予算が付かない」

最も多い行き詰まりです。効果を示すには実績が必要で、実績を作るには予算が必要——この循環に入ると動けません。

突破策は「予算を取らずに始められる範囲で1件やる」ことです。既存の全社ライセンス（Microsoft 365、kintone等）の範囲内、あるいは月数千円のツールで、1つの業務を実測付きで改善する。1件の実測値があれば、2件目からは金額の議論になります。逆に、最初から全社導入の稟議を書こうとすると、根拠がないため必ず差し戻されます。

情シスの壁——「セキュリティ要件で差し戻される」

差し戻しの原因は、多くの場合技術要件ではなく運用の説明不足です。「誰が作り、誰が保守し、いつ止めるのか」に答えられないと、どれだけツールが安全でも承認されません。

有効なのは、審査要件を企画段階でヒアリングしておくことです。公開直前に持ち込むから差し戻されるのであって、要件を先に聞いて工程に組み込めば止まりません。SSOの要否、データ保存先のリージョン、学習利用の可否、監査ログの必要性——この4点を先に確認してください。

現場の壁——「作ったのに使われない」

原因は機能ではなく、企画に現場が入っていないことです。推進部門だけで企画したツールは、現場の例外処理を織り込めていないため「使えない」と判断されます。

対策は単純で、企画段階で現場の1人を当事者として巻き込むこと。完成後に説明会を開くより、企画時に1人を入れるほうが定着率への影響は大きくなります。IPA「DX動向2024」やIPAのDX推進に関する取り組みでも、推進体制と現場の乖離は継続的な課題として挙げられています。

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

内製化の失敗は、技術的な難易度が原因であることはほとんどありません。順序の誤りと、測定の欠落と、統制の後回しに集約されます。以下の一覧は、いずれも着手前に自己点検すれば回避できるものです。

最後の2つは中長期で最も高くつきます。市民開発を統制なしに広げると、数年後には保守されないアプリが積み上がります。DXレポートが警告した既存システムのブラックボックス化と、構造はまったく同じです。IPA「DX白書」や総務省「情報通信白書」でも、推進体制と現場の乖離が繰り返し課題として挙げられています。

AI活用に進むための前提は何か？

「内製化の次はAI活用」という文脈がよく語られますが、順序を間違えると失敗します。AIが正しく動く前提は、綺麗なデータ基盤（SSOT：Single Source of Truth）が存在することだからです。

データが部門ごとのExcelに分散し、表記が揺れ、どれが最新か分からない状態では、AIに何を学習させても出力は信用できません。内製化による業務データの一元化は、AI活用の前工程として位置づけるのが正しい理解です。

逆に言えば、内製化の投資対効果を説明する際、「作業時間の削減」だけでなく「AI活用に耐えるデータ資産の形成」を成果に含められます。これは経営層に対して強い論拠になります。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして100社以上のCRM導入・活用を支援し、Lovableの日本公式パートナーとして業務システムの内製化をご支援しています。「何を内製し、何を作らないか」の切り分けから、体制設計・データ基盤整備・社内定着まで一貫して伴走します。

よくある質問（FAQ）

Q1. どこから始めればよいですか？

社内限定・読み取り中心の小さなアプリからです。リスクが低く、作業時間の削減という形で効果が数値化できます。ただし着手前に必ず現状の作業時間を実測してください。後から遡って測ることはできません。

Q2. エンジニアを採用しないと内製化はできませんか？

レベルによります。設定の内製（L1）とアプリの内製（L2）は業務部門＋情シスのレビュー体制で可能です。開発の内製（L3）は組織づくりの話で、数年単位の投資判断になります。L1・L2で成果を実証してからL3を検討する順序を推奨します。

Q3. 脱Excelはすべてのファイルが対象ですか？

いいえ。対象は「複数人が更新する／メールで送り合っている／転記が発生している／集計に人手がかかっている」もののみです。1人が自分用に使う計算シートまで手を出すと反発を招き、本丸の置き換えが止まります。

Q4. 新システムを入れてもExcelが残ってしまいます。

二重運用は効果がマイナスの状態です。避ける方法は1つで、移行日を決めて旧Excelを共有フォルダから削除すること。「使いたい人は使ってよい」という運用では切り替わりません。

Q5. 情シスが承認してくれません。

技術的な安全性より「誰が作って、誰が保守し、いつ止めるのか」が説明できていないケースが大半です。公開フロー・棚卸しルール・権限管理の3点を先に文書化してください。また情シスの役割を承認者ではなく「安全に作れる環境を整える人」と再定義することも有効です。

Q6. 効果をどう経営層に説明すればよいですか？

作業時間の削減（実測値）、旧手段の廃止率、変更リードタイムの短縮の3つです。加えて「AI活用に耐えるデータ資産の形成」を成果に含めると、単年度のコスト削減より強い論拠になります。

Q7. 内製したアプリが放置されて負債になりませんか？

棚卸しルールを配布前に決めれば防げます。誰が保守し、何か月使われなければ停止するか。配ってから統制しようとすると必ず遅れます。

Q8. AI活用の前に何をすべきですか？

データの一元化です。データが部門ごとのExcelに分散し表記が揺れている状態では、AIの出力は信用できません。内製化による業務データの一元化は、AI活用の前工程と位置づけてください。

Q9. 現場が使ってくれるか不安です。

企画段階で現場の1人を当事者として巻き込むことが最も効果があります。完成後の説明会より、企画時の巻き込みのほうが定着率を左右します。

本記事で引用した公的データは、経済産業省「IT人材需給に関する調査」「DXレポート」、IPA「ソフトウェア開発分析データ集2022」「DX白書」、総務省「情報通信白書」に基づきます。本記事は一般的な指針であり、個別プロジェクトの成果を保証するものではありません。