製造業のMES・基幹DBをJiteraで可視化する

製造現場では、MES、生産管理、品質管理、在庫管理、販売管理などのシステムが連携し、多数のテーブルやプログラムが長年にわたって蓄積されています。システムが安定稼働していても、どのテーブルがどの機能から参照されているのか、ある項目を変更するとどこへ影響するのかが分かりにくくなることがあります。

Jiteraの開発AIエージェントは、許可されたDBスキーマ、SQL、ソースコード、設計書、連携仕様などをもとに、テーブル、機能、API、バッチなどの関係を整理し、改修前の影響調査やシステム知識の共有を支援します。抽出された関係や影響範囲の正しさ・網羅性を保証するものではないため、実際の資産や運用と照合しながら利用してください。

本記事では、製造業の基幹システムを可視化し、調査や開発を効率化する進め方を解説します。

製造業の基幹システムに潜む課題

MES・基幹DBの依存関係が複雑になる

MESでは、製造指図、工程、作業実績、設備、品質検査、在庫、ロットなどの情報が連携します。テーブル名や項目名だけでは、どの処理がどのデータを利用しているのかを判断できないことがあります。ビュー、ストアドプログラム、バッチ、外部連携を含めて関係を確認しなければ、改修の影響範囲を把握しにくくなります。

改修時の影響調査に時間がかかる

工場向けシステムでは、現場の停止を避けながら改修を行う必要があります。設計書が古い場合や資料が複数の場所に分散している場合は、変更対象から関連する画面、API、バッチ、帳票、外部連携、テーブルを確認する作業が発生します。調査の起点と確認項目をそろえ、関連する資産を横断して確認できる状態を作ることが重要です。

システム知識が属人化し、引き継ぎに時間がかかる

長年担当してきた社員や委託先だけが、設計書に残っていない経緯や注意点を把握していることがあります。ソースコードやDBの構造だけでなく、業務上の意味、例外条件、確認方法を合わせて整理し、チームで参照できる形にする必要があります。

Jiteraで依存関係を整理する手順

DBスキーマ・ソースコードを許可された範囲で登録する

登録時には、システム名、環境、更新日、対象工場、担当部署、機密区分を付与します。開発環境と本番環境の定義が混ざらないよう、環境情報を明確にしてください。顧客情報、製造情報、認証情報などを扱う場合は、利用目的、アクセス権限、保管期間、ログ、マスキング、組織の規程を事前に確認し、必要な範囲に限定します。

テーブル・機能間の関係を整理する

依存関係を確認するときは、関係の種類を区別します。参照、登録、更新、削除、集計、連携を分けると、改修時に確認すべきリスクを整理しやすくなります。

依存関係の整理例

製造指図登録
  ├─ 製造指図テーブルを登録
  ├─ 工程テーブルを参照
  ├─ 設備指示APIを呼び出し
  └─ 作業実績登録の対象データを作成

作業実績登録
  ├─ 作業実績テーブルを登録
  ├─ 製造指図テーブルを参照
  ├─ 品質検査対象テーブルを更新
  └─ 基幹DBの在庫・原価連携データを作成

このような整理は、登録済みのスキーマやコードなどから関係を確認するためのたたき台です。登録資料に記載がない関係を推測で補完したり、図だけを根拠に改修範囲を確定したりしないでください。

影響範囲の調査観点をそろえる

改修対象のテーブル、カラム、API、画面などを指定し、関連する資産を上流と下流に分けて確認します。

依存関係解析のプロンプト例

架空の製造会社「富士山精機株式会社」のMESについて、許可されたDBスキーマ、SQL、ソースコード、連携仕様書だけを参照し、影響調査のたたき台を作成してください。

変更対象：
- 作業実績テーブルの「実績数量」項目
- 作業実績登録API

次の形式で整理してください。
1. 直接参照・更新する画面、API、バッチ
2. 上流の入力元と下流の連携先
3. 関係するテーブル、ビュー、帳票
4. MES以外に影響する外部システム
5. 工場や工程ごとの利用差異
6. 想定されるテスト観点
7. 登録資料では確認できない事項
8. 担当者がコードと設計書で確認すべき事項

登録資料にない関係は推測で補わず、「要確認」と記載してください。

出力された結果は、情シス、開発、現場、設備、品質などの関係者がコード、DB定義、設計書、運用実態と照合します。変更の安全性、テストの十分性、リリース可否は、権限を持つ担当者が判断してください。

解析結果をチームの知識として記録する

自動抽出された結果と、人が確認した内容を分けて記録すると、どこまで検証済みなのかを把握しやすくなります。次の項目を記録します。

• 解析対象のシステム、環境、工場
• 解析日時と参照した資産の更新日
• 自動抽出された関係と担当者が確認した関係
• 未確認の関係と確認予定
• 例外処理や工場固有の運用
• 確認者、確認日、参照した資料

工場向けシステムの設計・開発を支援する

要件定義書を起点に設計案やコードのたたき台を作成する

新しい工場向けシステムや既存機能の再構築では、要件定義書を起点に、画面、API、DBスキーマ、エラー処理、連携、テスト観点の設計案やコードのたたき台作成を支援できます。Jiteraに要件、業務ルール、既存システムとの関係、利用者権限を登録し、成果物の形式を指定します。

Jiteraが作成した設計案やコードは、そのまま本番環境へ適用しないでください。既存の開発標準、セキュリティ基準、性能要件、設備制約、工場の運用条件に照らしてレビューし、必要なテストと承認を経て適用します。

ハードウェア・基幹DBとの連携で確認すること

設備や基幹システムとの接続では、Jiteraが連携の成立や性能を保証するものではありません。実機、検証環境、ネットワーク、障害復旧手順などを含め、担当者が検証してください。

活用例と効果検証

大手製造業（電池メーカー）の匿名事例

社内資料に記載された匿名事例では、Oracle Databaseを基盤とするMESの依存関係や運用保守の属人化が課題となっていました。DBのマッピングや依存関係の整理を支援し、システム可視化時間を2週間から1日、影響範囲分析時間を3日から1日に短縮したとされています。これらは特定の活用例における実績値であり、すべての環境で同じ効果が得られることを示すものではありません。

大手自動車メーカーの匿名事例

社内資料に記載された匿名事例では、工場向けシステムの開発期間を11ヶ月から3ヶ月に短縮し、世界5工場へ展開した例が整理されています。複数工場へ展開する際は、単一工場で動作したことだけで判断せず、工場ごとの設備、ネットワーク、時刻、単位、生産品目、工程、権限、障害復旧、教育、運用体制の違いを検証してください。開発期間や展開範囲は、要件、既存資産、体制、検証環境などによって変わります。

効果を検証する指標

導入効果や工数削減をあらかじめ保証せず、対象範囲を限定して、次の指標を導入前後で比較します。

• 影響範囲の調査時間
• 関係者への確認回数とレビュー時間
• 未確認事項の件数
• 設計書・コード間の差異の件数
• テスト観点の追加・修正回数
• 運用手順の引き継ぎに要した時間
• 工場や工程ごとの適合性、障害発生時の復旧性

可視化結果を業務変更、設備操作、リリース判断に使う場合は、関係部署のレビューと承認を経てください。

まとめ

製造業のMES・基幹DBを可視化するには、次の順序で進めることが重要です。

1. 対象システム、工場、環境、利用目的を明確にする
2. DBスキーマ、ソースコード、設計書、連携仕様を許可された範囲で登録する
3. テーブル、画面、API、バッチ、外部システムの関係を整理する
4. 改修対象から上流・下流の影響範囲を確認する
5. 自動抽出結果と担当者が検証した情報を分けて記録する
6. 要件定義書を起点に、UI、API、DBスキーマの設計案を作成する
7. 現場、情シス、開発、設備、品質などの関係者がレビューする
8. 小さな範囲で効果と品質を検証してから、他工場への展開を判断する