それは仕様ですか、性状ですか？ 〜 マスタ構築に見るデータ・リテラシーの勘所

• モノのマスタ・データは、どの部署が登録維持すべきか
  

先日あるところでBOMに関するお話をしたところ、聴衆の方から興味深い質問を受けた。

「BOMのマネジメントでは、マテリアル・マスタを全社で共通に使うことが大事とのお話、確かにその通りだと思いました。自分の会社では、ERPのマテリアル・マスタに品目を登録するのは製品設計部門の仕事ですが、どうもいろいろと問題が起きています。マスタ登録の仕事は、どこの部門が担うべきだとお考えですか？」

ものづくりに関わるマスタ・データの登録保守は、製造業の組織で、一体どこが受け持つべきなのか。これは「データ・ドリブン経営」だとか「製造DX」などの活動を現実化していく上で、重要な問いだろう。さらに一般化していえば、『マテリアル・マネジメントの業務』は、どこが責任を引き受けるべきなのか。皆が悩んでいる問題だ。

ただ、質疑の時間は限られていたし、この方がどの業種か良く知らなかったので、「一般論ですが」という但し書きをつけて、お答えした。

「結論から言いますと、部品などの品目の登録は、製品設計部門よりも生産技術部門の方が適していると思います。なぜなら製品設計部門は、部品の具体的な作り方については、あまり詳細を知らないのが普通だからです。それを知っているのは、製造方法と生産工程を決める、生産技術部門です。」

新規登録すべき部品について、買ってくるのか作るのか、作るなら何からどう作るのか、他の似た部品と何が違うのか。そうしたことが判断できないと、マスタを適切に登録管理できない。もちろん組織の形や機能は、企業によって違うし、生産技術部門がない会社だって存在する。だからこれが唯一の正解だと言うつもりはないが、ヒントにはなっただろうと想像する。

• 品目コード問題があぶり出す、基本的データ・リテラシーの欠如
  

同じ仕様の部品だが、異なるサプライヤーから納入されるモノは、区別して登録すべきなのか。同一モデルだが仕向地が国内と海外の場合は、別のコードを立てるべきなのか。購入品と自社で内製する場合は、区別すべきか。これらは、品目コードに関してよくたずねられる質問である。

こうした疑問が積もり重なっていくと、本社と工場で違うマスタを維持したり、設計部品表（E-BOM）と製造部品表（M-BOM）が乖離していく問題が生じがちである。同じ一つの会社の中で、本社と工場が、あるいは事業部と事業部の間で、同じ筈のモノを、別の品目コードで呼んでいる事態が非効率で不合理なことは、誰でも分かる。分かるのに、しばしばそうした状況が放置されている。

「しょせん、コード程度の問題」と、たかをくくっているのかも知れない。製品戦略とか、拠点展開とか、情報システム・アーキテクチャ変革といった、高度な問題に比べれば、マイナーな問題、と（外資系戦略コンサルだったら、きっとそう言いそうだな）。

だが、わたしの見方は違う。マテリアル・マスタ（品目マスタ）に関する問題を、あちこちの会社で聞くにつけ、これは日本企業における基本的な『データ・リテラシー』に関する、ある種の欠如を表しているのだと感じるようになった。

データはあらゆるシステムの基礎、基本である。計算機内のデータは普通、キーとなるID（識別コード）と、その属性の値の並び、という形式になっている。ところが、その属性データが、仕様なのか性状なのかについて、曖昧になっている。というか、属性データは基本的に、「仕様」と「性状」に区別される、という原則の理解（リテラシー）が、ユーザ一般に欠けているのだ。

いや、下手をしたら、データの専門家であるITエンジニアさえ、理解できていない可能性さえある。そんな状態で、データ・ドリブン経営など（それが何を意味するにせよ）あったものではあるまい。

• モノのデータには二種類ある
  

モノを扱うデータには二種類ある。一つは、「機能（要件）」に関するデータ、もう一つは、「物体（実在）」に関するデータである。

たとえば自動車には、前後で4つの車輪がある。4つの車輪は、別々の機能を持っている。ただし、そこに装着 (install)される物体は、全部同じタイヤである。物体としてのタイヤは、前後左右で、交換可能である。

機能のキーは、機械図面でいえば①②といった番号（俗にいうフーセン）であり、プラント業界の用語でいえばTag No.である。SAP R/3ではこれを抽象化して"Functional Location"と呼んでいた。他方、物体のキーは、Serial No.やLot No.である。

当然、キーがちがうのだから、もつ属性の意味も全然別のものである。同じ「内径」でも、前者は「4mm以内であること」という要件が規定され、後者は「測ってみたら内径3.9mmでした」という現実が記載される。

「このモノはかくあるべし」と規定した条件が、「要求仕様」Required specificationである。一方、「このモノは実はこんなです」と、（測定結果を）記述したのが「供給性状」Supplied propertyだ。前者が「機能（要件）」に関するデータ、後者が「物体（実在）」に関するデータになる。

そして、製造とはまさに、この「機能」と「物体」とのlinkを生成する行為に他ならない。

「機能」的なモノは観念や設計図の中にのみ存在して、目には見えない。目に見えるのは、個別の「物体」である。もしそう呼びたければ、前者はクラスであって、後者はインスタンスと言ってもいい。あるいは西洋哲学風に言えば、前者はイデアであって、後者は個物にあたる（そう、ITの認識論の背後にはつねに西洋哲学がある）。

• マテリアル・マスタとは何を記述したデータか
  

さて、それでいったい、マテリアル・マスタとは、どちらを記述したデータの集合なのか。機能（要件）なのか、物体（実在）なのか。

ここで、「従業員マスタ」はどうなのかな、などと考えると、興味深いかも知れない。従業員マスタは、従業員コードがキーになって、氏名だとか生年月日だとか教育履歴だとかいった属性値が並んでいる。そう、具体的に存在するインスタンス、個物（いや個人）のデータである。

だったら、マテリアル・マスタも実在する物体のデータではないか！　などと考えるかもしれぬ。だが、答えはまったく逆なのだ。マテリアル・マスタとは、目に見えぬ、実在しない、要件の集合なのである。

どうしてか。それはまさに、部品表（BOM）データを考えてみれば分かる。部品表はいわば、組織図だ。BOMは部品と部品の従属関係を表している。BOMで参照する部品コードの元が、マテリアル・マスタである。

たとえば、企業における組織図を考えてみてほしい。仮にあなたが部長職になって、担当役員から「自部門の望ましい組織図を設計しろ」と言われたら、書くのは、“技術部長－機械設計課長－設計第二係長”・・という職名（はたすべき機能）の図だろうか？　それとも、“佐藤部長－鈴木課長－田中係長”・・という人名を並べた図だろうか？　

答えは当然、前者であろう。人の名前は変わりうるし、異動や退職もするかもしれない。だが職名（あるべき機能）と、その間の従属関係は変わらない。職名は、存在しない・抽象的な・機能につける標識である。人名は、実在する・具体的な・個物（個人）につけられた名前だ。組織を設計するとしたら、機能（職務）とその関係を設計するのであり、その参照先である職務リスト（＝モノの世界では品目マスタに相当する）は、抽象的な職務とその記述が並ぶのだ。

同様に、マテリアル・マスタとは、“必要なマテリアル”の名称と属性が並んでいる表をあらわす。すなわち、「要求仕様」の一覧表なのである。存在しない抽象的なモノ（＝要求仕様の集合体）を列挙したテーブルなのだ。

ここまで理解できれば、異なるサプライヤーから納入されるモノは、別に登録すべきかどうか、わかるだろう。それらがどちらも自社の要求仕様を満たしているなら、その二つは同一のマテリアルである。無論、価格や納期は違うかも知れない。だがそうした属性は、マテリアル・マスタではなく、（品目コードと調達先コードを複合キーとした）調達情報マスタに記述すべきである。

同一モデルで、仕向地が国内と海外の場合、もし満たすべき仕様が異なるのなら、別のコードを立てるべきである。購入品と自社で内製する場合、製造上で差が無いなら（互換性があるなら）区別は不要である。

なお念のため書くと、実際の供給性状を記録したければ、それは製品品質を製造ロット番号やシリアル番号に紐づけた履歴データに記録すべきである。それはそれで、もちろん有用だ。だが、マテリアル・マスタとは、別ものである。

こうした、「仕様」と「性状」の違いは、もちろんエンジニア達には「いわれてみれば当たり前」であろう。違和感はないと思う。ただ、それをデータ化する際、どちらに該当するのかが曖昧だと、後々そのデータを利用しようとする人にとって混乱の元となりがちだ。

そして、こうしたことは、データに関するリテラシーの基本に属するのだ。わたしが常日頃、「ITリテラシーよりも大切なのは、データ・リテラシーである」と主張しているのも、こうした非効率を避けたいがためなのである。

＜関連エントリ＞

　 (2022-07-09)