「どのBOMが最新版か分からない」「部署ごとに別々の部品表を持っている」——心当たりがあるなら、それはBOMが分断しているサインです。本記事では、部門別のExcel運用からBOM分断がなぜ起きるのかを解き明かし、版管理と「単一の正しい情報源」をどう実現するかを整理します。設計BOMと製造BOMのズレという、見落とされがちな問題にも具体例で踏み込みます。
1. BOM管理でこんな状態になっていませんか
結局どれが最新版かわからなくなる
BOMの版管理ルールを決めていたとしても、ちょっとした忙しさなどで「マイルール」でファイル名をつけてしまうことがあります。後から振り返ると「自分ではわかっているから大丈夫」と過信していたと思うのですが、「_最新版」「_final」「_修正版2」などをついつい使ってしまいます。似たような名前のBOMファイルが複数存在すると、結局どれが最新なのかわからなくなり、ファイルの中身を細かく確認したり、メールのやりとりを見返したりと、時間がかかってしまいます。
古いバージョンを他部署に渡してしまう
最新版がわからなくなって困るのは、自分だけではありません。BOMの技術情報は個人で完結するものではなく、部門内や部門間で共有するものです。最新版を取り間違えて共有してしまうと、たとえば設計変更したはずなのに調達・製造には古いBOMが渡ってしまい、意図した変更が反映されていない製品ができあがってしまう危険があります。細心の注意を払っていても、人の作業である以上、取り違えの可能性はゼロにはなりません。そして一度起きると、影響は自部署だけにとどまりません。
同じ製品なのに、部門間で部品の数量などが微妙に食い違う
製品の設計変更は珍しいことではなく、その都度BOMを更新しなければなりません。ただ、ちょっとした数量の変更だったりすると、「他部署への共有は後でも大丈夫」と思ってしまいがちです。他に対応すべき業務があると、どうしても手間の少ない作業は後回しにされます。そうして設計部門で更新されたBOMが調達・製造部門に共有されず、部品の内容や個数に微妙な差異が生じてしまいます。多めに調達される分には在庫が増えるだけで済みますが、部品が少なかったり違ったりすると、製造できない・製造が遅れるといった問題に直結します。
過去のBOMを資産として流用しづらい
BOMの管理が徹底されていないと、後からある製品のBOMを探そうにも、どれが最新版・最終版なのかわからない、という問題が起きます。最終版でないBOMは、何らかの意図で加えられた変更が反映されていないことを意味します。それと気づかずに流用や参考にすると、また同じ問題にぶつかり、同じ修正を繰り返すことになります。「これは最終版だ」と確信を持って作業できないと、また問題が起きるのではないかという不安がつきまといます。
「正しいBOM」がベテラン頼みになっている（属人化）
BOMの管理が属人化していて、ベテランに聞かないと「正しいBOM」がどれか分からない、というケースもあります。こうなると、そのベテランがボトルネックになります。お伺いを立てるのが苦手な社員からすると、声をかけること自体がストレスになり、どうしても作業が後回しになってしまいます。そして、その人が異動・退職してしまえば、正しいBOMの在りかが誰にもわからなくなる、という組織的なリスクにもつながります。
2. なぜ「最新版がわからない」が起きるのか（原因の分解）
これらの問題は、BOMが部門ごとにコピーされて流通する、という運用構造から生まれます。具体的な原因を見ていきましょう。
原因1：BOMマスターが存在しない
BOMが部門ごとに共有されると、「〇〇部署から来たBOM」として保存され、部署内用のBOMに転用されます。転用している際に他部署にBOMの変更をお願いしたいとなると、他部署に依頼して、新たな「〇〇部署から来たBOM」を待つ必要があります。進め方として間違っているわけではないのですが、後から振り返る際などに「〇〇部署から来たBOM」が大量に検索ヒットし、結局どれが正しいのかわからなくなります。部署間で特定のフォルダなどにBOMマスターを保存しておくと、このような問題は解決に近づくのですが、今度はBOMマスターの管理方法という新たな問題が発生するのも事実です。各部署でどんな変更があればBOMマスターを更新するのか、誰がBOMマスターの最終変更を承認するのか、などです。
原因2：更新が手作業で他のファイルに波及しない
紙やExcelでBOMを管理していると直面するのが、1つのBOMファイルを更新しても、他の関連BOMファイルが更新されないという問題です。単純な部品数の更新だとしても、E-BOMを更新したりM-BOMを更新したりと、複数ファイルを更新しなければいけません。他の部品や他の工程に影響するBOM更新では、その更新作業は複雑を極めます。自分に権限のないファイルや他部署のBOMであれば、担当者に更新の依頼をかけなければならないという手間と気苦労もあります。
原因3：版のルールが複数存在するが統一できない
BOMのファイル名をどのように管理するか、命名規則をどうするかは非常に悩ましい問題です。個々人で好む命名規則は異なるし、部署で設定されたルールも異なることがあります。中途入社のメンバーがいれば、前職で使っていたルールが全く違う、といった問題もあります。全社として統一の命名規則を決めて運用するのが当然良いのですが、それを監視し遵守させる体制を整えるのは非常に大変です。他社とのやりとりですでにルール化されていたり、他のシステムでの運用上決まっていたりと、社内だけの問題で収まらない可能性もあります。そうすると命名規則が曖昧になり、メンバー依存になってしまいます。結果、BOMの過去資産の活用が難しくなります。
原因4：設計BOMと製造BOMのズレが放置されている
設計BOM（E-BOM）と製造BOM（M-BOM）はそれぞれ目的が違うので、中身の構成が異なるのは当然です。しかし、同じ製品のBOMであれば、共通すべき項目は当然あります。つまり、E-BOMが更新されればM-BOMにも更新すべき項目があります。しかし、原因2に記載のとおり手作業でのBOM更新が抱える問題があり、E-BOMの更新がM-BOMに反映されていない、というあってはならないことが起こり得ます。致命的な問題を抱えたM-BOMのまま製造に進むと、最悪の場合、不良品や納品先からのクレームにつながります（設計BOM・製造BOMの違いは「BOMとは」で解説しています）。
たとえばノック式ボールペンで、ノック部品の素材変更に合わせてE-BOMのバネが変更されたとします。ところがM-BOMでは、旧バネを前提にした組立工程の副資材（グリス）がそのまま残っている——E-BOMだけを見ても、M-BOM側のこのズレには気づけません。調達は新バネを、現場は旧グリスを前提に動き、組立段階になって初めて発覚します。
3. まず自力でできること
ここまでBOM管理が抱える問題を見てきました。これらの解決のために、まずは何をすべきかを見ていきましょう。PLMツールを入れなくても取り組める運用はあります。
命名規則・版管理ルールを決めて全部門で統一する
ファイルの命名規則やバージョン管理方法は、早めに決めて統一しておきたいところです。たとえば「製品A_EBOM_v012_20260706.xlsx」のように「連番＋日付」だけで新旧が決まる形にし、「最新版」「final」「修正版」のような相対的な言葉は禁止します。「_（アンダーバー）」や「-（ハイフン）」などの挿入の仕方もルール化するとよいでしょう。ルールを決めるだけでなく、部門横断で1つに統一することが肝心です。仮運用期間・フィードバック期間・実運用期間と分けて実施していきます。
BOMマスターを作り保管場所を明確にする
BOMマスターを設置し、保管場所を明確にすることも重要です。「困ったらこのファイルを参照する」という運用になっていれば、BOMの内容に不安があった場合などに、参照してすぐ確認できます。BOM管理の属人化の解消にもつながる、効果の大きい運用です。これがいわゆる「単一の正しい情報源（Single Source of Truth）」の考え方で、システム化した後もこの原則は変わりません。
部署内・部署間での変更時の連絡・承認フローを明確にする
BOMの変更があった際の、部署内外への連絡・承認プロセスを整備しておくことも運用上とても重要です。連絡・承認プロセスがないと、どの連絡を信頼してよいのか、本当に正しい更新なのかを迷ってしまうことがあります。「この人からの連絡なら信用できる」「その承認プロセスを通っているので大丈夫」と思えることは、次の作業を進めるうえで大きな後押しになります。
これらの運用は、徹底されて初めて効果が現れます。どうしてもメンバー依存になるため、限界があるのも事実です。とくにメンバーや拠点が増えるほど、人の注意力に頼った運用は限界に近づきます。そこで次に、こうした限界を仕組み（システム）でどう補えるのかを見ていきます。
4. システムでの運用ではどう変わるか
BOM管理の運用が自力で難しいとなると、次の解決方法はシステムでの運用です。こうした運用をシステム側で支えるのが、PLMをはじめとする仕組みです。どのような特徴があるのかを見ていきましょう。
単一のBOMマスターを一元管理し、版を自動で管理する
システムの特徴の1つが、決めたルールの徹底です。マスターファイルの管理方法、命名規則、バージョン管理方法など、さまざまなルールをシステムの運用開始時に定義して決めます。システムは例外を基本的に認めないので、ルールはシステム上で徹底され、それを使うユーザーにも徹底することを求めます。作業が標準化されるので、BOMマスターを確実に管理でき、バージョン管理も半自動化されます。
更新・変更を他のBOMに自動で波及させ、関係部門へ自動周知する
システムの導入時には、運用ルールだけでなく、部門間でのBOMの連携方法（たとえばE-BOMとM-BOMの連携）も定義します。部門内でどんな承認プロセスを経れば他部門にBOMを連携してよいのか、どのようなBOM構成を他部門に連携するのかを決めます。部門によって求めるBOMの形が違うので、相手の求める形にBOM構成を変換して連携できると、部門間の連携がスムーズになります。また、BOMの連携方法が決まっていれば、一部のBOMに変更があった場合、他のBOMにどのような影響が出るのかはほぼ把握できている状態になります。つまり、1つのBOMでの変更・更新を他のBOMに波及させやすく、誰に連絡すればよいかも明確なので、周知が非常に簡単になります。
「誰が・いつ・なぜ変えたか」の履歴を残せる
システム運用の優れている点は、各作業に必ずユーザー名（ログインアカウント名）が紐づき、何時にどの作業を行ったのかを記録しやすいことです。これはBOMの履歴管理という観点から非常に重要で、誰がいつどのBOMのどの項目を更新したのかを管理できることを意味します。1回の変更・更新作業に対して1つのバージョンが管理され、履歴が蓄積されるので、後から履歴を追跡することも可能です。トラブルなどがあった際の原因究明にも非常に便利です。
これを担うのが、PLM（や、ERPとの連携）のシステムです。ただし、いきなりすべての機能を導入するとメンバーへの負担が大きいので、自社の課題と規模を見極めて、効果の大きいポイントからシステム導入を進めるのが定石です（PLMの詳細は「PLMとは」で解説しています）。
5. まとめ：どこから手をつけるか
BOM管理における分断は、命名規則と版管理が統一されていないこと、そしてBOMマスターが整備されていないことが大きな原因です。まずはルール化を徹底し、自力で解決に取り組むことが第一歩です。そして、限界が来たらシステム化、という流れがよいでしょう。
いきなりシステム化という選択肢もありますが、その場合、システム導入時の要件定義における理解度が低いまま進んでしまう可能性があります。自力で取り組むことで、ルールの徹底がいかに難しいかが身にしみてわかり、システム化によって受ける恩恵をより深く理解でき、より突っ込んだ要件定義が可能になります。自力での取り組みは遠回りに見えるかもしれませんが、システム導入の基礎になっていると捉えるとよいでしょう。
- 設計変更そのものの混乱 →「設計変更（ECO/ECR）の管理が回らない」
- 一元管理する仕組みの詳細 →「PLMとは」
- BOMの種類と違い →「BOM（部品表）とは」
- 自社に何が必要かを課題から逆引きする →「製造業システムの選び方」