タイの製造現場でアプリケーション開発 製造業の委託先を探すとき、最初に画面一覧や使用技術を決めると、ERP・MES・設備の境界、データの正本、通信断時の運用が後から食い違います。必要なのは「便利な業務アプリ」ではなく、工場の一つの判断を確実に支え、異常時にも責任の所在と復旧方法が分かる仕組みです。本稿では、RFP、ベンダー比較、ERP連携、受入試験、90日パイロット、ソースと運用の引継ぎまでを、発注者が検証できる形に整理します。
アプリケーション開発を製造業で成功させる結論
結論は、機能の数ではなく、次の五つを契約可能な成果物にすることです。
- ERP、MES、WMS、PLC・SCADA、端末、今回のアプリの責任を示す境界図
- 識別子、単位、時刻、状態遷移、再送、照合を定めるデータ契約
- 通信断、競合、二重登録、端末交換まで含む現場挙動
- 正常系と障害・復旧を同じ証拠で判定する受入基準
- ソース、ビルド、設定、展開、監視、教育を移管する引継ぎパッケージ
この五つが曖昧なままでは、デモ画面が美しくても、本番で「誰が直すのか」「どちらの数字が正しいのか」「ネットワーク復旧後に二重計上されないか」を判断できません。反対に、境界と証拠が先に決まっていれば、スクラッチ開発、ローコード、パッケージ拡張のどれを選んでも比較軸が保たれます。
既に発注先の一般的な比較を始めている方は、タイのシステム開発会社選びも併せて確認してください。本稿はそこから一段踏み込み、製造業特有のIT・OT境界と受入証拠に焦点を当てます。生産管理全体を個別開発する判断については、タイ製造業の生産管理システム・スクラッチ開発ガイドが補完になります。
画面一覧より先に「一つの摩擦」と「一つの判断」を選ぶ
TOMAS TECHは、最初の対象を「工場全体のデジタル化」ではなく、現場で繰り返し起きる高摩擦の業務一つと、その結果として改善したい判断・KPI一つに絞ることを推奨します。これは外部統計ではなく、要件を検証可能にするための実務的な進め方です。
例えば、紙の作業実績を後からERPへ転記している工程なら、単に入力画面を電子化するのではありません。班長が「計画に対してどの注文が遅れているか」をシフト中に判断できることを目的にします。対象は作業開始・完了、良品・不良数、停止理由、担当設備などに限定し、判断に不要な欄は初期パイロットへ持ち込みません。
別の例では、保全依頼をチャットと紙で管理している工場で、「どの停止を先に処置するか」を決めることを目的にできます。この場合、必要なのは派手なダッシュボードより、設備ID、停止開始時刻、症状、危険度、担当、部品待ち、復旧確認の一貫した状態遷移です。
対象選定では、次の質問に一文で答えます。
- 誰が、どの場所・シフトで、何を二重入力または待っているか
- どの判断が遅れ、誤り、または個人依存になっているか
- 判断の前後で、どのシステムが正本を持つか
- 通信断や設備停止中でも最低限続ける必要がある業務は何か
- 90日パイロット終了時に、どの証拠を見て継続・修正・中止を決めるか
「全帳票をアプリ化する」「ERPと全部つなぐ」は対象ではなく願望です。最初の範囲を狭めることは、最終構想を小さくすることではありません。境界、データ品質、支援体制を一つの実運用で確かめてから横展開するためのゲートです。
業務アプリ開発かパッケージかを境界で判断する
パッケージ、ローコード、個別開発にはそれぞれ適所があります。「スクラッチなら柔軟」「パッケージなら安い」と一般化せず、変更の中心がどこにあるかで比べます。
| 判断項目 | パッケージ設定・拡張が向く | 個別の業務アプリ開発が向く | 発注前の確認 |
|---|---|---|---|
| 業務の標準性 | 標準的な購買、在庫、承認 | 独自の工程順、品質判定、設備連携 | 独自性は競争力か、単なる慣習か |
| 変更頻度 | ベンダーの更新周期に合わせられる | 現場改善で短い周期の変更が必要 | 誰が変更を承認・試験するか |
| OT連携 | 標準コネクタで足りる | PLC、SCADA、特殊端末との調整が多い | 読み書き方向と安全境界 |
| オフライン | 製品の既定動作で受容できる | キュー、競合解決、端末運用が固有 | 何分・何件を保持し、どう戻すか |
| データ正本 | パッケージ側へ統合できる | ERP等を正本に保ち補助動作を作る | masterとtransactionのowner |
| 引継ぎ | SLAと製品ロードマップを受容 | ソース・ビルド・運用を自社へ移管したい | exit時のデータ・文書・権利 |
ローコードも「コードを書かないから簡単」とは限りません。コネクタ、ライセンス、端末、ブラウザ、オフライン、環境移送、監査ログの制約は製品ごとに異なります。Microsoftの公式Power Apps資料でも、オフライン動作はアプリ種別やコネクタ、データ構成に依存し、ブラウザのcanvas appはオフライン動作しないと説明されています。これはPower Apps固有の例であり、全プラットフォームへ一般化すべきではありません。ただし、「オフライン対応」をチェック欄一つで済ませず、端末・アプリ・データごとの試験条件へ分解すべきことは示しています。
システムインテグレーターと作る境界図
ISA-95 / IEC 62264は、物流・ビジネス系と製造制御系の統合に共通用語とモデルを提供します。Part 2はLevel 3の製造システムとLevel 4のビジネスシステム間で交換する情報を扱い、統合リスク、コスト、誤りの低減を目標とします。ISAは2025年版Part 1を掲載しています。ここでは認証を必須と主張するのではなく、境界とデータ所有を話すための土台として使います。
境界図には少なくとも、ERP、MES、WMS、今回のfactory app、integration/API層、OT data gateway、PLC・SCADA、バーコード・計量器・カメラ等の端末を置きます。そして各矢印に「何を」「どちら向きへ」「いつ」「失敗時は誰が」流すかを添えます。箱だけのアーキテクチャ図では責任分界になりません。
OPC UAはセンサー・制御システムからMES・ERPまでを対象にし、情報モデル、サービス、適合性、安全で信頼できる交換を扱います。認証、暗号化、完全性確認、現在値・履歴値、アラーム・イベント、Client-ServerとPubSubのパターンを含みます。ただし、OPC UAを採用するだけでデータの意味やownerが決まるわけではありません。タグ COUNT_01 が累計か差分か、単位が個か箱か、reset時にどう扱うかは別途データ契約で定めます。
| 対象 | Accountable（最終責任） | Responsible（実行） | Consulted / Informed | 境界で固定する事項 |
|---|---|---|---|---|
| 品目・BOM・注文master | 業務owner | ERP team | 生産管理、SI | 正本、変更時刻、有効開始日 |
| 作業実績 | 製造責任者 | operator / app | ERP・MES team | 仮登録、確定、取消の権限 |
| 設備信号 | OT owner | controls engineer | app vendor、保全 | read-only / write、sampling、quality |
| API・message | IT owner | integration SI | 各system vendor | schema、version、retry、monitoring |
| offline queue | 現場owner | app vendor | IT、security | 保持件数、暗号化、再送、手動照合 |
| master不一致 | 業務owner | designated support | ERP/app vendor | 停止条件、暫定処理、解消期限 |
| release・rollback | IT owner | DevOps / vendor | 現場、OT、security | 承認、maintenance window、evidence |
特に危険なのが書き込み所有権です。アプリとERPの両方が同じ注文状態を自由に変更すると、遅延や再送で競合します。例えば「完了」はアプリが現場イベントを仮登録し、ERPだけが会計・在庫反映後に確定状態を返す、というように権限を分けます。OT側へ指令を書く場合は、通常の業務アプリから直接PLCへ書かず、設備のrisk assessmentと制御設計に従ったengineered interfaceを別に設けます。
基幹システム連携を支えるデータ契約
データ契約はAPI仕様書より広い概念です。JSONのfield名だけでなく、業務上の意味、状態、品質、失敗、変更手順を合意します。最低限、次を含めます。
| 契約項目 | RFPに書く質問 | 受入証拠 |
|---|---|---|
| 識別子 | order、operation、lot、serial、employee、deviceを何で一意にするか | 重複・再発行・桁変更を含むtest data |
| 単位 | 個、箱、kg、m、秒をどこで変換するか | 変換式、丸め、上下限の結果 |
| 時刻 | event timeとreceipt time、ICT/UTC、device clockをどう扱うか | time zone・clock drift test |
| 状態遷移 | planned→released→started→paused→completed等で誰が遷移可能か | 許可・禁止遷移のscenario |
| 冪等性 | 同じmessageを再送しても二重計上しない鍵は何か | duplicate delivery test |
| retry | 即時、指数backoff、dead-letter、手動再送の条件 | network/API failure log |
| 照合 | ERPとappの差分を誰が何時に解消するか | reconciliation reportと承認 |
| master ownership | 品目・工程・設備・理由codeの正本はどこか | 変更・削除・有効日test |
| version | schema変更を何日前に通知し、互換性をどう保つか | old/new version regression |
例えば、operatorが完了ボタンを押した直後に回線が切れた場合を考えます。端末はlocal event ID、device ID、operator、event time、payload versionを保持し、画面では「送信済み」と誤表示せず「端末保存・同期待ち」と示します。再接続時に同じevent IDで送信し、serverは一度だけ処理します。ERPがbusiness ruleでrejectした場合、単にqueueを消さず、現場が修正すべき項目と再送可否を返します。
時刻も軽視できません。設備イベントはUTCで保存し、画面はICTで表示するのか、ERPのposting dateをどの時点で決めるのか、夜勤が日付をまたぐときのproduction dateをどう定義するかを決めます。端末時刻がずれてもserver receipt timeで監査できるようにし、補正した事実をログへ残します。
ERP連携と生産管理アプリの正常系・異常系
ERP 連携 生産管理の要件は、「APIでつなぐ」では足りません。発注者はend-to-end scenarioを、開始条件、操作、期待状態、証拠、復旧まで一行ずつ書きます。
正常系の例は、ERPがreleased orderを公開し、appが対象工程だけを受け取り、作業者が開始、数量登録、完了し、ERPが在庫・注文状態を更新する流れです。各段階で画面、API log、database record、ERP documentが同じcorrelation IDまたは追跡可能なkeyで結ばれる必要があります。
異常系では、次を必須にします。
- master未同期の注文を受信した
- 同じ完了eventが二回到着した
- APIはtimeoutしたがserver側では処理済みだった
- 端末がoffline中に別端末で同じ作業が完了した
- 数量の単位または小数桁がERPと異なった
- ERP maintenance中にqueue上限へ達した
- app update直後に旧version端末が接続した
- device交換後に未送信eventが残っていた
- integration certificateが期限切れになった
- schema変更で未知のstatus codeが返った
障害時に「管理者へ連絡する」だけでは受入条件になりません。誰へ、何分以内に、どの画面・ログ・runbookを使って連絡し、現場は紙へ戻るのか、read-onlyで続けるのか、対象工程を止めるのかを定めます。復旧後は紙・local queue・ERPの三者をどう照合し、誰が確定するかまで含めます。
オフラインと同期をチェックボックスにしない
「工場Wi-Fiが不安定なのでオフライン対応」という一文では、ベンダーごとの解釈が揃いません。TOMAS TECHは次の状態を明示することを推奨します。
- ONLINE：server確認済みのmasterとtransactionを表示する
- DEGRADED：serverへ届かないが、許可された作業を端末queueへ保存する
- SYNCING：回復後に順序、冪等key、versionを確認して再送する
- CONFLICT：server側変更とlocal eventが両立せず、人の判断を要求する
- RECONCILED：差分を解消し、誰が何を採用したか証跡を残す
RFPでは「offlineで使える機能」と「使えない機能」を分けます。例えば、既にdownload済みの作業指示の閲覧と実績仮登録は許可する一方、新規注文のrelease、master変更、在庫引当はserver確認がなければ禁止する設計が考えられます。何を許可するかは業務riskで決め、製品の既定値へ任せません。
競合解決もlast-write-winsに決め打ちしません。数量は加算可能でも、状態のcompletedをstartedへ戻すことは許せない場合があります。品質holdは後勝ちで解除されるべきではありません。fieldまたはevent typeごとに、自動merge、server優先、local優先、supervisor判断を定めます。
現場端末では、shared-device login、badge reader、barcode scanner、camera、printer、scale、glove操作、言語切替、battery低下、OS update、端末交換を試験します。端末交換時に個人credentialをコピーせず、未同期queueの有無を確認し、安全にwipe・re-enrollできる手順も必要です。
RFPに含める要求と提出物
RFPは「要件一覧」と「提案依頼」の両方です。ベンダーが答えを作れるよう、現在の業務、既存system、対象拠点、制約、期待する証拠を開示し、不明点を質問として残します。
| RFP章 | 必須内容 | ベンダー提出物 |
|---|---|---|
| 目的・scope | 対象workflow、判断、対象外、pilot gate | 理解した課題と仮説、追加質問 |
| 現状 | process、system、device、network、言語・shift | discovery計画、site survey項目 |
| 境界 | system of record、read/write、error owner | 境界図、RACI、interface一覧 |
| データ契約 | ID、単位、時刻、状態、retry、reconcile | schema、mapping、version方針 |
| 現場挙動 | offline、競合、duplicate、peripheral | state model、negative test案 |
| 非機能 | 性能、可用性、security、backup、audit | 測定方法、前提、evidence sample |
| localization | 日本語・タイ語等、日付、単位、label | 翻訳責任、用語集、review手順 |
| delivery | environment、release、rollback、support | project plan、owner、escalation |
| acceptance | E2E、failure/recovery、load、handover | FAT/SAT計画、traceability matrix |
| exit | source、build、deployment、data export | handover一覧、第三者移管条件 |
Thailand BOIのInvestment Promotion Guide 2025では、digital activity 8.1.1にsoftware、digital platform、digital contentの開発が含まれます。またIndustry 4.0のefficiency-enhancement measureは、automation/network technology、data analytics/smart operation、production・enterprise processへのdigital technology導入を含み、条件の下でsoftware、program、IT、cloud、data centerへの投資・支出が対象になり得ます。これは案件ごとの適格性を保証するものではありません。申請を検討する企業はBOIやNSTDAへ対象scope、時期、証拠を事前確認してください。補助制度を前提に契約やROIを確定しないことが重要です。
製造業向けシステムインテグレーターの評価表
デモの見栄えだけでなく、discovery、OT統合、現地支援、試験証拠、移管可能性を採点します。以下はTOMAS TECH推奨の評価例であり、普遍的な業界基準ではありません。重みはproject riskに合わせて変更してください。
| 評価軸 | 例示重み | 確認する証拠 | 注意信号 |
|---|---|---|---|
| discovery品質 | 20 | 現場観察、問い、境界仮説、対象外 | 要件を聞く前に製品demoだけ行う |
| 製造・OT統合 | 20 | ISA-95の理解、PLC/SCADA/APIの責任分界 | 「何でも直接接続できる」と断言 |
| data・offline設計 | 15 | state、idempotency、retry、reconcile | 通信断を再読込だけで説明 |
| acceptance evidence | 20 | traceability、negative test、log sample | testを画面確認で終える |
| security・operation | 10 | SDLC、脆弱性対応、backup/restore | securityを本番直前まで扱わない |
| Thailand site support | 10 | 言語、訪問、shift、escalation、部品 | 営業窓口しか現地にいない |
| transferability | 5 | source/build/deploy、文書、training | vendor環境でしかbuildできない |
合計点だけで決めず、重大な足切り条件を設けます。例えば、ERPへの二重登録を防ぐ設計を説明できない、OTへのwrite boundaryが不明、backupからrestoreした実績を提示できない、source handover条件を拒む、といった項目は平均点で相殺しません。
提案比較では、各社へ同じscenarioを渡します。「夜勤中にWi-Fiが20分切れ、二台のshared tabletで同じorderへ実績入力し、一台を交換した。その間ERPはmaintenanceで、復旧後に一件だけ確定する」といった問いです。architectureとoperationを同時に説明できる会社は、単なるUI制作会社と見分けやすくなります。
Securityを調達条件と受入条件へ入れる
NIST SP 800-218 SSDF 1.1は、secure development practiceを選択したSDLCへ統合することを示し、調達者と供給者の共通語彙として利用できます。ここで「NIST準拠」と表示するのではなく、どのpracticeを契約・開発・証拠へ採用するかを確認する参照枠として使います。
OWASP ASVS 5.0.0は2025年5月30日に公開され、metric、development guidance、調達時のtechnical security verification requirementの基礎として使えます。個別requirementを引用する場合はversionを併記し、存在しないIDを作らないことが重要です。Thai government agencyであるETDAのWeb Application Security Standardも、web appのsecure developmentとtesting、common threat、incident handling、backup、checklistを扱っています。タイのRFPと受入計画へsecurity・test requirementを含める根拠になります。
実務では少なくとも、identityとrole、shared device session、secret管理、通信・保存時暗号化、dependencyと脆弱性対応、audit log、backup/restore、incident escalation、退職・委託終了時のaccess removalを要求します。production dataを開発者のlocal PCへコピーしないこと、test dataの作り方、logにpersonal dataやcredentialを残さないことも確認します。
security testは一度のscanで終わりません。設計review、code/dependency check、environment設定確認、権限test、negative API test、backup/restore演習、重大issue修正後のretestをdelivery gateへ結びます。未解決issueはseverity、business impact、暫定策、owner、期限、受容者を明記します。
ISO/IEC 25010で非機能を受入可能にする
ISO/IEC 25010:2023はsoftware・ICT product quality modelを九つのcharacteristicで定義し、requirement、test objective、quality criteria、acceptance criteria、product-quality measureへライフサイクルを通じて利用できます。規格名を書くこと自体が品質保証ではありません。projectの利用状況に合わせ、測れるscenarioへ翻訳します。
例えばperformance efficiencyなら、代表load、device、network条件とともに、画面応答、同期throughput、queue回復時間を測ります。reliabilityなら、network断、API timeout、process restart、storage不足からの回復を確認します。interaction capabilityなら、タイ語・英語・日本語のlabel、手袋操作、誤操作防止、error messageから復旧できるかを現場利用者が評価します。
maintainabilityは「きれいなコード」という感想ではなく、新しいreason code追加、API field変更、端末設定変更を別teamが手順書に沿って実行できるかで確認できます。portabilityは新端末・test environmentへの再展開、securityはrole・audit・脆弱性・data protectionの証拠へ落とします。
受入試験は業務・障害・性能・引継ぎを一つにする
| 試験区分 | Scenario | 合格証拠 | 不合格時の扱い |
|---|---|---|---|
| E2E正常系 | ERP order→作業→実績→ERP確定 | correlation ID付き画面・API・ERP記録 | 差分の原因と再試験 |
| duplicate | 同じeventを複数回送る | business transactionは一件 | idempotency設計を修正 |
| offline | queue保存、再起動、復旧・再送 | 欠損・二重なし、状態が明示 | scope縮小または是正 |
| conflict | 二端末・server側変更が競合 | ruleどおり自動/手動解決、audit | ruleとUIを修正 |
| load | 代表端末・event・master量 | 合意percentileとresource log | bottleneck是正・再測定 |
| security | role、API negative、secret、session | test resultと修正証拠 | 重大項目はrelease block |
| backup/restore | database・file・configを復元 | RTO/RPOは契約値、整合確認 | runbook・backupを是正 |
| localization | Thai/EN/JA、date、unit、font | 現場review記録 | 用語・layoutを修正 |
| audit | 作成・変更・承認・再送を追跡 | actor/time/before-after/correlation | logging設計を修正 |
| handover | clean環境でbuild・deploy・rollback | 第三者が文書だけで再現 | 最終支払gateを保留 |
受入証拠はscreenshotだけにしません。test case ID、requirement ID、input data、version、environment、実行者、時刻、期待結果、actual result、log・record、defect linkを結びます。ベンダーが実行し、customerが重要scenarioへ立ち会い、現場ownerが業務結果を承認します。
FATに相当する事前試験では固定versionとtest packで機能・interface・negative testを再現します。SATでは本番に近いnetwork、device、scanner、user role、shift、ERP接続でend-to-endを確認します。PoC成功の動画をSATの代わりにはできません。
90日パイロットを継続判断のゲートにする
以下は一つの優先workflowを検証するためのTOMAS TECH推奨project exampleであり、工場全体を90日で完成させる保証や業界平均ではありません。
| 期間 | 主な作業 | Gateで求める証拠 | 判断 |
|---|---|---|---|
| Day 0–30 | 現場観察、boundary map、data contract、risk・security、test設計 | owner承認済みscope、interface、baseline、test pack | buildへ進む/再定義/中止 |
| Day 31–60 | 最小機能、integration sandbox、offline・negative test、用語review | traceability、defect一覧、FAT相当結果、support案 | pilotへ進む/是正 |
| Day 61–90 | 対象line・shiftでcontrolled pilot、SAT、training、handover rehearsal | KPI/判断の証拠、recovery、現場feedback、引継ぎ結果 | scale/限定継続/停止 |
Day 0–30では、画面を大量に作らず、現在の例外と責任を観察します。どの紙が公式で、誰が番号を付け、ERPと食い違ったとき誰が決めるかを明らかにします。情報security、OT safety、個人data、support timeもこの段階で境界へ入れます。
Day 31–60ではhappy pathだけでなく、duplicate、timeout、offline、old master、device lossを早期に試します。UIの色より、stateが利用者へ正しく伝わり、supportがlogから原因を追えることを優先します。Thai・English・Japaneseの用語は、直訳ではなく現場の呼称を用語集で承認します。
Day 61–90では対象line・shiftを限定し、代表的なoperator、supervisor、IT/OT、ERP team、vendor supportが実運用に近い形で参加します。critical defectが閉じ、未解決riskにownerと期限があり、backup/restore、rollback、source/build/deploymentの引継ぎが再現できた場合にのみscaleを判断します。
費用と契約を「変数」で比較する
ブリーフの根拠には市場価格や平均ROIがないため、本稿では金額・回収率を作りません。見積は次の変数へ分解し、各社のscope差を揃えます。
総計画費 = discovery + UX/業務設計 + app build/configuration + ERP/MES/OT integration + device/network + data migration + security/testing + training/change + support/operation + handover/exit
さらに、利用者数、拠点・line数、端末種別、interface本数、transaction量、offline保持、言語、support時間、規制・security要求、既存data品質をassumption sheetへ書きます。安い見積がdiscovery、negative test、source handover、夜勤supportを外していないか比較できます。
契約はmilestone支払とevidence gateを結びます。境界図・data contract承認、FAT合格、SAT合格、handover再現をそれぞれ条件にし、単なる「開発完了報告」で全額確定しない構成が考えられます。変更要求はscope、費用、日程だけでなく、data contract、test、training、runbookへ与える影響を記録します。
知的財産とexit条件では、customer固有source、汎用library、third-party component、configuration、credential、domain、cloud accountの所有を分けます。ソースを受け取るだけでなく、repository、branch、tag、build instruction、dependency lock、environment variable一覧、database migration、infrastructure設定、release・rollback手順、license一覧を要求します。
運用開始後に見るべき指標
公開後は、login数だけで成功を判断しません。対象とした一つの判断が速く・正確・追跡可能になったかを確認します。例えば、shift中に未完了orderを特定できるまでの時間、ERPとappの未照合件数、offline queueの滞留時間、manual correctionの理由、supportへの問い合わせ分類を追います。数値の目標はsite baselineとriskに合わせて契約前に決めます。
技術運用ではAPI error、retry、dead-letter、sync lag、device health、certificate expiry、backup成功だけでなくrestore test結果を確認します。変更後に特定lineや端末だけerrorが増えていないか、master変更が遅れていないかを見ます。
業務変更、ERP upgrade、新設備、network構成変更、OS update、言語追加、vendor team変更は再評価のtriggerです。同じgolden scenarioをrelease前後に実行し、critical regressionがあれば展開を止めます。設定変更もactor、理由、承認、before-afterをauditへ残します。
FAQ：製造業のアプリ開発を発注する前の質問
業務アプリ開発では最初に何を依頼すべきですか？
画面設計より先に、対象workflow一つ、改善したい判断一つ、system boundary、data owner、failure scenario、acceptance evidenceを依頼してください。discoveryの成果物としてboundary map、RACI、data contract、test outlineを受け取ると、後工程の見積差を比較しやすくなります。
システムインテグレーターを製造業向けに選ぶ基準は何ですか？
製品demoだけでなく、現場観察の質、ERP/MES/OTのread-write境界、idempotencyとreconciliation、offline試験、Thai-site support、source/build/deployment移管を証拠で評価します。同じfailure scenarioを複数社へ出し、architectureとoperationを一緒に説明できるか確認してください。
基幹システム連携でAPI仕様書以外に必要なものは？
ID、単位、時刻・time zone、status transition、master ownership、retry、duplicate防止、reconciliation、schema versionを含むdata contractが必要です。APIが200を返すことと、ERP上で正しいbusiness transactionが一件だけ確定することは別です。
ERP連携の生産管理アプリはオフライン対応できますか？
可能性はplatformとarchitecture次第ですが、「可能」の一語では発注できません。offlineで許す機能、local保持、暗号化、queue上限、同期順、conflict rule、old event、device replacement、監査証拠をscenarioとして指定してください。ブラウザ・mobile・connectorの制約は候補製品ごとに実機確認します。
ローコードとスクラッチ開発はどちらがよいですか？
一律の答えはありません。標準workflow、更新方針、license、connector、offline、OT integration、transferabilityを同じboundaryとtestで比較します。最初に技術を決めるのではなく、重大scenarioを満たす最小の選択肢を評価します。
製造業アプリの受入基準はどう書きますか？
「使いやすい」「高速」ではなく、代表device・user・network・data量のscenario、期待結果、percentile等の測定方法、evidence、failure/recovery、security、backup/restore、localization、handoverを記述します。ISO/IEC 25010:2023は品質観点を漏れなく整理する参照枠になります。
BOIの対象になるアプリケーション開発ですか？
BOI guideにはsoftware developmentやIndustry 4.0関連のdigital investmentに関する枠組みがありますが、個別projectの適格性はscope、申請主体、時期、条件に依存します。本稿だけで対象と判断せず、支出前にBOI/NSTDAへ確認し、必要証拠を準備してください。
ソースコードを受け取れば引継ぎは完了ですか？
完了ではありません。clean environmentで第三者がbuild、deploy、configuration、database migration、monitoring、backup/restore、rollbackを文書だけで再現できることが必要です。repository history、dependency、license、account ownership、known issue、support runbookも移管します。
まとめ：アプリではなく「境界と証拠」を発注する
製造業のアプリケーション開発は、画面数やframework名で比較すると、本番の境界障害を見落とします。一つの高摩擦workflowと一つの判断から始め、ERP・MES・OT・appのsystem of recordとread/write ownershipを境界図で固定してください。ID、単位、時刻、状態、idempotency、retry、reconciliationをdata contractにし、offline、conflict、device replacementを現場scenarioとして受入れます。
そして、vendorはdemoの印象ではなく、discovery品質、manufacturing/OT integration、Thailand-site support、evidence-based testing、transferabilityで評価します。正常系だけでなく障害・復旧、security、backup/restore、audit、localization、source/build/deployment handoverを同じacceptance planへ結び、90日パイロットをscale判断のgateとして使うことが、止まりにくく引き継げる業務アプリへの近道です。
TOMAS TECHでは、対象業務の切り出し、boundary mapとdata contract、RFP、ERP/MES/OT連携、offline設計、FAT/SAT、Thailand siteでの引継ぎまで、製品選定前の段階から整理できます。要件がまだ画面一覧になっていない段階でも、お問い合わせからご相談ください。
参考資料
- Thailand BOI Investment Promotion Guide 2025 — 適格性は案件ごとにBOI/NSTDAへ確認
- ISA-95 official overview
- OPC UA specification, OPC Foundation
- ISO/IEC 25010:2023
- NIST SP 800-218 SSDF 1.1
- OWASP ASVS 5.0.0
- ETDA Web Application Security Standard.aspx)
- Microsoft Power Apps offline guidance
- Microsoft Power Apps mobile limitations
