コアシステムだけでは変化に追いつけない

製造業のDXを語るとき、真っ先に挙がるのはERP・PLM・MESといったコアシステムです。しかし現実には、これらを導入した後も「現場で使われない」「業務変化に追いつかない」という問題が後を絶ちません。

その根本的な理由は、コアシステムが「変えにくい」ように設計されているからです。ERPやPLMは業務の骨格を担うため、一度仕様を固めると変更コストが大きく、市場ニーズや現場の運用変化に柔軟に対応することが難しくなります。

エクシオ・デジタルソリューションズ株式会社をはじめ、製造業DXに深く関わるSIerが共通して語るのは、「コアシステム自体を頻繁に変えるのではなく、その周辺にローコードを配置して変化を吸収する」という発想です。ローコードはコアシステムを守りながら、業務変化・市場変化を迅速に反映させる層として機能します。

「2025年の崖」を超えた先で問われること

経済産業省が提唱した「2025年の崖」は、老朽化した基幹システムの刷新が進まなければ、2025年以降に年間最大12兆円の経済損失が生じるというシナリオです。この警鐘を受け、多くの製造業企業がERP・MESの刷新に取り組んできました。

しかし崖を超えた先には、別の課題が待っています。システムを刷新しても、その後の業務変化にどう追随するか。市場のスピードに合わせてシステムを進化させ続けるためのアーキテクチャをどう設計するか。こうした問いに答える手段として、ローコード開発が注目を集めています。

また、Gartnerはローコードの役割が「アプリを速く作る手段」から「コアシステムをクリーンに保ちながら変化を吸収する層（コンポーザブルアーキテクチャ）」へと変化していると指摘しています。さらに直近では、AIエージェントプラットフォームとの連携という新たな展開も始まっており、ローコードの位置付けはより戦略的なものになっています。

タイプ① RAD型（高速アプリ開発ツール）

代表例：Mendix、OutSystems
1970〜80年代に概念が生まれ、2010年代に再ブレイクした「Rapid Application Development（高速アプリ開発）」の流れを汲むツール群です。アプリ開発そのものを目的として設計されているため、複雑なデータ構造・業務ロジック・スケーラビリティへの対応力が高いのが特徴です。エンタープライズ用途や製造業のように複雑な要件が求められる領域で力を発揮します。

タイプ② BPM進化型

代表例：intra-mart、Appian
ビジネスプロセス管理（BPM）ツールから進化した系譜です。アプリ開発よりもワークフロー設計・プロセス管理を得意とします。承認フローや業務プロセスの標準化・自動化が主用途で、製造業でも品質管理や調達フローなどへの適用例があります。

タイプ③ 業務SaaS派生型

代表例：Microsoft Power Platform、Salesforce Lightning、ServiceNow
特定の業務SaaSを起点に、その機能を拡張するために生まれたツール群です。Microsoft 365やSalesforceとの連携が強みである一方、それら基盤なしに単独で使うと真価を発揮しにくいという性質があります。製造業の基幹システムとは距離がある場合も多く、導入目的との整合を慎重に確認する必要があります。

タイプ④ 市民開発型

代表例：kintone、Pleasanter
業務ユーザーが自分でシンプルなアプリを作ることを前提に設計されたツールです。フォーム作成・簡易ワークフロー・データ管理が主用途で、すぐに使い始められる手軽さが強みです。ただし「できることは限定的」であり、複雑な業務ロジックや既存システムとの深い連携には対応が難しい場面が出てきます。

製造業でのツール選択に加えるべき視点

この4分類に加えて、製造業特有の軸として「SCM（サプライチェーン管理）軸で使うのか、ECM（エンジニアリングチェーン管理）軸で使うのか、あるいは両方か」という視点も選定に織り込む必要があります。また、Gartner・Forrester Researchのマジック・クアドラントにおけるリーダーポジションのツールは実績・機能・将来性の観点で有力候補になりますが、グローバル評価が高いからといって自社に最適とは限りません。自社の課題・用途・既存システムとの兼ね合いで判断することが重要です。

ツール選定の前に「目的」を固める

ローコードツールの選定で最もよくある失敗は、「ツールありきで導入を進める」ことです。どのツールが機能豊富かを比較する前に、「何のためにローコードを導入するのか」を明確にすることが先決です。

たとえば、ERPの周辺業務をデジタル化したいのか、現場担当者が自分でアプリを作れるようにしたいのか、PLM・MESとデータを連携させたいのかによって、最適なタイプのツールは全く異なります。

製造業向けの選定チェックリスト

• 導入目的が「業務効率化」「現場活用」「基幹連携」のどれに近いか明確になっているか
• SCM領域・ECM領域どちらでの活用を想定しているか
• ERP・PLM・MESなど既存の基幹システムとの連携が必要か
• 業務部門主導（市民開発）か、IT部門・SIer主導の開発体制を想定しているか
• グローバル展開・多拠点対応が必要か
• 将来的なAIエージェント連携・データ活用まで視野に入れているか

これらを整理した上で、前述の4タイプのどれに当てはまるかを照合すると、選定候補が自然と絞られてきます。

ローコードツール選定の意思決定フロー

まず「既存の業務SaaS（Microsoft 365・Salesforceなど）をすでに広く活用しているか」を確認します。活用している場合は、そのSaaSと連携する業務SaaS派生型（Power Platform・Salesforce Lightning等）が候補になります。

次に「現場の業務担当者が自分でアプリを作りたいか、それともIT部門・SIerが開発するか」を確認します。前者であれば市民開発型（kintone等）、後者であれば複雑度によって分岐します。

複雑な業務ロジック・基幹システム連携・スケーラビリティが必要な場合はRAD型（Mendix・OutSystems）、承認フロー・プロセス管理が主目的であればBPM進化型（intra-mart・Appian）が適しています。

製造業でERP・PLM・MESとの連携を重視する場合は、Siemens製品との親和性とSAP連携実績を持つMendixが有力候補です。

成功企業と失敗企業の差はどこにあるか

ローコードを上手く活用できている企業とそうでない企業の差は、ツール選びよりも「目的の明確さ」と「組織体制の整備」にあります。失敗しやすいパターンは以下の3つです。

• 単なる「IT効率化ツール」として導入し、現場の課題理解が浅いまま進めることで、要件定義がズレたシステムが出来上がり、現場に使われないまま放置される
• 組織的にローコードを支える仕組みがなく、担当者が孤立して属人化が進む
• 目標設定があいまいで「とにかく作る」が目的になり、ビジネス成果が見えなくなる

逆に成功している企業は、明確な導入目的の設定・小さく試して素早く改善するサイクル・組織的な支援体制の三点が整っています。

導入前にやるべきこと

導入後にやるべきこと

特に製造業では、「全体アーキテクチャを完璧に描いてから着手する」アプローチは現実的に難しいケースが多いとされています。ERP・PLM・MESの刷新プロジェクトは数年単位になり、その間に要件が変化することも珍しくありません。「スモールスタートで実証しながら全体像を固めていく」アジャイル的なアプローチが、ローコードの特性を活かす上でも合理的です。

ノーコードとローコードの違い：できることとスキル要件

「ノーコードで全部できる」「ローコードは誰でもすぐ使える」という認識は、どちらも誤解です。両者の違いを正しく理解することが、適切なツール選定につながります。

既存システムとの連携は「できるが、簡単ではない」

ローコードと既存のERP・MES・PLMとの連携は、技術的には可能です。主な連携手段としてはREST API・SOAP通信・データベース連携・ファイル連携・iPaaSの活用が挙げられます。ただし、認証設計・データ整合性の確保・エラー時の処理・ベンダー制約の把握など、非エンジニアには難易度の高い課題が伴います。

さらに製造業における既存システム連携で最大の壁となるのは、「クラウド（SaaS）」と「オンプレミス」のネットワーク境界です。MESや古いERPはインターネットから隔離されていることが多く、SaaS型のローコードツールから単純にAPI連携するハードルは高いです。セキュアなデータゲートウェイの構築が必要になるか、あるいはMendixのように「自社のオンプレミス環境やプライベートクラウドに直接デプロイできる」アーキテクチャを持つツールを選定し、システムを同じ閉域網内で連携させる設計が求められます。

現実的なアーキテクチャとしては、ローコード単体で全てを完結させようとせず、役割分担を明確にするアプローチが有効です。