結婚したての頃、ワンルームのアパートにすんでいた。部屋は12畳が一つ。ユニットバスと洗面台、玄関スペースを入れても15畳だ。遊びに来たアメリカの友人が、部屋を見て唖然とした表情をしたのをよく覚えている。彼らのスタンダードからは、ウサギ小屋どころかネズミ小屋に見えただろう。
わたし達はそのワンルームを、タンスなどの家具でパーティション的に仕切って、二つの部屋みたいに使っていた。ダイニングキッチンと、勉強部屋兼寝室である。二人とも仕事を持っていたので、互いに別のスペースがいるときもあるし、多少のプライバシーだって必要だ。その後、2回ほど引越しし、子どもが生まれて部屋数も増えたが、子どもが巣立つと不要な部屋は物置みたいになってくる。家族の増大や成長と共に、必要な部屋数は変わるのだった。
何の話をしているかというと、実はBOMの数についてである。2005年に発刊した「
BOM/部品表入門」で、わたしは次のように書いた。
IT担当者「・・率直におうかがいしたいのですが、本当はいくつBOMマスタを持つべきなのでしょうか？」
矢口助教授「そうですね。ところで、あなたのお住まいは、部屋数はいくつありますか。」
IT担当者「はあ？ それとBOMと何の関係があるんです？」
矢口助教授「お住まいを選ばれるとき、悩まれたはずです。２ＤＫか、３ＤＫか、はたまた３ＬＤＫか。あなたのご家族という『BOM』を入れる器として、何部屋が適当か。多い方が、家族それぞれに部屋を与えることができ、それぞれの都合や好みに部屋を使えて、便利です。でも、それだけ値段が高くなりますね。家族間のコミュニケーションも悪くなる。いっそのこと、大きなワンルームにするべきか。しかしそれだと、赤ちゃんが寝ているときに誰もＴＶを見られないし・・。」
IT担当者「・・ははあ、おっしゃりたいことがだんだん分かってきました。BOMのマスタの数は、利便性とコストのバランスから考えろ、と。こういうことですね。」
（第12章「情報技術から見たBOM」より。ただし発言者の名前は原著にはない。上では分かりやすいように補足した）
BOMのマスタの数をいくつ持てばいいか、正解はない。数が増えれば運用上の利便性は高くなるが、整合性を保つコストは幾何級数的に増える。だから自社のニーズにあった数を考えるべきで、それでも迷うなら、少なめの数から出発することをおすすめする、と書いた。この考えは、基本的に今でも変わらない。
中小零細の企業は別としても、中堅以上の製造業は普通、BOMデータを持っている。BOMは製造業の生産系における要（かなめ）で、多くのITシステムがBOMデータを必要とする。だからそれがなければ、業務が回らない。ただ、やっかいなのは、BOMデータが同じ会社に、2つも3つもあることだ。
なぜ一つの企業にBOMが複数あるのか？ 答えは、「それが（ローカルに）便利だから」である。ローカルに、とは、業務の大まかなくくりや部門単位で、という意味だ。ワンルームだと赤ちゃんが寝ているときにテレビが見られない。だから子ども部屋とリビングを区切ろう、という発想になる。設計部門が製品のBOMの中身をいじっているときにも、購買部門は主要な部品の発注数量を決めておきたい。だから別々に維持しよう・・といった事情だ。
ただし、部品表が複数存在するのは、これ以外にも理由がある。その一番大きなものは、カバー範囲の違いである。多くの企業では、設計部品表（Engineering BOM = E-BOM）と、製造部品表（Manufacturing BOM = M-BOM）を別々に持っている。この両者は、カバー範囲が違うのだ。
機械や電機などの組立加工業では、設計部門は最終製品の組立図や、それを構成するサブ・アッセンブリー組立図、そして個別の機械部品などの図面・仕様書を作る。それらの表現がE-BOMだ。だが部品を素材からどう加工製造するかは、生産技術部問の仕事になる。製造工程を設計するためには、部品加工の段階も必要だ。M-BOMは、この部分もカバーする。
（なお、これは組立加工業の話で、食品・化学・医薬品などは元々、原材料から出発して作り方を考えるから、このような分離はあまり聞かない）
またM-BOMでは、製造工程で消費する薬剤などの副資材や、製品の表面を保護する一次包装材なども登録する。それらが無いと、製造の仕事ができないし、原価の一部でもあるからだ。だから一般に、E-BOM < M-BOM というカバー範囲になる。
- 検討用の150% BOM、実行用の100% BOM
でも、それだけなら、素材や副資材や包材も、E-BOMに追加登録すれば良いはずである。だからわたしは、最初は一つのBOMから出発を、とすすめているのだ。だが、もう少し別の要因もある。それは「検討用」と「実行用」の区別である。
製品によっては、基本モデルにさまざまなオプションがつくケースがある。身近な例では乗用車とかパソコンを思えばいい。ユーザは、チャイルドシートだとかエアバッグだとかカーナビなど、選択肢の組合せの中から選ぶことができる。設計段階では、これら個別仕様に応じた部品構成を用意しておく。つまり、一つの製品を作るのに必要な部品だけでなく、可能性のある部品をすべて列挙し検討する必要がある。
近年はこのような可能性を検討したBOMを、「150% BOM」と呼ぶことが広まっている。100%以上、という訳だ。
ところが、生産管理や購買で使うBOMは、これではこまる。一つの受注オーダーで作る製品に、150%分の部品を用意するわけにはいかない。製造ではいわば「100% BOM」が個別に必要なのだ。これが、E-BOMとM-BOMが同居できない、もう一つの重要な理由である。
検討業務における「可能性」「べき論」の列挙と、実行業務における「現実」「これでいく」への限定。この両者が、業務では必要だ。検討段階では、異なる部品構成のケースを設定して比較したり、架空のシミュレーションも行いたい。しかし実行段階では、架空の話は不要だし、動いているシステムで勝手にそんなデータ変更をされたら迷惑だ。ある程度以上の規模の企業で、E-BOMとM-BOMが分離していくのは、そうした背景があるからだ。
さらに言うと、「べき論」と「これでいく」の区別は、前者をマスタ・データで規定し、後者をトランザクション・データに記録することで実現するのが望ましい。オブジェクト指向風の言い方でいえば、前者がクラス、後者がインスタンスということだ。これについては、すでに以前、「BOMデータのマスタと履歴を区別する」 で解説したのでここでは繰り返さない。
ただ、このように複数の目的別BOMを作っていくと、その間の整合性の確保が課題になっていく。すなわち、本当のBOMマスタはどこにあるのか（どれが派生したコピーなのか）、そして事実を一元的に記録したBOMトランザクション履歴はどこにあるのか、という問いである。
このような整合性確保は、当然ながら簡単ではない。ただ、はっきりしている事が一つある。それは、「BOMは複数あっても良いが、マテリアル・マスタは一つだけを共通に参照する」ことだ。（なお、マテリアル・マスタは「部品マスタ」「品目マスタ」などと呼ばれることもある）
ここがブレて、本社と工場が、あるいは営業と製造が、そして日本と海外子会社が、同じものを別のコードで呼んだりする状況は、断固として避けなければならない。個別の部署はそれで良いかもしれない。しかし、部門横断的なエンジニアリングチェーンもサプライチェーンも、もちろんアフターサービスも、実務が大変苦労するからだ。
ただ、そうしたBOMデータ不整合で生じる苦労は、実務レベルの人々が背負うものの、経営層はどこ吹く風で気づかなかったりする。そして時々、叫ぶのだろう。「なんでウチの現場は、生産性が低いんだ！ なんで何か聞いても、すぐ数字が出てこないんだ！」・・・
問題のあるところには、原因がある。経営の横断的機能が働かず、部門最適がはびこりすぎると、いつの間にか会社はタコツボ的データの集合体になる。12畳のワンルームを10個の小部屋に区切ったら、使い物にならないに決まっている。『データドリブン経営』をしたかったら、データ価値を理解する経営が、まず必要なのだ。
＜関連エントリ＞
「BOMデータのマスタと履歴を区別する」 https://mgt-technology.info/28544961/ (2019-08-28)
「BOMのレベルとは何か」 https://mgt-technology.info/33251771/ (2024-10-18)