設計が出図した部品表と、製造が使っている部品表が一致しない——多くの製造業で日常になっている光景です。設計部品表（E-BOM）を製造部品表（M-BOM）へ変換する作業が特定の担当者のExcelに依存していると、設計変更のたびに転記・照合・確認が発生し、生産計画も調達も原価も、その人の作業待ちで止まります。本記事では、BOM変換が人手のままになる構造を情報・人・プロセスの3層で分解し、業務の土台をデータとしてそろえる「業務OS」の考え方で、どこまで改善できるかを整理します。

E-BOMとM-BOMとは？なぜ部品表が二つに分かれるのか？

結論から言えば、部品表が二つ存在すること自体は正常です。E-BOM（Engineering BOM：設計部品表）とは、設計者が図面やCADから出力する、製品の機能構成を表した部品表です。一方、M-BOM（Manufacturing BOM：製造部品表）とは、工程設計を経て「どの工程で・どの順に・何を組み付けるか」という製造視点で再構成した部品表です。設計は機能のまとまりで考え、製造は工程と手配のまとまりで考えるため、同じ製品でも部品表の階層構造は変わります。

問題は二つあることではなく、二つの間の「変換」が構造化されず、人手の転記に依存していることです。次の章でその構造を分解します。

なぜE-BOMからM-BOMへの変換は人手のままなのか？

変換が人手に残る理由は、担当者の怠慢でも意識の問題でもありません。情報・人・プロセスの3層に分けると構造が見えます。

情報の層では、変換ルールが形式知になっていません。塗装や熱処理など工程で発生する中間品の追加、支給品と購入品の読み替え、共通部品のまとめ方——こうした判断基準は、変換用のExcelマクロや個人のメモに散在し、本人以外は参照できません。人の層では、設計の図面と製造の工程の両方を読める人がそもそも少なく、変換業務がその数名に集中します。プロセスの層では、変換が「出図後の一括作業」として後工程に置かれているため、設計変更が出るたびに差分が飛び込み、割り込み作業として積み上がります。

設計変更との相性の悪さは深刻です。設計変更通知（ECN）の伝達漏れを扱った過去記事では、こう指摘しました。

4つの分類のうち1つでも穴があれば、漏れは構造的に発生します。一つを潰しても、漏れは残りの3分類に移動するだけです。

設計変更通知の漏れが品質トラブルにつながる構造——情報・人・プロセスの分解

BOM変換はこの「漏れの通り道」の最下流にあります。ECNが漏れなく届いても、M-BOMへの反映が人手であるかぎり、反映漏れ・転記ミスという最後の穴が残ります。

変換の遅れは何を止めるのか——前提を置いた概算で見る

影響範囲を概算してみます。前提として、部品点数600点の装置を扱い、設計変更が月20件発生し、1件あたり影響部品の特定・転記・照合に平均30分かかると置きます。この場合、変換・照合だけで月10時間、年間120時間が「設計する」でも「作る」でもない転記作業に消える計算です（前提を変えれば増減する概算値です）。さらに誤転記が1件でも手配に流れると、欠品・二重発注・ライン停止として跳ね返り、金額影響は工数の比ではなくなります。

見落とされがちなのは原価への影響です。設計段階の原価を扱った過去記事では、次のように述べました。

材料の選定、加工方法、公差、部品点数といった原価の大半は、図面を引いた瞬間にほぼ固定されます。

図面はできたのに原価は「作ってみないと分からない」——設計段階で製造原価が見えない構造と、原価をそろえる順番

原価の実態はM-BOMの構成が確定して初めて計算できます。変換が遅れるほど、原価が見えるタイミングも後ろにずれ、「作った後に分かる」状態から抜け出せません。

業務OSでそろえられる範囲——変換ルールをデータとして持つ

業務OSとは、部門ごとに分断された業務データと判断ルールを、横断して参照・再利用できる形でそろえる業務基盤の考え方です。BOM変換に当てはめると、目指す状態は「変換ルールが担当者の頭の中ではなく、データとして存在し、差分照合は機械が行い、人は例外だけを判断する」ことです。順番は次の3段階です。

1. 変換ルールの棚卸し。現担当者が行っている読み替え・中間品追加・まとめの判断を、対象部品の条件とセットで書き出します。ここはヒアリングと過去の変換実績の突き合わせが中心で、ツールは不要です。
2. ルールをデータとして持つ。棚卸しした判断基準を「E-BOM側の条件→M-BOM側の変換結果」の対応表として構造化します。生成AIは、過去のE-BOMとM-BOMのペアから読み替えパターンの候補を抽出したり、ECNの文面から影響部品の候補を提示したりする用途で使えます。ルールの正否を決めるのはあくまで人です。
3. 差分照合の自動化。E-BOMの変更差分に対して、対応表から機械的にM-BOM側の修正候補を提示し、人は対応表にない例外だけを判断します。照合を機械に寄せ、判断を人に残す分担です。

この順番を飛ばしてシステム導入から入ると失敗しやすい理由は、量産立ち上げのノウハウ標準化を扱った過去記事の指摘と同じです。

属人化は意志の問題ではなく、引き継ぐべき情報をどこにも構造として持っていないことの結果です。

新しいラインの立ち上げが毎回ゼロからになる——量産移行のノウハウが標準化されない構造と、生産技術OSで蓄積・再利用する順番

変換ルールという「引き継ぐべき情報」を構造として持たないまま器だけを入れ替えても、属人化は器の外側に残り続けます。

「PLMやERPを入れれば解決」ではないのか？

もっともな疑問です。実際、PLMはE-BOMの、ERPや生産管理システムはM-BOMの置き場として機能します。しかし多くのパッケージにおいて、両者の間の変換ルールそのものは標準機能の外にあり、導入時の個別設定か、結局は人手の運用に委ねられます。マスタ整備と変換ルールの棚卸しを伴わない導入は、「二つの部品表が、二つのシステムに分かれて残る」結果になりがちです。逆に言えば、変換ルールを先にデータ化しておけば、既存のPLM・ERPを入れ替えずに、その外側で差分照合を仕組み化する道が取れます。自社の変更頻度と品種数を踏まえ、どの層から手を付けるかを見極めることが先です。

自己診断チェックリスト

次の5項目のうち2つ以上当てはまる場合、BOM変換の属人化を個人の頑張りではなく構造の問題として扱うサインです。

• E-BOMからM-BOMへの変換手順を、担当者以外が文書ベースで説明できない
• 変換に使うExcelやマクロが個人フォルダに置かれている
• 設計変更のたびに「M-BOM側の直し漏れがないか」を確認する会議・照合作業が発生している
• 変換担当者の不在時に、手配や生産計画の起点が遅れたことがある
• E-BOMとM-BOMの不一致に起因する手配ミス・欠品が年1回以上起きている

FAQ（よくある質問）

E-BOMとM-BOMは統合して一つにすべきですか？

無理に一つへ統合することは推奨しません。設計と製造では部品表に求める構造が本質的に異なるためです。現実解は、二つの部品表を保ちながら、間の変換ルールをデータとして構造化し、差分照合を自動化することです。

多品種少量の中小規模の工場でも問題になりますか？

なります。影響の大きさを決めるのは部品点数の絶対数よりも、設計変更の頻度と品種数です。品種が多いほど変換ルールの分岐が増え、担当者の頭の中への依存度はむしろ高まります。

最初の一歩は何から着手すべきですか？

変換ルールの棚卸しからです。現担当者が無意識に行っている読み替え・追加・まとめの判断を、条件とセットで書き出すことが出発点になります。ツールやシステムの選定は、ルールが言語化された後で十分間に合います。

次のアクション

自社のBOM変換がどこまで属人化しているか、外から測るのは難しいものです。ファースト・オートメーションでは、設計から製造までの業務フローを分解し、どの層から手を付けるべきかを整理する30分の業務診断を無料で提供しています。チェックリストに2つ以上該当した方は、現状の変換フローをお聞かせください。

次に読むべき記事

• 図面はできたのに原価は「作ってみないと分からない」——設計段階で製造原価が見えない構造と、原価をそろえる順番
• 生産計画が特定のベテランしか立てられない構造——需要・材料・段取りが一人の頭でしか繋がらない理由と、生産技術OSでそろえられる範囲
• 設計変更通知の漏れが品質トラブルにつながる構造——情報・人・プロセスの分解

出典

• 経済産業省「ものづくり白書」（開発・設計段階でのコスト決定に関する知見）: https://www.meti.go.jp/report/whitepaper/mono/
• 本文中の工数試算は、記載した前提（部品点数600点・設計変更月20件・1件30分）に基づく概算値であり、実測データではありません。