生産マネジメント ワンポイント講義 (その5)

生産計画・スケジューリング、部品表(BOM)、サプライチェーン・マネジメント(SCM)などの分野で理解すべき用語と概念を解説しています。



BOM(部品表)

コミュニケーションの基盤としてのBOM=部品表

拙著『BOM/部品表入門 』(日本能率協会マネジメントセンター刊)が増刷になり、累計5,000部の出荷となった。専門書としては堅実な部類に入る数字だ。これまで読んでいただいた多くの方に深く感謝したい。執筆に着手した段階では、BOMを主題とした本はほとんど出ていなかった。今では何冊も出版されているので、おそらく読者ニーズの時宜にかなったのでは、と思う。

本書は山崎誠氏との共著だが、全体構成と本文の8割を私が執筆した。2000年に出版した『革新的生産スケジューリング入門―“時間の悩み”を解く手法』の続編という位置づけで、同じ登場人物の「矢口先生」が、今度は大学ではなく企業に出張講義するスタイルで書かせてもらった。私はなぜか、一方的な叙述よりも、対話的な文章の方が書きやすいのである。

ところで、本書の執筆には1年ほどかかったが、書くにつれて、自分自身BOMに関する認識の深化していくのを感じていた。じつは、書き始めたときは、ERP技術者向きの本にするつもりだったのだ。それなのに、書き終わる頃には、まったく別の意図をもった本になっていた。そのメッセージとは、こうだ:「BOMデータを、特定のパッケージや外部コード体系に依存するべきではない」。なぜなら、広義のBOMとは、生産に関する企業内コミュニケーションの基盤であり、製造業のすりあわせ的統合の要(かなめ)となるからだ−−

BOMの問題に気づいたのは、生産スケジューリングの仕事にいくつかたずさわるようになってからだった。じっさい、多くの企業でスケジューラ導入時にぶつかる主要な困難が、BOMデータの構築なのだ。スケジューラはお金を出せば一応、買える。しかし自社の部品表データは、世の中のどこにも売っていない。だから自分たちで整理するしかない。上の方の偉い人は、“そんなのソフトウェア・ベンダーにやってもらえばいいだろう”などと無責任に発想するが、現実を知っている技術者はそうはいかない。まして、「設計部門と製造部門で持っているBOMが違っているんです」なんて、コワくて報告できたものではない。

MRPUをベースにしたERPパッケージの生産管理システムの場合、ある意味で問題はもっと深刻だ。MRPのスケジューリングは、タイム・バケットと標準リードタイムと無限負荷計画が生み出す、ラフな近似でしかない。近似は近似として使いこなせばいいのだが、困ったことにERPは原価管理に主眼がある。ERPのもつ奇妙な厳格さが、ここでは足かせとなってしまう。たとえば、製品を構成する部品を全部きちんとリストアップしないと、正しい原価がつかめない。購買オーダーも出てこない。つまり、おなじ部品表というマスタを見る視点が、違う粒度を持っているのだ。

一つの会社の中で、相矛盾する複数の部品表が生まれてしまう原因は、複数の機能部門が、異なる目的と粒度でBOMを見ているためである。BOMはもともと、資材購買の必要性から生まれ、ついで生産計画の主要概念になった。そこから派生して、設計・生産技術・生産管理・購買・在庫・製造・物流・保守・サービス・IT・営業・財務と、あらゆる部門が大なり小なり関わるハブ的な存在となっている。

そこで、『BOM/部品表入門 』では、各々がいかなる視点からBOMをながめ、そこにどのような要件を持っているかを解説することで、BOMをとりまく課題を多角的に示そうとしたのである。そして、その結果としてたどりついたのが、「BOMプロセッサ」の発想である。企業内コミュニケーションの基盤情報をコントロールするための、アプリケーションから独立した一種のデータベースが必要だ、というのが私の結論だ。

一種のデータベースであるから、できれば標準スキーマを示すべきなのだろう。しかし、いろいろ考えた末、本書ではスキーマを書くのはやめてしまった。製造業は多様である。BOMはプロセス生産から切替え型連続生産をへて組立加工生産まで、あらゆる生産形態に存在する。それらの最大公約数的なスキーマを提示しても、誰の役にも立たないからだ。むしろ、その企業固有の思想を反映するかたちで、各企業がスキーマを自分で考えるべきだと私は信じる。
(とはいえ、何かテンプレートとなるものがあると助かる人は多いと思う。この点で、私は渡辺幸三氏の仕事=Conceptware 生産管理に期待している)

この本では、まだ書き残した部分も多い。たとえば:
・設計ブロックと製造ユニット
・トランザクションBOMデータの内容とマスタからの変換
・個別受注生産のBOMの問題
などだ。こうした点については、どこかでおいおい書いていきたい。

企業内のBOMとマテリアル・マスタの統合は、今日のサプライチェーン問題を解決する最重要課題である。そのためには、企業内に、BOMの登録とライフサイクルをつかさどる、クロス・ファンクショナルな機能が必要になる。BOMに関してだけは、どこからか『解決策』を買ってくることはできない。自分たちで解決するしかないのだ。拙著が、そのわずかな助けにでもなれば幸いである。


→「革新的生産スケジューリング入門」にもどる

製造業とITをつなぐミッシングリンク − BOM(部品表)の問題 (2013/10/09)

最近、拙著「BOM/部品表入門 (図解でわかる生産の実務)」の重版の知らせを出版社から受け取った。累計7,400部になるらしい。発刊が2005年初頭だから、8年間かかってやっとこれだけの数字だ。でも、ビジネス書は3千部売れれば及第点のレベルと言われから、まあまあの部類ではあるだろう。多くの方に受け入れていただけたことに、感謝したい。それに、編集担当の方によると、8年以上もの期間にわたってジワジワ売れ続けるのは、こうした分野では珍しいらしい。

それにしても、最近、あらためてBOMが関心を集め直しているのではないか、と感じることがある。今年は二回もBOMに関して講演の依頼を受けているし、本書の増刷もある。もっと驚いたのは、数ヶ月前だが、電車ですぐ隣の人が「BOM/部品表入門」を読んでいたことである。本は何冊か書いているが、初めての体験だ。思わず、「著者ですが」と挨拶をしてしまった(^^;)。相手の方は、SI業界の方で、BOMに関して勉強するため読み始めたとのことだった。

本を書き始めた2004年の頃は、BOMに対する関心が産業界で高まっている時期だった。自動車会社が膨大な労力と費用をかけてBOMを再統一するプロジェクトをはじめたり、電機メーカーが大変な苦労をして部品の品番統一を行ったり、というニュースが報じられた。また本書に前後して、やはりBOM関係の著書や訳書が刊行されたりしていた。

ところがその後、しばらく鎮静期というか、BOMがあまりメディアに取り上げられなくなる時期が続く。そして最近になってまた、再び注目が集まっているように感じられる。これは、何故だろうか?

その答えを考える前に、ちょっとここで読者諸賢にクイズを出してみたい。以下の問に、みなさんならどう答えられるだろうか。いずれも、日本の製造業の姿をあらわす数字だ:

 GDPに占める製造業の割合 = ? %
 製造業ではたらく就業者数 =  ? 万人
 製造業の従業員あたりIT費用 = ? 万円/年

これらの質問は、今年3月に開催した「プロジェクト&プログラム・アナリシス研究部会」でBOMに関する講演をしたとき、イントロに使った問題である。さて、日本全体のGDPに占める製造業の比率は、何%か。“ものづくり日本”と謳われ、製造業が日本の産業をリードする、あるいは輸出の主軸である、と考えられているわたし達の経済で、さてどれくらいの割合を占めているのか。半分? 7割? それとももうちょっと小さく4割程度?

じつは、日本のGDPの中の製造業の比率は、2008年に19.8%となり、すでに2割を切ったのである。意外に思われる方も多いだろう。モノづくりが倒れたら日本が滅びる、みたいな論調をよく聞かされるが、ちょっとオーバーなことが分かる。メディアも感覚論だけでなく、こうした数字をおさえて報じてくれるといいのにな、と思わないでもない。

なお、ドイツの製造業GDP比率=25%、米国=12%、EU平均=20%である。ドイツはさすがに今でも製造業大国だと分かる。米国の製造業の衰退は、残念ながら数字から見ても本当である。日本はEU全体の平均に近い。

ただ、2割を切ったといっても、日本はGDP規模でまだ世界第三位の経済大国であり、他国と比較すると、やはり大きい。ちなみに日本のGDPは約480兆円。計算がしやすいように、だいたい500兆円と覚えておこう。製造業はその2割だから、毎年100兆円も稼いでいるのだ。ちょっとした国の経済規模より、ずっと大きい。

では、二番目の問は? 研究部会では「5万人くらいかな」と答えた方がおられたが、それでは少なすぎる(トヨタ一社だってそれより多い)。こういう問題を考えるには、概算と類推を活用する必要がある。いわゆる「フェルミ推定」である。GDPに占める製造業の割合は、2割だと分かった。日本の人口は、1億2千数百万だ。ここも、計算が簡単なように、1億2千5百万人と記憶しておこう。そうすると、その2割=1/5だから、2千5百万人が製造業のカバー範囲か。ただし、これは赤ん坊からお年寄りまで、全人口が入っている。就業者となると、生産年齢で、失業者ものぞかなくてはならない。エイヤっと半分にして、1,250万人でどうだ!

ま、惜しいところである。実際の答えは、1,030万人なのだ(2010年度の統計)。ちなみに日本全体の全就業者数は、6,246万人である。総人口の約半分で、ここのエイヤは合っていた。どこが違ったかというと、GDP比率と比例していない点だ。6,246万人中の1,030万人は、16.5%にあたる。製造業は、GDPでは全体の1/5だが、就業者数では1/6しかいないのである。

GDP比率よりも就業者比率の方が小さい。これはすなわち、製造業の方が一人あたりでは余計に付加価値を稼いでいることを示している。経済効率が高いのである。他の産業、すなわち流通業やサービス業などの方が、一人あたりの生産性が少し低い。

それでは第三問、製造業の従業員あたりIT費用は年間でいくらか? 答えをいってしまうと、43.2万円(2010年)である。これは多いと思われるだろうか、それとも少ないだろうか? これも、他と比較すると分かる。全産業平均のIT費用=57.8万円/人・年なのである。「いや、俺、そんなに使ってないから」などといわないでほしい。これは、配備パソコンの購入代金から、基幹システムの開発運用費、保守その他の労務費外注費、デジタル通信費用まですべて含めた金額なのだ。ユーザの目に見えない費用が全部含まれていることに注意してほしい。

さて、全産業の平均に比べると、製造業は75%、つまり3/4しかIT費用が使われていないことが分かった。問題は、これを、どう見るかだ。製造業はITを効率よくつかっているから、一人あたりの費用が少ない? わたしは、そう見ない。工場現場労働者というブルーカラー職種の人数まで入っているから、平均値が下がっている? だが、流通サービス業だって、相当に単純労働者を抱えている。他業種は派遣や外注など非正規雇用者を多用しているから、分母が小さい? いや、分母は正社員数ではなく就業者数であることに注意してほしい。

わたしの見方は、もっと単純である。製造業は、必要なIT費用を十分に使っていないのだ。どれだけ必要かは、無論、業態による。業種の中で最高なのは金融保険業の163.2万円だが、製造業はそのわずか1/4である。では、製造業の業務は金融や流通よりもずっと単純なのか? そんなことはない。むしろ、業務プロセスの幅でいうと、製造業は流通やサービス業よりも、ずっと大きい。受注・設計・製造・検査・物流・保全・販売・購買・在庫・経理・人事・・・(流通業は、これらの内、販売以降の部分だけをカバーすればすむ)。つまり、製造業の情報化は、業務が多くて複雑なのだ。

製造業にIT化費用の支払い能力がない、単価が安い、という訳でもない。わたしの経験では、流通業よりもむしろ発注の査定はリーズナブルである。だったら、なぜSIerはもっと製造業をターゲットにしないのか? いい顧客ではないか。

その大きな理由は、じつは「製造」という業務に対する敷居の高さにある、とわたしは見ている。会計や、販売管理や、発注検収システムを得意とするIT会社はたくさんある。しかし、製造となると急に出足が止まる。なんだかややこしいし、製造現場はうるさくて煙臭くて縁遠い。だいいち工場なんて妙に不便な田舎にあるじゃないか。

おかしなことに、肝心の製造業の情報システム部門の人たちも、しばしばそう感じているらしい。本社でERPやCADシステムを導入することには熱心でも、工場の製造実行システム(MES)などは案外、製造部門任せだったりする。製造部では、若手でちょっとパソコンに詳しいような技術者が、見よう見まねで設計書を書いて開発したりする。これできちんと情報化が進むわけがない。その結果が43.2万円なのだろう。

そのようなやり方は、そろそろ限界に近づいている。なぜなら製造の海外展開が近年急速に進んで、部品・製品のサプライチェーンが工場の壁をまたいで海外まで伸びてしまったからだ。おかげで、どこに何がいくつあって、どれをいくつ作ればいいか、ひと目で分からなくなってしまった。製造業の計画の鍵、中心となるマスタデータはBOM(部品表)である。この部品表という革袋が古くなって、海外展開という新しい酒を入れることができなくなってきたのである。

だったらば、そろそろITのプロに任せればいいじゃないか。製造業が全産業の平均並みにIT費用を使うとすると、57.8―43.2=14.6万円/人・年の潜在需要がそこにあるはずだ。就業者数1,030万人をかければ、毎年約1.5兆円の市場である。これは、IT産業から見ても、非常に良いマーケットだろう。大丈夫、製造業は年間100兆円のGDPを生み出している。念のためにいうが、売上100兆円ではない。付加価値額の合計が100兆円なのである。1.5兆なんて、そのわずか1.5%にすぎない。もし、1.5%のIT投資をして、それで年間3%の生産性アップが得られるなら、ものすごく引き合う話ではないか。

じつは、その素晴らしい見合い話で問題となるのが、BOM/部品表なのだ。多くのシステム屋さんの「躓きの石」が、部品表らしい。なんだか構造もややこしいし、数も種類も多くて訳わからない・・。

別に、そんなことはないのですよ。たしかに見かけはややこしいけれど、それは顧客のデータモデルがしっかりしていないだけかもしれない(だってITのプロが作ってこなかったのだから)。だから、そこさえきちんと押さえれば、あとは論理的に展開できる。そして、製造業のいいところは、業務が理屈どおり進むことなのだ。

わたしは自分の本が売りたくて、こんなことを書いているのではない。日本の製造業は今、明らかに質的転換の曲がり角に来ている。贅肉体質の企業はすでに淘汰が進み、よく考えて行動しているところが(規模の大小にかかわらず)生き延びる時代に入っている。そのボトルネックは、製造・物流のIT化なのだ。わたしはぜひ追加の1.5兆円市場が生まれて、それがGDP全体の拡大に寄与するようになることを望んでいる。その動きに、拙著がちょっとでも貢献できれば、望外の喜びなのである。

→「革新的生産スケジューリング入門」にもどる

生産革新のためのBOM(部品表)再構築入門 (2013/11/04)

数年前、三菱電機から依頼を受けて、「e-F@ctory」という同社のWebサイトに、BOM(部品表)に関する文章を書いた。今はそのurlはリンク切れになっており、同社のサイトを検索しても見つからない。サイトのリフォームにともない、この種の一般解説的文章は削除されたのだろう。そこで、当時の文章を、一部ブラッシュアップして、ここに再掲することにする。内容的にはとくに古くなってしまった部分も見あたらない。製造業におけるBOM(部品表)の構築と改善は、いつでも古くて新しい課題なのである。なお、ここでは分量の関係で2回に分けて掲載する。

<今、なぜBOMが問題なのか>

不況の長いトンネルを抜けて、いま日本の製造業は元気を取り戻しつつある。そして多くの企業で、この機会に生産全体のあり方を見直したい、という気運が高まっているようだ。

製造業とは、物品(マテリアル)を産出・加工し、付加価値をつけて販売するビジネスだ。その資材調達から出荷までの加工と物流の仕組み、ならびに受注から納品までの情報の流し方を総称して、「生産システム」と呼ぶ。

そしてBOM(Bill of Material=部品表)とは、その生産システムのDNAである。BOMとは、製品がどの部品資材から成り立ち、どのような手順をへて組み上げられるかを規定する、生産の基準情報だ。生命がDNAの遺伝情報をもとに細胞や体を組み立てていくように、製造業は基準情報としてのBOMにしたがって、資材から製品を組み立てていく。

ところが近年、そのBOMデータの内容に問題がある、と考える会社が増えている。数万点に及ぶBOMと部品マスタを作り直した電子機器メーカー、2年近くかけて配管材料コード体系を再構築したプラントメーカー、設計思想に立ち戻ってBOMを再構成しようと奮闘中の機械メーカー等、多大な時間と労力をかけて見直す動きが、業界を問わず進んでいる。いったい、なぜだろうか。

それは、生産のDNAであるべきBOMの情報が混乱し、社内のあちこちに、複数の相矛盾するBOMが乱立したり、あるいは基準の役を果たせずに毎回使い捨てにされたりする事象が起きているからだ。

なぜBOMが分裂するのか。皮肉なことだが、BOM情報を必要とする部門がきわめて多いからだ。BOMとマテリアル・マスタには、部品構成以外に工程や原価やリードタイムや購入先やオプションや保守履歴など、多種多様な情報が関係している。いわばBOMは企業内の情報のハブなのである(下図)。にもかかわらず、縦割り組織や分業病の影響で、社内にBOMを統一的に保守する責任部署が存在しないケースが多いのだ。

BOMが混乱してくると、新製品の投入や設計変更の実施スピードが、確実に遅くなる。そればかりか、工場の生産量を拡大したり、海外にグローバル展開をはかったりする際に、とんでもない副作用が出てくる−−部品点数と部品在庫量の無秩序な増大である。工場の中はモノが有り余ったいるにもかかわらず、必要なものが見つからない、という状態になる。企業内のサプライチェーン・マネジメントが運用不能になるのだ。こうして、直接製造作業に関わらない間接工数ばかりが増えていく。結末は、原価上昇による赤字である。

<ERPパッケージはBOM問題を解決できるか>

この状態を解決するために、ERPなど基幹情報システムの導入に期待する人もいる。たいていのERPパッケージの生産管理機能は、MRP(=Material Requirement Planning)の考え方がベースになっており、その中核にはBOMマスタがあるからだ。

だが、ちょっと待ってほしい。そもそも製造現場で一度も働いたことのない若き“ERPコンサルタント”たちに、BOMの作り方や生産システムの動かし方など本当に分かるのか? じっさい、多くのプロジェクトで、「BOMデータの作成はお客様の責任です」と言われ、導入直前の1ヶ月間で急ごしらえのBOMをばたばたと登録するだけで終わっている。

そもそもMRPは規格品見込み生産・大ロット・余裕ある標準リードタイム・豊富な機械設備などを前提とした、'70年代米国の生産思想の産物だ。個別仕様・超短納期・ぎりぎりの工場設備、そして受注/見込み生産混在の自分の会社に、どうフィットしたらよいのか?

生産管理の観点から日本とアメリカの企業を比べてみると、その違いにしばしば驚かされる。米国製造業の特徴は、抜きがたい大量見込み生産指向である。標準品・大ロット生産による生産効率をあくまで追求したがる。これに対してわが国の特徴は、小ロット・プル型を中心としたリーン生産方式であり、また顧客要求へのきめ細かな対応である。個別対応の傾向は、とくに消費財よりも生産財において明瞭だ。生産財の取引においては、産業機械であれ電子部品であれ化学素材であれ、買い手は際限ない個別仕様を要求してくるのが常である。サプライヤーはしたがって、受注生産の形態を強いられる。

そこで受注生産の業界では、ユーザが浜の真砂のごとく出してくる個別要求に応えるため、個別設計のサービス能力が決め手になる−−多くの人が、そう信じている。いかにも日本得意の「すりあわせ型」文化である。しかし、個別設計を続ける限り、企業の中のBOMの数は無際限に増えていく。なぜなら、BOMというのは、一種類の最終製品につき、一つずつ必要だからだ。「あとは類推で考えてくれ」という訳にいかないのが、生産システムのDNAたるBOMの宿命だ。まして、個別設計ということは、見積や受注の時点ではBOMが確定しておらず、BOMの作成と資材発注が並行して進むということだ。従来のMRPではとても対応できない流れである。

<受注生産とBOMのあり方>

ところで、生産システム効率化のための定石は、いうまでもなく「標準化」と「平準化」にある。設計における部品構成や図面の標準化、生産における能力や負荷の平準化によってこそ、生産性の向上が計れるのだ。しかし毎回、設計図面からBOMを起こすやり方では、標準も平準も困難で、とても競争力が保てない。それでは、どうすべきか。

先進的な企業は、その答えを、モジュール化とATO生産方式に求めている。

モジュール化とは何か。それは、製品を機能単位の要素(モジュール)に分解し、その組み合わせによって仕様のバリエーションを実現する考え方である。たとえば、パソコンは筐体・マザーボード・CPU・HDD・モニタ・キーボードなどから組み立てられるが、CPUの速度、HDDの容量などの組合せにより、膨大な仕様のバリエーションが生まれる。

そこで、無限にも思える要求仕様を、比較的少数のモジュールから組立てられれば、中間部品レベルでの標準化が可能になる。これを『バリエーション・リダクション』の発想と呼ぶ。

さらに、素材部品ではなくモジュール(中間部品)の形で在庫を持っておき、注文を受けたら即座にモジュールを組立てて出荷する方式が考えられる。これなら、モジュール製造工程の平準化も可能になる。これが、ATO(Assemble to Order)生産方式である。

すなわち、受注生産と一口に言っても、じつは下記の3種類があるのだ。
(1)設計から始まる、ETO(Engineer to Order)=個別受注生産、
(2)受注後に部品手配からはじめる、MTO(Make to Stock)=繰り返し受注生産
(3)モジュール化が前提の、ATO(Assemble to Order)=受注組立生産
さらに、これに消費財で普通行われる見込み生産が加わる
(4)需要予測にもとづき製品を作りだめする、MTS(Make to Stock)=見込生産

そして、今や少なからぬ先進的企業が、ATO生産方式を目指そうとしている。理由は、ETOやMTOでは受注リードタイムが長くなりすぎ、また標準化・平準化ができないため競争力が上がらないからだ。逆にMTSでは製品在庫のリスクが大きくなりすぎる。だから、生産財・消費財を問わず、ATOに向かう潮流があるのだ。

無論、モジュール化とATOを実現するためには、各モジュール間で組合せのインタフェースを規格化することが大事な条件である。したがって、その実現のためには、設計を根本から見直す必要があり、BOMの姿にも改革が求められるのである。(この項つづく

→「革新的生産スケジューリング入門」にもどる

生産革新のためのBOM(部品表)再構築入門(2) (2013/11/11)

<設計部品表(E-BOM)と製造部品表(M-BOM)の乖離>

BOM再構築の課題の中でも、もっとも多く見られる悩みが「設計部品表と製造部品表の乖離」だ。ふつう、前者はEngineering BOMを略してE-BOMと呼び、後者をManufacturing BOMの略でM-BOMと呼ぶ。

設 計部品表(E-BOM)とは、設計部門が作成する部品表のことで、最終製品を構成する全部品をリストアップしたものである。製品の構成図(断面図)の各部 品に@AB・・といった番号をつけ、その右側に番号・部品名称のリストをつけたものを、誰しも見たことがあると思う。この部品構成リストがE-BOMの原 型である。

たとえば、『冷し中華』という製品を考えてみよう。冷し中華一人前は、図1左に示すように、茹で麺・たれ・錦糸玉子・チャーシュー細切・きゅうり細切から組み立てられる。

機械・電気など組立加工系の業種におけるE-BOMは、最終組立に使う部品のリストであるため、伝統的にはしばしば、部品間の階層構造を持たない「サマリー型部品表」の形をしていた。もっとも、現代のインテリジェントなCADシステムは、自動的に部品リストをE-BOMとして出力する機能もある。さらに必要ならば、製品→モジュール→サブモジュール→部品、という階層構造を定義することもできる。

と ころが、工場はこのE-BOMだけでは仕事ができない。冷し中華の例で端的にいえば、材料の手配はどうしたらいいのか? まさか茹でたての麺を毎回買って くるわけにも行くまい。購買には、図1右に示すような購入材料リストが必要である(これを購買BOMと呼ぶこともある)。

 [図1 設計BOMと購買BOM]

E-BOMから、購入材料リストを作成するためには、それぞれの部品をどんな材料からどのよ うな手順で製造するかを示す表が必要になる(図2)。これを製造部品表(M-BOM)と呼ぶ。製造部品表は、通常は生産技術部門による工程設計の結果とし て作成され、主に製造現場において生産管理で用いる。

M-BOMの特徴は、部品の親子関係を示す「ストラクチャー型部品表」 の形になることだ。また、工順(Routing=加工順序)の情報が付加される。生産管理にMRPシステムを用いている企業では、さらに親子関係に「標準 リードタイム」を設定し、生産スケジューリングに利用する。このM-BOMは、生産技術部門がE-BOMを元に作成するケースが多い。

 [図2 製造部品表(M-BOM)]

それでは、なぜ多くの企業がE-BOMとM-BOMの乖離に悩んでいるのか。その理由は、大きく4つある。

(1)品目コードの不統一

本 社設計部門では、部品コードを定めずに「部品の図番」や「部品規格番号」や「名称」だけで済ませる場合がある。一方、工場では購買先を決めてから品目マス タを登録するケースが多い。その段階で、はじめて部品に品目コード(Part Number)がふられる。この品目コードは、本来であれば本社設計部門に伝達され、図面やCADの属性に登録されるべきだが、部品点数は多いし、マスタ 登録のタイミングはバラバラだし、おまけにしばしばマイナーチェンジが行われたりするので、実際にはなかなか簡単ではない。

その結果、全社で品目のコード体系の統一がとれなくなり、E-BOMからM-BOMへの「翻訳」作業が必要になってしまう。しかし、これでは手間がかかるし、誤りが入り込みやすくなる。

(2)代替部品の使用

材料手配の都合上、工場では一時的な代替部品を使用することがある。サプライヤー側や購買・外注の都合で素材・品番が変わることもある(この事情は、とくに海外工場に多い)。そのため、設計と現物に食い違いが生じてくるのである。

(3)副資材や包装材料の追加

製品設計図には、副資材や包装材料はふつう記載されないため、E-BOMにないことが多い。したがって、工場では手配が必要になる。したがって、独自にM-BOMに追加せざるを得ない。

(4)設計変更の発生と在庫切替タイミングの食い違い

設 計部門において仕様改訂や品質改善のため設計変更が発生した場合、本来はM-BOM側も同期して修正すべきである。しかし、工場は仕掛りや部品在庫のため に、M-BOMをすぐには切り替えられない。「手元にある在庫を使い切ってから修正しよう」などと考えている内に、次の設計変更通知が来たりする。

こうして、いったんE-BOMとM-BOMが乖離しはじめると、問題点がいろいろ発生してくる。まず、新製品導入スピードが遅くなる。また、品質クレームやアフターサービス対応が難しくなる。どのロットはどんな部品構成で作ったか、トレースできなくなるからだ。

中でも、もっとも深刻なのは(1)の品目コードの不統一である。企業のマテリアル・マネジメントが混乱し、モノが有り余っているのに必要なモノがない、という状態が生じてくる。コードが無ければ設計の標準化も困難だ。モジュール化や、前回述べたATO生産方式(Assemble to Order=受注組立生産)の実現は夢物語になる。

それでは、どうすべきか。この背景には、開発設計と生産現場の乖離がある。マネジメント・レベルで、まず問題認識が必要であろう。その上で、BOM維持体制と責任分担の確立、品目コード体系の統一、そして適切なBOMプロセッサの導入などの施策が必要になるのである。

<BOM再構築プロジェクトのために>

市場が回復中の機をとらえ、今日、多くの企業が生産の革新にチャレンジしている。その鍵がBOMの再構築にあることを、これまでの話でご理解いただけたと思う。

需 要は増えてきたのに、思ったように増産できない企業がある。第一の理由は、仕様の個別対応の手間が多くて、設計部門がボトルネックになっためである。第二 の理由は、部品マスタの無秩序な増大や変更で、資材購買と在庫管理が混乱するからだ。材料が無ければ工場はモノを作れない。第三の理由は、標準モジュール 化の欠如で、工場の負荷平準化が困難なことにある。これらはすべて、BOMに関わる問題だ。

BOMの問題は、生産のグローバル展開の 足かせにもなってきた。なぜ、国ごとに違う図番体系や品目コードになってしまうのか? マスタが欠如していたからである。あの自動車産業でさえ、国別仕様 と供給可能部品によって生じたバラエティに悩んできた。いまから10年近く前、トヨタは社内に4種類のBOMをかかえており、その一元化と再構築のため に、驚くほど巨額の費用と工数をかけてとりくまざるをえなかった。

ちあみに、正確に言うとBOMは『部品表』ではない。部品表という日本 語は、何となく組立加工産業のみを連想させる。しかし「部品」に縁のない食品・素材・化学・電子材料・医薬品・アパレル業界などでも、BOM(Bill of Material=マテリアルの集計表)は存在するし、同じように重要なのである。

それでは、どうしたらBOMの再構築が進められるのか。

まず、第一に、これは情報技術だけの問題ではない、 と強調しておきたい。複数のデータベースをつなぐツールや、ERP・PDMパッケージ等の導入で、事足れりと考えないこと。むしろ、BOMの運用ルールこ そ問題なのだ。誰が、何をいつ登録するのか。どうメンテしていくのか。いつ廃止にするのか。いかに標準化をはかるのか。設計(E-BOM)と製造(M- BOM)の乖離をどう防ぐのか。運用ポリシーがあって初めて、必要なITツールが決まる。

もうひとつ重要なことは、あるべきBOMのマスタと、現実のBOM履歴データを区別することだ。設計はBOMのあるべき姿を規定する。これ はマスタだ。しかし、製造の現実では、様々な理由から代替部品を使ったり、歩留りのために予定以上の材料を使ったりする。顧客サービスや在庫管理のために は、個別の履歴をとっておく必要がある。つまり、製造指図や製造報告に付随したBOMのトランザクション・データを、マスタとは別に持つべきなのだ。

そして、何よりも大事なことは、中心となる『マテリアル・マスタ』の再統一だ。これを部品マスタ、あるいは品目マスタなどと呼ぶ会社もある。呼び名はどうあれ、設計・購買・生産技術・工務・製造・物流・・すべての部門が使用し関係している基準データだ。これがバラバラの状態を放置してはいけない。

BOM 再構築プロジェクトのあり方は企業の状況や生産形態によって様々だが、その流れの一例を、図4に示す。いずれの場合でも、最初に着手すべきは、何のために BOMを再構築するのか、どのような問題を解決し、どんな能力を得るために行うのかを明確化する事である。これを、経営トップや企画部門が中心になって社 内に宣言する。そして、遂行体制を確立する。

いうまでもなく、BOM再構築には、クロス・ファンクショナルな活動=プロジェクト・チーム体制での取り組みが必要になる。プロマネを任命し、スタッフと時間と費用を与えて、これを推進していくべきだ。誰かの片手間で済む仕事ではないのだから。

 [図3 BOM再構築プロジェクトの流れ(例)]

つぎに、BOM活用の現状と課題を、関連する各部門(製造業ならば営業を含むほとんど のライン部門が関係すると思っていい)で調査し、把握する。そこから、あるべきBOMデータの設計に進む。マテリアルのコード体系、BOMに付随すべき属 性項目等を整理するのである。このとき、主要ユーザ部門を相手に、テスト収集を行い、実用に耐えるデータ設計となっているかを検証しながらすすめる方がい いだろう。

そして、BOMデータの収集と整理のフェーズに進んでいく。データを、マテリアル、マテリアルの親子(階層)関係、工順(=加 工手順、レシピ)にしたがって整理していく。このとき活躍するツールがBOMプロセッサだ。またモジュール化設計を進めている場合は、モジュールの組合せ で実現できる製品仕様・性能との関係を定めていく。これは受注用コンフィギュレータの基礎になるから、営業部門の参画も望ましい。

データが収集できたら、クレンジング作業や整合性チェックを経て、ターゲットとなる情報システムのデータベースに登録する作業となる。ここは特にIT部門に活躍してもらうべきステップだ。

そして最後に、BOMの運用フローと保守体制の構築を行う。BOMは生き物である。今後も長い間、データを維持・登録・修正しながら使っていかなければならない。その体制と責任分担を決めて実行するのである。

そ して、ひとつ助言させてもらえるなら、このプロジェクトには外部の目を取り入れた方が良い。さもないと声の大きい部署の「部分最適」で終わる可能性が大だ ろう。BOMを再構築し、生産システム全体を生まれ変わらせる仕事を成功させるためにも、全体最適を目標に高く掲げるべきだ。そうして、日本のより多くの 企業が、活気と余裕を取り戻すことを祈ってやまない。

<参考図書>
 

→「革新的生産スケジューリング入門」にもどる

E-BOM(設計部品表)とM-BOM(製造部品表)の関係を考える (2016/02/22)

拙著「BOM/部品表入門」(日本能率協会マネジメントセンター・刊)が、再び増刷になった。おかげさまで、累計8,900部である。本書は2005年1月の発刊だから、11年間にわたり現役のビジネス書ということになる。読者の皆様にあらためて感謝もうしあげたい。

ところで、この11年間、BOMをめぐる状況は変わったのだろうか?

正直に言うと、あまり大きくは進展していない印象である。相変わらず、いまだに多くの企業がBOMについて悩んでいる。いや、むしろ悩みは深まっているとさえ、いえよう。海外生産の進行やアジア市場への販売展開などで、サプライチェーンが海外まで確実に広がった。しかし、その現実にBOMの方がついていけていない。むしろBOMが、生産のグローバル展開の足かせにさえなっているようだ。

それだけではない。どうやら、BOMに関する基本的な認識さえ、まだあまり進んでいない気がする。たとえば、“ウチの会社にはまだ「BOM」がありません”、などと、かなりの大企業でも口にする。

BOMはBill of Material、すなわち部品表である。部品表のない製造業など、存在し得ない。部品表がなければ材料を調達できない。どうやって材料なしで製造するのか? 部品表がなければ材料費も計算できない。どうやって販売価格を見積もるのか?(個人営業の飲食店や職人の工房ならいざしらず)

こうした発言をきくと、世の中では、BOMを何か特殊なデータベースみたいなものだと、誤解しているらしい。BOMは製造業の中核データである。どんな製造業でもBOMはある。ただし、BOMをきちんとマネジメントしている企業は少ない。だから小著が11年間も現役で読まれ続けているのだろう。

かつてこのサイトで、「生産革新のためのBOM(部品表)再構築入門(2)」として、<設計部品表(E-BOM)と製造部品表(M-BOM)の乖離>問題をとりあげた。今回は、このテーマについて再度論じてみようと思う。これもひどく誤解の多いテーマだと感じるからだ。

乖離どころか、世の中には、「会社はE-BOMとM-BOMを二つ持つ必要がある」と信じ込んでいる人たちまでいる。「ウチの会社はいまM-BOMしかなくて、これからE-BOMを作らなくちゃなりません。」などとおっしゃる。冗談抜きで、きいて思わず頭がクラクラしてしまった。BOMが一つで済むなら、それで十分なのに。

上の記事では、設計部品表(E-BOM)と製造部品表(M-BOM)の乖離が生じる理由として、
(1)品目コードの不統一
(2)代替部品の使用
(3)副資材や包装材料の追加
(4)設計変更の発生と在庫切替タイミングの食い違い
の4つをあげた。このE-BOM, M-BOMの分断の背景には、設計部門(本社)と製造部門(工場)の組織的乖離が遠因にある。

もともと現代的なBOM概念、つまりストラクチャー(構造型)BOMの概念は1960年代にあらわれた。この概念はMRPという生産管理手法と一緒に確立された。つまり製造を強く意識したもの、今でいうM-BOMに相当するものである。

ではE-BOMの原型は、というと、機械組立図における材料表にさかのぼる。組立図には部品それぞれに引き出し線と、丸で囲った@Aなどの数字(俗に「風船」とよばれる)がついており、かつその図面の端っこに表が書いてあって、そこに@の品名と数量、Aの品名と数量・・が並んでいる、あれである。製品を最終的に組み立てるにあたって、必要な部品の種類と名前と数量、位置を記した表だ。昔はB/Mと表記されることが多かった(今でもエンジ業界はB/Mとよんでいる)。これは親と子が一階層だけの、フラットなサマリー型が普通だ。

さて。会社組織では、誰が(どの部署が)BOMを登録、維持するのか? という問いがしばしば、ついて回る。たとえば今、図のような製品があったとしよう。
(1) 製品SはアッシーXと部品A, Bとからなり
(2) アッシーXはサブアッシーYと部品Cからなる
(3) 部品Bは材料dを切削、研磨し表面加工したものである


<BOM(M-BOM)の全体像>

当然だれかが、製品S→アッシーX、アッシーX→サブアッシーY、部品B→材料d、という紐づけをBOMマスタに登録していかなければならない。なお、「アッシー」というのはAssemblyの略で、途中まで組み上がったアセンブリー(モジュール)のことを指す。

ところで当たり前だが、製造業では製品開発→量産準備→生産、という順序で仕事が進む。製品、アッシー、子部品は設計部門が図面を書く。製品やアッシーの組立図面には、品番の親子関係の表がついているだろう。つまりE-BOMが先に生まれる。製品S→アッシーX、アッシーX→サブアッシーY、はそれぞれ製品S・アッシーXの組立図に付随した「E-BOM」情報である。

別の言い方をすると、BOMの親子関係のうち、上位の階層は設計部門が定義する訳だ。

しかし、たとえば購入部品(汎用部品やボルト・ナット等)や、材料(たとえば丸棒)などは通常、図面は書かない。つまり、E-BOMの親子関係は途中で途切れてしまう。その先、外部購入品までの親子関係を定義するのは、工程設計を担当する部門(普通は生産技術)の仕事だろう。つまり、E-BOMは製造側の技術部門によって展開され、肉付けされることで、M-BOMとして完成するのだ。

ところで、たとえば上記の例で材料dから部品Bまでは、切削→研磨→表面加工と複数の工程が必要だったとしよう。では、その間の中間状態の部品はすべてBOMに登録すべきなのか? 切削後段階の部品d'、切削研磨後の段階の部品D、そして切削・研磨・表面加工後の部品B、という風に。

答えはNOだ。

じつは、BOMに登録すべき品目には原則があるのだ。BOMに(いいかえればマテリアル・マスタに)登録するすべき品目とは、在庫管理の対象となるマテリアルである。

もしも、切削→研磨→表面加工がつねに一貫した工程なら、途中段階の品目登録は不要である。途中段階の品目は一時的に出現しても、すぐに次工程に消費されてしまうからだ。だが、材料dを切削→研磨した後、用途別にいろいろな表面加工で品種が別れたりする場合には、研磨後の中間部品Dをいったん保管したくなるだろう。ならば、中間部品DをBOMに登録するべきである。

こうした製造工程上の都合は、設計部門では分からないのが普通だ。だからBOMの定義も、生産技術や製造部門の判断になる。

業務系の情報システムでは、データの作成者がそのデータの登録者となり、オーナーシップをもって管理すべきだと一般に信じられている。この原則にしたがえば、BOMのマスタデータの登録作業は、複数部門によって分担されることになる。もっとも、情報源(作成者)と、マスタへの登録者を誰にすべきかは別問題という考え方もある。だから設計部門からのデータを生産技術部門が受けて、BOM全体の登録は生産技術がまとめて担当する、という取り決めだって可能ではある。

ただし、ここに一つの問題が生じる。多くの企業では、製品開発・設計部門が本社にあり、生産技術・製造部門が工場に所属する。場所が離れているのだ。両者は、別々の情報システムを使っていることが多い。サーバもデータベースも、物理的に別である。

こういうケースではどうしたらいいのか? E-BOMとM-BOMは統合不可能なのか?

答えは、単純だ。システムは物理的に別々でも良い。しかし、同じマテリアルは同じコードでよばれなければいけない。これが「BOM統合の原則」である。本社と工場が、同じモノを別々のコードでよんだり、モノの同一性について意見が分かれたりする状態があってはいけない。同じマテリアルの親も、同一でなければならない(そうでなければ構成管理の一貫性が崩れてしまう)。

このような形で、複数のシステム間のマスタデータ整合性が担保されているなら、BOMは統合されているといっていい。少なくとも、E-BOMとM-BOMの乖離問題は起きていない。

ちなみに設計用CADシステムの発達により、図面管理や構成管理など、設計用ツールにはPDM(Product Data Management)的機能が増えている。設計部門はその中で、「E-BOM」を管理維持したいと考えるだろう。部品共通化や設計情報の再利用などをはかりたい、とも望むだろう。それは当然である。しかし、E-BOMに登録される品目コードは全社共通のものを使うべし、が原則だ。

ただし、この話を推し進めていくと、異なる部門間で、モノの同一性について意見がくい違い、論争が生じるケースが出てくる。設計部門は、「これは内径X、外径Yの○○部品じゃないか」といい、製造部門は「いや、同じ形状の○○部品といっても、材質強度的に区別が必要なものが2種類あるんですよ」とか「仕入れ先が3社あって区別したいんです」とかいう要望が出てくる。この種の論争をどう解決するかが、じつはBOM統合にとって大切なのだ。だが、ちょっと長くなりすぎたので、この問題は項を改めて論じよう。

→「革新的生産スケジューリング入門」にもどる

同じモノか、違うモノか? − マテリアルの同一性問題をめぐって (2016/02/29)

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

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

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

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になっていき、機械的な変換ができなくなるから、こまるのだ。

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

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

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

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

あなたの会社にはチーズ製造部門がある。そこの購買課に見解をたずねると、こう答えた。
「乳脂肪含有率が重要だ。産地が違えば区別が必要だ。いや、季節によっても品質は変動する」。
一方、あなたの会社はレストランもチェーン経営している。そこの仕入係の見解はこうだ:
「コップに注いでしまえば産地も容器も関係ない。要冷蔵かどうかだけが重要だ。」

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

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

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

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

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

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

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

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

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

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

→「革新的生産スケジューリング入門」にもどる

部品表と工程表 (2017-03-22)

今年の初め頃だったが、ある集まりを手伝うことになった。中高校生くらいの若い子達が20人くらい集まるので、彼らに昼食を出す。わたしと連れ合いはその食事作りのお手伝い、という受け持ちになった。わたし以外は全員、年配の女性達だ。集会場所の横にはそれなりのキッチン設備があり、食器もそろっているので、そこに集合となった。前日までのメールでは、シチューを作ると聞いていたのだが、当日集まっていたら、なぜかメニューはカレーと野菜スープに変更になっていた。ともあれ、食材もそろって、さあ調理と言うことになった。

ところで、この調理の進め方がなかなか見物だった。わたしは男なので、食器洗いその他の力仕事に回り、実際の調理は女性達が受け持つ。皆、何十年と料理をしてこられた方ばかりだ。ただ、わたしも一応、料理の心得はあるので、どんなプロセスで進むかは理解している。まず材料を洗い、切り、大鍋に適時投入して、煮て味付けをする。そのかたわらご飯を炊いて、織機を用意する。それだけのことなのだが、現場は大騒ぎだった。

まず、この集団には、采配をふるうリーダーがいない。2、3人、それなりにリーダー格というか、まあ仕切り屋のタイプの人はいる。だが回りの人たちも黙っていない。みな、料理については一家言ある女性ばかりだ。だからどの材料をどれくらい使うか、どう切っていつ鍋に投入するか、味付けには何をどれくらい入れるか、まあ実に喧々がくがく、議論が続く。議論だけでなく、彼女たちはしゃべりながら実際に手が動き、勝手にやってしまう。もうどうなることやら、ホントに昼食時間までに間に合うのか、などハラハラして見ていたが、幸いというかカレーも野菜スープもなんとかそれなりに出来上がって、腹を空かせたティーンエイジャー達の胃袋にあっという間に飲み込まれた。

この集まりはまあ、ボランティア集団のようなものである。こういう集団では、会社のような上司・部下関係が無いし、指示=命令原理も働かない。誰か図抜けたリーダーがいればその人の判断と采配で、皆が一応動くだろう。だが、そういう人もいなかった。それでも何とかなったのは、女性達の調理のスキルもあるが、一つにはカレーとスープという料理が、材料にも味つけにもある程度幅があっても、まとまりやすい料理だったからだろう。

それにしても、同じこの仕事を、わたしの勤務先の同僚達がやったらどうなるだろう、と想像してみた。ボランティアの組織だ。賛同者が集まり、業務命令系統はとくにない。でも、きっと、自然にこうなるだろう:
(1) まず、料理は何を何人前作るか相談の上、決める。
(2) 必要な食材のリストを作る。食材の種類と、数量と。必要ならば、スペックつき(たとえば豚肉ならば「バラ肉」とか)で。
(3) 調理の手順のリストを作る。それに必要な調理器具もリスト化する。
(4) 食材調達の担当者を決めて、買い物を任せる。
(5) その間に、調理器具と食器の準備をする。必要な食器を集めて洗い、並べる。
(6) 食材が来たら、これも分担して洗い、カット、下ごしらえをする。
(7) 調理をする。この作業にはやはり、多少はスキルのある経験者をあてる。
(8) たぶん何人かで味見をして、OKとなれば盛りつけ、配膳作業をする。

たぶんこうしたことが、なかば自然に進むだろう。なぜなら、これはエンジ会社が普段やっている、エンジニアリングの仕事そのものだからだ。誰かがリーダー役を引き受けるだろう。あるいは長老が、誰か若手を指名してリーダー役にするかもしれない。皆、そのリーダーの采配と交通整理に従う。難しい問題が起きたら、皆で相談して解決する。それでも迷ったら、リーダーの責任で打ち手を決断する。これがたぶん、わたし達のスタイルだ。もちろん、調理の腕前は熟練の女性達にはかなうまい。でも、何とか必要なものを必要なタイミングに必要な量だけ、届けられると思う。

とくに大事なことは、最初に大まかな計画を立て、必要な材料や道具や手順のリストを作ること。これがないと、全体の仕事量も、作業の分担も、そして納期も見通せないからだ。

わたしの勤務先が特別だというつもりはない。たぶん大方の会社は、少なくとも製造業なら、こういう風に仕事を進めると思う。ものづくり企業に共通なDNAというのがあるとしたら、その一つは、最初にいろいろなリストを作ることにあるだろう。リストなんか作らなくても、あの女性達のように、ものは作れる。だが、仕事の見通しは、格段に落ちるだろう。

必要なリストは何だろうか? あるいは、もっと抽象化して問題を捉えるなら、生産という仕事に必須な基準情報は何なのか。

それは大きく、「もの」(=マテリアル)に関する情報と、「製造作業」に関する情報とに分かれる。「もの」に関する情報は、まず、どういう品目(材料・製品を含む)があって、それはどういった使用・属性を持つか、というリストになる。これは通常のIT用語で言うと『マテリアル・マスタ』(品目マスタ)と呼ばれる。ついで、ある製品は、どのような部品・材料から成っていて、どれだけの数量を要するのか、という製品構成に関する情報が必要だ。これが『部品表』(BOM = Bill of Material)データである。ただしBOMがマスタとしてITシステムの中に整備されているかどうかは、その企業・生産形態に依存する。

では、製造作業に関する情報はどうか。これはまず、製造に使う機械・設備の情報と、具体的な作業の情報に分かれる。前者は、機械リストとか、会社によっては作業区(ワークセンター)マスタと呼ばれる。もう少し進んだ形では設備構成マスタというデータ形式になる。設備構成マスタとなると、その中に階層構造が表現されて、たとえば作業区1の圧縮機Aには、補機として潤滑油ポンプA1がある、といった事情がわかるようになっている。つまり一種の、機械設備に関する部品表みたいなものである。かなり保守業務のレベルの高い企業では、こうしたマスタが必要とされる。

後者の、具体的な作業の情報については、特定の製品・品番ごとに、(通常は複数の)製造作業が生じる。つまり、各作業に必要な機械・設備は何で、その順序はどうで、各作業条件は何で、(もしあれば)マニュアルや作業標準はどれで、といった属性が並ぶ作業マスタがいる訳だ。これは基準情報である。ただし、個別の作業指示が出される場合は、それぞれの作業にIDをふり、これに着手・完了のタイミングを指定し、さらに必要な機械・設備などをアサインしたリストを作ることになる。これは、しばしば『工程表』と呼ばれる。英語でBOP(Bill of Process)と呼ぶこともある。

以上をまとめると、生産という仕事に関する基準情報は大きく4種類に分けられる:

マテリアルに関する情報

製造方法に関する情報

なお、ここで注意しておきたいことがある。それは「情報」と「データ」の区別だ。これについては以前、『ITって、何?』というシリーズで長々と述べたことがあるから詳しくは繰り返さないが、

という区別 がある。今日はA社の業績ニュースが流れて株価が上がりました、が情報。各社の株価が定型化されて並んでいる株式欄が、データ。情報を定型化して機械で処理したり、データを読み取って人間に意味を提示するのが、IT(情報技術)である。上に述べた基準情報の例でいえば、人間は情報だけあればいい。ただ、量が増えたときには、紙に記録してリスト化したり、さらにコンピュータの中に収めてマスタ・データ化する方がベターだ。

もう一点。上の説明では、『工程』という言葉をあえて使わぬように説明した(「工程表」は別として)。これは、工程という用語が業種・会社によってかなりいろいろな意味に使われているためだ。大きく分けても、工程をプロセス=作業群の意味で使うケースと、ワークセンター=作業区の意味で使うケースがある。それらをごっちゃにしているケースだって、少なくない。工程表という用語だって、それなりにブレがある。

本当はこうした用語類は、わが国の生産管理の発展のためには、共通化した方が良い。しかし、抽象化・標準化への希求がかなり弱いわたし達の社会では、それぞれの業界や特定の大企業が勝手に作った方言を、グループや系列会社に押しつける例が、よく見受けられる。業界を横断して工場づくりの仕事をしている我々エンジニアリング会社にとっては、まことに不便な状況である。本来だったらアカデミアの学者が先導して、こうした状況を改善すべきなのだろうが、あいにくその動きも薄い。

そこでわたしは、せめてこのサイト内では整合性のある用語を使うように心がけており、とくに多義語である「工程」は極力使わないようにしている次第だ。かわりに、わたしは製造業務のプロセスを呼ぶときは『工順』(英語でRouting)と呼ぶようにしている。わたしの考える製造という仕事のプロセスの構造を、図に示すと次のようになる。

図 製造という仕事のプロセスの構造

もっとも「工順」という言葉だって、作業の集合を指す場合と、単に一連作業の中の連番(数字)だけを指す場合があるから、曖昧性は残るのだが、「工程」よりは誤解が少ないだろうと考えて、こうしている。

なお、図の中には「リソース」(Resource=製造資源)という言葉が出てくる。これは、作業の間は占有するが、作業した後でも別の作業に再利用できるようなものを指す用語だ。具体的には、作業する人・機械設備・治工具・金型などが含まれる。つまり、機械とか作業者とかよりも、1レベル抽象度を上げた用語である。このリソースのリストのことを、「資源表」(BOR = Bill of Resource)と呼ぶこともある。

かくして、製造業には、大きく言っても4-5種類の基準情報が必要であり、それをきちんと整備・保守していく仕事が生じることになる。こうした仕事は全て、「間接業務」=直接お金を生まない仕事である。だから、しばしば日陰の仕事、縁の下の力持ち的な業務とみなされ、不況の時は優先度が下げられたりもする。そして、そういう態度自体が、生産性の低下をもたらし、さらに不況を加速するというダウン・スパイラルが生じる。これは、企業の持つ思考と行動の習慣=OSがバグっている状態だ。

なぜ企業には基準情報が必要なのか? それは、情報・データを再利用可能な状態に保つためだ。さらにいえば、仕事を予見・計画可能な状態に保つために必要なのである。冒頭に紹介したように、たまに集まるおばさま達の集団なら、基準情報など無くても、なんとか料理はできる。いや、それこそ、「ちょっとカレーの味が薄いみたいだから、ここにある和風だしを入れちゃいましょ。」などという、臨機応変な小技(大技?)を繰り出すことだって、できたりする。だが、これを仕事にして食堂を開くなら、もう一歩上を目指す必要がある。きちんと計画できて、繰り返し可能な仕事の状態にするべきなのだ。部品表と工程表は、そのための武器なのである。

(本記事を書くきっかけとなったのは、OpenLearningが提供する「応用情報学」講義シリーズの中の、京都情報大学院・上田治文教授による「企業経営の情報学」Wee 2・Lesson 3「工場のIT化の核 部品表のコンセプト」を見たことである。わたしの用語・見解とはいろいろ異なっているが、4種類のマスタの整理など、いくつか学ぶべき良いヒントをいただいたことを記しておきたい)

→「革新的生産スケジューリング入門」にもどる

工程表と部品表 − 個別受注生産における主従の逆転 (2017-03-31)

若い頃、『システム・モデラー』という職種を目指したい、と言ったら、上司から「そんな職種はない」と言われたという話は、以前書いた(「システムとはいったい何を指すのか」 『考えるヒント』 2013-08-01)。それで、その後わたしは「プロジェクト・アナリスト」を名乗るようになり、今では名刺に、勤務先の「チーフ戦略アナリスト」である、と書いている。

だが、今でもわたしはモデリングの仕事が好きだ。データ・モデリングとは、世界の概念的スケッチである。言葉と簡単な図を使って、世界のあり方を切り取って分析する仕事は、何より楽しい、と思う。モデリングという仕事は、技術とアートの中間地点にある、とも言われる。科学的論理性だけでは、良いモデルを作るには足りない。モデルとは近似であり、見切りだからだ。モデルは必ずしも事物の厳密・正確な再現ではない。英語で、"Models are all wrong. But, they are useful.”という言葉をきいたことがあるが、金言だと思う。モデルはすべて、正しくない。だが、有用なのだ。

さて、前回は『部品表』と『工程表』という概念について、簡単なイントロ的解説を書いた。ところで、前回の記述は、じつは繰返し性の高い生産形態での話だった。つまり、見込生産(MTS)とか繰返し受注生産(MTO)の場合なのだ。

(なお、若干話がずれるが、生産形態の分類を表す用語については、日本語の慣用句よりも英語の用語の方が本質を突いているので好きである。見込生産は英語でMake to Stock = MTSとなる。「在庫してストックするために作る」形態なのである。繰返し受注生産はMake to Order = MTOで、これは「注文に応じて作る」やり方だ。このように、何に対して製造するか・製造の結果が何になるか、が英語での表現では、より明快だ)

さて今回は、ETOの場合について書いてみたい。ETOとは、Engineer to Orderの略だ。Engineerという単語は、ここでは「技術者」という名詞ではなく、「設計すること」という動詞で使っている(ちょうど”Engineering”という動名詞の言葉があるように)。ETOは日本語では、「個別受注生産」あるいは「一品受注生産」「受注設計生産」などとも呼ぶ。

ETOという生産形態の本質は、製造の前に設計作業が必須となることだ。このような生産形態は、意外と多い。たとえば造船。航空機。大型の産業機械(たとえば圧縮機や工作機械など)。あるいは金型。いろいろある。わたし達プラント・エンジニアリング会社が購入する資機材の大部分も、ETOの形態で生産される。そしてIT業界でSIerが行う受託型のシステム開発も、受注後に設計が必要になる点では、ETOの一種だと見ることもできる。

わたしの見るところ、日本の製造業には、このETO形態を(部分的にであれ)とっている企業がかなり多い。好むと好まざるとに関わらず、いや、それが企業自身で自覚して選んだ結果なのかどうかも分からないが、とにかく、広く見受けられる。統計的根拠までは示せないが、英米や中国などより、ずっと比率が高いのではないかと思う。

その理由は、日本における顧客(買い手)側のあり方に起因している、というのがわたしの推測だ。日本の顧客(B2Bで、顧客が企業の場合)は、なぜかメーカー標準品を買うことを潔しとせず、必ず自分好みの個別仕様を付け加えたがる傾向がある。たとえば生産財を買う場合、それが自社の生産ラインにぴったり最適化され、面倒が少ないようにしたい。そのため、いろいろ個別で特殊な注文がつく訳だ。そういう風に細かな注文をつけること自体が、エンジニアとしてのプライド、ないし存在意義とさえ思っているらしい(実際にはその分、標準品よりコストが上がっている可能性が高いのだが、会計部門への説明能力の高いこともエンジニアの能力の一部である^^;)。顧客から個別注文を受け取った企業の技術者は、自分のサプライヤーに振り向いて、同じように個別仕様を要求する。かくして、日本ではETOに対応しない企業は生き残れなくなっていく。

ところで、いろいろな生産形態のうちで、生産管理の一番難しいものが、このETOなのである。だから日本の製造業は、全体として、わざわざ一番難しい生産形態を、みんなして選んで、お互いに生産性の低さに苦しんでいるとも言える。

ETOは、なぜ難しいのか? ETOの特徴は、受注時点で部品表(BOM)が固まっていないことにある。まあ受注時点でも、たいていの場合、大きな骨格くらいは見えている。そうでなければ、そもそも金額さえ見積れないからだ。

しかし、細部は設計してみないと決まらない。当然、設計後に、部材を注文することになる。注文してはじめて、部材は工場に入ってくる。部材がなければ、製造はできない。当たり前だろうって? その通りだ。だが、製造のスケジュールという観点から見ると、ETOとそれ以外では、大きな違いがあるのだ。

前回の図を思い出してほしい。複数の子部品が組み合わさって、一つの製品ないし親部品ができあがる。それを作るために、工順がある。いいかえると、部品の親子関係に対応して、一つの工順がある(厳密には『代替工順』というものも存在しうるが、今その話には深入りしない)。工順は複数の作業からなっていて、それぞれの作業に、製造資源(人や機械)が結びつく。こういう構造だ。

ここで、ちょっと図を見てほしい。ここに掲げたのは、渡辺幸三氏が「CONCEPTWARE/生産管理」の名前で公開している、生産管理システムのデータモデル図の一部だ(http://dbc.in.coocan.jp)。渡辺氏は、今日のIT業界のレベルアップと生産性向上をめざして、あえてこうした本格的で実線的な業務系システムのデータモデルを公開しておられる。

E-R図を見慣れた方ならば、これを見るだけでわたしの言いたいことはお分かりいただけると思うが、念のために説明しておこう。なお渡辺氏の用語はわたしのとは少し違っているため、対応関係を示しておく。左が渡辺氏のモデル上の用語で、右がわたしの用語である。

(1) 工程→工順、 (2) 作業場→作業区(ワークセンター)、 (3) 製造品工程明細→作業、 (4) 製造品材料明細→部品表、 (5) 品目→マテリアル(品目)

この図を見ると、(5)「品目」レコードに対して、複数の(4)「製造品材料明細」レコードがぶら下がっている(渡辺氏の図法では、「∈」は1:Nの関係を示す)。これは、一つの親部品が、複数の子部品から組立・加工されて作られる「親子関係」を示している。そして、(5)「品目」レコードに対し、(3)製造工程明細が、やはり複数ぶらさがっている。つまりここでは、品目が主であり、工順・作業が従であることが表されているのだ。(細部に興味がある方はダウンロードして、全体をご覧になることをおすすめする。非常に勉強になると思う)

そして製造リードタイム(渡辺氏の図ではLead Timeの頭文字をとってLTと略されている)は、個別の作業に結びついており、作業を積み上げて、工順の、そして全体の生産スケジュールができあがるのだ。

言いかえるなら、設計が完了して、すべてのマテリアルと部品表が決まらない限り、製造コストやスケジュールが確定しない、ということになる。コスト(原価)については、もはや受注時点ですでに販売価格が決まっているのだから、今さら泣いても笑ってもどうにもならない。だがスケジュールは問題だ。工場では複数の品目や注文が流れており、スケジュールの相互調整によっては、他の品目の納期に影響してしまう。

MTS(見込生産)やETO(繰返し受注生産)ならば、事前にBOMが確定しているから、「標準納期」とか「標準リードタイム」といったものを設定することができる。だがETOは、受注時点で全体のスケジュールが見えないのだ。ということは、受注時点で、本当に納期を確約できるかどうかも、分からない訳だ。おまけに、現場の人や機械の事前手配も、難しいと言うことになってしまう。

それがどうした。ものづくり現場は、部品と図面がなければ動けないのだ。だったら設計が全部終わった時点で、製造のスケジュール計画を立てればいいではないか、と思う人もいるかもしれない。だが、そうはいかないのだ。競争環境下では、そんなにのんびりした納期を顧客は与えてくれない。だから、部品表が確定した部分から、順次作り始めなければ、ふつう間に合わなくなる。かくして、設計作業と、部品調達と、製造作業が、並行して進むことになる。本来は順番に進むはずの仕事が、入れ子になったり逆転したりして進むのだ。設計部品表(E-BOM)と製造部品表(M-BOM)が別々に管理されている企業の場合、話はさらに混乱してくる。

米国生まれの生産管理手法であるMRPが、日本でなかなか受け入れられず普及しなかった理由の一つが、ここにある。MRPは、大量繰返し生産マインドの強い米国で、'60年代に生まれた手法である。MRPでは、計画時点に、製品のBOMデータが存在していることを前提している。だが個別仕様が好きで短納期を要求したがる顧客だらけのわが国では、なかなか使い物にならない。

では、どうしたらいいのか?

ここで実は、発想の転換が必要となる。それは、「品目」→「作業」という主従関係の逆転である。

「作業」と、その集合である「工順」を、視点の中心におく。そして工順のインプットとアウトプットとして、子部品・親部品をとらえる。前回の図を、もう一度見直してみてほしい。

今、ここで問題としたいのは、製造スケジュールである。つまり個別作業にかかる正味時間、工順に与えるべきリードタイムだ。そして、それは、同じような親部品を製造する作業では、子部品の細部が多少異なっても、ほぼ同じだと見ることができる。え? 六角の部品の加工と、円形の部品の加工では作業が違うだろうって? たしかに厳密には違う。だが、生産スケジュールはモデルであり、一種の近似であることを思いだしてほしい。何秒単位の厳密な数字を議論しても仕方ないし、そんな精度は必要ないのだ。現場が必要とするのは、現場が混乱しないですむようなざっくりした精度の、しかしある程度は信頼しうる予測なのだ。

個別作業の所要時間見積のために、ここで登場するのが「パラメトリック見積法」である。これは、作業対象が持つ、なんらかの代表的なパラメーターを用いて、作業時間(つまりコストを)推計する方法だ。そして、この仕事のために、BOQ = Bill of Quantityという概念が、BOMのかわりに登場する。Quantityはパラメーターの数字である。グラムとか、mmとか、リットルとか、何の単位でもよい。それが作業の量(Quantity)を適切に示してくれたら、それで良いのだ。あとは割り当てる製造資源と、その生産性指標とから、作業時間を推算することができる。製造コストも、推算できる。

詳細な設計作業が十分に完了していなくても、基本設計段階(ないし受注前の見積設計段階)で、製品を構成するサブ・モジュールや共通部品等のBOQを洗い出し、リスト化しておく。そうすれば、これを元に、製造スケジュールをあらかじめ立てられる。これが、プロジェクト的なETO=受注設計生産のやり方なのである。詳細のBOMは、設計のあとでできてくれば良い。

もともとBOQという用語・概念は、100年ほど前に英国の建設業界で生まれた概念だ。そして、エンジニアリング業界に流れ込んできた。わたし達の業界では、このBOQ(しばしばBQとも略す)が、プロジェクト・スケジューリングの中心的なデータになるのである。わたし達にとって、作業(プロジェクト用語ではActivity)が主であって、そのインプット・アウトプットとなる品目(マテリアル)は従である。作業が先にあり、品目は段階的詳細化の結果として、後から決まってくる。このような世界観で、エンジ会社はプロジェクト・マネジメントを行っている。

そしてエンジニアリング・プロジェクトは、まさに巨大な「受注設計生産」そのものなのである。基本設計の外部仕様を元に、詳細設計を起こし、資機材を世界中のサプライヤーから調達し、プラントの現場に運んで、据付組立作業(「建設」)を行う。我々もまた、組立加工産業なのだ。

そしてもう一度最初の話に戻ると、システム・モデリングの面白い点は、こうしたデータモデル上の主従の逆転、アクロバティックな視点の転換が、ときに必要となることにある。必要なだけではなく、とても有効でもある。もちろん、そのためには、ある種のスキルがいる。ものごとを俯瞰して見る、一種マネジメント的なスキルが。そういう訓練の場をエンジニアのために作ろうと、わたしはこのところずっと研究部会の仲間達と活動しているのである。どうか期待していてほしい。

→「革新的生産スケジューリング入門」にもどる

BOM(部品表)で苦労する会社、得する会社 (2017-06-04)

よくセミナーなどで、「マネジメントとはどんな仕事でしょうか?」と問いかけると、「PDCAサイクルを回すことです」という答えが返ってくることがある。とくに製造業では、継続的改善のためのデミング・サイクルが、全員の頭にまことによく刷り込まれている。これ自体は立派なことだと思う。

だがPDCAサイクルを回すことだけが、マネジメントのすべてではない。そこは誤解してもらいたくない、と思う。なぜなら、企業の中には、一過性の仕事というのも多数存在するからだ。新製品を設計する、試作品を検査する、特注品を製造する、新工場を海外に開設する・・こうした仕事はすべて、一過性である。PDCAサイクルは、繰返し性のある仕事を、さらに高いレベルに改善していくことで、だからCheckとActionが入っている。じゃあ繰返し性のない一過性の仕事は、どうしたら良いのか?

過性の仕事を計画すること、実行可能にすること、再利用可能にすることも、またマネジメントの機能である。わたし達の社会では、量産型の時代は終わって、ますます個別性と一過性の高い仕事の比率が増えてきている。それをどうマネージ可能(Manageable)にするか、という問題に、もっと真剣に立ち向かう必要がある。それはBOMをめぐる状況に、典型的に現れていると思う。

BOM(部品表)は何のためにあるのか?

BOMとは、マテリアルのリストのことである。これは拙著『BOM/部品表入門 (図解でわかる生産の実務)』にも書いたし、このサイトでも繰り返し触れていることだ。マテリアル(資材部品)のリストを持たない製造業は、ない。資材の買い物をするのに必要だからだ。製造業はモノを加工変形し付加価値をつけるビジネスのことである。だからBOMを持たない製造業などというのも、存在しない。

それなのに、「ウチもそろそろBOMをちゃんと整備しなければ・・」とつぶやく会社が存在するのは、なぜなかのか? それは、以前も触れたように、BOMデータベースについての問題意識を感じるからだ。つまり、単なる使い捨てのリストではなく、再利用可能なマスタとしてのBOMデータベースの必要性と有用性、である。一過性の仕事を再利用可能にすること。これはマネジメント機能の一つである。そして、当たり前だが、BOMデータベースの必要性・有用性が、作成し維持する手間を上回るならば、持つ価値がある。

では、BOMデータベースの有用性、つまり目的とは何か? 端的に言って、ストラクチャー型(構造型)のBOMマスタは、部品展開(工程展開)と製造オーダー発行のために用いられる。これがあれば、生産オーダー(すなわち製品単位の生産数量指示)を、工場の各工程・作業区単位の細かな指図(製造オーダー)の束に、律儀に機械的に正確に展開してくれる。これを手作業でやるのは大変だ。もちろん、製造指示などなしでも、職人が勝手に判断して作ってくれる職場もあるだろう。だが職人が数百人もいたら、正確な指示なしでは動けない。指示を出せば実績が上がってくるのが常であり、そのデータは工数や材料費を通じて、コスト計算と、スケジュール推算のベースになる。計画可能になるのだ。

ここでいうストラクチャー型部品表とは、別名「製造部品表」(=M-BOM)と呼ばれるものだ。親部品と子部品の数量関係が規定され、それがどのような工順(作業の並び)を通してできあがるかが、紐づけられている。このM-BOMがマスタ化される目的は、つまり製造現場の計画と指示のためである。そしてM-BOMの作成の起点は、「設計部品表」(E-BOM)にある。

設計部品表=E-BOMは、もともと、製品組立図に表示するP/N, B/Mから発している。P/NはPart Numberの、B/MはBill of Materialの古い略号で、現在もこの呼び名を使っている企業がどれほどあるかは、良く知らない。組立図には、それを構成する部品に、引き出し線を引いて、数字を丸で囲んだ「フーセン(風船)」を表示する。これがP/Nである。そして図の脇に、数字と部品名とを並べた表をつける。これがB/Mの原型だ。B/Mは今ではBOMと呼ぶことの方が多いし、CAD/PDMで維持するのが普通だろうが。

設計部品表E-BOMとは、つまり製品と、部品図面への紐づけを示す情報だ。ただE-BOMは、必ずしも設計の必要性で生まれたとはいいにくい。これは製造や購買のための情報という側面が強い。もちろん、E-BOMをデータベース化すれば、部品の再利用には有用だろう。設計の手間が減るからである(再利用可能にする仕事)。また、部品を共通化できれば、さらに有用である(ただ設計の手間は多少、増えるかもしれないが)。

ここまでをまとめると、BOMデータの目的は、

ということになる。

これらの便益が、作成の手間を上回るならば、BOMマスタデータで得する会社になる。逆に言えば、これらの便益より、作成の手間が大きいと感じられると、BOMマスタデータは構築されないままだろう。では、どんな場合に、構築が難しくなるのか。

BOM構築の第一の難所は、作成の手間をかける部署と、便益を得る部署が違う事から生じる。E-BOMは設計部門が作成し、M-BOMは生産技術部門が展開する、というのが多くの会社の実情だ。しかも設計部門は本社に、生産技術部門は工場にあったりする。かくして両者は、次第に乖離していく可能性がある。

当たり前だが、BOMや構成するマテリアルの属性などは、上流側(設計部門)が入力すればベターである。だが、これを入力する手間は、設計部門にはあまりメリットももたらさないように思われる。かくして、属性入力は製造側が、あとで設計仕様書を見ながら手作業で入力したりする。

また、製造の都合で代替部品や代替工順(外注化)が行われることも、E-BOMとM-BOMが乖離していく理由の一つだ。では、この両者の整合性をとるのは誰の仕事か? どの部署も、あえて自分からは動きたくはない。会社全体の利益より、部門のコストを優先するのは、おかしな話だ。だが現実にはしばしば横行している。まあ、もっともこれは、会社の上層部が、本気で号令をかければ解決可能ではあろう。

BOM構築の第二の難所は、もう少しやっかいだ。もともと階層構造型のBOMデータのモデルは、米国の生産管理方式であるMRPから生まれた。MRPは’60年代の終わり頃に、IBMが中心になって作り上げた仕組みだ。そして現在でも、多くのERPパッケージや、生産管理パッケージの基本に組み込まれている。

ところでMRPには、当時の米国の生産思想を反映した、(暗黙の)前提条件がある。以下にそれを列挙してみよう:
(1) 製造指示はロット単位に、プッシュ型で行われる
(2) 工場の生産能力は十分にある
(3) 製造リードタイムはリーズナブルに与えられている
(4) 生産計画が確定したら、変更は少ない(受け付けない)
(5) BOMのトポロジーはA型である(組立加工的)
(6) 製品のバラエティ(オプション数)は多くない
(7) 計画立案時点で製品のBOMは確定している

一つひとつを解説すると長くなるので、ここではしない。ただ、上記の前提条件の全部が当てはまる日本の企業は、滅多にないだろう。あなたの会社はどうだろうか?

にもかかわらず、やはり最低でも製造オーダーの発行と資材の発注書くらいは自動化したい、というニーズが強い。で、どうするのか。結果として、MRPシステムでM-BOMデータベースからの部品展開機能だけを使い、スケジュールや進捗管理は手作業化する、というのが大方の企業のあり方である。研究会仲間のコンサルタント本間峰一氏は、この状態を「生産管理システムが伝票発行マシン化する」と表現している。

スケジュールや進捗管理は、実際には手作業なのだが、現場の裁量と有能さでなんとか乗り切るのが、日本企業である。ところが製造現場を良く知らない経営者は、「ウチは生産管理をシステム化している」と信じている。それどころか、現場の追随能力を超えた変更を、営業が(受注ほしさに)受けてしまうのも、よくある話だ。これが、BOMで苦労する会社の実態である。

一体、どうしたらいいか?

ここですべての解決策を書くことは、無論できない。だが、少なくとも大事なことが一つある。それは、「BOMで苦労している」という事実を、会社レベルで共有することだ。そして、適切なBOMデータのマネジメントは、便益(とお金)をもたらす、という認識を経営者が持つことが必要である。

しかし、これだけでは記事としてあんまりだろうから、一例として、上記の前提条件(5)があてはまらないケースについて、少しだけヒントを書いておく。A型のBOMとは、複数の部品を組み立てて、サブアッシーをつくり、製品を作っていく、集合型の部品表のことだ。これが当てはまらない場合とは、たとえば共通の中間部品・材料から、多数のバリエーションが生じるV型、T型のBOMのケースである。

現在のMRP系の仕組みは、こうしたBOMを扱うのが上手ではない。そのまま動かすと、一つの共通部品材料に対して、多数の製造オーダーが集まってしまう。しかもどれかの受注に納期変更や数量変更が生じると、影響範囲の特定はますます複雑になる。

こういうケースでは、共通する中間部品の上流側と、下流側の指示方式をかえるべきなのだ。上流側は、需要予測に基づく計画(見込)生産がおそらく適している。あるいは、(需要変動が小さければ)在庫推移監視方式で生産するのが良い。「在庫推移監視方式」というのは渡辺幸三氏の発案した用語で、文字通り、在庫の推移を監視して、適切な在庫量を切らさないように、補充生産指示をかけていくやり方である。

他方、下流側は確定オーダーに紐づく受注生産で動かすのが良い。このように、部品展開計算を途中の中間部品でせき止める(通して部品展開しない)ことで、個別の注文の変更による影響範囲やリワークが、全体に広がらないようにコントロールするのが大事なのだ。もっともこのような方式の実現には、在庫増が伴うし、営業部門や購買部門や原価管理部門の、理解と協力が必要だ。

・・さて。では、こうした生産・販売・在庫方式の変革を、リードするのは誰か? これが次なる疑問であろう。よくビジネス界の英雄物語に出てくる、「生まれつきのリーダーシップ」を持った人か? まさかね。そんな人が、あちこちの職場にいてくれるとは、あまり期待できまい。おまけに、生まれつきだったら、育てることも叶うまい。

そうではなくて、実際に必要なのは、生産システム全体を見通す能力を持った人である。それだったら、(もちろん資質にもよるが)教育可能だ。

わたしはこの点で、中堅企業に期待を持っている。

大企業では、縦割り分業病で変革がスローすぎる。小企業では、BOMソフトウェアに投資できまい。中堅企業ならば、変革の可能性を一番持っている。日本ならば、中堅企業にも、優秀な人はたくさんいる。

そしてわたしは、近々開催するBOMのセミナーで、限られた時間ではあるが、こうした問題への取り組みについて説明したいと思っている。何だ、お前の宣伝かよ、と思っていただいても別に構わない。ただ、わたしは、払っていただいた費用に見合う分の、気づきを持ち帰っていただけるよう、約束の意味も込めて書いているのである。わたしがこうしたセミナーをお引き受けする理由は、参加者に知識を伝授して「教育」するためではない。BOMの問題は各社に固有性がありすぎて、的確な解決法を限られた時間に伝えるなど、現実にはむずかしい。そうではなくて、自社にはどんな視点が欠けているか、何を学ぶべきかを参加者の皆さんに気づいてもらうためにやっているのだ。

気づけば、「学び」が発動する。きちんと学んだ人だけが、自分の問題を解決できるのである。

<関連エントリ>
 →「書評:生産管理・原価管理システムのためのデータモデリング 渡辺幸三」 (2004-07-05)

→「革新的生産スケジューリング入門」にもどる


広義のBOM−−その輪郭

製造業のDNA情報であるところのBOMを考える際には、マテリアルの概念を正しく再定義する必要がある。BOMとはマテリアルの数量的関係を表わしたリストだからである。したがって、BOMデータの構築のためには、まずマテリアル・マスタ自体を一貫性のある形に統一する必要がある。また、マテリアルとBOMをつなげる役割を果すのが工順(routing)である。したがって、マテリアル・マスタとBOMマスタと工順マスタは、互いに整合性がとれた形で構築されていなければならない。

さらに言うと、購買オーダーの明細リスト作成用のマスタはマテリアルをキーに持つ訳であるし、工場のリソース作業のマスタも工順に関連づけられている。こうして、BOMマスタを正しく再構築しようとしたとき、関連して見なおさなければならないマスタ・データもいろいろあることが分かってくる。

そこで、拙著『BOM/部品表入門』の中で、私は「広義のBOM」という、あまり世間では聞き慣れない概念を提出した。広義のBOMとは何かというと、
 
「マテリアル・マスタを中心とした製品構成と製造工程にかんする基準データ、ならびに、そこから派生する履歴データ」
 
と定義される、まとまったデータである。その中心は、(狭義の)BOMマスタと、マテリアル・マスタ、工順マスタの3つのマスタだ。中でも工順は重要で、その中には、時間とリソースの情報があるため、マテリアルのサプライチェーンを統御するために不可欠である。これに加えて、製造指図や製造実績報告などの履歴データ(この中にBOM履歴が格納される)がある。広義のBOMとは、こうしたさまざまな要素からなる、マテリアルに関連する大きな情報の体系を指している(下図)。

広義のBOM



BOMの問題を考える際には、狭義のBOMマスタだけの単体で考えてみても無意味である。広義のBOMの体系の中で、狭義のBOMデータが(あたかもDNAのように)どこで生まれ、どこに複製・転送され、どこで製品として具体的な肉体化されていくか、プロセスの視点から整理する必要がある。

広義のBOMの範囲を図に描いてみると、これが複数部署にまたがるマルチ・ファンクショナルな存在であることが目に見えてくる。たとえば、工順データは工程設計の結果として生まれるものだから、ふつう生産技術部門がオリジネーターとなる。製造指示データは生産計画部門がつくる。購買品目マスタは購買部門、といった具合である。たしかに狭義のBOMマスタ(製品構成情報)は最初、設計部門が作成するものだろうが、その中だけて考えていては全体の整合性などおぼつかないのである。

これは、とくに製造自体を外部に委託する動きが加速している昨今において、大事な視点である。製品開発だけが企業のコア・コンピテンシーであって、生産は“誰でもできる”力仕事だから、労賃の安い海外にシフトしようと言う傾向が2000年頃から強まっている。しかし、製造業のDNAであるBOMデータは、決して製品設計段階だけでまとまるものではない。もしも強い製造業を目指すのならば、強くて一貫性のある「広義のBOM」をどう維持していくかを考えなければならないのである。

→「革新的生産スケジューリング入門」にもどる

モジュラーとインテグラル − 製品アーキテクチャーの二つの方法

半導体製造装置の1つであるステッパーといえば、ながらく日本製品の独壇場というイメージが強かった。そのステッパー分野で、一時は世界市場の大半を占有していたキヤノンとニコンが、オランダ企業のASMLに敗れた話を耳にした方も少なくないと思う。1990年時点ではシェアが10%にも満たなかったASML社は、今や65%以上の世界シェアを握っている。

では、ASML社はどうやって勝利したのか。英エコノミスト誌の記事 "Japan's technology champions: Invisible but indispensable" (2009年11月7日号、 翻訳はこちらで読める→「技術立国日本のトップ企業」)によると、こうだ(以下抜粋して引用)。

「キヤノンとニコンは、製造するステッパーは部品を含め、すべてを内製化していた。そこでASML社は製品をモジュール式に設計し直し、各モジュールを専門企業に外注した。例えば、精密レンズはドイツのカール・ツァイスが製作した。『当社は、ニコン、キヤノンと正面から争うにはあまりに小さすぎた』と、'90年から2000年までASMLの社長を務めたウィレム・マリス氏は述懐する。そして、このモジュール化による設計思想こそ、ASMLがイノベーションを加速し、日本企業を凌ぐ原動力となったというのが、モリス氏の説明だ。

ASMLのオープン性は、単なる比喩ではなく、文字通りの形でも現れた。『例えばサムスンに納入した装置が壊れた時、日本人が20人やって来て、装置をテントで覆ってから修理をしたので、中で何をしているのか分からなかった』という。ASMLは正反対のアプローチを取り、顧客に問題点を見せ、その解決法を公開した。今でも、ニコンとキヤノンは閉鎖的なままだ。」(以上引用)

そして、エコノミスト誌はこう結論する。「両社(ニコンとキヤノン)は今やステッパー事業を統合する方が理にかなっているにもかかわらず、依然として別々に事業を行っている。」

同誌のこの結論が適切かどうか、私には分からない。少なくとも、このエピソードから、「オープン化・グローバル標準化が勝負を決めるのだ!」と決めつけるのは、即断にすぎるように思う(あわてて結論に飛びつく経済評論家も世間には多いのだけれども)。私の今回のテーマは、製品設計には二種類の方法がある、という話をしたいだけだ。その二種類とは、モジュラー型のアーキテクチャーと、インテグラル(すりあわせ型)アーキテクチャーである。

製品の全体機能を単位機能に分解する。個別の単位機能に、それぞれ独立したモジュール部品を用意し、それらを組み合わせることで全体機能を実現しようとする設計思想を、モジュラー型アーキテクチャーと呼ぶ(ModularはModuleの形容詞形)。モジュールの組合せは、標準的に規定したインタフェースに準拠するように設計する。モジュールを交換することにより、さまざまな機能的オプションのバリエーションを可能とするのである。

モジュール部品は、それぞれがいわば機能的に自己完結した存在であり、小さな製品であるとも言える。だから上述のように他社から調達しやすい。

子供の頃、初めて我が家に「ステレオ」なるものがやってきたとき、それはターンテーブルから両スピーカーまで一体型になったステレオセットだった。LPレコードの溝から振動を拾い出し、電気的に増幅してステレオ音響に変える複雑な機能を持った総合的システムだ。しかし、ラジオやオーディオに詳しい友達は、「出来合いのセットを買うんじゃなく、別々のパーツを買って組み合わせてステレオをつくるのが進んだやり方だぜ。」と得意げに教えてくれた。

見せてもらったメーカーのカタログの中には、『モジュラー・ステレオ』なる商品があった。両側のスピーカーと、真ん中のターンテーブル兼レシーバーが別々になっていて、ケーブルでつながれている。スピーカーは自分の部屋に合わせて自由に置くことができる。そのとき初めて「モジュラー」という言葉を知ったのだった。友達はさらに、プリメインアンプだとかチューナーだとか複雑な専門用語を駆使して、“コンポーネント・ステレオ”なる概念を私に吹き込んだ。コンポとはすなわち、インテグラル型の製品だった初期のステレオセットを、モジュール化アーキテクチャーに置きかえたものなのだった。

コンピュータもまた、初期のインテグラル型から次第にモジュール型へと変化していった商品である。その典型が、IBM PCだった。もっと初期のパーソナル・コンピュータは、グリーンモニタとキーボードとCPU本体が一体型の製品が珍しくなかったのだ。IBM PCの成功は、あらゆる種類の周辺機器や互換機メーカーの成長・繁栄をもたらすことになった。同時期にAppleが導入したMacintoshは、非常にクローズドでインテグラル型の製品だったため、成長が遅かった。いや、そもそも、もっと昔のIBM汎用機の時代に、ハードウェアとソフトウェアの分離があったからこそ、今日のソフトウェア産業が成り立ったのだ。

こう書くとモジュラー型アーキテクチャーがつねに優位に見えるかもしれないが、インテグラルが競争優位であり続ける分野も多い。自動車は、すり合わせ型アーキテクチャーの代表例である。前にも書いたが、自動車の部品はすべて個別に専用に設計されており、カローラ用のシートはプリウス用のシートとは別であって、互換性はない。

インテグラル型の長所は、個別の製品特性に合わせて経済的な最適設計がなされている点である。モジュール化すると、規定されたインタフェースにあわせて設計する必要がある。このとき、どうしても余計なオーバーヘッドやマージンが入り込みがちになる。そのかわり、モジュール化された部品は互換性(汎用性)が高いため、全体としては生産量が増える可能性がある。また、複数メーカーでの競争もある。だから量産効果や競争で単価が下がることが期待できるとも考えられる。冒頭で紹介したオランダのASML社の戦略は、これだった。

ただし、モジュール化とオープン化は、必ずしもイコールではない。モジュール化しても、インタフェースや仕様を非公開のままとどめる方法もある。結局、モジュラーとインテグラル(すりあわせ)アーキテクチャーの最大の違いは、部品の『単機能化』、ならびに『交換可能性』(=自由度)の大きさという指標の違いに帰着するのである。

インテグラル型の製品では、複数メーカー間の部品の交換可能性が低い。ここから「純正部品」という考え方が生まれ、メーカーの「保証」に組み入れられる(無償修理の権利だけでなく、性能保証という面もある)。そして純正部品は利益率がいい。これがゆえに、インテグラル型製品では、本体価格を安くして、純正部品や保守で儲けるという戦略も生まれる。

ここで、前回書いたプッシュとプルを思い出してほしい(「プッシュとプル − サプライチェーンの二つの方法」)。モジュラー型の製品では、部品についてはプッシュ型見込生産に移行しやすい。一方、インテグラル型の部品は、基本的にプル生産に結びつきやすい(なにせ客先仕様で設計された部品であり、納品先は1社のみなのだから)。

このように、製品のアーキテクチャーには二つの設計思想がある。そのどちらが優位かは、商品の特性や市場環境によって異なり、正解はない。だが、どちらを選ぶかは、サプライチェーンや工場計画のあり方に、密接に関連する。製品アーキテクチャーが、生産システムの戦略を考える上で重要なゆえんなのである。

→「革新的生産スケジューリング入門」にもどる

モジュラー型 vs. インテグラル型−−設計のアーキテクチャ再論 (2013/12/17)

3年前に書いたサイトの記事「モジュラーとインテグラル − 製品アーキテクチャーの二つの方法」に、最近、読者の方から質問が寄せられた。良い質問だと思うので、ここでとりあげ、あらためて自分の考え方をご説明したい。

ご質問は、つぎのとおりだ(やや長いが、全部引用させていただく):

「車がインテグラル型アーキテクチャということは多方面で言われていることなのですが、すんなり納得ができません。

確かに、ボディ形状は独自設計ではありますが、ヘッドライトは他車種でも移植可能なものもありますし、内部のランプ単体については明かな標準規格品です。

また、ハンドルの入れ替えも(日本国内法は別として)置き換え可能ですし、ワイパーやウィンカーレバーはメーカー内で汎用品になっていることが多いです。
タイヤは規格品ですし、ホイールやサスペンションも変更可能です。確かに社外メーカーが純正品規格に合わせて作っているからであるかもしれませんが、事実上ある一定の規格があるので、市場に製品を出せているのだと思います。
カーナビやカーステレオ、スピーカーについては、配線を通じて、社外品が十分に対応していると思います。

ですので、必ずしもメーカーに閉じたインテグラルクローズもしくは、モジューラークローズであるわけではないと思うので、、、いつもすんなりと納得できずにいます。

明確な規格が存在しないからというだけで、インテグラル型だと考えるべきでしょうか?
もしよろしければ、ご助言・ご教示頂けませんか?」

最初にわたしの答えを言ってしまうと、“両者の区分は設計思想によります”、ということなのだが、これだけだと分かりにくいので少し補足させていただこう。

世の中の製品は、単純なものから複雑なものまで、いろいろある。製品が単純で、ほぼ均一の材料からなり、部品で組み立てられていない製品(たとえばモノサシだとか、まな板だとかを想起されたい)では、誰も設計アーキテクチャーについて論じたりはしない。アーキテクチャーが問題になるのは、主に後者である。つまり、複数の部位・部材ないし部品から構成されるもので、想定される機能も複数持ちうるものだ。自動車はもちろん、その代表格である。

ちなみに機能とは、製品と使い手の意思との関係で決まる。だからモノサシのような単純な道具でさえ、長さを測る以外に、紙に直線を引く定規として使う、紙を直線的に千切るのに使う、背中をかく、人の尻を叩く、など様々な「用途」で使える。このうち、設計者が想定する機能は、たぶん最初の二つ程度であろう。それ以外の使用条件は、たぶん『想定外』となる(そのことの是非は別の議論なのでここでは論じない)。ここでは、機能というものが、何か客観的な実在ではなく、製品と使用者の間で相対的にしか決まらない、ということだけ頭に置いておこう。

さて、設計とは、すこぶる単純化すると、「機能を構造に落としこむ」作業である。たとえば椅子というものを考える。椅子は、人がその上に一時的に腰掛けるためのものだ。すなわち、一定の高さに座面を提供することが、その機能である。野良仕事に行った先の、木の切り株だって腰掛ける用には足りるが、その目的で設計されたものではない。椅子を設計するとなると、まず座面と、それを支持する脚部からなる「構造」を考える。次に、座面の広さ・高さ・材質を検討するだろう。それから、その座面を支える脚をどんな形で何本にするのか、地面とはどう接するのかを決めていく。こうして構造の大枠が決まっていく。

木の切り株には構造はない。ムクの木材が均質に詰まっているだけだ。構造とは、ある全体が、均質ではない部分から成り立っているときの、その成り立ち方を指している。目に見える個体製品の場合は、その部品群の相対的な位置と接合関係で記述される。

むろん、椅子は手で持ち上げられる重さでなければならないとか、耐荷重は100kg必要だとか、回転できるようにしたいとか、背もたれも必要だとか、さまざまな設計の『制約条件』がある。この条件を満たすように、要素の成り立ち、組合せを考える。そして、個々の要素が満たすべきサブ機能や仕様を決める。

ここまで来ると、座面と支持脚をどう接合(固定)するかという、インタフェースの問題が出てくる。一体型で同じ一つの素材から削り出すという設計方針もありえるし、接着・溶接する、金具や釘で固定する、取り外し可能にする、等々、インタフェースの実現方法は様々だ。

ここで、接合箇所の形状や固定方法を社内で標準化して、いろいろな座面と支持脚の組合せを可能にしよう、と考えると、その設計はモジュラー型アーキテクチャーだということになる。これに対して、個別の座面に最適な脚の接合方法を個別に設計しよう、というのがインテグラル(すり合わせ型)アーキテクチャーである。そのどちらを選ぶかは、複数の視点からの評価が必要である。

(1)強度(頑健性):一体型が一番、強度が高い。逆に取り外し可能にすると、どうしても強度が弱くなるため、それだけの余裕シロ(安全率)を設計にみなければならない。

(2)部品材料コスト:上記の理由で、インテグラルの方が最適設計となり、ムダがないため材料コストは抑えられる。

(3)製造コスト:組立加工の手間自体は、一概に甲乙は言えないが、モジュラー型の方が同じ作業の繰り返しとなるため、習熟度は上がりやすい。

(4)設計コスト:概して、モジュラー型の方が設計の工数は少なくてすむ。インタフェース回りは毎回流用できるし、なによりモジュラー型の方は、座面だけ、脚だけという風に、独立して設計をすすめることができる。インテグラル型だと、設計も相互調整が必要だ。

(5)技術進歩のスピード:モジュラー型の場合は、ある部品要素だけを設計上で入れ替えることがやりやすいため、技術進歩が早く、次々と取り替えて製品のバージョンアップを図ることが容易となる

(6)サプライヤーの選択肢:インテグラルの場合、自社で設計した詳細図面に基づき、外部調達することになる。モジュラー型の場合、インタフェースと基本仕様だけで引き合いが可能なため、(その業界がそういう仕組みになれていれば)幅広く調達先を探すことができる

(7)ビジネスモデルとの整合性:たとえば本体価格は安く抑え、周辺付属品や消耗品を売って儲けるという方式(ジレット社がカミソリの替え刃で最初に導入した方式なので「ジレット・モデル」と呼ばれる)の場合、その部分の付け外しは可能になっていなければならない。

以上のような複数の視点から、長短を比較しながら、どちらを選ぶべきかを選択することになる。なお、(4)で書いたように、インテグラル型かモジュラー型かは、設計作業の体制にもそのまま影響する。モジュラーの方が分業と平行作業がやりやすく、また設計の流用や標準化も進めやすいのは言うまでもない。

そして、ここまで書いたように、インタフェースを社内で標準化するかどうかと、それを社外にも公開・共有するかどうかは別問題である。前者はクローズド、後者はオープン戦略と言ってもいい。モジュラーだがクローズド、という戦略も当然あり得る(ジレット・モデルはその例である)。

結局、ある製品がモジュラー型かインテグラル型かは、その製品の中核的な機能と構造が、どのような設計思想で作られているかによって分類される訳である。モノコック構造の自動車の場合、エンジンやトランスミッション、ボディなどがそれにあたる。逆に、ヘッドライトやランプ、ホイール、AV機器などは、顧客要望を取り入れやすいように取替可能となっているが、これらは自動車の周辺要素である。その部分だけ取り出せばモジュラー型に見えるが、全体構造はインテグラルである。ある部分だけ、使い分けているわけだ。

もちろん、言うまでもないが、以上は設計思想が明確にある場合の話である。設計思想とは、設計上の判断が必要になったとき(つまりトレードオフが生じたとき)に、決断するためのガイドラインのことだ。だが、残念ながら、少なからぬ企業では、その設計思想自体が不明確だったり、部署・部位により混沌としていたりするのが実情である。その結果、従来はこうだったとか、業界の慣習ではこうだ(概して言えば電機部品業界は標準化・モジュラー化に慣れている)、といった判断がまかり通る。そして何型ともいえぬ製品ができあがる。

モジュラー型とインテグラル型を意識して使い分けるなら、それはそれで(車の場合にみるように)メリットはある。もしそれが意図した結果でないのなら−−今からでも遅くない、本来あるべき設計の姿を、あらためて考え直すべきなのだろう。

→「革新的生産スケジューリング入門」にもどる

設計部品表(E-BOM)と製造部品表(M-BOM)

つい先日、大手通信機器メーカの方とお話していたら、「最近ようやく、ある事業部でE-BOMとM-BOMを統合しました。大変でした。」という話題になった。E-BOMとは設計部品表(Engineering Bill of Material)、M-BOMとは製造部品表(Manufacturing Bill of Material)の略称である。前者は製品設計の部門が使っている部品表、後者は製造部門が使っている部品表だ。

製造業において、BOMは基準情報であり、いわばDNAである。製造とは、せんじ詰めれば、BOMに集約された設計情報を、実物の上に転写して成り立つ行為である。そのDNAにあたる情報が、この会社では二種類あって、それを統合するのに苦労したというのだ。

しかし、実はこの会社は例外ではない。E-BOMとM-BOMが社内で二本立てになっていて、両者には整合性どころか深い溝がある、というメーカーは多い。むしろ、意を決して2つのBOMを統合しようと決意し、それを実現できたという意味では、この会社は先進的な会社だとさえ言える。

なぜ製造業ではBOMが社内に複数種類存在していて、一元化されないのか? 考えてみれば不思議な話である。そもそも、ある製品を作る設計図はひとつではないか。設計図ができれば、それを忠実に実行するのが製造現場である。だとしたら、部品表だって唯一しか存在しないはずだ。−−そう思うエンジニアは、失礼ながら少々、製造という行為を単純に見すぎている。あいにく、人間の行う設計に完全なものなど無い。設計変更はつきものだ。部品材料のストックアウトや品質不良などで、設計図どおりに作りたくても作れないこともある。製造時に代替部品を使わなければならない。

もっと困るのは、部品コードの問題である。本社の設計部門と、工場の資材部門が使用する部品のコード体系が共通化されていないケースである。さきのメーカーでは、「BOM統合の一番キーとなったのは、意味なしコードの採用でした。」と言っていた。

意味なしコードとは何か。たいていの会社は部品マスタ、あるいは品目マスタなどと呼ばれるマスタファイルを基幹情報システムに持っている。このマスタのキーが部品コードだ。そして、部品コードを採番するとき、たいていの企業は、コードをいくつかの桁や記号に区切って、それぞれに多少の意味を持たせようとする。たとえばC-B09-2147は、Cが製品ファミリの番号で、B09は部品区分、2147は連番を意味する、といった風に。

このやり方は良さそうに見えるが、じつは落とし穴がある。設計にもとづいて部品番号を使用する製品ファミリで分類すると、他の製品と部品を共通化したときにコード体系が混乱してくる。製品の分類も、業態の変化とともにしだいに変わる。さらに、購買部門にとっては、製品を基準にしたコード番号よりも、形状や素材分類や仕入先などがわかる方がありがたい。購買課が工場ごとに分散していると、それぞれの要望も異なってくる。

こうして、設計図の指定とは異なる代替部品を使うことが定常化し、設計側と購買側で別の部品コード番号を使うようになって、E-BOMとM-BOMが分離してくるのだ。こうなると、部門間の情報共有はさらに困難になってくる。設計変更は工場にうまく伝わらず、部品の代替使用を設計部は知らないと言う状態が起きてくる。

悪いのは設計部門か製造部門か? どちらでもない。両者を統合しようとする意志が欠けているのが問題なのだ。もしも意味ありコードが足かせになっているのなら、それを廃止して、単純な連番による「意味なしコード」を採用するべきだ。むろん、マスタを入替える作業に大きな労力が伴うことは間違いない。しかし、E-BOMとM-BOMがバラバラである限り、製品のたえざる改善など絵に描いた餅でしかない。

そして、困ったことに、こうした問題は、単独の部署では解決できないのだ。クロス・ファンクショナル・チームで事に当たる必要が出てくる。したがって、どうしてもマネジメントの関与が必須になってくるのである。

→「革新的生産スケジューリング入門」にもどる

BOMプロセッサ

設計部品表(E-BOM)と製造部品表(M-BOM)が二元化してばらばらの状態にある。これを統一したほうが良い。そう決意したら、実際に必要になるものは何か。

こういう時に、まず何かソフトウェアを導入して、それからデータを整理・統一し、そして保守・運用主体の部門を決める、という順序で進めるのはあまり賢いやり方ではない。まずツールありき、というのはソフトウェア・ベンダーの販売の都合には合致するかもしれないが、必ずしもユーザのためにはならない。とくに、BOM再構築のように『クロス・ファンクショナル』な課題ではそうだ。

BOMの統合は、前にも述べた「広義のBOM」の視点が必要になる。そして、広義のBOMの中心にあるのは、マテリアル・マスタである。このマスタは、じつは非常に関連ユーザ部門が多い。製造業においては、設計・生産技術・生産計画・購買・在庫管理・製造・物流・販売・保全・サービス・財務、とほとんどあらゆる部門が『物品』とその属性データを参照しながら仕事をしている。また、場所的にも、本社・工場・物流センターというふうにバラバラに離れているかもしれない。

このように複数の部署がかかわりあうマルチ・ファンクショナルな課題で、かつ業務プロセスが確立しておらず、権限・責任体制も不明確な場合は、まず目的を定め、運用イメージを固めるところから着手しなければならない。どこまでの範囲まで統合するかを、先に考えておく必要があるのだ。

次に必要になるのは、データ項目の洗い出しと、実際データの収集・整理である。既存データには、いろいろなゴミや誤りや重複などがたいていあるから、いわゆる「データ・クレンジング」の作業が必要になる。この段階で疲れ果てて挫折してしまわないよう、外部リソースを活用するなど、予算と余裕をみておきたい。

そして、きれいになったマスタ・データを最後に一元化するための器に流し込む。この器が、「BOMプロセッサ」である。では、こうした幅広い業務範囲で利用されるマスタ・データを統一するとしたら、BOMプロセッサとしては具体的にどういう選択肢があるか。

おもな選択肢は三つ考えられる:
(1)ERPパッケージのマスタ管理機能をつかう
(2)専用のBOMプロセッサのパッケージを導入する
(3)自社でBOMプロセッサを手作りする

(1)のERPパッケージは、たしかに幅広い業務範囲をサポートしているから、理屈の上では良さそうに思える。しかし、現実の製造業では、設計業務や生産技術(量産準備)業務までERPでこなしている企業はかなり少ない。かりに実現していたとしても、カスタマイズの山となるケースが多い。

では、(2)の専用BOMプロセッサはどうか。こうしたソフトは、CADやPDMベンダーが作っており、設計業務にはななり親和性が高い。また、設計変更に伴う影響範囲の逆展開・特定など、構成管理の機能も充実していて、良さそうに思える。しかし、逆にいうと運用イメージが設計業務中心であって、とても物流や販売や会計(原価)管理までの属性に手が回りきらないうらみがある。

ということで、現実には(3)の手作りが、一番フィージブルな解だということになる。欠点は、“今どき手作りかよ”という批判(逡巡?)が出そうことだろうか。しかし、パッケージソフトがつねに万能でないことは、次第に多くのユーザが気づきはじめているように思う。

自社用のBOMプロセッサを作ったら、あとは他の業務システムのマスタに対して、そのデータを転写するようにする。そして、大本のデータは必ずBOMプロセッサに追加・更新をかけるような運用イメージをつくるべきである。

製造業のDNAであるBOMデータを守りたければ、その会社のニーズに最も合致したBOMプロセッサを持たなくてはならない。データとはつねに、ソフトウェアよりも寿命が長いのだから。

→「革新的生産スケジューリング入門」にもどる

オプションが多数ある製品のBOMは、どう構成すべきか (2013/12/02)

今からおよそ100年前、ヘンリー・フォードは世界で初めて自動車の量産をはじめた。それまで、自動車は富裕階級向けの特別な商品であり、ほとんどが注文生産だった。顧客は大きさや色をはじめ、様々な自分の好みをつけて注文する。メーカーはそれを受けて、個別に設計して製造する。当然ひどく高くつく。それでも買える人だけが顧客だった。ほとんど今の注文住宅のようなものである。

そのようなマーケットの常識を、フォードは完全にくつがえした。彼は黒色のT型フォードという、ただ一つの標準モデルを売ることに決め、そのための専用量産ラインを、当時としては画期的だった工程別分業体制とベルトコンベア方式によって実現した。この時に彼が言った、

 「顧客の望む色はどんな色でも売ります−−それが黒色である限り」

という、有名な文句は一種の標語となった。モデルを一種類にしぼり標準化をはかることで大量見込生産を可能とし、安価な製品で大きなマーケットを獲得したのである。かくしてフォード・システムはアメリカ的経営の成功モデルとなった。

しかし、時代が下り、自動車が大衆社会におけるコモディティ商品となっていくにつれ、単一モデル販売ではもはや競争に勝つことができなくなっていった。外装の色やエンジンの排気量など、標準モデルにさまざまなバリエーションをつけることによって、次第に消費者の細かな好みに合わせる方向に、販売競争が進んでいった。その結果、インテリアの仕上げ、変速がマニュアルシフトかATか、エアバッグの装備、搭載カーナビ機器のグレードなどなど、かなりの種類のオプションを購入者が選べる状態が、現代では常識となっている。つまり、

 初期の個別受注生産 →普及期の大量見込生産 →成熟期の個別オプション生産

という風にマーケットの形(生産・販売形態)が変遷していったのである。

同じことはコンピュータ産業でも起きた。初期の汎用機は非常に高価で、注文生産だった。顧客はそれを買える大企業や国立の研究機関だけだった。しかし、やがてミニコンやオフコンといわれるクラスの普及型製品が出される。さらに「Apple II」や「IBM PC」といった、大衆向けの安価な単一モデルが消費者市場を席巻した。フォード・システムの再来である。そして今日では、多くの消費者はショップに行き、CPU速度やディスク容量・メモリ容量など、多数のオプションを選ぶようになってきている。

このようにオプションが導入されたのは、多様な消費者ニーズに柔軟に対応して、販売しやすくするためである。こうして、消費者の手元に届く商品はバラエティが増え、同じモデル名でも一つ一つが異なる別のものになってくる。こうした生産形態を、大量生産(マス・プロダクション)に対比して、マス・カスタマイゼーションと呼ぶこともある。

ところが、BOM(部品表)の観点から見ると、ここで一つの難問が生じる。BOMというのは、最終製品(英語でEnd productないしEnd itemと呼ぶ)を頂点とした、部品群からなるツリー構造になっている。一種類の最終製品に、一つのBOMが付随する、1:1の関係だ。たとえ同じモデル名でも、もし、トランスミッションの種類が違ったり、エアバッグの装備などが違ったりすれば、当然ながら部品の構成は変わるわけだから、別のBOMが必要になる。

たとえば、自動車のオプションが次のようにあったとしよう。

 ・外装の色 5色
 ・内装の種類 3種類
 ・変速方式 マニュアルまたはAT
 ・エアバッグ装備 3種類
 ・搭載カーナビ機器 4機種

すると、可能な組合せの数は5×3×2×3×4=360種類にものぼることになる。この場合、360種類ものBOMを作成し、マスタに登録して用意しなければならないのだろうか? 

それはとてもばかげた手間に思える。じゃあ、個別の注文を受けた際に、その時毎回、必要なBOMだけを登録することにしてはどうか。いうまでもなく、BOMは製造工程で必要とする部品の出荷指示の基準情報である。だから、工場倉庫からの部品在庫の払い出しは、その個別BOMに従う、とすればいいはずだ・・。

ところが、そうは問屋が卸さないのだ。BOMは材料の購買手配の基準情報でもあることを、忘れてはいけない。部品サプライヤーたちに、先々の数量を先行内示で与えるのが、自動車業界の慣習だ。このとき、すでに登録されている(つまりたまたま過去に注文のあったオプション組合せの)BOMだけで購買手配をかけたら、これまでなかった新しい組合せの注文が顧客から来ても、応えられなくなってしまうだろう。

このような矛盾をはらむ問題の解決法には、じつは定石がある。ここでの問題の根幹には、BOMが「部品購買手配の基準データ」と「製造の部品払出指示の基準データ」という二つの機能を併せ持っていて、その二つが両立しがたいことにある。こういう場合は、二つの機能を受けもつ要素を別にするのである。ちょうど、機械設計のとき、異なる機能を受けもつ部品には違う材質を用いるように。つまり、「部品購買手配の基準」であるマスタとしてのBOMと、「製造の部品払出指示の基準」としての個別BOMを、別のデータとしてシステムに持つのである。前者はマスタデータであり、後者はITの用語で言えばトランザクション・データである。

まず、前者のマスタとしてのBOMから説明しよう。こういうケースでは、BOMの親製品と子部品の間の数量関係(員数)を、整数ではなく、使用比率に応じた小数つきの値で持つ。こうしたBOMデータの形式を、「モジュラーBOM」(あるいは「縮約BOM」)と呼ぶ。モジュラー化したBOMでは、まず最上位の仮想的な最終製品として、製品ファミリーを定義する。その下に、基本モデル製品と、各オプションに対応するモジュールのサブ・アセンブリーに関するBOMを、登録する。

この際、親子関係の員数として、オプション選択の比率を使う。もしユーザが平均してマニュアルを30%、ATを70%選ぶことが過去の経験から知られていたら、製品ファミリーから変速装置への員数をそれぞれ0.3と0.7に設定するのでである。むろん、この員数は定期的に見直す。

図:オプション構成とモジュラー化されたBOM (「BOM/部品表入門」第8章より引用)

このようなBOMを定義すれば、マスタ情報のメンテナンスが楽になるばかりではなく、MRPを利用する際にも、販売予測を360種類の最終製品に対して行なうかわりに、製品ファミリーに対して1種類行なえばすむようになる。

むろん、ユーザによるオプションの選択比率は、つねに定期的に見なおしていく必要がある。とはいえ、そ比率の見直し作業は、5+3+2+3+4=17種類のモジュールに対して行なえばすむ訳である。

そして、製造の部品払出指示に対しては、受注した個別オーダーのオプションから導出されるBOMを用いる。生産管理パッケージの中には、製造指図にBOMを添付する機能を持っているものもある(わたしの記憶では、SAPの生産管理モジュールもその機能を持っていたはずである)。ここで、添付するBOMは、元のマスタデータからコピーするが、顧客の指定したオプションに従って個別に修正したものを添付する。これが、製造BOMのトランザクション・データになる。

つまり、ただ一つのBOMデータでいろいろな業務機能をまかなおうとするから問題にぶつかるのである。BOMには、最低でもマスタとトランザクションの二種類が必要である。これは、わたしが拙著BOM/部品表入門で提案したことだ。より正確に言えば、トランザクションは「これで作れ」という指示系履歴データと、「これで作りました」という実績系履歴データに分かれるべきだから、BOMは合計、3種類必要だ、というのが、わたしのかねてからの主張である。

顧客の要望する機能や仕様は多様化しており、作り手がその流れを止めることはほとんど不可能である。そこで、いろいろなオプションや付属品をご提供することによって、なんとかニーズを満たしてもらう訳である。その無数に増え続ける組合せを、パターン化するための方法が、仕様に対応する「モジュラー化」の考え方なのである。モジュラー化とは、標準的なモジュールの組合せによって、選択のバリエーションを作りだす方法で、いわば注文住宅とプレファブ住宅の違いと言ってもいい。モジュラー化設計によって、必要な部品やサブ・アセンブリーのバラエティを減らし、ある程度見込をつけて生産しておくことができるようになる。そして、BTO生産方式(「ATO」とも)に近づくことができ、注文から納品までのリードタイムを劇的に短縮できるようになる。そのような生産革新のキーが、モジュラー化BOMなのである。

→「革新的生産スケジューリング入門」にもどる

ATO、BTO、CTO (2007/11/08)

生産管理の本を読むと、最初に生産形態の分類が出てくる。「受注生産」と「見込み生産」だ。受注生産はさらに、個別受注生産と繰返し受注生産に分けられる。

見込み生産は、たいていの人が思い浮かべる生産方式だろう。需要を見込んで、製品を生産し、販売していく。商店街のパン屋も、横町のお団子屋も、見込みで商品を生産している。食品、飲料、衣料、書籍、雑貨・・こうした、我々が日常生活で買う商品はほとんどすべて、見込み生産で作られる。携帯電話や自動車も、そうだ。こうした一般消費財をつくるメーカーは、TVでも新聞でも、たくさん広告を打つ。知名度を上げて、皆に買ってもらいたいからだ。だから私たちが「大企業」といわれて思いつく会社は、たいていが消費財メーカーだ。

そのせいだろうか、日本では生産形態は見込み生産が普通で、受注生産は特殊だと思っている人が多い。じつはとんでもない間違いである。自動車を考えてほしい。トヨタ自動車の下に、系列部品供給メーカーが何百いるだろうか。こうしたメーカーは、みな受注生産だ。ただし、生産財を作っているから、業界の人以外には知られていない。この間、何人もの大学生にたいして、日本を代表する超優良電子材料メーカーの名前をいくつか上げて知っているかたずねてみたが、ほとんど誰も知らなかった。これから就職活動にいそしむ3年生なのに、消費財メーカーにしか目が向いていないのだ。これでいいのだろうか?

いや、思わず脱線してしまった。私が言いたいのは、日本では受注生産の形態の方がずっと多くて、普通であるということだ。

その受注生産は、さらに2種類にわけられる。繰返し受注生産は、すでに設計の決まっている製品を、注文を受けてから作る。寿司屋のカウンターで注文するようなものだ(回転寿司は、見込み生産である)。本格的な鰻屋もそうだ。客の顔を見てから作る。一方、毎回、ゼロから設計して作る形態も、少なくない。たとえばオーダーメードの服屋さんを思い出してほしい。あるいは、注文住宅の大工さん。基本的に、建設業は個別受注生産だと思って間違いない。そして、SIerの業界もそうですね。個別受注生産は、お客の細かな希望/要望をすべてくみ上げることができるのが長所だ。

見込み生産のことを、英語ではMake to Stock=MTOと呼ぶ。作って在庫にする、の意だ。一方、繰返し受注生産は、Make to Order=MTOという。注文にたいして作る。そいして、個別受注生産を、Engineer to Order=ETOと略す。

ところで、この3種類にたいして最近、新しい生産形態があらわれ、急進してきている。それが、ATOなのである。ATOとは、Assemble to Order。日本語で、『受注組立生産』という。

受注組立生産とは何か? それは、部品あるいは中間製品やモジュールの段階まで、あらかじめ需要を見越して作って在庫しておく。そして、顧客から注文が来たら、即座に部品/モジュールをあつめて組立て、出荷する形態だ。

こんなやり方がなぜ注目を集めているのか。それは、このATOが、MTSもMTOもETOも抱えていた悩みを、かなり解決できるからだ。それは、リードタイムと在庫のバランスの悩みである。

ETOは何しろ、注文してから設計をはじめる訳だから、納品までのリードタイムがやたら長い。洋服でも3週間、住宅なら3ヶ月、プラントなど3年もかかってしまう。その間にお客の要望も懐具合も、どんどんかわっていってしまう。MTOは既に設計図がある分だけリードタイムは短いが、やはり注文してから材料を買って加工し始める。今日の明日、というわけにはいかない。

これにたいして、MTSは注文・即・納品。なにしろ在庫がある。そのかわり、売れ残りや陳腐化の在庫リスクを、つねにメーカーは抱えている。そうしたリスク費用が、すべて乗せられて値段が決まる。客の好みは多様だから、ひどくたくさんの種類の製品在庫を積んでおかなければならない。そのコストは半端ではない。

ここで、ATOの出番である。ATOでは、顧客の要求する仕様に応じた製品を、その場で、中間部品やモジュールの組合せで実現する。これを最も早くから見事に実行したのがDell Computerである。PCのたぐいは、仕様やオプションのバリエーションがとても多い。そこで、Dellは客が自分で「お好みメニュー」を選べるようにしたのである。そして、部品在庫はもっておく。だから注文して数日のうちに、好みの商品が送られてくる。

Dellではこの方式をあえて、BTO=Build to Orderと呼んでいる。だから、受注組立生産のことをBTOとよぶ人も多い。また、客先の希望に応じてコンフィギュレーションしていくわけだから、Configure to Order=CTOとよぶこともある。

ATOが巧みなのは、きわめて多様な顧客の要求仕様を、部品組合せのかけ算によって実現している点である。たとえていえば、1,000種類の要望があっても、それをCPU 10種、メモリ10種、ディスク10種の組合せで対応する。だからモジュール部品在庫は水準を低く保てる。たとえていえば、麺のかたさやトッピングを好きに選べるラーメン屋のようなものだ。

そのかわり、ATOには前提条件がある。それは、モジュール化に対応した設計になっているということだ。BOM(部品表)もその設計に応じた構成に整備しなければいけない。つまり、ATO生産のためには、設計の根本から対応を要求されるのである。

それでも、なおMTSやMTOからATOを目指す企業は多い。それは、やはりリードタイム短縮と在庫低減の効果が、非常に魅力的だからである。今後も、ATO生産形態を目指す製造業は、増えこそすれ減ることはないだろう。

→「革新的生産スケジューリング入門」にもどる

意味無しコードのすすめ

商売柄、多くの製造業の顧客に接していると、つくづく感じることがある。それは、生産の世界はとても多様なのに、抱えている問題はだいたい似通っている、ということだ。工場と生産のあり方は、つくるモノによって非常に異なる。電子材料・精密機器・医薬品・飲料・アパレル・産業機械・化学・原子力関係・・最近かかわった業種をランダムに思いだしてみても、それぞれじつに多様な条件下で、ものづくりが行なわれている。

にもかかわらず、多くの企業で抱えている問題には共通点がある。それは一言でいってしまうとサプライチェーンの悩みであり、それをささえるマテリアル・マネジメントの変化の悩みである。工場は大量・見込み生産の形で大きくなってきたのに、販売はどんどん多品種少量・短納期受注生産のスタイルを要求される。新製品をつぎつぎに市場に投入しなければならないのに、製品開発も量産準備もそれに追いつけずにいるのだ。

それなのに、どこの会社も判で押したように「自分の問題は特殊だ」と信じ込んでいる。この滑稽さは、以前、「特別な我が社」で書いたから、今は触れない。

しかし、「会社四季報」などを見るとつくづく思うのだが、そもそも化学・繊維・機械といった『業種分類』など、いまでは住民票の“本籍地”程度の意味しかない。化学企業が電子部品を作り、繊維メーカーが医薬品で儲け、素材メーカーが飲料を売って成功をおさめているのが今日の姿である。もはや“現住所”はずいぶん離れているのだ。それだけ、日本の技術者の適応能力が高いのだ、とも言える。

しかし、それに比して、管理技術の方は、なかなか進展も変化も見せないものらしい。製品市場では世界に知られる先進企業でも、工場を子細に見ると“えっ、まだこんな方法で生産管理やっているんですか!?”と驚かされたりする。10-15年前に、本籍地から現住所に移ったときの、旧い管理の考え方が、まだそのまま残されていたりするのだ。その一番典型的な例が「意味ありコード」である。

「意味ありコード」とは何か。それは、マテリアル・マスタ(会社によっては部品マスタとか品目マスタとか種々の名前で呼ばれるが)において、それぞれのマテリアルを識別するためのキー・コードのあり方である。そのキーを発番する際、複数の桁区切りをつかって、桁ごとにいろいろな意味を持たせる。これを「意味ありコード」と呼ぶ。

たとえば、PA-C12-74901 という品目コードを持つ部品があったとする。最初のPAは、流体計器という製品ファミリを表わし、C12は製品を構成するサブ・アセンブリのコード、次の749は仕入先のコードで、01は連番、といった具合だ。よく見かける「意味ありコード」の例である。なれた人は、コードをじっと見ると、それがどのような部品で、どこから仕入れて何に用いられるのか、だいたい分かるようになる。とてもインテリジェントな、優れモノのコード体系である・・はずである。

ところが、多くのメーカーでは、これが足かせとなり桎梏となってきている。その理由は、製品の多品種化と、製品領域のシフトである。多品種化にともない、共通部品や共通原料が増えてきた。そうなると、なまじ最終製品に紐づけられた部品コードは不便になってきた。それに輪をかけるのが、製品領域のシフトである(つまり「本籍地」から「現住所」への引っ越しだ)。製品ファミリの概念さえ、次第に現実に合わなくなってくる。こうなると、なまじ「意味ありコード」だったものが、何がなんだか見てもさっぱり分からなくなってしまう。

やっかいなことに、このマテリアル・コードの意味論の混乱は、目に見えない。工場の中で部品の搬送や保管が混乱すれば、だれの目にも明らかだ。しかし、コード体系の混乱は、真面目に生産管理に従事している実務者たちにしか気づれかない。だが、この目に見えぬ混乱は、思いもよらぬ所に影響を及ぼす。それは、製品開発スピードへのブレーキである。もっと具体的に言うと、設計部品表(E-BOM)と製造部品表(M-BOM)の乖離、という形で現れてくる。これが進むと、量産準備の途上でさまざまなトラブルが発生してくる。一番良くないのは、設計部門と工場部門との部門間の軋轢が増してくることだ。

これを避ける方法は一つしかない。それは、「意味なしコード」を採用して、マテリアル・マスタを作りなおすことだ。意味なしコードとは、文字通り、桁区切りなどに意味を持たせない。単純な連番によるコード体系だ。コードだけ見ても、何かよく分からない。だが、別にそれでよいのだ。今日では、どこの端末からでも、マテリアル・コードを検索できるはずだし、今できていなくても、検索可能にすることはたやすい。人間が目で見て判別できるコードが便利だったのは、紙で台帳をつくっていた時代のことなのだ。

考えてみてほしい。あなたの社内の従業員コードは、意味ありコードになっているだろうか? その人の所属部門や年齢や出身によって決まっているだろうか? そんなことをしたら、毎年コードを変えなければならない。だから、たいていの会社は意味なしコードになっているはずである。会社で一番重要である(ということになっているはずの)社員でさえ、意味なしコードで管理しているのだ。なぜ、部品だけは意味ありコードにこだわるのか?

生産管理の仕事を頼まれた場合、私はその顧客のマテリアル・マスタのコード体系を必ず見ることにしている。その作り方で、企業の生産管理のレベル、ひいてはサプライチェーン管理のレベルがだいたい分かるからだ。ただし、意味なしコードへの移行は、単純ではあるが必ずしも簡単な仕事ではない。ある大手通信機器メーカーでは、E-BOMとM-BOMを統合するために「意味なしコード」を使ったが、統合作業自体はかなり大変だったとのことだ。無理もない。コード体系の見直しは、それ自体がプロジェクト・マネジメントを必要とする、立派なプロジェクトなのである。

→「革新的生産スケジューリング入門」にもどる

設計変更(Engineering Change)の取り扱い

私の勤務するエンジニアリング会社は、お客様のために工場を設計し、資材を調達し、建設工事を管理し、操業のための情報システムを納入する、というビジネスを営んでいる。自社では工場を持たず、ひたすら他社のために工場を作るという意味では、サービス業である。しかし、世界各地のサプライヤーから資材を仕入れて、建設現場でそれを溶接・組み立てるという見方をすれば、巨大な組立加工業のメーカーでもある。

エンジニアリング会社がメーカーにたとえるなら、その製品とは工場であり、これは一品ごとの個別受注生産品である。そして、エンジニアリング会社の悩みというのは、世界共通で、『設計変更』(仕様変更)の取り扱いにある。なにせ、“工場という名前の製品”のBOM=部品表は巨大である。したがって、設計が完全に固まり、BOMが確定してから組立(建設)に入る、などということは期待し得ない。BOMが少しでもまとまったら資材調達に走り、まだ残りの部分を設計しながら、同時に建設に着手する。こうして短納期をめざすのである。

しかし、とうぜんながら最初に設計した部分と、後になって設計した部分に、不整合が生じてくる可能性がある。また、仮に設計が完璧であったとしても、客先の要求仕様が変わったり、ベンダーの供給性状が合わなかったり、法規制が改正されたりして、設計を見なおさざるを得なくなる。

工場のBOMは巨大であり、かつ設計・調達・建設の役割分担が社内部署にあるため、たとえ小さな設計変更であっても、それがどことどこに、どれだけインパクトを与えるか、担当者だけではつかみきれない。このために、エンジニアリング業界では『設計変更通知』(Engineering Change Notice)と呼ばれる情報伝達の仕組みを使って、変更の確実な伝達とフォローをコントロールしている。そのためのキーとなる職種が、エンジニアリング・マネージャーである。

エンジニアリング・マネージャー(EM)とは、プロジェクト・マネージャー(PM)の下にあって、設計作業一切に責任を持つ職種である。プロマネが映画のプロデューサーだとすれば、エンジニアリング・マネージャーとは、いわば映画監督である。設計の全体像をつねに理解し、それが調達・建設など下流工程の作業にどう関わるかも含めて、采配する権限を与えられている。

設計変更通知は、だれが作成するにしても、必ずエンジニアリング・マネージャーがレビューし承認した上で、関連部署に配布する(どこが関連部署かを考えるのもEMの仕事である)。そのために、変更台帳をつくり、発番と登録を行なっている。そして、どの設計変更は、どんなステータスにあるか(つまり伝達中か変更中か完了か)などをトラッキングしていく。

私の見るところ、見込み生産を含む多くの製造業では、この設計変更通知のコントロール手順がうまく確立していないか、あるいは、あっても十全に機能していないように思われる。その理由はいろいろあるだろうが、“設計変更はあってはならないもの”、“例外的な事象”と考えられているためではないか。それは、最近の製造業を取り巻く状況の中では、明らかにずれた考え方である。

設計は、必ず変更されていく。それにともなって、BOMも生き物のように変化していく−−そう考えて、社内の仕組みを作っていった方が、スピード化の時代にはふさわしいように思うのである。

→「革新的生産スケジューリング入門」にもどる

部品の展開と逆展開

MRPの中心は資材所要量の計算である。製品の需要量が与えられると、そこから、その製品の手元在庫量を差し引いて、正味所要量をまず計算する。正味所要量の分だけ、工場で生産しなければならない。

そこで次に、その製品を構成するBOM(部品表)を参照して、製造に直接必要となる中間部品や資材の数量を求める。かりに製品Aを組み立てる最終組立工程において、部品x・部品y・部品zが、製品A=1個に対して、それぞれ2個・5本・1m必要だとしよう。もし、製品Aの正味所要量が20個だったとしたら、最終組立工程に部品x・部品y・部品zをそれぞれ40個・100本・20mずつ用意しなければならない。これを部品レベルの総所要量ないし従属需要量と呼ぶ。

さて、いま、工場の資材倉庫に部品xが25個あったとしたら、40個の総所要量のうち、残る15個を作っておかなければならない。これが部品xの正味所要量である。もし部品xを1個作るのに、さらに孫部品mと孫部品nを2枚と3個必要とすると(これは部品xの部品表に記述されているはずだ)、mとnはそれぞれ30枚と45個、用意しなければならない。

以下、外部から購入してくる原材料や末端資材になるまで、この計算を繰り返すと、製品A(中間製品と区別するため、最終製品End Productと呼ぶことがある)の生産に対して必要な資材購買量が計算できる。これがMRPの部品展開計算である。

ここまでは、簡単な論理だ。初歩的な生産管理の教科書にも書いてある。ところで、MRPにおける部品の逆展開というのを御存じだろうか?

逆展開とは、この計算を逆にたどることだ(部品展開のことを英語でexplosionと呼ぶのだが、逆展開はimplosionと呼ばれる)。部品表を、下から上へ、子部品から親部品へとさかのぼる。部品mが10枚あると、親部品xや製品Aは、いったい何個作ることができるか? これに部品nが30個あったら、どうか。

この逆展開の計算は、納期回答をするときに必要になる。今、手元にある資材から考えて、すぐに作れる製品の数量はどれほどか。MRPの部品表には、リードタイム情報も同時に定義してあるから、納期も計算可能なはずである。また、製造設備にトラブルがあって、ある部品の製造が工程が止まってしまったときに、その影響する範囲を調べるのにも、逆展開機能は役立つ。

この逆展開計算は単純そうに見える。しかし、実際の工場では部品の共通化を進めているため、部品mが使われる最終製品はAだけではなくB・C・D・・と複数あるはずだ。また、部品mの手元在庫だけがあっても、他の部品がなければ製品は作れない。したがって、製品に価格や優先順位などがある場合、どれを作るべきかという問題を、逆展開計算は内包してしまう。たとえて言うならば、部品展開計算が“多項式の展開”だとすれば、逆展開は“因数分解”なのである。前者はある意味で、機械的に計算可能だ。しかし、因数分解は、人間の発見的な知恵や定石が必要になる。正確な納期回答がAPSを必要とする所以は、ここにあるのである。

→「革新的生産スケジューリング入門」にもどる

BOMにおける不良率と歩留り率の定義

「あなたの会社では、BOMなどの生産管理のマスタ・ファイルに、不良率や歩留り率をどう登録していますか?」と質問されたら、どう答えるべきだろうか。

だいたい、不良率というのは品質管理の問題だから、これを下げる努力こそが大事で、わざわざその数字をマスターに登録してしまったら、改善に結び付かない−−これがふつうの答えかもしれない。

「不良率は品質管理の問題」という捉え方は当たっているが、一面的でもある。最終製品を検査して、不良品を排除し、不良率の統計を取るの品質管理の主な仕事だ。しかし、品質管理課だけで製品の品質を決められるわけではない。製造プロセス全体の中で、いかに品質をつくりこんでいくかが、生産管理全体の大きな課題である。そのためには、製造の各段階、すなわちBOMの階層を下から順に上がっていく製造工程のどこで、具体的に品質を確保できるかを吟味しなければならない。

そもそも、失礼ながら多くの企業では、「不良率」の定義自体あいまいだ。へたをすると、同じ会社の中でも部署が違うと別の定義を使っていたりする。部品・材料の不具合に起因する不良と、工程上のミスで生じた不良を区別して、前者は資材購買課の問題と称して工場不良率から差し引いたり・・。

そこでまず、混乱を避けるため、資材が製造作業(工順)によってBOMの階層を一つあがるときの、歩留り率(yield)を、つぎのように定義してみる。
 
 歩留り率=その工順から実際に産出された親品目の数量 ÷ その工順から産出されるべき設計上の数量
 
 ただし、ここで「産出されるべき設計上の数量」とは、その工順に投入した子部品の数量と、設計上のBOMにおける所要比率から計算する。
 たとえば、親品目Xを1個組み立てるには、子部品A・B・Cが2:2:5の割合で必要だ、と設計上きめられているとしよう。そして、ある日の作業で、A・B・Cを200個・200個・500個用意して、組み立て作業をしたとき、でき上がった親品目のうち、品質検査に合格したものが90個だったら、歩留り率=90÷100=90%になる。

 ところで、用意した子部品Cの500個のうち、実際には450個しか使い物にならなかった(あとの50個は購買時点から不良だった)としたら、どうなるか。今度は、「その工順から産出されるべき設計上の数量」は90個だから、そのときの歩留り率は100%だとわかる。

つまり、歩留り率は、その「工順」の産出効率、すなわち作業品質を計るものなのである。なお、製品にならなかった分の材料は破棄されると考える。もし、それが原材料として再利用(リサイクル)可能ならば、工順の製品として原料を登録すべきだろう。そのときは、BOMにループ(自分自身に親子関係を持つ)ができる訳だが。

つぎに、不良率(shrinkage)を定義する。
 
 不良率=1−(設計上必要とされる子部品の数量/実際に消費した子部品の数量)
 
「設計上必要な数量」とは、BOMに規定されている部品の所要比率×生産すべき親品目の数量で計算される。さきほどの例で行くと、親品目を100個つくる際に、子部品A・B・Cをそれぞれ200個・220個・500個消費してしまったとしよう。部品形状その他のせいで組み付け作業が難しく、Bだけは余計に必要としてしまったと。むろん、用意した部品Bはすべて良品であるという前提だ。このとき、子部品Bの不良率は100%−(200/220)=約9%、という事になる。

つまり、不良率というのは、工順で使用する「部品」それぞれの、無駄になる比率を表している。歩留り率と不良率は、工順のアウトプットとインプットをそれぞれ計るものなのだ。

工場というのは、製造のあらゆる段階で検査をしているわけではない。検査には余計なお金も人もかかるからだ。しかし、不良部品を後工程までずっと流してしまって、最終検査で引っかかったら、それまでの資材と手間がかなり無駄になる。したがって、途中のどこで部品の検査をするのが最も効率がいいのか考えるためにも、BOMには不良率と歩留り率の登録が必要である。

また、生産計画で与えられた最終製品の数量から、原材料の量を部品展開して計算する際にも、不良率および歩留り率を考慮する必要がある。これもBOMに不良率を登録する理由になっているのである。


→「革新的生産スケジューリング入門」にもどる


→「革新的生産スケジューリング入門」にもどる
サイトマップ
このページの冒頭に戻る

(c) 佐藤知一
e-mail: tomsato@rio.odn.ne.jp