業務システム開発の見積書を3社から取って並べたのに、金額が2倍以上ばらついていて比べようがない。タイの日系工場から受ける相談で、これはほぼ毎回起きます。原因は各社の腕の差ではありません。見積の金額を決めているのは「何を作るか」ではなく「何と繋ぐか」だからです。
結論を先に書きます。工場で使う業務システムの費用は、画面や帳票を作る費用が中心ではありません。金額の最大の塊も、プロジェクトが失敗するときの原因も、既存の基幹システム（ERP）・生産管理システム・設備との連携インターフェースに乗ります。後半のモデル試算では、この連携部分が投資額の40.0〜64.7%（繋ぐ先が1系統のケースから3系統のケースまで）を占める計算になりました。当社が過去に公開したハンディターミナル導入の費用分解でも、連携開発費は初期投資の約55.8%、端末本体は約26.3%でした。「本体より繋ぎのほうが高い」というのは、比喩ではなく実測です。
そしてもう1つ、2026年8月時点で無視できない事情があります。SAP ERP 6.0（ECC 6.0）の拡張パッケージ EHP 6/7/8 のメインストリーム保守が、2027年12月31日で終了することです。これは一見「日本本社の話」ですが、本社のERPが変われば、タイ工場の現場システムが繋いでいる相手が変わります。海外拠点にとって、これは外から降ってくる連携要件の変更です。
この記事では、費用を5つの層に分解する方法、第3層＝連携インターフェースがなぜ最大費目になるのかの構造的な理由、バーツ建てのモデル試算2本と感度分析、発注前に紙で決めるべき5項目、タイ固有の税制と人材の論点、そして「連携仕様を凍結するまでの90日」ロードマップを、計算の根拠を全部見せながら並べます。読み終わったときに、見積書のどこを質問すればいいかが分かる状態になることがゴールです。
業務システム開発の相談が「作る話」から始まると失敗する理由
最初に、多くのプロジェクトが最初の30分で道を間違える構造を説明します。
依頼側は「画面」で語り、費用は「配線」で決まる
工場から届く要望は、たいてい画面の言葉で書かれています。「タブレットで生産実績を入力したい」「不良の写真を撮って報告書にしたい」「在庫の棚卸をスマートフォンでやりたい」。これは正しい要望です。業務の当事者は業務の言葉で語るのが当然だからです。
一方、見積を作る側が金額を積む単位は画面ではありません。そのデータがどこから来て、どこへ出ていくかです。「タブレットで生産実績を入力する」という1行の要望は、実装側では次のように分解されます。
- 品目マスタと工程マスタをどこから取ってくるのか（ERP？ 生産管理システム？ Excel？）
- 入力された実績をどこへ返すのか（返さないのか、日次でERPへ送るのか、リアルタイムか）
- 実績と設備の稼働信号を突き合わせるのか（PLCから取るのか、人が入力するのか）
- 送った結果がエラーになったとき、誰がどこで気づくのか
この4つの答えによって、同じ「タブレット入力画面」でも工数は数倍変わります。画面の数は同じでも、繋ぐ相手の数と方向が違うからです。相見積の金額が2倍以上ばらつく理由の大半は、この繋ぎ先の前提が各社でバラバラのまま見積られていることにあります。腕の差ではなく、読んでいる仕様が違うのです。
日本側の投資動向も「作る」より「繋ぎ直す」に寄っている
これは肌感覚だけの話ではありません。経済産業省監修のJUAS『企業IT動向調査2026』（2025年9〜10月実施、2026年2月2日に速報値発表）では、IT予算が増加する企業の割合は52.6%でした。注目すべきは増加理由の順位です。
| IT予算が増加する理由 | 割合 |
|---|---|
| 既存システム・基盤の刷新・更新・増強 | 66.3% |
| 円安・人件費高騰・ベンダー価格値上げ | 46.6% |
| クラウドサービスの増加 | 45.0% |
1位は新規開発ではなく既存の刷新・更新です。つまり企業がお金を使っている主戦場は、ゼロから何かを作ることではなく、すでに動いているものを繋ぎ直すことに移っています。2位にベンダー価格の値上げが入っていることも重要です。単価が上がっている局面では、工数見積の精度が以前より効きます。同じ2人月の読み違いでも、単価が上がった分だけ金額の傷が大きくなるからです。
なおIT予算DI値は25年度計画が43.3ポイント（5年連続の上昇）に対し、26年度予測は39.9ポイントとやや落ち着く見込みです。AI関連の投資・利用料増加は25年度計画36.3%から26年度予測43.7%へ7.4ポイント上昇しています。ただし本記事のテーマである工場の業務システムに関して言えば、「IT投資で解決したい課題」の最多は全体で34.6%の「業務プロセスの効率化・スピードアップ」であり、AIより手前の話が依然として中心です。
「作る話」から始めると、決められないまま金額だけ膨らむ
作る話から始めると、要望リストがどんどん伸びます。誰も反対しないからです。そして繋ぎ先の議論は「後で詰めましょう」と先送りされます。ところが後で詰めた結果、繋ぎ先が2つ増えたとします。それだけで金額は跳ね上がり、稟議は差し戻され、プロジェクトは半年止まります。
だから順番を逆にします。最初に繋ぎ先を確定させ、そのあとで画面の話をする。これが本記事を通しての主張です。発注先の会社をどう選ぶかという別の論点はタイのシステム開発会社の選び方で扱っているので、本記事では会社選びには踏み込みません。ここで扱うのは、どの会社に頼むにせよ共通して効いてくる「費用の内訳と契約の決め方」です。
業務システム開発の費用は5つの層に分かれる
見積書を比較可能にする最短の方法は、金額を同じ5つの層に割り直すことです。ベンダーが出してくる項目名は各社バラバラですが、この5層に落とせば横並びで比べられます。
5層の定義
- 第1層 要件定義・業務設計｜現行業務の棚卸、画面・帳票の仕様確定、承認フローの整理
- 第2層 アプリケーション開発｜画面、入力、帳票、業務ロジックの実装とテスト
- 第3層 連携インターフェース開発｜ERP／生産管理システム／設備／既存データベースとの接続
- 第4層 マスタ整備・データ移行｜品目・取引先・工程マスタのクリーニングと移行（社内工数の金額換算を必ず含める）
- 第5層 保守・改修・問い合わせ対応｜稼働後の年間運用費
そして、この記事では次の定義を最後まで固定します。
投資額 ＝ 第1層 ＋ 第2層 ＋ 第3層 ＋ 第4層
第5層は投資額に含めず、年間運用費として別枠で扱う
これは会計上の資産計上ルールの話ではなく、ROIの分母を1つに固定するための取り決めです。後半のROI式では、分母がこの投資額、分子が「年間便益 − 第5層の年間運用費」になります。第5層を分母にも分子にも入れてしまうと二重計上になるので、ここで線を引いておきます。
第4層の「社内工数の金額換算」を書かない見積書は危険
5層のうち、見積書からもっとも脱落しやすいのが第4層です。理由は単純で、マスタ整備の作業をやるのはベンダーではなく自社の社員だからです。ベンダーの見積書に載らないので、稟議書にも載りません。しかし実際には、生産管理や購買の担当者が数か月にわたって品目マスタの重複を潰し、単位や小数桁を揃え、廃番品を落とす作業をします。この時間はタダではありません。
業界の解説記事では、見積書に含まれないが実際に発生する費目として、カスタマイズ追加費、データ移行費、教育研修費、外部システム連携費、プロジェクト長期化による機会損失が挙げられ、これらの合計が見積額の50〜100%に達することもあるという指摘があります。これは一次統計ではないため数値そのものを鵜呑みにはできませんが、「見積書の外に同じ規模の費用が隠れうる」という警告としては実務感覚と一致します。同じ文脈で、マスタデータのクリーニングと移行に想定外の工数がかかり、データ移行の失敗がプロジェクト遅延の最大の原因になるケースが珍しくないとも指摘されています。
対策は難しくありません。第4層に必ず社内工数の時間数と金額換算を書くことです。後半のモデル試算では、この換算に人時単価50バーツ/時（タイの県別最低賃金の上限側である日額400バーツ ÷ 8時間）を使い、金額として明示します。
第5層は5年で見ると総額の4割を超える
もう1つ落としやすいのが第5層です。稼働後の保守・改修・問い合わせ対応は、金額が小さく見えるうえに稟議のタイミングが違うため、投資判断のときに視野から外れがちです。
後半の試算では第5層を投資額の年15%で置いています。この前提だと、5年間の総支出に占める第5層の割合は次のようになります。
シナリオAの5年総額 ＝ 3,600,000 ＋ 540,000 × 5 ＝ 6,300,000バーツ
うち第5層 ＝ 2,700,000バーツ ＝ 総額の 42.9%
投資額が3分の1のシナリオBでも、年率が同じ15%なので比率は同じ42.9%になります。5年で見れば、支払う金額のおよそ4割が稼働後の費用です。見積比較のときに「保守は年額いくらか」を聞かないのは、金額の4割を見ずに決めているのと同じことになります。
第3層＝連携インターフェースがなぜ最大費目になるのか
ここが本記事の核心です。なぜ「繋ぐ」だけの費用が、画面を作る費用より高くなるのか。感覚論ではなく、標準規格の構造から説明します。
ISA-95（IEC 62264）が定義しているのは、まさに「境界」
製造業のITアーキテクチャには国際標準があります。ISA-95、国際規格番号ではIEC 62264です。この標準は製造ITをLevel 0〜4に階層化し、生産・品質・保全・在庫の4つの運用ドメインを定義します。
- Level 4 ＝ ERP（事業計画、財務、購買、販売）
- Level 3 ＝ MES／製造実行（製造指示、順序付け、実績収集、トレーサビリティ）
- Level 2以下 ＝ 監視制御、PLC、センサ・アクチュエータ
そしてISA-95が主に規定しているのは、Level 3の中身でもLevel 4の中身でもなく、Level 3とLevel 4の境界＝インターフェースです。国際標準がわざわざ境界だけを標準化したという事実そのものが、ここが難所であることを裏づけています。
実装を支える技術も2つ整理されています。B2MMLはERPとMESの間でやり取りするデータをXMLで表現するモデルで、OPC UAはOT側とIT側のリアルタイム通信を担います。設備側から実績を取りに行く部分はPLCプログラム開発の外注の領域と重なるため、社内でも担当部署が分かれがちです。担当が分かれる場所は、そのまま見積の漏れが起きる場所でもあります。
「繋ぐ」の中身は、通信ではなく合意である
技術的な接続だけなら、それほど高くはなりません。高くなるのは、接続の前後にある合意形成と例外処理です。1系統を繋ぐと、最低でも次を決めて実装する必要があります。
| 決めること | 決まっていないと起きること |
|---|---|
| 送受信する項目とその型・桁・単位 | 数量の小数桁が合わず、丸め差が毎日積み上がる |
| 送信のタイミングと粒度（都度／時間／日次） | 締めの時刻が両システムでずれ、月末に必ず不一致が出る |
| マスタの正（どちらが正しいか） | 品目が両方で作られ、同じ物に2つのコードが付く |
| エラー時の再送とリカバリー | 送信失敗が誰にも気づかれず、数日後に発覚する |
| 権限と認証（誰のIDで繋ぐか） | 担当者の退職でジョブが止まる |
この表の5行はすべて「業務の決めごと」であり、プログラムの難しさではありません。だからこそ、決めるのに時間がかかり、決まらないまま実装が始まると作り直しになります。連携が最大費目になる理由は、技術の難易度ではなく、合意の総量です。
製造業で連携が複雑化しやすい理由として、マスタ変更や拠点追加のたびにIT部門へ依頼が集中し、変更対応のたびに工数が膨らむという指摘もあります。1回作って終わりではなく、変更のたびに費用が発生する構造になっている、ということです。
だからミドルウェアを挟む｜ERPが変わっても更新は連携部分だけで済む
ここまでを読むと、連携は避けられない負債のように見えます。しかしISA-95の考え方には、この負債を小さく閉じ込める設計指針が含まれています。
ミドルウェアやAPIを挟んだ設計にしておくと、ERP側が変わってもMES側は大きな影響を受けず、更新が必要なのは連携インターフェースだけで済む、という点です。
これは費用の話に直結します。現場のアプリケーション（第2層）が直接ERPのテーブルを見に行く作りにしてしまうと、ERPが更改されたときに第2層まで作り直しになります。逆に第3層に変換の役割を集約しておけば、ERPが変わったときに手を入れるのは第3層だけです。後述するモデル試算のシナリオAで言えば、第2層1,050,000バーツにまで作り直しが波及するか、第3層のうちERP側の780,000バーツで閉じられるかの差になります。
つまり第3層は、単に「高い費目」ではなく、将来の変更費用を1か所に集めるための投資です。ここを値切って直結にすると、目先の見積は安くなり、次の更改で高くつきます。
自社実測でも、本体より繋ぎのほうが高かった
当社が公開しているハンディターミナル導入の費用分解では、初期投資に占める連携開発費が約55.8%、端末本体が約26.3%でした。買い物の主役に見える端末より、繋ぎのほうが2倍以上高かったということです。同じ傾向は工程管理システムの費用と選び方でも在庫管理システムの比較でも繰り返し出てきます。後半のモデル試算では、連携インターフェースが投資額に占める比率は40.0〜64.7%になりました。この55.8%という実測値は、その範囲のちょうど内側に入ります。
2027年12月末のSAP ECC 6.0保守終了が、海外拠点に外から降ってくる
ここで時限性のある話を1つ挟みます。SAPの記事にするつもりはありません。あくまで「本社ERPの更改が、海外拠点の現場システムにとって何を意味するか」に限定して扱います。
事実関係の整理
SAP Communityの公式ブログ「Maintenance Timelines for SAP ERP 6.0」ほか複数のソースで一致している内容は次のとおりです。
| 対象 | 保守の期限 |
|---|---|
| SAP ERP 6.0 拡張パッケージ EHP 6 / 7 / 8 のメインストリーム保守 | 2027年12月31日で終了 |
| 追加費用（保守ベースに対し +2%）を払った場合の延長保守 | 2030年12月31日まで |
| EHP 6 未満の旧拡張パッケージ | 2025年12月31日で終了済み |
延長保守の費用について補足すると、ERP Private Cloud契約ではこの+2%はサブスクリプションに含まれます。2030年以降は有償のCustomer-Specific Maintenanceという選択肢が残りますが、機能追加や法改正・税制改正への追従は限定的です。タイのように付加価値税や電子インボイスの制度変更が起こりうる国では、この「法改正への追従が限定的」という一点が実務上かなり重い意味を持ちます。
海外拠点にとって、これは「連携要件の変更」である
日本本社の情シスにとって、これはERP更改プロジェクトです。しかしタイ工場の製造部門にとっては違う姿で見えます。自分たちが作った、あるいはこれから作ろうとしている現場システムの接続先が、期日付きで変わるということです。
具体的に何が変わるかは更改の中身によりますが、少なくとも次は影響を受けます。
- 接続方式（IDoc／RFC／ファイル連携から、REST APIやイベント連携へ）
- 項目とコード体系（品目コードの桁数、原価要素、プラント／保管場所の持ち方）
- 締めのタイミングと転記のルール
- 認証と権限の方式
このうち「項目とコード体系」が変わる場合、影響は第3層だけでは止まりません。マスタを持ち直すことになるので、第4層のマスタ整備が再発します。ここが、本記事で第4層に社内工数の金額換算を書けと繰り返している理由でもあります。
いま業務システム開発を計画している人にとっての実務上の意味
「本社のERPがどうなるか分からないから、現場システムは待つ」という判断は、一見安全に見えて実は高くつきます。2026年8月1日から2027年12月31日までは517日、約17か月です。待っている間に期日は近づき、選べる選択肢は減ります。
現実的な打ち手は3つあります。
- 繋ぎ先を1系統に絞って先に作る｜片方向で始め、双方向は本社の方針が出てから足す
- 第3層をミドルウェア経由に固定する｜アプリからERPを直接叩かせない設計を契約書に書く
- 本社に対して、期日付きで方針を確認する質問状を出す｜「いつ、どの接続方式に変わるのか」を文書で残す
3番目は技術の話ではなく段取りの話ですが、効果はいちばん大きいです。海外拠点が本社ERPの方針を文書で持っていないまま連携仕様を凍結すると、その仕様は本社の一言でひっくり返ります。
スクラッチ・パッケージ・パッケージ＋アドオンの作り分け
ここからは作り方の選択です。製品名を挙げた比較はしません。個別の製品比較は生産管理システムの比較や生産スケジューラーの比較に譲り、ここでは判断軸だけを整理します。
選択肢は次の3つです。
| 選択肢 | 向いている条件 | 第3層への影響 |
|---|---|---|
| フルスクラッチ | 業務プロセスそのものが競争力の源泉／既存の商習慣を変えられない／該当するパッケージが存在しない | 連携仕様を自由に設計できる反面、全部を自分で決めねばならず、第3層の合意コストが最大になる |
| パッケージ標準機能のみ | 業務を製品側に合わせられる／対象業務が一般的（在庫、購買、日常の実績入力） | 標準の連携アダプタがあれば第3層は最小。ただし「標準で繋がる」の中身は必ず項目単位で確認が必要 |
| パッケージ＋アドオン | 8割は標準で足り、2割に自社固有がある | 第3層に加えてアドオン部分の連携も増える。バージョンアップのたびに再検証が発生する |
判断軸は「作れるか」ではなく「変えられるか」
3つを分ける実務上の質問は1つです。その業務のやり方を、製品に合わせて変えられますか。
変えられるなら標準機能が最も安く、最も速く、最も壊れにくい選択になります。変えられないなら、変えられない理由が「競争力」なのか「慣れ」なのかを切り分ける必要があります。競争力ならスクラッチかアドオンで守る価値があります。慣れであれば、業務を変えるほうが安いことが多いです。
アドオンを選ぶときに必ず確認すること
パッケージ＋アドオンは中庸に見えるので選ばれやすい選択肢ですが、費用の時間分布が他の2つと違います。バージョンアップのたびにアドオンと連携の再検証が発生するからです。これは第5層（年間運用費）に効きます。
したがって、アドオンを検討する場合は次の3点を見積段階で確認してください。
- 年何回のバージョンアップがあり、そのたびに再検証費用が発生するのか
- 再検証費用は第5層の年額に含まれるのか、都度見積なのか
- アドオンが標準機能に取り込まれた場合、アドオンは撤去できるのか
なお「パッケージソフトの導入支援だけを頼めるか」という質問はよく受けます。答えは頼めます。ただしその場合でも第3層と第4層は消えません。誰が作るかが変わるだけで、決めることの量は同じです。
モデル試算｜シナリオAとシナリオBを同じベースラインで比べる
ここから数字に入ります。通貨はバーツ建てのみとし、円やドルへの換算はしません。すべて仮定値を積み上げたモデル試算であり、実在の案件の金額ではないことを先に明記します。
モデル工場の前提
| 項目 | 前提 |
|---|---|
| 立地・形態 | タイ国内の日系製造業（1拠点） |
| 従業員 | 約300名 |
| 生産ライン | 3ライン × 2交替 |
| 管理品目数 | 約1,200点 |
| 既存の基幹システム | 日本本社のSAP ERP 6.0（ECC 6.0） |
| 現場の実態 | 生産実績・出入庫を紙で記入し、Excelに転記し、さらにERPへ再入力している |
| 人時単価 | 50バーツ/時（タイの県別最低賃金の上限側 日額400バーツ ÷ 8時間） |
| 年間稼働日 | 250日 |
人時単価50バーツ/時は、タイの最低賃金が2026年7月時点でも全国一律化されておらず県別337〜400バーツ/日である事実に基づく、当社記事共通の前提値です。実際の間接部門の人件費はこれより高くなりますが、保守側に倒した数値として全シナリオで統一します。
シナリオは2本だけに絞る
- シナリオA：フルスクラッチ一括｜生産実績・在庫・出荷の全機能を一度に作り、ERPと双方向連携する
- シナリオB：範囲を絞った先行導入｜生産実績入力の1業務だけを、パッケージ標準機能を使い、ERPへ片方向で送る
費用5層｜シナリオA（フルスクラッチ一括）
| 層 | 内容 | 金額（バーツ） | 投資額比 |
|---|---|---|---|
| 第1層 | 要件定義・業務設計 | 480,000 | 13.3% |
| 第2層 | アプリケーション開発（画面・帳票・ロジック） | 1,050,000 | 29.2% |
| 第3層 | 連携インターフェース開発（3系統） | 1,620,000 | 45.0% |
| 第4層 | マスタ整備・データ移行 | 450,000 | 12.5% |
| 投資額合計（第1〜4層） | 3,600,000 | 100.0% | |
| 第5層 | 保守・改修・問い合わせ対応（年間運用費・別枠） | 540,000／年 | 投資額の15.0% |
第3層1,620,000バーツの内訳は次のとおりです。
| 連携先 | 方向 | 金額（バーツ） |
|---|---|---|
| ERP（SAP ECC 6.0） | 双方向 | 780,000 |
| 既存の生産管理システム | 片方向 | 420,000 |
| 設備・既存データベース（OPC UA経由の実績収集） | 片方向 | 420,000 |
| 合計 | 1,620,000 |
第4層450,000バーツの内訳も明示します。
外部委託分（移行ツール、変換、検証）370,000バーツ ＋ 社内工数換算 80,000バーツ ＝ 450,000バーツ
社内工数 ＝ 1,600時間 × 50バーツ/時 ＝ 80,000バーツ
（1,600時間 ＝ 生産管理・購買の担当者2名 × 5か月 × 20日 × 8時間）
第2層1,050,000バーツに対して第3層は1,620,000バーツ、約1.54倍です。フルスクラッチは作る量が多いのでアプリ層が大きくなりますが、それでも連携が最大費目になります。
費用5層｜シナリオB（範囲を絞った先行導入）
| 層 | 内容 | 金額（バーツ） | 投資額比 |
|---|---|---|---|
| 第1層 | 要件定義・業務設計（1業務に限定） | 180,000 | 15.0% |
| 第2層 | パッケージ標準機能の設定と画面調整 | 330,000 | 27.5% |
| 第3層 | 連携インターフェース開発（ERPへ片方向1系統） | 480,000 | 40.0% |
| 第4層 | マスタ整備・データ移行（品目マスタのみ） | 210,000 | 17.5% |
| 投資額合計（第1〜4層） | 1,200,000 | 100.0% | |
| 第5層 | 保守・改修・問い合わせ対応（年間運用費・別枠） | 180,000／年 | 投資額の15.0% |
第4層210,000バーツの内訳は、外部委託分170,000バーツ ＋ 社内工数換算40,000バーツ（＝800時間 × 50バーツ/時、担当者1名 × 5か月 × 20日 × 8時間）です。
シナリオAの投資額3,600,000バーツはシナリオBの1,200,000バーツのちょうど3.0倍です。作る機能の数はそれ以上に違うのに、金額差が3.0倍にとどまるのは、Bでも第3層と第4層がゼロにはならないからです。層ごとに下がり方を見ると差は明らかで、第2層はAの31.4%（330,000 ÷ 1,050,000）まで下がるのに、第4層は46.7%（210,000 ÷ 450,000）までしか下がりません。範囲を1業務に絞っても、費用は同じ比率では下がらない。これが「小さく始める」を検討するときの最初の現実です。
効果の前提｜ベースラインは1本に固定する
ここが試算でいちばん事故が起きるところです。効果を大きく見せたいという意識がなくても、「作業時間の削減」と「残業代の削減」を並べて書いた瞬間に、同じ1時間を2回数えてしまう。この種の二重計上は、稟議が通ったあとに実績と合わなくなって発覚します。そうならないよう、比較する反実仮想の世界線を1本に固定します。
ベースライン ＝ 「現在の手作業・二重入力をこのまま続けた場合」
効果はすべて、このベースラインとの差分としてのみ計上します。
まず現在の入力・転記・照合にかかっている年間工数を積み上げます。
| 作業 | 算定根拠 | 現在（時間/年） | 導入後（時間/年） | 削減（時間/年） |
|---|---|---|---|---|
| 現場での紙日報の記入と集計 | 6ポスト（3ライン×2交替）× 1.5h/日 × 250日 | 2,250 | 900 | 1,350 |
| 事務所でのExcel転記・集計 | 3名 × 3.0h/日 × 250日 | 2,250 | 450 | 1,800 |
| ERPへの再入力 | 2名 × 2.0h/日 × 250日 | 1,000 | 100 | 900 |
| 現品票・出庫伝票の起票と照合 | 2名 × 2.0h/日 × 250日 | 1,000 | 400 | 600 |
| 月次の突合・差異調査と本社報告用の集計 | 5名 × 8h × 12か月 | 480 | 144 | 336 |
| 年2回の実地棚卸の準備と差異つぶし | 10名 × 10h × 2回 | 200 | 120 | 80 |
| 合計 | 7,180 | 2,114 | 5,066 |
削減率は 5,066 ÷ 7,180 ＝ 70.6% です。紙とExcelを前提にした工場で、この規模の削減が起きること自体は珍しくありません。日報の電子化そのものの進め方は電子帳票システムの導入ガイドで別途扱っています。
年間便益｜シナリオA
| 便益項目 | 算定根拠 | 年間金額（バーツ） |
|---|---|---|
| ① 入力・転記・照合の工数削減 | 5,066時間 × 50バーツ/時 | 253,300 |
| ② 欠品リカバリーの緊急便（特別輸送）の削減 | 年18回 → 年6回、削減12回 × 80,000バーツ/回 | 960,000 |
| ③ 安全在庫の圧縮による在庫保有コストの削減 | 部材在庫 9,000,000 × 15%圧縮 ＝ 1,350,000、× 保有コスト率20% | 270,000 |
| 合計 | 1,483,300 |
二重計上のチェック（ここは必ず確認してください）。①は人の時間、②は物流費、③は在庫保有コストで、勘定科目も対象物も異なります。②は完成品側の出荷リカバリー、③は部材側の持ち方であり、同じ金額を2回数えてはいません。なお納期遅延による違約金や、在庫差異そのものの評価損は計上していません。②の緊急便がそれらを未然に防いだ結果なので、足すと同じ効果の二重計上になるためです。
年18回・1回80,000バーツ、在庫9,000,000バーツ、圧縮率15%、保有コスト率20%はいずれもこのモデルのための仮定値です。自社で試算する場合は、この4つの数字を自社の実績に差し替えてください。金額の大半（便益の64.7%）は②が占めているので、②の実績値が試算の精度をほぼ決めます。
年間純便益（A） ＝ 1,483,300 − 540,000（第5層の年間運用費） ＝ 943,300バーツ/年
単年ROI（A） ＝ 943,300 ÷ 3,600,000 ＝ 26.2%
回収年数（A） ＝ 3,600,000 ÷ 943,300 ＝ 約3.8年
年間便益｜シナリオB
シナリオBは生産実績入力の1業務だけなので、効果の範囲も狭くなります。対象となるのは工数表の上3行（現場の紙日報、事務所のExcel転記、ERPへの再入力）＝合計5,500時間分です。
| 便益項目 | 算定根拠 | 年間金額（バーツ） |
|---|---|---|
| ① 入力・転記・照合の工数削減 | 対象5,500時間のうち3,175時間を削減（削減率57.7%）× 50バーツ/時 | 158,750 |
| ② 欠品リカバリーの緊急便の削減 | 年18回 → 年12回、削減6回 × 80,000バーツ/回 | 480,000 |
| ③ 安全在庫の圧縮 | 在庫系は今回の範囲外のため計上しない | 0 |
| 合計 | 638,750 |
①の3,175時間の出し方を明示します。シナリオAでは対象3行を満額削減して4,050時間（1,350 ＋ 1,800 ＋ 900）取れますが、Bは片方向・実績入力のみで、Excelでの集計と月次の照合が現場に残ります。したがって満額の78.4%にあたる3,175時間を削減としました。内訳は、現場の紙日報 675時間（Aの半分）、事務所のExcel転記 1,600時間、ERPへの再入力 900時間（ここは片方向連携で満額なくなります）で、合計3,175時間です。
②について1点補足します。②は在庫そのものの持ち方（③）の効果ではなく、実績がその日のうちにERPへ入ることで欠品の検知が早まる効果に限定しています。検知の前倒しで防げるのは全体の3分の1と保守的に置き、残りは在庫の持ち方に依存するもの（＝今回の範囲外）として計上していません。
年間純便益（B） ＝ 638,750 − 180,000（第5層の年間運用費） ＝ 458,750バーツ/年
単年ROI（B） ＝ 458,750 ÷ 1,200,000 ＝ 38.2%
回収年数（B） ＝ 1,200,000 ÷ 458,750 ＝ 約2.6年
2本を並べて読む
| 指標 | シナリオA（フルスクラッチ一括） | シナリオB（範囲を絞った先行導入） |
|---|---|---|
| 投資額（第1〜4層） | 3,600,000バーツ | 1,200,000バーツ |
| うち第3層 | 1,620,000バーツ（45.0%） | 480,000バーツ（40.0%） |
| 第5層（年間運用費） | 540,000バーツ/年 | 180,000バーツ/年 |
| 年間便益 | 1,483,300バーツ | 638,750バーツ |
| 年間純便益 | 943,300バーツ | 458,750バーツ |
| 単年ROI | 26.2% | 38.2% |
| 回収年数 | 約3.8年 | 約2.6年 |
| 5年累計の純額（純便益×5 − 投資額、割引前の単純累計） | ＋1,116,500バーツ | ＋1,093,750バーツ |
読み取れることは3つあります。
- 回収年数はBのほうが1.2年短い（3.8年 → 2.6年）。範囲を絞ったほうが、投じた金額に対する戻りは速い。
- 5年累計の純額はほぼ同じ（差は22,750バーツ、Aの約2.0%）。効果の絶対量はAが大きいが、運用費と投資額の重さで相殺される。
- それでもBは投資額が3分の1。同じ5年後の到達点なら、動かす金額が少ないほうが稟議は通りやすく、失敗したときの傷も浅い。
これは「Aが間違い」という意味ではありません。5年より先まで見ればAが逆転する可能性は十分あります。ただし6年目以降を根拠に稟議を書くなら、6年目以降も同じ前提が成り立つことを説明する責任が発生します。2026年のタイの事業環境でそれを説明しきるのは、後述するとおり簡単ではありません。
感度分析①｜人時単価 50 → 100バーツ/時
タイの人件費は上がっています。人時単価が2倍になったらどうなるかを見ます。ここで重要なのは、人時単価は便益側（工数削減額）だけでなく費用側（第4層の社内工数換算）にも効くという点です。片方だけ動かすと結果が甘くなります。
| 項目 | シナリオA（50→100） | シナリオB（50→100） |
|---|---|---|
| 第4層の社内工数換算 | 80,000 → 160,000バーツ | 40,000 → 80,000バーツ |
| 第4層 合計 | 450,000 → 530,000バーツ | 210,000 → 250,000バーツ |
| 投資額 | 3,600,000 → 3,680,000バーツ | 1,200,000 → 1,240,000バーツ |
| 便益① 工数削減 | 253,300 → 506,600バーツ | 158,750 → 317,500バーツ |
| 年間便益 合計 | 1,483,300 → 1,736,600バーツ | 638,750 → 797,500バーツ |
| 年間純便益 | 943,300 → 1,196,600バーツ | 458,750 → 617,500バーツ |
| 回収年数 | 3.8年 → 約3.1年 | 2.6年 → 約2.0年 |
第5層の年間運用費（A:540,000／B:180,000）は外部への委託契約額なので、社内の人時単価には連動させていません。この感度分析で増えるのは第4層の社内工数換算だけであり、外部への委託契約額は変わらないためです（後述の感度分析②では、増えるのが外部への開発費なので第5層も投資額の15%で再計算しています）。なお仮にここで第5層も投資額の15%で再計算しても、A＝552,000バーツで回収3.1年、B＝186,000バーツで回収2.0年となり、結論は変わりません。
結論として、人時単価が上がると投資額もわずかに増えますが（Aで＋80,000バーツ、＋2.2%）、便益の増加のほうがはるかに大きく、回収年数は短くなります。人件費が上がる局面では、システム化の投資判断は有利になるという当たり前の結論ですが、第4層の費用側も同時に動かしたうえでそう言える、という点が重要です。
感度分析②｜連携先システム数 1 → 3
こちらが本記事の主張の核心を数字で示す部分です。シナリオBを基準に、アプリケーションの範囲は一切変えずに、繋ぐ先だけを1系統から3系統へ増やします。追加するのは既存の生産管理システム（420,000バーツ）と設備・既存データベース（420,000バーツ）です。
便益側は638,750バーツ/年で固定します。理由は保守的な前提を置くためです。繋ぐ先が増えれば理屈の上では効果も増えますが、現場の実感として「繋いだ数だけ効果が比例して増える」ことはまずありません。効果を生むのは現場の業務が変わることであり、システム間の接続本数ではないからです。
| 連携先 | 第3層 | 投資額 | 第3層の比率 | 第5層（年） | 年間純便益 | 回収年数 |
|---|---|---|---|---|---|---|
| 1系統（ERPへ片方向） | 480,000 | 1,200,000 | 40.0% | 180,000 | 458,750 | 約2.6年 |
| 2系統（＋生産管理システム） | 900,000 | 1,620,000 | 55.6% | 243,000 | 395,750 | 約4.1年 |
| 3系統（＋設備・既存DB） | 1,320,000 | 2,040,000 | 64.7% | 306,000 | 332,750 | 約6.1年 |
繋ぐ先が1系統から3系統になるだけで、回収年数は2.6年から6.1年へ、約2.3倍に伸びます。アプリケーションの機能は1つも増えていません。画面も帳票もそのままです。増えたのは繋ぎ先の数だけです。
冒頭に書いた「業務システム開発の見積は何を作るかではなく何と繋ぐかで決まる」という主張は、この表のことを指しています。稟議書で説明すべきなのは機能一覧ではなく、この行の数です。
発注前に紙で決める5項目
ここまでの議論をふまえて、契約書または覚書に紙で書いておくべき項目を5つに絞ります。口頭やメールの合意では足りません。担当者が変わった瞬間に消えるからです。
① 要件の凍結日と、凍結後の変更の扱い
いつまでに要件を凍結するか、日付を書きます。そのうえで、凍結後に変更が出た場合の扱いを先に決めます。「変更は追加見積」だけでは足りません。変更1件あたりの見積提出期限（例：5営業日以内）と、判断の決裁者まで書いてください。決めていないと、変更のたびにプロジェクト全体が止まります。
② 連携仕様書の粒度
これがもっとも重要です。「ERPと連携する」という一文は仕様書ではありません。最低でも次の粒度が必要です。
| 記載すべき単位 | 記載内容の例 |
|---|---|
| インターフェース単位 | IF-001 生産実績送信、IF-002 品目マスタ受信 |
| 項目単位 | 項目名、型、桁数、小数桁、単位、必須／任意、初期値 |
| タイミング | 都度／5分間隔／日次21:00／月次締め後 |
| 方向と正 | 送信のみ／受信のみ／双方向、マスタの正はどちらか |
| 異常系 | 送信失敗時の再送回数、再送間隔、通知先、手動リカバリー手順 |
| 件数の想定 | 1日あたりの最大件数、ピーク時の同時実行数 |
見積を比較するとき、この6行が埋まっている見積と埋まっていない見積を金額だけで並べても意味がありません。同じ粒度の連携仕様書を全社に配ってから相見積を取るのが、比較可能な見積を得る唯一の方法です。
③ テストデータを誰が、いつまでに用意するか
テストデータは自社にしか作れません。ベンダーは自社の品目コードも取引先コードも知らないからです。ここが決まっていないと、開発が終わっているのにテストが始まらないという停滞が起きます。
決めること：本番相当のデータを何件、いつまでに、誰が用意するか。個人情報や取引条件を含む場合のマスキング方針。異常系（数量ゼロ、マイナス在庫、廃番品、単位違い）のテストケースを誰が作るか。
④ マスタの持ち主
「品目マスタの正はERPか、新システムか」を1行で書きます。両方が正だと必ず壊れます。項目ごとに正が違う場合（例：品目コードはERPが正、標準工数は新システムが正）は、項目単位で表にします。
あわせて、マスタのメンテナンス担当部署と、新規登録のリードタイムも決めてください。稼働後に「新品目を登録したのに現場のタブレットに出てこない」という問い合わせが出るのは、ほぼこの取り決めがないことが原因です。
⑤ ソースコードの納品と改修権
契約書に次の3点を書きます。
- ソースコードを納品するか（納品する／しない、納品時期、格納場所）
- 著作権と利用範囲（自社の他拠点で使えるか、改変できるか）
- 第三者による改修を認めるか（開発元以外のベンダーが手を入れることを妨げないか）
3番目が特に重要です。タイでは後述のとおりIT人材の流動性が高く、担当エンジニアが数年で入れ替わります。「開発元以外は触れない」という契約は、開発元の担当者がいなくなった瞬間に自社の資産を凍結させます。
タイで業務システムを開発するときだけ効いてくる論点
日本と同じ感覚で進めると外す点が4つあります。3つは制度と人材の話、最後の1つは投資環境の話です。
BOI 8.1.1 は「開発する側」の恩典であって、発注する工場の恩典ではない
タイのBOI（投資委員会）には、活動区分8.1.1（Software / Digital Platform / Digital Content、カテゴリA2）があります。内容は次のとおりです。
- 法人税免除最大8年
- 免除の上限額は毎年の実支出に基づいて決まる
- 上限の算定対象は、申請後に新規雇用したタイ人IT人材の給与の100%と研修費の200%
- 条件として、ソフトウェア開発工程（コーディング・テスト・デプロイ）をタイ国内で、タイ拠点のITチームが実施すること
- IT／Tech事業は外資100%出資が可能（通常の外資規制の例外）
- プロジェクト用輸入機器、R&D用原材料、輸出品生産用原材料の関税免除あり
ここで誤解が起きやすいので明記します。これはソフトウェアを開発する事業者（ベンダー）が受ける恩典であり、システムを発注する工場が受けられるものではありません。自社がBOIの製造業として恩典を受けていても、業務システムを発注したことでこの8.1.1の恩典が増えることはありません。
では発注側にとって意味がないかというと、そうではありません。発注先の選定と、開発地の判断に効きます。開発工程をタイ国内で行うことが恩典の条件になっているということは、恩典を受けているベンダーはタイ国内に開発チームを持っているということです。これは「担当者が現地にいて、現場に来られるか」という実務上の関心と一致します。
depa 200%損金算入は、BOI企業には使えないという二重の壁
タイにはもう1つ、デジタル投資を後押しする制度があります。depa（デジタル経済振興機構）に関連する200%損金算入（王令802号）です。ただし条件が厳しく、実際に使える日系工場は限られます。
| 条件 | 内容 |
|---|---|
| 損金算入の上限 | 1会計期間あたり30万バーツ |
| 対象ベンダー | depa Thailand Digital Catalog 登録ベンダーに限定 |
| SME要件 | 払込資本金500万バーツ以下かつ年商3,000万バーツ以下 |
| 除外 | BOI／対象産業／EECで法人税免除を受けている事業には使えない |
| 対象支出期間 | 2027年12月31日まで |
タイの日系製造業の多くはBOIの恩典下にあります。したがって、BOI恩典を受けている時点でdepaの200%損金算入は使えないというのが第一の壁です。さらに使える場合でも、上限は年30万バーツ。本記事のシナリオBの投資額1,200,000バーツに対して、上限まで使っても損金算入できるのは300,000バーツ分の枠にとどまります。しかも30万バーツは損金算入の枠であって、減る税額そのものではありません。実際に軽くなるのは、この枠に法人税率を掛けた分だけです。この二重の壁は、稟議書に「税制優遇で実質負担が下がる」と書く前に必ず確認してください。
余談ですが、depaの対象支出期間の期限（2027年12月31日）は、前述のSAP ECC 6.0のメインストリーム保守終了日とまったく同じ日付です。偶然ですが、2027年末という同じ壁が制度側と技術側の両方に立っている、という見え方はしておいて損はありません。
タイのIT人材の流動性と単価
タイではデジタル人材が約7万人不足していると言われています。賃金の面では、2026年の昇給トレンドは年4.7%程度である一方、転職時には1回で15〜30%上がるという状況です。
この2つの数字は次元が違うので、年数に換算して比べます。年4.7%の昇給を積み上げて15%に到達するには約3.0年、30%に到達するには約5.7年かかります。つまり転職1回は、社内昇給の3年分から6年分に相当します。エンジニアが転職を選ぶ経済合理性は極めて高い、ということです。
これが業務システム開発にどう効くかというと、次の3点です。
- ベンダー側の担当者は数年で入れ替わる前提で契約を組む｜前述の「第三者による改修を認めるか」がここに直結します
- 属人的なドキュメントの不在が致命傷になる｜連携仕様書の粒度を発注時に指定しておく理由がここにもあります
- 自社の現地IT担当も同じ市場にいる｜社内に閉じた知識は、担当者の退職とともに失われます
だからこそ、第3層の仕様は「動くコード」ではなく「読める文書」として残す必要があります。
2026年のタイ経済｜大型一括投資の稟議は通りにくい
投資判断の外部環境も触れておきます。2026年のタイのGDP成長率は、政府系の見通しが3.0〜3.5%であるのに対し、民間シンクタンクや金融機関は1.8〜2.0%程度に下方修正しています。自動車生産は2026年5月に前年同月比マイナス11.4%と2か月連続で減少し、輸出向け生産はマイナス25.8%と報じられています。一方で日系企業の設備投資DIは2026年上期にプラス1へ回復しており、投資意欲そのものが消えたわけではありません。
これらの数値は業界メディアの集計に基づく二次情報であり、幅をもって読むべきものです。ただし実務上の含意ははっきりしています。投資意欲はゼロではないが、大型一括投資の稟議は通りにくい。シナリオAの3,600,000バーツを一度に通すより、シナリオBの1,200,000バーツで始めて実績を出すほうが、2026年の環境では現実的だということです。
連携仕様を凍結するまでの90日ロードマップ
最後に、明日から動かせる手順を出します。この90日は発注先を決めるまでの期間ではなく、連携仕様を凍結するまでの期間です。発注先の決定はこの後に来ます。
まず期日を確認します。2026年8月1日から、SAP ECC 6.0のメインストリーム保守終了である2027年12月31日までは517日、約17か月です。90日を使って連携仕様を凍結すると、凍結日は2026年10月30日、残りは427日（約14.0か月）になります。90日計画と2027年12月末の期日は矛盾しません。
第1〜30日｜連携先の棚卸
やることは1つ、いま情報がどこからどこへ流れているかを1枚の紙に書くことです。システム構成図ではありません。紙とExcelと口頭連絡を含めた、情報の流れです。
- 現場で発生する記録を全部挙げる（日報、不良票、現品票、出庫伝票、点検表）
- それぞれが誰の手で、どのシステムに、いつ入力されるかを線で結ぶ
- 同じ数字を2回以上入力している箇所に印を付ける
- 印が付いた箇所の年間発生件数と1件あたりの所要時間を測る
最後の実測が90日全体でいちばん重要です。前掲の工数表（7,180時間）に相当するものを、自社の実データで作ります。ここで測った数字が、そのままROIの分子になります。
第31〜60日｜連携仕様の一次案とインターフェース一覧
棚卸で見えた流れを、インターフェース単位に切ります。IF-001、IF-002と番号を振り、前述の6行（インターフェース単位／項目単位／タイミング／方向と正／異常系／件数の想定）を埋めていきます。
この期間に並行してやることが2つあります。
- 日本本社への確認｜ERP更改の方針、時期、接続方式の変更予定を文書で問い合わせる。返事が来るまでに時間がかかるので、この期間の初日に出すこと
- マスタの正の暫定決定｜品目・取引先・工程について、どちらを正とするかを暫定で決める。項目単位で正が分かれる場合は表にする
なお、この段階で決めきれない項目が出るのは正常です。決めきれないこと自体を仕様書に「未決」として書き残し、いつまでに誰が決めるかを付けてください。未決を空欄にしたまま出すと、ベンダーは自分の都合のいい前提で見積ります。
第61〜90日｜仕様の凍結と、同一条件での見積取得
30日と60日の成果物を統合し、連携仕様書として凍結します。そのうえで、全ベンダーに同じ連携仕様書を配って見積を依頼します。ここで初めて金額の比較が意味を持ちます。
見積を受け取ったら、本記事の5層に割り直してください。ベンダーの項目名がどうであれ、第1層から第5層のどこに入るかは判定できます。割り直した結果、第3層の金額が極端に安い見積があれば、それは連携仕様を読み込んでいないか、直結（アプリからERPを直接叩く）で設計している可能性が高いです。前者は後で増えます。後者は次の更改で作り直しになります。
第91日以降｜開発期間と2027年12月末の関係
凍結日（2026年10月30日）から残り427日、約14.0か月です。開発期間との関係は次のようになります。
| 進め方 | 想定開発期間 | 稼働の目安 | 2027年12月末までの余裕 |
|---|---|---|---|
| シナリオA（フルスクラッチ一括） | 9〜12か月 | 2027年7月末〜10月末 | 約2〜5か月 |
| シナリオB（範囲を絞った先行導入） | 4〜6か月 | 2027年2月末〜4月末 | 約8〜10か月 |
シナリオAは14.0か月の枠には収まりますが、余裕は2〜5か月しかありません。本社ERPの更改と時期が重なった場合、この余裕では吸収できない可能性があります。シナリオBなら8〜10か月の余裕があり、本社の方針が固まってから第2弾（双方向連携や連携先の追加）を判断できます。
参考までに、中規模拠点でMESをゼロから導入する場合、海外では12〜24か月・100万〜500万ユーロという相場観が紹介されています。これは欧州の値なのでタイの金額には使えませんが、期間の感覚としては上記の9〜12か月と大きく矛盾しません。
よくある質問
業務システム開発の費用相場はどれくらいですか
「相場」を1つの数字で答えるのは誤解のもとです。同じ機能でも、繋ぐ先の数と方向で金額が数倍変わるからです。本記事のモデル試算では、1業務・片方向1系統で1,200,000バーツ、全機能・3系統連携（うちERPのみ双方向）で3,600,000バーツになりました（いずれも第1〜4層の投資額、仮定値の積み上げ）。相場を知りたい場合は、金額そのものより第3層が投資額の何%かを見てください。本記事の試算では40.0〜64.7%、当社のハンディターミナル導入の実測では約55.8%でした。この比率から大きく外れて第3層が安い見積は、繋ぎ先の前提が違っている可能性を疑ってください。
基幹システム連携はどこまで自社でやるべきですか
作業そのものはベンダーに任せてかまいません。ただし次の3つは自社に残してください。①どの項目を、どのタイミングで、どちらを正としてやり取りするかの決定、②連携仕様書の内容を読んで承認すること、③テストデータの用意と、異常系のテスト結果の確認。この3つは業務の意思決定であり、外注できません。逆に、通信方式の選定、ミドルウェアの構築、エラー再送の実装は専門領域なので任せるほうが確実です。
パッケージソフトの導入支援だけを頼めますか
頼めます。ライセンスは別のルートで購入し、設定・移行・連携・教育だけを支援として発注する形は一般的です。ただし注意点が1つあります。パッケージを選んでも第3層と第4層は消えません。「標準機能で繋がる」と説明された場合は、標準の連携アダプタが自社のERPのバージョンと項目に対応しているかを、項目単位で確認してください。多くの場合、標準アダプタは「繋がる仕組みがある」という意味であって、「設定なしで自社のデータが流れる」という意味ではありません。
タブレットやスマートフォンで使う業務アプリの開発は、別料金になりますか
見積の切り方はベンダーによりますが、費用構造としては本記事の第2層（アプリケーション開発）に入ります。工場でタブレットの業務システムを使う場合、金額に効くのは画面の作りよりも利用環境です。具体的には、無線LANの死角の有無、オフライン時に入力を保持して後から送るか、防塵・防滴や手袋操作への対応、端末の管理方法（紛失時のロック、アプリ更新の配布）です。スマートフォン向けの業務アプリ開発も同様で、iOSとAndroidの両対応が必要かどうかで工数が変わります。これらは要件定義（第1層）の段階で確定させてください。
製造業向けのシステムインテグレーターは、日系とローカルのどちらに委託すべきですか
規模や言語だけで決めないでください。判断すべきは第3層と第4層を誰が回せるかです。具体的には、日本本社のERP担当と直接やり取りできるか、タイの現場担当者とタイ語で仕様を詰められるか、設備側（PLC・OPC UA）まで踏み込めるか、の3点です。この3つを1社で満たすのは日系・ローカルを問わず簡単ではないので、複数社で分担する場合はインターフェースの責任分界点を契約書に明記してください。会社選びの具体的な確認項目はタイのシステム開発会社の選び方で詳しく整理しています。
システム開発を委託すると、ソースコードは自社のものになりますか
自動的にはなりません。契約に書いていなければ、著作権は開発者側に残るのが一般的です。前述の5項目の⑤で挙げたとおり、①ソースコードの納品有無と時期、②著作権と利用範囲（他拠点での利用、改変の可否）、③第三者による改修の可否、の3点を契約書に明記してください。特に③は、タイのIT人材の流動性を考えると実務上の影響がもっとも大きい項目です。
開発期間はどれくらいかかりますか
本記事のモデルでは、連携仕様の凍結までに90日、その後の開発にシナリオBで4〜6か月、シナリオAで9〜12か月を見込んでいます。合計するとBで約7〜9か月、Aで約12〜15か月です。よくある誤解は、開発期間が短縮できないのはプログラミングに時間がかかるからだ、というものです。実際に時間を食うのは連携仕様の合意とマスタ整備であり、この2つは人を増やしても速くなりません。期間を短くしたい場合は、人を増やすのではなく繋ぐ先を減らすことが唯一の確実な手段です。
まとめ
本記事の主張を1行にすると、業務システム開発の見積は「何を作るか」ではなく「何と繋ぐか」で決まる、です。要点を整理します。
- 費用は5層に分解する。投資額は第1〜4層、第5層は年間運用費として別枠にする
- 第4層には社内工数の金額換算を必ず書く。書かない見積は、費用の一部が稟議書の外にある
- 第5層は5年で見ると総支出の42.9%を占める。年額を確認せずに比較しない
- 第3層＝連携インターフェースが最大費目になるのは技術の難易度ではなく合意の総量が大きいから。ISA-95（IEC 62264）が標準化しているのもLevel 3と4の境界そのもの
- ミドルウェアを挟めば、ERP側が変わっても更新は連携部分だけで済む。第3層は将来の変更費用を1か所に集める投資
- モデル試算では、投資額に占める第3層は40.0〜64.7%。当社実測の約55.8%と整合する
- 感度分析では、アプリの機能を1つも増やさずに繋ぐ先を1系統から3系統に増やしただけで、回収年数は2.6年から6.1年へ約2.3倍に伸びた
- SAP ECC 6.0（EHP 6/7/8）のメインストリーム保守終了は2027年12月31日。海外拠点にとっては外から降ってくる連携要件の変更として扱う
- BOI 8.1.1は開発側ベンダーの恩典であり、発注する工場の恩典ではない。depaの200%損金算入はBOI企業には使えない
- 90日でやるのは発注先の決定ではなく連携仕様の凍結。凍結は2026年10月30日、2027年12月末まで残り427日で矛盾しない
もし1つだけ持ち帰るとすれば、最初の30日でやる「連携先の棚卸」です。ここで作った1枚の紙が、そのあとの見積比較、稟議、契約交渉のすべての土台になります。
いま社内で業務システムの企画が動いていて、繋ぎ先の整理から手をつけたいという段階でしたら、お問い合わせフォームからご相談ください。連携先の棚卸だけ、あるいは他社から届いた見積書を本記事の5層に割り直してみるだけ、といったご相談でも構いません。金額の話に入る前の段階でご一緒するほうが、結果的に手戻りが少なくなります。
参考情報
- SAP Community「Maintenance Timelines for SAP ERP 6.0」 https://community.sap.com/t5/enterprise-resource-planning-blog-posts-by-sap/maintenance-timelines-for-sap-erp-6-0/ba-p/13524564
- Natuvion「SAP ERP 6 end of maintenance: is the deadline in 2025, 2027, or 2030?」 https://www.natuvion.com/newsroom/sap-erp-6-end-of-maintenance/
- JUAS『企業IT動向調査2026』 https://juas.or.jp/activities/research/it_trend/
- i Magazine「JUAS、企業IT動向調査2026の速報値を発表」（2026年2月2日） https://www.imagazine.co.jp/juas-report-on-20260202/
- ISA「ISA-95 Standard: Enterprise-Control System Integration」 https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- Siemens「ISA-95 framework and layers」 https://www.siemens.com/en-us/technology/isa-95-framework-layers/
- Symestic「ISA-95: The Standard for MES Architectures and ERP Integration」 https://www.symestic.com/en-us/blog/mes/isa95
- Emerhub「Thailand’s Renewed BOI Incentives for 2026 & 2027」 https://emerhub.com/thailand/thailands-renewed-boi-incentives-for-2026-2027/
- AIM Bangkok「Thailand BOI Incentives for Software, Digital Platforms, and Content Businesses」 https://aimbangkok.com/boi-incentives-software-digital-platforms-content-businesses/
- PwC「Thailand – Corporate – Tax credits and incentives」 https://taxsummaries.pwc.com/thailand/corporate/tax-credits-and-incentives
- 秋霜堂「ERP導入ガイド｜中小企業が失敗しない7ステップ・費用相場・製品比較【2026年版】」 https://syusodo.co.jp/blog/articles/erp-introduction
- Magic Software「製造業のシステム連携はなぜ複雑化しやすいのか」 https://www.magicsoftware.com/ja/magic-blog/majisemi03/
- 暮らすアジア「タイ経済2026年見通し完全ガイド」 https://kyujin.careerlink.asia/blog/thailand-economy-outlook-2026/
