多階層BOM（部品表）を基幹システムで管理する実践ガイド

もしあなたの会社の部品表がスプレッドシートにあれば、その苦労はすでにご存知のはずです。設計が一つの版を更新し、購買は別の版で発注し、在庫はまた別の版を持つ。数字がどうしても一致しない。多くの部品を組み立てて製品を作る企業にとって、部品表（BOM）は業務の背骨であり、その背骨がずれていれば、原価も資金も信頼も傷つきます。

本稿は、多階層BOMをExcelから基幹システムへ移すための実践ガイドです。現場の問題、具体的な事例、そしてBOM・在庫・会計が一つのデータでつながったとき何が変わるか、さらにそこへ至る具体的な手順までを順を追って解説します。

現場で起きている問題

部品表とは、製品を一つ完成させるために必要な構成部品、副次的な組立品、その数量を構造化して示したリストです。単階層BOMは直接の部品だけを並べます。一方、多階層BOMはより深く、組立品の中にさらに組立品を入れ子で定義します。たとえば完成した基板は、はんだ付けされたモジュールを含み、そのモジュールはさらに抵抗、コンデンサ、プリント基板を含む、といった具合です。

この入れ子構造は、現実の組み立て方をそのまま反映しています。問題は、多くの中小製造業がこれをモデル化していないことです。BOMをExcelで管理し、在庫・購買・会計を別々のツールや帳簿で持ちます。そこから三つの問題が生じます。

第一に、BOMが現実から乖離します。設計が代替部品に切り替えても、スプレッドシートは何週間も更新されません。購買は古い部品を買い続け、廃棄や消費は誰かが棚を数えに行くまで見えないままです。

第二に、原価が推測に過ぎなくなります。BOMと各部品の仕入単価が結びいていないと、完成品の真の原価は大まかな見積もりにしかなりません。利益率の低下に何か月も気づかれないケースもあります。

第三に、経理が月末に数字を手作業で組み直します。何を買い、何を消費し、何を廃棄したかを照合し、仕訳を一件ずつ起票します。日本の中小企業の多くは、こうした手作業の照合も一因となり、月次決算にいまだ一週間から二週間を要しています。

2025年の崖がこの紧迫感をさらに強めています。Windows Server 2012 R2、SQL Server 2014、そして多くの古いオンプレミスのERPがセキュリティサポートの終了を迎えました。中小企業は今、つぎはぎで維持するのではなく、基幹システムを刷新しなければならなくなっています。

具体的な事例

京都に本社を置く、従業員約75名の電子部品メーカーを考えてみましょう。同社は産業機器向けのカスタム電源モジュールを組み立てています。各モジュールは多階層の構成です。完成品は密閉ケース、実装済み基板、コネクタ、ヒートシンクで構成されます。実装済み基板はさらに、数十の表面実装部品、はんだペースト、プログラム済みのマイコンを含みます。

長年、BOMは一つの共有Excelブックにありました。設計がマスターのシートを持ち、購買は仕入先コードを書き込んだコピーを持ち、倉庫は在庫数を持つ三つ目の版を持っていました。誰が不注意だったわけではありません。同じ文書の異なるスナップショットを元に作業していただけです。

症状は現場で馴染み深いものでした。ある基板の改訂で、コンデンサをより耐圧の高い部品に差し替え、設計はそれを記録しました。しかし購買がそのメモに気づいたのは二週間後で、その間に古い部品を大量発注していました。古いリールが届いたとき、それは動きの遅い在庫となりました。

その間、完成モジュールの原価はじわじわと上がっていましたが、BOMが安価なコンデンサのまま価格計算していたため誰も気づきませんでした。経理が四半期を締めたとき、モジュールラインの粗利益率は6ポイントも下がっており、チームはその乖離を追跡するのに丸四日を費やしました。

最も深刻だったのは監査証跡です。取締役から、誰がいつ代替承認したのかと問われても、答えは名前もタイムスタンプもないスプレッドシートの一行しかありませんでした。より厳格なJ-SOX内部統制への準備を進める企業にとって、それは容認できるものではありませんでした。

何が変わるのか

多階層BOMを基幹システムに移すと、三つの壁が崩れます。

第一に、BOMが製品、在庫、原価と結びつきます。各部品は、カテゴリ、単位、既定の仕入単価を持つ一つの製品レコードになります。各副組立品は、それ自体が一つのBOMであり、親BOMの中に入れ子になります。ある部品の単価を変更すれば、それを使うすべての親の積上げ原価が更新されます。在庫は拠点や倉庫ごとに追跡され、移動は発生と同時に記録されるため、BOMが要求する数量と棚に実際にある数量が、ついに同じ言葉を話すようになります。

第二に、BOMの変更が下流へ波及します。設計がモジュールBOMのコンデンサを改訂すると、購買は次の発注で新しい要件を見ます。同じ改訂が原価の積上げに反映され、それが利益率のレポートに反映されます。更新を忘れる二つ目のスプレッドシートは存在しません。

第三に、消費と廃棄がそれぞれ明確な操作として記録されます。在庫操作は単なる在庫移動ではありません。消費は製造指図に対して構成部品を在庫から引き当てます。廃棄は独立した在庫引き出し操作として記録され、不良材は月末の曖昧な棚卸減耗の行に埋もれるのではなく、操作の記録として可視化されます。

タイムシートと勤怠で把握した作業時間は、同じシステムの中で製造指図の隣に置かれます。これで材料費と真の製造原価の間の乖離に向き合うための素地が整います。

そして仕訳そのものが最大の見返りです。複式簿記の基幹システムは、商取引の文書の背後にある会計仕訳を自動生成します。仕入請求書は買掛の仕訳を自動起票し、売上請求書や経費精算も同じように仕訳を起票します。一方で、BOM、製造指図、ロット、廃棄、作業時間といった業務データは、その複式簿記と同じ一つのシステムに並んで存在するため、全体像を一か所で把握できます。作業時間の計上や廃棄の償却といった業務上の出来事を特定の総勘定元帳の勘定に結びつけるには、経理担当者と確認のうえ手動仕訳を起票します。

トレーサビリティの面では、ロットとバッチの管理により、リコールや顧客からの問い合わせがあった際、完成モジュールを特定の基板に入ったコンデンサの正確なロットまで遡って追跡できます。この一つの機能が、何週間にも及ぶ調査作業を省き、仕入先から不良バッチの連絡があったときにブランドを守ります。

移行の手順

ExcelのBOMからシステム管理の多階層BOMへの移行は、コーディングのプロジェクトではなく、データとプロセスの作業です。基幹システムはカスタム開発ではなく、マスターデータを通じて設定します。以下は実践的なチェックリストです。

1. まずマスターデータを整備します。すべての構成部品、副組立品、完成品について一つの製品レコードを作成します。それぞれにカテゴリ、単位、既定の原価を割り当てます。整った製品マスターが、その後に立つすべての基盤になります。

2. 倉庫と拠点を定義します。システムが追跡すべき物理的な拠点をいくつにするか、どの移動を記録対象とするかを決めます。拠点別在庫は、その拠点が事業の実際の入荷、保管、消費の仕方を反映していなければ役に立ちません。

3. ボトムアップでBOMを構築します。最も低位の副組立品から始めます。それぞれに何が入るかを定義し、順に上へ進みます。親BOMは子BOMを参照するため、子が揃えば多階層構造は自動的に組み上がります。すべてを一つの長い部品リストに平たくしてはいけません。入れ子構造こそが存在意義です。

4. 各部品の原価基準を設定します。製品レコード上の既定の仕入単価か、保守された標準原価を使います。BOMが原価を自動的に積み上げるため、正確な部品原価は、追加の労力なしに正確な完成品原価を生みます。

5. 在庫操作の種類を整理します。どの操作が消費で、どれが移動で、どれが廃棄かを識別します。拠点間の移動は移動オーダーを使います。消費と廃棄はそれぞれ独立した在庫操作として記録されるため、これらの区分を正確にすることが、業務の記録を正確に保つ鍵になります。

6. 購買をBOMに結びつけます。各部品の製品レコードに、既定の仕入先、購買条件、税設定を置きます。BOMが購買要求を駆動するとき、正しい仕入先と、正しい購買税の勘定（支払った税金なので資産）をいっしょに引き出します。

7. 作業時間を製造指図と並べて把握します。各指図の隣に置かれるタイムシートと勤怠の入力を使い、作業時間が組み立ての原価の隣に同じシステム内で並ぶようにします。それらの時間を特定の原価勘定に結びつけるには、経理担当者と確認のうえ手動仕訳を起票します。

8. BOM変更の承認ワークフローを設定します。あらゆる改訂を、適用される前に、設計リード、原価管理者、あるいはマネージャーといった適切な役割へ回付します。各変更には承認者と承認日時が記録され、それがJ-SOXの内部統制が求める監査証跡になります。

9. 残りの移行前に、一製品を端から端まで通します。完成モジュールを一つ選び、その完全な多階層BOMを構築し、製造指図を起こし、部品を消費し、廃棄と労務を記録し、在庫残高が想定通りに動き、操作の記録が揃っていることを確認します。一つの対象でプロセスを整え、それから拡張します。

10. 古いスプレッドシートを凍結します。BOMがシステムに入り、その上で一度月次決算が回ったら、Excelのマスターを廃止します。二つのマスターを持ち続ければ、乖離は必ず戻ってきます。

よくある質問

システムは工場の生産スケジューリングも管理してくれますか。

いいえ。多階層BOM、製造指図、在庫、そして関連する仕訳は適用範囲内です。詳細な現場のスケジューリングや、完全な製造実行システム（MES）は別の領域です。基幹システムはBOM、原価、在庫のデータをきれいに構造化し、生産計画のチームがそのデータをスケジューリングのために使います。

BOMの変更は、手作業の再入力なしで購買や会計にどう伝わりますか。

BOM、製品、在庫、勘定が一つのデータモデルを共有しているからです。改訂された部品は親の積上げ原価を更新し、次の購買要求は最新の部品と仕入先を引き出します。仕訳が自動生成されるのは、仕入請求書、売上請求書、経費精算といった商取引の文書に対してのみです。部品の消費や廃棄の償却といった業務上の出来事を特定の総勘定元帳の勘定に結びつけるには、経理担当者と確認のうえ手動仕訳を起票します。

移行中、既存のExcelのBOMはどうなりますか。

それはシステムではなく、入力になります。製品レコードに整理し、入れ子を構築し、そして廃止します。目標は、基幹システムの中に、版の履歴と承認の記録を持つ、ただ一つの権威あるBOMを持つことです。共有フォルダに三つの矛盾するスナップショットを残すことではありません。

最も重要なポイント

多階層BOMは、つながって初めて効果を生みます。製品と結びつけば正確な原価を、在庫と結びつけば正確な有効性を、そして複式簿記のコアと同じ一つのシステムに並べば、BOM、製造指図、ロット、廃棄、作業時間が会計簿冊の隣に置かれ、経理はサイロをまたいで探すことなく全体像を一か所で把握できるようになります。これが経理に月末の日数を返します。

勝つ企業は、BOMを設計、購買、財務の共有の背骨として扱う企業です。他の誰もがコピーする設計の文書としては扱いません。2025年の崖と、より厳格な適格請求書発行事業者や内部統制の要請に直面する日本の中小企業にとって、問いはBOMを一元化するかどうかではありません。いつ一元化するか、です。

つながった基幹システムから始めませんか

基幹システムは、多階層BOM、拠点別在庫、製造指図、ロット管理、そして複式簿記の会計コアを一つの場所に集め、カスタムコードではなくマスターデータで設定できるようにします。原価は積み上がり、変更は購買へ波及し、業務データと会計簿冊が同じ一つのシステムに並びます。

2ユーザーまで無料、カード不要で始められます。

→ 無料で始める

基幹システムの選定と刷新に関する幅広い文脈については、クラウドERPの基幹システムの選び方と2025年の崖と基幹システム刷新をご覧ください。