仕掛品管理｜滞留を減らすタイ工場のRFP・KPI設計

仕掛品管理の課題は、単に「現場に物が多い」ことではありません。どの製造指図・ロット・工程に、何が、いくつ、いつから滞留し、次に誰が動かすのかを説明できない状態が本質です。この状態では、納期回答、材料手配、原価把握、品質調査、運転資本の管理が同時に不安定になります。本稿では、タイの製造拠点でWIP（Work in Process）を見える化するために、データ定義、工程イベント、KPI、RFP、90日のSmall Startをどう設計するかを実務の順番で解説します。

仕掛品管理で最初にそろえる共通言語

「物」「作業」「金額」を同じWIPと呼ばない

WIPという言葉は部署によって意味が変わります。製造部は工程間にある数量、計画部は未完了の製造指図、倉庫は中間品の在庫、経理は未完成品に集積した原価を指すことがあります。これらは関係しますが、同じデータではありません。RFPの冒頭で最低でも次の三層を分けます。

層	管理対象	主な識別子	主な利用者
物理WIP	実在する材料・半製品・容器	品目、ロット、シリアル、容器ID、数量、単位	製造、倉庫、品質
作業WIP	未完了の作業・工程・指図	製造指図、作業番号、工程、設備、状態	計画、製造、保全
会計WIP	未完成品へ配賦・転記された金額	指図、原価要素、勘定、会計期間	原価、経理、経営

物理WIPが移動しても、実績イベントが登録されなければ作業WIPは前工程に残ります。逆に完了実績だけを先に登録すると、システム上は次工程へ進んでいても現物は置き場に残ります。さらに会計WIPは、出庫、作業時間、間接費、完了・入庫などの転記規則に依存します。したがって「WIP残高が合う」という受入条件だけでは不十分です。三層ごとに正とする時点、数量、金額、責任者を決める必要があります。

WIPの状態遷移を先に定義する

仕掛在庫見える化は、一覧画面を作ることから始めません。製造現場で起きる事実を状態遷移として定義します。標準的には、未着手、払出済み、作業中、保留、完了待ち、次工程待ち、外注搬出、外注戻り、検査待ち、不適合隔離、手直し、完了、取消などです。ただし状態を増やしすぎると入力が破綻します。状態は「次に行う処置」「責任部署」「滞留時計を止めるか」が変わる境界に絞ります。

例えば「保留」は一語で済ませず、品質判定待ち、設備復旧待ち、材料不足、図面・条件待ち、計画変更待ちを理由コードで分けます。理由が違えば次の担当も違うからです。状態と理由を分離すると、状態一覧は簡潔なまま、改善分析に必要な粒度を確保できます。

WIPの一意性を保証する識別子

WIP 管理システムの精度は、識別子の設計でほぼ決まります。品目と数量だけでは、同じ品目が複数指図、複数ロット、複数工程に存在すると区別できません。最低限、製造指図、作業番号または工程、品目、ロットまたはシリアル、数量単位、現在ロケーション、容器・台車ID、最終イベント時刻を関連付けます。

バッチ生産では分割と統合も重要です。親ロットが複数の子ロットへ分かれ、後工程で再び混合される場合、単純な上書きでは系譜が失われます。分割元、分割先、数量、時刻、理由、実行者をイベントとして残し、数量保存の検証を行います。個体管理が必要な製品ではシリアル、数量管理が中心ならロットや容器を主キーにするなど、対象工程のトレーサビリティ要求に合わせます。

仕掛在庫見える化に必要なイベント設計

「現在値」ではなくイベントから再現できるようにする

現在位置と現在数量だけを保存する方式は、表示には速くても、なぜその状態になったかを説明できません。推奨するのは、発生時刻付きのイベントを記録し、その結果として現在値を更新する方式です。主要イベントには、指図発行、材料払出、工程着手、工程中断、工程再開、良品実績、不良実績、手直し指示、工程完了、移動、受入、検査判定、完了入庫、取消・訂正があります。

各イベントには少なくとも、event_id、event_type、occurred_at、recorded_at、order_id、operation_id、item_id、lot_or_serial、container_id、from_location、to_location、quantity、unit、reason_code、operator_or_device、source_systemを持たせます。occurred_atは現場で事実が起きた時刻、recorded_atはシステムへ到達した時刻です。この二つを分けると、オフライン入力や連携遅延を可視化できます。

訂正は元イベントの削除ではなく、参照関係を持つ取消イベントと正しい再計上で処理します。監査証跡を残し、過去時点のWIPを再現できるからです。RFPでは「履歴を保存する」だけでなく、訂正後も元記録、訂正理由、承認者、影響数量を追跡できることを受入条件にします。

ERP・MES・設備データの役割を分ける

Microsoft Dynamics 365の製造プロセス概要は、製造指図のライフサイクルを作成・見積・計画・リリース・開始・完了報告・終了といった段階で説明しています。この考え方は、ERPが指図・計画・原価の基準を持ち、現場実行側が詳細な着手・停止・移動・実績イベントを持つ役割分担の整理に役立ちます。

ERPは品目、BOM、工程、製造指図、計画数量、会計転記の正本になりやすい一方、MESは秒・分単位の進捗、作業者、設備、実績数量、保留理由を扱います。PLCやIoTゲートウェイはサイクル、信号、カウンタなどを取得しますが、設備信号だけではどの指図・ロットを加工したか分からないことがあります。そのため「設備が動いた」ことと「対象WIPが進んだ」ことを結び付ける文脈IDが必要です。

RFPでは、システム名ではなくデータ所有権を表にします。例えば指図ヘッダーはERP、作業着手はMES、設備カウンタはIoT、検査判定はQMS、会計WIPはERPというように、項目単位でSystem of Recordを決めます。双方向連携を増やすほど同期矛盾が増えるため、更新主体は原則一つにします。

現場入力は例外処理を中心に設計する

自動取得できる通常実績は設備やスキャナーから取り込み、人が入力する画面は例外に集中させます。作業者に毎回、指図、工程、品目、ロット、数量、置き場を手入力させると、入力遅れと誤りが発生します。バーコード、QR、RFID、端末ログイン、設備割当を組み合わせ、既知項目を自動補完します。

ただし、自動化しても分割、混載、代替材料、数量差、スクラップ、手直し、オフライン復帰は残ります。デモでは正常系だけでなく、次の例外を実機またはテスト端末で確認します。

一つの容器を二つへ分割し、数量合計が一致する
誤った工程完了を取消し、元履歴を残して再登録できる
通信断中に記録し、復帰後に重複なく同期できる
不適合判定で移動を止め、権限者だけが解除できる
単位換算がある品目で基準単位と現場単位を併記できる
ラベル破損時に再発行履歴と旧ラベル無効化を管理できる

工程進捗見える化をKPIへつなげる

KPIは意思決定と対にする

ISO 22400-1は製造オペレーション管理におけるKPIの枠組みを扱います。ISO 18828-4が扱うKPIは、量産における生産計画プロセスが対象であり、工業システム全般の万能なKPI規格ではありません。該当する計画業務に限って参照します。規格名をRFPへ書くだけでは成果は出ません。KPIごとに、定義、対象範囲、時間窓、除外、データ源、更新頻度、責任者、閾値超過時の行動をセットで決めます。

例えば「工程別WIP数量」が増えたとき、計画担当が投入を止めるのか、製造責任者が人員を再配置するのか、品質担当が保留理由を確認するのかで必要な切り口は変わります。ダッシュボードは観察の終点ではなく、判断と処置の入口です。

基本KPIの算式

以下は実績値ではなく、システムへ実装するための定義例です。分子と分母の対象を同じ工場、製品群、工程、期間でそろえます。

KPI	算式・定義	主な用途
WIP数量	対象時点で未完了の良品数量＋処置未確定数量	工程間滞留の把握
WIP金額	未完了指図へ有効に転記された材料費＋加工費＋配賦費の合計	運転資本・原価確認
滞留時間	現在時刻－現在状態へ入った時刻	優先処置の抽出
工程リードタイム	工程完了時刻－工程着手時刻	工程能力・ばらつき分析
待ち時間	次工程着手時刻－前工程完了時刻	搬送・段取り・キュー改善
期限超過率	基準滞留時間を超えたWIP件数÷対象WIP件数×100	アラート品質確認
初回合格率	手直しなしで合格した数量÷検査対象数量×100	品質ロス把握
記録遅延	recorded_at－occurred_at	データ鮮度の監視

「件数」と「数量」は分けます。容器一つに大量の仕掛品が入る工程では、件数が少なくても数量影響が大きいからです。「時間」はカレンダー時間、操業時間、正味加工時間のどれかを明記します。休日を含む滞留時間と、生産カレンダー内の待ち時間を混ぜると比較できません。

Little’s LawをWIP管理に使う条件

流入と流出が長期的に均衡する定常条件で、同じ境界と時間窓を使う場合、Little’s Lawは平均WIP・平均Throughput・平均Lead Timeの関係を次のように表します。

WIP = Throughput × Lead Time

ここでWIPは系内の平均仕掛量、Throughputは単位時間当たりの平均流出量、Lead Timeは系に入ってから出るまでの平均時間です。単位をそろえなければなりません。例えばThroughputを個／日で扱うなら、Lead Timeも日でそろえます。

この関係は、入力した数字から効果を自動的に保証する式ではありません。対象期間に大きな品種変更、停止、受注変動、仕掛の一括廃棄がある場合、平均だけでは現場を説明できません。製品ファミリー、ルート、ボトルネック工程など比較可能な母集団へ分け、中央値、分位、滞留理由も併記します。RFPの受入テストでは、抽出条件を固定し、WIP、Throughput、Lead Timeが同じイベント集合から再計算できることを確認します。

会計WIPと製造実績を照合する

SAPのWIP管理資料やイベントベースWIPの考え方、Microsoft Dynamics 365のproduction posting資料は、製造イベントと原価転記を結び付けて設計する際の一次情報になります。実装では、材料払出、時間実績、間接費、良品・不良、完了報告、入庫、指図終了がどの会計イベントを生むかを整理します。

日次照合では、物理数量と会計金額を直接同一視しません。未転記イベント、連携エラー、締め状態、標準原価・実際原価の差、バックフラッシュ、外注工程、再作業指図など、差異の理由をコード化します。「差がゼロ」だけを目標にすると、未処理を隠す運用になりかねません。差異の発生源、経過時間、解消責任者が見えることを受入条件にします。

タイ工場でWIP 管理システムを優先する背景

タイ中央銀行が2026年8月31日に公表した2026年7月の経済金融動向では、輸出増に沿って製造・サービス活動が前月から改善した一方、民間投資は前期の強い伸びの後に軟化しました。判断直前に再取得したBOTのSDDS表では、2026年7月の製造業生産指数（MPI、2021年=100、非季節調整、速報値）は94.8で、同表の直前表示値は95.7（速報値）です。月次の活動判断と非季節調整指数の水準は同じ尺度ではなく、これらは個別工場のWIP改善効果も示しません。外部環境を単純な因果へ変換せず、WIP管理では注文変更や材料制約がどの指図・工程へ影響したかを短い周期で確認します。

一方、タイ投資委員会（BOI）の2026年上期発表では、投資申請総額は1.47兆バーツ、1,299件、Smart and Sustainable Industryは132件、172億バーツと報告されています。BOIの別の最新発表では、実現した設備投資が5,300億バーツで、その半分がAI関連とされています。これらは個別工場のWIP改善効果を示す数値ではありませんが、タイで設備・デジタル投資が進む環境において、データ基盤と運用設計を同時に整える必要性を考える補助材料になります。

設備を増強しても、投入制御、優先順位、滞留理由、品質保留が見えなければ、工程間に仕掛が積み上がる可能性があります。逆に、可視化だけ導入しても、誰がアラートを処置するか決まっていなければ画面は使われません。投資判断では「ツール導入」と「運用変更」を別予算・別責任にせず、一つの業務成果へ束ねます。

より広い工程設計は製造工程管理システムの設計ポイントを、納期回答との接続は納期管理システムの要件整理も参照してください。

WIP 管理システムのRFPに書くべき要件

業務要件：誰が何を変えるか

RFPでは「リアルタイムに見える」「トレーサビリティを確保」といった抽象語を避けます。業務シナリオを、開始条件、操作者、入力、処理、出力、例外、承認、監査証跡に分けます。

計画担当が製造指図をリリースし、対象工程・計画数量・期日が連携される。
材料担当が払出ロットと数量を容器へ関連付ける。
作業者が指図・工程・設備を選択またはスキャンして着手する。
良品、不良、保留、手直し、移動をイベントとして登録する。
次工程が受入を確認し、送り側と受け側の数量差を検知する。
計画・製造・品質が期限超過WIPを理由別に処置する。
指図完了時に未処理WIP、未転記、未判定がないか検証する。

シナリオごとに権限も記述します。入力、訂正、承認、マスタ変更、強制完了、データ出力を同じ権限にしません。タイ語・英語・日本語で利用する場合は、画面表示だけでなく、理由コード、マスタ名称、帳票、検索、CSVの文字コードまで確認します。

機能要件：検索より先に例外を出す

必須機能は、WIP台帳、工程別キュー、ロット・シリアル系譜、容器管理、滞留アラート、保留・解除、分割・統合、移動、棚卸、訂正、監査ログ、KPI、権限、APIです。現場にとって重要なのは全件検索より「今、処置が必要なもの」です。

アラートには対象、理由、経過時間、数量、納期影響、次担当、推奨アクション、確認状態を持たせます。同じWIPに同じアラートを繰り返さず、確認、保留、解決、再発を履歴化します。閾値は全工場一律ではなく、製品群、工程、稼働カレンダー、優先度で設定できるようにします。

非機能要件：鮮度・復旧・監査を数値化する

「高速」「高可用性」では検収できません。画面応答、イベント反映遅延、同時利用、保存期間、バックアップ、復旧目標、監査ログ、端末管理、暗号化、認証連携、ネットワーク断時の動作を測定可能な条件にします。ただし目標値は工場の制約と重要度から決め、ベンダー提案値をそのまま採用しません。

特にタイ工場では、工場内ネットワークとクラウド間の断続、共用端末、交替勤務、複数言語、手袋着用、読み取りにくいラベルなど、現場条件をテストに含めます。オフラインキューの最大保持量、再送順序、重複排除、端末時刻ずれ、サーバー時刻基準を確認します。

連携要件：API名ではなく契約を定める

連携一覧には、送信元、受信先、データオーナー、トリガー、頻度、主キー、必須項目、再送、順序、重複判定、エラー通知、照合方法を記載します。APIがあるだけでは運用できません。

例えば工程完了イベントがERPへ届かなかった場合、MES側で送信済みか、ERP側で受信済みか、会計転記まで成功したかを段階別に追える必要があります。再送で数量を二重加算しないよう、event_idによる冪等性を求めます。マスタ変更の反映途中に現場が旧版を使う場合の互換性も決めます。

データ移行要件：未完了指図を中心にする

本番切替で最も難しいのは、稼働中のWIPです。過去データをすべて移すより、切替時点の未完了指図、現物ロット、現在工程、数量、置き場、保留状態、会計残高を整合させることが重要です。

移行前に現物棚卸を行い、システム差異を理由別に処置します。移行リハーサルでは、抽出時刻、凍結時間、差分取込、照合帳票、承認者、戻し手順を確認します。切替後に「旧システムと新システムのどちらが正か」が曖昧にならないよう、正本の切替時刻を明記します。

ベンダー比較と受入テストの設計

機能点数ではなくシナリオで比較する

チェックリストの丸の数だけで選ぶと、標準機能の名称は一致しても現場例外に対応できないことがあります。候補ベンダーには同じマスタ、同じ製造指図、同じ例外シナリオを渡し、設定・操作・履歴・KPIまで一連で示してもらいます。

評価軸は、業務適合、データモデル、連携、例外処理、運用保守、セキュリティ、展開性、総費用、導入体制に分けます。デモ用の作り込みと標準機能を区別し、追加開発部分は仕様、テスト、バージョンアップ影響を確認します。多拠点展開を想定する場合、共通テンプレートと工場固有設定の境界も評価します。

受入テストは再計算可能性を確認する

受入テストでは画面が表示されることだけでなく、元イベントから数量、滞留時間、KPI、会計連携結果を再計算できることを確認します。代表的なテストは次の通りです。

テスト	操作	合格条件
数量保存	分割・移動・統合を実行	元数量、移動数量、残数量の関係が一致
重複防止	同じevent_idを再送	二重計上せず再送結果を記録
順序逆転	完了後に遅延した着手イベントを受信	ルールに従い隔離または補正し監査記録を残す
訂正	誤実績を取消し再計上	元履歴、理由、承認、影響が追跡可能
オフライン	通信断中に複数イベントを登録	復帰後に欠落・重複なく同期
KPI再計算	固定データセットを集計	定義書と同じ対象・時間・結果になる
指図完了	未判定WIPを残して完了操作	完了を防止または承認例外として記録

数値の正しさは、期待値が既知の小さなテストデータで検証します。本番データの巨大な集計だけでは、誤差の原因を切り分けられません。テストケース、入力イベント、期待結果、実結果、証跡を一つのパッケージで保存します。

90日Small Startの進め方

90日は導入効果の実績値ではなく、限定範囲で要件と運用を検証する提案期間です。全工場・全製品へ一度に広げず、滞留課題が顕在化し、関係部署が協力できる一つの製品ファミリーまたは工程ルートを選びます。

1〜30日：定義と基準線

WIP三層、状態、理由、識別子、System of Recordを合意する
現物と既存システムを照合し、差異理由を分類する
KPI算式、対象範囲、カレンダー、更新頻度を決める
代表シナリオと例外シナリオを観察する
ERP・MES・QMS・設備の連携点を確定する

この期間の成果物は、現状フロー、イベント辞書、データ項目表、KPI定義書、課題一覧です。いきなり画面を作り始めず、同じWIPを部署ごとに違う意味で数えていないかを解消します。

31〜60日：限定実装と日次運用

対象工程のイベント収集を実装する
WIPキュー、滞留アラート、理由別ビューを用意する
現場端末で正常系・例外系を試す
毎日、記録遅延、未処理、数量差をレビューする
入力負荷とアラート過多を修正する

ここではダッシュボードの見栄えより、事実が漏れず、重複せず、現場の処置につながるかを優先します。アラートを出したら、誰がいつ確認し、どの理由で閉じたかを必ず残します。

61〜90日：受入評価と展開判断

固定データでKPIを再計算し、定義との一致を検証する
オフライン、訂正、分割・統合、保留を含む受入テストを行う
ERP会計転記との照合手順を確認する
運用役割、教育、問い合わせ、障害対応を文書化する
次工程・次工場へ展開する条件と未解決事項を決める

判定は「システムが動いたか」だけではなく、データ完全性、記録遅延、例外処理、現場採用、運用責任、連携安定性で行います。効果数値を事前に捏造せず、基準線と実測値を同じ定義で比較できる状態を作ることがSmall Startの成果です。

よくある失敗と対策

在庫画面だけを作り、工程イベントが欠ける

現在数量の一覧だけでは、滞留開始時刻や原因が分かりません。着手、完了、移動、受入、保留、解除、訂正をイベントとして定義し、現在値と履歴を両方持ちます。

すべてをリアルタイム連携しようとする

重要度の低いマスタまで即時双方向にすると、障害点が増えます。意思決定に必要な鮮度をデータ別に決め、イベント連携、定期同期、日次照合を使い分けます。

現場へ入力責任だけを移す

入力項目が多い、端末が遠い、例外処理がない状態では定着しません。スキャンと自動補完を使い、入力結果が次工程準備や問い合わせ削減として現場へ返る設計にします。

KPIを増やしすぎる

閲覧されない指標は改善につながりません。各KPIに判断者とアクションを割り当て、使われない指標は外します。まずはWIP、滞留、待ち、記録遅延、品質保留など、対象工程のボトルネックに直結する指標へ絞ります。

FAQ：仕掛品管理と工程進捗見える化

仕掛品管理とは何を管理することですか？

工程間にある数量だけでなく、製造指図・工程の未完了状態、ロットやシリアルの所在、保留理由、滞留時間、未完成品へ転記された原価を管理することです。物理WIP、作業WIP、会計WIPを分けて定義し、関連付けます。

仕掛在庫見える化はExcelでも始められますか？

対象工程が限定され、更新責任と時刻が明確なら、状態・理由・KPI定義を検証する初期手段にはなります。ただし同時更新、履歴、スキャン、権限、設備連携、重複防止、監査が必要になると限界があります。Excelを最終システムと決める前に、必要なイベント量と例外を確認します。

WIP 管理システムと在庫管理システムの違いは何ですか？

在庫管理は保管場所の入出庫・残高を中心に扱うのに対し、WIP管理は製造指図、工程順序、着手・完了、待ち、保留、良品・不良、手直しなど製造途中の文脈を扱います。両者は連携しますが、同じ機能範囲とは限りません。

工程進捗見える化で最初に見るKPIは何ですか？

対象工程のWIP数量、最終イベントからの滞留時間、前工程完了から次工程着手までの待ち時間、記録遅延、保留理由を候補にします。KPIは工場一律ではなく、誰がどの判断に使うかで絞り込みます。

リードタイム短縮システムを選べばWIPは減りますか？

システムだけで短縮を保証することはできません。WIP、Throughput、Lead Timeの定義をそろえ、投入制御、優先順位、段取り、品質保留、搬送、設備停止などの原因へ運用上の処置を行う必要があります。システムは事実と処置の追跡を支援します。

RFPではどこまでKPI算式を書くべきですか？

名称だけでなく、分子、分母、対象工程、対象状態、時間基準、除外、単位、データ源、更新頻度、丸め、タイムゾーンまで書きます。候補ベンダーが同じテストデータから同じ結果を再計算できる粒度が目安です。

まとめ

仕掛品管理を成功させる要点は、物理・作業・会計のWIPを区別し、工程の事実を訂正可能なイベントとして記録し、KPIを具体的な判断と処置へ結び付けることです。RFPには一覧画面の要望ではなく、識別子、状態、例外、データ所有権、連携契約、KPI算式、移行、受入テストを記述します。90日のSmall Startでは、効果を先に約束せず、限定工程で基準線と実測値を同じ定義で比較できる土台を作ります。

TOMAS TECHでは、現状の仕掛台帳や工程フローが未整理の段階でも、タイ工場に合うWIP定義、RFP、KPI、連携範囲の整理をご相談いただけます。設備更新やシステム製品の選定前に要件を固めたい場合は、お問い合わせページからご連絡ください。

仕掛品 管理｜滞留を減らすタイ工場のRFP・KPI設計

仕掛品 管理で最初にそろえる共通言語