期末の仕掛品棚卸で「生産オーダー上は工程2に100個あるが、現場で数えると工程1の脇に20個、工程2に75個、品質保留箱に5個」という状態は珍しくありません。合計100個というだけでは十分ではありません。作業着手前の20個と加工中の75個と検査保留の5個は、完成見込み、作業責任、原価の集計点が違うからです。仕掛品棚卸管理システムを導入する目的は、期末の数字を無理に一致させることではなく、ある時点の現物を識別し、作業指示、ロット、場所、工程状態、取引記録につなぎ、差異の理由と承認の証跡を残すことです。
この記事ではタイの製造工場を想定し、月末または年度末の実地棚卸を扱います。日常の仕掛品管理全般、ロット分割・統合や工程間搬送の設計、材料返品の処理とは対象を分けます。棚卸効率化の一般論や在庫調整の承認にも関連しますが、ここでの中心は「加工途中の現物を期末時点でどう数え、どの生産状態として確定するか」です。例示の数量や期間は設計検討用の仮定であり、業界の標準値や規制上の基準ではありません。
まず棚卸対象と会計上の仕掛品を分けて定義する
現物棚卸は、工場内または委託先にある物の数量と状態を確認する作業です。一方、仕掛品の会計残高は材料投入、作業時間、製造間接費、完成報告などの記録と原価計算規則から求めます。両者は同じ画面に並べられても同義ではありません。たとえば材料が製造オーダーへ払い出され、まだ切断されずにライン脇に置かれているとき、現物は原材料の形を保っていてもシステム上は仕掛品原価へ振り替わっている場合があります。逆に完成を現場が宣言していても、検査待ちのため完成品入庫が未計上の場合もあります。Microsoftの生産転記の説明は、材料消費、作業時間、完成報告、オーダー終了が別の記録であることを示しています。製品の機能例であり、全工場に同じ仕訳を要求する規則ではありません。
導入前に、現物棚卸の対象を「原材料庫から出て生産に割り当て済み」「工程間で待機」「設備内で加工中」「品質保留」「手直し待ち」「委託先保管」などに区分します。物が存在しても当社所有でない支給品、廃棄承認済み品、完成品入庫済み品は同じ集計に混ぜません。対象外にする理由も文書化します。所有権、所在、工程状態、評価区分は別の属性です。一つの「仕掛品」フラグだけで四つを表現しようとすると、棚卸時の例外が必ず曖昧になります。
多品種少量の工場では、製品ごとに加工途中の形が違います。加工前の素材10本、切断後の部品40個、組立後の半製品10台を単純に60個として足せません。数える単位と原価評価単位、換算の根拠、版数を決めます。重量、長さ、個数の換算には測定誤差があるので、見かけの数量差を損失と断定しない設計が必要です。会計方針やタイの申告要件は自社の経理・監査担当と確認してください。システム設計はその判断に必要な現物と記録を渡す役目です。
数量を固定する時刻を一つ決め、移動中を消さない
棚卸で最初に決めるのは「何時何分の残高を求めるか」です。たとえば月末日の18:00をカットオフとするなら、17:59の工程完了と18:01の完成入庫は別期間に属します。数える作業が翌朝まで続いても、基準時刻は変えません。現場端末の登録時刻と実際の発生時刻を両方持ち、遡及登録があれば理由と承認を残します。端末がオフラインでもイベントIDと端末時刻を保存し、同期時刻だけで期間を判定しないようにします。時刻はタイ現地時刻とシステムのUTCを換算し、日付境界の誤差を防ぎます。
すべての設備を一斉停止する必要があるとは限りません。棚卸区域を順番に固定し、固定中に入出庫を禁止する方式、作業を続けながら基準時刻前後の移動イベントを補正する方式があります。どちらでも「誰が、どの場所を、いつ固定し、いつ解除したか」を記録します。Microsoftのタグ棚卸の説明では、設定によって計数中の現物更新をロックできる一方、タグ棚卸は計数中に品目をロックしない場合があると区別しています。製品仕様を参考に、自社では物理移動の禁止とシステム入力の禁止を別々に定義します。
搬送中のワークを「出発元にも到着先にもない」として消してはいけません。搬送票、コンテナID、出発時刻、到着確認、搬送責任者を使って、基準時刻時点の所在区分を「工程間移動中」にします。倉庫システム、MES、手書き票のどれが移動イベントの正本かを決め、同一移動を二重計上しないようIDで照合します。委託先にある物は、現場で見られないため、委託先の確認日、確認者、数量、差異の処理状況を別に持ちます。ただし委託先確認の時点が期末と異なる場合は、その間の入出荷をブリッジして期末数量を求めます。
棚卸単位は「品目」より細かく、現場が数えられる粒度にする
推奨する棚卸キーは、品目、品目版、ロットまたはシリアル、生産オーダー、工程、場所、容器、所有区分、品質状態、基準時刻です。すべての物に全項目を強制する必要はありませんが、期末時点に同じ品目が別工程、別オーダー、別品質状態に存在するなら、集計前に区別できる識別子が必要です。GS1のGlobal Traceability Standardは、品目レベル、ロットレベル、個体レベルの識別を目的に応じて選ぶ考え方を示しています。全品をシリアル化することを求める根拠にはなりません。
タグを容器に付ける場合、そのタグが箱のIDなのか箱の中のロットIDなのかを分けます。箱が再利用されると容器IDは一定でも中身は変わります。棚卸時点の容器と中身の対応、ラベルを印刷した時刻、ラベル交換履歴を保存します。端末では品目名だけでなく写真または図面版、容器色、標準入数、現場の通称を表示できます。ただし写真は本人の判断を助ける補助情報であり、異品混入を自動的に否定する証拠にはなりません。バーコードが読めないときは手入力を許し、手入力理由、入力者、再確認者を付けます。
工程状態は「着手前」「加工中」「工程完了・次工程待ち」「品質保留」「手直し」「廃棄判断待ち」など、数えた人が実物で判断できる名称にします。「進捗率60%」だけでは現物を分類できません。加工中の設備内に複数個ある場合は、安全を優先し、停止手順と設備側の計数方法を事前に決めます。設備を開けて数える行為自体の安全上の可否は、現場の機械安全手順に従います。読めない内部物を推定値で登録するなら、推定方法、担当者、後日確定方法を明示し、実測と区別します。
同一ロットを複数容器に分けたときは容器ごとに数え、集計では元ロットに戻せるよう関係を保持します。ただしこの記事の主題は分割・統合の一般的な履歴管理ではなく、棚卸日現在にどの容器の何個を誰が数えたかです。重量換算の場合、容器風袋、秤の校正状態、測定時刻を記録します。数量が小数になるか、端数をどう扱うかを棚卸開始前に決め、差異が出た後でルールを変えないことが重要です。
実地計数は「一度入力したら終わり」にしない
計数票または端末の作業単位を場所別に発行し、担当者が現物のラベル、数量、状態を確認します。予想数量を表示するか隠すかは統制の選択です。盲検計数では期待数に合わせる誘因を抑えられますが、現場の識別が難しい品目では誤読リスクもあります。二回目の計数を行う条件を、差異の絶対数、価額、品質状態、重要顧客向けロットなどで設定します。しきい値は製品価値とリスクに合わせて社内承認し、記事の例をそのまま閾値にしないでください。
「場所Aを数えた人が場所Bのワークも数えた」「同じ箱に二枚のタグが貼られていた」「棚卸中に工程が完了した」といった例外を登録できることが大切です。計数票にはゼロ件確認も必要です。空の棚を無視すると、数え忘れとゼロを区別できません。予定された棚卸対象の各場所について、完了、未着手、立入不可、移動中、対象外を明示し、未完了のまま期末確定できないようにします。
Microsoftの在庫ジャーナルの説明では、計数ジャーナルが実際の数量を記録し、差を調整する仕組みとされます。ただし汎用の在庫計数画面をそのまま使うだけでは、製造オーダー、工程、品質状態、加工単位が足りない場合があります。RFPでは「仕掛品の物理計数に必要な列が標準機能で持てるか」「不足分をMESのイベントとして持ち、ERPへ要約できるか」を画面デモで確かめます。WMSの倉庫ロケーションだけで工場内の工程状態を代用しないでください。
差異を三つに分けて、原因を先に調べる
差異には少なくとも、物理数量差、識別・所在差、期間差があります。物理数量差は同じキーの現物が帳簿より少ないか多い場合です。識別・所在差は合計数量が合っていてもロット、オーダー、工程、品質状態の割当が違う場合です。期間差は期末前に実際は移動したが記録が翌日に入力された場合などです。この分類なしに「棚卸調整」で一括処理すると、次月も同じ不一致が再発します。
仮の例として、オーダーPの工程2に帳簿上120個、現場計数では工程2に90個、品質保留箱に10個、工程1からの搬送コンテナに20個が確認されたとします。総数120個は一致しますが、工程2の加工可能数量は90個で、10個には品質判定、20個には到着確認が必要です。ここで30個の棚卸増減を計上するのは誤りです。別の例で、帳簿120個に対して現物が118個しか見つからない場合は、2個の真の不足と断定する前に、重複票、計数漏れ、完成報告の時差、不良品置場、機内残を調べます。どちらも例示値で、実際の許容差ではありません。
調査画面には差異の元となるスナップショット、計数票、写真、移動イベント、製造実績、品質記録、再計数結果を紐づけます。責任者は原因候補、確認方法、暫定措置、最終原因、予防策を記録します。数量を修正する権限と、原因を確定する権限と、会計仕訳を承認する権限を分ける設計が有効です。例外承認そのものの詳細は在庫調整承認の記事を参照してください。ここでは調整前に現物の所在を説明できることを主眼とします。
差異ゼロでも、別ロットを誤って付け替えた可能性があります。重要ロットは帳簿数量との一致率だけでなく、識別の一致、場所の網羅、保留品の漏れ、未完了票の残数をKPIにします。差異件数を減らすために現場へ帳簿を見せて数字を合わせる運用は、問題の発見能力を失わせます。調査の成果は「なぜ起きたか」と「同じ誤りを防ぐ入力点がどこか」に置きます。
ERP・MES・WMSの役割を決めて照合する
ERPは製造オーダー、材料払出、完成報告、原価と会計期間の正本になりやすい一方、MESは工程実績と現場状態、WMSは倉庫の保管場所と容器移動を詳しく持つことが多いです。ただし製品名だけで役割を決めないでください。既存システムの実データと担当部署を見て、各属性ごとに正本を一つ定めます。たとえば製造オーダー番号はERP、工程進捗と作業完了時刻はMES、棚卸対象の工場内位置はMES、完成品倉庫位置はWMS、会計確定残高はERP、といった割付です。工場ごとに変わってよいですが、同じ属性に二つの編集可能な正本を置かないことが重要です。
照合は単一の総数比較で終わらせません。品目・ロット・オーダー・工程・場所・状態のキーで、基準時刻のMESスナップショット、ERPの材料投入と完成報告、WMSの移動記録を突き合わせます。Microsoftの品目トレースの資料は、追跡キーとして品目、バッチ、保管ディメンション、期間を使い、生産オーダーも追えることを示します。これも製品の実装例であり、他システムでは独自のキー設計が必要です。キーマッピングの誤りが棚卸差異に見えるので、旧品目コードや代替単位の対応表を版管理します。
インターフェースではイベントID、発生時刻、登録時刻、送信元、送信先、処理状態を保持し、再送しても二重転記しない冪等性を確保します。同期遅延と入力遅延は別です。ERPへ届いていないがMESにはあるイベントは連携障害、MESにも無い現物は現場登録の問題です。期末確定前に未送信、失敗、手動修正待ちのキューを一覧化し、原因と締め切りを付けます。月をまたぐ遅延が分かった場合、会計処理は承認済みの方針で行い、元データの時刻を黙って書き換えません。
期末スナップショットと監査証跡を残す
棚卸の確定時には「今の画面」を証拠にせず、基準時刻のルール、対象範囲、マスタ版、数量、評価区分、未解決差異、承認者をまとめて固定します。翌日に搬送や再計数が起きても、前日のスナップショットが自動で上書きされないことが必要です。修正は差分イベントとして追加し、修正前後と理由を追えるようにします。閲覧者が「期末時点で何が分かっていたか」と「後から何を訂正したか」を区別できる構成にします。
写真を証跡とする場合は、対象ロットや位置、撮影時刻との対応が必要です。画面上に写真があるだけでは、別の箱の写真でない保証になりません。カメラを使えない区域、個人情報や顧客図面が映る区域では別の証拠を設計します。承認ログには承認者の役割、承認対象のスナップショットID、未解決例外の扱い、承認時刻を残します。タイ・日本本社間で承認する場合は時差があるため、表示時刻と保存時刻を統一し、承認の順序を取り違えないようにします。
月次で必要な集計表は、現物総数だけでなく工程別、品質状態別、オーダー別、未解決差異別を見られるものにします。Excelへのエクスポートだけで終わると、出力後にどの修正が入ったか分からなくなります。ファイルには出力日時、スナップショットID、フィルタ条件、データ版を含めます。評価額と現物数量の明細を同じキーでドリルダウンできることが望ましい一方、原価は権限管理が必要なので現場計数者に全面表示する必要はありません。
タイ工場での運用設計は言語と勤務体系から始める
日本語の管理ルールをそのままタイ語端末に翻訳しても、現場で同じ判断になるとは限りません。「工程完了」「検査保留」「再加工待ち」などの状態名を現場のタイ語、英語、日本語で対訳表にし、実物を使って意味を確認します。ラベルには短い語と色を併用できますが、色だけで状態を伝えないようにします。夜勤の最後と日勤の最初にカットオフが重なる場合は、どちらの班がどの区域を数え、未完了を引き継ぐかを決めます。シフト交代で承認待ち票が放置されることを防ぐため、担当者だけでなく役割・期限でタスクを追跡します。
ネットワークが不安定な場所では端末のオフライン入力が必要かもしれません。その場合、同じ容器を二台が数えた際の衝突検知、再同期順序、端末紛失時の未送信データの扱いを試験します。携帯端末を導入しても、グローブ着用、油や粉じん、照明、ラベルの曲面、バーコードの汚れなどで読取率は変わります。机上のデモだけで選定せず、実際の作業姿勢と設備周辺で試します。電子化が目的ではなく、誤認を減らし、期末の現物と履歴を説明できることが目的です。
委託加工がある工場では、相手先から期末残高確認を受ける時刻、フォーマット、単位を合意します。こちらの期末18:00と相手先の営業終了時刻が一致しないことがあります。差分期間の入出荷を記録し、相手先の「加工済みだが未発送」と自社の「未入庫」を両方残します。仕掛品の所有権や原価の認識は契約と会計方針によるので、単に所在地で評価を決めないでください。
RFPには画面一覧より受入シナリオを書く
RFPで「バーコード対応」「棚卸機能あり」と書くだけでは、仕掛品の難所を評価できません。最初に対象工場、対象ライン、品目数、オーダー数、容器数、現在のERP・MES・WMS、月末締め時刻、稼働シフト、対象言語を整理します。次に、実際に起きた差異を匿名化したテストデータを渡します。たとえば同一ロットが二つの工程にあり、片方は検査保留、片方は搬送中で、現物は帳簿総数と一致するケースを入れます。ベンダーには「数が合う画面」ではなく、状態別にどう説明し、期末スナップショットへどう残すかを実演してもらいます。
必須要件は、基準時刻の固定、場所と状態の網羅、計数担当者の分離、再計数、差異分類、未解決例外の可視化、元データへの遡り、監査ログ、権限、連携失敗時の再送です。性能要件は自社の実測から定めます。たとえば「現場の実データ件数を使い、締め処理後に指定時間内で全工程の未完了票を一覧表示できる」と書けば検証できます。「高速」とだけ書いても検証できません。端末台数とオフライン時間、スキャン率、ラベル貼替頻度も見積条件に含めます。
提案価格はライセンスだけで比べず、マスタ整備、過去データ移行、設備周辺のラベル、端末、ERP・MES・WMS連携、教育、夜勤サポート、変更管理、運用保守まで分けて確認します。カスタム開発の境界、将来の品目追加費用、データエクスポート形式、障害時の手動手順も求めます。見積が低くても、工程状態を表現できずExcelで毎月補うなら、実務の負担は残ります。利用部門、IT、経理、品質の全員が同じ受入条件を見て比較できるようにします。
FATではデータ整合、SATでは実物と締め処理を試す
FATはベンダー側の制御された環境で、代表データと例外データを使って仕様を検証します。典型ケースだけでなく、タグ読取不可、二重スキャン、オフライン登録、18:00前後の搬送、翌朝の遡及入力、帳簿総数一致だが工程状態不一致、未解決差異があるままの確定操作を入れます。期待結果を事前に書き、操作ログと出力ファイルを証跡に残します。改善点は重大度、担当、再試験日を付けて閉じます。
SATはタイ工場の実際の端末、ネットワーク、シフト、ラベル、設備、既存ERP・MES・WMSとの連携で行います。短い試験区間の現物を実際に数え、期末時刻でスナップショットを作り、翌日の修正が前日の結果を上書きしないことを確認します。二言語以上で同じ状態を選べるか、夜勤から日勤へ未完了票が引き継がれるか、経理が承認済み値だけを受け取るかも確認します。実地棚卸の本番日は作業が集中するため、障害時の紙票、採番、復旧入力、重複防止まで事前に練習します。
判定基準は「全シナリオ成功」だけでなく、未解決差異の残件、データ連携エラー、棚卸票の網羅率、再計数の完了、承認待ちの扱いを含めます。例として「未解決の高リスク差異ゼロ」は実務的ですが、高リスクの定義を顧客製品と金額で合意しなければ測れません。FATで通ったからSATを省略する、SATで数量が合ったから監査ログを省略する、といった判断は避けます。受入後の最初の月末は並行確認期間を設け、旧手順との違いを説明可能にすることが有効です。
導入手順は小さな区域から始めて月末全体へ広げる
第一段階では、現在の棚卸票、ロットラベル、工程状態、会計締め手順を集め、どこで「実物はあるがシステム上は見えない」状態になるかを洗い出します。最近の差異を数件選び、原因追跡に必要だった項目を逆算します。第二段階で代表ラインを一つ選び、品目・オーダー・場所・状態のマスタと識別ルールを整えます。第三段階で計数、差異分類、再計数、承認、スナップショットを同じ区域で試します。ここで操作が複雑すぎれば、全工場展開前に見直せます。
次にERP・MES・WMSの連携を段階的に接続し、期末の未送信・二重送信・遡及入力を検証します。最後に夜勤、品質保留、委託先、搬送中の区域へ広げます。各段階で「未解決の差異を説明できるか」「数え忘れを検知できるか」「修正前後の履歴が残るか」を受入条件にします。現場の計数時間だけを短縮しても、経理が数日間Excelで差異を調べるなら改善とは言えません。計数から承認済みスナップショットまでの全体時間と再調査件数を測ります。
運用開始後は、棚卸差異の金額だけでなく、未完了場所数、識別不能容器数、時刻不明イベント数、再計数率、期末後の訂正件数を月別に見ます。これらは原因を探す指標であり、無理にゼロへ近づけるための現場評価項目ではありません。繰り返す不一致があれば、ラベル貼付、工程完了登録、搬送確認など入力点を改善します。仕掛品棚卸は期末だけのイベントですが、精度は毎日の工程記録によって決まります。
棚卸票の一行に何を残すか：後から再現できる記録例
棚卸票の設計を抽象的な項目表で終わらせないため、仮の一行を考えます。「基準時刻は月末18:00、工場Aのライン2、工程20の前、容器C-017、品目P-42の版B、ロットL-08、製造オーダーMO-531、品質状態は工程完了・検査待ち、実測は24個、単位は個、計数時刻は翌朝08:14、計数者は作業者A」とします。ここで翌朝08:14は物を数えた時刻で、18:00の現物数量そのものではありません。その間に移動や検査があれば、18:00から08:14までのイベントを足し引きして基準時刻の数量に戻します。補正のイベントIDと計算式を同じ行から開けるようにし、結果だけを24個に書き換えないようにします。
容器が空だった場合も行を残します。想定した容器が見つからないのか、容器はあるが中身がゼロなのか、そもそもその場所が棚卸範囲外だったのかは別の事象です。ゼロ確認には現場で場所を見た人、見た時刻、棚や設備の識別子を残します。安全上立ち入れない設備内は「ゼロ」ではなく「未確認・代替方法待ち」にします。後で設備を開けて数えられたら、先の未確認行を消すのではなく、実測行と結び付けて解消します。これにより、期末承認者は未確認がいくつ残ったかを判断できます。
同じ24個でも、重量換算で求めた24個と一個ずつ実測した24個は証拠の強さが異なります。記録に「個別計数」「標準入数×箱数」「重量換算」「設備カウンター」「推定」などの計数方法を持たせ、計器ID、風袋、換算係数、端数処理、必要なら再確認者を紐づけます。スキャンの成功だけを証拠にすると、貼り違えたラベルに気づけません。図面版と現物形状を照合したか、封印した容器を開けずに標準入数を採用したか、といった確認条件も選択式で残すと、翌月の再調査が速くなります。
初回の月末を迎える前に、移行データと例外の責任者を確定する
新システムへの移行では、現行ERPの仕掛品残高をそのまま初期値として流し込むだけでは不十分です。場所が空欄の製造オーダー、廃止された品目コード、別単位で残った旧ロット、工程完了だけ登録されて入庫していない半製品を抽出します。それぞれ「現物がある」「帳簿だけある」「現物はあるが識別できない」「期間差で翌月に反映する」に分類し、移行前に直すものと、初回棚卸の調査案件として残すものを決めます。移行時の帳尻合わせで履歴を消すと、導入後に同じ差異を追跡できません。
初回の並行確認では、旧帳票と新スナップショットの総数が合うかだけでなく、オーダー・工程・品質状態別に差を出します。片方にしか存在しない行は自動で一覧化し、品目コード対応表、計数範囲、計上時刻、単位換算のどれが原因かを記録します。運用部門は現物の確認、品質部門は保留状態、ITは連携とマスタ、経理は期間と評価を担当する、といった責任分担を合意します。誰が判断するか未定の例外は、ソフトウェアがどれほど速くても締め日に滞留します。承認期限と代理者を設定し、夜勤・休日でも解決の経路を用意します。
本番切替の可否は、単なる「システム稼働」では判断しません。棚卸対象区域の網羅、必須キーの欠落件数、未送信イベント、照合不能行、権限設定、バックアップ復元、紙票からの復旧入力を証拠付きで確認します。重大な未解決差異が残る場合は、承認済みの暫定手順で月末を処理し、原因と解消期限を残します。次月は同じ例外を繰り返さないため、ラベルの貼付点、工程完了の登録点、搬送の受取点を改善します。移行の成功は最初の月末に数字が偶然一致したことではなく、差が生じても所在と原因を説明し、修正履歴を再現できることです。
よくある質問
仕掛品棚卸管理システムはERPだけで実現できますか
ERPが工程、場所、容器、品質状態、実地計数、基準時刻のスナップショットを必要な粒度で扱えるなら可能です。扱えない場合はMESや現場端末で現物と工程状態を記録し、承認済みの結果をERPへ連携する構成が考えられます。製品の名前より、実データでの受入試験結果を優先してください。
期末にラインを止めずに数えられますか
可能な場合がありますが、基準時刻前後の入出、工程完了、搬送を確実に記録し、区域ごとの固定・解除と遡及補正を管理する必要があります。安全のために停止が必要な設備内は現場手順が優先です。作業を続けたまま数えること自体を成果とせず、期末時点の数量を再現できるかで判断します。
帳簿総数が合えば差異なしとできますか
できません。同じ120個でも、90個が加工可能、10個が品質保留、20個が搬送中なら、工程2に120個あるという帳簿とは状態と場所が違います。数量差、識別・所在差、期間差を分けて確認します。
バーコードを導入すれば棚卸差異はなくなりますか
バーコードは識別と入力を助けますが、ラベルの貼り違え、未登録移動、誤った工程状態、二重計数を自動的には防ぎません。再計数、計数票の網羅、イベント照合、承認履歴まで一緒に設計します。
原価評価まで同じシステムで行う必要がありますか
必須ではありません。現物の数量・状態と、原価評価・会計転記の責任を分ける構成もあります。ただし同じ生産オーダーと基準時刻をたどれないと、両者の差を説明できません。自社の会計方針に合わせた連携を設計してください。
まとめ
仕掛品の期末棚卸を成立させる鍵は、数えた量だけでなく、基準時刻、物の識別、工程状態、場所、計数者、差異の説明を一緒に固定することです。総数が一致しても加工可能数や品質状態が異なれば、次の生産計画と原価の判断を誤ります。RFPでは現場の例外をシナリオ化し、FATでデータ整合を、SATで実物・端末・シフト・締め処理を確かめると、導入後の月末作業を具体的に改善できます。
タイ工場で期末の仕掛品数量とERP・MES・WMSの記録が合わず、棚卸単位や連携範囲から整理したい段階でも、TOMAS TECHは現場調査と要件定義をご支援できます。お問い合わせから対象ラインと現在の棚卸方法をお知らせください。
