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

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

個別受注生産における設計・製造上の方針のこと。個別受注生産方式をとっているメーカー(産業機械などに多い)にとって、部品点数の無制限な増加はつねに悩みの種である。部品点数の増加は、同時に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)