<   2006年 06月 ( 3 )   > この月の画像一覧

「設計管理」の必要性

私の好きな米国のマンガ"Dilbert"にこんな話があった。セクレタリー(秘書業)の低い地位にいやけがさした若い女の子が、技術職になりたいと思い立ち、同僚の女性エンジニアであるアリスに相談に行く。アリスは彼女にこういう。

アリス「あなた、エンジニアになるには、何年もの訓練が必要なのよ。」(ふと上司を思い出して)「・・でも、エンジニアのボスになるには、何の訓練もいらないの。あれって、スキル不要の、苦労なき労働なのよね。」

すると彼女はこたえる。「だったら、私にもできそうね。」 

米国のハイテク企業を舞台にしたマンガ"Dilbert"には、無能を絵に描いたような部長が出てきて、よく私たちを笑わせてくれる。この部長ときたら、ネットワーク回路図とプロジェクト工程図を見分けられるかどうかさえ疑問だが、それでも『リーダーシップとは』などと経営論の片言を口にして、必要もないのに部下を休日出勤させたりするのだ。

上司は部下を管理するものだと、誰でも思っている。このマンガでは、技術を知らない上司が、部下を管理したつもりになっていることの愚かしさを描く。しかし、それでは、設計の固有技術をよく知っている人間ならば、設計部門をうまく管理できるのだろうか。たとえば電磁流体解析や熱応力計算が上手なエンジニアは、他のエンジニア達をうまく采配できるのだろうか?

生産工程には生産管理が必要であり、設置工事には工事管理が必要であると、誰もが知っているし、たいていの会社にはそうした名称の部署がある。ところが、「設計管理部」という部署がある企業には、まだお目にかかったことはない。ちょっと考えると不思議である。設計は管理しなくともうまく進むのか。設計が遅れて困ったり、設計の品質が低くて現場が混乱するケースは、希少な例外なのだろうか。

むろん、そんなことはあるまい。しかし、設計管理部の必要性が議論されない理由は、想像がつく。それは「管理」という語の曖昧性、そして設計者がホワイトカラーという(元)エリート階層に属することにより、おおいかくされてしまっているのだ。

いったい、管理とは何だろうか。以前も書いたように、私自身は、この曖昧な多義語がきらいなので、自分では滅多に使わない(「マネジメントと管理はどこが違うか」参照)。かわりに、マネジメントとかコントロールとかスーパービジョンとか、英語にあるカタカナ言葉を使うようにしている。しかし世間では、上司は部下を「管理している」と思っている。上司という立場になれば、部下への命令や、業績評定や、アドバイスや、宴席で上座に座る権限などを、手に入れられる。しかし、Dilbertのマンガにあったように、なんの訓練もスキルもなしで、本当に部下を「管理」できているのか? 

その典型例は、ソフトウェア産業の組織にしばしば見られる、奇妙な進化論である。平社員のプログラマが、少し経験をへるとになるとSEクラスのリーダーになり、SEもだんだんとベテランになると課長兼プロジェクト・マネージャーになる。そして、クリティカル・パスもWBSも知らないまま、プロジェクトの戦場に突入していく。引率される兵隊こそいい迷惑である。

ここには、「管理」のためには「管理技術」が必要である、という認識が欠けている。そこで、ようやく最近はPMO(プロジェクト・マネジメント・オフィス)なる別組織を作って、設計・開発の固有技術以外に、プロジェクト管理技術の専門担当者をおく企業が増えてきた。

ところがひるがえって、一般の製造業ではどうか。まだまだ、設計管理という問題意識が乏しい。その理由は、社内の人種階層制にある。生産管理部や工事管理部が存在するのは、じつをいうと製造現場や工事現場のブルーカラーを監督し統率するため、と考えられているからだ。一方、設計部門は社内でもエリート集団の場所である。一丁目一番地に住む人々が、なぜ他の部署から監督統率されなければならないのか。

そのくせ、製造業はどんどん見込生産から受注生産へとシフトしている。ますます、個別案件での設計のかかわりが増えている。製品開発設計のスピードも、しばしばネックとなっている。だから、生産システム全体を見渡すと、あきらかに設計にも課題が増えてきているのだ。

ここで、映画監督を思い出してほしい。監督は自分では演技しない。必ずしもベテラン俳優が監督になっていくわけでもない。しかし、スター俳優にシナリオを渡し、演出を指導する。そして、映画撮影の進行をコントロールする。

このような役割の人間が、製造業でも必要ではないか。多くの会社の現状は、監督のいない映画撮影のようだ。一人一人は努力し、苦心している。だが、ちっともハーモニーもストーリーもないのだ。それも、困るのが設計部門だけなら、まだしも自分のまいた種と言えるだろう。しかし、設計で発生した問題は、購買や、生産技術や、製造や、物流や、販売や、あちらこちらの離れた場所で火をふくのだ。

それでは、具体的には『設計管理』のために、いったい何をしたらいいのか。長くなってきたので、項をあらためて、また書こう。
by Tomoichi_Sato | 2006-06-22 23:14 | ビジネス | Comments(0)

製造管理とは何か

日本の生産管理系の用語はややこしい。その最たるものが、この「製造管理」だろう。生産管理と、製造管理とは、同じなのか、違うのか。同じなら、なぜ二つの用語が並立しているのか。違うとしたら、何が違うのか。生産と製造はそもそも違うものなのか。疑念は尽きない。

生産管理』が、製造業において生産システムをつかさどるために必要な、すべての間接業務をあらわす風呂敷みたいな概念だということは、すでに書いた。生産システムの中には、工場内の生産活動みならず、設計や調達や物流にかかわる活動も、しばしば含まれる(どこまでが含まれるかは、その企業の生産形態による。個別受注生産・見込生産・繰返受注生産・連続生産・ファブレス企業等々で、そのバリエーションと守備範囲がことなってくる)。

また、同じ製造業といっても、企業の規模は様々である。社長自身が額に汗して働く町工場からはじまって、工場と本社が同居している企業、本社や営業機能がわかれて工場は生産に専念している企業、複数工場を持っている企業、そして全世界に生産・物流拠点をもっている企業まで、広いスペクトルがある。

一般に企業組織は、量的に大きくなればなるほど、機能別に分化していく性質をもっている。したがって、生産に直接間接にかかわる部門の範囲は、大企業になるほど多くなる。設計や、集中購買や、物流や、生産計画などの諸機能が、工場の外に行ってしまっているケースは珍しくない。

そのため、こうした広義の「生産」にかかわる活動と、工場内で直接作業に従事するための活動とを、区別する必要が出てくる。その場合、後者をしばしば『製造』と呼ぶ。生産は広義の概念で、製造が狭義の概念に相当するのである。そして、その製造を支えるための間接活動を指して、製造管理と呼ぶのだ。

ちなみに、英語では生産はProduction、製造はManufacturingであるが、この両者を広義と狭義で厳密に使い分けているかというと、必ずしもそうではない。たとえばMRPⅡはManufacturing Resource Planningの略と言うことになっているが、カバーしている範囲は明らかに購買も受注(販売)も含む広義の生産活動である。

もう一つ、MESという言葉もある。これは情報システム系の用語で、Manufacturing Execution Systemの略だ。もともとはAMR Researchという機関による造語で、日本語では製造実行システムと訳しているが、なんだかあまりしっくりこない。そこでしばしばこれは、『製造管理システム』とも呼ばれる。ここにも製造管理が出てくる。

しかし、これは実はなかなか穿った訳語なのである。もともとAMR Researchでは、製造業の情報システムとして、「三層モデル」というものを考える。最上位層は、本社レベルにおける生産のマクロな計画と管理である(これを「計画層」Planning Layerとよぶ)。最下位層は、工場現場における機械設備の運転と制御である(「制御層」Control Layer)。そして、その中間に、工場の製造手配と進捗把握のための活動が来る(これを「実行層」Execution Layerとよぶ)。

これらの階層は、そのまま働く人間の職位につながっている。計画層は本社の生産企画部門、実行層は工場のホワイトカラー管理職、制御層は現場の職工である。また、情報システム的に言うと、最上位のERPシステムと、現場の制御システムをつなぐ立場として、製造実行システムMESが来る、という位置づけになる。整理すると次のような形だ。

(1)計画層-本社管理者-年月単位・工場単位・製品群単位のマクロな視点-ERP
(2)実行層-工場管理者-月週日単位・工程単位・品目単位の視点-MES
(3)制御層-現場運転員-週日時単位・機械単位・ツール単位の視点-PLC

むろん、これは類型化したモデルであって、いつもこの通りとは限らない。本社で、時間単位のスケジューリングをしている会社もあれば、現場班長が半月分の差立てを決めている会社も知っている。ただ、こう整理すると分かりやすいのだ(詳しくは、工業調査会・刊「MES入門」をご参照いただきたい)。

そして、(1)が広義の生産管理、(2)が狭義の製造管理、にそれぞれ対応していることが分かるだろう。広義とか狭義とかは、すなわちマネジメントのスコープ(責任範囲)のことを差しているのだ。

だから、ERPシステムで生産管理までやるべきだ、とか、いや無理だ、とかいった議論は、そもそもナンセンスなのである。生産管理といい製造管理といったとき、どこまでが必要な管理の粒度(視点の細かさ)なのか、そして判断の自由度をどこまで下ろすべきなのか、それは生産システムの質に依っている。そこの議論を抜かしたまま、情報システムベンダーや経営雑誌の批評に自分の判断をゆだねては、いけない。
by Tomoichi_Sato | 2006-06-12 00:18 | ビジネス | Comments(0)

科学の子

JR高田馬場駅のホームで乗り降りしたら、耳慣れた曲が聞こえた。電車の発着のベルのかわりに、アニメ「鉄腕アトム」の主題歌が聞こえたのだ。谷川俊太郎作詞・高井達夫作曲の、あの“空を超えて~、ラララ、星の彼方~♪”という歌である。この駅だけ、なぜ鉄腕アトムなのかは、よく知らない。もしかしたら手塚治虫の虫プロが、かつてこの地にあったのかもしれない。いずれにせよあのメロディは、昭和30年代に生まれた男の子なら、誰でも知っていた。

この歌を想い出してみると、もう少し先で、“心優し~、ラララ、科学の子~♪”という風に音階が盛り上がっていく。「科学の子」! 今日の世界では、決して思いつかないフレーズだなあ。若いときの谷川俊太郎は才能があったのだろう。いずれにせよ、今ではこんな言葉、誰もロマンチックには感じまい。

科学というものが、ロマンチックな性質を持つことを、もはや皆が忘れているらしい。エンジニアはみな、科学を学ぶ。技術は科学の裏付けがなければ、たんなる職人の手仕事にとどまってしまう。技術者を志す大きなモーメントは、科学というものの持つ限りない可能性と、理知的な精神の結びついた、ロマンチックな性質だったはずだ。

最近、情報系の学科は入学希望者がたてつづけに減ってきている。知り合いの大学教授から、そう聞いた。さもありなん、とも思う。IT産業はこの20年間というもの花形だったが、それを支えるソフトウェア技術者は過酷な労働環境を強いられる職業だと、誰もが思うようになった。技術者というより、ソフトウェア労働者と呼んだ方がふさわしい。しかも、それで大金が儲かる確率は、もはや極めて小さい。企業は中国かインドに仕事をアウトソースしようと虎視眈々だ。経済産業省が鉦と太鼓で育成の音頭をならそうとも、誰がそんなしんどいばかりの仕事に就きたいと思うだろうか?

似たようなことは、工学部全般に言える。青少年の理工系離れを防ぐために、いろいろな人が策を提言しているが、私は悲観的だ。なぜなら、エンジニアという職種は、今の産業界では、たいして報われないからだ。嘘だと思うなら、製造業の役員リストを調べて、その中に生産畑・研究畑出身がどれほど少ないかを見てみればいい。彼らの科学知識は、彼らのキャリアを豊かにするために、どれだけ役に立ったか? こうした事実に目をつぶったままで、青少年だけを、使いやすい歯車として育てようというのは虫が良すぎる。

つい先日、同年代のエンジニアで飯を食いに行って、しばらく雑談した。話は彗星にロケットを打ち込んで、そこから物質サンプルを持ち帰るプロジェクトの成功と失敗要因に至り、おおいに花が咲いた。こういう話は楽しい。もっている科学知識をあれこれ動員して、想像力の翼を多少なりと羽ばたかせることができる。こういう議論をしていると、ああ、自分たちはまだ科学の子の意識が、少しは残っているな、と感じる。わずかなりともそこには、歳を忘れさせるロマンティックな香りがある。

リスク確率にもとづく貢献価値理論について、最近あれこれと考えている。その中で、タスクの貢献価値の比率は、その仕事の難易度(つまり代替可能性の小ささ)に比例することを証明できた。これを応用すると、コストセンターの生産部門の貢献価値が、プロフィットセンターの営業部門よりも大きくなる条件も示せる。お金を使うばかりの部署でも、価値の源泉であることが示せるのだ。こういう発見こそ、科学的アプローチの醍醐味だろう。

製造は代替可能ではない、と私は言い続けている。設計もそうだ。こうした仕事は単なるコストセンターだから、さっさと海外に移転すべきだと考える今日の経営思想に、私は反対だ。販売はプロフィット・センターであり、マーケット・インの環境下で強い発言権をもつのは当然だ、と多くの人は思っているらしい。私はこれにも完全には同意しない。モノの感覚に裏打ちされた科学のセンスを失うと、組織はしばしば言葉の上だけで空回りを始める。言葉では何でも言える。だが、言葉による論理の暴力に対抗できる力を持つのは、検証可能な事実に即して考える訓練を経た者、すなわち科学を身につけた者だけなのである。
by Tomoichi_Sato | 2006-06-05 00:33 | ビジネス | Comments(0)