同じモノか、違うモノか？ － マテリアルの同一性問題をめぐって

同じモノか、違うモノか？ － マテリアルの同一性問題をめぐって
（2016/02/29）

前回、「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」
を書いた後で、この分野の専門家の方々と少しやりとりがあり、わたしのつかったBOMという言葉に分かりにくい点があったかな、と気づかされた。そこで今回は補遺として、用語を明確にすることからはじめたい。

一般に、『BOM』という言葉は、三つの意味を持っている。それは「BOMデータ」「BOMデータベース」「BOMソフトウェア」だ。同じ一つの問題の、三つの側面といってもいい。

BOMデータとは、部品表（業界によっては「材料表」）の内容そのものである。データというのは、数字や文字の規格化・定型化された並びのことである。BOMデータとは、マテリアルの数量的な関係を示した一覧表で、たとえそれが手書きでも、Excelの表の形でも、きちんと業務でハンドリング可能な形になっていたら、BOMデータと呼べる。ただし、誰かの頭の中にあるだけで、形式化されていない状態では、まだデータとはいえない。（なお、データと情報の違いについては『ＩＴって、何？』の「質問2：　『ＩＴを理解している人を見分けるにはどうしたらいいの？』」
を参照のこと）

「BOMデータベース」とは、コンピュータの中に形式化されて保存されているデータを指す。データベースは、ご承知の通りマスタ・データと履歴（トランザクション）データに、さらに区分することもできる。BOMデータベースは、その両者の形態があり得る。

「BOMソフトウェア」とは、主に上記BOMデータベースを処理する情報システムのことだ。製造業ではBOMはいろいろな業務に関係するから（設計・購買・製造・保守・原価など）、いろいろな業務系システムがBOMソフトウェアとなり得る。とくに、BOMデータベースの維持管理を主目的としたソフトウェアをつくる場合、それは「BOMプロセッサ」と呼んで区別することにしている。

このサイトでは今後、上記の三つを、可能な限り区別して使うことにする。たとえば前回「どんな製造業でもBOMはある。ただし、BOMをきちんとマネジメントしている企業は少ない」と書いた。これは、より正確には、次の意味である：

「どんな製造業にもBOMデータはある。だがBOMデータをマネジメントしている会社は少ない。」

たとえば、製品を自前で製造している会社なら、ふつうは必ずP-BOM（購買部品表）データをもっている。これがなければ部品材料を仕入れられないからだ。もしもその会社が、よくセットメーカーにあるように、部品は全て外部から購入し自社では最終組立・検査のみを行う業態の場合、

　P-BOMデータ＝M-BOMデータ

でもある。自社内で加工・製造を行う業態の場合、工程ごとに展開されたM-BOMデータをもっているはずである。そうでなければ、各工程に製造指図書（製造オーダー）を発行できないからだ。ただし、その企業が構造型の「BOMデータベース」を持っているかどうかは不明だが。

また、設計機能のある会社なら、必ずE-BOMデータはある。それは組立図面の上のたんなる表かもしれないが、データではある。

（小うるさいことを書くようだが、念のために注釈。製造業の裾野は非常に幅広い。製品を自前で生産しないメーカーというのも存在する。製造を全て外部委託している会社だ。具体的には、一部の電子機械メーカー、開発型医薬品メーカー、そして多くのアパレルメーカーなど。出版社もこれに近い。また、自社で設計をしない製造業は、中小下請け部品メーカーに非常に多い。それから、化学・食品産業などではBOMという言葉はあまり使わず、「レシピ」概念がそのかわりにある。ただ、混乱を避けるため、わたしの話はデフォルトで「組立加工型・繰返し生産形態・生産管理中心」で書いている。日本ではそういう企業の裾野が一番広いからだ。読者諸賢は、ご自分の業種業態にあった形で翻案しながら、お読みいただきたい）

さて、BOMデータをきちんとマネージするためには、普通はBOMデータベースが必要だ。他方、上述のようにBOMソフトウェアは業務目的別に複数持つ場合もある。たとえば設計業務用ソフトと、生産管理用ソフトのように。もちろん両者が一つのソフトウェアで済むなら、それに越したことはない訳だが、現実にはなかなか難しい。そういう意味で、E-BOMソフトウェアとM-BOMソフトウェアが別々にあるケースは珍しくない。同一のBOMデータベースから、異なる表現形式としてE-BOMとM-BOMを取り出す例もあるだろうが、あるいは物理的に別々なDBかもしれない。

では、わたしが前回述べた、「E-BOMとM-BOMの乖離問題」とは何のことなのか？　それは、データ内容の乖離の話である。設計部門と生産部門が維持・参照しているBOMデータの中身が、だんだんと食い違ってくる。それが社内で様々な問題を引き起こしているのである。たとえばユーザからクレームが入った。保守部門が対応すべくアクションを起こす。ところが調べてみると、設計図面とは別の部品が使われている。あるいは、工場内で部品の欠品が起きる。本社資材部門は正しく手配済みのはずだった。だが工場では当該部品とは別の部品を使用することが恒常化していた・・。こうした不便がいろいろと起こりうるのだ。

そしてBOMデータ内容の中心は、マテリアル・コードである。マテリアル・コードとは部品材料を特定するキー・コードのことで、会社によっては部品番号とか品目コードとよぶ場合もあるだろう。ある部品のマテリアル・コードは何か、その子部品のコードは何か、がBOMデータの中心部分である。BOMデータの乖離とは、同じ製品を構成するはずのマテリアル・コードが、設計部門と生産部門で次第に食い違っていく事態を意味する。甚だしい場合は、両者でまったく異なるコード体系をもっている。まあ、仮に異なるコード体系であっても、その間に1対1の対応関係があるなら、まだいい。その対応関係が次第にずれて1対NやN対Nになっていき、機械的な変換ができなくなるから、こまるのだ。

なぜそのような乖離が起きるのか？　それは、異なる部門間で、ある品目が同一であるか、違うモノかで意見が異なってしまうからなのだ。

例を挙げよう。ここに、「岩手産の牛乳１L瓶」と、「十勝産の牛乳２Lパック」 があったとする。この両者は、同じモノなのか、違うモノなのか？

仮にあなたが、ある食品メーカーで、マテリアル・マスタの管理者だったとする。お好みなら、SAPのMMかなんかでもいい。そこにユーザから、上のような質問があった。どう判断するべきだろうか？

見た目に明らかに違う物品だから、別のコードで登録すべきだ、などと結論にジャンプしてはいけない。慎重なあなたは、ためしに、社内の関係者に質問してみることにした。

あなたの会社にはチーズ製造部門がある。そこの購買課に見解をたずねると、こう答えた。

「乳脂肪含有率が重要だ。産地が違えば区別が必要だ。いや、季節によっても品質は変動する」。

一方、あなたの会社はレストランもチェーン経営している。そこの仕入係の見解はこうだ：

「コップに注いでしまえば産地も容器も関係ない。要冷蔵かどうかだけが重要だ。」

片方は別のモノだと答え、もう一方は区別の必要はない、という。

二つのものが同一物かどうかは、会社によって違い、部署によっても違う。つまり、ものの見方によって違うのだ。そこには、第三者が客観的に決められる厳密な基準はない。では、『モノの見方』を規定するカギは何なのか？

こたえは単純だ。同一と見なせるかどうかは、「キーとなる属性」が同一かどうかで決まるのだ。キーとなる属性とは、業務上の要求仕様のことであり、マテリアルの使用目的によって決まる。チーズ製造部門にとってキーとなるのは乳脂肪含有率であり、レストランにとっては保管方法だった。だから、使用する企業・部署ごとに見方は変わるのである。どちらが正しい、どちらが間違っている、ではない。ただし、企業として統一したマスタを持つのなら、そこには基準が必要だ。そして、それは区分がむやみに増殖しないような基準であってほしい。

たとえば、「設計上は同じ仕様だが、サプライヤーが異なる物品」はどう扱うべきか？　もしも製造組立でまったく互換性がある場合は、両者は同一のモノである。
でも、価格や納期が異なるとしたら？　その場合、サプライヤーに依存する属性は、品目マスタではなく、「購買情報マスタ」に登録するのが定石なのだ（
「購買情報マスタ」は、マテリアル・コードと取引先コードを複合キーとするマスタである）。

あるいは、「設計上は同じ仕様だが、荷姿や入り数や保管方法が異なる物品」は？ 　その場合、物流側の情報システムで、SKU（Stock
Keeping Unit）として区別するのが定石だ。

そのような形の工夫を重ねることで、マテリアル・マスタの品目数がずるずると膨張し、類似したデータが増えて1対N風の状態になることを防ぐことこそ、BOMデータをマネジメントする際の要諦なのである。

わたしの接してきた経験では、残念ながら多くの企業が、このような判断基準を社内的に確立していない。そもそも購買情報マスタだとかSKUだとかいうことさえ、理解されていない。こうした事情の背景には、部門同士の距離感があるのだろうと感じる。各部門がサイロのようになって、部門単位で最適化された業務フローを持ち、それに応じて情報システムを作ってしまう。結果として、本社設計部門の管理する部品マスタと、工場の製造部門のつかう品目マスタの対応関係が、乖離してくるのである。これを称して、E-BOMデータとM-BOMデータの乖離という。

これを防ぐためにはどうしたらよいか？　原因が単純である以上、解決法も単純だ。社内の複数部門を横断する「マテリアル・マネジメントのためのコミッティー」を形成し、そこで基本指針を定め、各種情報システムの要件にも口をはさむ。個別の事案の判定は、実務担当チームを任命してあたらせる。このようにすべきだろう。

拙著「BOM/部品表入門」では、社内の10以上の部門が横断的に集まるBOM検討ワークショップによばれた、外部アドバイザーの矢口先生が、各部門の担当者に順番に質問を発していくという形式で書いた。それは、上に述べたような問題意識があったからだ。マテリアル・マネジメントは、非常に多くの部門にまたがる課題である。だから、部門の垣根を越えて話し合う仕組みがどうしても必要なのだ。

単純だ。だが、難しい。単純なことほど実現の難しいのが、会社というものだろう。そしてそのために、マネジメントという機能が存在するのである。