事例：BOM・工数・複式簿記を一つの基幹システムにまとめた製造業の取り組み

製造業にとって、製品原価はスプレッドシート上の一つの数字ではありません。消費された材料、費やされた工数、処分された仕損、そしてそれらを記述する仕訳の合計です。これらが別々のシステムに分散していると、損益計算書に載る原価は「事実の体裁をとった推測」にすぎません。本稿では、大阪に本社を置き従業員約150名の繊維機械メーカーが、現場と総勘定元帳を一つの基幹システムにどうまとめたかを追います。

現場のリアルなシナリオ

同社は織機部品を設計・組立し、鋼材、ベアリング、電子制御機器を地域の取引先ネットワークから調達しています。技術、組立、品質、営業、それに少数の管理部門を合わせ、約150名が働いています。

長年、同社は三つのゆるく結ばれたツールで業務を動かしていました。一人のエンジニアが一つのアプリで部品表（BOM）を保守し、小さな小物まで各サブアセンブリを追っていました。現場の責任者は紙の作業日報で工数を記録し、それを1週間後に経理へ手渡していました。経理チームは別の複式簿記の元帳に仕訳を起票し、材料や労務の数値を手で打ち直すことが日常でした。

結果は予想通りでした。帳簿上の完成機械の原価は、実際の製造原価とほとんど一致しませんでした。取引先からの材料単価の改定は、1か月遅れて元帳に届きました。残業の工数は丸められたり抜け落ちたりしました。仕損は月末の曖昧な調整として処理されていました。経営陣が主力製品の真の利益率を求めたとき、回答には2週間を要し、なお注釈がついていました。

転機は、大型の輸出向け受注を失ったあとに訪れました。営業部門は既存の原価数値を正確とみなし、攻めた価格で見積もりを提出しました。事後検証で、実際の原価が約9パーセント過小に計上されていたことが分かりました。そのほぼ全体が、取引先の単価引き上げと直近の残業が間に合わず元帳へ届かなかったことが原因でした。取締役会は、製造と会計を一つに結ぶ単一の基幹システムの探求を承認しました。

その背景にある問題

根本原因は決して人にありませんでした。経理チームは規律正しく、現場の責任者は几帳面であり、エンジニアは正確な部品構成を維持していました。問題はアーキテクチャでした。三つの「真実の源」が、それぞれ自分の時計で更新され、期限の圧力の中で手作業で突き合わされていたのです。

三つの失敗が繰り返し起きていました。

一つ目、部品表が実態から乖離していました。技術がベアリングの取引先を変更しても、購買は古い仕様のまま発注し、経理は古い単価で原価を計上していました。多階層のBOMは誤差を増幅し、サブアセンブリでの小さな変更が、完成機械すべてに気づかれず伝播しました。

二つ目、工数が意味を持つ時期に間に合いませんでした。金曜日に記入された作業日報は、水曜日になって原価システムに入力され、翌月の月次決算で総勘定元帳に届きました。その頃には期間はすでに締まり、差異は解決不能な謎になっていました。

三つ目、仕訳が物理的な出来事と結びついていませんでした。原材料の消費、鋳物の仕損処分、残業費用は、いずれも手入力の一行として元帳に着地し、原因となった在庫移動や製造指図書から切り離されていました。監査人がある原価数値の裏付けを求めたとき、回答は印刷物の山でした。

これが分断されたシステムの静かな危機です。個々のツールは働きます。ツール間のつながりが働かないのです。製造業にとって、そのつながりこそが真実の在り処です。

何が変わるか

同社は、部品表、製造指図書、工数、複式簿記のすべてを一つの基幹システムにまとめ、それらを分断していた三つのスプレッドシートに代えて、単一の真実の源として運用する基幹システムへ移行しました。この転換はすべてを自動でつなぐものではありません。すべてを一か所に置くことで、四つのことを変えました。

部品表は、静的な文書ではなく生きた構造になりました。多階層BOMは一度だけ定義され、各製造指図書はそれに基づいて材料を引き当て、完成時に原材料を自動で控除します。技術が部品を変更すると、その変更は購買、在庫、原価計算に同時に見えます。消費や仕損を含む在庫移動は、型付きの操作として記録され、帳簿と同じ一つのシステム内に並んで置かれるため、全体像が一か所に揃います。仕損はもはや月末の曖昧な調整ではなく、発生時に捕捉される独立した在庫出庫操作となりました。その仕損を特定の総勘定元帳科目に紐づける作業は、会計士と確認した手動仕訳によって行われます。

工数は、作業が行われた日から原価記録の一部になりました。作業日報や勤怠の入力は各作業やプロジェクトごとの工数を捕捉し、そのデータは別々の紙の記録ではなく、製造指図書や複式簿記と同じ一つのシステム内に置かれます。システムが捕捉するのは工数であり、労務費を製造指図書に自動で載せたり元帳に送ったりすることはありません。真の製品原価は、製造指図書がすでに消費した材料、作業日報がすでに捕捉した工数、そして労務を正しい原価科目につなぐ会計士確認済みの手動仕訳を組み合わせることで組み立てられます。決算まで見えなかった残業工数は、作業が行われた同じ期間に見えるようになります。

総勘定元帳は、手入力のサマリーの行き先ではなく、帳簿を動かす商取引文書の一部の自然な出力になりました。すべての売上請求書は独自の売上仕訳を生成し、すべての支払請求書は独自の請求書仕訳を、すべての経費精算は独自の仕訳を、仕訳タイプの検証を組み込んだ形で生成します。材料の消費、仕損の処分、労務費といった業務イベントは帳簿と同じシステムに記録されるため、現場と元帳は一つの共有された現実を表しますが、総勘定元帳へは自動では転記されません。いかなる業務イベントを特定の総勘定元帳科目に結びつけるにも、会計士と確認した意図的な手動仕訳が必要です。

決算は、苦闘ではなく規律あるものになりました。決算スケジュールが各期間を定義し、決算実行がその期間の確定した数値をロックします。請求書と支払請求書はその実行に紐づくため、期間の売上と仕入の数値は、週末の手作業なしに突合します。労務費から原価、業務イベントから元帳へのつながりは手動仕訳のままですが、基になる数値がすべて一つのシステムにあるため、三つのスプレッドシートをまたいで探すのではなく、すでに一か所にある数字を確認する作業へと変わります。

2023年10月から運用されている適格請求書等保存方式（インボイス制度）は、一つの基幹システムを望むもう一つの理由を加えました。2026年税制改正で定められた経過措置の改定では、免税事業者からの請求書に対する仕入税額控除が段階的に縮小します。2026年10月から2028年9月までは70パーセント、その後50パーセント、さらに30パーセント、そして2031年10月からはゼロになります。支払請求書を消費や正しい税区分と突き合わせられない製造業者は、年を追うごとに深刻化する突合の頭痛に直面します。各社の適格請求書発行事業者登録番号を保持し、各取引先の登録番号を記録し、明細ごとに正しい税区分を適用する基幹システムは、その頭痛を定型の仕訳に変えます。

いまなぜ重要なのか

この刷新のタイミングは偶然ではありません。多くの日本の製造業者が、同じ時期に自社の基幹システムを見直しています。Windows Server 2012 R2、SQL Server 2014、そして一世代前のオンプレミスERPプラットフォームがセキュリティサポートの終了に達し、立ち止まることの方が動くことより危険になる「レガシーの崖」を生んでいます。経済産業省は、いわゆる2025年の崖を約12兆円規模の潜在的な経済影響という広く引用される数字で枠取りしており、その規模が保守的な企業にすら動きを促しています。

さらにもう二つの力が圧力を重ねます。人手不足は、手作業による突合をますます割高な贅沢にしています。古いスプレッドシートの暗黙知を握る人たちこそ、代替が最も困難だからです。中小企業の事業承継の問題は、引継ぎや売却を計画する経営者にとって、外部の人、監査人、買い手が信頼できるシステムを必要とすることを意味します。一人のベテランの記憶でつなぎ止められた分断されたシステムは、買い手が対価を払う資産ではありません。

とりわけ製造業者にとって、売上原価の問いこそが核心です。BOM、製造指図書、作業日報の工数、総勘定元帳を一つの基幹システムにまとめることは、月次決算を速める以上のことをします。日本の中小企業では、月次決算に未だ1週間から2週間を要する企業が少なくありません。それは決算が何を証明するかを変えます。散在したスプレッドシートから事後に再構築された原価ではなく、すでに一つのシステムにある数値、すなわち製造指図書から消費された材料、作業日報から捕捉された工数、そして労務を製品原価につなぐ会計士と合意した手動仕訳を組み合わせて組み立てられた原価を、決算は報告するようになります。

予実管理の規律も可能になります。部門ごとに予算を設定し、使用量を追跡し、差異通知を適切な管理者へ回すことで、製造業者は材料消費、労務支出、仕損が計画を逸脱したときをほぼリアルタイムに把握できます。その早期のシグナルは、事後のいかなる報告書よりも価値があります。

よくある質問

スプレッドシートでうまく動いているのに、なぜ単一の基幹システムに変えるのですか。

スプレッドシートは計算を正確に行いますが、一か所に揃いません。一つのファイルにあるBOM、紙の上の工数、別の元帳にある仕訳は、人の努力によってのみ突合される三つの真実の源です。個別には正しく、全体としては間違う、それこそが事例のメーカーが大型受注を失った失敗の形でした。単一の基幹システムは計算を置き換えるのではなく、計算間の手作業の橋を置き換え、すべての数値を一か所に置き、すべての変更にタイムスタンプを付けて追跡可能にします。

大規模なERPプロジェクトの混乱は耐えられない。どう進めれば安全ですか。

フィット・トゥ・スタンダードの導入は、企業設定、取引先、製品、BOM、税率、支払条件をコーディングではなく設定で済ませるため、プロジェクトの範囲を限定的に保ちます。Kikan System は最大2ユーザーまで無料、クレジットカード不要で始められるため、まず自社のBOMと製造指図書をモデリングし、小さく検証してから本番に進めます。目標はスプレッドシートの癖を再現することではなく、清らかな標準を採用することです。

監査人や税理士は、複式簿記を土台にした一つのシステムを受け入れますか。

はい、たいていの場合むしろ好まれます。複式簿記が土台であり、売上請求書、支払請求書、経費精算はそれぞれ監査証跡を伴う型付きの仕訳を生成します。材料の消費、仕損、工数といった業務イベントは同じ監査可能なシステム内で帳簿と並んで捕捉され、業務イベントから総勘定元帳科目へのつながりは会計士と確認した意図的な手動仕訳となります。税理士の確定申告に向けたデータは清らかに構造化されますが、行政への申請や電子帳簿保存の認証は専門家にお任せします。

労務費や仕損は、基幹システムの中で自動で総勘定元帳に転記されますか。

いいえ。システムが捕捉するのは工数と仕損の事実であり、労務費や仕損を特定の原価科目に自動で載せるわけではありません。真の製品原価は、製造指図書が消費した材料、作業日報が捕捉した工数、そして労務を正しい原価科目につなぐ会計士確認済みの手動仕訳を組み合わせて組み立てられます。自動化されるのは事実の捕捉であり、会計上の判断は人の手元に残ります。

重要なポイント

この大阪の繊維機械メーカーから学べる教訓は、狭く実務的です。真の製品原価は、BOM、工数、簿記のいずれか一つを個別に改善して見つかるものではありません。三つすべてが一つの基幹システムの中に、同じ期間にあり、防御できる一つの数字へと組み立てられて初めて現れます。材料費は製造指図書から流れ、労務費は作業日報で捕捉され、労務を製品原価につなぐのは会計士と合意した手動仕訳です。突合が縮み月次決算が速くなるのは、すべての基になる数値がすでに一つのシステムにあるからであって、すべてのつながりが自動だからではありません。2025年のレガシーの崖、適格請求書等保存方式への移行、そして縮小する労働力に直面する製造業者にとって、単一の基幹システムこそが、防御できる原価数値と、言い訳でしか説明できない原価数値との違いです。

基幹システムは、まさにこの土台の上に構築されています。中核にある複式簿記、多階層BOMと材料を消費する製造指図書、作業日報で取得した工数、仕損を含む型付きの在庫操作が総勘定元帳と同じ一つのシステム内に並び、それに加えて企業ごとに設定可能な税設定と確定した期間をロックする決算実行です。労務費から原価、業務イベントから元帳へのつながりは手動仕訳のままですが、その基になる数値はすでに一か所にあります。もしあなたのBOM、工数、元帳を一つの基幹システムがどう扱うかを見たいなら、最も早いのは試すことです。

ご自身の目で確かめてみませんか

本日、Kikan Systemで無料ワークスペースを始めましょう。2ユーザーまで無料、カード不要で、ご自身の部品表をモデリングし、一連の帳簿を端から端まで実行できます。

(→ 無料で始める)(/#get-started)

クラウドかオンプレミスかで迷っているなら、クラウドERP vs オンプレミス：2026年の基幹システムモデルの選び方と、基幹システム導入のRFP作成ガイド：失敗しない要件定義が、その決断を一歩ずつ案内します。