タイム・コンサルタントの日誌から:A5 BOM（部品表）

お知らせ：来る6月19日に、BOMに関する1日セミナー（有償）を開催します

Tomoichi_Sato — Sun, 11 May 2025 13:43:21 +0900

ある市場調査によると、日本国内では、PLMの方がERPよりも、売上高が大きいのだそうです。PLMとはProduct Lifecycle Managementの頭文字で、主に製品開発・設計業務の統括に使われるソフトです。22年の売上高は約2,900億円とのことで、あの高価なERP（統合業務パッケージ、同年度で約1,600億円）よりも市場規模が大きいというのです。ERPは全業種で使うのに対し、PLMは自社で製品を開発する製造業だけが対象ですから、ちょっと驚きませんか。

つまり製造業では、それだけ設計開発業務を大切にし、そのIT化・DX化にお金をつぎ込んでいる訳です。もちろんそれ自体は結構なことですが、一方で、PLMの実際の適用範囲はCADデータ管理が中心だ、との声も聞こえます。PLMが本来うたい文句とする、設計から生産準備、生産、そして保守・廃棄まで、「製品のライフサイクル全体」とのギャップが大きいのは、なぜでしょうか？

前回の記事で、「長引く日本社会の低迷の理由は、考える力と決断する力の低下にある」と、書きました。それでは日本の製造業の、長引く低迷の理由は何か。いろいろな仮説がありうるでしょうが、わたしなら、これを挙げます：

「市場環境は多品種化した受注生産に移行しているのに、量産型・見込生産の仕組みやマインドセットを残したまま業務を続けている」

量産型・見込生産のマインドセットとは、具体的に何でしょうか。それは、たとえばBOM/部品表でいうと、「一つの製品には一種類のBOMが対応し、なおかつ、BOMはあまり変わらない」という考え方です。

一つの製品モデルにオプションも仕様のバリエーションもないのなら、たしかにBOMはワンセットあれば済みます。また滅多に変わらないのなら、別に変更管理の仕組みもいりません。ややこしいデータベース化などしなくたって、Excelの表でも仕事は回るでしょう。

そういう時代が過ぎてしまったことに、ようやく気づいたから、最近は「150%BOM」だとか「逆展開」だとかを実現できるPLMシステムに、ニーズを感じるようになったのかもしれません。でも、ちょっと待ってください。エンジニアリングチェーン側で必要だからと、一つの製品にマルチのBOMを登録できても、サプライチェーン側はどうなるでしょうか。製造部門は、製造に不要な多数の部品まで、部品展開で出てきたらこまってしまいませんか？

製造業において、BOMは幅広い業務部門が関わる、一種の『情報のハブ』的な存在です。BOMをデータベース化し、その構成や機能を考える際には、多面的な業務視点からの考察が必要です。ところが多くの製造業では縦割りのサイロ化した組織が、これを阻んでいます。上で述べた、「考える力」の低下です。それはどこから生じたかというと、サイロ化です。では組織がなぜサイロ化したかというと、「決める力」が弱まったから、責任回避のために役割単位で自己防衛しようとしてきたためです・・

わたし達はこの不毛なサイクルから脱却し、よりスマートで、環境変化に適応能力の高い製造業への道を、進み始める必要があります。設計は設計、製造は製造、お互い自己都合の中で最適化、という状況を終わらせて、組織全体に必要なBOMの情報構造は何か、一緒に考えませんか。

なお、わたしが行うBOMのセミナーには、一つの特徴があります。それはBOMだけでなく、その根本である部品マスタ＝マテリアル・マスタについて、きちんと理解してもらうセクションがあることです。マテリアル定義のために必要な概念と原則、ならびに品目コード化について、演習を含めたディスカッションを行います。ここが高度成長時代のセンスのままだと、じつはBOMが社内でガタつくのです。他のセミナーにない特徴だと自負しています。ぜひご来聴ください。

＜記＞

「BOM／部品表の基礎とBOM構築のポイントおよび応用テクニック」

日時：　2025年6月19日(水) 10:30 ~ 17:30
主催：　日本テクノセンター
会場：　〒163-0722　東京都新宿区西新宿二丁目7番1号
　　　　　小田急第一生命ビル22F セミナー

内容詳細および申込み：　下記をご参照ください
https://www.j-techno.co.jp/seminar/seminar-68962/
（コンテンツ項目および説明順序は、参加者のニーズに応じて多少変える場合があります）

有償のセミナーですが、大勢の方のご来聴をお待ちしております。

佐藤知一

いくつBOMを持つべきか、一元化か多種類か？

Tomoichi_Sato — Fri, 11 Apr 2025 11:22:54 +0900

いくつ部屋を持つべきか

結婚したての頃、ワンルームのアパートにすんでいた。部屋は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が同居できない、もう一つの重要な理由である。

BOMの増殖と乖離を防ぐには
検討業務における「可能性」「べき論」の列挙と、実行業務における「現実」「これでいく」への限定。この両者が、業務では必要だ。検討段階では、異なる部品構成のケースを設定して比較したり、架空のシミュレーションも行いたい。しかし実行段階では、架空の話は不要だし、動いているシステムで勝手にそんなデータ変更をされたら迷惑だ。ある程度以上の規模の企業で、E-BOMとM-BOMが分離していくのは、そうした背景があるからだ。
さらに言うと、「べき論」と「これでいく」の区別は、前者をマスタ・データで規定し、後者をトランザクション・データに記録することで実現するのが望ましい。オブジェクト指向風の言い方でいえば、前者がクラス、後者がインスタンスということだ。これについては、すでに以前、「BOMデータのマスタと履歴を区別する」で解説したのでここでは繰り返さない。
ただ、このように複数の目的別BOMを作っていくと、その間の整合性の確保が課題になっていく。すなわち、本当のBOMマスタはどこにあるのか（どれが派生したコピーなのか）、そして事実を一元的に記録したBOMトランザクション履歴はどこにあるのか、という問いである。
このような整合性確保は、当然ながら簡単ではない。ただ、はっきりしている事が一つある。それは、「BOMは複数あっても良いが、マテリアル・マスタは一つだけを共通に参照する」ことだ。（なお、マテリアル・マスタは「部品マスタ」「品目マスタ」などと呼ばれることもある）
ここがブレて、本社と工場が、あるいは営業と製造が、そして日本と海外子会社が、同じものを別のコードで呼んだりする状況は、断固として避けなければならない。個別の部署はそれで良いかもしれない。しかし、部門横断的なエンジニアリングチェーンもサプライチェーンも、もちろんアフターサービスも、実務が大変苦労するからだ。
ただ、そうしたBOMデータ不整合で生じる苦労は、実務レベルの人々が背負うものの、経営層はどこ吹く風で気づかなかったりする。そして時々、叫ぶのだろう。「なんでウチの現場は、生産性が低いんだ！　なんで何か聞いても、すぐ数字が出てこないんだ！」・・・
問題のあるところには、原因がある。経営の横断的機能が働かず、部門最適がはびこりすぎると、いつの間にか会社はタコツボ的データの集合体になる。12畳のワンルームを10個の小部屋に区切ったら、使い物にならないに決まっている。『データドリブン経営』をしたかったら、データ価値を理解する経営が、まず必要なのだ。

＜関連エントリ＞「BOMデータのマスタと履歴を区別する」 https://brevis.exblog.jp/28544961/ (2019-08-28)「BOMのレベルとは何か」 https://brevis.exblog.jp/33251771/ (2024-10-18)

BOP（Bill of Process）とは何を意味するのか　～　三種類の用法を再整理する

Tomoichi_Sato — Sun, 09 Mar 2025 21:50:18 +0900

Bill of Processは比較的新しい言葉である

「言葉を大切にする」——これは、ロジックに関わる仕事をする人間にとって、とても大切な思考習慣だ。言語は（特に名詞や動詞などは）、その背後に『概念』を抱えている。何かを言葉で伝えるとは、その背後にある概念を指し示すポインターを、相手に渡すようなものだ。

このポインターがずれてしまうと、誤解の元となり、仕事がうまくいかなくなるばかりか、感情的な摩擦の原因になったりもする。ガンバリズムの「目標」に過ぎないものを「計画」と呼んだり、支配欲求丸出しの号令を「リーダーシップ」などと称したりするところから、わたし達の混乱ははじまっていく。

もっとも、差し示される対象の「概念」のほうも、明確な領域や境界線があるとは限らない。しばしば、個物（インスタンス）の雲のような集合があって、そこから帰納的に概念を導いたりする。雲のような集合だから、人によって思い描く範囲が異なる。そこで時には話し合いによって、ここからここまでを、この概念の範囲に取り決めようと、「定義」が定められたりもする。ただし法律用語でもない限り、そうした定義は、部署や企業や業界団体の中で、慣例として用いられるだけで、同じ言葉が業種を超えると、しばしば別の意味を持ったりする。

BOP（Bill of Process）という用語は、拙著「BOM/部品表入門」には出てこない。この本を書いていたとき（2004年）には、まだほとんど使われていない言葉だったからだ。BOPは日本語では、「工程表」ないし「製造工程表」と訳される（というか、正確に言うと、これらの言葉はずっと昔からあったわけで、日本語ではこれらに対応する、と言うべきだろう）。

つまりBill of Processは、近年になって普及してきた比較的新しい用語なのである。実際たとえば、大手PLM/MESベンダーであるダッソーシステムズ社は、つい最近までこの言葉を使わず、別の用語を当てていた。ようやく昨年頃から、Bill of Process の言葉も使われるようになった、と聞いたことがある。

Bill of Processの中核概念とは

BOPは、BOM（部品表）に関連した、いわばセットになる概念である。もっと具体的に言うと、設計部品表「E-BOM」= Engineering Bill of Materialを、製造部品表「M-BOM」= Manufacturing Bill of Material に展開・変換する際に必要となる、製造プロセス情報の集合を示す。プロセスの列挙表だから、Bill of Processと呼ぶ（レストランの勘定書きを英国でBillと呼ぶように、英語のbillには所有物や債務などを列挙した表の意味がある）。

ところで、ここから先がいささかややこしい。それは、この表が、具体的な個別の製造作業を指すのか、それとも概念的な製造作業のリストを指すのか、という点に混乱があるためである。別の言い方をすると、この表はマスタ・データなのか、トランザクション・テーブルなのか、と言う問題だ。あるいは、クラスを示すのか、インスタンスなのか、と表現してもいい。

実はこの混乱は、BOM=部品表にもある。BOMとは、製品を作るのに必要な部品の構成表である。ところで製造業では、部品の一時的な変更や代替がしばしば発生する。特に変化スピードの早いハイテク産業や電子機器業界では、部品の世代交代が激しく、古い部品の在庫を使い切ったら、新しい部品に切り替える、といった事態が平気で起こる。

このような時に、BOMをどのタイミングで更新したら良いだろうか？　製品はこれこれの部品で作るべきであると言う「べき論」と、実際の製造指図はここにある部品で作るしかないと言う「現実論」に、ギャップが生じる。この「べき論」の方はマスタ・データに規定し、「現実論」の方は、個別の指図に添付したBOMと言うトランザクション・データとして記録するのが良い。だからBOMには、マスタの他に、指示の履歴と実行の履歴の、合計3種類のテーブルが必要なのだ。この事は拙著「BOM/部品表入門」でも最初のほうに説明した。

同じ区別が、Bill of Processでも必要なのである。その製品はこういう製造プロセスで、こうした作業時間の下で作る「べき」という情報と、この製品ロットはこれこれの製造プロセスで、この着手と完了期限で作ってくれという「現実」は、マスタとトランザクションで区別しなければならない。

工程なのか工順なのか

もう一つややこしいことがある。それは「工程」という言葉だ。皆さんの職場で工程表と言ったら、何を指すだろうか。わたしの職場では、工程表と言うとデフォルトで、スケジュールを示したガントチャートのことになる。もちろんそうではない会社だって多いだろう。

製造業では、工程とはある種の製造プロセスをさすのが普通だが、その粒度はかなりまちまちだ。しかも、「工程」が実は工場内のエリアや作業区で区分されたり、組織の班で分担されたりもする。「工程」は、極めて多義的な言葉なのである。だから「BOP」の語を、頭の中で「工程表」に翻訳して理解しようとする人たちは、この言葉に伴う混乱を、逆に持ち込むことになる。

製造プロセスの粒度、すなわちどこからどこまでをひとまとまりとして扱うのか、については古くから議論があった。アメリカで1960年代にMRPが成立するが、1つの課題は製造負荷と工程能力の調整にあった。MRPは納期から逆算して工程別に製造オーダーを計算する。機械的に計算すると（機械だから機械的に計算するのだが）、工程の能力で処理しきれないほど、製造オーダーが集中してしまうことが起きる。

だったら、工程の能力上限をマスタ・データにして、チェックをかければ良いではないか。ところが、これを適用しようとすると、厄介な問題に突き当たる。1つの工程とされている製造プロセスの中をよく見ると、複数の異なる機械や人員や金型といった「製造資源」を必要とする、別々の単位的な作業が並んでいたりするのである。

そこで80年代以降の「MRP II」では、複数作業が並んだセットとしての「Routing」概念が登場する。そして部品の親子関係をつなぐ製造プロセスとは、工程ではなくRoutingだ、ということになった。ところで、英語のRoutingはふつう「工順」と訳されるが、この日本語は、「一連の作業工程のセット」という意味で使われる場合と、「作業の順番」（つまり番号）を意味する場合がある。MRP IIでいっているのは、セット＝集合の方である。

BOPの3種類の用法とは

ということで、ここまででもう充分、読者の頭は混乱したと思うから(笑)、ここで再整理しよう。

BOP = Bill of Processの用語は、3種類に分けることができる。

第1の用法：工順を表す

すなわちBOMの中で、あるマテリアル（部品材料）が、その親のマテリアル（中間部品・製品）になるまでの、一連の作業の集合を表す、という使い方である。わたしの知る事例では、航空機製造業界で大手企業が部品製造に関して、このような使い方をしている。つまりMRP IIでいうRoutingのことを、BOPと呼ぶ訳だ。
第2の用法：工順の全体ツリーを表す（共通マスタ情報）

第1の用法が、BOMの1段階の親子関係をつなぐ部分に着目しているのに対して、第2の用法は、最終製品を作るために必要なRouting全体をさすケースである（BOMがツリー構造になっているため、BOPもツリーに表現できる）。ネットでBOPを検索すると、現時点ではPLM系のベンダーやコンサルタントの記事が多く引っかかるが、ほとんどはこの用法で使っている（ようだ）。

なお、自動車産業をはじめ、グローバル生産を行う企業では、同一の製品でも生産地によって異なる作り方をすることが多い。この場合、複数の代替的な製造プロセスを一つのBOPに集約する、150%BOM的な例も紹介されたりする。つまり、ここでのBOPはあくまでマスタ概念である。

第3の用法：工順の全体ツリーを表す（具体的な日時の情報をもつ）

ところで、PLM系の業務に用いるマスタでは、複数の代替手段を定義してもいいが、SCM系業務に用いる現実の製造オーダーでは、どれか一つを選ばなくてはならない。無用な重複は許されないからだ。つまり、その場合BOPのトランザクション・データ（インスタンス）は、現実に可能な製造プロセスのスリムなセット、ということになる。

そして現実の製造オーダーには、具体的な期日がついて回る。したがって、BOPには着手完了に関して、具体的な日時の情報をもつことになる。そして、このようなケースでは、しばしばガントチャート（工程表）表現も付随して使われる。これが第3の用法だ。第3の用法、つまり製造オーダーまでも、PLMシステムでカバーしている事例は少ないと思われる（少なくともわたし個人は知らない）。多くはERPや生産管理システムなど、SCM系システムで展開しているはずである。

はじめにも書いたとおり、言葉は大切だ。ただ、わたし達の社会では、言葉は雰囲気作りの道具としても使われる。「DX」しかり、「スマート製造」しかり。「グローバル戦略」なんて、もっとそうだ。ポジティブな雰囲気を作り出し、ムードに酔うことも、ときには必要だろう。だがロジックに関わる仕事をしたいのなら、概念について、きちんとクールに付き合うべきだろう。

＜関連エントリ＞
「製造作業を自動化するために必要なデータとは」 https://brevis.exblog.jp/33521355/ (2025-02-15)
「BOM（部品表）は世代交代とともに精緻化している」 https://brevis.exblog.jp/32588574/ (2024-07-04)
「部品表と工程表」 https://brevis.exblog.jp/25634844/ (2017-03-22)

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

Tomoichi_Sato — Fri, 01 Nov 2024 23:49:11 +0900

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)

BOMのレベルとは何か

Tomoichi_Sato — Fri, 18 Oct 2024 10:58:16 +0900

BOM用語はなぜ分かりにくいか

BOMの用語はややこしい。BOM（Bill of Material＝部品表）の概念自体はもう、50年以上もの歴史がある。その間に、いろいろな用語・概念が確立し、徐々に変遷してきた。またBOMをめぐるソフトウェア業界にもいろんな技術進化と流行があり、大手ベンダーが差別化のために提唱した用語が、いつの間にかスタンダードみたいに普及していくこともある。

近年では、BOP（Bill of Processes）という用語がそうだ。このBOP概念はここ10年くらいに普及してきたものだが、実はまだ発展段階で、きちんと定まっていない。同一企業内でも異なる意味で使っていたりする。ちなみに2004年に発刊した拙著「BOM/部品表入門」では、BOPという言葉は取り上げなかった（ほとんど使われていなかったのだ）。しかし最近のBOMのセミナー等では、かならず説明する必要がある。

ちなみに、ERP（Enterprise Resource Planning）という用語だって、ある意味その一例だ。これは元々、MRP（Manufacturing Resource Planning）＝製造資源計画という、生産管理用語からきている。これは部品・資材をはじめ、機械設備、人員、そして資金など、製造活動に必要な資源（Resource）を包括的に計画する活動を指す。その中心にあるのが、製品とその部品表BOMデータだった。80年代後半頃の話だ。

ところで、そこにドイツのSAPという会社が現れ、財務と管理会計を中核にして、企業内のあらゆる活動（部門間取引）データを集約するパッケージを考えた。彼らは、企業の財務部門が原価をベースに、すべての経営資源を計画するのが理想だと考えた（らしい）。そして、MRPをもじってERPなる造語をつくったのである。だがSAP社がメジャーになるに従い、ERP概念も通用範囲が広まり、今では世のはじめからある一般概念みたいな顔をしている。

BOMのシングルレベル表現とは

話を戻そう。BOM概念は、MRP（Material Requirement Planning）＝資材所要量計画という生産管理手法と共に産まれ育ってきた。60年代アメリカでの話である。ここで述べている60年代のMRPと、上で書いた80年代のMRPでは、頭文字は同じだが、単語・概念が違うことに注意してほしい。普通は区別するため、後から出てきた方（製造資源計画）を、"MRP II"とよぶ。

MRPが産まれた当初、コンピュータは大型ホストしか存在せず、言語はアセンブラかCOBOLかFORTRANのみ。RDBなど存在すらしない時代だった。この時代に、ツリー構造のBOMデータを定義した先人達は、相当な苦労をした。

今日のテーマであるBOMのレベルとか、シングルレベル・マルチレベルという表現は、その時代からある考え方である。これには、コンピュータ内部のデータ構造としての側面と、ユーザに見せる表現系としての側面がある。でも分かりやすいように、表現系の話からしよう。

一番初期のBOMは、単純な部品リストだった。つまり製品を構成する部品の表である。親子関係は1段階。BOMの世界では、ツリー構造に表示した際に、上から順にレベル番号をふっていく。建物のように、一番下を1階として、順に上の階に番号を振るのではなく、最上階から下りるように番号を振る。

BOMの最上位にある最終製品を、レベル0とよび、そこから段階に従ってレベル1、レベル2とする（なお、最終製品を1とする流儀もあるが、レベルとは最上位からの距離を示す「距離」だと考えて、0とする方が計算上、何かと便利なので、わたしはこちらを採用している）。

機械組立図の部品表と、シングルレベルBOM

さて、機械製品などでは、設計部門が組立図を作成する。そして通常、製品を構成する部品をリストアップして、図の右とか下に表形式で表示するのが、つねだった。これが設計部品表（E-BOM = Engineering Bill of Material）の原型だ。ちなみに古い時代は、Bill of MaterialをBOMではなく"B/M"と略すことも多かった。この部品表は、親である製品と、子である部品の1段階の親子関係を示す。つまり、機械組立図から導出される部品表は、通常、シングルレベルBOM（サマリー型部品表）になる。

ところで機械モノではしばしば、アッセンブリー品（Assembly item）が用いられる。これは、ある程度独立した機能と内部構造を持つ、パーツのことである。たとえば、駆動用モーターなどがその例だ。同じモーターが、複数製品に用いられたりする。そこで設計部門は普通、アッセンブリー品の組立図を別に作成する。その組立図にも、アッセンブリー品の部品表がつく。これもシングルレベルBOMだ。

さて、BOMの重要な用途は、構成管理や資材手配計画である。だから、二つバラバラにあるシングルレベルBOMを結合して、一緒に見たくなる。こうして、マルチレベルBOMが形成されることになる。E-BOMは、このように複数階層のマルチレベルBOMになりうる。

ちなみに、「部品のローレベル・コード」とは、その部品がマルチレベルBOMの、どの階層に現れるかを示す数字である。汎用的な部品は同一製品で複数カ所に使われたりするが、その場合は、一番下の階層を指す。

シングル/マルチレベルと、サマリー型/ストラクチャー型

もしその企業が、部品はすべて外部から購入し、自社では組立しか行わないのなら、これでBOMとして完成である。「BOMとして完成」とは、これで構成管理もできるし、原価企画も可能だし、生産・購買計画と、工場へのオーダー指示にも使えるからだ。つまりBOMの主要な用途に耐えうる、という意味である。

このようなマルチレベルBOM（組立図に表されるシングルレベルBOMを統合したもの）は、設計部門だけで作成できることに注意してほしい。つまり、担当部門別のカテゴリーでいえば、E-BOMなのである。今日の大企業なら、それは何らかの洒落たPDMないしPLMパッケージソフトの中に、データとして構築されるケースも多いだろう。

そして日本の大企業には、部品はサプライヤーに納入させ、自社は組立・検査・出荷だけ、という形態の企業が、案外多い。こういうケースでは、

　　E-BOM = M-BOM = P-BOM、

という等式が成り立つ。作成・保守に関わる部門は、製品設計の1部門だけ。ツールはPLMだけ。非常に単純である。大企業の設計部門は、本社にいて予算も持っていることが多い。だからPLMベンダーなどは、「BOMはPLMだけで大丈夫ですよ」などと宣伝することになる。

ただし、ここには外部から購入した材料の、加工などの段階が含まれていない点に注意してほしい。社内で部品加工などの工程をおこなう製造業では、さらに外部購入の原材料まで遡った、中間段階を付け加えて、はじめてBOMがが完成する。少なくとも、生産・購買計画と工場へのオーダー指示には使えない。こうした加工工程や購買に関する情報は、普通は設計部門ではなく製造部門が所掌とするので、担当部門別のカテゴリーでは、製造部品表（M-BOM = Manufacturing BIill of Matrial）になる。

ともあれ、シングルレベルBOMという呼び方自体は、E-BOM、M-BOMなどの種別にかかわらず、用いられる用語である。これは用途や作成部門ではなく、表現の形をしめす概念だからだ。

ところで、シングル/マルチレベルと、サマリー型/ストラクチャー型の区別は、別の概念である事に注意してほしい。たとえば、今でもよく用いられるサマリー型の購買部品表P-BOMは、親の製品に対して、その外部購入の原材料が並ぶ表である。これは1段階の階層しか、もたない。しかしそれは直接の親子関係を示すものではない。

かりに機械製品の原材料に、ステンレス丸棒が書かれていたとしても、それは通常、切断され加工され表面処理などをされた上で、機械部品として組み込まれるからだ。つまりP-BOMというのは、途中の親子関係を全部捨象して、最終製品と一番元の原材料を示しているのである。だから、これはシングルレベルBOMとは呼べない、ということになる。シングルレベルかどうかと、サマリー型かどうかは、厳密に言えば別なのである。

・・などと説明していたら、うーん。例によって、思わず長くなってしまった。データ表現としてのシングルレベルBOMの話は、稿を改めて、また別に書くことにさせてください。

＜関連エントリ＞
「BOM（部品表）、その第1世代～第2.5世代の変遷を知る」 https://brevis.exblog.jp/32520484/ (2024-06-24)

BOM（部品表）は世代交代とともに精緻化している

Tomoichi_Sato — Thu, 04 Jul 2024 17:17:41 +0900

設計部品表（E-BOM）の階層について

最初に、前回記事「BOM（部品表）、その第1世代～第2.5世代の変遷を知る」について補足しておきたい。記事では、第1世代の設計部品表（E-BOM = Engineering Bill of Material）には、階層構造がなく、製品と構成部品の数量関係（員数）があるだけだ、と書いた。

しかし、「それはちょっとおかしい。ウチの会社のE-BOMには、ちゃんと階層構造があるぞ」という、疑問を抱かれた読者も、おられたに違いない。E-BOM＝サマリー型、M-BOM＝ストラクチャー型、という区別は本当なのか？と。その点について説明しておきたい。

元々、BOM＝部品表の概念は、機械組立加工系の分野から発達した。機械設計の分野では、製品組立図という図面を作る。製品全体の構造を図示し、それを構成している各部品について、引き出し線と番号をつける（――①、つまり細い糸の先に○がついてる形なので、俗に「風船」と呼ばれる）。

そしてふつうは図の端に、表がついている。その表は、引き出し線の番号①②…と、それぞれの部品名称・番号、そして数量が記載された表だ。これが、設計部品表の原型なのだ。そして世の中には、この部品表だけで業務を回している会社も、まだ少しは残っているはずだ。

機械組立図の例

アッセンブリーという名の部品

ところで、複雑な機械製品になると、それを構成するモノの中に、「アッセンブリー」を持つ場合がある。アッセンブリーとは、複数の部品を組合せて作る、一種の大型部品だと思えば良い。長いので、しばしば「アッシー」などと略して呼ばれる。

たとえばモーター駆動のポンプを考えた場合、そのモーターを外から買ってくる場合は、一つの購入部品扱いだ。だがもし電動モーターも内製するとなると、その内部構造も設計しなければならない。この場合、電動モーターがアッセンブリー扱いになる。そして設計部門は、モーターの組立図を作成することになる。そこにはまた風船が飛んでいて、図の右端に部品構成表がつくだろう。つまり、製品のE-BOMの下に、アッセンブリーのE-BOMがつき、一種の階層構造になる訳だ。

そして時には、アッセンブリーの下に、「サブ・アッセンブリー」を持つ場合だってある。そうなると、

製品 > アッセンブリー > サブアッセンブリー > 部品、

という風に、E-BOMは4階層になる。もっと階層が増えるケースだってあり得るだろう。これが、E-BOMにも階層が現れる理由である。

E-BOMの階層は、どこまでをカバーするか

ただし機械設計部門の仕事は、組立図で終わる訳ではない。それを構成する機械部品全てについて、それぞれの部品図を作成する。この際に、部品図は「一品一葉」で作成するのが、由緒正しいお作法とされている。つまり個別の部品に対して、1枚ずつ部品図を作成するのである。隣接していても、別々に図面化する。なので、古くからある企業では、しばしば「部品番号」を取る代わりに、「図面番号」で代用してきたところも多い。

当然ながら、個別の部品は、図面に表す幾何的形状のみならず、材質や表面処理・仕上げなどの仕様についても、規定する。ただ、一般的に、製品設計部門の仕事は、そこまでだ。

その部品を、どのような素材から、どう切り出し、素形材をどんな工作機械を使って加工するか、どんな熱処理や表面処理、塗装を行うか、などといった製造技術に関する部分は、通常、生産技術部門の仕事になる。そこではしばしば、切断→加工→熱処理→表面処理、といった工程が並んでいく。これらを総称して『加工工程』と呼び、できあがった部品たちをくみ上げていく『組立工程』と区別する。

つまり機械製造は一般に、『加工工程』→『組立工程』という大きなステップから成り立っているのである。このうち、製品設計部門の部品図や組立図がカバーするのは、後半の『組立工程』だけだ。であるから、設計図やCADデータをベースとした、通常のE-BOMのカバー範囲は、『組立工程』に限られることになる。でも、製造工程の全体像を示す、本来の第2世代・製造部品表M-BOM（= Manufacturing Bill of Matrial）は、『加工工程』も表現していなければならないのである。

M-BOMの全体像と、階層構造を持つE-BOMのカバー範囲

MRP IIの発達に伴い、第3世代のBOMへ

さて前回記事では、第2世代のM-BOMの親子関係を規定するのは「工程」であり、そこに「標準リードタイム」を追加したものが、第2.5世代である、と解説した。標準リードタイムを追加したのは、日程展開計算を可能にすることによって、生産計画立案に活かしたいからであった。この考え方をベースに確立したのが、MRP = Material Requirement Planningという生産管理手法で、その成立には米国IBMが大きな貢献を果たした。

80年代に入ると米国では、このMRPの手法をさらに発展させ、資材所要量だけでなく、製造に関わるすべての経営資源の所要量を計算しようと言う方向に機能拡充させた。製造に関わる経営資源とは、機械設備であり、人員であり、金型・ツール類であり、そして資金であった。

これらの所要量をきちんと計算するためには、部品表の親子関係に1つの工程が定義されているだけでは足りない。一口に加工工程や組立工程といっても、部品は複数の機械を渡り歩き、それぞれは異なるオペレーターによって操作される。したがって、粒度を1つ上げて、工程を複数の「作業」からなる『工順』（Routing）として認識する必要が出てくる。各作業には、それぞれ必要とする機械設備・人員・金型・ツールなどが定義される。

このようにして生まれたのが、第3世代のBOMである。図は、ある親部品と、それを構成する子部品のペアとの関係を示しているだけだが、相当精緻かつ複雑になっていることがわかると思う。

第3世代のBOMの概念

ともあれ、ここまで表現することができれば、各種製造資源の所要量計算が可能になる。こうして、単なる部品の所要量計算が主機能だったMRP = Material Requirement Planningは、80年代に入ると、MRP II = Manufacturing Resource Planningへと進化した。頭文字は同じMRPだが、単語が入れ替わっている点に注意してほしい。

そして90年代に入ると、あるドイツの基幹業務パッケージ・ソフトウェアのベンダーが、製造だけでなく、企業全ての経営資源の所要量を、経営者がコントロールするツールの概念を提唱した。そして、それをERP = Enterprize Resource Planningと名付ける。その企業の名前は、SAP社。これがERPの誕生なのだが、その源流を遡ると、BOM/部品表にたどり着くと言うことを理解している人は、決して多くない。

＜関連エントリ＞
「BOM（部品表）、その第1世代～第2.5世代の変遷を知る」 https://brevis.exblog.jp/32520484/ (2024/6/26)

BOM（部品表）、その第1世代～第2.5世代の変遷を知る

Tomoichi_Sato — Wed, 26 Jun 2024 22:17:52 +0900

BOM/部品表をめぐる、日本と中国の製造業事情

このところ、BOM（部品表）に関する依頼や問い合せが、急に増えている。先週19日に開催した、有料1日セミナー「BOM／部品表の基礎とBOM構築の留意点および応用テクニック」は、参加申込みが事前に満員御礼で、アンコール講演を秋に行うことになった。また拙著「BOM/部品表入門」もつい先日、1,000部増刷して、15刷・累計13,800部となるとの連絡を、出版社からもらった。個別企業や団体からの講演依頼もあり、誠にありがたい。

だが、2004年に出版した本が、今さら売れ出すという現象は、不思議でもある。一体この20年間は、何だったのか。日本の製造業はBOMに関して、眠っていたのか？

もっとも今月は、同書の中国語翻訳版も売れ続けているとの知らせも受けた。実際、中国からの製造業の視察団に本を紹介したところ、かなり興味を持っていただけた。また質問内容からすると、中国製造業も次第に、BOM（部品表）のマネジメントについて、次第に難しい局面に入りつつあるようだ、との印象を受けた。

BOM（部品表）のマネジメントを難しくする、製造業の構造変化

BOMの難しい局面とは何か。それは簡単に言うと、見込生産から受注生産への転換、そして製品バリエーションの無際限な増大、という二つの大きなシフトだ。この二つの変化は突然、急に起きるのではなく、いつの間にか徐々に、ちっとも劇的でない形で、製造業のビジネスのやり方を変えていく。しかしある日、気がつくと製品在庫の膨張、部品資材の欠品の頻発、多発する設計変更への対応不全、そして品目コードの桁数不足など、目に見えにくい地味な形で、製造業の俊敏な対応力を奪っていく。

多数の人口をかかえ、広大な国土を持つ中国の製造業は、これまで見込生産中心で拡大してきたのだろう。わたしは中国事情についてはほとんど知らないので、想像で書いているだけだが、元々は計画経済の下で、計画生産、それも少品種大量生産形態が、メインだったろう。「作れば売れる」時代だったのだ。これは、日本の戦後の高度成長期を思い出してみても分かる（わたしは昭和世代なので、当時のことは多少まだ記憶にある）。

ところが経済が成熟し、消費者や企業が豊かになっていくと、何が変わるか。当たり前だが、市場が次第に飽和し、「作れば売れる」状態から、競争の激しい状態になっていく。するとメーカーは、従来の大量生産・低コスト戦略だけでは持たなくなり、差別化戦略を求めて、製品仕様のバリエーションを増やしていくことになる。それは家電でも自動車でも一般消費財でも、あらゆる商品カテゴリーで進んでいく。

サプライチェーンで商品の種類が増えると、何が起きるか。当然ながら、小売店やチェーンストアの店舗で、棚の場所の奪い合いが起きる。自社の商品を置いてもらえるかどうかが、売れ行きに直接、はね返る。物不足時代には、商店がメーカーに製品を「置かせてもらう」立場だったが、モノあまり時代には、メーカーが商店に「置いてもらう」時代になる。

かくて、流通側と生産側の力関係が、いつの間にか、逆転していく。流通側が力を持つようになると、チェーンストアが発達し、商品仕入れや在庫管理能力も高まる。そして、次第に流通側が主導権を取って、メーカーに対し、作る商品と時期を伝えるようになる。つまり、見込生産から受注生産に変わっていくのだ。

実際、メーカーの方だって、製品ラインナップが増えているので、同じ品目ばかり、常時作り続ける訳にはいかなくなる。何をいくつ、どのタイミングで作るか、市場の需要情報を見て、決めなければならない。受注生産が増えると、顧客からの個別仕様の要求も増えてくる。かくして製品バリエーションは、どんどん多様化・複雑化の方向に向かう。

大量見込生産時代を支えた、第1世代のBOMとは

ところで、モノづくりをするためには、部品材料が必要である。では、その調達計画を支えるものは、何か。二つ、重要なインプットがある。それは製品単位の生産計画と、その製品を構成する部品表である。これが無かったら、資材購買部門は何をいくつ、買ったら良いか分からない。

ここで言う部品表とは、一つの製品を作るのに、どの部品が何個、必要かを表した表である。

BOMの世界では、「親子関係」で部品間の関わりを表す。つまり、親製品を構成する子部品は、何が何個ずついるのかを示すのが、部品表の元々の姿である。たとえば親製品Xを1個作るのに、部品Aが2個、部品Bが4本、といった関係である。この数量関係を『員数』と呼ぶ。この、親子間の員数を記述した表を、わたしは「BOMの第1世代」と呼ぶことにしている。

図1 第1世代のBOM

図を見てほしい。第1世代のBOMの典型例を示す。左にあるのは、『設計部品表』（E-BOM = Engineering Bill of Material）と呼ばれるもので、設計部門が、製品の機械組立図などに記載するものだ。もっとも図の例は、製品として「冷やし中華」を取り上げているので、組立図などは作らないかもしれないが、ともかく最終製品は、錦糸玉子50gと、ゆで麺150gと、チャーシュー細切り50g・・などを、お皿に盛り付けて（＝組み立てて）作ることを示している。

もっとも、このままでは購買の役には立たない。ゆで麺とかきゅうり細切りなどは、市場から調達できないからだ。そこで、これらの部品を、外部から調達可能な原材料に変換しなければならない。それを示したのが、図右側の『購買用部品表』(P-BOM = Purchase Bill of Material）と呼ぶ表だ。これなら、製品100個を作る場合なら、何をどれだけ、買ってくればいいかを知ることができる（こうした計算を『部品展開』と呼ぶ）。

ちなみに、BOMの世界では、上にある品目を親と呼び、下にある品目を子と呼ぶ約束だ。ふつうの世の中では、親が子を産むのだが、部品表の世界だけは、子が集まって親を生むのである。

この２種類のBOMはいずれも、親子だけが記述されており、それ以上の階層構造を持っていないことに注意してほしい。これが第1世代のBOMの特徴である。そして現在でもなお、かなり多くの企業が、この第1世代のBOMだけで、業務を回していたりする（日本でもそうなのだから、中国においておや、とも想像される）。

工程展開と、BOMの第2世代

ところで、高度成長期の日本と現代の中国は、次第に製品バリエーションの増大と製品在庫の膨張に、頭を悩ませていると書いたが、じつはこの問題にもっと先に直面したのは、アメリカの製造業だった。「1ダースなら安くなる」という思想を信条とする米国では、ずっと大量見込生産で産業をドライブしてきた。T型フォードが、その良い例だ。

そしてフォードをはじめとする自動車産業が、少品種だけで済まなくなってきて直面したのが、在庫膨張問題だった。それが目に見えてきたのが1960年代であるが、ここで彼らは、米国人らしく論理的かつ実用的な方式を考案する。生産マネジメントに、当時登場してきたばかりの、電子計算機を使うことを思いついたのだ。

それまでの米国の生産管理を支えてきたのは、工程別のロット生産、そして在庫の定量補充発注だった。少品種ならこれを繰り返していれば良い。しかし多品種化すると、工程別に、何をどう作るべきか、的確な指示が必要になる。

何も指示しなくても現場が主体的に判断して動く日本と違い、低賃金労働者や移民を大量に雇う米国の工場では、事細かな指示を、紙に書いて出さないと動かない。その工程への指示を、計算機で出すことにする訳だ。そのためには、製品を1個作るのに、何が何個、だけでは足りない。製品から原材料までさかのぼった、工程のリストが必要になる。

これを表現するのが、第2世代の「ストラクチャー型部品表」である。これは最終製品（End item）を1個製造するために必要な、すべての購入部品・中間製品等の親子関係を表示したものである。そして、親子関係の属性として、それをつなぐ「製造工程」を記述する。そこで、これを製造部品表（M-BOM = Manufacturing Bill of Matrial）とも呼ぶ。

図2 第2~2.5世代のBOM

この第2世代のBOMがあれば、工場の各工程に対して、何を何個作れ、と計算することができる（これを『工程展開』と呼ぶ）。そして、指示を出すことも可能になる。M-BOMはまた、製品の構成管理や、工程設計などにも連動し、活用される。用途と、関わる部門数が増える訳だ。

MRPと第2.5世代のBOM

ところで、各工程への指示となると、実は何を何個、だけでは足りない。いつまでに、というタイミングも、指示には必要である。では、これを計算するにはどうするか。

60～70年代の米国人が考えたのは、BOMの親子関係の属性として、工程種別だけでなく、その標準的なリードタイムをも設定することだった。これによって、どの工程で、何を何個、いつまでに作るべきか、が計算できるようになる。つまり『日程展開』が可能になるのである。これをわたしは、第2世代とあえて区別して、第2.5世代のBOMと呼ぶことにしている。

（ただし、このような世代の呼び方は、わたしのオリジナルであって、別に世間的に確立した用語ではないし、「[BOM/部品表入門]」 https://amzn.to/3xIFai6 にも書かなかったが、分かりやすさのために世代番号を振っていると理解してほしい）

まとめると、各世代のBOMの主な目的は、以下のようになる：

第1世代＝部品展開第2世代＝工程展開第2.5世代＝日程展開

この2.5世代BOMで可能になったのが、生産スケジューリング機能を持つMRPと呼ばれる手法であった。そして80年代に入ると、MRPはさらに発展してMRP IIとなり、それに伴ってBOMも第3世代に進化していくのだが、長くなってきたので、それについては次回、書こう。

＜関連エントリ＞
「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」 https://brevis.exblog.jp/24157732/ (2016-06-21)

お知らせ：BOMをテーマとした1日集中セミナーを6月19日に開催します

Tomoichi_Sato — Wed, 24 Apr 2024 08:27:23 +0900

お知らせです。久しぶりに、BOM/部品表をテーマとした1日集中セミナーを開催します。リアル開催としては4年半ぶり、オンラインだった前回から数えても、2年半ぶりになります。

「部品表の本って、どれくらい売れるんですか？」と、最近ある人から尋ねられました。「残念ながら、それで飯を食えるほどには売れませんね」というのがわたしの答えです。拙著『BOM/部品表入門』は2004年刊行で、おかげさまで20年間、版を重ねていますが、累計で1万部ちょっと。年に数百冊しか売れないことが、お分かりいただけると思います。

たとえ大きな製造業の会社でも、部品表の登録と維持に関わる業務をしている人の数は、ほんのひと握りです。どんな会社でも製造業である限り、部品表は必要ですし、持っているはずです。部品表がなければ、部品原材料を外から買ってくることができませんから。でも、この問題に真剣な関心を持つ人は、事の重大さに比して、決して多くないのです。

しかし、BOMデータをなおざりにした結果、何が起きるでしょうか？　製品開発のリードタイム長期化、設計部品表E-BOMと製造部品表M-BOMの乖離、品目マスタのコード爆発、トレーサビリティ追跡不能、などなど、その影響はボディブローのように効いてきます。行き着く先は、「不要なモノがあふれているのに、必要なモノが見つからない」、すなわちマテリアル・マネジメントの混乱と見えないコスト上昇です。

ちなみに、わたしがBOM/部品表のセミナーで、出席者の方によくたずねる問いに、

「岩手産の牛乳１ℓ瓶と、十勝産の牛乳２ℓパックは、同じモノでしょうか？」

という問題があります。これは、誰もが知っている牛乳を材料に、「あるモノが同一であるか異なるかは、誰がどう判断するのか？」を考えてもらうための例題です。

二種類のモノが同じか違うか、それは自明だろう、というのが大抵の人たちの認識です。でも厳密にあらゆる点で全く同一のものなど、この世に2つと存在しないわけです。では、同一部品のはずだが、サプライヤーによって性状が微妙に違うときは、どうするべきか。同じ製品なのだが品質によって納入先を区別しなければならないときは、どうしたらいいのか？

マテリアル・マスタ（品目マスタ）は部品表の基礎で、そこに登録されてない品目は、部品表にも登場しません。だとしたら、品目マスタには何を登録すべきか。マスタを照合した際に既存品と少しだけ違う場合、それが新規品目とすべきかどうか。判断の基準が必要です。こうした基準への納得のいく説明は、世の中にあまりないと思いませんか？

もう一点。本セミナーでは、『BOM/部品表入門』で扱えなかった、BOP = Bill of Processesという言葉についても解説します。BOPは20年前には殆ど使われていなかった用語ですが、M-BOMの充実（複雑化？）と共に、認識されるようになりました。ただし、BOPという概念の意義や範囲については、まだ世の中で完全に定まりきっていません。しかし工場スマート化と製造実行システムMESでもますます重要になる、このBOPについても説明をいたします。

＜記＞

「BOM／部品表の基礎とBOM構築の留意点および応用テクニック」

日時：　2024年06月19日(水) 10:30 ~ 17:30
主催：　日本テクノセンター
会場：　〒163-0722　東京都新宿区西新宿二丁目7番1号
　　　　　小田急第一生命ビル22F セミナー

内容詳細および申込み：　下記をご参照ください
https://www.j-techno.co.jp/seminar/seminar-61801/

（コンテンツ項目および説明順序は、参加者のニーズに応じて多少変える場合があります）

有償のセミナーですが、大勢の方のご来聴をお待ちしております。

佐藤知一

BOMに関する新連載記事のお知らせ

Tomoichi_Sato — Fri, 03 Jun 2022 22:06:04 +0900

2004年の末に『BOM/部品表入門』を山崎誠氏と共著で上梓し、以来18年が過ぎました。おかげさまで同書は今年に入ってからも増刷が決まり、累計1万2千部を超えています。また中国語版も、正確な販売部数は不明ながら、着実に売れ続けています。それだけ、BOM/部品表のマネジメントに悩む製造業の方が、内外で多い証拠でしょう。

その後、何度か有償の一日セミナーも行ってきました。こちらもそれなりに継続し、ニーズの根強さを実感すると共に、BOMをめぐる課題の裾野の幅広さを感じました。ただし同書で十分カバーしきれなかった項目や、出版後に浮き彫りになった種類の問題もあります。また新たに確立普及してきた概念・ツールなどもあります。たとえば、以下のような事柄です：

・E-BOM、P-BOM、M-BOMの関係
・製番管理や個別受注生産におけるBOMの扱い
・品質トレーサビリティと製造ロット
・E-BOMとM-BOMの乖離
・資源表（BOR）　など

ちなみに上記の本は、BOMをめぐって設計・生産技術・製造・購買・営業・・など、様々な部門の関わりを示し、またその要求事項を明らかにするという構成で書きました。わたしが本を書くと、なぜか必ず対話劇みたいになる（笑）のですが、同書も架空の企業におけるBOM構築プロジェクトに対して、外部コンサルタントが各部門と対話する形式になっています。その縦割りの多部門に対して、横串を通すのが、「事務局」としての情報部門だ、という仕立てです。

こういう構成の本は珍しいようですが、BOMという多面的な基準データの全体像を理解するには、適切だったようです。

今回ご縁があって、大興電子通信さんから、同社のWebメディア『DAiKO+PLUS』で、BOMに関する連載記事を書いてもらえないか、という依頼を受けました。そこで、部門単位の視点を保ちつつ、上述のような新しいトピックを組み込んだ上で、読みやすい長さの記事を書くことにしました。全部で11章（「はじめに」を含むと12セクション）です。これを、6月から毎週1記事ずつ、掲載していただくことになりました。

なお、大興電子通信さんは、＜部品表中心の生産管理システム＞『rBOM』という、とてもユニークなソフトウェア・パッケージを開発販売されています。ただし、わたしの記事はとくにrBOMについては触れていません。宣伝目的ではなく、あくまで一般的なBOMの解説記事として書きました。

記事はPDF形式で提供され、登録ユーザがダウンロードできます。よろしければ、ぜひ、お読みください。ちなみに初回のイントロは、こんな風です：

はじめに　〜　今、なぜBOMが問題なのか

最近、「データ・ドリブン経営」という言葉を、ときどき耳にするようになりました。「製造業DX」について語る人も、増えてきているようです。そして「スマート工場」という用語も、もう何年も前から話題になっています。

これらの言葉が実際に何を指すのかについては、必ずしも意見が定まっていません。ただ共通するのは、これからの製造業ではデータが非常に重要になる、ということです。

もちろん、製造業がこれまで、データを無視してきた訳ではありません。設計図は今や、多くがCADデータでしょうし、製造指図も生産実績も、多くの企業では生産管理システムの中に、データとして記録されているはずです。品質検査記録から、サプライヤーとの発注・入荷、製品の出荷実績に至るまで、ほとんどは手書き伝票でなく、情報システムで管理しているでしょう。

ならば、なぜ今更「データが大事」という標語が叫ばれるのでしょうか。

こういうケースを考えてみてください。顧客からある日、納入した製品に関する品質のクレームが入りました。一大事です。品質検査記録を調べ、納入製品が、どの製造ロットに属しているかを、さかのぼって確定しなければなりません・・・

以下はぜひ、サイトでダウンロードしてご覧ください。記事は毎週水曜日に更新されます。

佐藤知一@日揮ホールディングス（株）

お知らせ：BOM/部品表のマネジメントに関するオンライン・セミナーを開催します（11月19日・25日）

Tomoichi_Sato — Wed, 11 Nov 2020 23:31:14 +0900

えー、ここでまた恒例のお知らせです(^^)

BOM＝部品表に関するセミナーを、今月の後半に２つ、行います。一つは無償のウェビナー、もう一つは有償のオンライン・セミナー（一日コース）です。

「製造業のデジタル化に関する問題は、ITシステムが足りないことではない、むしろシステムが多すぎることだ」――これは最近、ある大手製造業のキーマンの方から聞いた言葉です。その方によると、自社のある事業部を調べたところ、なんとシステムは大小合わせて千以上もあったが、その多くがExcelで書かれ、互いにデータがちゃんとつながっていない状態であった、と・・。

相互につながっていない多数のシステムを抱え、その間のつなぎを、人間が手作業で行っている組織に、アジリティ（俊敏性）など求めようもないことは、言うまでもありません。

製造業におけるシステム・インテグレーションの中核部分には、基準情報としてのBOM（部品表）データがあります。製造業なら、どの企業も必ず、BOMを持っています（そうでなければ材料も購入できません）。しかし、BOMデータをきちんとマネジメントできている会社は、決して多くないようです。BOMには、受注・製品設計・工程設計・購買・生産管理・製造・品管・物流・保全・サービス・会計と、数多くの部門が、いろいろなフェーズとタイミングで関わるからです。

この問題を多面的に理解するために、2004年に「BOM/部品表入門」を山崎誠氏と共著で出版しました。以来、15年以上が経ちましたが、本書はいまだに現役で、累計1万2千部以上が売れ、中国語版も好評です。それだけ、この問題に悩む企業が多い証拠なのでしょう。

じつは、本書は最初、ERPパッケージの生産管理部分を担当するITエンジニアに対して、その設定方法の基本を教えるための本として、構想しました。BOM構築に悩む企業に、前著「革新的生産スケジューリング入門」の主人公である矢口先生がレクチャーに行き、各部門と対話を行っていく、というスタイルの設定です。

ちなみに、わたしの著書は、前述書をはじめ、「時間管理術」や「世界を動かすプロジェクトマネジメントの教科書」など、なぜかみな、登場人物たちの対話による構成になっています。もしかしたら前世は、売れない劇作家だったのかもしれません(;_;)

ところが書き進めていくうちに、BOMに関する全く違った主張の本に、変わっていきました。BOMは製造業におけるインテグレーションの中核データであり、維持と保守を、特定の外部パッケージソフトに依存するのではなく、自社でBOMプロセッサを構築すべきだ、というのが、本書のたどりついた結論です。

では、具体的にはどうすべきか。もちろん、その企業の生産方式やBOMの特性、そして現状システムのあり方に応じて、答えは千差万別です。ただ、共通の基本概念を理解し、BOM特有の各種テクニックを飲み込んだ上で取り組まなければ、あまりにも非効率でしょう。さらに近年では、BOP（Bill of Process＝工程表）概念の普及や、海外を中心としたPLM（Product Lifecycle Management）ソフトウェアの発達など、この分野で紹介すべき進展もあります。こうした事柄を理解しながら、自社のBOMデータのあるべき姿について、考えるきっかけにしていただければと願う次第です。

BOM/部品表マネジメントに関心のある方のご来聴を、心よりお待ちしております。

＜記＞

(1) 「製造業デジタル化のボトルネックを考える　〜　BOM/部品表のマネジメント入門」

日時：　2020年11月19日(木) 15:00〜16:30
主催：　（株）三菱総合研究所

セミナー：「DX戦略の実現に向けたデータマネジメント　〜　BOM／部品表のマネジメント」
内容：
・製造業デジタル化のボトルネックを考える　〜BOM／部品表のマネジメント入門
　　日揮ホールディングス株式会社　佐藤知一

・サプライチェーンをまたいだデータマネジメントに貢献するSImount（シマント）
　　株式会社シマント　代表取締役　和田怜
　　株式会社シマント　CTO　渡邉繁樹
　（SImountというユニークなnon-SQLデータベース技術を持つベンチャー企業さんです）

・DX戦略策定と実装
　　株式会社三菱総合研究所　企業DX本部　DX戦略グループリーダ　中西祥介

セミナー申込み：　下記をご参照ください
　https://www.mri.co.jp/seminar/20201119.html

(2) 「BOM／部品表の基礎とBOM構築の成功ポイント」

日時：　2020年11月25日(水) 10:30〜17:30
主催：　日本テクノセンター

本セミナーでは、BOMの基本概念の再整理からはじめて、マテリアル・マスタの統一、BOMの応用テクニック、そしてBOM構築プロジェクトの進め方について、演習をとりまぜつつ、平易に解説します。特に、BOM構築の３つの難所について重点的に説明し、E-BOM/M-BOMの乖離問題などについても、詳しく述べます。一日セミナーですので、じっくりと学ぶには最適です。

なお、量産型製造業だけでなく、拙著「BOM／部品表入門」で触れられなかった個別受注生産でのBOMの取扱いなどにも光を当てて、「自分で考え身につく」セミナーを目指します。

セミナー申込み：　下記をご参照ください（有償です）
https://www.j-techno.co.jp/seminar/seminar-39463/

なお、PC環境等の制限によりオンライン視聴が難しい方は、日本テクノセンター研修室でも受講が可能です。

以上、よろしくお願いします。
　　　　　　　　　　　　　　　（佐藤知一）

＜関連エントリ＞
　→「ふーん、デジタル時代には双方向のインテグレーションが必要って事？」 (2020-11-08)

お知らせ：BOM/部品表とPMに関するオンライン講演を行います（9月10日・9月17日）

Tomoichi_Sato — Thu, 27 Aug 2020 22:25:04 +0900

えー、前の記事では「この項続く」と書いたばかりですが、ここでスポンサーからお知らせです（笑）。
9月に2件のオンライン講演を行います。前者はエンジニアリング・チェーンとPLMに関する話題（無料）で、後者はスケジューリング学会シンポジウム（有償）でのプロジェクト・マネジメントに関する研究発表です。

実はつい最近、拙著『BOM/部品表入門』の増刷が決まりました。おかげさまで累計1万2千部です。2004年に上梓した一種の専門書が、16年後まで現役で売れ続けているのはとてもうれしいこですが、逆にそれだけBOM関係の情報のニーズが高いのだろうなと想像します。結局、設計から製造への機能的な橋渡しに悩む企業が多いからでしょう。同書の中国語版も売れ続けていますので、悩んでいるのは海を隔てた向こう側も変わらないようです。

今年の『ものづくり白書』でも、「サプライチェーン」と「エンジニアリング・チェーン」が生産で合流する、という概念の説明が出てきます。サプライチェーンは物づくりの順番に従い、受発注から始まって、生産計画→生産→流通・販売→保守・アフターサービス、とつながっていきます。これに対して縦軸は、研究開発→商品企画→製品設計、という製品開発の「エンジニアリング・チェーン」がぶつかり、両者が『生産』で合流します（より正確に言うと、製品設計の後には、工程設計→試作→量産準備→がはさまってと生産につながる訳ですが）。

エンジニアリング・チェーンを統合的に支えるソフトウェアは、PLM（Product Lifecycle Management）と呼ばれます。現時点では、その主力製品は欧米製です。複数部署をまたいで、データ中心に業務プロセスを統合する取り組みは、欧米製造業の方が先を走っているのでしょう。その統合の要は部品表/BOMデータベースで、その中にE-BOM→M-BOMが整合性をとって格納される姿になっています。

ところが現実には、PLMソフトの導入と、　SCM/生産管理系との統合は、なかなか一筋縄ではいきません。もともとPLMは、量産型の製造業を念頭に置いて作られたからです。他方、日本の多くの企業は受注生産、とくに個別性の強い受注設計生産の形態に取り組んでいます。こういう状況下で、BOMのあるべき姿について、皆が頭をひねる必要が出てきている訳です。

ここで登場するのが、設計という業務にまつわる「個別性の罠」です。どんな設計作業でも、つねに一度限りの営為です。これをどうマネージするかに、多くの組織が悩んでいます。

そして、そこで鍵となるのがプロジェクト・マネジメント（PM）の技術です。プロジェクトは、つねに個別性との戦いです。そこでは繰り返し型業務における、お得意の「PDCAによるカイゼン」が、うまく働かないからです。そうした意味で、製造業におけるPMの有用性は非常に高まっています。

しかし、現代のPM手法にも大きな課題があります。とくにプロジェクトが大規模化すると、「崩壊現象」と呼ぶべき事象が、ときおり起きるのです。人員を追加しても生産性が上がらず、いわゆるデスマーチ状態に陥って、いつ全体が終わるか誰も見えない、そういう状況です。モダンPM理論は、EVMSとかクリティカル・パス法などの技法で、プロジェクトの先行きを予測・計画していきます。しかし、それが機能しなくなる状況が生じるのですから、今の理論にはまだ、足りていない部分が残っている訳です。

2つのセミナーはテーマも内容も異なりますが、ここに述べたような問題をめぐって、皆さんと一緒に議論できればと思っています。関心のある方のご来聴をお待ちしております。

＜記＞

(1) 「BOM/部品表とエンジニアリング・チェーンのマネジメント」

日時：　2020年9月10日(木)　13:30 ～ 16:45（小生の講演は13:35～14:35の時間帯です）
テーマ：　「BOMで改善！中小企業の設計効率を上げる業務改革」
主催：　エスツーアイ（株）＋ダッソーシステムズ（株）
セミナー詳細：　下記をご参照ください（無料、定員なし）
https://blogs.3ds.com/japan/webinar-bom/
　　なお、セミナータイトルには「中小企業」と書いてあるのですが、中堅あるいは大企業の方も歓迎です。
　　むしろBOMマネジメントの問題は、ある規模以上の組織の方が難しい面がありますので。

(2) 「プロジェクトのコスト超過と崩壊現象のシミュレーション」

日時：　2020年9月17日(木)　14:30～15:45
主催：　スケジューリング学会　「スケジューリングシンポジウム2020」
　　　　オーガナイズドセッション「プロジェクト・マネジメントの教育と実践をめぐって」講演(1)
概要：
プロジェクトの完了日予測と、完了時点でのコスト予測は、プロジェクト・マネジメントにおける重要な課題である。従来、完了日はPERT/CPMのクリティカル・パス分析と、各アクティビティの進捗から計算してきた。また完了時点のコスト予測（Cost EAC）はEVMS手法により推定した。これらの手法はいずれも確定的予測であって、リスクと不確実性を反映することが難しい。他方、プロジェクトの実践現場においては、大きな納期遅れとコスト超過を伴う「崩壊現象」が、時おり生じることが知られている。本発表では、プロジェクトのアクティビティ・ネットワークにおける遅延とコスト超過の連鎖反応のパターンについて、シミュレーションを元に考察する。

シンポジウム詳細：　下記をご参照ください（有償です）
http://www.scheduling.jp/symposium/2020/

以上、よろしくお願いします。
　　　　　　　　　　　　　　　（佐藤知一）

お知らせ：BOM/部品表に関するオンラインセミナー講演を行います（6月16日）

Tomoichi_Sato — Thu, 28 May 2020 20:47:36 +0900

お知らせです。
来る6月16日(火)に、BOM/部品表に関する有償オンラインセミナーを行います。昨年12月に行った対面セミナーのアンコール版です（お陰様で昨年は満員でした）。ただし昨今の情勢を鑑み、オンラインで受講可能としております。

2004年に「BOM/部品表入門」を上梓して以来、わたしは15年以上にわたって、BOM＝部品表のマネジメント重要性を、訴え続けてきました。幸い本書はいまだに現役で、累計1万部以上が売れたばかりか、中国語版もかなり好評です。

いやしくも製造業である限り、どの企業も、BOMは必ず持っています（そうでなければ材料も購入できませんから）。しかし、BOMのデータをきちんとマネジメントできている会社は、決して多くないようです。なぜ、BOMのマネジメントが難しいのか。それは、生産の中核に位置づけられる基準情報であるにもかかわらず、複数の部門がいろいろなフェーズとタイミングで関わるからです。

とくに近年は、
　・新製品開発・投入のサイクルが早くなった、
　・製造のサプライチェーンが国境をまたいで海外に伸びた、
　・企業買収や提携が進んだ、
などの要因が相まって、BOMデータの維持運用を難しくしています。

他方、最近は製造業でも「DX」ブームの声とともに、データ・サイエンスやデータ・マネジメントに関心が集まり、あらためてBOMのあり方が注目されているようです。さらに、BOP（Bill of Process＝工程表）概念の普及や、海外を中心としたPLM（Product Lifecycle Management）ソフトウェアの発達など、この分野での進展も確かにあります。

今回は、前回の内容をさらにバージョンアップし、著書に述べた量産型製造業だけでなく、BOMを扱いにくい個別受注生産にも光を当て、「自分で考え身につく」セミナーを目指します。

BOM/部品表マネジメントに関心のある方のご来聴を、心よりお待ちしております。

＜記＞

「BOM／部品表の基礎と効果的な活用ノウハウ」

日時：　2020年6月16日(火)　10:30～17:30
主催：　日本テクノセンター（東京・新宿）

セミナー詳細：　下記よりお申し込みください（有償です）
https://www.j-techno.co.jp/seminar/seminar-36510/

なお、PC環境等の制限によりオンライン視聴が難しい方は、日本テクノセンター研修室でも受講が可能です。

よろしくお願いします。
　　　　　　　　　　　　　　　（佐藤知一）

＜関連エントリ＞
　　

　　

お知らせ：BOM/部品表に関する2件のセミナー講演を行います（11月28日・名古屋、12月17日・東京）

Tomoichi_Sato — Mon, 28 Oct 2019 22:28:31 +0900

11月と12月に、BOM/部品表に関連して、2件のセミナー講演を行います。前者はエンジニアリング・チェーンとPLMに関する話題（無料）で、後者は6月に行ったセミナーのアンコール講演（有償）です。

このところBOM関係の講演依頼が増えているのは、あらためて設計から製造への機能的な橋渡しについて、悩む企業が増えているためではないかと想像します。

製造業ではよく、「サプライチェーン」と「エンジニアリング・チェーン」が生産でクロスする、という説明がなされます。下図はわたしがときどき講演で使ってきたチャートで、横軸は左から右に向かって、物づくりの順番にサプライチェーンが描かれています。生産計画から始まって、調達→生産→出荷→販売→保守、といった流れです。これに対して縦軸は、上から下に向かって、マーケティングからはじまり、企画→製品開発→工程設計→試作→量産準備、という製品開発の流れを示します。これを「エンジニアリング・チェーン」と呼ぶわけですが、両者が交わるのが『生産』です。

そしてPLM（Product Lifecycle Management）と呼ばれるソフトウェアは、「製品の企画・設計から保守・廃棄にいたるプロセス全般を管理する」仕組みの提供を目的としています。もっとも、PLMソフトは普通、エンジニアリング・チェーンの側をサポートし、生産計画や生産・物流などはSCMソフトウェアが面倒を見ます。両者の統合の要は、部品表/BOMデータベースで、その中にE-BOM→M-BOMが整合性をとって格納されるのが理想形です。

ところが現実には、2つのチェーンの流れは、この図のようなきれいな直交形に統合しにくいのです。それは、もともとこの図が、量産型の製造業を念頭に置いて作られたからです。一方、日本の多くの企業では、もはや受注生産、とくに個別性の強い受注設計生産の形態が主流になっています。したがって、BOMのあるべき姿について、現下の状況に応じて皆が考える必要が出てきている訳です。

2つのセミナーはテーマも内容も異なりますが、この主題をめぐって皆さんと一緒に議論できればと思っています。関心ある方のご来聴をお待ちしております。

＜記＞

(1) 「BOM/部品表とエンジニアリング・チェーンのマネジメント」

日時：　2019年11月28日(木)　13:30～14:35
テーマ：　「BOMで改善！中小企業の設計効率を上げる業務改革」
主催：　エスツーアイ（株）＋ダッソーシステムズ（株）
会場：　〒450-0002　名古屋市中村区名駅4-7-1
　　　　　ミッドランドスクエア 5F ミッドランドホール会議室A

セミナー詳細：　下記をご参照ください（無料、定員30名）
https://www.s2-i.co.jp/seminar_and_exhibition/2308/

(2) 「BOM／部品表の基礎と効果的な活用ノウハウ　～演習付～」

日時：　2019年12月17日(火)　10:30～17:30
主催：　日本テクノセンター
会場：　〒163-0722　東京都新宿区西新宿二丁目7番1号
　　　　　小田急第一生命ビル22F

セミナー詳細：　下記をご参照ください（有償です）
https://www.j-techno.co.jp/seminar/seminar-31675/

以上、よろしくお願いします。
　　　　　　　　　　　　　　　（佐藤知一）

スマート工場時代の製造部品表（M-BOM）を考える

Tomoichi_Sato — Sun, 08 Sep 2019 23:28:51 +0900

当サイトの記事アクセスランキングを見ていると、2016年に書いた「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」がしばしば上位に顔を出す。E-BOMとM-BOMの関係に悩む人が少なくないのだろう。

『設計部品表』（Engineering Bill of Materials、略称E-BOM）とは、簡単に言うと、自社の製品の構造をその構成要素（部品・モジュール等）から示したものである。他方、『製造部品表』（Manufacturing Bill of Materials、略称M-BOM）とは、外部から購入した素材・部品を、製品に作り込む製造の道筋を示す道標だ、といえる。E-BOMは製品という「結果」を示し、M-BOMは工順データ（工程表）とともに、それを作る「方法」を表現したものである。

設計部品表E-BOMは製品の構造を示し、少なくとも自社で製品を設計する企業なら、必ず持っている（データベース化されているかどうか、はともかく）。では、製造業にとって、M-BOMは何のために必要か。

それは製品の需要を、具体的な製造の作業指示に展開するために使われる。M-BOMを基準にして、生産オーダーを工程展開し、各工程・作業区ごとの製造オーダーや購買オーダーを作成するためである。つまり、製造日程計画のベースとなる、個別オーダーの工程表を作成するために必要なのだ。

さらに、製造の標準原価を計算し、価格を見積るためにも役立つ。そして、進捗管理や負荷予測や変更管理の基準とするためにも有用だ。

このように重要な基準情報であるにもかかわらず、なぜM-BOMに悩む人や企業が多いのか。そして「M-BOMクライシス」ともいうべき状態に陥りやすいのか。理由は、三つほど考えられる。

一つには、そもそも製造部品表の概念がない企業が、しばしば見受けられるからだ。それも結構な大手企業であっても、である。そんな馬鹿な、というなかれ。理由は後ほど説明する。

二つ目の理由は、日本企業における生産技術部門の弱体化に関係している。それに追い打ちをかけるのが、製品品種数の増加現象だ。そして三つ目が（そして多分、将来的には一番重要になるのが）自動化・スマート工場化の動きである。だが、これらを見ていく前に、基本的な概念と用語について、一応確認しておこう。

図を見て欲しい。部品Aは、サブ部品（子部品）aとbからなっている。Aとa・bを結びつけるのは、工順Xである。工順Xは、作業1・作業2・作業3からなっている。各作業は、一つ以上のリソース（作業者・機械・工具・金型など）を必要とする。そして、製品を製造するための工順の集合をBOP＝「工程表」と呼ぶ。これが当サイトにおける用語とモデルである。

もっとも、もしかすると、あなたの会社の使っている用語とは異なるかもしれない（たとえば「工順」ではなく「工程」と呼ぶとか）。だが、日本には米国における「APICS Dictionary」のような生産管理分野の標準辞書が存在せず、業界各社バラバラなままなので、そこは我慢していただきたい。

さて、多くの企業において、設計部門は工場の生産部門とは別の拠点で、異なるITプラットフォームを使っている場合が多い。そのため、E-BOMからM-BOMへの展開が、整合性をとって行われにくくなる。整合性のキーとなるのは、品目マスタ（部品マスタ）の共通化である。設計部門と生産部門は、同じ材料を同じ品目コードで呼ぶ必要がある－－ここまでは、以前の記事でも書いたことだ。

ところで、先ほど述べた、製造部品表のない会社とは、どのようなケースか。それは、最終組立工程と検査・出荷輸送ぐらいしか、自社内でやらないメーカーだ。部品材料は全て、外部の下請けから購入する。こうした企業では、設計部品表と購買部品表は存在する（それがないと最終検査や資材調達ができない）。しかし、製造部品表は、設計部品表と構造が同一なので、あえて別に作る必要がなかった。

ただし、E-BOMでは同種の部品が複数箇所に使われている場合がある。購買用のP-BOMでは、同一品目は数量をまとめてサマリー化する（その方が価格ネゴがやりやすいので）。このため、E-BOMから材料ごとの数量をサマリーする作業が生じる。これをエンジニアリング業界などでは、Material Take-off（MTO）と呼ぶ。もちろん、CADで設計しているならば、MTOはCADシステムの機能を使う。

それにしてもなぜ、最終組立しか自社工場でやらないメーカーが存在するのか。それには歴史的背景がある。高度成長期には、ちょっとした工作機械や製造設備を持てば、下請け企業としてビジネスが成り立つ環境があった。このために、多数の零細な下請け部品加工業者が存在する、独特の産業構造ができた。最終消費財を作る大手メーカーは、部品はすべて下請けに作らせ、自社では設計と組立てだけを行う業態になっていったのだ。

最終製品のメーカーが、M-BOMを持たぬことで、何か不都合はあるのか？　昔は、なかった。しかし、時代の変化はこの状況をかえてしまった。

長い平成不況の時代を経て、単に製造設備だけで食っている下請けは淘汰された。現代に残っているのは、筋肉質な部品メーカーばかりである。彼らは中小企業とはいえ、技術開発力も磨いているし、取引先を一社に依存しないよう、販路も拡大している。

M-BOMは製造の「方法」に関する情報だ。部品レベルの詳細な製造方法を知らないと言う事は、品質や納期問題に対して、前向きな技術的対策が打てないと言う事でもある。最終製品メーカーに課題が生じたら、下請けに命じたり、競わせたりするしか手がない。だが今や、複数の取引先を開拓した部品メーカーからは、そっぽを向かれる結果に終わる。

また最終組立しかしないメーカーでは、製品競争力の中核になるコアの部品についても、外部サプライヤーに製造を依存している。それが入手困難になったり、他社に同等製品を売られる事態になったらどうするのか？　さらに、部品加工以前の製造現場を持たないので、製造好みの設計、つまり作りやすく品質が保ちやすい設計を、自社ですることができない。競争力の重要な源泉を握っていない、と言うことになる。こうしたメーカーが外注を内製に取り込もうとすると、とたんにM-BOM不在の問題に突き当たるのだ。

さて、M-BOMにまつわる二番目の問題として、生産技術部門の弱体化は、どう関係するのか？　それは、誰が製造部品表を作るのかを考えてみれば、わかる。M-BOMは工程展開の基準情報だ。製品から工程展開を行えるのは、製造工程を熟知している生産技術ないし生産管理部門である。

既に作ったことのある製品を、繰返し生産する場合は、マスタから自動的に展開できる。だから普通は生産管理部門の仕事になる。ところが、新製品や、仕様の変更を含む場合は、どうしたって生産技術部門の仕事になる。その結果は、次回以降も繰返し可能とするために、マスターに登録することが望ましい。

問題は、リーマンショック以来、多くの製造業で生産技術部の人員削減・弱体化が進んでいることだ。にもかかわらず、差別化を求めて、次々と新製品は繰り出され、試作品が工場に充満する。そんな状況下で、製造部品表の登録維持といった地味な仕事を、誰が魂を込めてやれるだろうか？　そういう仕事をちゃんと評価できる会社だったら、そもそも生産技術者を無理に削減したりはするまい。かくて、E-BOM/M-BOM乖離の問題が発生していく。

そして製造部品表を取り巻く第3の、そして多分一番重要な課題は、昨今の人手不足に起因した自動化やスマート工場への期待だろう。スマート工場においては、より精密で新しい製造部品表の概念が要求される。生産管理業務と製造実行システムでは、部品表の粒度が異なる場合が多いからだ。だが、このことに気がついている人はまだ少ないように感じられる。

ちなみに、ここで言っている「スマート工場」とは、藤野直明氏らが近著「小説・第4次産業革命」で皮肉っぽく指摘しているような、単に製造機械にセンサーをつけてAIで分析し、チョコ停を防止したりする試みのことではない。それはごく局所的なスマート化でしかない。

わたしが課題と考えるているのは、あくまでも工場全体の知能化を目指す、スマート化である。それは工場の中の機械・人・物の状態を、全体として把握することをねらう。また、非人間的な作業は極力、機械化・自動化する工場である。それによって、より生産性の高い操業状態を目指せるし、様々な変更やトラブルに、俊敏に対応できる能力を持つだろう。

そのような次世代のスマート工場の中核には、現在の製造実行システム(MES)をさらに発展させた、中央管制のための仕組みが登場するだろうと、わたしは予測している。そこでは、複数の製造機械や搬送機械を束ねて、協調制御するシステムが機能しているだろう。

ここで改めて、先ほどの図を見てほしい。1つの工順Xの中に3つの作業1・2・3が並んでいる。それぞれの作業は、異なる機械や人などのリソースを必要としている。

そして、各作業の加工それ自体も、作業間の搬送も、自動化されてるとしよう。機械だったら、賢い人間とは違って、それぞれにプログラムを作り、指示を与えなければいけない。搬送指示だって、どの物を、どこからどこにに搬送しろ、と言う命令を機械に下すことになる。

という事は、工場内を動くモノには全て、識別のためのIDが必要になるわけだ。IDを与えたら、それが具体的に何であるかも、認識できる必要がある。こうなると、1つの工順の中に3つの作業がある場合、対応する3つの品目が必要になる訳だ。

ところで、以前別の記事に書いたように、部品表と品目マスターへの登録は、在庫管理が必要かどうか、がカギになる。1つの工順の中で、作業1で作られて次の作業2にすぐ受け渡しされる品目は、通常は在庫管理の対象にならない（こうしたものをファントムと呼ぶ）。だから生産管理システムにおいては、工順内に作業が3つあっても、品目は1つ登録すればいい訳で、製造部品表は簡潔で済んだ。

そして、わたしが見たところ、多くの製造現場では、生産管理システムの中の工順のくくりは、比較的大きな単位でまとめられている。それは、製造工程のリードタイムを、時間や分単位ではなく、「日単位」で与えているところが多いからだ。これによって、製造の順序を決める権限を、製造現場にある程度委譲しているのである。

こうした工場では、製造現場は毎朝、その日にやるべき製造オーダーのリストを眺めて、着手順位を決める。変更やトラブルがあった際にも、現場側が製造オーダーの順番を見直して解決する。それによって、製造現場に自主性と責任感を与え、また、起こりがちな予定からの変更に柔軟に適応できる能力をつけるためだ。

これは特に繰り返し性の薄い個別受注生産や、仕様変更品が多い現場には有効である。また生産計画の精度が低く、リードタイムの見積が信頼できない場合にも必要だろう。

しかし、このやり方にも弱点がある。正味1時間で済むはずの作業も、最小リードタイムの設定が1日になる。だから、工程表を構成する工順の数が多くなると、全体の生産リードタイムが有意に長くなってしまう。これを避けるためには、できた端から次工程に運搬していく必要がある。ところが、次工程に部品材料が到着しても、製造オーダーは翌日の着手予定のままだ。だから製造日程表を、生産管理システムの外側で、人手で変更するか、あるいは運んでいった人間が、自分で次工程の作業もするか、いずれかである。かくて、特級品は担当者が自分で複数の作業区を渡り歩いて、加工していくような工場も存在する。いずれにせよ人間系依存で、ちっともスマートでない。

これに対し、自動化・機械化の進んだスマート工場では、より粒度の細かな製造部品表が要求されることがおわかりいただけると思う。

しかし、そんな細かなデータを、すでに限られた人員の中で、どうやって作れるだろうか?　もし設計部品表から製造部品表への自動展開の仕組みがあれば、便利だろう。ただし、それが実現するには、製品設計において、機能別モジュール化など、いくつかの前提条件が満たされなければならない。

もう一つの方法は、製造部品表にBOD（Bill of Distribution）の概念を応用することだ。つまり品種に位置の概念を取り込むのである。長くなったのでこれ以上の説明は省くが、いずれにせよスマート工場化は、製造部品表に対し、新しい挑戦的な課題を突きつけることになるだろう。

わたし達も、それに対応するための準備や研究を怠ってはいけないと思うのである。

＜関連エントリ＞
　→「スマート工場はスマートか? 」 https://brevis.exblog.jp/27295851/ （2018-05-26）
　→「広域サプライチェーンのためのPSI（生産・販売・在庫）計画と、その立案手法DRPとは」 https://brevis.exblog.jp/23466870/ （2015-07-25）

BOMデータのマスタと履歴を区別する

Tomoichi_Sato — Wed, 28 Aug 2019 23:17:49 +0900

どんな会社にも、従業員台帳というのがある。従業員の氏名・誰それ、その住所、生年月日、入社年度、職種といった情報が記されている台帳だ。同姓同名の場合もありうるから、普通は従業員番号も振られているはずである。
同じようにどんな会社にも、給与台帳と言うものがあるはずだ。従業員誰それに支払うべき月給はいくらいくら、といった金額が書いてある。

もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから2019年8月には、誰それに給料をいくらいくら支払った、という履歴も、台帳に残しているはずだ。

月々支払うべき基準としての給与と、毎月実際に支払うべき金額のリスト。どんな会社もこの2つを持っている。

それだけではない。会社によっては、実際にいくら支払ったかの履歴を、さらに別に持っている場合もある。例えば手当の一部が外貨建てである場合は、給与計算をした日と、実際に支払う日では、換算レートが違ったりする。だから、支払おうと決めた金額と、実際に支払った金額に若干の差が出るのである。外貨建て以外にも、現物支給などがあると、やはり実際の支払額が変わりうる。

標準としての給与額。支払おうと決めた決済の金額。そして、実際に支払った金額。この3種類は別のデータだ。だからコンピュータでこのデータを管理したいときには、3種類の別々のテーブルに、記録することになるだろう。

ITエンジニアは、標準としての給与額を記載したケーブルを、「マスタデータ」と呼ぶ。そして月々の支払い金額を消した2種類のテーブルは、あまり聞き慣れない名前かもしれないが、「トランザクション・データ」と呼ぶ。

マスタデータとトランザクションデータの違いは何か? マスタデータは、基準値だから、一旦登録するとそう頻繁には変わらない。給与台帳を更新するのは普通、年に1回位だ。

トランザクションデータの目的は、取引履歴の記録であることが多い。したがって取引が発生するごとに、頻繁に追記される。そのかわり、一旦記録したデータは、基本的には更新されない（例外はあるが）。「取引」と言う言葉を使ったが、これは商取引の意味には限らない。社内的な指示や報告は、データのやり取りであって、データ論的には取引にあたる。

それでは、部品表（BOM）データは、マスタだろうか、トランザクションだろうか？

ある種の人々にとっては自明なこの問いが、しばしば別の人々にとっては混乱の元となる。今回はこの問題を考えてみたい。

「生産とは、設計情報をモノ（媒体）に転写する活動である」、という言い方がある。ちょうど、生物の細胞の中で、DNAに書かれた遺伝情報が、分裂増殖のたびに転写され、新しい細胞が作られていくように。これは、元は東大のものづくり研究で著名な、藤本教授の発言である（たとえば、「ものづくり経営の今後」https://www.panasonic.com/jp/corporate/technology-design/ptj/pdf/v5503/p0202.pdf参照）。

そして、製造業にとってDNAにあたる「設計情報」の、中核にあるのがBOMデータだ。

である以上、BOMデータは製品の「あるべき姿」を示す基準であって、そうそう頻繁に変更されるものではない。だから、マスタデータに他ならない・・こう考える人が多いだろう。

果たして、そうだろうか？

ためしに、個別受注生産（受注設計生産）の場合を考えてみてほしい。造船だとか、産業機械だとか、宇宙ロケットといった、もの作りの分野だ。金型とか鉄骨建材なども、この部類に入る。こうした業種では、正式に受注してから、詳細な設計作業が始まる。顧客の要求する仕様は、毎回、個別だから、それに合わせて、機能や構造や制御方式を考え、決めていく。当然ながら個別受注生産では、受注時点でBOMが確定しておらず、設計が進むにつれてBOMが出来上がっていく。

このような業種のBOMは、マスタデータだろうか。もちろん、この設計情報が、工場でモノに転写され製品と化していく訳だから、一種の「基準情報」であることは間違いない。しかし、このBOMをデータベースに登録するとして、これはマスタだろうか。

マスタデータの条件は、頻繁に内容が更新されない事、だった。さて、この条件はどうか。いったん設計が確定し、出図されたら、そう簡単には変更されるべきではないし、変更されたら皆が困る。購買部門は注文したものを変更しなければならないし、製造部門は作りかけたものを手直ししなければならない。うん。だから、変更は少ないはず、と。

実際にこの業種に従事する人がここを読んだら、苦笑いするだろう。そんなことはない、現実には、ありがたくない変更が次から次に起こって、そこから発生する問題をどうボクメツするかが、生産管理の仕事の中心にあるのだ、と。

この事情は、ITエンジニアの読者の方には、受託開発のSIの仕事に類似している、といえば分かっていただけるだろう。SIプロジェクトでは、個別の要件に従って、毎回、要件定義と基本設計を行う。だが、上流工程で固まったはずの仕様が、しばしば実装テスト段階になっても変更を余儀なくされ、それとの闘いが仕事の後半戦の中心になるのだ。SIerの人達に、あなた方の設計図（たとえばモジュール構成図）は、マスタデータですか、と問うたら、どういう答えが返ってくるだろうか。

それに、上記の説明では、まるでBOMデータが設計の完了とともに、一気にワンセット出力されてくるようなイメージで書いた。しかし、現実はそうではないのだ。個別受注生産ではしばしば、コアとなる長納期部品があって、その周囲の部分から先に設計を固めていく。そして中核部分のBOMデータから順次、アウトプットされていく。そうしないと、購買手配が間に合わないからだ。

ある部分はすでに調達が走っているのに、別の部分はまだ設計作業を続けている。そういう並進フェーズがしばらく続く。その間は、BOMデータは順次、追加されていく。既存部分の変更も起きる。

しかも、こうした業種では、部品・材料自体、毎回、個別仕様で購買することが多い。さすがに汎用の材料を使う部分もあるが（とくにケーブルやパイプ・継手など）、こちらは長さ・個数など数量が、毎回、まちまちである。

したがって、こうした個別受注生産の業種では、BOMデータはマスタとして登録しがたいことが分かる。この分野のBOMデータは、購買や製造部門に対する指示であって、いわばトランザクションデータなのである。

しかも個別受注生産では、製造段階で思わぬ問題が生じ（主に設計変更に起因する）、その対応のために、最初の設計図とは違う形で、製造がおこなわれることも、しばしばある。そこで、出荷納品時に、あらためて設計図や設計情報を更新することも多い。これを「As-built」データと呼ぶ。世の中は「As-Is」と「To-Be」の2種類のモデルで割り切れる、と信じている類の人には、驚きだろうが。

As-builtのBOMデータは、「こう作りました」という製造実績を記録する履歴データ＝トランザクションである。これは、「こう作ってほしい」という設計のBOMデータと対になっている。個別受注生産の業種では、基本的に、
「製造指示のBOMデータ」
「製造実績のBOMデータ」
の2種類のトランザクション・データが存在し、もしもITシステムでデータベース化する際には、この2種類のテーブルを構築する必要がある。

では、マスタデータはないのか？　BOMのマスタデータは、ない。毎回異なるのだから。毎日違う人を雇って、実働時間に合わせて日給を支払う、日雇い労働の会社に、給与台帳など存在しないのと同じだ。

ただし、個別受注生産の業種でも、品目マスタ（部品材料マスタ）は作れるし、作るべきだとわたしは考えている。それは、調達業務や原価（＝見積）業務のコントロール水準を向上するために、役に立つからだ。もちろん、設計基準情報の共有・再利用という面でも、省力化に利するだろう。

しかし現実には、たとえそれなりの大企業であっても、品目マスタを持っていないケースを、しばしば見かける。毎回、個別仕様でまちまちの部品・材料の数量表を作って、調達やコスト見積を追いかけていくが、出荷して仕事が終わったら、誰かの机の中にファイルされて朽ちていく。データの使い捨てである。余談だが、個別性に生きるこの業界では、データの再利用とか、標準化の意識が低いように感じられる。過去の設計結果（履歴）のコピペで、もう十分「省力化」ができてると思っていたりする。

・・以上のような話を読んでも、「それは特殊な業界の話だろ」と思う読者は多いかもしれない。日本の製造業の花形は、自動車と家電、その周辺業界だ。こうした業界では、あらかじめきちんと設計された製品を、繰り返し量産していく。だからBOMデータはまさにDNAであり、マスタであるはずだ。一部の特殊な業種の病的な事例を挙げても、参考になるのか、と。

たしかに、繰返し生産型の工場では、ふつう、BOMデータはマスタとして保持している。それを元に、資材購買の手配や、部品在庫からのピッキングや、各工程への製造オーダーが発行される。個別の数量やタイミングは、需要（受注数）と在庫や進捗に応じて変わるだろうが、本来、製品が必要とする部品材料の員数は、不変である。

そしてBOMマスタは、設計に変更生じた時にのみ、更新される。設計は、何らかの仕様に変更が生じた時（ふつうは製品開発に伴って）に起きるだけのはずだ。これが正常なBOMデータの姿である、と。そう思われるかもしれない。

では、お伺いしたい。貴方が新品の自動車を買うとき、いろいろなオプションを指定し注文しなかっただろうか。新しいPCをネットで注文した時、ストレージやCPUやメモリを選ばなかっただろうか。これはすべて、個別仕様ではないか？

そう。個別仕様だ。だが、そのために、自動車メーカーやPCメーカーが、いちいち設計図を起こすようなことはしない。塗装の色もエアバッグもミッション部分も、すべて標準モジュール化され、組立て段階で選んで組みつければ良いようになっている。これを受注組立生産（ATO=Assemble to Order）による「マス・カスタマイゼーション」と呼び、先進的な業界の姿である、と。きっと新進気鋭のコンサルタントなら、そう反論するだろうなあ。

それで、個別仕様への対応を、オプションとモジュール構成で実現するATOの工場では、BOMデータはどうなっているのか。オーダー番号ABC0987の、佐藤氏の注文したPCは、どの部品とどの部品を組み合わせて作るのか。当然ながら受注システムから製造システムに対して、オーダー番号に紐づいて、データが受け渡される。内容は、使用すべき部品のリストである。これは、BOMのトランザクションそのものではないか。

見込生産・繰返し型受注生産で量産型なら、たしかに生産活動はBOMマスタの単純な転写と言っていい。しかしATO（受注組立生産）では、明らかに、個別のBOM指示が必要で、その履歴はトランザクションデータになる。（ついでに言うと、ATOでは、月度生産計画や部品調達計画のために、モジュラー型BOMも必要になるのだが、この話をすると長くなるので、興味がある方は拙著『BOM/部品表入門』第8章を参照してほしい）

そして、さらに言うならば、単純な繰返し型の生産形態は、今日の日本では少なくなった。単純な量産は、海外に出てしまって、日本国内に生き残っている工場の多くは、個別仕様だとか、試作品だとか小ロット特級品だとか、ちょっと厄介な仕事に対応することで稼いでいる。

そして、個別仕様を受け入れ始めるやいなや、必要とされるBOMデータは、マスタに登録されている標準品からずれていく。それを、個別のオーダーに紐づけて、記録していく必要が生じる。だから、BOMはマスタ以外に、製造オーダーに紐づくトランザクションデータも、持っておかねばならない。

BOMがマスタであるべき、という一種の思い込みは、現在の構造型BOMが、MRPという生産管理方式と一緒に生まれたことから生じているらしい。だが、本家欧米のMRPさえ、個別仕様に対応せざるを得なくなってきているし、実際、SAPの生産管理モジュールでさえ、ずいぶん以前（R/3の時代）から、生産オーダーにBOMを添付して発行する機能を持っていたと記憶する。

それだけではない。実際には、生産オーダーを受け取った製造現場側が、さまざまな理由から、その通り作れずに、部品材料を変更することがある。よくあるのは、サプライヤーの変更に伴い、部品材料が変わってしまうとか、部品のストック切れを待って、新しい仕様の部品に切り替えていくとかいった状況である。ほかにも、リソース（生産資源）の変更（加工機械を変える、など）もありうるし、工順の変更（外注に出す、など）もある。

こうしたことは、すべて、指示されたBOMデータからの変更であり、実績として別途、記録しておく必要がある。そうしないと、出荷後に品質問題が見つかったり、保守サービスの要求をもらった際に、実際に何と何でどう作っていたかを、追えなくなってしまうからである。

かくして、いわゆる繰返し受注生産型の業種であっても、結局、
・設計の姿としてのBOMのマスタデータ
・製造指示としてのBOMの履歴（トランザクション）データ
・製造実績としてのBOMの履歴（トランザクション）データ
の3種類のBOMデータベースが必要になる訳である。

そして、これこそが、いわゆる「E-BOMとM-BOMの乖離問題」を防ぐ、予防線の一つなのだ。E-BOM/M-BOMの乖離が生じる原因はいくつかあるが、その重要な一つが、設計図と、実際の製造にズレが生じることにある。ズレの原因は、上述のように、個別仕様への対応の場合もあれば、部品在庫の都合もあるし、様々だ。だが、ズレが生じるのが、現実だ。その現実を、BOMマスタ一つだと、救いきれなくなる。

だから、BOMデータベースには、原則として、3種類が必要になる、と最初から考えてDB設計する方がいい。これは、落ち着いて考えれば当たり前の話であって、だからわたしは『BOM/部品表入門』の冒頭、プロローグにこの図を入れたのである。

だが、BOMデータのマスタとトランザクションの区別（併用）という考え方は、未だに必ずしも普及していないようだ。つい最近も、ある大手IT企業の資料の中に、「E-BOMとM-BOMの乖離問題は、見込生産や繰返し受注生産に起きやすい。個別受注生産ではこの問題は生じない」という見解が書いてあって、驚いた。わたしの誤解かもしれないけれど、この会社は、E-BOM/M-BOM問題と、マスタ/トランザクションの区別を、なんだか一緒くたに論じているのではないかと思えたのである。

こうした議論の混乱が生じる一因は、マスタデータというものが、「再利用可能なデータの格納場所である」という理解が不足していることにもあるのではないか。マスタデータは、単に更新頻度が少ないデータの置き場所ではないのだ。データを「再利用可能」な姿にブラッシュアップして、それを皆が共有し参照できるようにするため、台帳としてのマスタを作るのである。

マネジメントとは、PDCAサイクルを回すことだけではない。個別性の高い仕事を、繰り返し可能にし、再利用可能にし、標準化することもマネジメントなのだ。もちろん、そのためのデータのマネジメントだって含まれる。

マネジメントとは、結果（製品）だけ出せば良いのではない。仕事を個人に依存しない、インパーソナルな仕組みに作り上げることである。仕事を、個人の知識や経験値に依存した、属人的なものに留める段階にとどまっているならば、その組織は、いつまでたっても、新しい能力を共有することができないだろう。

では、製品種別が増え、個別仕様が増え、受注設計生産を余儀なくされている現代の製造業にとって、BOMデータのマネジメントはどうあるべきか。それを考えるための有償セミナーを、12月にもう一度、アンコールで実施することになった。長い記事の最後に、宣伝めいた終わり方で恐縮だが、もしこの主題に関心がおありになる方がいたら、下記のURLをのぞいて、ご検討いただきたい。

2019年12月17日(火) 10:30 ~ 17:30
ＢＯＭ／部品表の基礎と効果的な活用ノウハウ
https://www.j-techno.co.jp/seminar/seminar-31675/

もちろん、佐藤の考え方には賛成できない、反論を述べたい、という方も大歓迎である（笑）。ちゃんと議論して、わたし達の社会の製造業のレベルアップに、ぜひ一緒に寄与しようではないか。

＜関連エントリ＞
　→「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」 https://brevis.exblog.jp/24157732/ （2016-02-21）
　→「オプションが多数ある製品のBOMは、どう構成すべきか」 https://brevis.exblog.jp/21404200/ （2013-12-02）