在庫管理システム カスタマイズ判断｜タイ工場のRFPと5年TCO

タイ工場で在庫管理システムを導入するとき、現場から出る要望をすべてカスタマイズ要件へ変換すると、稼働時の操作は現行業務に近づいても、その後の変更に弱い仕組みになりがちです。逆に標準機能へ無理に合わせれば、競争力の源泉、法令・顧客要求への適合、設備や建屋の物理制約を損なう場合があります。大切なのは「標準か個別か」という二択ではありません。差異が生む価値と、その差異を何年も守る生涯コストを同じ表で比較し、設定、API／side-by-side拡張、コア改変の順に選ぶことです。本稿では、在庫管理システム カスタマイズの判断を、タイ工場のRFP、PoC、受入、アップグレード回帰テストまで実務に落とします。

結論：差異の価値より保守生涯コストが大きければ標準へ戻す

最初に結論を示します。現行業務と標準機能の差異が見つかったとき、次の三つのゲートを通過した差異だけをカスタマイズ候補にします。

1. その差異は競争力、法令・顧客契約、または設備・動線などの物理制約に由来するか。
2. 標準化した場合に失う利益、品質、納期、安全、追跡可能性を定量または検証可能な指標で説明できるか。
3. その価値は、開発費だけでなく保守、障害調査、教育、セキュリティ対応、連携変更、アップグレード回帰テストを含む生涯コストを上回るか。

三つのどれかに答えられなければ、まず業務を標準へ戻す案を検討します。カスタマイズを残す場合も、優先順位は「標準設定」「公開APIやイベントを使うside-by-side拡張」「コア改変」です。コア改変は、ほかの方法では制約を満たせず、責任者が例外として承認し、廃止条件と回帰テスト資産を持てる場合に限定します。

この判断は、現場の工夫を否定するものではありません。むしろ、価値のある工夫を「本当に守るべき差異」として明確にし、単なる慣習や過去システムの操作順から切り離すための方法です。

なぜ在庫管理システムの費用は開発見積だけでは決まらないのか

在庫管理システムの費用を比較するとき、RFPではライセンス、導入支援、データ移行、端末、アドオン開発が目立ちます。しかし、個別ロジックは稼働後も「守り続ける対象」です。品目体系の追加、倉庫レイアウト変更、ERPやMESのバージョン更新、バーコード仕様の変更、担当者交代、脆弱性対応のたびに、影響分析とテストが発生します。

MicrosoftのALM解説では、アプリケーションのライフサイクルに要件、アーキテクチャ、開発、テスト、保守、変更管理、支援、継続的インテグレーション、展開、リリース管理、ガバナンスまで含めています。したがって「アドオンを作る費用」はプログラミング工数だけではありません。誰が変更を承認し、どの環境で試し、どのデータで回帰し、失敗したらどう戻すかまでが費用です。

例示試算：5年TCOを同じ式で比較する

以下は市場相場ではなく、自社の数字へ置き換えるための例示試算です。初期開発費を1,800,000 THB、年間保守率を20％、年2回のアップグレードごとに回帰テスト120,000 THBと仮定します。インフレと割引率は考慮しない単純モデルです。

感度も見ます。年間保守率が1ポイント上がると、5年間で90,000 THB増えます。回帰テスト1回の費用が10,000 THB上がると、年2回なら5年間で100,000 THB増えます。連携先が増え、テストケースが倍になるなら、単価だけでなく回帰範囲そのものが膨らみます。

一方、標準へ戻すと1日40分の追加作業が発生するとします。稼働220日、作業単価250 THB／時間なら、40÷60×220×250＝36,666.67、丸めて年36,667 THB、5年で183,333 THBです。これも市場相場ではなく例示入力です。誤出荷、停止、安全、品質、機会損失を含めていないため、実案件では別項目で加えます。それでも、単純な手作業回避だけが便益なら、例示のカスタムTCO 4,800,000 THBを正当化できません。

重要なのは、カスタマイズの便益に「標準導入でも得られる改善」を混ぜないことです。在庫精度向上や紙削減の全額をアドオンの効果にせず、個別差異があるから追加で得られる価値だけを分離します。

標準機能・設定・アドオン開発・コア改変を分ける

在庫管理システム 導入の議論では、ベンダーごとに「カスタマイズ」の意味が違います。画面上の設定変更も、外部サービスの追加も、標準コード修正も同じ言葉で呼ばれると、アップグレードリスクを比較できません。RFPでは最低でも次の四層へ分けます。

「設定だから無料」「APIだから安全」とは限りません。設定が数百項目に増えれば、どれが正なのか分からなくなります。API連携も、タイムアウト、二重送信、順序逆転、認証鍵更新、レート制限への設計がなければ止まります。層を分ける目的は、無条件に上位層を善とすることではなく、責任と生涯コストを見えるようにすることです。

SAPの公式Extension Architecture Guideやclean coreの解説は、拡張方法を分類し、コアと個別機能の結合を抑える判断枠組みの一例です。これはSAP製品だけを選ぶべきだという意味ではありません。どのWMS／ERPでも、「標準更新と独自ロジックの衝突面をどこに置くか」をRFPで問う材料になります。

カスタマイズを許す三条件：競争力・法令等・物理制約

1. 競争力を守る差異

顧客への即日補充、極端に短い段取り、特殊なキッティング、独自の生産同期など、再現可能で利益や受注に結びつく能力は候補です。ただし「当社独自」は証明ではありません。KPI、対象顧客、代替案、価値の発生条件を明確にします。標準プロセスでも同じ納期を達成できるなら、操作手順の違いは競争力ではありません。

2. 法令・顧客契約・監査要求に必要な差異

記録保持、ロット追跡、承認、ラベル、データ越境、顧客指定インターフェースなど、外部義務から逆算する差異です。RFPには根拠文書、対象範囲、証跡、保存期間、変更通知責任を記載します。ここで「業界では普通」と書くだけでは不足です。実際の法令、契約、顧客仕様を案件ごとに確認します。

GS1 General Specificationsは識別キー、データキャリア、アプリケーション識別子を設計する際の公式な参照先です。またEPCISは、異なるアプリケーションが企業内外でvisibility event dataを作成・共有するための標準インターフェースを示し、イベントを何が・いつ・どこで・なぜという業務文脈で扱います。ただし、すべての工場がEPCISを実装すべきという意味ではありません。取引先連携やトレーサビリティの必要性があるとき、独自フォーマットを増やす前に検討する共通語彙です。

3. 建屋・設備・素材の物理制約に必要な差異

電波が届かない冷凍域、手袋での操作、防爆区域、固定されたコンベヤ、計量器の通信仕様、狭い通路、印字できない素材などは、業務手順だけでは解決できません。この差異は現場観察と実機PoCで確認します。会議室で「端末は使えるはず」と判断せず、照度、読取距離、速度、汚れ、温湿度、ネットワーク断を含む試験条件を作ります。

三条件に該当しても、いきなりコア改変へ進みません。標準機能の再設定、マスタ設計、ラベルやスキャナ側の調整、外部アプリ、API連携の順に代替案を比較します。

在庫管理システム バーコード設計は「読めた」だけで受け入れない

バーコード導入では、ハンディ端末で一度読み取れたデモが成功に見えます。しかし、本番品質は、識別体系、データ内容、印字品質、貼付位置、読取距離、照明、速度、例外処理、マスタ同期の組み合わせで決まります。

RFPには、品目・ロット・シリアル・荷姿・ロケーションのどれを識別するか、取引先ラベルを自社キーへどう対応付けるか、同じコードの再読をどう防ぐか、不明コードや破損ラベルをどう扱うかを書きます。GS1を採用する範囲は顧客やサプライチェーン要件に合わせ、キーやApplication Identifierの意味を独自解釈で上書きしないようにします。

PoCでは、正常系だけでなく、二重読取、逆順搬入、部分入荷、数量差、ラベル再発行、オフライン、API遅延、端末交換を試します。受入基準は「読み取りできる」ではなく、例えば「対象ラベル条件下で処理が完結し、二重計上を防ぎ、エラー時に担当者が復旧でき、監査ログで経緯を追える」という業務結果で定義します。

WMS 連携はAPI一覧ではなくデータ契約で評価する

現行のエンタープライズWMSにはREST APIを提供する製品があります。Oracle Warehouse Management 26Bの公式REST APIガイドはその一例です。しかし、APIが存在するだけでは、ERP、MES、設備、輸送システムとの連携が安全に運用できるとは限りません。エンドポイント数を比較するより、業務トランザクションの責任境界を決めます。

最低限、次の事項をデータ契約としてRFP添付にします。

• 品目、単位、ロット、シリアル、ロケーション、在庫状態のsystem of recordはどこか。
• 入荷、移動、消費、完成、出荷、調整のイベントをどちらが起票し、どのIDで冪等化するか。
• 同期か非同期か。タイムアウト、再送、順序逆転、重複、部分失敗をどう扱うか。
• 切断中に現場を継続するか、停止するか。復旧後にどの順で整合させるか。
• マスタ変更とトランザクションの前後関係、時刻、タイムゾーンをどう統一するか。
• 認証・認可、秘密情報の更新、監査ログ、保存期間、アラート責任を誰が持つか。
• API廃止やバージョン更新の通知期間と、互換性テスト環境が提供されるか。

EPCISは、captureとqueryの標準インターフェースを定めつつ、内部データベースや実装方式を規定しません。この分離は設計の参考になります。物理世界のスキャンやセンサー入力を、業務イベントとして正規化し、上位アプリが端末固有の事情へ直接依存しない形にすれば、スキャナや設備の変更範囲を抑えられます。

RFPで「要望一覧」を「判断可能な仕様」へ変える

RFPの弱点は、各部門の希望を一つのExcelへ集め、「対応可／不可」と価格を記入してもらうだけになることです。これでは、標準対応とコア改変が同じ「可」に見えます。要件には少なくとも、業務結果、制約根拠、優先度、受入指標、対応層、所有者、退出条件を持たせます。

NIST SSDF 1.1は、安全なソフトウェア開発の成果指向プラクティスを供給者との共通語彙として使い、調達要件に組み込む際の参照になります。認証制度ではなく、脆弱性ゼロの保証でもありません。RFPでは、ソース・依存関係の管理、変更レビュー、脆弱性対応、リリース証跡、インシデント連絡など、納入後に確認できる成果物へ変換します。

ISO/IEC 25010:2023の製品品質モデルは9特性からなり、品質を指定・測定・評価する参照モデルです。規格本文をコピーするのではなく、性能だけに偏らず、信頼性、セキュリティ、保守性、互換性などの観点を受入項目へ展開する足場として使えます。実際の契約には、自社の重要度と試験条件に応じた測定値を定めます。

PoCは「きれいなデモ」ではなく高リスク仮説を壊す場

PoCの目的を機能紹介にすると、ベンダーが用意した正常なデータと安定したネットワークで成功します。本番で問題になるのは、例外、量、順序、切断、権限、設備差です。PoCでは、投資判断を左右する仮説を先に並べ、失敗条件を合意します。

PoCで優先するシナリオ

1. バーコード：実ラベル、実距離、実速度、汚れ、再発行、誤ラベルで試す。
2. 在庫イベント：部分入荷、分納、ロット分割、戻入、廃棄、棚卸差を通す。
3. WMS 連携：二重送信、順序逆転、応答遅延、再送、片側停止、日跨ぎを再現する。
4. 権限：作業員、班長、倉庫責任者、IT、監査の職務分離を確認する。
5. 負荷：ピーク時間の端末台数、トランザクション量、ラベル印刷を模擬する。
6. 復旧：端末故障、無線断、連携キュー滞留、誤操作後に業務を戻せるか試す。

PoCの終了条件は「主要画面を見た」ではありません。どの仮説が確認され、どの差異が標準設定で吸収でき、どれがAPI拡張を必要とし、どのリスクが未解決かを記録することです。未解決項目には、追加検証、契約条件、運用回避、対象外のいずれかを割り当てます。

受入テストは業務・品質・運用の三層で作る

受入テストを要件一覧のチェックにすると、ボタンが動くことは確認できても、工場が継続できるかは分かりません。次の三層で設計します。

業務受入

入荷から出荷までのend-to-endを、正常、例外、取消、訂正、締め後のケースで試します。在庫残高だけでなく、ERP仕訳、MES消費、ラベル、監査証跡まで照合します。基準データは現場が理解できる小さなセットと、ピーク量を模擬する大量セットを分けます。

品質受入

応答時間、同時利用、可用性、復旧時間、データ整合、アクセス制御、監査ログ、変更容易性を測ります。ISO/IEC 25010を観点漏れのチェックに使い、契約では具体値に落とします。「高速」「十分」「セキュア」といった形容詞だけでは受け入れません。

運用受入

監視、アラート、バックアップ、再処理、日次照合、権限申請、マスタ変更、問い合わせ、障害エスカレーション、リリース承認が実行できるかを確認します。運用手順書が存在するだけでなく、担当者が手順を使って復旧できるか演習します。

アップグレード回帰テストを契約前に設計する

カスタマイズの生涯コストは、最初のアップグレードで顕在化します。そこで、稼働後に考えるのではなく、RFPで次を質問します。

• リリース頻度、通知期間、強制更新日、延期条件は何か。
• sandboxや検証環境はいつ使え、本番相当データをどう匿名化するか。
• 標準機能、設定、API、コア改変の互換性責任はそれぞれ誰にあるか。
• APIのversioning、deprecation、変更履歴はどう提供されるか。
• 自動テストに使えるテストAPI、固定データ、ログ、モックはあるか。
• 障害時のrollback、feature flag、代替運用は用意できるか。
• 回帰テストの失敗を誰が修正し、費用と期限をどう扱うか。

最小の回帰パック

最小パックには、重要業務のend-to-end、全カスタム分岐、主要API契約、権限、帳票・ラベル、在庫残高照合を含めます。テストごとに入力、期待結果、証跡、データ初期化方法、所有者を持たせます。手作業でも開始できますが、頻度と変化量が多い箇所から自動化します。

「ベンダーがテストするので自社は不要」は危険です。ベンダーは標準製品を試験しても、自社の設備、マスタ、ネットワーク、連携順序、例外運用まで知りません。反対にすべてを自動化すればよいわけでもありません。物理ラベルの貼付、ハンディ操作、現場復旧は実地確認が残ります。

タイ工場での導入体制と意思決定

在庫管理システム 導入はITだけの案件ではありません。最低限、工場責任者、倉庫、製造管理、品質、IT／アプリケーション所有者、財務・購買、ベンダーの責任を分けます。肩書きは会社ごとに異なるため、法定役職を想定せず、決定権と成果物で定義します。

複数言語の現場では、画面翻訳だけでなく、用語辞書、品目・ロケーション命名、エラー時の連絡、教育教材をそろえます。英語を契約言語にする場合でも、作業者がタイ語で例外を理解し、班長がどの証跡をITへ渡すかまで確認します。

BOIのSmart and Sustainable Industry向け制度では、効率向上投資の最低額を土地・運転資金を除き1,000,000 THBとし、既存Group B事業には一定条件で3年間の法人所得税免除、通常は対象投資の50％上限、国内自動化産業に関連する機械等が所定比率以上の場合は100％上限とする説明があります。またBOI/OSOSは2026年上期に同制度で132件、約17.2 billion THBの申請があったと発表しました。これは産業高度化への動きを示す情報ですが、特定の在庫管理システムや本稿の例示費用が対象になるという意味ではありません。活動、投資項目、申請時期、認定条件はBOIや専門家に案件別に確認してください。

実装ロードマップ：12の成果物で曖昧さを減らす

プロジェクトを「要件定義、開発、テスト」の大項目だけで管理せず、判断が残る成果物へ分解します。

1. 価値仮説表：業務上の検討背景、対象KPI、標準化時の損失、差異価値を記録。
2. 現場制約台帳：設備、ラベル、無線、動線、契約、監査の根拠を添付。
3. 標準適合表：各要件を標準、設定、API拡張、コア改変へ分類。
4. 5年TCO：開発、保守、監視、回帰、教育、変更、退出をシナリオ比較。
5. データ所有権表：品目・在庫・イベントの正本と更新責任を定義。
6. API契約：ID、冪等、順序、再送、エラー、認証、versioningを記載。
7. バーコード仕様：キー、データ内容、印字、貼付、読取、例外を確定。
8. PoC計画：高リスク仮説、実機条件、失敗条件、判定者を定義。
9. 受入パック：業務、品質、運用の試験と証跡を準備。
10. 回帰パック：重要フロー、カスタム分岐、API、権限、帳票を反復可能にする。
11. リリース運用：dev/test/prodの分離、承認、rollback、feature flagを決める。
12. 廃止計画：標準機能が追いついた場合のアドオン撤去手順とデータ移行を定義。

この12点がそろえば、ベンダー比較は機能数競争から、長期運用に耐える提案かどうかの比較へ変わります。

よくある失敗と対策

現行帳票をそのまま画面要件にする

紙の欄をすべて入力欄へ変えると、過去の制約までデジタル化します。必要な意思決定、証跡、後工程のデータを先に定義し、標準画面で不足する結果だけを要件にします。

ベンダーの「対応可能」を同じ意味で比較する

標準、設定、追加開発、コア改変を別欄にし、初期費用だけでなく年次保守、更新時テスト、API制限、退出費を記入させます。

現場要望を却下して標準化する

標準化は上から押し付けると隠れExcelや手書き台帳を生みます。差異を競争力・外部義務・物理制約の三条件で一緒に評価し、採用しない要望には理由と代替運用を返します。

PoCで正常系だけを見る

例外、断線、重複、順序逆転、復旧を試し、未解決リスクが投資判断へ見える形にします。

稼働後の変更管理を契約しない

変更単価、SLA、ソースや設定の引き渡し、テスト環境、API廃止通知、終了支援を契約前に確認します。

FAQ

在庫管理システム カスタマイズはどこまで必要ですか？

競争力、法令・顧客契約、物理制約に由来し、標準化で失う価値が生涯コストを上回る差異までです。操作の好みや過去システムの踏襲は、まず標準業務、設定、教育で吸収できないか確認します。

在庫管理システム 費用は何年で比較すべきですか？

最低でも想定利用期間と主要アップグレードを含む期間で比較します。本稿は5年の例示ですが、設備更新、契約期間、会計方針に合わせて変えます。初期費用、保守、監視、回帰テスト、教育、連携変更、撤去・移行を含めます。

在庫管理システム バーコードはGS1準拠が必須ですか？

一律に必須とは限りません。取引先、業界、顧客契約、追跡範囲に応じて判断します。GS1キーやApplication Identifierを使う場合は公式仕様を参照し、独自解釈を避けます。

WMS 連携はAPIがあれば追加開発不要ですか？

いいえ。APIがあっても、データ所有権、ID、冪等性、順序、再送、認証、監視、versioningの設計と試験が必要です。公開APIで標準連携できる範囲と、外部変換・業務ロジックが必要な範囲を分けます。

アドオン開発とコア改変の違いは何ですか？

アドオン／side-by-side拡張は、公開された拡張点やAPIを使い、独自ロジックをコアの外へ置く考え方です。コア改変は標準処理内部のコードやDBへ直接手を入れるため、更新衝突と支援制約が大きくなりやすいです。製品ごとの定義をRFPで確認してください。

BOI優遇を在庫管理システム 導入の前提にできますか？

前提にはしない方が安全です。公式制度には投資下限や実施期限、対象活動、税免除上限などの条件があります。ソフトウェア、端末、設備、工事のどれが対象かを案件ごとにBOIへ確認し、優遇なしでも成立する投資判断を用意します。

まとめ

在庫管理システム カスタマイズの良し悪しは、要望数や開発可否では決まりません。差異を守る価値と、その差異を保守し続ける生涯コストを比較し、競争力、法令・顧客契約、物理制約に必要なものだけを残します。実装方式は標準設定、API／side-by-side、コア改変の順に検討し、RFPで対応層を可視化します。PoCでは例外と物理条件を壊し、受入では業務・品質・運用を測り、アップグレード前から回帰パックを持つことが、タイ工場で長く使える在庫基盤につながります。

自社の差異が標準化できるのか、API拡張が必要なのかをRFP前に整理したい段階でも、TOMAS TECHへご相談ください。現場制約と5年TCOを並べ、実装範囲を絞るところから検討できます。

関連記事

• タイ工場の在庫管理システム導入ガイド
• ERPと生産管理システムの連携設計
• 工場向け在庫管理システム比較の視点

参考情報

1. Thailand BOI, Measure for Industrial Upgrades towards Smart and Sustainable Industry: https://www.boi.go.th/index.php?language=en&page=smart_sustainable
2. BOI/OSOS, Thailand Secures $43.6bn 1H 2026 Investment Surge, 23 July 2026: https://osos.boi.go.th/EN/news/2430/Thailand-Secures-43-6bn-1H-2026-Investment-Surge-as-Big-Tec/
3. GS1 General Specifications 17.1.0: https://ref.gs1.org/standards/genspecs/17.1.0/
4. GS1 EPCIS 2.0.1: https://ref.gs1.org/standards/epcis/2.0.1/
5. NIST SP 800-218, Secure Software Development Framework Version 1.1: https://csrc.nist.gov/pubs/sp/800/218/final
6. ISO/IEC 25010:2023 product quality model: https://www.iso.org/standard/78176.html
7. SAP Extension Architecture Guide: https://help.sap.com/docs/sap-btp-guidance-framework/extension-architecture-guide/what-is-extension-architecture-guide?locale=en-US
8. SAP clean-core extensibility: https://help.sap.com/docs/erp-transformation-with-itc/buildable-map/clean-core-extensibility-for-sap-cloud-erp?ai=true
9. Microsoft Power Platform ALM overview: https://learn.microsoft.com/en-us/power-platform/alm/overview-alm
10. Microsoft application modernization guidance: https://learn.microsoft.com/en-us/power-platform/guidance/adoption/application-modernization
11. Oracle Warehouse Management 26B REST API Guide: https://docs.oracle.com/en/cloud/saas/warehouse-management/26b/owmre/wms-rest-api-guide.pdf

※本稿の制度・標準・製品情報は2026年9月15日時点で確認した公式情報に基づきます。BOI優遇の適用可否、税務・法務要件、製品の契約範囲は、必ず所管機関・専門家・各ベンダーへ案件別に確認してください。