
部品表(BOM)のエクセル管理の限界は、設計変更の版ズレと所要量計算の手作業化にある。単層/多層BOMの構成管理と数量展開、脱エクセルの判断基準までまとめる。
無料相談受付中いきなり作らない。
AIで何がどう変わるかを、先に見極める。
- ノーコードの卒業先、AIネイティブ受託。事業の文脈で要件から実装まで伴走
- 45分・Web。検討段階のご相談・資料だけでも歓迎。しつこい追客はしません
目次
- 部品表をエクセルで作るのは間違いではない、が限界線がある
- 単層BOMと多層BOMの違い、構成管理の実装知
- 所要量計算(親→子の数量展開)がエクセルで壊れる仕組み
- 設計変更(ECN)がBOMを壊す最大の変動要因
- エクセルBOM運用でしのぐための実務的な対策
- 脱エクセルの判断基準 生産管理システム・MRP・PLMへの移行
- まとめ
- よくある質問
- 部品表(BOM)をエクセルで管理する場合、単層と多層のどちらで作るべきですか?
- 所要量計算(親→子の数量展開)をエクセルで自動化するにはどうすればいいですか?
- 設計変更(ECN)が起きたとき、エクセルBOMの版管理はどう運用すればいいですか?
- BOMをエクセルからシステム化する場合、何を基準に判断すればいいですか?
- 関連記事
部品表(BOM)のエクセル管理はどこまで限界か 構成管理と所要量計算の実務
部品表をエクセルで作るのは間違いではない、が限界線がある
部品表(BOM)をエクセルで管理すること自体は間違いではない。問題は、単層の部品リストから多層の構成管理・所要量計算へと要求が膨らむ過程で、シート1枚の設計思想のままスケールさせてしまうことだ。限界が来るのは「部品点数が増えたとき」ではなく「設計変更(ECN)が版ズレを起こし始めたとき」である。
単層BOMと多層BOMの構成イメージ。階層が深くなるほどシート1枚の管理は破綻しやすい。
生産技術・購買の現場でよく聞くのは、「最初はA4一枚の部品リストで足りていたのに、いつの間にか複数シートを跨いだ参照だらけになり、誰も全体を把握できなくなった」という声だ。これは設計であり運用の失敗ではなく、単層の発想のまま多層の要求に応えようとした構造の限界である。ここから先は、その限界がどこで・なぜ来るのかを、実装レベルの仕組みで分解する。
単層BOMと多層BOMの違い、構成管理の実装知
単層BOMは「製品→部品」の1対多、多層BOMは「親品番→子品番」の連鎖構造」で、後者は正規化されたテーブル設計が前提になる。
単層BOMは、1つの製品に対して必要な部品と数量を横一列に並べるだけで成立する。試作段階や部品点数が数十点程度なら、この形で十分に運用できる。問題は、ユニット→サブアセンブリ→部品のように組み立てが2階層・3階層と深くなったときだ。単層の発想のままシートを増やすと、「サブアセンブリBという中間品目が、複数の親製品から共通で参照される」ような多対多の関係を表現できなくなる。
多層BOMを正しく管理するには、品目マスタ(品番・品名・単位)と構成マスタ(親品番・子品番・数量)を分離したテーブル設計が必要になる。これはリレーショナルデータベースの正規化そのものであり、エクセルのシート構造とは相性が悪い。VLOOKUPで親子関係をたどることは可能だが、同じ子品番が複数の親から参照される「共通部品」が出てきた瞬間に、数式のコピペでは対応しきれなくなる。
所要量計算(親→子の数量展開)がエクセルで壊れる仕組み
所要量計算は親品目の必要数量に子品目の員数を掛けて積み上げる展開計算で、階層が深くなるほど数式の複雑度が指数的に増える。
所要量計算とは、例えば「製品Aを10台作るには、サブアセンブリBが10台×員数2=20個必要」というように、親の必要数から子の必要数を掛け算で展開していく計算だ。2階層なら=親必要数*員数の単純な数式で組める。だが3階層になると、孫品目の必要数は「親の必要数×子の員数×孫の員数」という掛け算の連鎖になり、さらに同じ孫品目が別の枝からも参照される場合は、複数経路の必要数を合算しなければならない。
SUMPRODUCTやSUMIFで階層ごとの積算を組むこと自体は技術的に可能だが、実務で見てきた範囲では、4階層を超えたあたりから数式のメンテナンスコストが急増する。誰か1人がその複雑な数式構造を理解している状態(いわゆる属人化)になりやすく、その担当者が抜けた瞬間に誰も直せなくなる。これは所要量計算というロジックの性質上、エクセルの手組み数式では吸収しきれない複雑さだ。
親の必要数×員数で子の必要数を展開する所要量計算のメカニズム。階層が増えるごとに数式が複雑化する。
自社のどの工程が最も所要量計算の負荷を受けているか、実は当事者ほど気づきにくい。初月無料の経営AI診断では、こうした構成管理・所要量計算の負荷が実際にどこに集中しているかを可視化し、改善の優先順位を一緒に整理している。
設計変更(ECN)がBOMを壊す最大の変動要因
設計変更(ECN)の伝達が現場・購買まで届く前に旧版のBOMで動いてしまう「版ズレ」が、エクセルBOM運用における最大の事故要因になる。
BOMは一度作って終わりではなく、設計変更のたびに更新され続ける生きたデータだ。ここでエクセル運用の弱点が露呈する。ファイル名に「rev3」「最新版」といった手動の版管理を入れても、その最新ファイルがメールやチャットで共有されるまでのタイムラグの間に、現場が旧版を参照して作業指示書を作ってしまったり、購買が旧版の員数で発注してしまったりする「版ズレ」が起きる。
受託開発の現場で相談を受ける中小製造業(従業員数十〜百名規模が多い)では、この版ズレによる「発注し直し」「作業のやり直し」が典型的なパターンとして頻出する。改訂履歴をシート内のコメント欄に書き込むだけの運用では、誰が・いつ・どの箇所を変更したかを後から追跡することが難しく、変更の影響範囲(その部品を使っている他の製品)を洗い出す仕組みも存在しない。エクセルには「この改訂が確定した瞬間に関係者全員へ通知する」機能がなく、版管理は最終的に人の記憶と口頭確認に依存することになる。
設計変更の伝達が遅れ、現場・購買が旧版のBOMを参照してしまう版ズレの構造。
エクセルBOM運用でしのぐための実務的な対策
版ズレと所要量計算のミスを完全には防げないが、改訂履歴の一元化と参照ルールの固定化で発生頻度は下げられる。
システム化する前段階でも、被害を小さくする運用は組める。まず、BOMファイルは1箇所(共有ドライブの固定パス)にしか置かず、ローカル保存・メール添付での二次配布を禁止する。次に、改訂履歴を専用シートに「改訂番号・日付・変更箇所・変更理由・承認者」の5項目で必ず記録し、旧版は上書きせず別ファイルとして残す。そして、構成マスタと品目マスタを分離し、品目情報(単価・調達先)は品目マスタ側でのみ更新する運用にする。
これらは根本解決ではなく、あくまで「エクセルのまま延命するための運用ルール」だ。改訂履歴の記録自体を人間の善意に依存している以上、記録漏れや更新忘れは一定確率で発生し続ける。運用ルールを厳格化するほど、現場の入力負荷とチェック工数は増えていく。この工数が、システム化した場合の月額費用を上回り始めた時点が、実質的な損益分岐点になる。
改訂番号・日付・変更箇所・承認者を記録した改訂履歴シートの運用イメージ。
脱エクセルの判断基準 生産管理システム・MRP・PLMへの移行
部品点数が数百点を超える、設計変更が月5件以上発生する、在庫と連動した引当・所要量計算が必要になる、のいずれかが移行の分岐点になる(仮説・要検証)。
生産管理システムやMRP(資材所要量計画)、PLM(製品ライフサイクル管理)は、まさにここまで述べてきた「多層の構成管理」「所要量計算の自動展開」「改訂履歴とアクセス権限の一元管理」を標準機能として持っている。MRPは在庫数・発注残・リードタイムを加味した所要量計算を自動で回し、PLMは設計変更(ECN/ECR)の承認フローと影響範囲の追跡を一体で扱う。
移行の判断は、部品点数や階層数だけで決めるものではない。実務で見るべきは「エクセルの運用ルールを守るための工数」と「版ズレ・所要量ミスによる手戻りコスト」の合計が、どの程度の速度で増えているかだ。この工数が横ばいならエクセルの延命で問題ない。増加傾向にあるなら、次の3ステップで移行を検討するとよい。1つ目は現状のBOM運用でどの工程に工数が集中しているかを棚卸しすること。2つ目はMRP/PLMの必要機能(所要量計算の自動化か、改訂管理の強化か)を絞り込むこと。3つ目は自社の構成管理データを移行できる形に整理することだ。
工数の棚卸し→必要機能の絞り込み→データ整理という移行判断の3ステップ。
どの機能から着手すべきかは、部品構成の複雑さや設計変更の頻度によって現場ごとに異なる。初月無料の経営AI診断では、自社のBOM運用の現状を可視化した上で、移行が必要かどうかの判断材料まで一緒に整理している。
まとめ
部品表(BOM)のエクセル管理は、単層構成・少ない設計変更のうちは合理的な選択だ。限界が来るのは部品点数の多さそのものではなく、多層の構成管理と所要量計算の展開、そして設計変更(ECN)の版ズレという3つが重なったときである。改訂履歴の一元化やアクセスルールの固定化で延命は可能だが、それを維持する工数が手戻りコストを上回り始めたら、生産管理システムやMRP/PLMへの移行を検討するタイミングだ。
部品表の運用工数と手戻りコストのバランスを見極めることが、脱エクセルの判断基準になる。
よくある質問
部品表(BOM)をエクセルで管理する場合、単層と多層のどちらで作るべきですか?
構成部品が2階層以内で試作・小ロット中心なら単層エクセルBOMで十分機能する。ただし、ユニット→サブアセンブリ→部品のように3階層以上の親子関係があるなら、シート1枚の単層管理は早晩破綻する。多層BOMは「親品番・子品番・数量・単位」を1行1レコードで持つ正規化構造にしないと、所要量計算のたびに手作業の掛け算が発生し、転記ミスの温床になる。
所要量計算(親→子の数量展開)をエクセルで自動化するにはどうすればいいですか?
VLOOKUPやINDEX/MATCHで親子関係をたどり、SUMPRODUCTで階層ごとの必要数量を積算する構造は組める。ただし4階層を超えると数式が複雑化し、循環参照や更新漏れのリスクが跳ね上がる。実務では2〜3階層までが手組みエクセルで安全に運用できる上限で、それ以上はMRP機能を持つ生産管理システムへの移行を検討すべきタイミングになる(目安・要検証)。
設計変更(ECN)が起きたとき、エクセルBOMの版管理はどう運用すればいいですか?
ファイル名に改訂番号と日付を入れ、変更点をシート内の改訂履歴欄に記録する運用が最低限必要になる。ただし、変更が現場の作業指示書や購買発注に反映されるまでにタイムラグが生まれやすく、旧版のまま部品を発注してしまう「版ズレ」事故が起きやすい。改訂履歴の一元管理とアラートの仕組みがないなら、ECN発生頻度が月数件を超えた時点でシステム化を検討すべきだ。
BOMをエクセルからシステム化する場合、何を基準に判断すればいいですか?
目安として、部品点数が数百点を超える、設計変更が月5件以上発生する、在庫システムと連動した引当・所要量計算が必要になる、のいずれかに該当したタイミングが移行の分岐点になる(仮説・要検証)。これらは生産管理システムやPLMが標準機能として持つ領域で、エクセルの数式で再現しようとするとコストが急増する。
関連記事
- 町工場・製造業のAI活用 見積と図面対応と一次問い合わせを自動化する実践ガイド — 関連: 製造業のAI活用全般
- 製造業の在庫管理改善事例 エクセル脱却で欠品・過剰在庫を減らした進め方 — 関連: 在庫連動の実例
- 生産管理をエクセルで回す方法と限界 脱エクセルのタイミングと移行ステップ — 関連: 生産管理全体の限界論
- 在庫管理エクセルのマクロ化はどこまで有効か VBAの限界と脱エクセルの分岐点 — 関連: エクセル延命策の限界
- 中小企業のAI導入 費用相場と内訳 初期費用から運用コストまで実例で解説 — 関連: システム化の費用感(横断クラスタ)
「まず費用感だけ知りたい」という方へ。
1分で概算費用がわかるシミュレーターをご用意しています。
よくある質問
- Q. 部品表(BOM)をエクセルで管理する場合、単層と多層のどちらで作るべきですか?
- A. 構成部品が2階層以内で試作・小ロット中心なら単層エクセルBOMで十分機能する。ただし、ユニット→サブアセンブリ→部品のように3階層以上の親子関係があるなら、シート1枚の単層管理は早晩破綻する。多層BOMは「親品番・子品番・数量・単位」を1行1レコードで持つ正規化構造にしないと、所要量計算のたびに手作業の掛け算が発生し、転記ミスの温床になる。
- Q. 所要量計算(親→子の数量展開)をエクセルで自動化するにはどうすればいいですか?
- A. VLOOKUPやINDEX/MATCHで親子関係をたどり、SUMPRODUCTで階層ごとの必要数量を積算する構造は組める。ただし4階層を超えると数式が複雑化し、循環参照や更新漏れのリスクが跳ね上がる。実務では2〜3階層までが手組みエクセルで安全に運用できる上限で、それ以上はMRP機能を持つ生産管理システムへの移行を検討すべきタイミングになる(目安・要検証)。
- Q. 設計変更(ECN)が起きたとき、エクセルBOMの版管理はどう運用すればいいですか?
- A. ファイル名に改訂番号と日付を入れ、変更点をシート内の改訂履歴欄に記録する運用が最低限必要になる。ただし、変更が現場の作業指示書や購買発注に反映されるまでにタイムラグが生まれやすく、旧版のまま部品を発注してしまう「版ズレ」事故が起きやすい。改訂履歴の一元管理とアラートの仕組みがないなら、ECN発生頻度が月数件を超えた時点でシステム化を検討すべきだ。
- Q. BOMをエクセルからシステム化する場合、何を基準に判断すればいいですか?
- A. 目安として、部品点数が数百点を超える、設計変更が月5件以上発生する、在庫システムと連動した引当・所要量計算が必要になる、のいずれかに該当したタイミングが移行の分岐点になる(仮説・要検証)。これらは生産管理システムやPLMが標準機能として持つ領域で、エクセルの数式で再現しようとするとコストが急増する。
あわせて読みたい





