|
「風のシカゴ」（Amazon） 駅にいる普通の駅員さんたちが、ごく普通に、仕事の必要で、英語を話している。もちろん、ネイティブの流ちょうな発音とは全然違うが、何を言っているかちゃんと聞き取れて、達意で明瞭だった。それは、英語を話すという事が、何か『特別なこと』ではなくなってきた証なのだ。 日本人にとって、英語が「特別な外国語」から「普通の言語」の一つになること。異文化との接触と交流を、普通のあたりまえの人達が、（体当たりであっても）自分で行うようになること。それこそ、2013年に亡くなった著者・中津燎子氏が長年、望んできたことではなかったか。 中津燎子氏は、傑出した英語教育家だった。わたしは中津先生（ここからは先生と書く）に長らく私淑していたが、残念ながら生前お目にかかることはできなかった。それが、不思議な偶然に導かれて、昨年5月に、先生のお墓参りをすることができた。古くからのお弟子さんで友人でもあった、西端千鶴子さんにご案内いただいたのだ。河内長野の墓地は明るく穏やかで、中津先生とご主人の眠る場所には、小さいけれどお洒落な墓標が飾られていた。
中津先生の本はほとんど読んだはずだが、唯一残っていたのが、本書「風のシカゴ ～シェリダン・ロード物語」 だった。1989年の発刊で、すでに絶版だが、幸い古書で入手できた。
本書は中津先生の、自らの米国留学体験（1960年代前半）の記憶と、その30年後に家族と再訪した印象記である。そして、アメリカ文明への静かな批評となっている。
わたしがはじめて中津燎子先生の「なんで英語やるの？」 を読んだのは高校3年生のときだが、そのショックは今でも覚えている。それまで漠然と感じていた、学校における英語教育への違和感と疑問が、ある部分は見事に解決され、またある部分はより深い疑問に変えられた本だった。
同書の最初の方に、中津燎子先生による英語の最大公約数的な4原則がのっていた。それは、 (1)英語は意思伝達のために存在し、他の言語と対等である (2)音を重視する聴覚型言語である (3)英語は腹式呼吸で発声する (4)自他を明快に分ける思考を土台にしている の4項目だ。どれも、それまで自分が、あるいは世の中が、無意識に抱いていた前提と真逆なほど違っていた。
(1)は、「英語は国際的エリートの使うカッコいい言語である」という通念と対立する。(2)は、読み書きと文法中心の入試やテストで評価される、英語教育のおかしさを再認識させられた。(3)は、わたし達の日本語のあり方（息の量も小さく口もあまり動かさない）との違いを意識させられた。おまけに、声が相手に届くかどうかを気にしないのだ。(4)の「自他の弁別」という発想は、それ自体、日本文化にはないものだった。少なくとも高校3年まで、そんな視点を考えたことはなかった。
そして、中津先生の根本には、「英語を学ぶことの中心には、異文化理解があり、それには身体的・思考的な訓練を要する」という明快な認識があった。読む・書く・聞く・話すの4技能はいわば手足であって、異文化理解という胴体がなければ意味をなさないのだ。
それにしても、なぜ英語は日本で特別な外国語になったのか？
明治期から、英語教育は外国文化摂取を目的に行われた。英語は先進文明国の言語であり、ことに戦後は日本を占領した戦勝国の言語となった。序列思考の強い日本文化では、最上位に位置づけられた外国語だった。しかも高校・大学の必修科目となり、受験英語の成績がその子の価値を左右することとなった。
おまけに、日本では伝統的に、外国語学は文献学であり、読み書きと文法中心の学習だった。中国語を「漢文」として素読し、古典の訓詁学で受け入れた伝統を忘れてはならない。このおかげで、「読み書き」（受験英語）と実用的会話能力が分離する不思議が生じても、学者先生方はなんとも思わなかったらしい。
いうまでもなく、日本の生活では、英語を必要とするシーンがほとんどない。結果として、話者が少ない。だから学校で習っても、使わないのですぐ忘れてしまう。結果として、全国の教師の需要を満たせるほど、話者がいないのである。当然、教師の側のレベルも理想からは程遠く、おかげで受験産業がビジネスの種にしやすい。
この文章を書いている今日、ちょうど、文科省が大学入学共通テストで英語の民間試験導入を延期した、という報道が舞い込んだ。当然のことに、わたしには思える。そもそも業者テスト導入策の背後には、英会話の能力が「グローバル人材」の必須の要件だ、という愚かな経済界の思い込みがあるように感じる。そこには、異文化理解の能力の低さが、日本経済が海外で競争力を失った最大の要因だという反省が、まったくない。
でも、本書に戻ろう。著者の中津先生は、旧ソ連・ウラジオストク育ちの帰国子女であった。戦中の日本社会に帰国し、非常な苦労をされた。そして戦後、占領軍の電話交換手の仕事を機会に、英語を身に着け、米国留学を志す。
ただ、最初に行ったボストンでの医療技術者の勉強には挫折する（なにせラテン語がまだ必修だった時代なのである）。そこでPlan Bとしてシカゴに移り、商業美術を勉強する。やがて知り合った日本人医師と結婚し、男女二人の子どもを得て、65年に帰国される。
中津先生は帰国後、岩手県で子供のための英語塾を始められるが、後にご主人の仕事の関係で南大阪に移られてからは、英語教師向けの教育をされた。これはとても良いことだったと思う。岩手の小学生よりも、大阪の中学校英語教師のほうが、「なぜ英語を学ぶのか」目的意識がはっきりしている。
本書はその30年後、息子のケンさんと娘のリッツさん（いずれも仮名）と一緒に、米国に向かうシーンから始まる。
はたして30年間に、アメリカは変わっただろうか？
著者がまっさきに思い出すのは、'50年代のアメリカにおける人種差別である。黄色人種である日本人だ、というだけで、下宿探しを始め、あらゆるシーンから静かに締め出しを食う。その頃のアメリカでは、黒人と日本人と白人が、同じレストランのテーブルに座って食事する事など、考えられもしなかった。そういう一行は、入り口できっぱり拒否された。
今は、それができる。では、表立った人種差別は、アメリカから無くなったのだろうか？
だが機内やアメリカ入国の手続きの中で、中津先生は、入管事務所・税関その他、有色人種の多く働く現場では、「いっさいの親切心、サービス精神、気くばりはゼロであること」を見抜く。「屈折した差別の存在するところでは、人々は他に向ける心のゆとりも思いやりもなくなり、不満だけが純粋培養されて固まっていく。」「こうも独特の押し殺した不満顔の人々を見ていると、アメリカは相変わらず『表面規則は平等』であり、『真相部分では差別』という構造が続いているのかもしれない」（P.31）
シカゴは、広大なミシガン湖に面する、風と寒さの厳しい北国の街である。中津先生はながらくシカゴの、シェリダン・ロード界隈に住んでおられた。いわゆる「魅惑の1マイル」（Magnificent Mile）などの繁華街からは、ずっと北にあたる。
この再訪の旅で、かつて家族で住んでいたアパート、子供を生んだ大学病院なども訪れる。そして、かつて歌を習い、一緒に活動指していたエラ・ジェンキンスという黒人女性音楽家とも再会する。彼らの旅のクライマックスは、シェリダン・ロードをずっと北に向かい、かつて見たシベリア風「きのこの家」を再発見するくだりだろう。それはまた、アメリカ生まれで帰国子女だった先生の二人のお子さんにとっても、ルーツ再発見であった。
アメリカはベトナム戦争に負けた。だが、その事実を意識は受け入れがたい。敗北の記憶は、無意識に回って抑圧される。ジャーナリストのシラー老人は、その危険性に気づいている人物だ。だが、明朗な表面とは違い、深く傷ついている人物でもある。そして、彼は孤独だ。それはこの国の人々の抱える、深い孤独感を象徴している。
「アメリカって社会は、何が何でも機会を狙え！ という国でしょ？」−−かつての友人レイチェルは、著者にこう語った。「それこそ髪の毛一筋のチャンスでもつかまえて生かす者が最後に勝つわけ。そんなふうに一人ひとりが自分の限界も考えず必死になっているときは、友達どころではなくなるのよ。そしてますます閉鎖的になって、しまいには心が冷凍肉みたいにカチンカチンになってしまうのよ。」「その冷凍ハートの人間は心はカチカチなのに、うわべの表情や行動はやたらに明るく輝いていてさ、目はチャンスを探してギラギラしてるんだ」（P.290-291）
そして、レイチェルいうところの「間抜けな太陽」である著者のところに、そうした冷凍ハートの人間が自然と引きつけられていく、という。「冷凍人間たちは、間抜けな太陽を探すか、麻薬に逃げるか、どちらかしかないのよ。」ここに、もう一つのアメリカの病相がある。
さて、上に述べた中津先生の英語4原則に、「英語は、他の言語と対等である」という項目がある。
この、対等とか、公正とか、権利とかいう概念は、分かりにくい。日本では、それらと「平等」とが、しばしば混同される。日本文化では、伝統的に序列思考と平等原理が強かった。その反動として、今は優勝劣敗の競争原理が全盛を誇っている。だが、アメリカ文化の文脈では、競争はフェアな環境でなされなければならない。
しかも、人の上に立つリーダーや、権力者は、公正でフェアであることが要求される。そうでないと、下の人々が信頼してついてこないからだ。えこひいきをしたり、貢献者を罰したりするリーダーに、誰がついていくだろうか？
これについて、学生アルバイトをこき使う鬼のような雇用主を、著者は思い出す。あるとき、新聞記事でもっとペイの良い仕事を探して丸をつけていたら、その鬼が見つけて「そこはやめておけ」という。あんたは知らないだろうが、そこは売春組織と関係しているからだ、というのだ。そして、「俺は、こういうことは、フェアでありたい」と言い残す。
「ソ連も日本も、ともに『フェア』という概念や発想を持っていなかったように思う。」（P.301） だが、アメリカは私に対してフェアであろうとすることを教えてくれた、と著者は書く。アメリカ社会の深い断面を活写した後、最後に、でも大事なことを教えてくれたから好きだ、という。それは中津先生が、自分もアメリカに対してフェアでありたい、と考えたからだろう。
本書は、だから、著者・中津燎子先生と家族による、アメリカとの和解の書でなのである。
＜関連エントリ＞ →「書評：『英語と運命』 中津燎子・著」 （2014-06-08） →「国際人として最低でも守るべきたった一つのルール ～ 『ありがとう』と家族に対してでも言う」 （2016-09-11） #
by Tomoichi_Sato
| 2019-11-02 20:12
| 書評
|
Comments(0)
11月と12月に、BOM/部品表に関連して、2件のセミナー講演を行います。前者はエンジニアリング・チェーンとPLMに関する話題（無料）で、後者は6月に行ったセミナーのアンコール講演（有償）です。 このところBOM関係の講演依頼が増えているのは、あらためて設計から製造への機能的な橋渡しについて、悩む企業が増えているためではないかと想像します。 製造業ではよく、「サプライチェーン」と「エンジニアリング・チェーン」が生産でクロスする、という説明がなされます。下図はわたしがときどき講演で使ってきたチャートで、横軸は左から右に向かって、物づくりの順番にサプライチェーンが描かれています。生産計画から始まって、調達→生産→出荷→販売→保守、といった流れです。これに対して縦軸は、上から下に向かって、マーケティングからはじまり、企画→製品開発→工程設計→試作→量産準備、という製品開発の流れを示します。これを「エンジニアリング・チェーン」と呼ぶわけですが、両者が交わるのが『生産』です。  そしてPLM（Product Lifecycle Management）と呼ばれるソフトウェアは、「製品の企画・設計から保守・廃棄にいたるプロセス全般を管理する」仕組みの提供を目的としています。もっとも、PLMソフトは普通、エンジニアリング・チェーンの側をサポートし、生産計画や生産・物流などはSCMソフトウェアが面倒を見ます。両者の統合の要は、部品表/BOMデータベースで、その中にE-BOM→M-BOMが整合性をとって格納されるのが理想形です。 ところが現実には、2つのチェーンの流れは、この図のようなきれいな直交形に統合しにくいのです。それは、もともとこの図が、量産型の製造業を念頭に置いて作られたからです。一方、日本の多くの企業では、もはや受注生産、とくに個別性の強い受注設計生産の形態が主流になっています。したがって、BOMのあるべき姿について、現下の状況に応じて皆が考える必要が出てきている訳です。 2つのセミナーはテーマも内容も異なりますが、この主題をめぐって皆さんと一緒に議論できればと思っています。関心ある方のご来聴をお待ちしております。 ＜記＞ (1) 「BOM/部品表とエンジニアリング・チェーンのマネジメント」 日時： 2019年11月28日(木) 13:30～14:35 テーマ： 「BOMで改善！ 中小企業の設計効率を上げる業務改革」 主催： エスツーアイ（株）＋ダッソーシステムズ（株） 会場： 〒450-0002 名古屋市中村区名駅4-7-1 ミッドランドスクエア 5F ミッドランドホール会議室A セミナー詳細： 下記をご参照ください（無料、定員30名） (2) 「BOM／部品表の基礎と効果的な活用ノウハウ ～演習付～」 日時： 2019年12月17日(火) 10:30～17:30 主催： 日本テクノセンター 会場： 〒163-0722 東京都新宿区西新宿二丁目7番1号 小田急第一生命ビル22F セミナー詳細： 下記をご参照ください（有償です） 以上、よろしくお願いします。 （佐藤知一） #
by Tomoichi_Sato
| 2019-10-28 22:36
| サプライチェーン
|
Comments(0)
マネジメント・テクノロジーは、目に見えにくい領域における技術である。わたし達の文化は、目に見えるもの（五感で感じられるもの）に対しては細部にまで徹底してこだわるが、見えない物事や抽象的概念には、いたって無頓着、という傾向が強い。 たとえばカレー屋さんの場合、料理の味と、その材料やレシピには研究を怠らない。しかし客の注文をどうとってどういう順序でデリバリーするか、何をストックし作る量をどう予測するか、といった店を運営する過程や仕組みには、なりゆきで応対する。これが多くの店のあり方だろう。 カレーの料理法は「固有技術」で，店の運営の仕組みは「管理技術」（マネジメント・テクノロジー）に属する。もちろん固有技術（味）は、いわばビジネスのベースで、これが不味ければ商売は成り立たない。しかし管理技術（運営の仕組み）ができていないと、商機に乗って展開することも、急な環境変動にうまく応対することもできず、気づかぬうちに非効率と機会損失を出してしまう。ここが弱いと、皆が必死に働いているのに、なぜか儲からなくなるのだ。 わたし達の社会は、このマネジメント・テクノロジーの存在と、その重要性を見過ごしてきたことで、長い不況を抜け出せずに来たのではないか。それが本サイトの問題意識だ。 そして、マネジメント・テクノロジーは、隣接する3つの固有技術領域、すなわちIT（Information Technology）、OT（Operational Technology）、ET（Engineering Technology）と少しずつ重なり合いながら、その方向性を広げてきた。では、このIT、OT、ETとは、それぞれどのような技術なのか。  ITについては、すでにネットの内外に、数多くの情報があるため、いまさらここでは解説不要だろうと思う。コンピュータのハードウェア設計から始まり、OS、通信ネットワーク、ミドルウェア、データベース、そしてその上で活躍する応用ソフトウェア群（とくに業務系システム）の設計・実装・運用技術までが、ここに含まれる。 本サイトでも、随分前だが、『ITって、何？』という連載をのせた。長い記事になっているが、あそこで書いたコアのメセージは、
である。データとは定型化された符号の並びで、他方、情報とは人間に意味を与える（不定形な）ものだ。だから情報を機械に与えて蓄積・処理できるようにするには、定型化してデータにすることが必要だ。データは上手に組織化し提示しないと、人間に意味をもたらさない。この双方向をうまく回すのが、IT=情報技術である。 固有技術としてのITの基礎を支える科学は、コンピュータ・サイエンス（計算機科学）である。それは数学・論理学から電子工学さらには言語学まで、様々な科学領域にまたがって存在している。だから、大学のコンピュータ・サイエンス学科を卒業して、専門職としてのITエンジニアになる、というのが米国流の普通のキャリアパスである。日本があまりそうなっておらず、大学にも「計算機科学科」がめったに存在しないのはなぜか、わたしはよく分からないが。 さて、これに対して、OT（Operational Technology）とは何か？ OTについては最近、IoT技術に関連して注目されるようになり、世の中にもいろいろな解説が流布している。ネットでちょっと調べただけでも、以下のようなものが出てくる。
こう見ると、社会インフラ向けと言ったり産業機械向けと言ったり、定義には幅があっていろいろだ。最後の米国ガートナー社の定義は2011年のもので、中では一番古い。ちなみに現在はこうかいてある：
この定義は英語版WikipediaのOperational Technologyの記事にも冒頭で引用されている（日本語版ウィキペディアの記事は、現時点ではその部分的抄訳でしかない）。 ただ、このガートナー社の定義は、わたしの目から見ると、少しだけ制御系や通信系の仕組みに偏りすぎているように感じられる（ガートナーはIT系コンサルティング会社だから、主な顧客はITエンジニアである）。 たとえば、NC（数値制御）のマシンを対象に入れるのだとしたら、その加工プログラムは、明らかにOTに入るはずであろう。そうなると、そのための切削条件決定や、加工ツール・バイト（刃先）の選定も、OTに含まれなければ、おかしい。搬送やチャッキングや検査の仕組みだって、そうだ。こうした機械工学系の加工技術は、現場の熟練者たちの手中にあって、ITコンサル会社には見えにくいのだろうが。 いいかえると、OTとは加工技術や機械制御といった、直接ものづくりに関わる固有技術だと、広く捉えるべきであろう。もちろんNC装置の加工プログラムや、SCADA, PLC、DCS、MES（とくにLower MES）など制御系も、この領域に入る。 日本のIT分野は世界の最先端に比べて遅れつつある、という認識が最近は広まっているが、それに比して、OTの分野に関しては、まだかなり世界的な強みを維持している。この点は強調しておいていいと思う。NC工作機械やマシジングセンタ、ロボット、物流搬送系設備、制御システムなど、世界トップレベルの企業がごろごろいるのが、この分野だ。 最後に、図の下の方に配置したET（Engineering Technology）に触れておこう。ETとは、製品設計や工程設計・レイアウト設計などに関わる固有技術領域である。ここには、機械・電気・制御・建築・空調・化学プロセスといった、いわゆる工学系技術が活躍する。そしてCAD/PLM/BIMなども、この分野のためのツールだ。 もっとも、IT・OTに比べて、ETという用語はあまり広く用いられていない。調べると、たとえば米ARC社は次のように使っているが、これが唯一の用法という訳でもない。
じつはETという用語が広まらないのには、別に特殊な理由がある。米国の大学教育コースの中に、”Engineering Technology”という学科が、”Engineering”とは別に設けられているところがあるのだ。たとえば英語版WikipediaでEngineering Technologyをひくと、Engineering Technologistという項目に自動転送されて、こういう説明が出てくる。
設計よりも実装に近い仕事を受け持つ技術職。日本の高等教育で言えば、高専のカリキュラムに近いのかもしれない。ET（Engineering Technology）というと、米国ではこちらのことを連想するらしいのだ。ともあれ、他に適切な言葉も見つからないため、上記の図ではETと表記しておいた。 そしてManagement Technologyは、OT＋IT＋ETの三本柱の上に乗っており、一部は重なっているのである。重なった部分は、それぞれ OM（Operations Management） EM（Engineering Management） IM（Information Management） と呼ぶべき領域である。 そして、これら3つのマネジメント・テクノロジーは、日本ではいずれもほとんど教えられておらず、知られてもいない。理工系はもちろんのこと、いわゆる文系の経営学でも、またビジネススクールでも、ほとんど等閑視されている。米国にはちゃんと、OMやEMを教えるコースを持つ大学・大学院があるのに。 なお、ITと重なる領域を、IM（Information Management）と表記したが、この言葉はプラント・エンジニアリング業界では、ある特殊な狭い領域の業務を指すことがある。本当はより一般的に、DM（Data management）とか、KM（Knowledge Management）などと併用すべき用語に思われる。 そして、図中には、他にもSCM（Supply Chain Management）やPM（Project Management）やMM（Material Managemen）といった、やはり物づくりに関連するマネジメント・テクノロジーの領域を入れておいた（ただし図中の位置は場所的に散らしているだけで、必ずしもPMがIMとEMの中間にあるという意味ではない）。 ちなみに、上の説明ではOTに属するPLC/DCS/SCADAや、ETに属するCAD/PLMなどを、ITとは別のものとした。だが、これらはみんなコンピュータのハードとソフトで実現するものだから、ITの一部ではないか、という議論もあるだろう。 しかし現実を見ると、業務系システムと、制御系・組込系システムと、科学計算系システムでは、作る人達も売る企業も、業界的に分かれている。技術の要素も相当に違っており、昨日まで製造原価報告書を設計していた人が、今日から偏微分方程式の収束計算を設計できるかというと、まあ無理であろう（逆も真なりだ）。繰り返すが、図中の「IT」は、主に業務システム系の領域を主に意識している。ITとOTの融合が語られはするし、そうした動きを否定するつもりはないが、それは、建築と機械の融合、くらい大変な話であることは理解しておいたほうがいい。 ともあれ、これがマネジメント・テクノロジーの領域の見取り図である。固有技術の領域では、日本の技術者たちはそれなりに優秀だ。みな真面目だし、ほぼ例外なくハード・ワーカーでもある。だが、縦割り組織と分業病におかされているため、固有技術を束ねて、全体をオーケストレーションする部分が弱い。オーケストレーションの技術、それがマネジメント・テクノロジーである。 もちろん、マネジメント・テクノロジーを学ぶとしても、この図の全部に通暁する必要はないし、そんなスーパーマンもいないと思う。ただ、わたし達は、自分が何を知っておらず、どこを探しに行けば先人の知恵を学べそうか、その方角を知るために、こうした地図を必要としているのである。 ＜関連エントリ＞ →「マネジメント・テクノロジーの領域を知ろう」（2019-10-05） https://brevis.exblog.jp/28610522/ →「マネジメント・テクノロジーの技術地図を見渡す」（2019-10-13） https://brevis.exblog.jp/28623704/ →『ITって、何？』https://brevis.exblog.jp/i12/ #
by Tomoichi_Sato
| 2019-10-20 17:36
| ビジネス
|
Comments(1)
前回の記事では、技術（Technology）とは2種類あり、固有技術と管理技術に分類できる、と書いた。わたし達が大学の工学部などで習う技術のほとんどは、固有技術である。これは対象分野に固有の科学法則に基づくテクノロジーだ。これに対し、管理技術（Management Technology）とは、仕事の仕組みそれ自体に関する技術で、たとえば、プロジェクト・マネジメントの分野では、CPM（Critical Path Method）やEVMS（Earned Value Management System）などがこれに相当する。 わたしは大学でプロジェクト・マネジメントを教える際に、いつも「この講義で教える内容は、ほぼすべて社会人になってから学んだことで、わたし自身は大学ではほとんど教わった記憶がありません。だけれど、それでは非効率なので、こうやって大学に来て皆さんに講義をしているのです」と説明している。 実際のところをいうと、大学の学部生レベルでは、プロジェクト・マネジメントの講義をしても、あまり響かない。人と一緒に仕事をして苦労した経験が乏しいからだ。これが大学院の修士課程くらいになると、一度は「卒論」というチャレンジを経験した後なので、少しは話を聞く態度に身が入る。そしてもちろん、一番皆がちゃんと学ぶ姿勢になるのは、社会人大学院生や、企業相手の講義のときだ。 まあ、だからといって大学での講義が全くムダだとは、思っていない。アーンド・バリューだのクリティカル・パスといった概念の意味は忘れても、いざ自分が卒業して、仕事で問題に直面したときに、「そういえば、昔なんだかこれに関連する話を聞いたよな」と思い出せれば、あとは自分で探して調べることができる。 自分が本当にニーズを感じているときほど、良い学びの機会はない。このとき、頭の中に、たとえぼんやりとでも「技術の地図」のイメージが残っていれば、（ああ、あっちの方に探しに行けばいいんだな）と、希望を持つことができる。技術者という人種は、「技術的に可能だ」という希望を持てることが、いちばん大切だからだ。そして優秀な人なら、自分で調べて勉強していく。 しかし、わたし達の社会では、管理技術をほとんど大学で教えないため、そうした技術の地図を知らないまま、世の中に出てしまう。つまり、そもそも「仕事の仕組み」には技術があること、人・モノ・情報などの配置と流し方に、ちゃんと先人たちの叡智と工夫があることを、知らないのだ。その結果、各人がゼロから車輪を再発明することになる。いや、それどころか、「リーダーシップ」「気合と根性」でなんとか乗り切れ、という話がまかり通る。 これに関して、わたしがよく使うたとえは、オーケストラの指揮者である。指揮者という仕事は、ちょっと見たところ、リズムに合わせて棒を振っているだけで、誰でも（楽譜さえ読めれば）できそうに思える。自分では笛を吹くわけでもなければ弦をこするわけでもなく、何の音も出さない。そもそも、管楽器や弦楽器の演奏技術も持っているまい。ただ、オケに指揮棒で指示を出すだけである。 では、指揮にはとくに技術はないのか。指揮者は、どのように育成するのか？ 日本の組織では、幹部やリーダーの地位に登っていく人を、「ジェネラリスト」として育てるところが多い。その典型は官庁で、「キャリア職種」と呼ばれるエリート候補生たちは、２〜３年ごとに部署を変わっていく。しかも前職とろくに引き継ぎもしないことが多いので、役人と付き合う民間人たちは、相手が変わるたびに一から説明し直しになる、という。 技術者の場合、専門的な仕事を覚えて一人前のプロとして通用するには、ふつう10年くらいかかる。それがスペシャリストというものだし、医師や弁護士だってそうだ。それなのにキャリアと呼ばれる人たちは、わずか２〜３年の間で、その領域の仕事を概略理解し、何らかの成果を上げて次のポジションに進んでいく。だから、こうした制度は、彼らエリート層の優秀さの証左なのだ、という説明も聞いたことがある。優秀かどうかはともかく、スペシャリストを束ねて指揮するのは、ジェネラリストだ、という思想がそこにある。 こういう話を聞くたびに、じゃあ日本社会では、オーケストラの指揮者もジェネラリストとして育てることになりそうだな、と思う。指揮者のキャリアパスは、まずビオラで3年、次にフルートで2年、さらに打楽器とトランペットなどを経験し、最後に第一ヴァイオリンでコンサートマスターを5年ほど務めた後、めでたく指揮者の地位になる、と。 こんなバカなやり方で指揮者を育てる音楽界は、世界中どこにもない。指揮者は、専門家であり、指揮は専門技術だ。音大には指揮科があり、そこで指揮の理論や技術を学ぶ。それから指揮者の見習いとして、先輩について指揮法の実際的なスキルを学んでいく。たしかに、ときにはピアニスト出身の指揮者やヴァイオリニスト出身の指揮者もいる。だが、彼らだって、ちゃんと指揮法を学んで棒を振っているのだ。ただやみくもに棒を振ればついてくるほど、オーケストラという集団は甘くない。 人が集団で仕事をするとき、とくにその専門分野が多岐にわたり、規模が大きくなればなるほど、専門的なマネジメントの技術が必要になる。そして、そこには理論もあるし、学ぶことも、伝えることも可能だ。 では、そうしたマネジメント・テクノロジーを学ぶとしたら、それはどのような範囲をカバーすべきか。いいかえると、「技術の地図」は全体として、どのようになっているのか。 もちろん、それはかなり広い領域にまたがることになる。プロジェクト・マネジメント（PM）はその一部分にすぎないが、それだけでもPMBOK GuideやP2Mなど、分厚い教科書的な本がいくつも存在する。 そこで、ここでは一般的な製造業における物づくり分野について、その全貌を考えよう。また、マネジメント・テクノロジーを考える際には、隣接する固有技術との関係で理解したほうが分かりやすい。わたしの考える、物づくりに関わるマネジメント・テクノロジーの領域と、隣接する固有技術との関係マップを示しておく。  隣接する3つの固有技術とは、以下の3つだ： IT（Information Technology） OT（Operational Technology） ET（Engineering Technology） それぞれが具体的に、どのような種類の技術領域を表すかについては、長くなりそうなので、次回書くことにしよう。 （この項続く） ＜関連エントリ＞ →「マネジメント・テクノロジーの領域を知ろう」（2019-10-05） https://brevis.exblog.jp/28610522/ →「オーケストラの指揮者かジャズ・バンドのリーダーか － プロジェクト・マネジメントの４つの類型を知る」（2014-02-02） https://brevis.exblog.jp/21641066/ #
by Tomoichi_Sato
| 2019-10-13 15:32
| ビジネス
|
Comments(1)
本サイトの主要なテーマは、（知らなかった人もいるかもしれないが）『マネジメント・テクノロジー』である。マネジメントと言う仕事には技術があって、学ぶこともできるし、蓄積したり磨いたり、人に伝えることもできる。決して気合とか根性とか、生まれつきのセンスとかだけで能力の決まる仕事ではない。そういうことを多くの人と共有したくて、ずっとこのサイトを運営してきた。 そもそもTechnology（技術）には2種類ある。固有技術と管理技術（マネジメント・テクノロジー）だ。固有技術とは、対象固有の科学法則に縛られる領域におけるTechnologyである。たとえば、機械設計、材料開発、システム設計、といった技術がそれに当たる。ちなみに、わたし自身の大学の専門は化学工学（Chemical Engineering）だった。これは化学プラントの設計に関わる工学だが、やはり固有技術である。 これに対して、管理技術とは、仕事の仕組みそれ自体に対して適用すべきTechnologyをいう。「仕事の仕組み」では分かりにくければ、人・モノ・情報などの配置と流し方、と言い換えても良い。たとえば、プロジェクト・マネジメントの分野では、CPM（Critical Path Method）やWBS（Work Breakdown Structure）、生産マネジメントの分野なら、在庫理論とか生産スケジューリングといった技術だ。 こうした管理技術（Management Technology）には業種・分野固有の部分がない。製品開発プロジェクトだろうが橋梁建設プロジェクトだろうが、CPMは当てはまるし、在庫品がダイヤモンドでもトイレットペーパーでも、在庫理論は使える。このため、マネジメント・テクノロジーは業種分野を超えて、汎用的である。だから、まったく畑違いの分野の知恵も、学んでうまく応用すれば、自分の仕事を楽にするために使える。 ところが残念なことに、日本の大学教育では、この『管理技術』の教育・研究を、伝統的に軽視してきた。その1番の証拠は、東大と京大に、学部レベルで経営工学や管理工学の学科が存在しないことである。この2つの大学は、日本の文科省の高等教育政策を映し出す鏡のようなものだ。つまり国の側にも、管理技術という意識が欠けているのだ。 ちなみにかなり以前から、慶応には管理工学科が、早稲田には経営システム工学科があり、東工大にも経営工学科があった。だが、肝心の東大と京大には、ずっと存在しなかった。さすがに、今世紀に入ってからようやく、大学院レベルで、東大に技術経営戦略学専攻が、京大に経営管理専攻が設置された。 だが学部レベルでは、相変わらず存在しない。だからこの二つのエリート大学を卒業してくる人たちは、基本的に、「仕事の仕組みにはテクノロジーがある」ということを理解せぬまま、社会に出て働くわけだ。 なぜ、国の側に管理技術＝「マネジメント・テクノロジー」への認識が欠けているのか、わたし自身はよく知らない。ただ、もしかすると、わたし達の国の上の方の人たちは、「管理とは法学部出身者の仕事である」、と考えているのかもしれない。そう疑わせる兆候は多分にある。そうでなければ、なぜこの2つの大学の法学部出の人たちばかりが、中央官庁や政界財界のトップの座をあれほど席巻しているのか。 だが、話を元に戻そう。わたし達の社会では、残念ながら、「マネジメントにも技術がある」という概念が希薄である。だから、マネジメントの上手下手は、まったく属人的なものだ、という思想が強い。その結果、マネージャーの地位は、学歴・年功序列・出身等により選ばれることが多い。マネジメントは「地位に付随する権力・権能」 であって、前もって研修・訓練が必要な技術とは考えられていないのである。 なおここでもう一つ注意しておきたいことがある。それは、『経営』という言葉とマネジメントとの違いだ。本サイトは、「ビジネス・経営」のカテゴリーに分類されている。他に適切なカテゴリーがないから、そうしているだけだが、あまり本意では無い。なぜなら、このサイトでは、ほとんど経営について語ったことがないからだ。わたし自身、経営者ではないし、経営の仕事もしたことがない。 普通、日本語で経営と言うと、会社レベルの組織をまとめて運営する仕事を指す。しかし、私がここでマネジメント・テクノロジーと呼ぶ技術は、もう少し中間層のレベル、言い換えると経営者層と現場をつなぐレベルの技術である。クリティカルパス法だとか、在庫理論だとかいった技術知識は、会社経営のレベルではあまり必要がない（無論、知っているに越した事はないが）。 少し具体的な例で考えてみよう。今、ある所にカレー屋さんが開業した。ご主人はもともとエンジニアだったが、長引く不況と、先の見えない業界にうんざりして、心機一転、脱サラを決意したのだ。昔からカレーが得意料理で、親戚知人に披露すると結構評判が良かったので、自分で店を開こうと思いたったわけだ。 愛想の良い奥さんと二人三脚で、幸い、店は順調に滑り出した。ご主人が料理を作り、奥さんが客の応対をする。1年経つと、ピーク時には店の前に行列が並ぶほどになった。今のスペースは手狭なので、近くに3倍位の広さを持つ店舗の空き家を見つけ、そこに移転することにした。そうなると夫婦2人では手が足りない。厨房とフロアの手伝いに、2人ずつ人を入れた。 ご主人はこれに加えて、持ち帰りのカレー弁当も売ることにした。長年のオフィス勤めで、昼食に皆が苦労していることを知っているからだ。オフィス街に小さな机を並べ、昼の間だけそこでお弁当を見ることにした。当然そこにも人が必要だ。 だが、こうして店の業容を広げていくうちに、少しずつ問題が起きてきた。例えば、お弁当の仕込みの数をどう決めるべきか。作り過ぎれば売れ残るし、数を絞れば利益が出ない。それに、仕込んだカレーだって、賞味期限がある。3日も4日も前に煮込んだカレーをお客様に出すわけにはいかない。 店を広げた際に、カレーのメニューの種類を増やしたことも問題だった。厨房の中で、洗い場と、調理台と、冷蔵庫との導線が錯綜して、3人の人がぶつかりやすくなった。しかもメニューの数を増やしたために、フロアからの注文の聞き取りミスも増えてしまった。注文してから料理を出すまでの時間が長くなったとなじみの客にクレームされたこともある。 おまけに甚だ厄介な、今回の消費税対応。朝から晩まで寝る間も惜しんで忙しく働いているのに、利益は上がらない上に、客足も少しずつ鈍ってきている。カレーの味自体は変わっていない。むしろ腕は上がっている自信がある。だが商売の利益につながらないのだ。ご主人は深夜、自分の席で、ため息をつくことが多くなった。 これが典型的な「仕事の仕組み」の問題だ。今のご主人に必要なのは、カレー作りの品質向上ではない（それは固有技術に属する）。大事なのは、人と物と情報の配置・流し方の工夫である。つまりマネジメント・テクノロジーが足りないのだ。 夫婦2人で小さな店をやっているときには、それはほとんど必要なかった。だが品種を増やし、人を増やし、売り上げと生産量を増やしたときに、次第に目に見えない非効率が生まれてきたのだ。適切な厨房のレイアウト、適切な在庫量の設定と発注、需要の読みと臨機応変な対応、店舗から弁当売り場への搬送、注文と会計のシステムの導入・・こうしたことが必要になるのだ。だがそれを実現するテクノロジーを、どこで学べばいいのか?  これと同様の問題が、おそらく最初は東京オリンピックの翌年の「昭和40年不況」のときに、多くの中堅中小企業で噴出した。そして、より大規模な形では、高度成長期を終えて、消費者ニーズの多様化と輸出拡大に直面した80年代以降に、日本企業を襲ったのだった。 ただ残念ながら、マネジメント・テクノロジーは、目に見えない領域に属している。そして、目に見える物の品質やディテールには大変こだわるが、目に見えない事には至って無頓着な傾向を、わたし達の文化は持っている。加えて、国家レベルでの認識不足。こうして、バブル崩壊以降の90年代から、長らく不況を出せずにきたのだ。 わたしのこの、ささやかなサイトが、国家レベルの問題を解決できると夢想しているわけではない。ただ、たまたまここを訪れた方のうち、たとえわずか数人でも、問題解決のヒントを提供できればいいと思っている。ネットの世界では、マネジメント・テクノロジーの情報源は、あまりに少ない。話題のほとんどは、固有技術か、さもなくば経営論に行ってしまう。それでは、問題に悩むカレー屋の店主の助けにはならないのだ。 それと同時に、わたし達は、マネジメント・テクノロジーについて、フェース・ツー・フェースで情報交換し、議論する場を必要としているように思う。ネットでの匿名による意見交換は、限界がある。工場作りに関しては、互いに勉強でき議論できる場を、（財）エンジニアリング協会で、立ち上げているところだ。そちらもいずれ近いうちに、より広くアナウンスできるようにしたいと考えている。そうやって、かつての東京オリンピック後と同じ状況に、日本の製造業が今度は陥らないよう、今から準備しようと思っているのである。 ＜関連エントリ＞ →「マネジメントのテクニックと技術論について」 https://brevis.exblog.jp/22951856/ （2015-04-22） #
by Tomoichi_Sato
| 2019-10-05 20:24
| ビジネス
|
Comments(2)
中学校の修学旅行は、京都・奈良だった。清水寺では、その舞台の高さに驚き、「清水の舞台から飛び降りる」の意味を改めて知った。ところで清水寺の参道には、旅人が喉をうるおす3つの湧水の滝口があった。引率のガイドさんによると、3種類の水はそれぞれ、飲むと「恋愛」「長寿」「賢さ」の願いを成就できるのだと言う。わたし達は喜んで、3つの口からそれぞれ水を飲んで、参道を登った。 ところが帰り道、ガイドさんが思いもかけぬことを言い始めた。「あら私、大切なこと言い忘れたかしら。お水を飲むなら2種類までなの。欲張って3種類を全部飲むと、効き目がなくなっちゃうのよ。」 これを聞いた私たちは、そんな大切なことなら、なぜはじめに言ってくれなかったんだ、と、いたく憤慨した。 もっともそれを聞いて、中学生のわたしは思った。恋愛と長寿と賢さと、どれが2つを選ぶとしたら、どれになるだろうか？ 難しい問いだ。それはある意味で、どれか一つを犠牲にしなくてはならないことを、意味している。頭が良くて女の子にモテても、短命ではなんにもならない。かといって健康でハンサムでも、頭が悪くては人生台無しだ。じゃぁ頭が良くて健康でも、異性が誰も寄り付かない人生に、どんな意味があるだろう？ このエピソードを久しぶりに思い出したのは、最近ある方から、アメリカにおけるオペレーションズ・マネジメント（OM）や生産管理の教育の充実ぶりについて、聞いたときだった。日本では、生産管理を専門的に勉強する大学院レベルのコースはほとんどないし、実務家のための勉強の機会も限られている。しかし米国では、ジョージア工科大学を始め、この種の研究と教育のメッカと言うべき大学が複数存在するし、米国生産在庫管理協会（APICS）という、実務家のための大きな組織もある。アメリカの製造業はもう廃れた、と思い込んでいる人が多いが、こうした科目を学ぶならば、日本よりもアメリカの方がずっと進んでいるのだ。 その人は、アメリカでの生産管理教育のメッセージをわかりやすく伝える、1枚のチラシを見たと言う。それは宅配ピザのチラシを、模している。 「あなたのお好みのピザを届けます。 ただし、以下の3つのオプションから、2つまでを選びください」 そしてチェックボックス付きで、Q:品質、C:コスト、D:納期、の3つのオプションが並んでいる。 安いピザを早く持ってきてもらいたかったら、品質（おいしさ）は多少犠牲になる。おいしいピザを早く持ってきてもらいたかったら、それなりの値段を払わなければならない。そして、おいしいピザを安く届けてもらいたかったら、（そのためには同じ種類のピザをある程度のロット数量まとめて焼く必要があるのだから）納期が遅くなるのは、覚悟しなければならない。 製造業においては、顧客好みにカスタマイズされた商品を、QCD全て満たした形で生産するのは、ほぼ不可能である。なぜならばこの3つの尺度の間には、あちらを立てればこちらが立たず、1つを完璧にしようとすると、他の2つのいずれかが犠牲になる、『トレードオフ』の関係が成り立つからだ。それは、生産システムというものが持つ、基本的な性質である。このチラシは、それをごくわかりやすい簡潔な形で、教えている。 いったい全体最適とは、何だろうか？ 品質・コスト・納期の、3つの尺度を全て最大化することだとしたら、それは本当に可能なのだろうか？ 全体最適と言う言葉は、しばしば縦割り組織で、いろいろな行動がサイロ化されているとき、「それは局所最適だ」という批判とともに、用いられる。つまり局所最適の反対概念として、『全体最適』と言う言葉が使われる。 しかし、少しでも最適化理論やオペレーションズ・リサーチ（OR）をかじったことがある人は、最適と言う言葉を、もう少し正確に、ないし慎重に使う。それは何らかの評価関数（尺度）を、最大化することを意味する。では製造業における評価関数とは、何なのだろうか。評価尺度が複数あるときは、どうしたら「全体最適」が達成できるのだろうか？ 別の言い方をしてみよう。今、工場で生産に問題が生じているとする。そこで工場長は、品質の徹底的に向上するため品質管理マネージャーを任命し、コスト削減のためにコスト管理マネージャーを任命。さらに納期短縮のために、スケジュール管理マネージャーを置いた。この3人が、それぞれ自分の持ち場で最大限努力すれば、QCDの全てが最大化されるだろうか？ この3人はそれぞれ、他の2人と相談せずに、独立に活躍できるのだろうか。 これは制度設計の問いである。つまり一種のデザイン問題なのだ。そこでエンジニアにわかりやすいように、製品設計の例に置き換えて考えてみよう。 あなたの会社は今、これから新しい電気自動車を開発しようとしている。あなたはそのプロジェクトの、主任技師に選ばれた。あなたに与えられたミッションは、「世界最高の電気自動車を設計すること」である。 世界最高の電気自動車とは、どういう意味か。それは、どんな尺度を持ってきても、他のライバルに勝っていると言うことである。では、電気自動車を評価する性能尺度には、一体どのようなものがあるか。 自動車はまず第一に、移動手段だ。A地点からB地点に、乗っている人が移動することができる。これが一番主要な機能である。見るからに精悍でかっこいいが、1kmも走れない電気自動車に、金を出す人はいるまい。である以上、最大航続距離が、第一の性能尺度になりそうだ。 それと並んで、最高速度も大事な性能だ。最高時速20キロで、高速道路にも乗れないような自動車では、役に立つまい。 加速性能は？ それも大事な尺度だ。では、回転性能についてはどうか。思う方向に向かってキビキビと進路を変えられることも、車にとって大事な性能だ。加速と逆に、減速も重要である。回生制動であれメカニカル・ブレーキであれ、必要な時にきちんと止まれることも、とても大切だ。そして移動手段である以上、かりにセダンのタイプとしても、可載重量も使い手は気になるだろう。 それだけで良いだろうか？ いや、車の走行には、安定性や安全性も求められる。例えば高速走行時の安定性。路面のゴツゴツした凹凸に、いちいち進路がぶれるのではたまったものではない。そして衝突時の安全性。これも非常に大切だ。そして、製品の寿命が長く、壊れにくいことも、ユーザの視点からは、大きなポイントになる。それに隣接して、自動車の場合、スペース的な余裕、つまり居住性も考慮がいる。 こうしてみると、移動という基本的な機能の性能のほかに、まだ様々な評価尺度があることがわかる。ITエンジニアだったら、航続距離や最高速度を「機能要求」と呼び、回転性能や高速安定性や衝突安全性等は、「非機能要求」と呼びたくなるかもしれない。 それで、これだけで十分だろうか？ いや、まだ大切なことを忘れていた。それは効率性である。「コスト・パフォーマンス」と言い換えてもいいかもしれない。例えば、移動性能に対しては、どれだけ燃費がかかるかが、効率性の尺度になる。これも自動車を選ぶ際には、とても重要な物差しであろう。 また製品の寿命に対しては、保守維持費の安さも大事だ。そして何よりも、製造コスト。販売価格は、製造コストに依存する。自動車全体のコスト・パフォーマンスとは、何よりその販売価格で測られるものだ。  さて、あなたの手元には、すでに1ダースもの評価尺度が集まった。図を見てほしい。ここでは、12個の評価尺度を、あえて抽象化した表現で表してある。これらすべてを、どんなライバルも追いつけないほど、最大化（ものによっては最小化）することが、主任技術者たるあなたに与えられた使命＝ミッションである。 このミッションは、本当に実現可能なのだろうか。CAD画面に向かって設計図を描き始める前に、あなたは落ち着いて考えてみるべきだろう。 さて、先ほどの図をじっくり眺めていくうちに、あなたは、これらの尺度が大きく、4つに分類できるのではないかと気がついた。 まず、図の上辺にある、主性能Effectiveness (最高速度)と、使用価値Usefulness(航続距離)。これらはシステムとしての電気自動車の有用性に関わっている。つまり、ユーザの主たる期待への合致である。 円の左側に位置する、俊敏性Agility(加速性能)、柔軟性Flexibility(回転半径)、許容性Capacity(可載重量)などは、広い意味での御しやすさ＝制御性 Controlabilityに属している。逆に右側にある、安定性Stability(高速安定)、頑健性Robustness(衝突剛性)、居住性Comfortability(スペース余裕)、耐久性Durability(機械寿命)などは、広い意味での持続性 Sustainabilityの範疇と考えられる。 最後に、円の下部に位置する、製造コストInitial cost、保守コストMaintenance costは燃費と共に、コスト・パフォーマンスの分母側＝負荷尺度に相当する。分子に相当するのが他の3カテゴリー、つまり有用性・制御性・持続性である。だから分母を小さく、3つの分子を大きくしていけば良い。 だが、個別に考え始めてみると、あなたは次第に思考のループにとらわれているような気がしてきた。例えば頑健性を高めるために、剛性の高い車体を使うとする。すると車の重量が重くなって、俊敏性や最高速度が損なわれる。重くしないためには、軽くて強い特殊素材が必要だ。そうすると製造コストが高くなってしまう。 回転性能を高めることと、高速安定性を両立させることも、決して容易ではない。安定性を素材の重量や形状など、メカニカルな方法で確保しにくい場合、何らかの制御システムで担保するしかない。かつ、安全性を考えると、制御システムは冗長化・多重化が必要だ。そうなると仕組みが複雑になって、保守コストが上がるだろう。 こうして、あちらを立てるとこちらが立たず、トレードオフの網の目にトラップされたような気になってくる。 それも当然なのだ。よく考えてみて欲しい。制御しやすさ＝「制御性」とは、一体何か。それは、使い手の意図した変化への追随性である。他方、持続性とは何か。それは使い手の意図せざる変化への耐性である。片方は変化に追随し、片方は変化にあらがう。その境目は、ユーザの意図にある。だが、電気自動車と言う機械システムの側から見て、どれがユーザの意図で、どれが意図せざるものなのか、判別できるだろうか？  ハンドルやアクセルやブレーキ、フロントパネルなど、ユーザインターフェースからの入力が、意図した変化であって、それ以外の外界からの入力が、意図せざる入力である。そう考える方法もあるかもしれない。 だがユーザは人間なのだ。そして人間だから、思わぬ行動をとることがあり、間違えることさえある。くしゃみをして握ったハンドルがブレたら、それは意図した入力なのだろうか。車庫入れでブレーキを踏むべき時にアクセルを踏んだら、それは意図した行動なのか。 電気自動車は、機械・電気・制御が統合されたメカニカルなシステムである。だが、それを設計するときには、電気自動車＋ユーザ（人間）という、複雑な系を対象として考えなければいけない。 法政大学の西岡教授は以前、機械学会の報告の中で、「自動車や携帯電話など、人がその外側にいるシステムを第一種のシステムと呼び、人がシステムの内部にいて、その構成要素となっているものを第二種のシステムと呼ぶことにしましょう。」と提案された。これはとても良い分類だと思う。 しかし、わたし達が何らかの道具を設計する場合、必ず、その道具と、使う人間との組み合わせを考慮する必要がある。つまり設計においては、常に第二種のシステムが相手となるのだ。 そして第二種のシステムでは、意図した変化への追随性と、意図せざる変化への耐性は、常にトレードオフの関係になる。言い換えるならば、すべての評価尺度を同時に最適化することができないのである。 もちろん実際には、相反する2つを両立する工夫も、しばしば可能である。例えば車のハンドルのブレを例にとると、周知の通り、ハンドルにはわずかな遊びがある。これによって、手元が多少増えても、車の方向が急に大きく変化したりしないようにできている。 しかしこれは部分的な問題解決であって、第二種のシステムに内在する本質的なトレードオフが全部解消できるわけではない。 では、どうしたら良いのか。答えははっきりしている。清水寺の前に立った中学生のように、重要な尺度と、そうでない尺度を選り分けるのだ。どういうときには、誰とどの尺度が重要になるのか。その際、どれを犠牲にせざるをえないのか。上に述べたのは電気自動車の例だが、これが自社工場という生産システムだったら、どういう評価尺度群になるか、一度考えて見てほしい。 このような判断基準の体系を、「設計思想」と呼ぶ。何かをデザインする際には、それが電気自動車であれ生産システムであれ、必ず設計思想が必要である。できればそれは、明文化されていることが望ましい。 設計思想のはっきりした製品には、たいてい明確な個性がある。それはいわば、作り手の価値観の表明だからである。 もちろん価値観は多様だから、どうしても製品への好き嫌いが生じるだろう。嫌われるのがいやなら、あらゆる物差しをまんべんなく適度に満たした、八方美人的な製品を作ることになる。私たちはそうした、無個性な工業製品に囲まれて暮らしている。無思想な設計に囲まれて、と言い直しても良い。 それもこれもわたし達が、システムに内在するトレードオフを理解せずに生きているからなのだ。そしてあらゆる尺度を満たす、全体最適を無自覚に求めすぎる。恋愛と長寿と賢さを同時に求めた中学生たちのように。それは人間の欲深い業であると、お寺の僧侶たちなら言うかもしれない。 だが、わたしなら別の言い方をする。それはシステムというものへの、基本的な無自覚から来るのである。 ＜関連エントリ＞ →「生産システム、そのパラダイム・シフト」 （2018-04-28） #
by Tomoichi_Sato
| 2019-09-22 17:12
| 考えるヒント
|
Comments(0)
当サイトの記事アクセスランキングを見ていると、2016年に書いた「E-BOM（設計部品表）とM-BOM（製造部品表）の関係を考える」がしばしば上位に顔を出す。E-BOMとM-BOMの関係に悩む人が少なくないのだろう。 『設計部品表』（Engineering Bill of Materials、略称E-BOM）とは、簡単に言うと、自社の製品の構造をその構成要素（部品・モジュール等）から示したものである。他方、『製造部品表』（Manufacturing Bill of Materials、略称M-BOM）とは、外部から購入した素材・部品を、製品に作り込む製造の道筋を示す道標だ、といえる。E-BOMは製品という「結果」を示し、M-BOMは工順データ（工程表）とともに、それを作る「方法」を表現したものである。 設計部品表E-BOMは製品の構造を示し、少なくとも自社で製品を設計する企業なら、必ず持っている（データベース化されているかどうか、はともかく）。では、製造業にとって、M-BOMは何のために必要か。 それは製品の需要を、具体的な製造の作業指示に展開するために使われる。M-BOMを基準にして、生産オーダーを工程展開し、各工程・作業区ごとの製造オーダーや購買オーダーを作成するためである。つまり、製造日程計画のベースとなる、個別オーダーの工程表を作成するために必要なのだ。 さらに、製造の標準原価を計算し、価格を見積るためにも役立つ。そして、進捗管理や負荷予測や変更管理の基準とするためにも有用だ。 このように重要な基準情報であるにもかかわらず、なぜM-BOMに悩む人や企業が多いのか。そして「M-BOMクライシス」ともいうべき状態に陥りやすいのか。理由は、三つほど考えられる。 一つには、そもそも製造部品表の概念がない企業が、しばしば見受けられるからだ。それも結構な大手企業であっても、である。そんな馬鹿な、というなかれ。理由は後ほど説明する。 二つ目の理由は、日本企業における生産技術部門の弱体化に関係している。それに追い打ちをかけるのが、製品品種数の増加現象だ。そして三つ目が（そして多分、将来的には一番重要になるのが）自動化・スマート工場化の動きである。だが、これらを見ていく前に、基本的な概念と用語について、一応確認しておこう。 図を見て欲しい。部品Aは、サブ部品（子部品）aとbからなっている。Aとa・bを結びつけるのは、工順Xである。工順Xは、作業1・作業2・作業3からなっている。各作業は、一つ以上のリソース（作業者・機械・工具・金型など）を必要とする。そして、製品を製造するための工順の集合をBOP＝「工程表」と呼ぶ。これが当サイトにおける用語とモデルである。  もっとも、もしかすると、あなたの会社の使っている用語とは異なるかもしれない（たとえば「工順」ではなく「工程」と呼ぶとか）。だが、日本には米国における「APICS Dictionary」のような生産管理分野の標準辞書が存在せず、業界各社バラバラなままなので、そこは我慢していただきたい。 さて、多くの企業において、設計部門は工場の生産部門とは別の拠点で、異なるITプラットフォームを使っている場合が多い。そのため、E-BOMからM-BOMへの展開が、整合性をとって行われにくくなる。整合性のキーとなるのは、品目マスタ（部品マスタ）の共通化である。設計部門と生産部門は、同じ材料を同じ品目コードで呼ぶ必要がある－－ここまでは、以前の記事でも書いたことだ。 ところで、先ほど述べた、製造部品表のない会社とは、どのようなケースか。それは、最終組立工程と検査・出荷輸送ぐらいしか、自社内でやらないメーカーだ。部品材料は全て、外部の下請けから購入する。こうした企業では、設計部品表と購買部品表は存在する（それがないと最終検査や資材調達ができない）。しかし、製造部品表は、設計部品表と構造が同一なので、あえて別に作る必要がなかった。 ただし、E-BOMでは同種の部品が複数箇所に使われている場合がある。購買用のP-BOMでは、同一品目は数量をまとめてサマリー化する（その方が価格ネゴがやりやすいので）。このため、E-BOMから材料ごとの数量をサマリーする作業が生じる。これをエンジニアリング業界などでは、Material Take-off（MTO）と呼ぶ。もちろん、CADで設計しているならば、MTOはCADシステムの機能を使う。 それにしてもなぜ、最終組立しか自社工場でやらないメーカーが存在するのか。それには歴史的背景がある。高度成長期には、ちょっとした工作機械や製造設備を持てば、下請け企業としてビジネスが成り立つ環境があった。このために、多数の零細な下請け部品加工業者が存在する、独特の産業構造ができた。最終消費財を作る大手メーカーは、部品はすべて下請けに作らせ、自社では設計と組立てだけを行う業態になっていったのだ。 最終製品のメーカーが、M-BOMを持たぬことで、何か不都合はあるのか？ 昔は、なかった。しかし、時代の変化はこの状況をかえてしまった。 長い平成不況の時代を経て、単に製造設備だけで食っている下請けは淘汰された。現代に残っているのは、筋肉質な部品メーカーばかりである。彼らは中小企業とはいえ、技術開発力も磨いているし、取引先を一社に依存しないよう、販路も拡大している。 M-BOMは製造の「方法」に関する情報だ。部品レベルの詳細な製造方法を知らないと言う事は、品質や納期問題に対して、前向きな技術的対策が打てないと言う事でもある。最終製品メーカーに課題が生じたら、下請けに命じたり、競わせたりするしか手がない。だが今や、複数の取引先を開拓した部品メーカーからは、そっぽを向かれる結果に終わる。 また最終組立しかしないメーカーでは、製品競争力の中核になるコアの部品についても、外部サプライヤーに製造を依存している。それが入手困難になったり、他社に同等製品を売られる事態になったらどうするのか？ さらに、部品加工以前の製造現場を持たないので、製造好みの設計、つまり作りやすく品質が保ちやすい設計を、自社ですることができない。競争力の重要な源泉を握っていない、と言うことになる。こうしたメーカーが外注を内製に取り込もうとすると、とたんにM-BOM不在の問題に突き当たるのだ。 さて、M-BOMにまつわる二番目の問題として、生産技術部門の弱体化は、どう関係するのか？ それは、誰が製造部品表を作るのかを考えてみれば、わかる。M-BOMは工程展開の基準情報だ。製品から工程展開を行えるのは、製造工程を熟知している生産技術ないし生産管理部門である。 既に作ったことのある製品を、繰返し生産する場合は、マスタから自動的に展開できる。だから普通は生産管理部門の仕事になる。ところが、新製品や、仕様の変更を含む場合は、どうしたって生産技術部門の仕事になる。その結果は、次回以降も繰返し可能とするために、マスターに登録することが望ましい。 問題は、リーマンショック以来、多くの製造業で生産技術部の人員削減・弱体化が進んでいることだ。にもかかわらず、差別化を求めて、次々と新製品は繰り出され、試作品が工場に充満する。そんな状況下で、製造部品表の登録維持といった地味な仕事を、誰が魂を込めてやれるだろうか？ そういう仕事をちゃんと評価できる会社だったら、そもそも生産技術者を無理に削減したりはするまい。かくて、E-BOM/M-BOM乖離の問題が発生していく。 そして製造部品表を取り巻く第3の、そして多分一番重要な課題は、昨今の人手不足に起因した自動化やスマート工場への期待だろう。スマート工場においては、より精密で新しい製造部品表の概念が要求される。生産管理業務と製造実行システムでは、部品表の粒度が異なる場合が多いからだ。だが、このことに気がついている人はまだ少ないように感じられる。 ちなみに、ここで言っている「スマート工場」とは、藤野直明氏らが近著「小説・第4次産業革命」で皮肉っぽく指摘しているような、単に製造機械にセンサーをつけてAIで分析し、チョコ停を防止したりする試みのことではない。それはごく局所的なスマート化でしかない。 わたしが課題と考えるているのは、あくまでも工場全体の知能化を目指す、スマート化である。それは工場の中の機械・人・物の状態を、全体として把握することをねらう。また、非人間的な作業は極力、機械化・自動化する工場である。それによって、より生産性の高い操業状態を目指せるし、様々な変更やトラブルに、俊敏に対応できる能力を持つだろう。 そのような次世代のスマート工場の中核には、現在の製造実行システム(MES)をさらに発展させた、中央管制のための仕組みが登場するだろうと、わたしは予測している。そこでは、複数の製造機械や搬送機械を束ねて、協調制御するシステムが機能しているだろう。 ここで改めて、先ほどの図を見てほしい。1つの工順Xの中に3つの作業1・2・3が並んでいる。それぞれの作業は、異なる機械や人などのリソースを必要としている。 そして、各作業の加工それ自体も、作業間の搬送も、自動化されてるとしよう。機械だったら、賢い人間とは違って、それぞれにプログラムを作り、指示を与えなければいけない。搬送指示だって、どの物を、どこからどこにに搬送しろ、と言う命令を機械に下すことになる。 という事は、工場内を動くモノには全て、識別のためのIDが必要になるわけだ。IDを与えたら、それが具体的に何であるかも、認識できる必要がある。こうなると、1つの工順の中に3つの作業がある場合、対応する3つの品目が必要になる訳だ。 ところで、以前別の記事に書いたように、部品表と品目マスターへの登録は、在庫管理が必要かどうか、がカギになる。1つの工順の中で、作業1で作られて次の作業2にすぐ受け渡しされる品目は、通常は在庫管理の対象にならない（こうしたものをファントムと呼ぶ）。だから生産管理システムにおいては、工順内に作業が3つあっても、品目は1つ登録すればいい訳で、製造部品表は簡潔で済んだ。 そして、わたしが見たところ、多くの製造現場では、生産管理システムの中の工順のくくりは、比較的大きな単位でまとめられている。それは、製造工程のリードタイムを、時間や分単位ではなく、「日単位」で与えているところが多いからだ。これによって、製造の順序を決める権限を、製造現場にある程度委譲しているのである。 こうした工場では、製造現場は毎朝、その日にやるべき製造オーダーのリストを眺めて、着手順位を決める。変更やトラブルがあった際にも、現場側が製造オーダーの順番を見直して解決する。それによって、製造現場に自主性と責任感を与え、また、起こりがちな予定からの変更に柔軟に適応できる能力をつけるためだ。 これは特に繰り返し性の薄い個別受注生産や、仕様変更品が多い現場には有効である。また生産計画の精度が低く、リードタイムの見積が信頼できない場合にも必要だろう。 しかし、このやり方にも弱点がある。正味1時間で済むはずの作業も、最小リードタイムの設定が1日になる。だから、工程表を構成する工順の数が多くなると、全体の生産リードタイムが有意に長くなってしまう。これを避けるためには、できた端から次工程に運搬していく必要がある。ところが、次工程に部品材料が到着しても、製造オーダーは翌日の着手予定のままだ。だから製造日程表を、生産管理システムの外側で、人手で変更するか、あるいは運んでいった人間が、自分で次工程の作業もするか、いずれかである。かくて、特級品は担当者が自分で複数の作業区を渡り歩いて、加工していくような工場も存在する。いずれにせよ人間系依存で、ちっともスマートでない。 これに対し、自動化・機械化の進んだスマート工場では、より粒度の細かな製造部品表が要求されることがおわかりいただけると思う。 しかし、そんな細かなデータを、すでに限られた人員の中で、どうやって作れるだろうか? もし設計部品表から製造部品表への自動展開の仕組みがあれば、便利だろう。ただし、それが実現するには、製品設計において、機能別モジュール化など、いくつかの前提条件が満たされなければならない。 もう一つの方法は、製造部品表にBOD（Bill of Distribution）の概念を応用することだ。つまり品種に位置の概念を取り込むのである。長くなったのでこれ以上の説明は省くが、いずれにせよスマート工場化は、製造部品表に対し、新しい挑戦的な課題を突きつけることになるだろう。 わたし達も、それに対応するための準備や研究を怠ってはいけないと思うのである。 ＜関連エントリ＞ →「スマート工場はスマートか? 」 https://brevis.exblog.jp/27295851/ （2018-05-26） →「広域サプライチェーンのためのPSI（生産・販売・在庫）計画と、その立案手法DRPとは」 https://brevis.exblog.jp/23466870/ （2015-07-25） #
by Tomoichi_Sato
| 2019-09-08 23:36
| サプライチェーン
|
Comments(0)
どんな会社にも、従業員台帳というのがある。従業員の氏名・誰それ、その住所、生年月日、入社年度、職種といった情報が記されている台帳だ。同姓同名の場合もありうるから、普通は従業員番号も振られているはずである。 同じようにどんな会社にも、給与台帳と言うものがあるはずだ。従業員誰それに支払うべき月給はいくらいくら、といった金額が書いてある。 もっとも、従業員に支払う月給は毎月、異なるだろう。残業代もつくだろうし、手当の金額も変わり得る。だから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 ＢＯＭ／部品表の基礎と効果的な活用ノウハウ もちろん、佐藤の考え方には賛成できない、反論を述べたい、という方も大歓迎である（笑）。ちゃんと議論して、わたし達の社会の製造業のレベルアップに、ぜひ一緒に寄与しようではないか。 ＜関連エントリ＞ →「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)
ポータブル・オルクハンガー （Amazon.com） 以前も書いたことだが、冷房が苦手である。若い頃に、南国に1年ほど暮らしたことがあったが、その時に冷房病にかかってしまった。それ以来、体温調節の機能が低下したらしい。もともと汗かきの方だったが、冷房の効いた場所に入っても、しばらく首から背中にかけての汗が止まらず、それが冷えて風邪をひく原因になりやすい。 自衛のために、夏は、替えの下着を持って歩くのが常である。おまけに、冷風による「冷え」から体を守るために、薄手のベストや上着を持って歩くことも多い。まして客先を訪問する時ともなれば、なおさらだ。かくして、夏場はかえって荷物が増える、という奇妙なことになる。 ことに面倒なのは、上着の扱いである。サラリーマンなので、上着を持って歩かなければいけないことが、結構ある。上着というやつは、畳んでバックに入れるとしわくちゃになるし、かといって、腕にかけて持ち運ぶのはけっこう面倒な上に、腕にも汗をかいてしまって、汚れやすい。 どうしたものかと悩んでいた時に、携帯型の小さなハンガーを、知人が見せてくれた。伸縮可能なステンレス製のポールに、ストラップのついただけの簡単なハンガーだが、小さいし、持ち歩きやすい。たたむと20センチ以下だが、伸ばすと40センチ位になる。小さな袋が付属していて、使わないときにはたたんで、バッグの中で邪魔にならないように、しまうこともできる。 上着を持って歩くときは、ボールを伸ばし、上着を2つ折りにし、そこにかけて、外側のストラップを引っ張る。すると、内側のストラップがボールに密着して、上着がずれて落ちないようになっている。簡単だが巧妙な仕掛けだ。   このままストラップを肩にかけて、持ち歩くのでもいい。だが、わたしはあえて、トートバッグの口に、このハンガーの両端を引っ掛けて、上着が外から見えないような形で持ち歩くことにしている。 新幹線の中などでも、上着をこのハンガーにかけて、自分の座席の前にかけておくと、シワになりにくく、扱いが楽である。上に述べた小さな袋を使うと、リュックやバッグの外側に、このハンガーを固定して、一体で持ち運ぶこともできる。なかなか小技が効いているのは、ユーザのことをよく考えている証拠だろう。 この頃は毎年、暑い夏が続いている。本当は、日本のような高温多湿な地域で、夏も冷涼な英国発のスーツ・ワイシャツ・ネクタイの風俗に従っていることに、無理があるのだ。近年はお上の主導で、ようやく夏場のネクタイをしなくて済むようになり、少しは助かった。 しかし、米国ハワイ州のように、気候風土に適した服装（＝半袖のアロハシャツ、女性ならムームー）が『正装』の地位を占めるようになるまでは、まだ時間がかかるのだろう。あそこの島では、知事だろうが州議会議員だろうが、アロハ姿で仕事をしえいるのだが。そして、冷房抜きで過ごせる気持ちの良い夏は、日本の大都会には望みようもないらしい。だとしたら、しばらくは、こうして上着を持ち歩く道具に、少しばかりの知恵を注ぐのが賢明なのだろう。 #
by Tomoichi_Sato
| 2019-08-17 19:45
| ビジネス
|
Comments(0)
－－敗北から学ぶために必要な方法にも、いくつかある。ここでは4つぐらいあげようか。 まず第一に、勝敗の結果だけではなく、プロセスと中間目標を設定しておく。本当はこれは、戦う前に、やっておく必要がある。その上で、個別の戦局や、あるいは全体における達成度を吟味する。 「どういうことですか？」 －－つまりさ、ローマは1日にしてならず、というだろう。たとえば何でもいいけど、大学受験を例に取ろうか。難関の名門校に入りたい、と。そうしたら、受験科目のどれが得意か、どう勉強するのか、予備校には行くのか、考えるだろう？ また、模試を複数回受けるとして、現役1回目は何点くらい、2回目は何点、と想定して、直前模試でA判定になればいいはずだ。 こう言う風に、単なる勝ち負けだけでなく、プロセスと中間目標を設定する。そして、途中途中で、目指した通りに進んでいるか検証する。うまくなければ軌道修正する。仮に現役では合格できなくても、もう一度チャレンジするべきか、考え直す。そして反省点を翌年の試験に生かそうとするだろう・・それなのに、受験生のときにはできていたことが、ビジネスマンになるとすっかり忘れてしまうとしたら、奇妙なことだ。 「確かにそうですね。でも、その中間目標というのは、実際にはどう立てたらいいんでしょう。ビジネス上の戦いは、受験ほど単純じゃありません。偏差値の表もなければ、予備校の模擬試験もありませんし。」 －－もちろんだ。だから2番目に大切なことは、適切な戦略を選んでから、中間目標に落とし込むと言うことだ。 「戦略を選ぶ、ですか？ 戦略って、毎回個別に考えるものかと思っていました。」 －－もちろん、そうさ。そうだけれども、戦略にはある種の定石ないしパターンがある。まあ、戦略論は多岐に渡るから、ざっくり簡単なパターンに絞って説明することにしようか。 たとえば市場における競争戦略は、その会社の立場によって異なる。チャンピオンの戦略と、挑戦者にとっての戦略と、ニッチプレイヤーの戦略は異なる。あなたのところの会社は、チャンピオンかな、それとも挑戦者か、ニッチプレイヤーなのかな？ 「えーと・・あまり考えたことがありませんでした。今回の戦いに限って言うと、トップ企業じゃないから、チャレンジャーかなぁ。」 －－なるほど。どんな業界も大体、少数のトップ企業と、それに次ぐチャレンジャーたちと、多数の小さなニッチプレーヤーからなる、いわばピラミッド構造になっている。 業界のトップ企業は、その規模を生かして、製品もフルラインナップを揃えているし、営業ネットワークもあるし、物量を生かしてローコストで大量生産ができる。だから最終的には価格競争に持ち込んで、顧客を囲い込む。これを『コストリーダーシップ戦略』という。戦争に例えるならば、正面攻撃の戦術といってもいい。 「はい。」 －－一方、チャレンジャーたちは、正面から価格競争を挑んでも、勝てそうもない。そこで普通は、『差別化戦略』を考える。大手が販売する製品とは、かなり異なった特徴のある製品を売り出して、価格とは別の面で顧客に訴求する。側面攻撃の戦術と言っていいだろう。 「確かにある意味で、僕らが戦う上でとっていた方策は、差別化を志向したと言ってもいいかもしれません。意識してやったわけではありませんが。」 －－なるほど。そして大多数の、中小零細規模のプレイヤーたちは、ある狭い局地的範囲内のみに、自分たちの持てる経営資源を集中して、そのニッチなマーケットだけは死守しようとする。例えば顧客との長いつながりで商売を続けている、地方の老舗の商店を考えればわかるかな。あるいはごく特殊な製品のみを扱う、その分野でのみ全国的に名の知られている企業なんかも、これに近い。いわば局地戦、ないしゲリラ攻撃の戦術だ。これを『集中戦略』という。 そしてこの3つの戦略ごとに、立てるべき方策も、中間目標も異なっている。  「なるほど、そういう風にロジックを持って考えると、中間的な目標も立てやすいですね。」 －－ただしね、ここに挙げたのはパターンに過ぎないから、実際には具体的に何をどうするかを考えないと、戦略の名に値しない。戦略とは、固有名詞が入って初めて、役に立つものだ。 たとえば第二次大戦中、ドイツ軍に占領されたフランスを奪還するために、連合軍が作戦を考えるとしよう。その時、側面攻撃しよう、フランスの大西洋岸から上陸だ、だけでは戦略とは呼べない。具体的に、カレーを攻めるのか、ノルマンディーから上がるのか、それとも別の攻略ポイントを探すのか。具体的な地名と、時期と、兵力と、方法がなければ、戦略にならないし、準備もできない。わかるだろう？ 「たしかに。」 －－もしも、あなたの会社がチャレンジャーで、差別化戦略を志向するなら、どのような訴求点を持つべきか。どの程度他社を引き離すべきか。それによって得られる金銭的なアドバンテージはいくらぐらいか・・といったことについて仮説を立て、目標設定して、検証していくんだ。 戦略とは仮説だ。「こう戦えば、きっと勝てるはずだ」という仮説だ。だがしばしば、仮説には間違いがある。だから途中途中で検証しながら進む必要がある。人間は誰だって、自分たちが有利であると言う思い込みにとらわれやすく、そこから間違った仮説が生まれやすい。したがって、仮説を文字に残しておくことがとても重要だ。 「でも、方針というのは、いったん書面にすると、仮説どころか、絶対化されやすいですが。」 －－そうだね。だから、3番目に大事なのは、戦いを始める前に、状況を客観的・数値的に分析しておくことになる。たとえばマーケットの戦いならば、敵は誰と誰で、どういった商品を揃えていて、どんな販売チャンネルを抱えているのか。これまでの売上高や、受注確率はどれくらいなのか。顧客はどんなセグメントからなっており、どういう好みを持っているのか。こうしたことを事前に分析しておかなければいけない。 「具体的には、例えばどんなことですか?」 －－そうね。例えば営業における受注競争なら、過去の勝率はどうだったのかという事さ。もしも自社の平均的な勝率が約3割で、今期の受注目標が10億円だったら、最低でも合計33億円以上の可能性のある競争案件を、営業リストに載せなければ、目標は達成できない。また、既存顧客には強いのか、大型の案件には弱いのか、といったことも分析の対象だ。 「それってでも、案件ごとに条件が違うと思います。確率なんか言われても、個別の現場担当として役に立ちません。問題はむしろ、勝敗の質じゃないか、って感じるのですが。」 －－勝敗の質ね。そう言いたい気持ちはわかるよ。でも、あなたは製造業の人だから、あえて尋ねるけれども、じゃあ不良品はモノの質が低く、良品はモノの質が高い、と言えるだろうか。むしろ、検査結果にデコボコがあって、予測し難い点に、問題があるのではないか。つまりモノの質ではなく、プロセスの質を上げるべきではないか。 同じように、個別の戦いの勝ち負けだけが問題なのではなく、勝敗が予見し難いことが問題ではないのか？ そうなると、自社の体制や人材も、前もって適切に準備できないだろう。それはやはり、プロセスの問題なのではないか？ 「つまり、事前にもっと計画しておけ、ってことですね。でも、ウチのボスは、『どうせ計画した通りには現実なんか運ばないんだから、計画を立てるなんて時間の無駄だ。現場を見て状況に応じて考えればいい』と、つねに言っています。」 －－もちろん現場を見て考えるのは、いつでも大切だ。しかし、計画抜き・現場判断、というやり方が通用するのは、ごく小さな戦局か、あるいは自社がリーダーで、戦い全体を自分たちの思惑通りに運んでいるときに限る。連合軍がノルマンディーに上陸するか、カレーに上陸するかを、現地を見て決められると思うかい? 上陸する兵士や機材を動員するのに、数カ月はかかる。上陸地点によって、必要な装備も違うだろう。数字に基づいた計画がいるんだ。 第二次大戦の英雄だった米国のアイゼンハワー大統領は、「計画通りに現実は動かない。しかし計画を立てるプロセスは絶対に必要だ」と言っている。君の上司との違いがわかるよね。 「たしかに、違いはありますね。」 －－計画のための情報収集と分析は、分担を分けた方が良い。なぜなら分析は、総合的な情報を集めて行うべき仕事だからね。個別の情報入手した時点で、勝手にローカルな分析を行って解釈した結果を、中央に集めたりするのはあまり良いやり方ではない。データ収集には、必要ならば第三者の知恵を借りることも、するべきだろう。市場調査会社とか、コンサルタント、エージェントといった人たちだ。 そして、戦いの中間の要所要所で、データを集めて状況を分析し、戦略を補正する。ターゲットとすべきセグメントが間違っていることもある。あるいは顧客の要求を読み間違えることだってある。それを一つ一つ、データによって検証する。ときには、撤退を考えなくてはならない場面もある。 前に「マジックナンバー＝5」という話をしたのを覚えているかなあ。対等だと思った勝負に5連敗したら、もう対等だという仮説は捨てたほうがいい、という数学的法則だ。こういう判断は、データを積み上げないと出てこない。 「データを集め、数字から学ぶ、ってことですか。確かに、ウチに一番欠けていたのはそこかもしれません。」 －－そして最後の4番目は、戦いが終わったら、根本原因（Root cause）の分析を行うことだ。Root causeの定義とは、「論理的に見つけられる基本的原因で、かつ、マネジメントによって解決可能であるもの」だ。 表面的に、客が悪いんだとか、運がなかったとか、不況や円高などの環境のせいにしては、いけない。それは自分たちには解決可能でない。だから根本原因に選んではならない。選ぶなら、なぜ客筋をきちんとアセスしなかったのか、なぜ為替リスクのヘッジを怠ったのか、運不運で決まるような案件に、なぜ大きな勝負を賭けたのか、を問題にすべきだ。 「リーダーの責任というのは、どうなるんです？」 －－根本原因分析をするときに気をつけるべき点は、「責任追及の場にしない」ことだよ。もし責任追及が主目的だったら、誰もが自分をかばって、本当のことを言わなくなる。本当のことがわからなかったら、根本原因分析なんて、どんな意味がある？ 根本原因分析の最大の目的は、同じ種類の間違いを繰り返さないこと、つまり再発防止にある。そのために、自分たちの仮説や行動に足りなかった点は、どこかを明らかにする。そして教訓を文字に残す。 敗北などのトラブル事象を、リーダーとか誰かの責任、で説明してしまうと、対策はその人間をポストからはずす、しかなくなる。じゃあ、他の人間をそのポストに据えたら、同種の間違いは決して起きない、と言えるのか？ それに、失敗したら責められる、という組織では、だれが新しい創造的な仕事に挑戦するだろうか。 「ふー。結構大変ですね。とくに、勝負の前にやっておくことが多いですし。・・これ、ウチでやりきれるかなあ。」 －－まあ、わたし自身だって、正直言って、いつも全部はできていなかったさ。ただ、こうすべきだったと思うから、偉そうに聞こえたかもしれないけれど、あえて喋らせてもらった次第だ。 「でも、自分のところは、計画立案能力も弱いし、データ活用も、からきしダメです。片方だけでも大変なのに、両方なんて到底無理かな。」 －－でもないさ。計画とデータ活用は、じつはワンセットの能力だから。 「そうなんですか？」 －－うん。計画を立てない組織には、ちゃんとした「ふり返り」もない。客観的なふり返りを知らない組織は、後で活用するためにデータを蓄積する、と言う姿勢もない。最初に用意しないまま、あとになってからデータを分析しようとするのは、予算も立てずに決算だけするようなものだ。 「その財務の喩えは、よく分かります。計画とふり返りが、データ蓄積の基本なんですね。」 －－計画とは、いいかえれば具体的なアクションの塊だ。そして計画を立てられないようなビジョンは、夢と言う。夢を見ているだけでは、現実は近づかない。 夢に近づきたかったら、まず事実と経験から学ばなければ。たとえそれが、痛い経験であってもね。昔の人も言ったじゃないか、「過ちて学ばざる、これを過ちと言う」ってね。 ＜関連エントリ＞ 「失敗の無限ループから抜け出すマジックナンバー『5』」 https://brevis.exblog.jp/15454723/ （2011-09-15） #
by Tomoichi_Sato
| 2019-08-07 23:12
| ビジネス
|
Comments(0)
|
検索
カテゴリ
著書・姉妹サイト
私のプロフィル My Profile
【著書】 「世界を動かすプロジェクトマネジメントの教科書  」「時間管理術  」(日経文庫)「BOM/部品表入門 (図解でわかる生産の実務)  」「リスク確率に基づくプロジェクト・マネジメントの研究  」【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
最新のコメント
最新のトラックバック
フォロー中のブログ
ブログパーツ
ファン
記事ランキング
ブログジャンル
画像一覧
|
