生産管理システム スクラッチ開発｜タイ工場の発注実務

タイ工場で生産管理システム スクラッチ開発を検討するとき、最初に決めるべきことは「パッケージかスクラッチか」ではありません。先に、どの業務を標準化し、どの競争力を個別仕様として残し、ERP・MES・設備のどこにデータ責任を置くかを決めます。その境界が曖昧なまま見積を取ると、各社が違う前提で提案し、価格も納期も比較できません。

本稿では、タイの製造拠点で生産管理システムを発注する責任者向けに、パッケージ、カスタマイズ、スクラッチの判断方法、RFP、ISA-95を使った要件境界、データ移行、受入試験、ソースと運用移管、TCO、90日ディスカバリーから段階導入までを実務の形に整理します。特定製品や開発方式を万能解として推奨する記事ではありません。現場の制約、保守体制、法務・セキュリティ要件を確認し、比較可能な証拠に変えるためのガイドです。

生産管理システム スクラッチ開発とは

スクラッチ開発とは、自社の業務要件に合わせ、データモデル、画面、ワークフロー、連携、権限、帳票などを個別に設計・実装する方式です。ただし「すべてをゼロから作る」という意味ではありません。データベース、認証、クラウド基盤、開発フレームワーク、監視、帳票エンジンなど、適切な既製技術を組み合わせながら、工場固有の業務ロジックと統合境界を作ります。

一方、パッケージは製品が持つ標準業務に自社を合わせる方式、カスタマイズは標準機能を土台に設定、拡張、アドオン、外部連携で差分を埋める方式です。実際の案件は三択ではなく、ERPはパッケージ、生産実行は個別アプリ、設備収集は既存ミドルウェアという混成になることが多いため、方式名よりも「誰がどの機能とデータを所有するか」が重要です。

スクラッチ開発が向く要件

次の条件が複数重なる場合、スクラッチまたは大幅な個別開発を検討する合理性があります。

• 工程順、投入制約、ロット形成、段取り、外注、検査判定などが自社の競争力に直結する
• 多品種少量、個別受注、連産品など、標準パッケージの前提と現場運用が大きく異なる
• ERP、WMS、品質、保全、PLC、計測器など複数システムとの一貫したデータ境界が必要
• タイ工場の言語、承認、シフト、設備制約に合わせた操作が不可欠
• 標準機能に業務を合わせる変更コストが、個別実装より大きい
• 長期的に自社主導で機能を改善し、ソースとデータモデルを管理したい

ただし「業務が特殊」という主張だけでは不十分です。本当に差別化要件なのか、単なる慣習なのか、法規・顧客要求なのかを分け、標準化できる業務は標準化します。特殊性を無条件に残すと、現行の非効率までコードに固定されます。

生産管理システム パッケージが向く要件

会計、購買、在庫、標準的な受払、マスタ管理など、業務を業界標準へ寄せやすい領域では、パッケージの標準機能、更新、導入実績、サポート網が利点になります。要件の大半が製品標準で満たせ、業務変更を受け入れられ、拡張が公開された仕組みで管理できるなら、個別コードを減らせます。

重要なのはデモで機能が見えることではなく、対象版・対象契約で利用できるか、設定で済むかコード改修が必要か、更新時に拡張が維持されるかを確認することです。製品名ではなく、適合する要求IDと差分一覧で判断します。

パッケージ・カスタマイズ・スクラッチの判断表

方式は一つの合計点で決めず、業務領域ごとに比較します。例えば、品目・取引先マスタはERP、実績収集と仕掛追跡はMES、独自の配合最適化は個別アプリという分割が可能です。

比較では「できる／できない」ではなく、標準、設定、拡張、外部連携、非対応の五区分にします。さらに、各区分へ検証方法、追加費用、更新影響、代替運用を付けます。すでに方式比較を始めている場合は、タイ工場向け生産管理システム比較も合わせて、製品機能と自社要件を同じ表で評価してください。

生産管理システム カスタマイズの境界を先に決める

カスタマイズは便利な中間案ですが、境界が曖昧だと最も複雑になります。製品標準を直接改変すると、更新のたびに差分を再適用・再試験する必要が生じます。可能なら、設定、公開API、イベント、拡張テーブル、外部サービスなど、製品が保証する拡張点を使います。

RFPでは各要求について、次を回答させます。

1. 標準機能か。対象版と設定項目は何か。
2. 設定のみか、ローコード拡張か、個別コードか。
3. 標準ソースを変更するか。変更するなら差分管理方法は何か。
4. 製品更新時の互換性を誰が確認し、費用を負担するか。
5. 拡張が停止した場合の業務継続方法はあるか。
6. データを標準形式で抽出できるか。

「カスタマイズ可能」は要件回答ではありません。拡張点、制限、検証済み版、再試験範囲、所有者まで書かれて初めて比較できます。

ISA-95でERP・MES・設備の要件境界を切る

ISA-95は、企業・物流側と製造オペレーション・制御側の統合を整理する国際的な標準群です。ISAの公式説明では、レベル0を物理プロセス、レベル1をセンシングと操作、レベル2を監視・制御、レベル3を製造オペレーション管理、レベル4を事業計画・物流として説明し、特にレベル3と4のインターフェースを扱います。これは製品選定表ではなく、活動、情報、責任の境界を共通語で話すための参照モデルです。

生産管理システムの発注では、次のように使えます。

境界で最も重要なのは、同じ概念を複数システムが「正本」として持たないことです。例えば、MESとERPの両方が在庫を独立計算し、差異だけを夜間修正する構成では、障害時の復旧と監査が難しくなります。正本、参照コピー、更新権限、同期頻度、再送、重複排除、照合、手動補正の責任を一つずつ決めます。

インターフェース契約に必要な項目

API名だけでは連携仕様になりません。各インターフェースに、送信者・受信者、業務イベント、データ項目、単位、コード体系、時刻、順序、再送、タイムアウト、重複排除、エラー通知、リカバリー、監視責任を記載します。

特にタイ工場と日本本社で日付・時刻を扱う場合、タイムゾーン、夏時間の有無、サーバー時刻、現地表示、締め時刻を明記します。数量には基準単位と表示単位、換算精度、端数処理を設定します。品目、工程、設備、ロットの識別子は、表示名と不変IDを分けます。

GS1のGlobal Traceability Standardは、識別・取得・共有を基礎とし、追跡対象のライフサイクルにおけるイベントとデータを扱います。GS1のトレーサビリティ説明では、Critical Tracking EventsとKey Data Elementsという考え方も示されています。GS1適用が必須でない工場でも、「何が、いつ、どこで、どのイベントを通り、どのデータを残すか」をRFPで定義する参考になります。

RFPは画面一覧ではなく受入可能な業務契約にする

生産管理システムのRFPは、機能チェックリストだけでは足りません。業務目的、対象範囲、利用者、データ責任、品質属性、成果物、受入方法、移管条件を一つの契約可能な構造にします。

RFPに含める章立て

要求は「誰が・いつ・何を・どの条件で」にする

「進捗を見える化する」では合格条件がありません。例えば、「生産管理者が、当日シフトの製造指図について、計画数、良品数、不良数、停止状態、最終更新時刻をライン別に確認でき、データ欠損時は欠損と分かる」と書けば、画面、データ、更新、異常表示を試験できます。

要求IDには、業務シナリオ、優先度、根拠、所有者、実現方式、設計、テストID、結果を結びます。要件変更は、影響するデータ、連携、権限、帳票、翻訳、試験、教育を追跡して見積もります。

非機能要件は数値だけでなく測定条件を決める

応答時間、同時利用、データ量、可用性、復旧目標、バックアップ、監査ログ、保持期間を定義するときは、対象画面、ネットワーク、データ件数、ピーク条件、除外時間も書きます。「高速」「24時間対応」だけでは検収できません。

数値は現場観測と事業影響から設定します。本稿で一律の性能値や可用性を提示しないのは、ライン停止の影響、ネットワーク、取引要件、運用体制が工場ごとに異なるためです。RFPでは、根拠のない目標値を置くより、測定方法と責任者を先に決めます。

業務システム 開発会社を比較する質問

提案書のページ数や技術用語ではなく、要件を証拠へ変える能力を比較します。

• タイ工場で現場観察とユーザー検証を誰が、何語で行うか
• 要求から設計、コード、テストまでの追跡性をどう維持するか
• 標準機能・拡張・個別コードをどう分類するか
• データ移行の品質指標、照合、再実行、ロールバックをどう設計するか
• ERP・設備側の別ベンダーと障害をどう切り分けるか
• 開発・検証・本番環境の分離とリリース承認をどう行うか
• 脆弱性、依存ライブラリ、秘密情報、アクセス権をどう管理するか
• ソース、ビルド、運用文書、クラウド契約をどの状態で移管するか
• 担当者が交代しても保守できる文書と教育があるか
• 稼働後の変更単価、優先度、緊急対応、保証境界は何か

NIST SP 800-218のSecure Software Development Framework（SSDF）は、既存の開発ライフサイクルへ組み込める高水準のセキュア開発実践を整理し、ソフトウェア取得側が供給者との共通語として使えると説明しています。RFPでは、開発環境保護、コード・依存物の管理、脆弱性対応、リリース完全性、問題の根本原因対応などを、宣言だけでなく成果物と証跡で確認します。

CISAのSecure by Demand Guideも、ソフトウェアの買い手が調達プロセスでセキュリティを明示的に要求し、メーカーの取組を確認するための質問を提示しています。工場システムの発注者は、セキュリティを「ベンダー標準」に丸投げせず、アカウント、ログ、更新、通知、サポート終了、バックアップ、インシデント対応を契約前に確認すべきです。

データ移行はコピー作業ではなく業務移管

データ移行で難しいのは、ファイルを取り込むことではなく、古い定義を新しい業務へ変換し、移行後の数字を業務責任者が信頼できる状態にすることです。

最初にデータ台帳を作る

対象ごとに、所有システム、所有者、件数、期間、形式、文字コード、主キー、重複、欠損、単位、保持根拠、個人情報、移行要否を記録します。品目、BOM、工程、設備、取引先、在庫、ロット、未完了指図、品質、ユーザー、権限を同じ「データ」として一括せず、業務責任者を分けます。

マッピングとクレンジングを承認する

旧コードと新コードの対応、廃止値、統合・分割、単位換算、桁数、丸め、タイムゾーン、未入力値の扱いを変換仕様にします。自動補正した値は件数と規則を記録し、業務担当者が承認します。判断できない値を開発会社が推測で埋めてはいけません。

移行リハーサルと照合

移行は少なくとも、抽出、変換、投入、技術照合、業務照合、欠陥修正、再実行の一連を本番前に反復します。照合は総件数だけでなく、数量合計、金額、状態別件数、サンプル追跡、親子関係、未完了業務、権限を確認します。

切替計画には、データ凍結、最終差分、停止判断、Go/No-Go、ロールバック、旧システムの参照、監査証跡、問い合わせ窓口を含めます。ロールバックは「戻せる」ではなく、誰が何時点で判断し、どのデータをどこまで戻すかを試験します。

受入試験はFAT・UAT・SATを役割で分ける

受入試験では、機能が動くこと、利用者が業務を完了できること、実際の工場環境で連携と運用が成立することを分けて確認します。

正常系だけでなく例外を試す

標準的な受注から完了までだけでは不十分です。欠品、代替材料、分割、再作業、不適合保留、設備停止、通信断、重複送信、締め後訂正、ユーザー無効化、バックアップ復元を試します。設備を安全に止められない試験は、シミュレーションで代替する範囲と残存リスクを承認します。

合格判定を事前に決める

重大度の定義、合格に必要な結果、未解決欠陥の扱い、再試験、証跡、条件付き受入、保証開始を契約前に決めます。「軽微な不具合」の意味を納入直前に協議すると、稼働判断が商務交渉になります。

各テストは要求ID、前提データ、操作手順、期待結果、実績、証拠、実施者、日時、環境版へ結びます。スクリーンショットだけでなく、必要に応じてログ、API結果、データベース照合、設備信号、承認記録を残します。

導入全体のゲートと役割分担は、生産管理システム導入プロセスも参照し、構想、要件、設計、移行、試験、切替を一つの計画へ統合してください。

ソースコード・知財・運用移管の発注条件

スクラッチ開発では、ソースを受け取るだけで自立運用できるとは限りません。再現可能なビルド、依存物、環境構成、秘密情報の引継ぎ、監視、障害対応、データ抽出、教育が必要です。

契約で確認する所有と利用権

• 新規作成したソースコード、設計書、テスト、データモデルの権利
• 開発会社の既存部品、第三者ライブラリ、OSSの範囲とライセンス
• 自社内・関係会社・後継保守会社が修正できる利用権
• 契約終了時のデータ抽出形式、期限、費用、削除証明
• 商標、画像、フォント、帳票部品など非コード資産の権利
• ソース開示の時点、リポジトリ管理者、エスクローが必要な条件

法的判断は契約当事者と専門家が行うべきですが、技術チームは構成要素台帳を作り、「何が自社所有で、何が利用許諾か」を説明できるようにします。

移管成果物

最終受入では、納入先が管理するクリーン環境からビルドし、検証環境へ展開し、バックアップから復元し、軽微な変更をリリースする演習を行います。開発会社の個人端末や個人アカウントだけで再現できる状態は、移管完了ではありません。

TCOは初期開発費ではなく変化の費用まで見る

TCOには、初期の要件定義、設計、開発、ライセンス、クラウド、設備連携、移行、教育に加え、監視、問い合わせ、障害、脆弱性対応、製品更新、依存物更新、機能改善、データ保管、監査、契約終了、再移行を含めます。

概念式は次のように置けます。

TCO = 導入費 + 稼働基盤費 + 運用保守費 + 変更費 + リスク対応費 + 終了・移行費

試算では一つの精密な数字を作るより、前提を変えた複数シナリオを比較します。拠点追加、利用者増、ライン追加、大規模改修、製品更新、保守会社変更、停止事故などの変化に対し、費用とリードタイムがどう変わるかを見ます。割引率、評価年数、為替、社内工数は財務方針に合わせ、同じ前提で比較します。

90日ディスカバリーから段階導入する方法

90日ディスカバリーは、90日で全システムを完成させる計画ではありません。投資判断に必要な業務・データ・技術・移行・運用の不確実性を減らし、段階導入の範囲と受入条件を決める期間です。日数は組織規模に応じて調整するもので、ここでは普遍的な工期ではなく、発注準備に使える実務上の一例として示します。

1〜30日：現場と境界を可視化

• 経営目的、対象KPI、意思決定者を確認する
• タイ現場でシフト、例外、紙・Excel、二重入力を観察する
• 現行システム、設備、インターフェース、データ所有者を棚卸しする
• ISA-95を参照し、ERP、MES、設備、周辺システムの責任境界を仮置きする
• パッケージ標準へ合わせる業務と差別化要件を分類する

成果物は、対象業務マップ、課題・KPI台帳、システム構成、データ台帳、要件仮説です。

31〜60日：代表シナリオを検証

• 代表製品・ラインの業務シナリオを端から端まで定義する
• 主要画面またはプロトタイプで現場利用者と操作を確認する
• パッケージ候補のFit-to-Standardと差分を検証する
• 主要インターフェースとデータ品質を小さく技術検証する
• 移行、性能、セキュリティ、停止時間の高リスク仮説を試す

成果物は、要求追跡表、方式比較、プロトタイプ、Fit/Gap、技術検証結果、リスク台帳です。

61〜90日：RFPと段階導入を確定

• MVPではなく「最小の運用可能範囲」を決める
• 移行、UAT、SAT、教育、切替、ロールバックを計画する
• ソース、知財、クラウド、保守、SLA、移管条件を確定する
• 要求ID別の見積様式とベンダー評価表を作る
• 投資、TCO、効果測定、次段階への合格ゲートを承認する

成果物は、RFP、段階ロードマップ、受入計画、移行計画、運用モデル、TCOシナリオ、意思決定資料です。

段階導入の単位

一度に全工場へ展開するのではなく、代表ラインや一つの製品群で、計画配信、実績、仕掛、品質、在庫連携など一続きの業務価値を実現します。画面だけ、データ収集だけのように業務が閉じない単位ではなく、担当者が旧運用を止められる単位を選びます。

初期段階の合格後に、別ライン、別製品、詳細計画、保全、原価などへ広げます。各段階でKPI、データ品質、利用率、欠陥、サポート負荷、バックログを評価し、次段階の設計へ反映します。

タイ工場で追加確認すべき事項

現場言語と承認

日本語要件を英訳して開発し、タイ語を最後に追加する進め方では、現場の判断語と画面がずれます。品目、工程、設備、状態、不良、停止理由の用語集を早期に作り、タイ人キーユーザーが業務シナリオと一緒に承認します。翻訳対象は画面だけでなく、エラー、通知、帳票、教育、運用手順も含みます。

ネットワークと設備停止

事務所では安定していても、工場Wi-Fi、端末、PLCネットワーク、時刻同期、電源、遠隔接続に制約があります。現地調査で接続点と責任者を確認し、通信断、遅延、再接続、オフライン業務を試します。既設設備への接続は安全と生産影響を評価し、承認された停止窓で行います。

タイのデジタル化支援情報

depaのDigital Transformation枠は、デジタル技術を製品・サービス、業務プロセス、生産性や付加価値の向上へ適用する考え方を示しています。また、depaが2025年4月に公表した2024 Digital Density Surveyの説明では、調査対象の多くが部門別に分離した情報システムや比較的初期段階のデジタル利用にとどまる状況を報告しています。これは個別企業の成熟度を示すものではありませんが、連携境界とデータ正本を先に決める重要性を裏付ける現地文脈です。

BOIのSmart and Sustainable Industry向け現行ページには、製造・サービスの効率向上や高度化を促す措置と条件が掲載されています。ただし、生産管理システム開発が自動的に優遇対象になるとは限りません。対象法人、活動、投資、設備、申請時期で判断が変わるため、申請前にBOIまたは資格ある専門家へ確認してください。

FAQ：生産管理システム スクラッチ開発のよくある質問

生産管理システム スクラッチ開発の費用はどう比較しますか？

総額だけでなく、要求・設計、連携、移行、試験、教育、ソース移管、保証、運用、変更の内訳と前提を揃えます。各要求を標準、設定、拡張、個別コード、非対応に分類し、更新影響と再試験も比較してください。

生産管理システム パッケージとスクラッチはどちらが安いですか？

一律には決まりません。標準業務へ合わせられる範囲が大きければパッケージが有利になりやすく、独自業務・複雑な連携・長期変更が大きければスクラッチが合理的な場合があります。初期費用ではなく、変更と終了まで含むTCOで同じシナリオを比較します。

生産管理システム カスタマイズで避けるべきことは？

標準ソースの直接改変、更新影響が不明な拡張、個人しか分からない設定、抽出できないデータ、試験のない変更を避けます。製品が保証する拡張点を使い、差分台帳と回帰試験を維持します。

業務システム 開発のRFPに最も必要なものは？

利用者が完了すべき業務シナリオ、システム・データの責任境界、測定可能な受入条件です。画面一覧や機能名だけでなく、例外処理、移行、非機能、成果物、運用移管を要求IDへ結びます。

システム開発 委託でソースコードは必ず受け取るべきですか？

スクラッチや重要な個別拡張では、継続性のために移管条件を検討すべきです。ただしソースだけでは不十分です。ビルド、依存物、環境、テスト、データ辞書、監視、バックアップ、権限、教育を含め、納入先が再現できる状態で受け取ります。

ISA-95に準拠すれば要件定義は完了しますか？

いいえ。ISA-95は活動・情報・統合境界を整理する有力な共通語ですが、工場固有の業務ルール、性能、セキュリティ、UI、移行、受入、法務を自動的に決めません。参照モデルとして使い、具体的な要求と試験へ落とします。

90日ディスカバリー中に開発も始めますか？

高リスク仮説を検証する小さなプロトタイプや技術検証は有効です。ただし、未承認の全体設計を本番コードとして積み上げないことが重要です。90日後に捨てる検証物と、製品化する資産を契約と品質基準で分けます。

タイ工場のデータ移行で注意する点は？

英語・タイ語・日本語の文字、品目別名、単位、時刻、Excel手入力、重複コード、旧設備IDを確認します。現場責任者がマッピングと照合を承認し、停止窓、差分移行、ロールバック、旧システム参照をリハーサルします。

まとめ：方式ではなく境界・証拠・移管で発注する

生産管理システム スクラッチ開発を成功させる鍵は、最初からスクラッチを選ぶことではありません。標準化する業務と差別化する業務を分け、ISA-95を共通語にERP・MES・設備の責任境界を決め、各要求を実現方式と受入証拠へ結びます。データ移行、例外試験、ソースと運用移管、TCOまでRFPに入れれば、パッケージ、カスタマイズ、スクラッチを同じ土俵で比較できます。90日ディスカバリーでは不確実性を減らし、業務が閉じる単位で段階導入してください。

タイ工場向け生産管理システムの構想段階で、まだ方式やベンダーが決まっていない場合でも、現場業務の整理、Fit/Gap、RFP、データ移行・受入条件のたたき台から相談できます。TOMAS TECHへのお問い合わせで、対象工場、現行システム、優先課題など分かる範囲をお知らせください。

参考情報

• NIST SP 800-218: Secure Software Development Framework Version 1.1
• ISA-95 Series of Standards
• GS1 Global Traceability Standard
• GS1 Traceability Standards
• CISA Secure by Demand Guide
• depa Digital Transformation
• depa 2024 Digital Density Survey announcement
• Thailand BOI: Smart and Sustainable Industry