BOMのデータ構造（の入り口を、ちょっと）考える

• BOMデータベースの基本構造

「ウチの会社にはBOMがないんです」「そろそろ、BOMを作らなきゃと考えていまして」といった台詞を、ときどき製造業の方から、お聞きすることがある。きっと何か、誤解があるんだろうなあ。聞くたびに、そう思う。

BOMはBill of Materialの略で、材料表ないし部品表のことである。材料表がなかったら、製造業は外から部品材料を買ってくることができない。何も仕入れずに、モノを製造することはできない。だから、どんな製造業でも、必ずBOMは持っているはずなのである。

ただ、上記のような言い方をする人たちは、おそらく「ウチの会社にはBOMデータベースがないんです」「そろそろ、BOMソフトウェアを作らなきゃと考えていまして」と考えておられるんだと想像する。今は、手書きのFAXやExcelシートで仕事を回している。しかしそろそろ、もう少し近代的なITのやり方に切り替えたい、と。

そこで意思疎通の誤解を避けるため、わたしはBOMに関する用語を、次のように区別することを、かねてから提案している。すなわち、BOMのデータ、データベース、ソフトウェアの区別である。

1.「BOMデータ」：　表になっている状態。Excelや手書きも含む

2.「BOMデータベース」：　コンピュータに形式化されている状態

3.「BOMソフトウェア」：　BOMデータベースを処理するITシステム。BOMプロセッサと呼ぶこともある

『データ』とは、元々、「定型化された記号の並び」を指す。だからここでは、Excelや手書きも、意識して定型化されている限りは、データに分類している。でもまあ、普通はコンピュータの中にデータベース化しないと、効率的な処理はしにくい。

では、それはどのようなデータ構造になるのだろうか。ちょっと考えてみよう、というのが今回のテーマだ（いつものことだが、イントロが長いな・・）

ちなみに、わたしは拙著『 BOM/部品表入門』を書いた際に、DBの論理スキーマを示すことは、あえて避けた。BOMの世界はバリエーションが複雑で、企業によって必要とする深さも異なるため、妙に一般論を示しても役に立たないからである。でもまあ、ここではその入り口、もっとも基本的なところだけを、少し考えてみたい（ITが専門でない方にも役に立つ程度に、書くつもりである）。

なお、BOMにはマスタデータとトランザクションデータの2種類があり、ふつうは両方が必要だが、ここではマスタの方を考える（なぜトランザクションBOMデータが必須かの理由は、拙著P.23「Q: BOMは何種類お持ちですか」などを参照されたい）

さらにBOMとしては最も一般的な、「A型」BOMを考える。A型BOMというのは、複数原材料（醤油・酢・ゴマ油・砂糖）を集めて中間材料（タレ）を作り、さらに中間材料や部品（麺・錦糸玉子・キュウリ・チャーシュー）を組み合わせて、最終製品（冷やし中華）ができあがる、というような食品系、あるいは組立系の機械・電機などに多いトポロジー類型である。（いいかえると化学反応のような、複数原料から複数生成物ができる「X型」BOMや、製鉄・ガラスのような、製品が原材料にリサイクルされる「Q型」は対象外とする）

• BOMデータの基本構造

そして、BOMデータベースは普通のリレーショナル型DBを用いるとしよう。いや、俺はnon-SQLの方が好きだとか、最近流行りのGraph DBの方が樹形構造は表現しやすいぞ、とか考える向きには、ご自由に設計をお任せしたい。ここでは、業務系システムでの利用を考えて、ありきたりのRDBを想定しておく。

BOMデータの一番基本的な構造は、親子関係の1対による表現である。つまり、

「親部品Aを作るには、子部品aがN個必要である」

という関係を表現するデータ構造が基本だ。すなわち、BOMデータベースの基本は、シングルレベル表現である。親の品目コードと、子の品目コードと、その間の数量関係（「員数」と呼ぶ習慣になっている）の、3データ項目が最低限、記述できなければならない。

そして、品目コードとその属性が並ぶ「マテリアル・マスタ」（品目マスタ・部品マスタと呼ぶ場合もある）の存在が、まず前提になる。その上で、一種のサブ・テーブルとして、BOMを考える訳である。そうなると、2種類の考え方が可能だ。

一つめは、親の品目コードと、行番号ないし単純な連番を、複合キーにとったサブ・テーブルを作る方法だろう。つまり、

親品目A - 1番目：子部品a、員数N個、他の属性…

親品目A - 2番目：子部品b、員数M個、他の属性…

親品目A - 3番目：子部品c、員数L個、他の属性…

　・・・といった感じのデータが並ぶことになる（下線のついている項目がキー値で、これらはテーブル内でユニークでなければならない）。もちろん員数の後ろには、さらに他のデータ項目が並ぶ。これを、かりに『行番号方式』とよぶことにする。

こういうデータ構造は、機械組立図をベースに、BOMを登録したりするときに便利である。組立図には各部品に、いわゆる「風船」（引き出し線と丸数字）が記入されていて、そのリスト（番号と部品名と員数）が、図面の横の方についている。この表の構造に類似しているからだ。

もう一つの考え方は、親子の品目コードを複合キーとする方法だ。この場合、

親品目A - 子部品a：員数N個、他の属性…

親品目A - 子部品b：員数M個、他の属性…

親品目A - 子部品c：員数L個、他の属性…

　・・・といったデータになる。この場合、別に組立図とか風船は、なくてもいい。「冷やし中華のBOM」を作る場合、わざわざ組立図は作らないだろう。そういう製品分野だって、たくさんある。こちらは『ペア方式』とよんでおこうか。

• 二つの方式を比較する（そして、BOMデータは生き物である）

さて、設計に複数の選択肢がある際は、そのプラス・マイナスを考えるというのが、よい習慣であろう。

『行番号方式』の設計の良い点は、何だろうか。たとえば、行番号（連番）がついていいるので、入力した順が分かりやすい事かもしれない。また、表示順をユーザが制御しやすい面もある。『ペア方式』の設計では、別途「表示順」のようなデータ項目を用意して、ユーザが入力編集できるようにしてやらないといけなくなり、ちょっとだけ手間ではある。

その代わり、『行番号方式』が単純な連番だと、あとから順序の途中の所に追加で行を挿入する、といったことができなくなる。それはとくに、親に対する子部品の数が多くなった場合に、やっかいだろう。

・・でも、そうしたことはマイナーだ。むしろ比較検討上で考慮すべきは、BOMデータの変更である。BOMは生き物であって、設計変更と共に、いろいろと変わっていく可能性がある。子部品aが、子部品zに入れ替わったとき、どうするか。

『行番号方式』だと、1行目の子部品の品目コードを、aからzに直接、更新することになる。それでもいいが、そうするとその時点でマスタの内容が変わってしまう。だから、「翌月から変更」といった計画的変更のためには、何かバッチ処理を別に組まなければならない。

『ペア方式』ならば、親品目A - 子部品a と、親品目A - 子部品z という2レコードの一時的な共存が可能になる。だから「有効期限」のような属性項目を作っておいて、月末になると条件判断で自動的に切り替わる処理が、可能になる。

だが、あるいは子部品aが、a1とa2の二つの部品に変わったら、どうか。そして二つの部品が一体化して、一つの部品になったら。一つ言えるのは、こうした設計変更が頻繁に起きる場合、「どこの部位の部品が、いつ、どう変わったのか？」が分かりやすいようにすべきだ、ということであろう（変更がめったに起きないなら、そんな心配は無用だが）

従って変更が多いケースでは、『行番号方式』で行く場合でも、単純な連番はさけた方が良さそうだと分かる。10番刻みにして、途中に追加可能にする、などの工夫がいるだろう。もう少し言うと、この「行番号」というのは、実は親部品の中に子部品が占める「部位」「機能要素」のIDなのである（これを設備系BOMではFunctional locationないしOperational locationなどと呼ぶ）。

• 属性データの種類

ついでに少し、その他の属性データ項目についても考えておこう。

まず員数には、セットで「UOM」（Unit of Measure＝係数単位）がいる。つまり、個数とかccとかgといった単位である。わたしの生きているエンジニアリング業界にはしばしば、ポンド・ヤード系とか、石油の「バーレル」とか、言語道断な単位系が登場する。だから場合によっては、相互変換の計算機能も必要になるかもしれない。

BOMにおいて親子関係をつなぐのは、製造プロセスを表す「工程」（または複数作業からなる「工順」）のIDである。このIDは、同一の親部品にぶら下がる子部品では、すべて共通になるよう、注意を要する。そして、MRPで使用するBOMならばさらに、工程のロットサイズと標準リードタイムの項目が必要である。

さらに、改廃に関する項目がある。上でも述べたように、BOMには変更がつきものだ。変更履歴を過去に渡って、ずっと追いかけられるようにしたいとしたら、改訂番号、改廃年月日などが必要になる。その場合、行番号方式であろうがペア方式であろうが、改訂番号は複合キーの一部になっていなければならない。

いずれにせよ、BOMデータベースのシングルレベル表現では、親部品と子部品の品目コードを、マテリアル・マスタの外部キーとして参照する構造になる。だから、BOMデータベースにはマテリアル・マスタが必須、ということになる。実はここが重要なポイントで、BOMデータとは、マテリアル・マスタという土台の上に乗っかる建物なのである。

ともあれ、こう見てくるとシンプルな例でも、BOMデータベースのスキーマは案外、単純ではない、ということだ。そして現実に応用するには、それなりのバリエーションにも対応できるようにしなければならない。

例えば、「代替部品」はどう表現するか、考えてみられたい。代替部品とは、本体の製品自体にはあまり影響しないが、複数の部品の選択肢が可能なケースである。冷し中華に乗せる細切りチャーシューは、三枚肉の場合も、肩ロース肉の場合もあるだろう。これが代替部品だ。普通の顧客は、どちらを乗せてもとくに文句は言うまい。だが作る側からすると、製作時間も原価も違うのだ。

・・でも読者の中には、「寒くなってきたから冷し中華の話は、もういいや」とお考えの方もおられるかもしれない。うむ、わたしもそろそろ、そう思っていたところだ。

＜関連エントリ＞

「BOMのレベルとは何か」 https://brevis.exblog.jp/33251771/ (2024/10/18)