1. はじめに — なぜ製造業の IT 投資は高くつきがちなのか
製造業の中小〜中堅企業において、「IT 投資の見積もりが想定の 5〜10 倍になって驚いた」という経験は、決して珍しいものではありません。設備の稼働データを集めて可視化したい、品質管理を自動化したい、複数システムを連携させたい——どれも一見シンプルな要件ですが、SIer に発注すると数百万円〜数千万円、納期は半年〜1 年というのが標準的な相場です。
その一方で、社内の現場エンジニアが Python と少しの工夫を持っていれば、同じ機能を 1 ヶ月で作れる場合がしばしばあります。本記事では、このギャップが生まれる構造的な理由と、内製化を組織として実現するための現実的な方法を整理します。
本記事は、特定の SIer や外注ビジネスを否定する意図は一切ありません。基幹システムや大規模インフラなど、外部パートナーが必須となる領域は確実に存在します。本記事の主題は、「外注すべきもの」と「内製で十分かつ早いもの」の境界線を、製造業の現場目線で再定義することです。
2. ケーススタディ — 架空企業 A 社の事例（数値は記事用のダミー）
具体例で全体像を掴むため、架空の中堅製造業 A 社の事例を提示します。登場する数値・固有名詞・状況設定はすべて記事用のダミーですが、製造業の現場では類似のパターンが頻繁に観察されます。
状況設定
- A 社: 従業員 200 名規模、産業機器の組立・検査を行う中堅メーカー
- 課題: 検査工程の設備が PLC で動いており、稼働ログを Excel で手集計している。月末の集計に毎回 20 時間かかっている
- 解決したいこと: 設備のデータを自動取得し、Web ダッシュボードでリアルタイム可視化、月次レポートの自動生成
外注ルートの見積もり（架空）
- SIer A への RFP 提示 → 提案：開発期間 12 ヶ月、初期費用 1,800 万円、月額保守 30 万円
- SIer B → 1,500 万円、納期 9 ヶ月
- SIer C → 2,200 万円、フル機能版で 14 ヶ月
いずれの SIer も、要件定義 → 基本設計 → 詳細設計 → 製造 → テスト → 受け入れ、のウォーターフォール工程を提案。ヒアリング期間だけで 2〜3 ヶ月、その後の実装と検証に半年以上を見込みます。
内製ルートの試算（架空）
- 担当: 社内の生産技術エンジニア 1 名（Python 経験 1 年程度）+ 外部メンター（顧問契約）
- 使用ツール: Python、pymodbus、pandas、Streamlit、SQLite。すべて OSS
- 期間: PoC 2 週間 → 限定運用 2 週間 → 本番運用へ。総開発期間 1 ヶ月
- 費用: 担当者の人件費（1 ヶ月分）+ 外部メンター費 30 万円 + 必要 PC・ライセンス 20 万円。合計 100〜150 万円程度
結果と教訓
このケースで A 社が内製を選んだ場合、コストはおよそ 1/10、納期はおよそ 1/10 に短縮されます。さらに、内製したシステムは「現場の言葉」で書かれているため、後の機能追加や改修も社内で対応可能。SIer に再発注する必要がありません。
もちろん、内製にもリスクはあります（後述）。しかし、適切な対策を取れば、このギャップは現実的に活用できます。
3. 構造的問題 — なぜ外注は時間とコストがかかるのか
「外注 1 年・1500 万円」が、悪意ある見積もりではなく、業界の構造から生まれていることを理解しておくと、対応策が考えやすくなります。
ヒアリング期間の長さ
SIer は依頼者の業務を一から学ばなければなりません。製造業の現場知識（PLC、設備、ライン構成、品質基準、運用フロー）を持たない外部の人間が、これを理解するだけで数週間〜数ヶ月かかります。発注側のキーパーソンの時間も大量に奪われます。
中間マージン
元請け SIer → 二次請け → 実際にコードを書くエンジニア、という多重構造が常態化しています。各層でマージンが発生し、最終的な開発単価は実装者の人件費の 2〜4 倍になることが普通です。
仕様書のラリー
ウォーターフォール型の開発では、要件定義書 → 基本設計書 → 詳細設計書、と承認のラリーを繰り返します。「このボタンの色を変えたい」レベルの変更が、書類の改訂を伴うため数日〜数週間かかります。
リスクプレミアム
SIer は契約上、「動かなかった」「想定と違った」という事態に備える必要があります。そのリスクを吸収するためのバッファ（人月、契約金額）が見積もりに乗ります。これは責任を持つ立場としては当然の対応です。
ベンダーロックイン
外注で作られたシステムは、その SIer 独自のフレームワーク・命名規則・運用手順で実装されることがあります。後から別ベンダーに引き継いだり、社内で改修したりするのが困難になり、結果として保守費用が継続的に発生します。
現場の暗黙知が伝わらない
製造業の現場には、文書化されていない「暗黙のルール」が無数に存在します。「この設備は冬になると微妙にズレる」「金曜の夕方は通信が混む」「あの取引先のデータは特定列だけ独自フォーマット」——こうした情報を、外部の人間に正確に伝えるのはほぼ不可能です。結果として、要件漏れや手戻りが発生します。
4. 生成 AI 時代の追い風 — なぜ「いま」内製化なのか
「内製化」というテーマ自体は、製造業の DX 文脈で 10 年以上語られてきました。しかし、2023 年以降の生成 AI の登場で、状況が劇的に変わっています。
コーディング難易度の劇的低下
従来、内製化のボトルネックは「Python が書ける人材を社内で育成・確保できない」という人材問題でした。しかし、Claude や ChatGPT、GitHub Copilot などの AI コーディングアシスタントを使えば、Python 経験 1 年程度のエンジニアでも、対話しながら実用的なコードを書けるようになっています。
ドメインエキスパートが直接実装できる
従来の構図は「ドメインエキスパート（生産技術者・品質管理者）が要件を伝え、エンジニアが実装する」でした。これが、「ドメインエキスパートが AI と対話しながら直接実装する」という構図に変わりつつあります。要件のすり合わせコストが激減します。
レビューと検証は依然として人間の仕事
注意すべき点として、AI が出力したコードは必ず人間が検証する必要があります。動作確認、エッジケース、セキュリティ、業務要件との整合——これらは AI に任せきれません。「AI に書いてもらい、自分でデバッグする」が新しい開発スタイルです。
中小製造業に追い風
SIer に大型案件を発注しにくい中小製造業ほど、生成 AI による内製化の恩恵を大きく受けます。「これまで諦めていた IT 化」が、現実的な選択肢に変わっています。
5. 内製化の組織的な壁
技術的には可能でも、組織として内製化を進めるには別の困難があります。「現場のエンジニアが書けるから OK」では話が進まない場面が多々あります。
経営層の理解不足
経営層から見ると、「ちゃんとした SIer に頼んだ方が安心」「内製は属人化が怖い」という直感的な不安があります。これは合理的な部分も含むため、感情論で押し切らず、リスク対策とセットで提案する必要があります。
保守責任の所在
外注したシステムは「動かなくなったら SIer に連絡する」で済みますが、内製したシステムは社内で保守する必要があります。担当者が異動・退職した時、誰がメンテナンスするのか——この不安は組織の側から見ると正当なものです。
「ちゃんとしたところに頼まないと不安」という慣性
長年の外注文化が、組織の意思決定に染み付いていることがあります。「IT 部門でない人間が業務システムを作っていいのか」「監査で何か言われないか」「品質保証は誰が？」——これらの問いに、事前に答えを準備しておくことが提案を通すコツです。
評価制度の問題
多くの製造業の人事評価制度は、「IT を作ること」を評価項目に含んでいません。生産技術者がシステムを内製しても、評価には反映されにくい。結果として、現場のエンジニアが内製化に踏み出すインセンティブが弱くなります。
失敗のコスト負担
内製で失敗した場合、その責任は社内エンジニアが負うことになります。一方、外注で失敗した場合は SIer の責任。この非対称性が、内製化への心理的ハードルを高くしています。
属人化リスク
内製したシステムが「あの人しか分からない」状態になると、その人が休んだ・退職した瞬間に組織が困ります。これは外注リスク（ベンダーロックイン）の裏返しでもあり、内製であっても無対策ではいけない領域です。
6. 社内提案の具体例 — 経営層を説得するための材料
組織で内製化を進めるには、合理的な提案資料を準備する必要があります。以下、提案資料に含めるべき要素を整理します。
段階的導入の提案
「いきなり大きなシステムを内製します」という提案は通りにくい。段階的に進める道筋を示すと、経営層も判断しやすくなります。
- PoC（概念実証）: 2 週間〜1 ヶ月で動くプロトタイプを作る。費用は最小限、リスクも限定的
- 限定運用: 1 ライン or 1 工程に絞って運用。問題があっても影響範囲が小さい
- 本番運用: 限定運用で得られた知見を反映してスケール
外注 vs 内製のコスト比較表
具体的な数字で比較表を作ります。仮想ダミーでも構わないので、提案する案件に近い形で書くと説得力が出ます。
- 初期費用
- 開発期間
- 保守費用（月額）
- 機能追加時の単価
- 仕様変更への対応速度
- トラブル時の対応速度
- 属人化リスク（と対策）
リスク対策のセット提示
内製化の不安要素に対して、事前に対策を提示します。
- 属人化対策: GitHub での Git 管理、READMEと運用手順の文書化、コードレビュー（最低 2 名体制）、AI コーディングアシスタントの活用で「コードを書いた人がいなくても AI に解説させられる」状態を作る
- 保守体制: 「OSS と AI を活用した内製のため、担当者の退職リスクは外注よりむしろ低い」と論証する
- 失敗時のリカバリ: 段階的導入により、各フェーズで撤退判断が可能
- 外部メンター: 月数万円〜数十万円の顧問契約で、技術判断のサポートを得る
既存のサクセスケースを引用
社内で「Excel + VBA で業務改善した過去事例」があれば、それを延長線上に位置づけて提案します。「VBA で月次集計を自動化した時と同じ発想で、今度は設備データを Python で扱います」という連続性のある語り方をすると、抵抗が減ります。
7. 内製化ロードマップ — 段階的に進めるためのフェーズ設計
個人レベルでなく、組織として内製化を進める際の段階的ロードマップを示します。一気にすべてを内製化しようとせず、確実な実績を積み上げる順序が大事です。
フェーズ 1: スモールスタート（数ヶ月）
- 狙い: 「内製で動くものができる」という事実を組織内に作る
- 対象: Excel・VBA からの脱却、定型業務の自動化、社内ツール
- 例: 日報の自動集計、複数 Excel ファイルの統合、PDF レポート生成
- 注意: ここで派手な失敗をすると後続が進まない。地味でも確実に動くものを
フェーズ 2: 設備データ収集（数ヶ月〜半年）
- 狙い: 設備と Python をつなぐ。データドリブン化の土台
- 対象: PLC との通信、センサーデータ収集、CSV / DB への保存
- 例: 検査機の稼働ログ自動収集、しきい値超過の自動通知
- 注意: ネットワーク・セキュリティ部門との事前調整が必須
フェーズ 3: 統合システム（半年〜1 年）
- 狙い: 複数のデータソースを統合し、可視化・分析する基盤を作る
- 対象: ダッシュボード、データベース連携、Web 画面
- 例: 設備の稼働率を Streamlit でリアルタイム可視化、品質データの自動分析
- 注意: ここから先は外注との「協業」も選択肢。インフラやセキュリティは外部の手を借りつつ、業務ロジックは社内で持つ
フェーズ 4: 業務基幹の一部内製化（1 年〜）
- 狙い: 基幹システムの一部を内製で代替・補完する
- 対象: 受発注、生産計画、原価計算の業務支援ツール
- 例: ERP との連携バッチ、生産計画の自動最適化、コスト分析ダッシュボード
- 注意: 基幹に関わるため、設計・テスト・運用すべての品質を高める。組織として IT ガバナンスを整える
各フェーズ共通の心得
- 各フェーズの開始時に、「成功・撤退の判断基準」を明文化しておく
- 担当者を孤立させない（最低 2 人体制、外部メンター活用）
- すべての成果物を Git で管理、運用手順を README に書く
- 毎月「振り返り」を行い、改善点を次フェーズに反映
8. おわりに — 「外注か内製か」ではなく「どこを内製するか」
本記事では、「外注 1 年」を「内製 1 ヶ月」に変えるための、技術的・組織的な道筋を整理しました。
大事なのは、「外注 vs 内製」を二項対立で考えないことです。基幹インフラ・大規模システムは外部パートナーと組む方が合理的ですし、業務改善ツール・設備連携・データ可視化は内製の方が圧倒的に早く・安く・現場に即したものになります。
製造業のエンジニアにとって、「外注に頼らず自分の手で動くものを作る」スキルは、組織にとっても個人キャリアにとっても、ますます価値の高いものになっていきます。本サイトでは、その実装ノウハウを継続的に発信していきます。