ディスクリート・ケミカル産業

私は大学で化学工学を専攻した。カガクコウガクという学問名は、すべて「カ行」の音だけでできている上に、一つの単語の中に「学」が二回出てくる、きわめて珍しい分野名である(こういう語は、あと他に『科学哲学』があるだけだ)。

日本は言霊のさきわう国だというが、このように難解(?)な名称の学科を選択したおかげで、私は他人にうまく専門を理解してもらったためしがない。化学工学は広い意味では「応用化学系」に分類されているので、“ああ、化学が得意なんですね”と言われたりする。だが、現実は、全然違う。私は化学は大の苦手で、大学入試の理科の試験は物理と化学だったが、物理はほぼ100点に近い自信があったのに、化学はただ1つの小問を除いて白紙答案を提出した。

さらに、恥を忍んで告白すると、私は大学院の試験勉強のために、高校生向けの化学の参考書を買って勉強した。それでもパスしたのだから、化学工学という学問を専攻するのに、複雑な化学の知識は不要なことがよくわかる。私の知る範囲でも、化学工学を専攻した人の中で、化学に強い人は3割程度しかいないと思う。

化学工学は20世紀に入ってから発達した学問で、英語ではChemical Engineeringという。具体的には、化学装置と化学工場の設計論を目的にした工学である。米国ではMechanical Engineering=機械工学とならんで、人気の高い分野だ。機械工学は機械装置と部品組立工場の設計論だから、ちょうど対をなしている。いいかえるなら、化学工学はプロセス産業を支え、機械工学はディスクリート(組立加工)産業を動かしている。だから、化学工場の設計技師は『プロセス・エンジニアProcess Engineer』と普通呼ばれる。

ところで、化学工業=プロセス、機械工業=ディスクリート、という区分は最近、当たらなくなってきている。じつは、現代日本の化学産業には、見えない地殻変動が起きており、化学工場なのに製品はディスクリートのケースが増えているのだ。どんなケースか?

それは、いわゆる電子材料、あるいは高機能素材と呼ばれる製品をつくる工場である。たとえば有機EL材料、半導体封止材、発光素子、偏光フィルム、逆浸透膜といった製品群だ。こうした製品の特徴は、固体であること、単価が高いこと、組成は似ていても機能的な違いが大きいこと、などである。言いかえれば、高付加価値であり、かつ多品種化した製品群となっている訳である。

そして、それが相当の利益を稼ぎ出している。「会社四季報」などの化学のページをめくってみれば分かるが、日本の化学メーカーの多くは、すでに1年半から2年前に不況を脱しているものが多い。そして、その企業の収益を支える製品が、こうしたディスクリート・ケミカル製品なのだ。四季報には各企業の概況が要約されているが、“携帯向け素材が好調”“デジタル家電用途で成長”といった言葉が並んでいる。

かつて、化学産業では「バルクケミカル」・「ファインケミカル」という区分があった。前者はエチレンやBTXなど原材料から、せいぜい汎用ポリマーくらいまでの、物量の大きな上流側製品群を指す。後者は農薬・原薬・試薬・添加物・特殊ポリマーあたりの下流側製品群を指すことが多かった。共通点は、いずれも連続プロセスないしバッチプロセス中心で製造されること、物流の主要な形態は液・ガスないし粉体(大きくてもペレット)であることだ。

日本の化学産業は基礎原料の石油・ガスを輸入に頼らなければならない制約がある。このため、バルクケミカルでは規模の経済を追求しても、なかなか海外品に比べて競合がきつい。したがって、'70年代の石油ショック以降は、しだいにファイン指向を強めてきた。しかし、やはり付加価値を高めたければ、より消費者に近い素材に向かうことになる。

こうして、'90年代の後半から、ディスクリート・ケミカルの領域が生まれてきたのだ。この領域はある意味ではニッチ的だったため、大手化学メーカーだけでなく、新進の素材専業メーカーが活躍する余地を残しており、製品開発競争も活発である。官庁の法的規制もあまり強くなく、自由に技術力をふるうことができる。技術者として、非常に面白い分野である。

最初に述べたとおり、「化学工学」は本来、化学工場の設計論として発展してきた。しかし、この国では化学、とくにバルクケミカルは、公害問題以来あまりいいイメージを持たれていない。そのため学生に不人気となり、今や大学から化学工学科の名前がほとんど消えてしまっている。かわりにシステムとかバイオとか格好いいカタカナの混じった学科名になっている(ここらへんが言霊のさきわう国なのだ)。しかし、いざ外国に行くと、そんな新奇な学問名は通じないので、みな当惑する。

私は、むしろ化学工学は、新しいディスクリート・ケミカル産業に奉仕すべく、変化を遂げるべきだと思う。無論、従来のプロセス設計が急に不要になる訳ではない(とくに海外では)。しかし、今、一番進歩が活発なのは、この分野なのだ。そして、困ったことに、ディスクリート・ケミカル分野は、工場の設計論が未整備である。どこが難しいのか、どこに手がかりがあるのか、長くなってきたので、続きはまた書こう。
# by Tomoichi_Sato | 2006-04-17 00:24 | ビジネス | Comments(0)

「ソリューション・セリング」 マイケル・ボスワース著

現代は製品がなかなか売れない時代である。市場の競合はきびしく、長かった不況のせいでユーザの財布の紐はかたい。

製品が売れないのはなぜか。うちの会社の営業マンが無能なせいさ、と楽観(悲観?)できる技術者は、あまり多くない。価格で競合製品と大差がない場合、ふつうは、製品に魅力がないのではないか、必要な機能が足りないからではないか、あるいはデザイン・センスに問題があるからではないか--そう、技術者という人種は考えたがる。だから、どんどんと製品の機能は肥大化し、開発コストはかさんでいく。

この考え方は、裏を返せば、製品が良ければ必ず売れるはずだ、との単純な信念になる。だが、はたしてそうだろうか?

そうではないのだ、と著者・ボスワースは本書で主張する。たとえば、米国では腕の良いセールスマンはしばしば同業他社に引き抜かれる。すると、どうだろう? 彼(彼女)は、移った先の会社でも、やはりすぐれた売上成績を上げるのだ。そして、また別の会社に高給で転職したりする。すると、またまた、その新会社の製品をたくさん売るのだ。

これから分かることは何か。それは、よく売れるかどうかは、じつは製品の優劣にはあまり関係がない、という事実だ。では、売れ行きは何で決まるのか? それは、営業マンの販売プロセスであり、セールスが顧客の問題意識といかに連携しているかが、キーなのである。それは商品の物質的実体がないソリューション型商品では、とくに大きい、と著者は言う。

そもそも、「ソリューション」とは何か。ふつう、顧客は通常「ニーズ」を持っていると考えられている。しかし著者は、顧客は解決したい「ペイン」(痛み)を持っているのだ、と捉える。そのペインをどう解決すべきか、たいていの顧客はぼんやりとしか分かっていない。この解決手段に関して、具体的なビジョンが顧客の心の中に形成されて、はじめてニーズになるのである。そして、その解決手段のビジョンにマッチする商品が「ソリューション」である。

したがって、販売プロセスで一番重要なポイントは、顧客のペインを察知し、顧客の心中に解決策のビジョンが(自社の製品に合致する方向で)形づくられるのを、助けることなのだ。これがボスワースの主張である。そして、顧客のビジョンを誘導するために、“ナイン・ボックス”、“ペイン・シート”、“パイプライン管理”などの、非常に実践的なツールを用いる。これが「ソリューション・セリング」の仕組みである。

私はこの本を、大学時代の先輩から薦められて読んだ。この先輩は技術者で、博士号まで取った人だが、外資系の会社に転身するときに、「技術開発はつねに本国がリードする。外資系で上に行きたければ営業に徹するしかない」と考えて、営業職を選んだという。そして、「ソリューション・セリング」に書かれた技法をそのまま実践して、見事な成績を上げ、とうとう日本法人のトップまでたどり着いた人だ。

私もまた技術者だが、営業力の無さに苦心している。そして、ご多分にもれず、“良い製品なら顧客は買うはずだ”という過信に陥っていた。本書は、その蒙を開いてくれた。そして、顧客の中に具体的なビジョンを形づくることを、今は第一に考えるようになった。本書は販売に関心のある全ての人に薦められる良書である。

ただし、残念ながら、この日本語訳は今は品切れになっているようだ。私は古本で入手した。もっとも訳文はこなれているものの、ケアレスな点が目につく。原文はそれほど難しくないので、英語が苦にならなければ原書を読む方がいいだろう。
# by Tomoichi_Sato | 2006-04-11 20:21 | 書評 | Comments(0)

必要な人はいつもたった一人しかいない-その理由と帰結

個別受注生産におけるスケジューリング問題を根本から解決したければ、製品設計において、バリエーション・リダクションの方針を導入する必要がなる、と前回書いた。

ところで、これを書いていながら、ふと思ったことがあった。それは、バリエーション・リダクションのような方針変更はかなりラディカルな変革であり、しばしば設計部門・原価管理部門・営業部門など本社サイドからの、強い反発にあうということだ。

設計技術者にとっては、個別仕様に対してぴったりの最適設計をすることが、自らの誇りである。モジュールの組み合せで仕様を実現する場合、ぴったりの数字にはならず、9.5馬力でよい所に10馬力の駆動部をもってくるようなことになりがちである。仕様上の余裕があれば、その分、コストも上がることになる。そう、原価管理の担当者は考えるであろう。そうなれば価格競争力が落ちて、競合他社に負けかねない、と営業部門は恐れるだろう。

では、個別最適設計方針がつづけばどうなるか。設計の工数はかさむばかりだし、営業の手間も減るまい。が、本社部門の人件費は販売管理費に含まれる。販管費比率が高い責任は、誰も問われない。生産リードタイムが長いと、工場の年間生産能力は伸びない(1台作るのに1ヶ月かかれば年産12台だが、それが2ヶ月になれば6台しか生産できない)。しかし、工場長以外の誰がそんなことに責任を感じるだろうか? みな、自分の持ち場で最善をつくしているだけなのだ。

そうなると、結局困るのは経営者である。販管費が同業他社より高ければ、人員削減を考えることになる。製造に問題があれば、安い海外部品を調達するか、あるいは工場ごと中国に移してしまえ、という結論になる。では、その結論がもたらすものは何か? いいたくはないが、安易な海外展開での製造品質やリードタイムの行方は、火を見るより明らかだろう。だから、ゆっくりとではあるが、その事業部門は顧客の信頼も失って行く。そして、事業部門自体が撤退の対象になりかねない。こうして、長時間労働に耐え、最善をつくした多くの人たちが職を失うのだ。

極端すぎる議論だと思われるかもしれない。だが、これこそ過去5年間、日本の製造業で起こってきたことではないか。

いいかえるなら、ここには根本的な矛盾がある。技術者の仕事とは、「業務の設計・改善」それ自体を、主要な一部として含んでいる。それはつまり、仕事に関して『代替可能性を高める』ということだ。だから海外展開が可能になるのだ。しかし、代替可能性が高まるほど、それは技術者個人から、アイデンティティの根拠を奪っていく。

その結果、どうなるか。技術者はあらゆる機会をとらえて、個別な・特殊な・些末な・例外的な・だが重要な(少なくともそれ無しでは不便な)仕事を、自分のために作りだしてゆく。彼(彼女)個人がいないと、ビジネスが回らないようなものに仕立て上げてゆく。ルールを定めるのが本来の仕事なのに、例外事象ばかりを増やしていくのだ。

こうして、会社の業務は、外部のシステム・アナリストがちょっとやそっとでは分析できないような、複雑な処理系になっていってしまう。ERPパッケージをもってくれば、仕事が効率化・加速化できるなどという幻想は、例外処理の藪の中でいつのまにか崩壊していく。ルールや標準プロセスが混乱すれば、はびこるのは根性論ばかりになる。マネジメントの仕事は、精神主義の鼓舞になっていく。

このように、技術者に代表されるホワイトカラー階層とは、自分のスキル上の価値に固執するあまり、長期的には自分の存在基盤自体を掘り崩すようなことをしがちである。これが、経済合理性を追求するための組織であるはずの会社を、合理性からひきはなす効果をもたらすのだ。

この矛盾をとくにはどうするか。簡単なことだ。ホワイトカラーが、会社での仕事だけにアイデンティティの根拠を求めなければいいのだ。会社もあり、家庭もあり、それ以外のプライベートもあって、はじめて人間は全体性を保つ。家族にとって、コミュニティにとって、ある個人がかけがえのない、たった一人しかない存在であることこそ、大事なのだ。それを、ただ一ヶ所、会社にだけ仮託しようとするから、訳が分からなくなるのである。

ただし、そうなると、知的労働者は、もっと別の難しい問題に直面することになる。それは、「自分の人生の本当の目的とは何か」を考える、という問題である。たしかにこれは難問だ。とくに、自分の人生が有限なものであることを、皆、うすうす知っているから、なお難しい。そんな難しいことを考えたくないから、世の中という代物は、会社を発明したのではないかと思いたくなってしまう。

この問題は、ある意味で「製造は代替可能か」の続きでもある。価値というものは全体性の中にある。その中の一部分だけを切り出して、それだけを他の代替品と単価で比較しようとする考え方は、きわめてミス・リーディングだ。現代の経営論は、そんな部分品分解論の上になりたっている。だが人間は部分品ではない。人間にとっての「シビル・ミニマム」が、現代の経営論では忘れ去られている。しかし、どこの家庭にも父親・母親は一人ずつしかいないし、それは取り替えがきく存在ではないはずだ。そう、文化の次元においては、誰にとっても、本当に必要な人は、いつもたった一人しかいないのである。
# by Tomoichi_Sato | 2006-04-01 23:29 | ビジネス | Comments(0)

バリエーション・リダクションとは何か

個別受注生産における設計・製造上の方針のこと。個別受注生産方式をとっているメーカー(産業機械などに多い)にとって、部品点数の無制限な増加はつねに悩みの種である。部品点数の増加は、同時にBOMと工順の増加、部品在庫量の増大、発注リードタイムの増大、設計手数と図面枚数の増大など、数々の問題をもたらす。

規格の決まったカタログ部品は、ある程度見込みで生産するため、サプライヤー側も在庫がある。したがって発注リードタイムは短い。しかし個別仕様の部品はどうしても納品までのリードタイムが長くなる。つまり、製品の多様性と、発注から入手までのリードタイムとの間にはトレード・オフの関係があるのだ。多様で細かい注文が可能な製品の入手リードタイムは長く、カタログ的にパターンの決められた製品は入手がはやい。

逆に考えると、もし購買のリードタイムを短くしたければ、製造に使う部品や資材をパターン化して、種類を少なくした方がいい、ということが分かる。そうすれば生産の全体リードタイムがかなり短くなる。リードタイムが短くなれば、年間の生産能力も上がる。

しかし、個別設計の機械部品の場合、ボルト・ナットや一部の計器などの汎用部品は共通化できるが、あとは中核部品も周辺部品も、種類は同じでもサイズはほとんど別物になってしまう。ほとんどの部品は毎回、仕様を決めては発注し直すわけである。製品種類は多様なのに、部品の種類だけを減らすことなんかできない、と考える人が多い。

それでは、どうするか。このために登場するのが、モジュール化によるバリエーション・リダクションだ。これは、多様な製品を生み出すために、組合せを使う手法である。

たとえば、100種類の製品を作るために100種類の部品を毎回設計しなおすかわりに、10種類の部品群と10種類の部品群の組合せで実現する。こうして、部品の種類は20種類におさえながら、かけ算で100種類の製品を可能にできる。これがモジュール化の力だ。これを実現するためには、部品群の設計において、ある程度グループ・テクノロジーを使う必要がある。これは金属加工部品を念頭においていえば、部品をなるべく共通の母型から削り出すように設計する方式だ。

しかし、ちょっと待てよ、と思う方もいるだろう。理屈の上では、組み合わせて100種類作れるとしても、客先の注文にぴったりあうとは限らない。性能の点で余裕がでたら過剰仕様になるではないか? これは、そのとおりである。余分な性能は、その分よけいにコストがかかることを意味する。それに、設計のやり方もがらりと変えなければならない。

これに対する回答は、こうだ。お金の時間的価値(The Time Value of Money)の観点から見れば、材料費のアップよりも、設計時間や生産リードタイムの短縮の方が、ペイすることが多い。その条件は企業によりまちまちだが、算定することができる。ペイすると分かったら、バリエーション・リダクションを導入するべきだ。そして、たいていの企業では、このお金と時間のバランス判断をしないまま、単にコスト削減だけを追っているのである。

このように、スケジューリングの問題点を深めていくと、設計による解決にたどり着くことがしばしばある。だからこそ、設計と製造の統合された企業(「設計の価値」参照)が望ましいのである。
# by Tomoichi_Sato | 2006-03-28 23:29 | ビジネス | Comments(0)

予定と実績の間のミッシング・リンク

今、米国で最も広く使われているプロジェクト管理ソフトウェアは何か? --答えは、"Excel"である。これは少し前にBostonで行なわれたProject Worldのカンファレンスで聞いた答えだ。ついでにいうと、Microsoft Projectとは、米国で最も売れており、かつ最も使われていないソフトウェアだ、とも聞いた。

MS Projectは私の勤務先でも(使いたければ)使えるが、あまり好まれていない。その理由は色々だ。ユーザ・インタフェースは親切なようでいて、一貫性がない。マウスのドラッグで工程表のガントチャートを簡単に書けるのは便利だが、どうも妙に親切すぎて、おかしな事をしばしば、しでかしてくれる。メニュー階層も分かりにくいし、印刷設定も不可思議である。

しかし、もっと根本の所で、プロジェクト・マネジメントのプロの目から見ておかしな部分がある。たとえば、MS Projectにはタスクやプロジェクトの予定終了日以外に、「期限」を設定できる。この二つは何が違うのか? またプロジェクトの終了日をずっと後ろにずらすと、何とクリティカル・パスが消えてしまう。「クリティカル・パス」というのはプロジェクトの開始から終了までの経路の中で最長のものを指す、というのが定義である。だとしたら、このソフトは、クリティカル・パスの意味を知らないのだ。

しかし、もっとも問題なのは、じつは別のところにある。MS Projectには、スケジュールの開始/終了日付が、「予定」と「実績」の二つしかないのだ。これでは困る、と、プロジェクト・マネジメントのプロである同僚たちは言う。予定と実績の間に、プロジェクトの世界ではもう一つ必要なものがあるのに、MS Projectをはじめとする多くのプロジェクト管理ソフトには、それが欠けている。そのミッシング・リンクとは、「見込み=forecast」である。

見込み日(forecast date)とは何か。これは、「現在のままでゆくと、開始日・終了日はこの日付になる」と判断された結果だ。今、設計のタスクを遂行中だとしよう。予定では、3月の1ヶ月間で設計完了のはずだった。つづく実装作業は、4月1日から開始の予定である。これらは「予定日」だ。ところが、設計は3月10日になって、ようやく開始した。そしてまだ完了していない。だから、実績開始日は3/10で、実績終了日はまだ無い。しかし、開始が10日遅れたのだから、作業ボリュームにかわりがないとしたら、設計が終了するのは、4月9日の「見込み」(forecast)である。実装開始の見込み日は、4月10日になる。

プロジェクトは複数の人間が協同する作業である。下流工程の担当者は、自分のタスクが本当はいつ着手できる「見込み」なのか分からないと、困ってしまう。だからforecast dateは必須なのだ。これが、プロジェクト・マネジメントのプロの感覚である。

ところが、少なからぬ企業で、この「見込み日」の概念が、なぜか活用されていない(単に知らないだけなのだろうか?)。では、そうした会社では、現実を予想するのに、どうしているか。

答えは簡単だ。計画をそのたびごとに変更していくのだ。設計の着手が遅れたら、設計の予定日付も変えてしまう。こうして、何回も計画を更新していくから、計画の履歴管理が必要だ、などという要求が出てくる。しかし、この調子で計画をどんどん変更していったら、結局のところ、実績は常に計画と一致することになる。これで本当に進捗管理といえるのだろうか? 

計画のベースラインとは、めったなことでは変えないのが、プロフェッショナルのやり方である。では、変わりやすい現実にどう追随していくか。そのためにこそ、見込み日(forecast date)が必要なのだ。

ちなみに、生産スケジューリングの世界には、普通Forecast dateなどない。いらないのだ。なぜなら、製造現場の作業は精度が高いので、たいていはスケジュールどおり仕事が進んでいく。見込み日の概念がいるのは、ホワイトカラーだけだ。ホワイトカラーの仕事は、製造現場よりも精度が低い。だから、計画通り進まないのが当たり前になっている。精度が低い人たちが、不思議なことに、なぜか給料はたくさん貰っている。まあこれは余談だが。

ところで、見込み日を運用するに当たって、きわめて重要なことが一つある。それは、“見込みは誰が決められるのか”という問題である。よく、プロマネが進捗会議で担当者に対して、「その仕事はいつ終わる見込み?」と聞いたりする。この質問が意味を持つのは、回答者が『正しく予測できる能力・態度を持っている』という時に限られる。パートナー企業との共同プロジェクトや、海外ベンダーとのプロジェクトなどでは、この条件はかなりの留保つきでないと、適用できない。担当者が見込みを正しく答えられると言うのは、一企業の中だけで成り立つ、性善説だと考えるべきである。
# by Tomoichi_Sato | 2006-03-17 12:47 | プロジェクト・マネジメント | Comments(0)

必要な人はいつもたった一人しかいない

客先でのヒアリング日程が急につまずいたのは、帰る日の直前だった。見積のための概略の要件定義を進める中で、次回は工場の生産スケジューリングについて、詳しく聞きたいと申し出たところだった。その出張では、機密性の高い工場の実物見学は許してもらえなかったが、かわりに各工程のビデオ映像を見せてもらって、だいたいの様子は理解できたと思った。製造実行系および制御系システムの構成も、およそつかむことができた。あとは計画系だ。けっこうこの工場のスケジューリングはややこしいに違いない。本社からの受注オーダーに対して、どう製造指図を展開してひもづけていくのか・・・

ところが、相手方の管理者からかえってきたのは意外な答えだった。「スケジューリングはルールが複雑すぎるから、システム化しなくていいよ。」 驚いた私は、計画と実行は生産管理の両輪で、両者がかみ合わないと工場の真の能力は上がらないのだ、と説明した。そして、スケジューリングが複雑だと言うが、では、担当者は何人居るのかと訪ねた。答えは「一人」だった。では、この担当者が風邪を引いて一週間休んだら、工場はどうなるのか? そんな属人的なやり方で、主力工場を切り回していいのか。そう訪ねた。

すると、スケジューリング担当者の人減らしはとくに考えなくてもよい、と返事が返ってきた。別に人員削減を目的にシステムを提案している訳ではありません。そう説明したが、無駄だった。

その仕事は結局、受注できなかった。予算が合わない、という理由だった。果たしてそれが表向きの理由にすぎなかったのか、それは分からない。案外、実はそのスケジューリング担当者が、当の管理者の右腕だったのかもしれない。むろん詮索しても仕方のない話だ。しかし、その代わりに私は、ひとつの大きな教訓を得た。それは、「ホワイトカラーの組織では、ある特定の業務をうまく遂行できる人は、いつもたった一人しかいない」ということだ。

似たようなことを、私は要件定義のフェーズで、何回も経験している。業務プロセスのヒアリングをしていても、最初から最後までカバーして説明できる人は少ない。ある箇所になると、なにがしさんに聞かないとわからないな、という状況になり、その一個人の都合にスケジュール全体が振り回されるのだ。特定業務のキーパーソンは、つねに一人しかいない、のだ。

しかし、これはあるいは逆の方から言いかえた方がわかりやすいかもしれない。「ホワイトカラーはいつも、その人自身だけしかうまく遂行できないような、特殊だが重要な仕事を作り出すものだ」と。なぜ、そうなるのだろうか?

それは、多くのホワイトカラーにとって、仕事がアイデンティティであり、自己の価値証明になっているからだ。自己証明である限り、それは他人と違っていなければならない。他人では置き換え不可能なものでなければならない。代替可能でない物、それがアイデンティティなのだ。しかも、これはあまり明言されない。いつも内心だけのプロセスなのだ。

なぜホワイトカラーは、そんな風に無意識に信じたがるのか。工場労働者を考えてみるといい。ベルトコンベヤーで流れてきた部品にネジを締めるだけの人は、その仕事にアイデンティティを求めるだろうか。彼が居ないと成り立たない仕事だろうか。それは明らかに、代替可能な仕事だ。むろん熟練工という存在はある。しかし、工場のほとんどの仕事は、非熟練工・季節工でもそれなりにできあがるようになっている。そうなっていなかったら、それは工程設計がどこかおかしいのだ。

おわかりだろうか。マネジメントだとか、IE(インダストリアル・エンジニアリング=経営工学)だとかいった手法は、“誰がやっても70~80点の成果が出る”ように、生産業務のプロセスを組み立てるのことを目的としている。そして、ホワイトカラーの知的業務だって、同じはずなのだ。マネジメントの視点から見れば、“誰がやっても70~80点の成果が出る”ように、手法論やマニュアルや業務手順を組み立てることが求められる。

そして情報システムとは、まさにそのための目的のものではなかったか。それなのに、なぜ、そう機能しないのだろうか。長くなってきたから、つづきは次回書こう。
# by Tomoichi_Sato | 2006-03-06 00:28 | ビジネス | Comments(0)

トヨタ生産方式の神話と現実

目の前に一冊の本がある。「トヨタ生産方式を支える最適化手法に関する研究」、小谷重徳・著(2004年)と題された、冊子ともいうべき本だ。現在、首都大学東京の教授である小谷先生の博士論文である。中身を開けてみると、素人には目がちらちらする数式の羅列がつづく。主題は、輸送費用と生産制約を考慮した組立ライン決定問題である。そして、この問題の線形計画法による厳密解が、じつは整数解になる理由などが書かれている。

知らない人は、“また学者が出てきて、トヨタの実践的な手法を、妙な数学で理論化しようとしているわい”などと思うかもしれない。しかし、それは誤解だ。小谷氏がこの博士論文を書いたときには、じつはトヨタ自動車に勤務しておられた。つまり、このいささか難解な数学は、この会社の生産計画を支える基盤なのだ。これがトヨタ生産方式の現実(あるいは、そのすごさ)なのである。

ビジネスの世界では、ときに奇妙な神話や誤解が流布することがある。中国生産はコスト低減の切り札だ、といった神話だとか、ERPを導入すると在庫が削減できる、といった誤解である。思うに、企業は自社の内部事情をあまり公開しないから、素人評論家の噂話や職業コンサルの意図した誇張が、まかり通りやすいのではないか。

最近はやりの神話はトヨタ生産方式にかかわるものだ。なにしろトヨタ自動車の業績が信じられぬほど好調だから、周囲の見る目が神様あつかいになるのも、いたしかたあるまい。そのトヨタについて、もっとも広く流布している誤解は、「トヨタ生産方式はプル型の受注生産で、生産計画など持たない」というものだろう。じっさい、元町工場の見学コースは、『かんばんと自働化こそトヨタ生産方式を支える二大要素』とビデオで見せてくれる。生産計画の文字はどこにも見あたらない。ましてや線形計画法などは。

「神様ではあるまいし、誰も先の需要などは読めない」--これはトヨタ生産方式を築いた大野耐一氏の言葉ではなかったかと思う。「だから生産計画など作ってもあてにならない。現実の需要変動に耐えうる工場を作るべきだ」・・論理は、そうつながりやすい。そして、「そのためにはカンバンを中心としたプル型生産の体系とするべきだ」との信念が生まれていく。こうした“信念”をもとに、『計画はずし』を指導するコンサルタントも少なくない。トヨタOBの中にも、そうした人たちがいると聞く。

ところで、上記のテーゼはトヨタ系列の部品メーカーには合致するかもしれないが、トヨタ自動車自体には当たらない。彼ら自身は、きちんと生産計画をたてて実行しているのだ。そうでなければ、お得意の「平準化」をどうやって実現できるというのか。トヨタ生産方式の中核は平準化にある、と私は銀屋技監から直接うかがったこともある。たしかに、作るべき計画台数がなければ、平準化などもともと出来ない相談である。

では、なぜ、「計画不要論」がトヨタの名前と結びついて広まったのか。私は一つの仮説を持っている。それは、自動車業界のサプライチェーンの特徴から説明できる。自動車の世界では、販売チャネル(ディーラー網)は、生産メーカー別に統制されているし、また部品生産も系列化されている。つまり、長いサプライチェーンのちょうど中心に、自動車メーカーがいるわけだ。そして、だからこそ、このサプライチェーンでは計画の意志決定はたった一ヶ所で行えるのである。

これは、たとえば電子・情報機器業界などと比べてみれば分かる。パソコンやデジカメは自動車とならんで、日本の製造業のもう一つの花形である。しかし、これらの商品は、チェーンストアやディスカウント店などが販売を仕切っている。店頭にはキャノンとソニーと東芝の機種がならぶ。これは自動車販売とは全く別の世界だ。販売の主導権は流通業界が持っているために、電子情報機器のサプライチェーンでは、意志決定ポイントが最低でも2ヶ所(流通と組立生産)になってしまうのだ。

部品サイドで見ると、自動車ではカローラのシートをフィットに乗せるわけにはいかないから、部品生産は必然的に系列化されやすい。一方電子業界では、電子部品は互換性が高い。だから系列でしばりにくい。こうして、部品メーカーもまた計画が必要になる。

くり返すが、自動車のサプライチェーンでは意志決定ポイントは一ヶ所で十分なのである。むしろ部品メーカーが勝手に、車両メーカーの計画を無視して、余計な生産計画などを立て始めたら、余計な在庫が発生しコストアップにつながる可能性が高い。だから、「考えるのは自動車メーカーのみ。あとの部品メーカーは、その計画に従うように制御されていればよい」という論理が成り立つ。その制御のツールとして、『引取りカンバン』が使われるのだ(今はほとんど電子化されているが)。

おわかりだろうか。『生産計画不要論』は、自動車業界で、部品メーカーにとってのみなりたつ論理なのである。この前提条件を理解せずに、どこの業界に対してもドグマとしてふりまわせば--それはもはや、神話とよぶべきものだろう。

(線形計画法に興味のある方は、小谷重徳・他「輸送費用と生産制約を考慮した組立ライン決定問題」日本経営工学会論文誌、54-4(2003)をご覧になるとよい。これは平成15年度日本経営工学会論文賞を受賞している)
# by Tomoichi_Sato | 2006-02-24 00:49 | ビジネス | Comments(2)

プロジェクト制の要件

ソフトブレーン(株)の会長・宋文洲氏はいつだったか、持論のプロセス・マネジメントに関連して、「プロセスは線路で、プロジェクトはそこを走る個別の電車である」と言われたことがあった。これはなかなか面白い喩えだと思う。プロセスはいったん路線を引いたら固定して変わらないが、プロジェクトは運転手も、乗せている客も毎回違う。行き先だって変わることもある。“だからプロセスの設計が重要なんだ”というのが宋さんの立論である。

しかし、これはある意味では例外的なケースだとも考えられる。通常の製造業においては、まず「プロジェクト」という仕組み自体が確立していない。製品開発や受注生産といった個別の『案件』は、たとえば

企画→設計→試作→生産技術→購買→製造→物流、

という複数の機能部門の中を、上流から下流に向けて流れていくケースがほとんどだ。言いかえれば、縦割り組織の中をバケツリレーのように受け渡されていくわけだ。普通の電車の運転手は終点まで変わらないが、縦割り組織のメーカーは、ひと駅ごとに運転手が交替する鉄道に似ている。

むろん、それでずっとうまく行っているならば、何の問題もない。しかし、製品開発や個別受注生産は、複数の機能部門が関わり合う、クロス・ファンクショナルな活動である。業容を拡大したり、短納期化を進める状況下で、複数の案件が並行して進むとき、ボトルネックの作業負荷を誰が調整するのだろうか? 部門を統括する上級マネジメントか? しかし、個別の案件で設計と購買の鞘当てが起こるたびに、いちいち事業部長が介入して調整するわけにもいくまい。

たとえば、既存の部品を転用すれば、早くできるのは分かっているが、しかしオーバースペックで高いものにつく。今回用に注文し直せば安く上がるが、とうぜん手配に時間がかかる。製品出荷の早さ(納期)をとるか、製品コストを取るか。製品開発は常にトレード・オフに直面するものだ。決断には責任がともなう。誰がそのリスクをとるのか?

答えは明らかだ。プロジェクト・マネージャーが必要なのである。納期とコストの双方に最終的な責任をもつ、プロマネが判断すべきだろう。そして、そのためには、社内でまず『プロジェクト制』の確立が必須になる。バケツリレーがこんぐらがって、もう限界に達したな、と思ったら、それはプロジェクト制を導入すべき時期なのだ。

プロジェクト制、というと、なぜだかすぐ「社長直属プロジェクト」を想起する人が多い。しかし、ここではそんな、“社運を決する一大プロジェクト” だけを考えているのではない。始まりがあり、明確なゴールがあって、複数の部署の人間が協力して成し遂げなければならない仕事(しかも失敗の可能性もある仕事)は、「プロジェクト」として公式に扱おう、と決めるのだ。

プロジェクト制の要件はいくつかある。まず第一に、プロジェクト・マネージャーの指名である。プロマネに、品質・納期・予算(QCD)に関する最終的な権限と責任を与える(人事権までは与える必要はない)。

予算に責任を持つためには、プロジェクト予算体系を確立しなければならない。これを支える仕組みとして、プロジェクト番号制が望ましい。プロジェクト番号をキーとして、日報による社内人件費把握や、外部費用のプロジェクト別把握ができなければならない。

誰をプロジェクト・マネージャーに任命すべきかも、悩ましいところだろう。企画部門かもしれないし、設計部門かもしれないし、生産技術部門から出すのがいいかもしれない。タスクフォース(「工務店」型)組織か、マトリクス(「置屋」型)組織かによっても、答えは違う。だが、いずれにせよ、プロジェクト・マネジメントに関する基礎的なトレーニングは必須だろう。固有技術と、管理技術は違うからだ。この点を忘れると、プロジェクト制など、すぐに絵に描いた餅になってしまう。

スムーズな製品開発や個別受注生産にとって、「プロセス」は必要条件だが、十分条件ではないのだ。最後まで決定に責任を持つ「運転手」=プロジェクト・マネージャーが望まれるのだ。
# by Tomoichi_Sato | 2006-02-19 23:46 | プロジェクト・マネジメント | Comments(0)

PMOが最も必要とされる場所

先日、PMI東京支部のシンポジウムにパネラーとして招かれ、参加させていただいた。テーマは「PMOはPMクライシスの救世主になれるか」で、PMO組織への期待論が中心だった。参加者は私の他に、Johnson & Johnsonのマーケティング部門の方、そしてUNIYSの方で、司会進行役がIBMの神庭さんである。外資系メーカー・エンジニアリング業界・IT業界それぞれの観点から、興味深い論議になったと思う。

PMOはProject Management Officeの略語である。複数のプロジェクトを統括してマネジメントする専門部署、というほどの意味だが、最近はどうやら流行の3文字略語になってきたらしい。例によって米国で広まりはじめ、すぐわが国にも飛び火した。おそらくシンポジウムの聴衆の中にも、PMOの名刺を持つ方が少なからずいらしたに違いない。

ところでパネル・ディスカッションが進むにつれ、このPMOという組織の位置づけについてのすれ違いが明らかになってきた。それは、簡単に言うとPMOがラインを主導するのか、あるいはスタッフとして支援に徹するのか、その違いである。あるいは、プロマネはPMO部門に所属するのかしないのか、という違いだと言ってもいい。

ちなみに、私の勤務先である日揮は、PMOという名前の組織はない。プロジェクト本部という組織があり、それとは別にエンジニアリング本部という機能別組織(電機・機械・化学・建築・制御・シビル等の設計者集団)がある。プロマネはプロジェクト本部に属して、各案件(プロジェクト)ごとに機能別組織の横串を通すマネジメントを行なう。つまり、典型的なマトリクス型組織である。

マトリクス組織のプロジェクト・チーム員は、機械エンジニアなら機械専門部の部長が上司であり、固有技術はその部長が統率する。プロマネは、管理技術に徹するわけだ。ここでは固有技術と管理技術は独立して、車の両輪となっている。

ところが、IT業界のSIerは、タスクフォース型組織をとる会社が殆どである。タスクフォース型組織では、プロマネはプロジェクト・チーム員の上司に当たる。つまり、固有技術と管理技術の両方を、ある意味では同じプロマネが面倒を見なければならないわけだ。しかも、SIerでは、プログラマ→SE→サブ・リーダ→プロマネ、というようなキャリア・パスが多い。固有技術者が進化して、管理技術のマネージャーになるという、ポケモンの進化論みたいな変身が要求される。

だからこそ、管理技術の中心であるPMOの確立が「救世主」として期待されるのだろう。PMI東京支部は、IT業界の参加者が圧倒的に多い。パネル・ディスカッションのテーマも、その問題意識が反映されたのだろう。

しかし、タスクフォース中心型組織(私はこれを「工務店方式」と呼んでいる)では、プロマネはPMOの所属にはならない。したがって、PMOは必然的に支援型スタッフになる。これで複数プロジェクトを統括管理できるのだろうか? まあ、指揮系統から言ってかなり困難だろう。もし、無理にそうした役割をPMOに期待するとなると、こんどはPMOが『本社』、各プロジェクト・チームが『工場』、みたいな関係にならざるをえない。

その場合、PMOを「頭でっかちの本社組織」にしないための工夫と制限が必要だろう。ひとつの方法は、現場と人を定期的に入れかえることである。つまり、PMO勤務経験をプロマネの必須のキャリア・パスとする。また、プロジェクト実務経験者を、PMOに転属させる。要するに、固有技術と管理技術の『両刀使い』を養成するしかない。

もともとPMBOK Guideの原型は、エンジニアリング業界や航空宇宙業界の出身者が中心になって作られた。こうした業界は機能別組織が発達している。一方、IT業界は、構造的にそういう社内体制になりにくい。米国PMI風の発想が、どうしても日本ですれ違いを生みやすいのはこのためだろう。

私の見るところ、PMO組織の確立がもっとも成功するのは、じつはSIerでも建設・エンジニアリング業界でもない。製造業・流通業における、新製品開発や上市などのプロジェクト管理である。なぜなら、こうした仕事は、必ず複数の機能部門の協力を必要とする。営業企画・研究開発・製品設計・生産技術・購買・マーケティング・物流・・等々である。しかも、こうした仕事は、たいていの場合、「プロジェクト」として位置づけられておらず、単に「案件のバケツリレー」でこなされているからだ。予算についても、スケジュールについても、誰も本当の意味でのコントロールをしていない。

このような縦割り組織において横串を通し、『プロジェクト制』を確立し、効率よく短期間で製品開発・上市を進めていくためにこそ、PMOという部門が役に立つのだ。じじつ私も、最近はこうした製品開発プロジェクトのマネジメント・システム導入をお手伝いすることが増えており、かつその効果が大きいのも見てきている。

PMOは、製品開発にとってこそ「救世主」なのだ。もっとも、まれに単なるプロジェクト・チームをPMOとよんでいるケースもあるようだ。これは遂行と統括マネジメントの区別がされていないのだろう。誤解だと言うべきなのかもしれない。
# by Tomoichi_Sato | 2006-02-08 01:22 | プロジェクト・マネジメント | Comments(0)

特別な我が社

考えるヒント、2001/2/03より)

ITコンサルタントの仕事をしていると、つくづく面白いと思うことがある。仕事柄、さまざまな企業を訪問して話を聞くわけだが、訪れる会社はどこも、「自分のところの業務はひどく特殊だ、ウチは特別な会社だ」とおっしゃるのである。どの会社もどの会社も、“これこれの理由でウチはよその会社とちがう”と主張される。

いわく、「ウチの業種の製品は鮮度管理が非常にきびしいから」「ウチの製品はお客様の生命に直接かかわるものだから供給の責任があって」「ウチの業種は可燃物を大量に取り扱うので消防法のこうるさい設備検査が必要で」「ウチの業界はものすごい多品種少量で、かつ製品のライフサイクルがめちゃくちゃ短いから」「徹底したカンバン方式で工場を回しているから」「完全受注生産でリードタイムが長いから」「小さく高価で壊れやすいから」「場所ふさぎなのにひどく安価だから」etc...

“というわけで、外部の方には我々の問題の難しさはご理解いただけにくいでしょうねえ・・”と続く。

そして結論はというと、
「だから平均的な製造業向けにつくられたパッケージ・ソフトではウチの仕事はうまく取り扱えない」
という風に誘導されるのだ。特殊性を強調されたあげく、ほとんど判で押したかのように、同じ結論にたどり着くところが面白い。

そんなことはないのである。

この仕事をやってみるとわかるのだが、日本の製造業が抱えている問題点というのは驚くほど共通性が高いのだ。それは、非常に圧縮した形で表現するならば、『大量・見込み生産の体制を残したまま、多品種少量の受注生産に移行しようとしている』ということになる。だから調達から販売までのサプライチェーンのあちこちで、プルとプッシュが混在しているのである。

したがって、解決の手法も一つの事例できちんと確立してしまえば、あとはかなり応用が利く。若いコンサルタントでも、見習いで3社の事例をやってみたら、4社目からは中核の問題を自分で見つけることができるようになる(むろん、応用問題を解くにはその業種の個別知識と、人を動かし説得できるだけの知恵がいるから、経験もなしにすぐに独り立ちできるわけではないが)。

「パーキンソンの法則」で有名な経営学者C・N・パーキンソンは、「コンサルタントの仕事はミツバチに似ている」と言っている。花から花へ、花粉を運ぶ蜜蜂のように、コンサルタントはある会社で見つけた知恵を別の会社に運んでそこに植え付ける訳である。自分自身では花粉を作り出したりしない(知恵を生み出したりしない)点が面白い。こう書くと怒り出す人もいるだろうが、かなりの程度、真実に近い。

個別性・特殊性の強調は、なんとなく日本の文化に根ざしているのかな、とも思う。丸山真男が『日本の思想』で分析して見せたように、日本では「理論信仰」と「実感信仰」が表うらの関係で支え合っている。外国から直輸入した公式的理論によって現実をばっさりと切ってしまうような風潮と、逆にその防御として、個別の事象・実感をならべたてて共通論理をいっさい否定してしまう態度。まるで「パッケージに業務を合わせろ」「いや業務に合わせてすべてカスタマイズしろ」という水掛け論を聞いているかのようではないか。

面白いことに、私のつきあった範囲では、欧米の会社からはあまりこういう「ウチは特殊だから」論は出てこない。それも当然だろう。彼らはそもそも、みずからの独自性を前提として生きている。一人一人に個性がある、というところから思考は出発する。その上で、個別の事物を包含するイデアが存在する、というのが西欧の哲学だからだ。

哲学抜きで特殊論にしがみつく国には、ただ“諸行無常”の風が吹くだけかもしれない。
# by Tomoichi_Sato | 2006-02-01 22:39 | ビジネス | Comments(0)