人気ブログランキング |

カテゴリ:サプライチェーン( 154 )

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

当サイトの記事アクセスランキングを見ていると、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=「工程表」と呼ぶ。これが当サイトにおける用語とモデルである。
e0058447_23275319.jpg

もっとも、もしかすると、あなたの会社の使っている用語とは異なるかもしれない(たとえば「工順」ではなく「工程」と呼ぶとか)。だが、日本には米国における「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)



by Tomoichi_Sato | 2019-09-08 23:36 | サプライチェーン | Comments(0)

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


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

もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから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データベースが必要になる訳である。

e0058447_23170544.jpg
そして、これこそが、いわゆる「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
BOM/部品表の基礎と効果的な活用ノウハウ

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


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


by Tomoichi_Sato | 2019-08-28 23:24 | サプライチェーン | Comments(0)

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

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

もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから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
BOM/部品表の基礎と効果的な活用ノウハウ

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



by Tomoichi_Sato | 2019-08-28 23:18 | サプライチェーン | Comments(0)

BOM/部品表に関するセミナー講演のお知らせ(6月18日・東京)

お知らせです。
来る6月18日(火)に、BOM/部品表に関する有償セミナーを行います。場所は東京・新宿です。

ご承知のとおりBOM/部品表の構築と保守は、製造業にとって古くて新しい問題です。わたしは2004年に「BOM/部品表入門」を上梓しましたが、この本は発刊後15年経っても、いまだに現役です。昨年も増刷され累計1万部を超えたばかりか、中国語版もかなり売れています。

それはしかし、BOMのマネジメントに関わる根本の問題が、多くの企業で、未解決のまま長く残っている事を意味します。とくに近年は、
 ・新製品開発・投入のサイクルが早くなったことと、
 ・製造のサプライチェーンが国境をまたいで海外に伸びたこと、
 ・企業買収や提携が進んでいること
などの要因が相まって、BOMの維持運用を難しくしています。

ともあれ、近年製造業でも多少は情報化投資の余裕が出てきたことと、データ・サイエンスや統合データ・マネジメントに関心が集まったことで、ふたたび注目されているのでしょう。また過去15年間に、この分野でたしかに進展もありました。たとえばBOP(Bill of Process=工程表)概念の普及や、海外を中心としたPLM(Product Lifecycle Management)ソフトウェアの発達などが挙げられます。

わたしは最近、有償セミナー講師をいささか控えてているため、このテーマで講演するのは2年ぶりとなります。今回はとくに、著書に詳しく書いた量産型の製造業だけでなく、BOMを扱いにくい個別受注生産における知恵にも光を当てて、「自分で考え身につく」セミナーを目指します。

この問題に関心のある方のご来聴をお待ちしております。

<記>

日時: 2019年6月18日(火) 10:30~17:30

テーマ: 「BOM/部品表の基礎と効果的な構築・活用ポイント ~演習付~

主催: 日本テクノセンター

会場: 〒163-0722 東京都新宿区西新宿二丁目7番1号
     小田急第一生命ビル22F

セミナー詳細: 下記をご参照ください
     →詳しい開催案内


 よろしくお願いします。
               (佐藤知一)


by Tomoichi_Sato | 2019-04-16 22:45 | サプライチェーン | Comments(0)

なぜエレベーターは(そして仕事も)、一度にまとまって来るのか

デパートに買い物に行った。行きたい階は、上の方だったから(なぜ男性用のフロアはいつも上階にあるのだ)、エスカレーターだと時間がかかって面倒そうだ。エレベーターにしよう、と決めた。ところがエレベーターの所に行って待っていても、なかなか来ない。しまった、これならエスカレーターの方が早かったか、と思う。

とくにイライラしたのは、3台並んでいるエレベーターが、みな同じような階を同じ向きで動いていることだった。自分は1階にいて、6階にいきたいと思っている。ところが数台あるエレベーターは、皆なぜか、8階あたりを上に向かって進行中だ。何だこりゃ。もっとばらけて動いていたら、待たずにすむのに、と思う。

なぜ、エレベーターというのは、複数台あっても同じような動きをしていて、来ないときはずっと待たせ、来るときは一度にまとまってくるのか?

オフィスビルでも、エレベーターの待ち時間は、たぶん似たような状況にある。あるはずだ、と思う。ただ断定できないのは、最近のオフィスビルのエレベーターでは、どの階にいてどちらに動いているのかを表示せず、単に近くまで来たらランプで知らせるような仕組みが多いためだ。各エレベーターの位置や動きを表示しないのは、それを表示すると利用者がかえってイライラするからだ、と聞いたことがある。
(デパートが現在位置を表示しているのは、逆にたぶん顧客サービスの観点なのだろう。)

それにしても、エレベーターが団子のように固まって動くと、どういう状態が生じるのか? ようやく来たエレベーターに乗り込んでから、あらためて考えてみた。たとえば1分に1台ずつ来る場合と、3分に3台がまとめてくる場合の、待ち時間を比べてみよう。前者では最大待ち時間が1分なのに、後者では最大3分待たされる。そのため、エレベーターホールに並んで待つ人数が、どうしても増えてしまう。つまり、いったん団子運転の状態が生じると、待ち時間にムラが生じるのだ。

では、待っている人数が増えると、どうなるか。当然、乗り降りに余計な時間がかかることになる。すると、エレベーターが階と階の間を移動する平均速度が、どうしても遅くなってしまう。そして、さらに待ちの人数が増えることになる。悪循環である。別にここで待ち行列理論など持ち出すつもりはないが、結局、ある限度まで人数が増えたところで、平衡点に達する。その人数は、平均的に分散して動いているときよりも、ずっと多くなる。

なぜ、エレベーターは適度に分散して動かず、団子になってしまうのか? これは、よく考えてみると当然の理由がある。たとえば、複数台のエレベーターが、同じ方向を、一定間隔をおいて動いている状態を想像してみよう。さて、進行方向の先の階に、利用者がいて、ボタンを押して呼んだとする。すると、その階に一番近い箱が、止まってその客を拾うはずだ。

するとどうなるか。先頭の箱(ちなみに、英語ではエレベーターの箱のことをCarと呼ぶ)は、利用者を乗せるため、平均の移動スピードが、他の箱よりも遅くなる。たくさん乗客を乗せた箱は、降りるために止まる階も増えるだろう。各階停車になりがちだ。他方、一群で動いている最後の箱は、平均よりも速いスピードで移動する。なぜなら、ほとんどの利用者を、前に走っている箱たちが拾ってくれるからだ。

集団で移動する群れにおいて、先頭が遅く、後尾が早くなったら、団子状態が生じるのは当たり前である。だからエレベーターは、はじめは均等に動き出しても、次第に団子運転に陥っていくのだ。
e0058447_22414140.jpg
いったん団子ができると、利用者の到着がかなり減るまでは、解消しにくい。エレベーターには追い越しもあるが、追い越して先頭に行った箱は、やはり乗降客を先に拾うので遅くなる。満員通過もあるが、利用者の降りる階は通過できない。だから混んでいると各駅停車になりやすい。

そして、これと同じ事が、わたし達の仕事でも起きているはずだと、気がついた。

仕事というのは、なぜか知らないが、しばしばまとまって、やってくる。忙しいときに限って、さらに依頼だの注文だのトラブルだのが舞い込んでくるのだ。そして、これが、わたし達の仕事を、いっそう非効率で、ややこしいものにしている。

わかりやすいように、工場の例で考えてみる。建物のエレベーターではなく、工場の機械を想像しよう。機械は別に、階を移動したりはしない。しかし、かわりに、時間のなかを移動する、と考えてみる。1階ずつではなく、1日とか1時間という単位(タイム・バケット)ごとに、動いていく、と。載せるのは、利用者ではなく、加工対象のワークである。そのワークごとに、所要時間(=移動日数)が決まっていく。ちょうど利用者ごとに行き先の階が決まっているように。

ただ、エレベーターとは違い、別々の客(=異なる種類の品目)を混載することは、普通ない。だから機械の処理速度自体は、どれだけ注文が混み合って、その機械の前に未加工品の在庫の列が並んでいようと、変わらない、と思われている。いや、セットアップ・タイム(段取り時間)を考えれば、ロット数が大きいほど、むしろ全体の効率が上がるはずだ、と。

ところが、工場をよく観察していると、加工待ちの行列が増えるほど、機械の平均的な処理速度が落ちていく現象が、しばしば観察される。その主な理由は、モノ探しである。手前の行列が増えるほど、次に加工すべきワークの所在が分かりにくくなるからだ。加工速度は変わらなくても、セットアップ・タイムが長くなってしまうのだ。

とくに、個別性の高い多品種の組立加工をしている場合(今の日本ではたいていそうだが)、それに必要な部品が全部そろっていなかったり、ツールや金型を待ったりする可能性が増える。しかたなしに、製造順序を入れ替えて、別のワークを探しに行かなければならない。現場の製造順序が入れ替わると、下流工程や出荷日にまで影響が及ぶ。だから社内外の調整作業も発生する。本来そんな作業は不要だったはずなのに、余計な仕事が増えるのだ。

おまけに、機械も人もフル稼働が続くと、どうしても疲労や故障も起きやすい。忙しいプロジェクトの追い込み時期に限って、キーパーソンが倒れたり現場で事故が起こったりするのも、よく見聞きする話ではないか。

機械ではなく、人間が頭脳労働だけを担うホワイトカラー的職種も、じつは似たような事が起きる。人間だって、マルチに案件を抱えると、どうしても頭の切替えのために、一時的に集中度が落ちる。これは心理学的実験でも明らかだ。それに受注した仕事量が増えると、どうしても優先順位の判断だとか、日程の入れ替えのための調整時間が増える。

人が足りないから、他から人を入れて増員することもよくある。だが、そうすると、増員された人がその案件の状況を理解するまでの、学習時間がかかる。キャッチアップするまでの間、当然ながらその人の生産性は、最初から関わっていたときよりも落ちる。こうしたことが、仕事の繁忙に伴う、生産性の低下である。

仕事量が増えて忙しいと、平均的な生産性が下がる。でも仕事量が減ってある程度余裕ができると、処理スピードが上がる。だったら、職場全体では、適正な速度にバランスするのではないか、と思いたくなる。

ところが、そうはならないのだ。現在の原価計算では、工場の稼働率が下がると、機械の1時間あたりのコスト(賃率)が上がるしかけになっている。SIerや建設業など、受注産業では同じ事情だ。つまり、同じ仕事でも見積金額が上がるのだ。上がったら、コスト競争力が下がって、仕事がとれなくなる。

仮に賃率が据え置かれたとしても、会社というのは受注量が減ると、注文を取ろうとして、見積案件数を増やしていく。見積自体は、金にならない。だから大してヒマにならないのに、生産性(付加価値労働生産性=労働時間あたりのスループット)は下がっていく。

仕事については、もう一つの要因も考えられる。それは、繁盛している店には客が殺到し、閑散とした店は客が敬遠する、という事情だ。行列がさらに行列を呼ぶ、といってもいい。コンサルタントなども、満足した顧客による評判が、さらに顧客を集め、逆に評判の乏しい所には、あまり顧客が集まらない。つまり顧客の側に同調作用が働くのだ。株価は上がるとそれを買う人が集まってますます上がり、下がると離れる人が増えてますます下がるのと、同じ理屈だ。同調作用は、不安定性と偏りによる波を生む。

このような波が生じると、当然ながらその波は、さらに発注先の企業や業種に伝播していく。セットメーカーに波があれば、部品メーカーにも波が及ぶ。サプライチェーン全体に波が伝わっていくのだ。しかもこの波は、ブルウィップ現象によって、しばしば増幅されていく。

世の中には、「シリコン・サイクル」だとか「エチレン・サイクル」などの、業界別の設備投資の数年単位の波が観察される。こうした波も、似たようなメカニズムで生じているのかも知れない。そうでなくても、もっと細かな波は、あるいは需要の「団子現象」は、あちこちで起きやすいのだ。

こうした波の存在は、企業全体の、いや、業界全体の生産性を損なっている。波がひどすぎると、企業経営者は、人件費を固定費から変動費に切り替えたいと考えるから、派遣労働者に頼る比率が増えていく。そうなると雇用環境が不安定になって、ますます実質賃金が下がり、消費が冷え込んでいく。すると需要が下がって・・

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

エレベーターの話に戻そう。世の中には、「AIで制御すればいいじゃないか」と、何でもAIで解決するかのように思う人もいるだろうが、そうではない。この問題の本質は、「先行する箱が、待っているすべての乗客をサービスしようとするため、平均移動スピードが下がる」「後続する箱は、客が少ないから、早く移動できる」という問題にある。この原則がある限り、AIでも団子運転はどうにもならない。

したがって、先着の箱が「すべての客をサービスする」ことをやめない限り、解決はないことが分かる。

答えは簡単である。一度に乗り降りする客数を制限して、移動速度を平均化するのだ。そんなことをしたら乗れなかったお客が怒って大変だぞ、と思うかもしれない。そこで、乗降客を、行き先の階ごとにまとめて、一つの箱に乗ってもらうよう誘導する方法が考えられる。行き先別に、2-4階、5-7階、8-10階、という風にグルーピングし、箱にもそう表示するのだ。

ただしこの場合は、エレベーターホールの上下リクエスト・ボタンを、箱ごとに個別に設定する必要がある。事実、最近のオフィスビルでは、上下ボタンではなく階別にボタンが並んでいて、自分の行き先階を個別に押すタイプも出てきている。

もっとも、この方法はハードの改造が必要だ。それがムリな場合は、人が制御するしかない。つまり、一昔前の、エレベーターガールの復活である(別にボーイでもいいが)。とにかく、意思を持って、需要量をコントロールするしかない。「恐れ入りますが、次のエレベーターをお待ち下さい」という必要がある。

では、仕事は? 仕事についても、実は同じだ。自分の適正な能力を超えて、仕事を取り過ぎないようにしなければならない。だが、たいていの企業にとって、これはとても難しい。営業部門は受注高で目標管理するのがつねだし、経営者もできる限り売上を増大して株主にアピールしたい。多くの企業にとって、自社の実際的な遂行キャパシティは、数値的によく見えていない。だから、過剰な受注でも「気合いと根性」で何とかできると思いがちだ。

ところで以前も書いたように、トヨタ生産方式の人達は、「ムラがあるからムリをする。ムリをするから、ムダがでる」という言い方で、仕事量のムラが様々な問題の根本原因と考えている。だからこそ、あれほどトヨタは平準化生産にこだわるのである。

多品種の場合も、品種ごとに数量を固めて作りだめをするのではなく、あえて数量を期間内に一定に散らして指示を出す。営業部門に対しても、平準化した受注ができれば、どれだけ工場は作りやすいかを、トヨタでは教育する。

営業部門が、平準化も何も考えずに、ただ客のいうとおり仕事を取ってきて、特急注文も変更も右から左に技術部門や工場に回すような企業では、波は防げない。だから、自社のキャパシティを、営業と技術部門とで可視化して共有するような仕組みが必要だ。それはたとえば、製造業における「生産座席予約」のような仕組みである。

と同時に、逆に、自社の波を、サプライヤーに波及させない工夫も必要だ。サプライヤーに波をかぶせると、相手の生産性を下げるわけだから、結局は高い買い物をすることになる。それよりもむしろ、自社で原材料の在庫をある程度抱えて、サプライヤーには平準化した一定量を発注するようにした方が、賢いということになる。今、あちこちの会社がやっている「JIT納品の押しつけ」とは、反対のことをやる訳だ。

「そんなことをしたら、自社だけが変動のリスクをかぶることになる」という意見が出そうだ。あらゆることを変動費化して、すべてのリスクを他者にヘッジするという、現代流の経営思想には、あまりマッチしない。外資系コンサルなどからも、賛同は得られまい。

だが、サプライチェーンの中では、自らがリスクに身をさらして、需給を調整する機能を持つところが、結局はパワーを得る。それが、サプライチェーンの原理である。団子になったエレベーター群で、誰が一番先に乗り込むか競争するよりも、団子にならないエレベーター操業を考えて守る方が、わたしは賢いと思うのだ。


<関連エントリ>
 →「とれるだけ仕事をとってはいけない」 https://brevis.exblog.jp/22850999/ (2015-03-03)
 →「ムリ・ムラ・ムダ 〜 どれが一番いけないか?」 https://brevis.exblog.jp/25029784/ (2016-12-09)
 →「BtoB企業とサプライチェーンの強者 ~これから就活をする大学3年生へ」 https://brevis.exblog.jp/19283044/ (2012-11-28)


by Tomoichi_Sato | 2018-12-05 23:18 | サプライチェーン | Comments(1)

コード体系の設計法を考える

はるか数千年前の古代中国。動物は、以下のように分類されていたという。

(a) 皇帝に属するもの、(b) 香の匂いを放つもの、(c) 飼いならされたもの、(d) 乳呑み豚、(e) 人魚、(f) お話に出てくるもの、(g) 放し飼いの犬、(h) この分類自体に含まれているもの、(i)気違いのように騒ぐもの、(j)算えきれぬもの、(k) 賂蛇の毛のごく細の毛筆で描かれたもの、(l) その他、(m)いましがた壷をこわしたもの、(n)とおくから蝿のように見えるもの。

これは哲学者M・フーコーの『言葉と物』の冒頭に紹介されている話だ。分類体系としては、いささか奇妙である。まず、皇帝に属するもので、かつ、香の匂いを放つものは、どちらに分類するのか。それに、乳飲み子から育ってしまった豚はどうするのか・・

ま、これはもちろん真面目な顔をして書かれた冗談である。調べると、どうやら元ネタは、アルゼンチンの作家ボルヘスのようだ。幻想的な作風で知られる南米の巨匠ボルヘスらしい、奇妙なウィットに富んだジョークだ。

ただ、物事を体系的に精緻に分類するのが好きな文化と、あまり分類には関心を持たぬ文化が存在するのは事実らしい。たとえばギリシャ・西欧文明は前者で、彼らの学問はしばしばカテゴリー論と認識論にこだわる。他方、東アジア・東南アジアは、後者に属するのではないかと感じている。これは個人的な感触に過ぎないが、しかしたとえば梅棹忠夫も「東南アジア紀行 」 で、タイや中国の大学研究のあり方についてそんなことを述べていた。ちなみに生物の分類学を体系化し、「学名」という命名システムを発明したのは、西洋人のリンネであった。

ところで今、分類体系とか命名システムという語を用いたが、では中国語で『系統科学』というと、何を差しているかご存じだろうか? じつはこれ、System science すなわち「システム学」の事なのである。システムとは、元々、系統あるいは体系のことを指していた。現に今でも英語では、(生物)分類学のことをSystematicsと呼んでいる。

だから我々も日本語では、システム工学とか書かずに、「系統工学」とでも呼んでおけば良かったのではないかと、時々思う。システムエンジニア(SE)ではなく、系統技術者である。漢字の方が、カタカナより、多少は分かるような、あるいは威厳を感じさせるような気がする。今日、多くの経営者が、「俺はシステムとかコンピュータとかって、サッパリ分からん」、で済ましていて、IT分野の技術者はいつも傍流扱いの金食い虫みたいに思われている事態も、少しは防げたかもしれない。

さて、前回の記事「従業員番号のない会社、あるいは、わたし達の社会のアキレス腱について」 で、コード化に関するリテラシーの低さが、わたし達の社会のアキレス腱になっていると書いた。わたし達の仕事においては、何かを追いかけコントロールしたかったら、それに整理番号のコードをふっておくべきである。これはビジネスにおける業務知識だとか技術だとかよりももっと基本的な、思考と行動の習慣であって、わたしが「OS」と呼ぶものの一部だ。

わたし達の社会は、はっきり言って、物事にコードを振る、という部分のOSが弱い。コード体系の作り方も、あまり上手ではない。いや、それ以前に、コード体系の作り方に上手下手がある、という感覚自体が薄い。「コード設計論」を、本来は大学でも教えるべきだとわたしは思うが、そんなコースを開設したというニュースを聞いたことがない。

ビジネスでは従業員番号にはじまって、製品コード、部門コード、取引先コード、受注ジョブコード(製番)、マテリアル・コード(品目コード)など、様々なコード体系が必要だ。なのに、それらは、どこか担当部門が勝手に決めているか、あるいは(例によって、ERP導入に伴う大騒ぎの際に)IT部門の若手あたりに押しつけられる仕事になっている。そして、上に述べたような、わたし達の文化に内在する「体系的分類に関する思考の弱さ」が、足を引っ張ることになる。

一例を挙げよう。ある会社では、マテリアル・コード(品目コード)を、以下のような桁区切りのシステムでとっている。

e0058447_18474441.jpg
このようなコード体系の長所は、何だろうか。そして短所は? −−先を読む前に、少しだけ考えてみていただきたい。

ちなみにこの会社は、製造業である。日本では最も一般的な、組立加工系の業種の、部品メーカーだ。それなりの技術力も持つ、業界では一目置かれる存在の企業である。そこが、このような体系を使っている。そのことについて、あなたはどう思うだろうか。

長所を挙げよう。まず、固定桁数のコードなので、コンピュータで扱いやすい。そんなの当たり前だろ、と思われるかもしれないが、放っておくと、「1, 2, 3….11, 12, 13」みたいな桁数可変の番号を振り始める人間は、いくらでもいる。

それにもう一つの長所は、部品番号を見ると、それがどの製品に使われているか、すぐに分かることだ。これは、製造現場で現品票などがきちんと添付されているならば、「この部品ってどれに使うんだっけ」といったことが、すぐ分かるメリットがある。

では、欠点は? まず思いつくことは、製品の後の部品の連番が、3桁しかないことだ。一つの製品を作るのに、999個を超える部品数が必要な、複雑な製品だったらどうするのか? ・・まあ、この会社は部品メーカーだから、この会社にとっての「製品」は、顧客である自動車メーカーや家電メーカーにとっては、小さな「部品」にすぎないので、たぶんそんなケースはないと思ったのかもしれない。だが、この会社が、将来もっと消費者に近い製品を開発して、売り出さないと、誰が決めたのか? 経営者か? そうではあるまい。

もう一つの欠点。それは、複数の製品で共通の部品を使う場合はないのか、という問題である。ボルト・ナットの類いは、おそらく共通性が高いはずだ。それはどうするのか? まさか、製品ごとに、異なる品目コードを振り直しているのか? だとしたら、合計の在庫数量は、どうやって管理しているのか。謎である。

そもそも、このような部品コード体系を考える、ということは、この会社の技術部門には、「部品の共通化」という大事な問題意識が、最初から欠落しているらしいことを示している。部品メーカーは、顧客の個別注文にいちいち応じることが、命題になっている。だが、自分たちの生産性を上げたかったら、いかに共通部品を増やし、設計を再利用するかが、ポイントとなるはずではないか。

でも、もう少し続けよう。次の例は、どうだろうか?
e0058447_18484535.jpg

このようなコード設計の長所をあげるとしたら、最初の5桁で表される製品コードの決め方が、より体系的(システマティック)であり、2桁目までで種別が明確なことだ。

では、短所は? これは、ここではあえて論じない。読者諸賢は、ご自由に考えてみていただきたい。

この例のように、コードを複数の桁の単位に区切り(見た目が分かりやすいように、ハイフンが良く使われる)、その後に連番を打つ、という方法は広く使われる。前方に置かれるのは、分類を示す記号である。それも大分類・中分類・小分類といった、複数のレベルにまたがる分類であったり、異なるカテゴリー(分野別・素材別・地域別など)の表示だったりする。

つまり、こうしたコード体系では、前半は主に人間にとって「意味」のある判別記号を表し、後半は意味のない番号になっている。問題は、そのようなコード体系の「意味」を、どこまで普遍性を持ち、かつ、長持ちできるように定義できるかだ。

最初にあげた中国の動物分類は、あまりにも馬鹿げているので、まずい体系だということは誰でも分かる。あのような体系は、MECEになっていない。MECEとは、Mutually Excludive and Completely Exhaustiveの略で、ロジカル・シンキング用語である。意味は、「お互いに重複もなく、漏れもない」という意味である。

何かを分類する人は、その分類方法が、MECEであるかどうか、意識する必要がある。ところが、これが案外、難しい。わたし達の文化では、そのような思考の訓練を、初等教育でも高等教育でも、受けていない。

それにもう一つ。西欧的な文化で育った人は、MECEには慣れている。しかし、逆に、分類というものが、時と共に移りゆく可能性のある、動的なものだという感覚が薄い。コード設計には、このMECEセンスと、分類は動的なものという感覚の、両方が必要になる。

じつをいうと、上にあげた2例は、藤井一良著『「品目コードNo.」の考え方・採り方』(日刊工業新聞社)から引用させていただいた。本書は、わたしの知る限り、この問題を正面から扱った唯一の和書である。

この中で著者は、こう指摘している:

「実際、長年パンクなど大きな不具合もなく運用され続けている体系に共通しているのは、“分類の定義設定が懲りすぎていないこと”です。コード体系は永久に継続していくことが大切なのです。」

まことに正しい指摘だ。過度に分類しすぎた体系は、時の移り変わり(事業環境やビジネス構成の変化)についていくことができなくなる。

ついでにいうと、上の文章で「パンク」と表現されているのは、『品番爆発』とよばれる現象である。品目数が、色や外形や表面処理などのバリエーションのために掛け算で増えてしまい、連番の上限を超えてしまう現象である。上の例では3桁しか連番がないから、1000以上に増えると、コード体系が破綻してしまう。

したがって、上手なコード設計では、「意味」の部分をあまり多く取り過ぎず、なるべく単純な「連番」を使う方が良い、ということになる。とはいえ、連番部分の桁数が増えすぎると、人間が覚えきれないし、入力時にミスを誘発しやすい、といった副作用が出る。しかもいったん設計に失敗すると、後でコード体系の変更などという、とんでもないコストを支払うことになる。

コード設計は、こうしたトレードオフの中で、リーズナブルな形態を決めていく、高度に知的な作業なのである。いってみればIT技術、とくに上流工程といわれるビジネス・アナリシスにおいて、きわめて重要なスキルである。なのに、こうした知恵について教える大学もなければ、書いている本もきわめて少ない。こういう知的状況を見ると、わたし達の社会のアキレス腱は本当に大丈夫かなと、いつも心配になるのである。


<関連エントリ>
 →「従業員番号のない会社、あるいは、わたし達の社会のアキレス腱について」(2018-10-19)https://brevis.exblog.jp/27603707/


by Tomoichi_Sato | 2018-11-04 18:50 | サプライチェーン | Comments(0)

講演のお知らせ:「生産スケジューリングの基礎とリードタイム短縮のポイント」(12月5日)

お知らせです。12月に、生産スケジューリングとリードタイム短縮をテーマとした研修講演を行います(有償)。6月に実施した講演がお陰様でほぼ満席だったため、再企画したアンコール版です。

何度も書いていますが、わたしは長年、エンジニアリング会社で国内外の工場・プラント作りに関わってきました。また、それなりに多くの工場も見学しましたが、疑問を感じるケースも少なくありません。「なぜ、こんな所に在庫を持つのだろう?」「どうしていらないモノはたくさんあるのに、必要なモノは欠品しがちなのか?」「ここを工夫すれば、もっと効率よく、かつ楽に仕事ができるはずなのに」

そうした非効率が生じるのは、生産活動の仕組み=『生産システム』の基本デザインに問題があるからです。つまり、生産活動のシステム・エンジニアリングが欠けているのです。むろん、ここで言うシステムとは、コンピュータのことではありません。情報系も一要素ですが、むしろ働く人々と、機械設備と、物流と、それを包む建築空間のことをいっています。こうした基本的なことを抜きにして、ただ最近の流行であるAIやIoTなどの「スマート化」技術を追いかけても、部分的な改善効果しか生まないのがつねです。

また生産システムは、自社を取り巻くサプライチェーンの特性に応じて、適切な機能構成を選ばなくてはなりません。単に、業績の良い他社の物真似をしても、生産形態が違えば、役に立たないのです。

拙著「革新的生産スケジューリング入門」や「BOM/部品表入門」をお読みになった方はご承知の通り、わたしは具体的なテクニック論のみならず、原理に関する体系的な理解を重視します。そのため、生産システムをより良く運用するにはどうしたらいいかを考える『システムズ・アプローチ』をとります。そのため業種分野については、わりと間口を広くとってお話しできる点が特徴です。

普通の現場改善コンサルタントや、ITベンダー系コンサルタント達の提言に、飽き足りない気持ちでおられる技術者の皆さんの、ヒントになればと思っています。


生産スケジューリングの基礎とリードタイム短縮への活用ポイント」(12月5日)

日時: 2018年12月5日(水) 10:30 ~ 17:30
主催: 株式会社日本テクノセンター
会場: 株式会社日本テクノセンター研修室
     東京都新宿区西新宿2-7-1 小田急第一生命ビル22F
     (都営地下鉄大江戸線「都庁前」駅または丸ノ内線「西新宿」駅)

生産計画とスケジューリング、リードタイム短縮について、事例と演習を含めてお話しします。

セミナー詳細: 下記のURLをご参照ください(受講申込もここからできます)

関心のある大勢の方のご来聴をお待ちしております。


佐藤知一


by Tomoichi_Sato | 2018-10-11 22:21 | サプライチェーン | Comments(0)

生産マネジメント手法の系譜を考える(3) 90年代以降の発展とこれから

--ちょっとこれまでの流れをおさらいします。生産マネジメントの手法は20世紀前半に、米国の自動車産業が牽引する形で誕生・発展しました。複雑な機械製品を、大量生産することが主眼でした。60年代には計算機を利用するMRPという計画手法が開発され、需要に合わせてロット生産のタイミングを調整し、工場全体を采配する事が現実化します。

「集中管理の実現ですね。」

--そうです。そしてMRPはその後も、発展を続けます。資材調達だけでなく、人員や資金など、製造に必要な経営資源全体の計画ツールにまで拡大し、80年代にはManufacturing Resource Planning = MRP IIという概念が生まれます。そして、これにヒントを得て、ドイツのSAPという名の企業が、Enterprise Resource Planning = ERPという用語を作ります。こちらは皆さんご存じですね。

「ERPって、元は生産管理用語から来たんですね・・」

--はい。だから、今でも主要なERPパッケージは、その生産マネジメント部分にMRP IIのロジックを実装しています。
 ところで一方、日本では70年代ごろから小ロット・多品種で、市場の需要にきめ細かくより添う、トヨタのような生産方式が主流になります。かつての「メード・イン・ジャパン=安物」の汚名をそそぐべく、また現場のモチベーション向上も込めて小集団活動を中心としたTQCが盛んになり、石油ショックも手伝って、日本製品は米国市場で力をふるいます。そして80年代後半には、「ジャパン・アズ・ナンバーワン」、日本型経営礼賛の時期が来ます。

「なんだか遠い昔の話を聞いているような気がします。」
「でもこれ、今も変わらぬ現実だと思ってるオジサンたちも多そう・・」

--かもしれません。ところで、この間、米国も指をくわえて見ていた訳ではありません。あなたがアメリカ企業の経営者だったら、どうしますか?

「ええと。関税をかけるよう政治家を動かして、輸入をブロックします。」

--なるほど。政治に頼る解決ですね。実際、そういう動きもあって、日本の自動車会社は米国での現地生産に取り組みはじめます。しかも、部品の現地比率その他の規制までかかって、単に部品を全て米国に持って行って、現地で最終組立だけするような生産方式は通じなくなります。部品の調達からやらざるを得ない。かくして米国企業は、日本の工場マネジメントのやり方を間近に見ることができるようになります。そして気がつくんです。これは単に、安価な労働力を人海戦術的に使ったやり方ではないのだ、と。

「当たり前ですよ!」

--また、日本にも盛んに調査団を送ります。その結果を、MITが’90年代の初めに報告にまとめ、こうした日本企業の生産方式を「リーン生産」と名付けます。Leanとはお肉の赤身のこと。贅肉のない、つまり徹底して在庫を減らした生産マネジメント方式です。また品質問題についても考え直し、「シックス・シグマ」という概念に至ります。徹底した品質追求から、生産のムダやムラをあぶり出す方法論です。

「日本のやり方を、呼び名を変えて真似しただけじゃないか。」

--そうとも言えません。彼らは概念の体系化に長じていますし、技法も生み出します。それに日本のQCだって、もともと米国の統計的品質管理から学んだのです。

「たしかにITマネジメントの世界でも、アメリカではLean Six Sigmaという言葉を時々見かけます。」

--ところで、少し話は戻りますが、貿易摩擦と関税による障壁は日本企業だけでなく、米国企業をも悩ませることになりました。すでに部品製造を安価な外国にかなりシフトしたしまった会社は、同じく関税に直面します。それだけではありません。米国内での生産と、中米やアジアでの部品製造を、どう上手につなぎ、どうタイミングを合わせるか、という問題に直面します。そしてここから、『サプライチェーン・マネジメント』という重要な概念が登場してくるのです。

「SCMですね。」

--そうです。サプライチェーンという言葉や、供給連鎖という概念は、古くからあったものです。しかし、その全体をマネージしよう、との発想は’90年代以降のものです。最初は流通業における企業間の取り組みからスタートし、製造業にもその概念が波及します。そしてSCMとともに、個別最適 vs. 全体最適、といった問題意識が出てくるのです。

「へえ。全体最適とか、昔からある議論かと思ってました。」

--80年代後半はちょうど、計算機が汎用機からPCへとシフトし、かつ計算能力も通信速度も、飛躍的に伸びていく時期でした。そこでサプライチェーン・マネジメントを実現するために、ITを利用した、新しい発想による技術が生まれます。それが、Advanced Planning & Scheduling = APSでした。APSは、MRPの難点であった負荷計画問題を克服し、最適な生産スケジューリングを可能にしたのです。そして90年代には、実用の時代に入ります。
関税が政治に頼る解決だとしたら、こちらは論理とITに頼る生産マネジメントの改革法です。

「マネジメントのIT化、ですか。うーん」

--同時期にもう一つ、米国では重要なマネジメント理論が現れます。イスラエル出身の物理学者ゴールドラットが、制約理論(Theory of Constraints = TOC)を提案するのです。彼は最初、OPTというAPSソフトウェアを開発していたのですが、ソフトよりも生産マネジメントの考え方の変革の方が重要だと考え、’84年に『ザ・ゴール』という、ベストセラーになったビジネス小説を書きます。これがSCMの概念とマッチして、90年代には生産マネジメントの世界に多大な影響を及ぼしました。TOC理論は、MRP IIなどの持っていた、計画偏重・中央管理のやり方とは一線を画す思想から生まれ、それがSCMにマッチしたのです。ポイントは何だったと思いますか?

「え、何だろう。現場の自主性を尊重するんですか?」
「私、TOCのクリティカル・チェーンという、プロジェクト管理の方法を聞いたことがあります。現場尊重っていうより、なんか、バッファー・マネジメントとかって話だったような気がします」

--そうです。TOC理論では、現場にはいろいろな変動要因があり、計画通りになかなか進まない、という認識がベースにあるのです。生産マネジメントでは、DBRとかDBMといった方法論が提案されます。これらは、工場にある「ボトルネック工程」へのコントロールに集中して、工場全体のスループットを最大化しよう、との発想が中心にあります。複数のサプライヤーをまたぐSCMでは、こうした変動への対処が、さらに重要になるのです。
 でも、日本の製造業は、こうした新しいマネジメント手法には、馬耳東風だった・・。

「え?」

--アメリカから日本に、MRP IIやSCMなどの考え方が紹介されるのは、じつは10年近く遅れたのです。わたしは’98年に、仲間と共著で『サプライ・チェーン・マネジメントがわかる本』を出版しました。この中でAPSやTOC理論の紹介もしたのですが、これは日本語で書かれた入門書としては、かなり早いものでした。なぜ、そんなに情報が遅れたのだと思いますか?

「わかりません。いつもアメリカの情報はすぐ入ってくるのにな。」
「バブル崩壊と関係があるんじゃないですか?」

--バブル崩壊よりも、バブル経済それ自体に関係があります。つまり、’80年代の半ばから’90年代の前半まで、日本人は鼻高々の絶頂期にあった。日本型経営、日本のものづくり、これは世界最高である、と。「もうアメリカに学ぶものはない」--そういう標語さえ、世間を闊歩していたのですよ。

「嘘みたい・・」

--この時期を、わたしは「生産マネジメントの失われた10年間」だと考えています。90年代、バブル崩壊で日本の製造業は、困難に直面します。工場も海外移転し、サプライチェーンが長くなってしまった。でも、日本の生産現場や、経営それ自体の考え方に、ITの重要性がすこしずつ認識されるようになるのは、ようやく2000年代に入ってからでしょう。

「それって、IT開発プロジェクトの世界も、似ているのかもしれません。米国でPMBOK Guideが初めて出たのは90年代前半とききました。でも、日本のIT業界が、PMに真剣に取り組みはじめるのは、2000年代の半ば頃からだったそうです。」

--たしかにね。90年代中頃までは、半導体もPCも、日本の計算機メーカーが世界市場を制覇していました。日本のIT技術は世界一である、とメーカーが思っていたとしても、不思議はありません。

「それってハード製造の分野だけの話で、ソフトウェアが弱いのは昔からなんですけれど。」

--そうですか。まあ、ともあれ、21世紀に入っても、日本からは新しい生産マネジメント思想が生まれません。「現場力」が大事で、職人的な技を磨く「ものづくり」が企業を支える、みたいな考えが強く、あとはヒットする新製品をどう生み出すかが、話題の中心になりました。トヨタは相変わらず強いので、トヨタ生産方式の表面的な真似をする人たちは、たくさん出ましたが、最初に申し上げたように、生産形態も需要特性も違うところに、技法だけ持ち込んだって活きないのです。

「2000年代に、欧米から新しい考えはでてきたのですか?」

--いい質問ですね。二つあげましょうか。米国の「工場物理学」と、ドイツの「Industry 4.0」です。米国では、MRP II・APS・SCMといったメインの流れに沿って、大学にも生産マネジメント学を教育する学科があります。その中からW・ホップという学者が、Factory Physics(工場物理学)という考え方を提唱します。これは待ち行列理論を出発点として、工場内のモノの滞留現象を解析し、リードタイム短縮をねらうとともに、より効率性の高い生産ラインを設計しようという考え方です。これまでの生産マネジメント思想は、すでにある工場を、どう効率よく運用するか、という問題意識でしたが、こちらは一歩踏み込んで、より効率的な工場の生産ライン設計にまで踏み込んでいきます。

「それと、例のインダストリー4.0、ですか?」

--そうです。これは2013年に、ドイツの科学アカデミーが国策として提唱した概念です。最初はかなり抽象的でしたが、だんだんと具体的な技術論に発展してきました。こちらは世界でも高賃金で労働時間の短いドイツが、それを維持しながら国内製造業の競争力をどう向上すべきか、という問題意識が底流にあります。賃金の安い国に工場を移転すればいい、という風には彼らは考えません。かわりに、彼らは市場の要求にきめ細かく対応できるような生産マネジメント能力を作る必要がある、とします。このための手段として、スマート機械とスマート製品の二本立てで、フレキシブルなバリューチェーンを構築すべきだ、と構想します。

「バリューチェーンって、サプライチェーンと違うものですか?」

--バリューチェーンは本来、同一企業内の価値連鎖を指す経営学の言葉ですが、Industry 4.0では複数企業間をまたがるようなケースも想定しています。製品の個別仕様ごとに、違った経路を部品が渡り歩く、というイメージです。ドイツも自動車産業の国なので、量産型機械のイメージが強いのですが、単なる大量ロット生産ではなく、顧客の個別の要求にあわせた製品を作る必要があります。これを、「マス・カスタマイゼーション」といいます。

「日本では、当たり前に実現していることじゃないですか!」

--ですが、それは下請け部品メーカー達の、相当な努力と犠牲で成り立っていることを、忘れてはいけません。それと、機械加工系の工場では、従来、各工程の進捗をつかむのが大変でした。工作機械は皆、スタンドアローンで動いているからです。生産スケジュールをどんなに精密に立案しても、現実の進捗をちゃんとフィードバックしてあげないと、工程表はすぐ絵に描いた餅になります。日本はこれを、現場の職長達の判断でフォローしています。
 ドイツは、IoTなどの技術を使って機械をよりスマート化し、リアルタイムに状態を把握できる仕組みをつくればいい、と考えました。また、CAD/CAMの設計データを、工作機械に直結して流せるよう、あらゆる機械のインタフェースを標準化できる「管理シェル」を作っています。こうしてERPから現場の機械までを垂直統合する「スマート工場」が生まれます。

「あの、スマート工場というのは、何となく分かる気がするんですが、スマート製品って何ですか?」

--部品や製品自体に、たとえばチップか何かが載っていて、自分が何か、今どこにいるか、次にどこに行くべきかを、自分で判断できるような仕組みをつけたものです。組立加工系の工場の悩みは、モノの場所探しにあります。それを、複数企業からなるサプライチェーンの中でも、行き先不明にならないよう、スマート化しようという訳です。さらに顧客の手に渡っても、どのような使い方をされているかを逐一、記録し報告することで、さらなるサービス価値を生み出せる,という訳です。

「それだって、コマツの建機などはもう実現していますよ!」

--製品的には、おっしゃる通りです。日本企業は個別には、Industry 4.0の目指すところを実現している例があります。ですが、システム化とか標準化になると、突然弱くなる。特定個人や企業の強みが、日本全体の強みに共有されません。なぜだか、分かりますか?

「え! ・・産業界にリーダーシップが足りないから、ですかね。」

--ほお。トヨタさんにも、リーダーシップが足りない、と?

「それは違うような気がします。・・でも、分かりません。」

--わたしの答えを言いましょうか。マネジメントに関する科学的・体系的思考が弱いからです。科学として考えないから、技術として定着できない。体系的でないから、個別事例で終わってしまう。あるいは、もっと皆さんに分かりやすい用語を使うと、「システム思考が弱い」になるかもしれません。マネジメントの問題を、リーダーや現場の「人間力」のレベルだけで説明する考え方など、その典型です。

「でも、人間力のどこがいけないのですか?」

--じゃあ皆さんは、デスマーチに陥ってしまったITプロジェクトの問題を、プロマネ個人の人間力不足として、人事評定されたら満足ですか? そうじゃないからこそ、こうやってわざわざ生産マネジメントについて、勉強しにいらしたのでしょう?

「それはそうですが。でも、そうしたら私たちは、この表にあるいろいろな考え方の、どれを学べばいいのでしょうか?」

--どれかを学べば、それがすぐ皆さんの役に立つとは考えない方が良いです。というのも、マネジメントの手法というのは、それぞれ、その時点で直面していた課題を解決するべく、開発されたものだからです。(わたしはボードの表に欄を書き加えて説明した)
e0058447_23175330.jpg
--フォード・システムは連続大量生産の実現が課題でした。それができるようになったら、次は多品種での大ロット生産の在庫適正化のために、MRPが生まれます。他方、より少量生産で、かつ多品種混流でのコストダウンのために、トヨタ生産方式が工夫されます。TQCは品質向上と現場のモチベーションアップが課題でした。
 リーン・シックス・シグマは同じく在庫最小化と改善活動を、米国の企業文化の中で実現することがねらいです。APSはMRP IIの生産計画をより現実的なものとし、SCMを可能にしようとしました。TOCはスループットの最大化と変動へのフレキシブルな対応が、問題意識の中心でした。工場物理学はリードタイム短縮と工程設計論を目指し、インダストリー4.0は先進国の製造業における生産システムの将来形を構想し、マス・カスタマイゼーション実現をターゲットとしています。
 こういう風に、マネジメントの方式は、それぞれ課題意識があって生まれているのです。世の中には今のところ、完全無欠な生産マネジメント手法はありません。それぞれ、何を主要なねらいとするかによって、とるべき手段がかわるのです。

「じゃあ、私たちがトヨタ生産方式に学べるところは、ないのでしょうか?」

--多くの日本企業がトヨタに学ぶべきところは、生産と販売が同じ計画で動くことを徹底している点です。彼らは月度計画と呼びますが、とにかく、実行可能な計画を立てて、それを生産側も販売側もきちんと守る点が、あの会社の最大の強みなのです。つまり、トヨタのやり方は、実は「トヨタ生産販売方式」と呼ぶべきだと、わたしは思っています。ところが、多くの企業では、生産と販売の両輪がかみ合っていない。とくに多くの企業では、販売側が弱い。

「僕の会社では、営業の方が強いですけど。」
「IT系企業を見ると、たいていそうですね。お客様の会社でも、営業の方が強いところが多いです。」

--わたしが言っているのは、社内の発言力の強さのことではありません。計画を立てて、その通り実行できる能力のことです。計画なのか精神目標なのか分からない数字を立てて、そこからズレたら全部、製造側に変動を押しつけるようなやり方は、能力が高いとはいいません。生産と販売が共同で立てる計画のことを、英語ではSales & Operation Plan = S&OPと呼びます。この概念は、MRP IIの中で80年代に生まれたものです。皆さんの会社にS&OPと言える計画はありますか?

「・・ないと思います。」
「しいて言えば、半期の予算計画かなあ。あれも当てにならないけど」

--ITは分かりませんが、製造業では最低でも月サイクルで回していかなければ、S&OPとは言えません。ここがブレると、まずリソースに余計な負荷がかかります。調達にも影響が出て、サプライヤーをこまらせることになります。納期も延びコストも上がるでしょう。

「IT分野でも、人ごとには聞こえません・・」

--さらに物販の場合は、製品在庫が過大になったり欠品したりします。これらは全部、製造と販売がリンクしないために起こります。それを避けたければ、リソースに無理やムラが生じないように、営業側も販売努力しなければならない。

「ですが、営業部門の事なんて、私たちの手に余ります。技術の側で、学ぶところはありませんか?」

--ありますよ。仕事=作業+改善、というのも、トヨタの考え方です。改善におけるPDCAサイクルの概念は、TQC以来、広く普及しています。ですが、業務に必要な作業をしているだけでは、仕事をしたとみなさない、というトヨタの徹底ぶりは学ぶべきです。

「受注したプロジェクトのために、設計や実装作業をしているだけでは、たとえそれが新しい技術要素を含んでいても、改善とはいえない、ということですか? 厳しいですね。」
「でも、自分から新しい方式にチャレンジすることだって、やっていますよ!」

--標準なくして改善なし、というのも、トヨタの標語です。だから先ほど皆さんに、改善活動による効果についてご質問したのです。バグ数でもいい。生産性指標でもいい。何か、これが標準、と定めた上で、その標準をどうやって持ち上げていくかを考えるのが、改善の姿です。
 いや、この考え方は何もトヨタにはじまったものではありません。もっとずっと前、フォードとほぼ同時代に、米国で初めて「科学的管理法」という概念を打ち出し、近代経営学の基礎を作ったテイラーも、それを実践しました。彼の方法論を受け継いだInustrial Engineerng = IEの人たちも、同様です。

「でも、ITの仕事は、工場の労働者とは本質的に違います。繰返し性が少ないんです。」

--プロジェクトはすべて個別だから、比べられない、と皆さんはおっしゃる。たしかに表面的にはその通りです。ですが、その違いの下にある共通プロセスを明らかにして、そこに科学の光をあててこそ、マネジメントが技術となるのではないでしょうか?
 仕事のパフォーマンスを測定し、数値化し、原因を分析して、工夫を加える。これがマネジメントに関する科学的・体系的思考の姿です。それを全部、リーダーや経営者の人間力のせいにしていたら、何の進歩もなくなってしまいます。皆さんがもし、エンジニアとしての自負をお持ちなら、ぜひ、仕事を科学する意識をもっていただきたいのです。


<関連エントリ>
→「生産マネジメント手法の系譜を考える (1)」 https://brevis.exblog.jp/27426439/ (2018-07-23)
 →「生産マネジメント手法の系譜を考える(2) 日本型生産思想のあり方」 https://brevis.exblog.jp/27462519/ (2018-08-02)

by Tomoichi_Sato | 2018-08-11 23:24 | サプライチェーン | Comments(0)

生産マネジメント手法の系譜を考える(2) 日本型生産思想のあり方

「’73年の石油ショックについては聞いたことがあります。石油の値段が急に上がったんですよね。」

--そうです。それまで中東アラブ諸国の原油生産は、事実上、欧米の石油メジャーが支配しており、バーレル$3の超安値で、原油を欧米に輸出していました。しかしイスラエルとの中東戦争に端を発し、ナショナリズムに目覚めた各国が団結し、輸出を止めると脅したので、原油価格は$10以上にはね上がったのです。それが、アメリカの製造業にどう影響を与えたと思いますか?

「エネルギー価格が上がって、製造原価が高くなったんじゃないでしょうか。」

--たしかに、それもあります。でも、一番影響を受けたのは、消費者の側でした。米国の自動車市場で、それまで常識だった、安いガソリンを湯水のごとく消費する、大型のアメ車に頼ったライフスタイルが、ピンチに瀕しました。消費者はやむを得ず、燃費の良い中小型車に目を向けることになります。その市場に入り込んできたのが日本車でした。そして、またたく間にシェアを伸ばしていった。

「高性能・高品質な日本車が、米国市場を席巻したんですね!」

--いや、それは現代から振り返って考える人の錯覚です。’70年代の前半まで、日本製品は、「安かろう悪かろう」の代名詞でした。そして当時の米国への最大の輸出商品は、衣料品と雑貨です。今日のメード・イン・チャイナが持っているイメージと同じですね。

「そんな馬鹿な!」

--信じにくいでしょうけれども。まあ、その時代のことを覚えている人は、もう現役引退の世代ですからね。Deep Purpleという英国の人気ロックバンドが、’72年に日本公演のライブ盤を二枚組LPで出したとき、原題は”Made in Japan”でした。皮肉なタイトルだったのです。日本車も、当時はそういう目で見られていました。そして事実、安かった。まだ固定相場制度で、1ドル360円の時代でしたから。こうして、日本車は米国市場のスキマに侵入し、少しずつ地歩を固めていくのです。

「それで、どうなるんですか?」

--70年代は、アメリカが自信喪失に陥っていく時期でした。石油ショックの後、’75年にはベトナム戦争に最終的に敗北します。アジアの小国ベトナムが、超大国アメリカに史上初めて勝利し、自国から追い出すのです。’70年代は米国の製造業が企業買収で多角化したり、工場を労賃の安い中米に移転したりする動きが、目立ちはじめた時期でした。70年代はまた、あるサービス業種がのびた時期でもありました。何だと思いますか?

「さあ・・鉄道か通信業でしょうか。」

--経営コンサルタントという業種です。彼らの主要な仕事は、経営者にかわって首切りリストラと、コストカット計画を立案することでした。工場の主要問題は立地で、生産管理やMRPではなくなってしまいました。そしてこの時期、日本に対して怒っていた米国人も多かった。皆さんは知らないでしょうが、ハンマーで日本製品を打ち壊すパフォーマンスを、TVカメラの前で議員がやったりしました。彼らの多くは、日本は不公正に安い通貨レートで輸出しているし、何より日本国内の安価な労働力を酷使して、大量に製品を作っているから価格競争力があるんだ、と本気で信じていました。

「なんだか、今、世間の経営者の人たちが、中国製造業に対して抱くイメージと、よく似ていますね。」

--いいポイントです。歴史の皮肉ですね。ただ、日本の製造業が実際に考えて、取り組んでいたやり方は、すいぶん違っていました。自動車産業で言えば、トヨタは’70年頃から、独自の生産方式を築き上げてきました。その発想の原点はきわめてはっきりしている。それは、「トヨタの会社の規模では、フォードやGMみたいに大量生産で安く作ることはできない」でした。

「え? トヨタの規模じゃ小さすぎる、ということですか?」

--そうです。フォードやGMは生産台数が非常に多く、生産ラインを単一車種専用にできました。ラインは同じモノを繰り返して作るわけですから、きわめて生産効率が高い。しかし、当時のトヨタの規模では、一つの生産ラインに複数の異なる製品を流さざるを得ません。小ロット生産の中で、いかに安く効率よくモノを作るか。これがトヨタ生産方式を引っ張った、大野耐一という人の問題意識の原点なのです。

「その答えがカンバン方式ですか!」

--いえ。かんばん方式はツールの一つでしかありません。トヨタ生産方式については、どうも「群盲象を撫でる」的な誤解が多いのです。が、根幹にあるのは、生産と販売が同じ一つの計画で動くこと、その中で徹底した平準化を行うことです。月度計画で、まず大きな線を引く。細かな変動は、かんばん方式などで調整・同期化する。だからかんばんは従であり、ツールなのです。

「・・トヨタって、計画生産だったんですね。」

--そうです。生産と販売がバラバラの計画で動いていたら、良いことはない。80年台前半には、別会社だったトヨタ自工とトヨタ自販が合併します。一体化を進めることも、目的の一つだったんじゃないでしょうか。そもそも営業部門が、製造現場の事情など無視して、勝手に仕事をとってきたらどうなると思いますか?

「ウチの会社なんか、営業がムリな納期や値段で仕事を取ってきて、あとはプロマネに押し付けています・・。」

--工場の生産は、一定のペースで進めるのが一番効率が良い。多品種であっても、月度の中で均等に作っていく。これがトヨタの平準化で、販売もこれを意識するのです。「ムラがあるから、ムリをする。ムリをするから、ムダが出る」という標語があるくらいです。そのために小ロットでも、切り替え時間を短く工夫する。自働化といって、不良が出たら機械が自分で止まるようにする。こういった現場の工夫と改善を引き出すため、あえて中央管理による指示の形を避けるのです。皆さんの職場では、改善はどのように位置付けられていますか?

「ぼくらITの世界では、技術進歩が激しいので、日々、開発のやり方を改善して、生産性を上げる工夫を重ねています。」

--そうですか。それは、すばらしい。それで、過去10年間で、御社では何%くらい生産性がアップしたのですか?

「いや、僕らのは考えるタイプの仕事ですから、生産性は簡単に数字では表せません。」

--なるほど。では品質はどうですか? 品質の改善効果なら、バグの数などで係数化できるでしょう。

「それは、計量化できなくはないですが、開発環境自体が進化していますからね。比較は難しいんです。」
「あの、システム開発は個別設計ですから、量産品のように効果測定はできませんので。」

--なるほど、なるほど。それでも皆さんは、仕事を改善したいという熱意を持って、こうして勉強会をされているんでしたね。すばらしい。日本の現場は、皆さんのような優秀かつ士気の高い人たちが支えているのだと、よく感じますよ。工場に行っても、そうです。
統計的品質管理の手法は、もともと米国から輸入したもので、デミング博士などが指導者として有名です。デミング・サイクルという言葉はご存知ですか?

「たしか、PDCAサイクルのことですね。」

--その通りです。マネジメントとは、PDCAサイクルを回し、改善を積み上げていくこと、との認識が日本の製造業に定着しました。さらには、この品質管理による改善を、職場の小集団活動に結びつけて、TQC (Total Quality Control) という独自の手法に発展させました。「品質は工程で作り込む」。つまり、品質は検査係の仕事ではなく、製造に携わる全員の責任と考えられました。

「まあ、たしかにバグはテスターの責任ではないですね。」

--また小集団による改善活動には、現場の人材育成とモチベーション維持という意義もあります。部門ごとに目標KPIを決め、自分で考えて仕事を改善していく訳です。MRP的な集中管理の排除、品質重視、現場の自主性尊重と責任移譲。これは80年代を通じて、日本の生産管理に広く見られた考え方です。日米を比較すると、こんな感じです:

米国:中央集権。計画重視。現場の人間はただ、マニュアルと命令に従うだけ。
日本:分権的。実行重視でフレキシブル。現場の裁量と自主的改善活動にまかせる。

--こうした比較から、日本型経営は人間重視だと自賛する声も、よく聞きました。ただ、こうした特徴には、裏の面もあります。何だと思いますか?

「うーん、こうして比較を見ると、やはり日本の方がずっと優れているように見えますが。」
「ええと、日本型は、現場に優秀な労働者が揃っているから可能だ、という面はないでしょうか。移民社会の米国では、文字も読めない人が案外いると聞いたことがあります。」

--そうですね。日本型の生産管理は、たしかに分権的ですが、現場の優秀さに依存している面があります。現場の人の会社へのロイヤリティ(忠誠心)は、ある程度、終身雇用制に裏付けられていました。米国の北部、デトロイトあたりの工業は、もともと奴隷解放で南部から大量に来た黒人労働者で成り立った時期がありましたが、彼らに会社への忠誠心は希薄です。改善しても会社が儲けるだけで、自分たちの給料に反映されないなら、誰が進んでわざわざ時間外に改善活動などするでしょうか。
それと、分権的であることにマイナス面はないでしょうか?

「中央集権より、良いと思いますが。」
「リーダーシップが、弱いと思います。」

--リーダーシップは、なぜ必要なのですか? あるいは、こう聞きましょうか。リーダーシップを必要とされるのは、どんな時ですか?

「そりゃ、無いより、ある方が良いに決まっているじゃないですか!」

--あなたは、電車の運転士や、航空機のパイロットに、リーダーシップを期待しますか? ジャンボジェットの席に座ったら、アナウンスが流れたと想像してみましょう。「皆様、ご安心ください。当機の機長は、強いリーダーシップを持っております。どんな変化や苦境も見事乗り越えて進むことができます…

「(笑って)それは、いやですね。席を立って逃げたくなります。」
「そうすると、リーダーシップって、変化が大きくピンチの時に必要なんですね。」

--その通りです。それだけではありません。分権的で現場任せの組織は、意思決定が縦割りで、皆が部門単位の利害を求める、いわゆる『局所最適』マインドになりがちです。この、局所最適・全体最適という言葉自体、米国で、90年代ごろからポピュラーになってきます。それは、ある重要な概念が米国で生まれて来たからです。

(この項つづく)



<関連エントリ>
→「生産マネジメント手法の系譜を考える (1)」 https://brevis.exblog.jp/27426439/ (2018-07-23)


by Tomoichi_Sato | 2018-08-02 22:32 | サプライチェーン | Comments(1)

生産マネジメント手法の系譜を考える(1)

「佐藤さん、お忙しいところ、時間を取っていただき、ありがとうございます。突然お邪魔して恐縮です。」

--別にいいですよ。それより、何のお話しをすればいいんですか?

「ぼくら、生産管理について、少し勉強したいと思っています。ただ、どこから手をつけていいか、よく分からなくて。教科書もあるような、ないような、Amazonとかで探せば、山のように候補は出てくるんですが、どれが良いのか迷ってしまいます。また逆に、自分たちの社内にはあまりそういう資料はなくて。」

--なるほど、生産管理の勉強ですか。皆さんは受託開発のシステム・インテグレーターにお勤めですね。すると、製造業向けのシステム開発に取り組まれるんですか。生産の実務を知っているITエンジニアは少ないので、勉強されるのはいいことですね。

「いえ、少し違うんです、佐藤さん。たしかにぼく自身は今、製造業向けの仕事をしていますが、業務分野は会計システムですし、他のメンバーも、製造業はあまり経験がないんです。ぼくらの勉強会は、しばらくプロジェクト・マネジメントについて勉強してきました。ご存知でしょうが、ITプロジェクトはいろんな問題があって、ひどい赤字が出ることもあります。それで、議論しているうちに、ほんとは製造業の方がずっと上手なマネジメントをしているんじゃないか、って話になって。」
「あのお、たとえば、『トヨタ生産方式』とか、よく聞きますよね。ああいうのを導入したらいいんじゃないかと、私なんか思ったんです。それで、まず生産管理の基本的なところを勉強しよう、となりまして。だったら、佐藤さんがお詳しいらしいので、教えていただこう、と。」

--ははあ。そういう事ですか。ただ、どうかな。IT系のプロジェクト・マネジメントに改善余地があるのは同感だけれど、“製造業の方が管理は上”とか、“トヨタのやり方を導入すれば解決”、とかって意見は、必ずしも賛成できないなあ。

「そうなんですか?」

--うん。そう思い込む人は、よくいますけどね。マネジメントというのは、対象とする組織なり仕組みがどういうもので、何を主眼にして動かすのかによって、全然異なってきます。プロジェクトというのはそれぞれが個別の、一度きりのもので、チーム組織もその場限りの時限的なものですよね。そしてプロジェクト・マネジメントの主眼は、プロジェクトの価値をどう最大化するかにあります。

「はい。」

--ところが、生産マネジメントが対象とするのは、ふつう『工場』と呼ばれるパーマネントな仕組みで、その中を複数の案件・オーダーが動いています。いわば、多数のマルチ・プロジェクトが走っている状態です。おまけに働く人数や機械の数も制限がある。その多数のオーダー間を調整して、リードタイムや在庫や生産性や品質など、互いにトレードオフのある目標値をなんとか合わせようと苦心する訳です。おまけに次々に追加受注や変更が入ってくる、動的な環境です。つまり、動的な適応制御のようなものですね。
 たとえて言えば、プロジェクト・マネジメントは月ロケットの操縦で、方や生産マネジメントは混雑する空港の管制塔みたいなもの、といえるかな。ずいぶん違うでしょう?

「でも、トヨタさんはあれだけ利益を上げているじゃないですか。それにひきかえ、弊社では・・」

--いやいや、ちょっと待ってください。トヨタにはプリウスをはじめとするハイブリッド車などの、新製品開発もあります。製品開発は収益力の重要な柱です。ところがSIビジネスは基本、受注産業でしょう? 林檎とオレンジを比べて、林檎はオレンジに学ぶべきだ、といっても役には立たないですよ。

「じゃあ、どうしたらいいですか?」

--まず、オレンジはオレンジで、どんな種類があるのか、どう進化してきたのかを知りましょう。つまり、生産マネジメントの方法論には何があり、それらは製造業において、どう発展してきたのか。多少、遠回りに思えるかも知れないけど、その方が学ぶ価値があると思いますよ。

「生産管理の考え方って、そんなに種類があるんですか?」

--もちろん、あります。(わたしはホワイトボードに、簡単な表を書いた)ええと、ざっくりいって、7〜8種類くらいあるかな。まあ数え方にもよりますが。

e0058447_22525506.jpg
「最初がフォード・システムですか。」

--うん。そうです。ものづくりの歴史は何千年もあるけれど、非常に複雑な機械製品を大量に生産する必要が出てきたのは、20世紀の自動車工業からです。課題は同じものの大量生産。もう、ここからして皆さんのITプロジェクトと違うでしょ?

「・・そうですね」

--それを解決するために、ヘンリー・フォードという人は、組立中の自動車をコンベヤで一定速度で動かし、順番に部品を組み付ける方法を考えた。そのために、作業を徹底的に分業化し、またタクトタイムという概念で標準化しました。おかげで労働は単純化し、負担も増えたが、フォードは労働者の賃金を上げることで報いた事も、公平のために言っておきましょう。

「へえ、単にブラックだったわけじゃないんだ。」

--そのおかげで、都市近郊に、自動車を買える勤労所得層が生まれ、ますます自動車市場は拡大しました。そこまで考えていたんだと思いますよ。それまでの自動車は、特注の個別受注生産でした。今の業務系ITシステムみたいでしょ?

「ですね。すると、T型フォードはパッケージソフトか。」

--さて、時代は下って1960年代。この頃までに製造業は発展し、次第に製品が増え、多品種化していきます。ところでフォード以来、部品工場はロット生産でした。そもそも米国の製造業は、自社の決めた標準仕様品を大量生産することで、価格を下げる方針が強い。『1ダースなら安くなる』という評語の通りです。ところが多品種化が進むと、工場内のあちこちで、やたらと部品在庫が増えるようになった。需要を読み間違えると、みんな不良在庫化して除却損になります。そこで、必要なモノを、必要なタイミングで、適正量だけ作るような生産計画が求められたのです。

「あ、それが、有名なジャスト・イン・タイム生産ですねっ!」

--いや、そう急がないでください。必要なモノを必要な時に必要な量だけ作るなら、ジャスト・イン・タイムですが、『適正量』作ると申し上げたでしょう? 経済的ロットサイズという概念があって、ある程度の数をまとめて加工した方が安くなる、というのが米国式の考えです。そこで、構造型部品表というマスタ・データをつかって、製品の需要を工程別に展開し、標準リードタイム分だけ差し引いて着手タイミングを決める手法が考えられました。これがMRP (Material Requirement Planning)です。
 MRPは、史上初めてコンピュータを生産管理のために応用した手法です。開発の中心となったのはIBM。

「さすがはIBM、か。」

--ですね。ただ、MRPには弱点もいくつかありました。代表例は、計算時間がかかること。1回の計算が夜間バッチで一晩かかる、というケースは珍しくありませんでした。

「そりゃひどい。そんなに計算量が多いんですか」

--まあ60年代ですから。当時の汎用コンピュータの、能力の限界ですね。それに、計画立案はいいけれど、現実からのフィードバック・ループが弱いこと。つまり何らかのトラブルなどで計画通り現実が動かなくなったとき、リカバーがけっこう難しいのです。
 そして、製造機械の能力や労働者の人数の上限を、考慮できないこと。これを専門用語で『無限負荷計画』と呼びます。だから、実行できない計画もできてしまう。

「それじゃ、計画立案の手法として落第じゃないですか?」

--ただね、当時も今も、米国では工場を作るとき、将来の需要増を見越して、最初からかなり過剰投資気味に作ることが多いんですよ。だから、工場は生産能力が余っているのが普通でした。したがって、標準リードタイムを多少長めに設定すれば、実際には何とかなったのです。
 MRP登場以前は、その余っていた機械能力を使って、沢山の品種の部品を、大ロットでがんがん作るもんだから、あちこちに中間在庫の山ができていた。MRPは製造のタイミングを、真に必要な時からリードタイム分だけ前倒して、指示を出すわけですから、、少なくともその問題は解消されました。
 しかし、70年代に入ると、予想もつかぬ出来事が起きて、アメリカの製造業を大きく揺るがします。

「いったい何ですか?」

--’73年の、石油ショックですよ。

(この項続く)


by Tomoichi_Sato | 2018-07-23 22:56 | サプライチェーン | Comments(0)