【製造業DXの現実】AIで内製化できるのに「作らせてもらえない」本当の理由。固定費と外注費の壁
世間では「生成AIを活用した内製化」や「製造業DX」が叫ばれています。
確かに、成功事例として語られる大手製造業のキラキラした話を聞くと、それが正解のように思えます。
しかし、サプライチェーンの中流に位置する中間部材メーカーの現場では、全く別の重力が働いているのです。
私は精密機械の制御やデータ解析ソフトの開発に1X年携わり、現在は製造メーカーの社内SEとしてAI活用の推進に関わっています。
PythonやNext.jsを駆使して、かつては外注で1年かかっていたような「製造ラインのDXシステム」や「社内RAG」「工場監視」のプロトタイプを、今ではたった1ヶ月で組み上げることができるようになりました。
技術的には、間違いなく内製化は可能です。
けれど、現場の空気は冷え切っています。
「作れるようになった」ことと、「組織がそれを受け入れる」ことの間には、技術力だけでは超えられない深くて暗い溝があるのです。
製造業DXの誤算：「固定費」を嫌う会計の壁
なぜ技術的に可能なのに、内製化が進まないのでしょうか。
その答えは、技術ではなく「会計」と「採用方針」にありました。
私の会社を含め、日本の多くの製造業では、IT人材を「資産（固定費）」として抱えることを極端に嫌う傾向があります。
どれだけDXや内製化を掲げていても、本音では「必要な時だけ調達できる経費（変動費）」として扱いたいのです。
いわゆる「アクセンチュアの陰謀」などと酒の席で揶揄されることもありますが、コンサルやSIerへの外注費は何億円出ても「投資」として決裁が降りるのに、年収1000万円のエンジニアを一人雇う稟議はカチコチに固まって動きません。
この構造がある限り、生成AIでどれだけ開発効率が上がっても、「社内で作る」という選択肢が選ばれることはありません。
むしろ、AIによって開発工数が下がれば下がるほど、「じゃあ外注費も安くなるね」と、外注依存が加速するパラドックスすら起きています。
社内SEの現実：Pythonで開発できるのに「情シス」扱い
さらに難しいのは、社内に残っている数少ないIT人材の扱われ方です。
本来であれば、AIとドメイン知識を掛け合わせて、現場特有の課題を解決するツールをバリバリ開発すべき人材が、専門性のいらない事務作業や調整業務、あるいは「DX推進室」という名ばかりの「情シス（PCキッティングやアカウント管理）」業務に忙殺されています。
会社は「内製化」と言いますが、その実態は「エンジニアにコードを書かせる」ことではなく、「外注先を管理する」ことになってしまっています。
私がNext.jsで工場監視システムを作ってみせても、賞賛されるどころか「誰が保守するんだ」「属人化だ」と警戒される始末です。
しかし、経営判断としては「合理的」な側面もある
もちろん、経営層が無能だからこうなっているわけではありません。
むしろ、短期的なPL（損益計算書）の観点だけで見れば、この判断は極めて合理的です。
需要の波が激しい製造業において、簡単に解雇できない正社員（固定費）を増やすことは、経営上の大きなリスクです。
一方、外注費（変動費）であれば、業績が悪化した瞬間にカットすることができます。
過去に内製化を進めたものの、システムが陳腐化し、スキルの古い高給取りの社員だけが残ってしまった……そんな「固定費の失敗体験」を持つ経営者であれば、今の姿勢はむしろ賢明とさえ言えるでしょう。
しかし、その「短期的な合理性」こそが、AI時代における最大の足かせになっているのです。
結論：「会計思考」の限界と、新たな「学習速度」という指標
従来のシステム開発は「仕様を決めて、作る」というプロセスでした。これは外注に適しています。
しかし、AI時代のシステム開発は「現場で試して、改善し続ける」というプロセスに変わりました。
ここで問われるべきは、「いくらかかるか（コスト）」ではなく、「どれだけ速く失敗し、正解に辿り着けるか（学習速度）」です。
パラダイムシフト：PL合理性 vs 学習速度
多くの日本企業が囚われている「PL脳（損益計算書の合理性）」と、DX成功企業が持つ「速度脳（学習サイクルの最大化）」は、根本的に思想が異なります。
【IT人材の定義】
旧来：資産（固定費・コスト）
新：実験装置（検証サイクルのリソース）
【開発の主目的】
旧来：最初から正解を作ること
新：最速で仮説を検証すること
【失敗への態度】
旧来：損失（避けるべきもの）
新：学習（資産となるデータ）
【外注の役割】
旧来：リスクヘッジ（変動費化）
新：ノンコア業務（速度低下の要因）
経営層が恐れる「固定費リスク」は、正解がわかっている時代には正しい判断でした。
しかし、変化の激しい現代において最大のリスクは、固定費を持つことではなく、「変更に弱く、検証が遅い組織」であり続けることです。
DXの本質はツールの導入ではなく、組織のOSアップデート
DXの本質は、AIツールを入れることでも、業務を自動化することでもありません。
組織全体の**「学習速度（Learning Speed）」を上げること**です。
エンジニアを社内に抱える本当の価値は、コスト削減ではありません。
「外注にお伺いを立て、見積もりを取り、契約する」という数週間のリードタイムを、社内エンジニアなら「隣の席で15分でプロトタイプを作る」という速度に変えられる点にあります。
この圧倒的な「検証速度の差」こそが、不確実な未来における唯一の競争優位性です。
私たちは「AIでコードが書けるようになった」という技術論に留まってはいけません。
「IT人材＝コスト」という古い会計の呪縛を解き、「IT人材＝学習速度の源泉」という新しい思想を組織にインストールする。
それこそが、現場のエンジニアが挑むべき、本当の「エンジニアリング」なのかもしれません。
