タイム・コンサルタントの日誌から（2002年）
Christmasメッセージ －－ 平和の果実 （2002/12/24）
Time is Money （2002/12/15）
プロジェクト・コラボレーション・ツールに望まれること （2002/11/07）
Windows 497日問題とMES （2002/10/30）
アーンドバリュー分析の落とし穴 （2002/10/20）
AspenTechはどこにいくのか （2002/09/27）
ＢＯＭはなぜ一元化できないか （2002/09/16）
電子カタログの夢と現実 （2002/08/31）
サプライチェーンは電子カタログの夢を見るか （2002/07/21）
Web Servicesと子守り歌 （2002/07/03）
ドットコム・エコノミーの後に来るもの （2002/2/15）
Christmas メッセージ
— 平和の果実 （2002/12/24）
Merry Christmas!!
Apple to orangeという言い方をご存じだろうか？ Don’t compare apple to orange、のように使う。ものごとの比較をする時に、リンゴならリンゴ同士、同種のものでなければ優劣を決める事ができない、という意味だ。リンゴ１個とオレンジ１個、種類の異なるものを並べて、値段や大きさを比べるのはおろかだろう。比較は同じ土俵の上でなければならない。
したがって商取引において、買い手はつねにapple to appleになるように、売り手達に条件をつける。仕様はこれこれ、性能はこれこれ、取引条件はこれこれ、という具合だ。こうして横並びにしておいて、最終的には一番価格の安いものに発注する。これが世の中の通常の仕組みだろう。
これに対して、売り手がとりうる方策は二つある。価格競争で勝負するか、さもなくば同じ土俵に乗せられないように、製品に他にない特徴をつけて「差別化」するかだ。いわゆる差別化戦略というのは、買い手がapple
to appleに持ちこむ無慈悲な経済原理を逃れるための方策なのである。
ところで、はたしてリンゴとオレンジは本当に別モノなのだろうか？ 両者は広い意味では同じ「果実」という範疇に属している。スーパーの仕入れにとっては重大な違いだが、産業統計を見るエコノミストにとっては、両者の区別にたいした意味はない。つまりあるモノを同一カテゴリーと見るか、別モノと見るかは、視点によりけりなのだ。相似と相違とは、相対的である。微視的にみれば別でも、巨視的には似ている。違いをいう事ができるのは、両者に似た点があるからなのだ。つまりカテゴリーのとり方は、おおげさに言えば、世界観のあらわれなのである。
ＳＣＭとかマテリアル・マネジメントを語る場合には、カテゴリーというものの相対性を忘れてはならない。現代のたいていの（まともな）ＩＴツールは、品目やサービスのカテゴリーをツリー構造の階層で定義できるようになっている。しかし、複数のツリー構造を共存させたり、共有したりできるものは少ない。もしサプライチェーンに参加する複数の部門・企業が異なるカテゴリー構造をもっていたら、どこかで調整を行わなくてはならない。
そして実は、これが至難のわざなのだ。ＳＣＭ実現の過程で、非常にしばしば我々はこのコンフリクトを目撃する。それはテクノロジーの問題ではない。結局のところ「世界観の擦り合せ」であり、そこにはそれぞれの組織が背後にもっている文化の衝突がある。そして、それは非常にたやすく、感情的な対立にエスカレートしていく。
なぜ同じ目的とゴールを共有しているはずの組織の間に、このような現象が起こるのか？ それは、異文化接触のスキルがたいていの人に欠落しているからだ、と私は思う。私達が会社員になって以来、残念ながら一度として、異文化理解のためのトレーニングを受けたことがない。私がたまたま何かを知っているとしたら、それはすべて痛い思いをして学んだ事ばかりだ。
私達の世界は、確実に小さくなってきている。もはや他の部門、他の会社、他国の人達とつきあわずに仕事を進めて行く事は不可能に近い。だとしたら、今、何よりも必要な事は、文化の違いを理解しながら、障壁を乗り超えて進んで行くための基礎的なトレーニングではないか。これは、学ぶ事ができるスキルなのだ。
サプライチェーンは、世界が平和に共存できている時に、最良の価値を発揮する。ＳＣＭは平和の産物、平和の果実である。このクリスマスの季節において、私は、より多くの人が、異文化と共存できるスキルを磨けることを切望する。そして、広く地上に平和な時間が訪れる事を、天に祈りたい。
ほぼ同等の品物ならば、安い方を買う－－たいていの人は、こういう経済原理で動いているはずだ。そう考えるから、メーカーは１円でも安い製品を売り出すために、懸命な努力を重ねつづける。より効率的な生産方式と工場設備、より安価な労働力、より廉価な部品・原材料を求めて・・・。そうした努力が、しかし結局、何をもたらしたか？
最終製品メーカーが安価な部品を求めて海外生産・海外調達に急速にシフトしたため、国内の部品メーカーは追いつけずに、大きな打撃を被ることになった。国内製造業の空洞化現象である。今のところ、それでも最終組立ラインは日本国内に持っているメーカーがほとんどだが、それさえ次第に変わりつつある。某大手自動車メーカーが最近タイ製のモデルを輸入販売しはじめたことは、そのはっきりした兆しの一つかもしれない。
しかし、本当にいつでも安い製品・部品を買うべきなのか？ そうした問いを、立ち止まって考える人は、あまりいないようだ。実は、答えは「ノー」である。高い製品の方がいい場合があるのだ。いや、高品質・高価格、という詰まらぬ話をしているのではない。ほぼ同等な仕様でも、高い方が選ばれる場合があるのである。
世の中には客先の注文を受けて作るような商品、つまり一品受注生産の市場がある。大型の産業機械や建築・設備、情報システムなどがそれで、筆者の勤務先であるエンジニアリング会社の商売（プラントの設計・建築）も、その典型の一つである。こうした一品受注生産の業種では、買い手は「価格」以外に重要な評価項目を持っている。それは「納期」である。そしてしばしば、納期は価格以上に重要になる。
なぜ買い手にとって「納期」が重要か。それは、こうした品目が「生産財」であるからだ。買い手は、自分自身が何らかの生産行為をはじめるための必要条件として、こうした生産財を注文している。モノが早く納入され工場やシステムが完成すれば、それだけ自分は早く生産を開始できる。それは買い手自身の競争にとってきわめて重要な意味を持つ。ときに、いや、ほとんどしばしば、B2Bの生産財の世界では“どれだけ早く生産を開始できるか”の方が、“どれだけ安く生産設備を入手したか”よりも、マーケットの競争にうち勝つのに、大きな貢献をする。たとえ工場の建設費が１割高くても、他の競争相手よりも３ヶ月先に生産体制に入れれば、大きな利益を手にできる－－こうした数字の比較は、生産にたずさわるプロジェクト経済分析を冷静に行なえば、明らかなことなのだ。
それにもかかわらず、ほとんどの生産財メーカーが安値競争のたたき合いで受注しようと必死になる。愚かなことではないか。他の競合相手と納期が同等だったら、むろん安い方が良いに決まっている。問題は、そんな価格の土俵に上がって仕事をとろうとする、営業戦略のあり方そのものにあるのだ。
もしも、戦略を「より安値」ではなく、「他より高くても良いから、劇的な短納期を」と設定し直すことができれば、ドラスティックな発想の転換ができる。生産財メーカーは、安価だが納期の不確実な海外資材調達より、品質が良好で確実に納期が早い日本のサプライヤーからモノを買う方が有利だ、と考えるようになるだろう。安値の労働力を求めて、むりやり詳細設計の作業を中国やインドに発注する必要がなくなることに、気づくだろう。コミュニケーションのスピードや正確さからいって、気心の知れた日本人同士、母国語でしゃべるのが一番いいに決まっている。面倒な契約文書も通関手続きもみんな不要だ。
そして、何よりも、他より高価格でモノを売れる。確実に利益を手にすることができる。タイム・イズ・マネー。解くべき問題は、いかに低価格、ではなく、どうすれば時間を買うことが出来るのか、になってくる。これはもう、ほとんどコペルニクス的な視野の転換をもたらすのである。
ところで、じつは消費財の世界でも、やはり“Time is Money”の原則が存在する。こちらは、商品の短納期ではなく、「いかに需要変動にすばやく追随するか」という課題である。そして、この種の“時間の悩み”には、APSを用いた生産スケジューリングが最大の特効薬である・・これこそ私がずっと主張しつづけていることだ。
しかし、かりにAPSで工場内の手番が多少は速くなったとしても、部品調達に時間がかかっていたのでは何もならない。そして、「なぜ部品の手配がこんなに遅いんだ！？」「はい。安い部品を中国から調達しているので、しかたがないのです。」という問答が企業内で繰り返されているようでは、スピードなど絵空事だろう。サプライチェーン全体の機敏さをどう生み出すか、が鍵なのだ。
もう一度、繰り返そう。時間こそ収益の鍵である。そしてこの問題を解決できれば、１億２千万人が路頭に迷うのを、確実に防ぐことができるはずなのだ。
プロジェクト・コラボレーション・ツールに望まれること
（2002/11/07）
最近のプロジェクト・マネジメントに対する注目と歩を合せて、企業間で使うプロジェクト・コラボレーション・ツールがいろいろと登場してきた。どれもWebベースでインターネット上で動き（これは当然の技術的トレンドだが）、同一プロジェクトに関わる複数企業が情報交換をする基盤を提供する。ASP（Application
Service Provider）のビジネスモデルのものも多い。中には無料のサービスもある。
エンジニアリング企業という、典型的なプロジェクト中心の会社に勤務している関係上、この種のツールには以前からかなり興味をもって見てきた。一時、電子市場の多くがコラボレーション・プラットフォームを指向してこの方向に動き出したが、ネットバブルの崩壊とともに、かなり消滅してしまった。これに対して、調達ではなくプロジェクトに焦点をあてるのが、最近出てきたものの特色だ。これには建設省（現・国土交通省）がPMや建設CALS/ECにお金を出してきたことも、追い風になっているのだろう。
ちなみに、私自身が昨年来、開発に関わっている電子市場epc-business.comは、基盤ソフトウェアとしてOracle社のPDX（Product
Development Exchange）を利用しているが、これも別名Project Exchangeというように、プロジェクト・コラボレーション・ツールの一つである。以前、「e-CollaborationにむかうOracle」で書いた流れから開発された製品だ。もっともOracle社は気が変わりやすく（機を見るに敏ともいう）、Exchangeモデルはもうやめた、PDXももう捨ててERPのe-Business
Suiteにコンバートする、と言い出し、ユーザみんなの頭痛の種になっている。
ところで、私の考えでは、この種のツールが実用になるためには、必ず備えなければいけない条件がいくつかある。
まず第一に、技術的なことだが、Fire Wallを越えられることだ。あたりまえのようだが、各企業のオフィスはそれぞれF/Wで守られている。HTTP以外は、POPやFTPさえ許さないところも多い。したがって、特殊なプロトコルやPort番号、Appletなどを使わず、F/W,
Proxy, NATを通過できる仕組みでなければならない。
つぎに、アクセス権管理が重要だ。アクセス権が管理できないようでは論外だが、ユーザ別・文書別に全部を手動設定、では、大きなプロジェクトには使えない。グループ定義やフォルダの定義にテンプレートを利用できることが実用の条件だろう。また、ユーザの分類は単純な階層構造ではなく、マトリクス型のアクセス・セキュリティ・モデルが必要だ。
この種のツールは文書の共有が最大の売り物だが、バージョン管理機能を欠いたツールはISO-9000の精神から見て落第だから、お仕事には使えない。ま、あなたがISO-9000を愛しているかどうかは知らないが、これはマック・フライド・ポテトのケチャップのように、いらなくてもつきまとってくるものなのだ。また、文書のインデックス機能も必須だろう（もっとも、プロジェクトにおける文書インデックスの意味さえ知らないソフト会社が多いのだから、この部分はほぼ絶望だが）。
さらに、プロジェクト・タスクの実績入力の自動化が大きな課題だ。いわゆる実績系の機能である。キーとなる設計文書がワークフローで承認されたら、設計作業のマイルストーンが自動更新される、というような。もしタスクの進捗を全部手で入力しなければいけないようだったら、だれがそんなツールを喜んで使うだろうか。
（ついでにいうと、なまはんかなプロジェクト・プランニング機能は不要だ。PERTやCPMをやりたかったら、我々だったらリソースの負荷分散まで自動計算してくれる、Primaveraなどのきちんとしたプロジェクト・スケジューリング専門ツールを使うだろう）
いろいろと書いたが、今の市販のツールを見ると、みなプロジェクト型の企業間コラボレーションを甘く見ているとしか思えない。ＩＴ屋さんは、Web対応ソフト＝コラボレーションという誤解をしているらしい。あいにく、企業間コラボレーションは情報技術の問題ではない。利害の反するもの同士の調整とかけ引きの場所なのだ。複雑なツールばかりを持ちあげる気はないが、Web上のファイル共有ていどで協業関係を築けるくらいだったら、プロジェクトマネージャなど誰が苦労するだろうか。
Windows 497日問題とMES
（2002/10/30）
Windows NT/2000/XP には、497日問題と呼ばれるトラブルがあることを最近知った。これは、WindowsのOSを起動してから連続497日間以上稼働させ続けると、タイマー割り込みが一切きかなくなって、マシンがフリーズする現象だ。正確に言うとCPUの内部は動き続けているのだが、ユーザから見ると一定時間毎の画面更新がなく、止まってしまったように見える。原因は10msのタイマー割り込みカウンターのオーバーフロー処理にあるらしい（じつはlinuxにも同様の問題があるという）。
対策はたった一つ、システムを再起動するしかない。Microsoft社から一応パッチが出されているが、請求しないと入手できないし、そもそも無保証だ。問題の起こったシステムにだけパッチを当てろ、という冗談のようなことが書いてある。どのマシンでも起こりうる問題なのに、である。同社がユーザのことをどう思っているのかは神のみぞ知る、だが、少なくともお仕事の場では、「無保証」では気休めにもならない。
もっとも、JWNTUG（Japan
Windows NT User Group）のコラムも書いているように、「現実問題として、497 日間連続稼働するシステムはそんなに多くないだろう。」と、同社はたかをくくっているのかもしれない。たいていのPCは毎朝起動されるし、NTサーバだってディスク増設だネットワークの変更だ何だかんだで、ときおりリブートされるだろう、と。
とんでもないことだ。Microsoft社は自分たちがMES（Manufacturing Execution System：製造実行システム）の領域に攻勢をかけようとしていたことを忘れたのだろうか？ 私自身はこの問題を、某制御システムメーカーが顧客宛に出した警告のレターで知った。知ってすぐ、青ざめた。私が地球の裏側、南米のプラントに納めたMESの中のRTIS（Real
Time Information System）は連続稼働してから１年以上たつはずだ。プロセス産業ではDCSもPLCもSCADAもMESも、みんな連続運転が前提なのである。
私のケースでは、DCSは幸いunixベースだし、RTISへのインタフェースにバッファリング機構があるため、サーバをリブートする程度の時間だったら、データが失われることはない。しかし、すべてのユーザがそうだとは限らない。Microsoft社はOPC（OLE
for Process Contrl）という規格を提唱して、WindowsでPLCを全部束ねられます、と宣伝し続けてきたではないか。それなのに、497日問題に本気で対応しているとは思えない。どんなOSやアプリにもバグはつきものだが、問題はそのあとの対応なのだ。
もう一度繰り返すが、プロセス産業では連続運転が前提だ。以前の日本の石油業界ならば、時代遅れの法規制にしばられて、１年に１回必ずシャットダウン・メンテナンスや開放点検を義務づけられていたから（我が国の石油・石化業界に国際競争力がなかったのはこのせいだ）、497日問題を見逃していたかもしれない。
だが、今は違う。プロセス・プラントを２年以上連続して動かすのは、内外の常識なのだ。私は以前から、「製造業には、ERPよりもまずMESを」と主張してきた。しかし、これからは、「でもMSベースのシステムはおすすめできません」と小声で追加しなくてはならない。困ったものだ。
（注）MESにかかわる各種用語と概念、およびプロセス産業におけるMESの特徴については、中村実・正田耕一編「MES入門」を参照のされたい。私は第３章を執筆している。続編も近々出版される予定。
最近、プロジェクト・マネジメントに新たな関心が集まっている。米国PMIの旗振りで、日本でもPMP（Project
Management Professional）の資格試験が行なわれるようになったことが一つの要因だろう。が、おそらく製造業の製品ライフサイクルが短くなって、プロジェクトの概念を持ち込まないと製品開発から製造販売までのプロセスをスピーディに回せなくなってきたことが、大きな原因ではないか。また、それとは別に、ＥＲＰ導入の事例がふえるにつれ、しだいにシステム・インテグレータにおけるプロジェクト管理の質（の低さ）が注意を集めるようになったことも、あげなくてはなるまい。
そのプロジェクト・マネジメントの業界では、このところアーンドバリュー分析の手法が急速に浸透してきているようである。前回のワンポイント講義「進捗率の計算と図的表現法」でも取りあげたが、コストとスケジュールの両方を一度に予実管理できる手法として、注目を集めている。
アーンドバリュー分析では、以下の三つの指標を用いて、コストとスケジュールを計測する：
(1) BCWS = Budgeted Cost of Work Scheduled (ないしPC = Planned Cost)
(2) ACWP = Actual Cost of Work Performed (ないしAC = Actual Cost)
(3) BCWP = Budgeted Cost of Work Performed (ないしEV = Earned Value)
目新しいのは、(3)のBCWP（ないしEV）である。(1)のBCWSと(2)のACWPは自明の指標であり、従来はこの二つだけで予実管理をしていた。しかしプロジェクトの進行途中で、BCWS
< ACWPという集計結果が出ても、それがコスト超過を示しているのか、それとも予想以上に作業が進捗しているためなのか、判別できないという問題があった。そこにBCWPを持ち込むと、ここまでの進捗ではこれだけの費用が見込まれていたはずだった、という数字が判るので、コスト変動と進捗偏差を区別することができ、結果を正しく分析できるようになるのである（参考図）。
アーンドバリュー分析は、このように素晴らしい手法である。が、同時に重大な問題点をかかえていることは、あまり認識されていないようだ。問題点は、私の見るところ、大きく三つある。
まず第一に、予算 Budget が明確なプロジェクトでなければ利用できないこと。これは自明のようだが、たしかに制約である。スコープが契約で明確に規定された『ＸＸシステム構築プロジェクト』を、一括請負で率いているときは、BCWPに何の曇りもない。しかし、あなたが仮に製薬会社の研究所で、これから何年かかるか判らない新薬開発プロジェクトをやっているとしたら。あるいは、本社で『意識改革プロジェクト』なる漠然としたテーマを総務本部長から与えられたら、どうだろうか？
世の中のほとんどのプロジェクトは、最初はスコープを規定するフェーズからスタートする。そして、このフェーズだけで数ヶ月も、へたをすれば１年以上もかかるのである。この間ずっと、アーンドバリュー分析は進捗報告に、無力だ。
第二の問題点は、もっとずっと深刻である。アーンドバリュー分析では、全てのタスク（アクティビティ）にコストを配布してそれを積算する。その結果、クリティカル・パス上に乗っているタスクも、そうでない雑多なタスクも、すべてコスト配分の重みで評価されるのである。したがって、クリティカル・パスが遅れていても、他の多数のタスクが予定よりも進行していれば、プロジェクト全体は滞りなく進んでいるかのように見える。重大なスケジュールのリスクを見逃しかねないのだ。
いや、そればかりか、請負業者の場合は、この性質を逆に利用して、顧客へのレポートを粉飾することができる訳だ。プロジェクト全体は遅れているのに、どうでもいいタスクだけを急がせて、進捗率を稼ぐことができてしまう・・・
最後の問題点は、アーンドバリュー分析ではマイルストーンに重みを賦課するのが難しいことだ。進捗はタスクの出費だけで評価される。だが、それのどこが問題なのか？
それは、たとえば「基本設計完了」というマイルストーンを考えてみればわかる。プロジェクトマネージャにとって、基本設計をユーザと開発チームとが承認することは、きわめて大きな意味を持つ。これによって、今後の不確定性とリスクをかなり減少できるのだ。心理的には、25%とか30%の達成感がある。
しかし、大きなプロジェクトになればなるほど、それ以降の構築／製造フェーズでの費用割合が大きくなる。相対的に、基本設計段階でのBudgeted
Costは25%どころか、ずっと小さな比率しか持てなくなってしまう。基本設計完了で、進捗が7%だと言われて、あなたは満足だろうか？
どうしてこのような不合理が生まれるのか。それは、皮肉なことに、アーンドバリュー分析がコストしか計っていないからである。実は、全てのタスクは、コスト（原価）とは別に、それがもたらすバリュー（価値）を持っている。ふつう、設計は大きな付加価値の源泉である。だから、基本設計のバリューは、そのコストに比べてずっと大きいのだ。そして、だからこそ、人はそこに大きなマイルストーンを認めるのだ。
アーンドバリュー分析をこれから導入しようという人は、これらの問題点を十分理解した上で、賢明な使用法を見いだされるよう望みたい。
AspenTechはどこにいくのか
（2002/09/27）
最近、プロセス産業向けソフトウェア業界の巨人、AspenTechをめぐる動きが急だ。
ARC Advisory Groupは、SAPとAspenTechの間で、石油ガス業界における提携の話が進んでいると報じている（ARCwire
for the Week Ending September 6, 2002）。これによると、サプライチェーンの世界でながくライバル関係にあった２社は、石油ガス業界向けに協同するために話し合いを続けており、draft
agreementの段階に来ているという。
ARCは、「これが実現すればドリーム・チームだ。SAPは世界のトップ石油会社の８割以上を押さえているし、AspenTechのSCM
solutionはトップ25社中24社で使われている。両者が協力すれば、この業界では盤石の存在となるだろう」と、いささか気の早いコメントを出している。
その一方で、つい数ヶ月前に行われた、AspenTechによるHyprotech社の買収のニュースは化学業界を激震させた。プロセス・シミュレーションを事実上Aspenが寡占することになったからだ。Aspenはまた、実際のインプリメンテーション・ビジネスのために、今年Accenture社とアライアンスを結び巨額の投資を行った。さらにプロセス業界向けCADの最大手Intergraph社とも２年前から提携をしている。こうなると、向かうところ敵なし、という感じだ。
にもかかわらず、同社は今年１割以上の北米従業員をレイオフし、創業者のEvans氏がCEOを退任することになった。きびしい減収と株価急落にあえぎ、買収の噂が飛び交っている。いったいなぜか？
それは、Aspenの抱える多数の製品群に、統一性が欠けているからだ。個々の製品のクオリティは非常に高いにもかかわらず、である。Aspenはもともと大学の研究者が、技術の商品化のためにスピンアウトして作った会社だった。しかし、買収に次ぐ買収で製品ラインアップを拡大する戦略をとったために、設計思想もアーキテクチャーも異なるソフトウェアを多数抱え込むことになった。開発拠点も全米の各地に分散している。
ユーザ企業にとって、こうしたバラバラな製品のオーナー・コストは結局かなり高くつく。プロセス産業におけるオートメーションの歴史は深く、インテグレーションの結合度も高いので、データ・モデルやインタフェースの統一はきわめてクリティカルな問題になる。しかも、同社の技術サポートの姿勢が内向きだ、という批判もしばしば耳にする。
Aspenの現在の苦境は、ユーザ企業にこうした不安が広がり、契約がなかなか取れなくなってきたためだ。セールスを強化するために、後任のCEOはHoneywell出身のマーケティング担当副社長D.
McQuillinが指名された。彼は組織のリストラと製品ラインの整理を行うと言われている。研究開発指向が強く、マネーゲームで躍進してきた会社が、いまや営業力強化で生き残りをかけていくことになった。
同社のあり方は、今のアメリカのソフトウェア企業の一典型であるとも言えるだろう。企業は買収できるが、組織の融合には金も時間もかかる。まして、異なる設計思想をつなぎ合わせるのは、木に竹を接ぐより難しいのだ。
参考記事：Boston
Business Journal, From the May 3, 2002
先週紹介したD. Garwood著「Bills of
Material – Structured for Excelence」は、BOMの全社的統一を大きな問題としてとりあげている。裏表紙の惹句に“以下のような問題に突き当たったら本書をお薦めする”とあって、その第一が
- E-BOMとM-BOMの不統一
である。
E-BOMとM-BOMというのはそれぞれ、Engineering BOMとManufacturing BOMの省略だ。前者は設計図面で規定された部品表、後者は工場で実際に製造される部品表、を意味している。多くの企業はこの二種類が両立・乖離している問題に苦しんでいる。
なぜ同じ製品の部品表が設計と製造で乖離するのだ？ と無邪気な情報技術者は思うかもしれない。ところが乖離するのですよ。それにはいろいろな理由がある。たとえば設計変更（たいていは細かな改善でモデルチェンジではない）。これで部品が変わってしまう。しかし工場では旧タイプの部品のストックがつきるまでは、それを使いつづけたりする。あるいは資材の仕入先の変更。また、納入待ちなどの事情で一時的に類似の代替部品を使うことも多い（とくに包材など）。
工場では出荷した製品の品質や保証に責任を問われるから、実際にその製品に使用された品目が何だったか、記録する必要に迫られる。こうしてM-BOMが生まれ、それは次第にE-BOMとは異なったライフサイクルをたどってメンテナンスされることになる。Garwoodの本では、BOMの統一性を救うために、"Requirement
File"というデータベースを提案している。これは一つのアイデアだと思うが、しかし一種のM-BOMの代替品と見えなくもない。
そればかりか、多国籍で工場を展開している大企業では、同じ部品番号でも製造する国や工場によって性状が微妙に変わってしまったりする。こうなると組み付ける相手部品や検査ポイントもずれてくる。こうしてBOMは次第に複雑怪奇な分化増殖を遂げていく。日本の自動車業界を代表するＴ社もＨ社も、４種類ものBOMをかかえて不統一に苦しんでいるのが実状なのだ。
それなら情報技術の出番だ、ネットワーク上でBOMマスタを共有できるようにすれば、見事に統一できるにちがいない－－ソフトウェア企業から、こういう発想が出てくるのも、わからぬではない。先日、米オラクル本社の開発ディレクターと話していたときも、そんな意図の開発プロジェクトがあるということだった。
しかし、それで解決できると思ったら間違いだ。BOMが分化し乖離していくのにはビジネス・プロセス上の理由がある。それは要するに、要求（Requirement）と実現（Fulfillment）が別々の事柄だからだ。「電子カタログの夢と現実」にも書いたとおり、この両者は明らかに区別して管理しなければならない。
二元化は不可避なのだ。ビジネス上の原理的要求で生じる問題を、ＩＴで解決できるとコンピュータ屋さんが考えたとしたら、それはいささか無邪気すぎるといわざるを得まい。
前回、「サプライチェーンは電子カタログの夢を見るか？」で、電子カタログの実現はＳＣＭソフトのベンダーたちが言うほど簡単ではない、と書いた。この問題を、もう少し考えてみよう。
「カタログ」という言葉で、普通の人が思い浮かべるものは何か。商品の名前と説明と写真がならんでいて、それに値段や納品までの日数などがついている、通販のカタログを考える人がほとんどだろう。そして、これを電子化したものが電子カタログだ、と想像するはずだ。
これをもう少し（カッコつけて）専門家風に表現すると、こうなる：『品目に、その仕様情報と、価格・納期などの販売情報を付加したデータベースが電子カタログである』
一般消費者向けの商売ならば、このような電子カタログも役に立つかもしれない。少なくとも、BtoC E-Commerceの入り口の敷居をまたぐ程度の助けにはなるだろう。－－しかし、BtoBとなると、これだけではぜんぜん商売に使えない。それは、企業対企業の取引で、通信販売がほとんど利用されていないことを考えてみればわかる。
電子カタログが企業の購買で役に立たない理由は、大きく分けて５種類くらいある。
（１）価格の問題
企業間取引では、価格はほとんどつねに売り手・買い手双方の交渉と合意のすえに決められる。いいかえるならば、カタログの言い値でモノを買う購買担当者など、まず存在しない。価格ネゴがバイヤーの腕の見せ所、というわけだ。その是非はともかく、これが現実である。
これはすなわち、カタログは買い手の承認プロセス抜きでは存在できない（意味がない）ということである。そして価格はつねに、量や時期や決済方法や販売先ごとに各種のディスカウントが行なわれるから、電子カタログはこうした多様なニーズに対応できるよう、非常にフレキシブルなデータ構造を要求される。
（２）納期と在庫回答
発注者にとって、納期は価格と並ぶ重要な条件である。ところが、納期は在庫の有無によって大きく変わる。買い手の側は、その商品がすぐ納品可能なのか、バックオーダーの扱いになるのか、カタログの上で知りたいところだ（Amazon.comだって、その程度のことは教えてくれる）。
これはすなわち、電子カタログのコンテンツが、静的なマスタ・データではなく、毎日更新する必要のある動的なデータである、ということを意味する。カタログのメンテナンスは、売り手にとってかなり重たい作業になってくる。ことに、複数の購買サイトにカタログをアップロードしなければならないような、昨今の状況では。
（３）仕様（属性）データの構造
製品の仕様は、技術的な属性情報である。電子カタログの利点の一つは、属性に基づく商品の検索が、速く効率よくできることにあるわけだから、この属性項目の定義はとても重要である。
ところが、この属性項目の設定（情報技術風に言うならばデータベースのフィールド定義）が、案外くせものである。複数の商品カテゴリーの品目を扱うようになると、属性は商品種別ごとに変えなければならない。しかし共通項目もある。これをうまくさばくには、属性に階層構造を作らなくてはならなくなってくる。
階層構造を作りはじめるやいなや、複数企業間をまたいだ検索など夢のまた夢になる。なぜなら、製品カテゴリーの分類は、その企業の（大げさに言えば）世界観の表明に他ならず、それは各社で常に独自のものだからだ。UNSPSCといえども、このバリアーを壊せるほど万能ではない。
（４）オプションとＢＴＯの取り扱い
現代の製品の多くは、顧客のニーズや好みに応じてさまざまなオプションを設定できるようになっている。オプションの組合せは掛け算だから、すぐに品種数は千や万の桁になってしまう。これらのすべてを電子カタログに記載できるのか？ できたとしても実用になるのか？
オプション・コンフィギュレータのようなソフトを使ってオーダー・エントリー・システムを使い、ＢＴＯを実現している会社は、電子ファイルに対してどう取り組めばいいのか。どうみても、静的なデータベースで対応できないのは明らかではないか。
（５）カタログは誰のものか
そして、最後の、根幹の問題は、カタログには買い手の"Requirement"を記述する目録と、売り手の"Fulfillment"を示す目録の二種類が、つねに厳然として存在することである。この区別はサプライチェーンにおけるマテリアル・マネジメントの中核をなす概念である。
しかし、今のソフトウェア・ベンダーの中で、この両者の区別に意識的に対応しているものは、私の知る限りほとんどいない。
こうしたさまざまの論点を考えてみると、電子カタログの実現までにはまだ長い道のりが必要であることがわかる。むろん、不可能な道だとは言わない。ただ、巷間いわれるがごとくたやすい仕事でないことは確かなようである。
サプライチェーンは電子カタログの夢を見るか
（2002/07/21）
ResolveNetが２年前、UNSPSCの構造に準拠して、すべての国の商品を一元登録するという巨大電子カタログのプロジェクトをはじめたとき、多くのジャーナリズムは「これでサプライチェーン・マネジメントの難問を解決できる」と、そのねらいを賞賛した。むろん、『あまりに野心的すぎる』と思った人もいたようだが、電子カタログのコンテンツ管理というビジネス・モデルの有効性については、誰も疑問を持たなかったようだ。
ＳＣＭの難問とは何か。それは、企業間で共通に使える品目マスタMaterial Masterの構築だ。Source→Make→Deliverの連鎖したネットワークを効率よく運転するためには、チェーン内を流れる同じ物品を、同じ呼び名・同じコードで扱える仕組みを企業間で共有したい。UNSPSCのような標準物品コード体系のねらいはそこにある。
UNSPSCはコードの構造を与えるだけだが、ResolveNetは、具体的な商品名とコードを登録することをビジネスにした。商品名を入れれば、どの国の物であっても、そのコードや属性を検索できる、というわけだ。
ところで、私自身はあまり電子カタログの普遍性を信じていない。すくなくとも、ＳＣＭのボトルネックを解消する救世主だという風には思っていない。なぜか。
それは、電子調達の仕事をして行くうちに、売買行為とは基本的に、『売り手の商品概念』と『買い手の商品概念』の間のマッピングならびに価値（値段その他）の合意形成過程にほかならぬ、ということに気がついたからだ。２者間で互いに物品に関するパーセプションを擦り合せること。そこに価値の対等な交換が生まれる。
もしそうなら、まさに電子カタログの出番ではないか、と思われるだろう。事実、「電子市場の現在」にも書いたように、多くのMarketplaceは今、カタログ・コンテンツの充実が課題だといっている。しかし、これは逆に言えば、カタログがなくても市場が成立することを示している。直接のネゴで十分売買は可能なのだし、多くの場合バイヤー達はそれを好む。
現在の電子調達ソフトウェアのカタログ機能は、正直いってB2Cの商品カタログの基本設計からあまり大きく発展していない。サプライヤーの提供する商品があり、名称と、多少の仕様・属性と、そして価格がついている。まあ、ふつう購買担当者心理の常として、カタログ・プライスなんかで買ってたまるか、という習性があるのだが、ここではその是非はおくこととしよう。
問題なのは、ここにバイヤー・サイドのカタログ、という概念が欠けていることだ。売買が両者間のマッピングである以上、サプライヤー・カタログ単体では購買行為が成立しない。バイヤーは要求仕様を常に自分の心の中に持ち続けなければならない。これではＳＣＭの仕組みとして片手落ちではないか。
他にも、サプライヤー・カタログ自体にも問題はある。最大の課題は、在庫及びAvailabilityのデータをどう維持していくかだ。カタログ・データベースはマスタ情報だと思っているケースが多いが、ATPを入れたとたん、トランザクション情報に急変するのだ。こうなると更新のリアルタイム性など、コンテンツ・アグリゲーター商売の急所を痛打することになる。
もちろん、電子カタログの意義自体を否定するつもりは私にはない。現に、電子部品業界は最もカタログ化の進んだ業界であり、そのＳＣＭに大きな役割をはたしている。しかし、電子カタログがどの業界のサプライチェーンでも、夢のように効果があるとは信じない。どんな道具立ても、その領域と限界をわきまえてこそ、正しい力を発揮するものなのだから。
Web Servicesと子守り歌
（2002/07/03）
インターネットを通して、複数のアプリケーションが連携し合う仕組みとしてWeb Servicesが注目されている。
これまでのWeb-basedアプリケーションは、基本的にHTMLを使ったユーザ・インタフェースから起動され、ブラウザに結果や返答を表示する方式だった。もしユーザが複数のサイトでさまざまなサービスを受けて、その結果をまとめたい場合は（たとえば複数のショッピング・サイトから商品カタログと価格を探すようなケースを考えてほしい）、手動で複数のブラウザ画面を立ち上げて、copy
& pasteで表計算に持ち込む、といった手順が必要になる。
しかし、B2Bで複数の企業アプリケーション間がやりとりをするためは、これではあまりに不便である。自動的に他社のサイトにメッセージを送ってアプリケーションを呼び出し、自動的に答えを受け取るような仕組みがほしい。そのために編み出されたのがWeb
Servicesとよばれる手法で、基本的にはXMLメッセージの形式と、それをやりとりするためのプロトコル、そしてアプリケーション・サービスを検索するための公開ディレクトリ、などの技術要素から成り立っている。
ところで先週、Web Servicesの現状に関する、二つの興味深いレポートが米国の調査会社から発表された。これは（例によって）テクノロジーの売り手側が叫んでいる宣伝文句と、使い手側の認識のギャップをクールに示したものとなっている。
まず、B2B専門の調査会社FactPoint Groupによるレポート
「Fortune
1000 Aggressively Adopting XML Web Services, New Report Finds」
では、昨年の夏頃からようやく始まり出したWeb Servicesが、すでに米国の主要大企業でかなりのパーセンテージで実用に使われるようになってきている、と驚きを持って伝えている。Web
Servicesのツールが“比較的”安価であることも、この不況の時代にマッチしている。
Web ServicesはHTTPを通信手段の基盤に使う。HTTPはどこのFirewallでもたいていは設定変更せずにとおるので、たしかに運用管理費用の点でも利点がある。
一方、ＩＴリサーチ業界の老舗AMR Researchのレポート
「Web
Service Vendor Hype Conflicts With User Feedback」
はもう少しクールである。現時点ではWeb Servicesが準拠する標準規格WSDLやSOAPの実装技術が未成熟なため、複数社間のデータ交換には障害が少なくない。また、技術論以前の問題として、業界内部で用語・概念等の統一が図られていない場合（残念ながら、これはカタログの発達した電子部品業界以外のほとんど全てにあてはまる）、意味論の面で会話が成立しない。
B2B integrationでもう一つ障害となるのは、公開ディレクトリ・サービスであるPublic UDDIのコンテンツがきわめて貧弱な点だ。
したがって、当面Web Servicesが活躍するのは、企業内での業務アプリケーション統合（Enterprize Application
Integration = EAI）である、というのがAMR Researchの提言である。
Web Servicesの将来性については、疑う余地はない。高価なEAIツールや、融通のきかないEDIよりも望ましい解決であることは誰もが合意するだろう。しかし、Microsoft,
IBM,SUNなどのベンダーが喧伝する、いつもの“この新技術がＩＴの世界を救う”という謳い文句は大げさすぎる。どれだけ我々はこの手の「子守り歌」を聴かされつづけてきただろう？ 売り手たちの合唱するうすら甘い声に耳を閉じ、目を覚ますべき時がもう来ているのだ。
またシリコン・バレーにきている。今回は、電子市場の運営者達によるフォーラムに参加するためだ。世界各地から市場サイトを実際に運営している会社・十数社が集まった。主に欧州・中南米と中東・アフリカの会社で、あいにく米国と肝心のアジア・パシフィック地域からの参加はなかったが、これだけのドットコム・サイト運営者たちが一堂に会すると、それなりに共通した傾向や悩みが見て取れる。
業種、というか対象とするビジネス・モデルを見ると、３種類に分けられる。まず、われわれepc-business.comのような、特定業界の商取引のためにサービスしているサイト。石油・ガス業界や電気通信業界などの大企業が出資設立したものだ。次に、主に自治体や政府機関、医療機関などの調達サービスのために設立されたサイト。それから、（ちょっと意外だが）銀行が、顧客の中小企業のために設立した購買のサイトだ。最後のものは主にオフィス・サプライなどの間接材を対象にしており、これが一番多い。
ちなみに、スペアパーツや間接材をひとくくりにしてMRO (Maintenance Repair and Operation)
goodsと呼ぶ。MROのたぐいはカタログ購買にむいている。サプライチェーンの長さも納期も短い。サプライヤーに中小・零細企業が多い点も特徴だ。われわれのような重厚長大産業で直接材を調達している世界とはずいぶん違う。
ところで、話を聞いていると、意外なことに多くのサイトが、カタログ抜きで引き合い業務からスタートしていることが分かった。バイヤーという人種は、カタログがあってもなくても、とにかく引き合いし値引交渉するすることを自分の仕事と心得ているらしい。そして、カタログ・コンテンツの導入・充実は、これからの大きな課題だという。まあ、電子カタログの難しさは、色々な理由から理解できるのだが、この話をはじめると長くなるので次回にまわそう。
また、サプライヤー・データベースの充実も大きな課題だと言っていた。これはまったく同感だ。買い手にとって、売り手の素性やこれまでの経験ほど重要なものはない。サプライヤー・データは、売り手が自分からインプットして公表するパブリックな情報と、買い手がそれぞれに対してつける評価というプライベート情報の２種類がある。この両者をきちんと扱えなければ電子市場とは言えない。なぜなら、市場とはｎ対ｎのコミュニティなのだから。
そして共通した悩みが、参加企業の社内システムとの接続だった。これも当然すぎるほど当然だろう。引き合い書の準備から請求・支払いまで、社内システムと関係しない業務は一つもない。このインタフェースを開発するのはひと苦労だ。そこで、ERPベンダーはここぞとばかりに、「Web対応した我が社の製品を使えば、はじめから購買から会計まで統合されていますから苦労なしです。電子市場なんていりませんよ」と宣伝して来る。
しかしｎ対ｎの電子市場は、１対ｎのインターネット購買とは質的に違うものなのだ。第一、買い手中心の１社購買システムばかりが、あちこちにぽこぽこと出来ては、サプライヤーの方が困ってしまうではないか。アカウントもパスワードも別々にもつ必要があるし、パブリック情報もカタログも顧客の数だけくり返し入力・保守しなければならない。データ形式に互換性もない。使用方法だってマニュアルだってばらばらだ。そんなやり方のどこが進歩なのか。サプライチェーンの無駄を増やしてスピードを落とすばかりではないか？
電子市場はインターネット購買ではない。大企業の買い手中心の、唯我独尊の思考を止めなければ、ネット社会の真の進歩はありえまい。
「そもそもね、需要予測なんて本当に我々人間にとって可能なのか、と哲学的な疑問を感じるんですよ。」
経営コンサルタントの研究会の席上で、とある先輩はこう発言された。ＳＣＭをテーマに考える会合だった。かれこれ２年以上前のことである。
ＳＣＭソフトの売り物の一つは需要予測である。しかし、需要予測システムという商品には、どこか胡散臭さがつきまとう－－そう感じている人は多い。そんなに簡単に将来が読めるものか、先が読めるくらいだったら誰も苦労はしない、そんなつぶやきが聞こえてきそうだ。
しかし、「予測」には嫌疑的な人も、「計画」や「予定」まではさすがに排除しない。だから、たいがいの企業では「販売計画」が立てられる。むろん、その位置づけは“精神目標”的なものから、“需要予測”に限りなく近いものまで、さまざまだ。実際には、目標・計画・予測・予定・確定は、同一事象の延長線上にあると考えてもかまわない。
こうしてみると、どんな企業でも、需要予測に類する仕事はやっていると言ってよい。また、逆にＳＣＭソフトの方も、「予測」という“哲学論議”をよびかねない名前をさけて、「需要計画システム」と呼ぶ例も多い。
しかし、名前をどう付けようが、果たしてコンピュータ・ソフトを入れて予測の精度が劇的に上がるようなことがありうるのだろうか－－これが人々の最大の疑問だろう。
答えから先に言うと、精度は上がるのだ。しかし、それはべつに、需要予測ソフトウェアが十数次の移動平均数学モデルを内蔵しているから、という訳ではない。いや、そもそも、予測ツールの導入だけでは、予測精度が劇的に上がることはない。
精度が劇的に上がるのは、月次予測から週次予測へと、予測スパンを短くしたときなのだ。だれだって、１月先よりも来週のことだったら、より確実に読むことができる。ごく当たり前のことなのだ。
しかし、その「当たり前」を実行するためには、週次予測を受け取って、週次の生産・物流・在庫計画を立て、それをもとにサプライチェーンを回せる仕組みができあがっていなければならない。もし需要予測を週次で回しても、生産計画が月次のままだったら、それはナンセンスというものだ。自動車を運転するのにエンジンの回転数だけ上げて、ギアはローのまま走るようなものだから。
需要予測の精度を向上させたければ、予測ツールの導入だけでは足りない。予測を実行につなぐための計画系のツールを導入し、業務のプロセスに組み入れる努力が必要なのだ。予測ツールの導入に比べて、こちらの方がはるかにたいへんな仕事だということは、誰でもわかるだろう。予測というものは、それが現実に即時につながらない限り、絵に描いた餅なのだから。
ゴールドラットの小説「ザ・ゴール」の翻訳が昨年日本でも出て、ベストセラーになっている。面白い本は、やはり売れるということだ。
ところで、このストーリーの中に、工場のコントローラーという人が出てくる。これは日本ではあまり見かけぬ、なじみのない職種だ。翻訳すれば「工場管理者」になってしまうが、和訳本ではどうなっているのだろうか。ちなみに、主人公のアレックスはPlant
Managerであり、これも直訳すれば「工場管理者」だが、実際には「工場長」である。
つまり、米国の企業では一つの工場に二種類の管理者がいることになる。ということは、二種類の別々の管理の仕組みが存在する－－そういうことだろうか？
もちろん違う。小説を読めば分かるが、工場長は一応コントローラーの上役と位置付けられている。ただし両者は明らかに別の職能であって、工場長と副工場長のように同じ職能の中での上下関係をしめしているのではない。マネジメントとコントロールは、あきらかに違う概念なのだ。
似たような例は、プロジェクトの世界にもある。わたしの属しているエンジニアリング業界はプロジェクト中心の業態だ。ここにも、「プロジェクト・マネージャー」の下に別職能としての「プロジェクト・コントロール」が所属する。これも、両者を「プロジェクト管理」と訳してしまうと、わけがわからなくなる。
なぜ英語にはこんな区別が存在するのか。なぜその違いに日本人は鈍感なのか？ これを理解するためには、日本語で「管理」という言葉に対応する英単語が、
– Management
– Control
– Administration
の３種類あることを知る必要がある。
英語でI can manage.というと、「わたしが管理する。」ではなく、「何とかやり遂げるよ。」というニュアンスになる。それはうまく行く保証のない、けっこう大変なことなのだ。Manageすべき対象には予期しがたい部分があって、どこかに、暴れ馬を乗りこなすようなイメージがある。あるいは、航海に出る船長のような。
それに比べて、I can control.はもっと精密さを感じる。日本語で「制御」とか「統率」にちかい。なすべきことは計画で決まっていて、それをきちんと達成する。現実の状態を把握して、計画と実際に差があったらそれを正して行く、そんな感じだ。
ではmanageよりcontrolの方が管理水準が上なのかというと、そんなことはない。ふつうcontrolの対象は通常manageよりも小さく、御せる範囲にある。たとえていうと、controlは船の航海士の仕事にあたる。船長が決めた方針通りに、海図にひかれた航路をとっていく。
両者の大きな違いは、manageには最初に大きな「計画」をたてたり、組織や仕組みを作る「組織化」の仕事が含まれているのに、controlにはそれがないことだ（狭い近未来の範囲では多少重なるが）。また、不測の事態に対してリスク・テークしたり、あらかじめ手を打ったりすることも少ない。大方針を決めて、リスクの責任を取るのはmanageする船長の側なのだ。
もう少しエンジニアに分かりやすいたとえでいうならば、「Controlは フィードバック制御、Manageはフィード・フォワード制御」ということになろうか。先読みができなければマネジメントとは言わない。
このような観点から、自分の身の回りで「管理」と呼ばれている仕事を見直してみるといい。先読みし、リスクをとっているかどうか。それとも単なる記録と状況報告が主な役割となっていないかどうか。前者はマネジメントの名に値するが後者はコントロールにすぎない。生産管理・コスト管理・労務管理・在庫管理・・・検討すべき対象には事欠かないはずだ。
情報技術の分野でいえば、「○○マネジメント・システム」とか、 「××管理レポート」などが再検討の対象だ。入力されたデータを、単に記録し適度に集計してプリントアウトするだけの仕組みだったら、それは「○○状況レポーティング・プログラム」と呼ぶのがふさわしい。
正しい名前を与えることが、正しい事実認識の第一歩なのだから。
（注）：日本のトイレタリー業界のトップであるユニ・チャーム社にコントローラーという職種が存在するが、これがわたしの知る範囲では唯一の製造業の例である
工場の計画を立てているとき、「稼働率最大」という目標を満たすように工場側から要求されることがしばしばある。面白いことに、「稼働率を下げて仕事を楽にしてくれ」などとは決して言われない。つねに忙しくすることを求められるのだ（少なくとも日本では）。
スケジューリングを最適化問題としてとらえる場合にも、往々にして、この稼働率アップが目的関数にもぐり込んでくる。しかし、ここで私は声を大にして言いたい。
「稼働率アップを目標にしてはいけない！」
そもそも工場の稼働率とは何だろうか。ごく単純に定式化するならば、“設備リソースの実稼働時間を、利用可能な時間総数で割って求められる比率”だ。
稼働率で管理する、とは、稼働率がいかに100%という限界に近づいているかで、工場のパフォーマンスを計る考え方である。機械設備の特性上、フル稼働に近ければ近いほどロスや不良率が下がり、生産効率が良くなるはずだ－－これが稼働率管理の背景にある。また減価償却を時間ベースで生産原価に配分する場合も、稼働率が上がればそれだけ生産単価が下がる勘定になる。
しかし、よく考えてみてほしい。もしも、同じ製品１００個を２人の作業者が担当して、一人は１時間で首尾良く作り、他方は２時間かけて不手際に作った場合とで比べると、後者の方がその設備の稼働率が高くなるのだ。しかし、誰がどう見ても、前者の方が優れている。かりに残りの１時間は遊んでいたとしても、である。
さらに、稼働率計算にはワナがある。見込み生産で動いている業種では、工場がフル稼働して見かけ上は景気良く動いていても、実は製品在庫がどこか遠くの見えない倉庫に積み上がっていくだけ、という可能性がある。会社全体では、生産を売上につなげて初めて利潤が生じるのだから、稼働率による管理は工場だけの「局所最適化」になるおそれが高い。
ＴＯＣ理論を学んだ方なら、ここで「工場のボトルネック工程での稼働率最大化ならば全体最適にマッチする」とおっしゃるかもしれない。いえいえ、答えはＮＯです。ＴＯＣで求めるのはサプライチェーンのスループット最大化であり、それが工場のボトルネック工程での稼働率最大化にイコールとなるためには、さまざまな留保条件が付くことを忘れてはいけない。端的には、さきほどの１００個の製品の例を考えてみればわかる。
それでは、無用な在庫が存在しないはずの完全受注生産や、在庫が理論的にありえないサービス業などの業態（典型的には受託開発のソフトウェア・ハウスなど）ならば、稼働率管理に意味が出てくるだろうか。
ここでも、答えはＮＯである。なぜならば、完全受注生産の業態においては、全体稼働率は仕事の受注量の従属関数にすぎないからだ。独立変数である受注量を見過ごしたまま、従属関数だけ向上させようとするのは、愚の骨頂である。その結果は、予算として与えられた作業時間のいたずらな消費、タイムシート上の「調整」（＝嘘）、低能率の看過など、さまざまな望ましくない副作用をもたらす。
間違った評価尺度で生産組織を管理してはいけない。それは企業組織全体のあり方をゆがめてしまう。そして、稼働率管理はその最たるものの一つなのである。
ドットコム・エコノミーの後に来るもの
（2002/2/15）
またシリコン・バレーに来ている。昨年の４月以来、ほぼ１年ぶりだ。１年は長いようでもあっという間だ。とくに４０歳を過ぎてからはそう思う。
サン・フランシスコの丘から見下ろす街と湾の風景は、あいかわらず美しい。しかし、この１年間に米国のＩＴ産業はがらりと変わってしまった。たしか少し前までは「インターネットはドッグ・イヤー」と言っていたはずだ。それが牛の１年程度にスローモー化したような気がする。
いや、でも、もしかしたら実は「ラット・イヤー」だったのかもしれない。この１年間に無数の小さな新生企業が、短命なネズミのようにばたばたとつぶれてしまった。そもそもインターネット革命とともに生まれたドットコム・カンパニー自体が、右肩上がりの神話という笛吹き男に動かされたハーメルンのネズミの行進さながら、同じ終末に向けて盲動的に走っていたようだ。
「リエンジニアリング」「競争優位戦略」で有名な元ハーバード大のカリスマ教授マイク・ハマーは、最近のSupplyChain
Management Review誌上のインタビューで、
私はドット・コム企業を許すことは決してできない。彼等はインターネットが持つ真の力から経営陣の目をそらしてしまうという罪を犯した。
と語っている。
ドット・コム企業はなぜ失敗したのか？ 説明はいろいろあるだろう。私の考えでは、ドット・コム企業の多くは（少なくとも第一世代の起業家たちは）、「山頂の上に高速道路のインターチェンジを造ろうとして失敗した」のである。第一世代とは、“中立なexchange市場を形成して中抜きdisintermediationを目指そう”とした人たちである。インターネットという、どこでもドアならぬ『どこでも高速道路』さえあれば、遠くの山脈の上でもインターチェンジは可能になるはずだ（そしてそこで通行料を取って稼げばいい）と彼らは考えた。
ところがどっこい、そうはいかないのである。高速道路が今ある場所を走っているのはちゃんとした理由があってのことで、（たとえ米国であっても）地図上に勝手に線を引いて出来上がったわけではない。都市と都市をつなぐ合理的な線としてこうなっているのだ。
モノの売買の場合も同じである。ある業界に仲介業者がいるとしたら、それは一定の機能を果たしているから存在しつづけていられるのだ。与信・輸送・在庫・需要予測・物流加工などなど・・その機能を十分に持たない新生のドット・コム企業が横から割り込んで、売買をひったくれると思うのは傲慢というものだ。
ドット・コム企業の失敗の第二の原因は、売買ということを単純に考えすぎたことだ。調達にせよ販売にせよ、長いサプライチェーンの連鎖の中でとらえなければ十分とはいえないのに、彼らは単純にカタログ商品の売り買いという断面的な次元でのみ、とらえてしまった。カタログ・コンテンツを充実させれば、それで業界のニーズを満たせると思ったのだ。これがドット・コム第二世代、ISP（Industry
Sponsered Providers）とよばれる寄り合い所帯型電子市場の行き詰まりの原因だった。
ハマーが指摘しているのは、インターネットという道具をサプライチェーン・マネジメントという縦の流れを差配する道具として使わずに、売買市場という断面だけに適用しようとした愚かさなのだろう。
高い山脈の上に高速道路を引いても、誰も使わないことは皆の目に明らかだ。そんな無謀な事業にアメリカのベンチャー・キャピタルは何十億ドルという金を投資してしまった。金をドブに捨てる、とはこのことだ。その投資の波が、潮が引くように退いていった後の砂浜がいまのシリコン・バレーである。あちこちで砂の城が崩れかかっている。
もっとも、１０年前に、誰も使わぬゴルフ場やリゾート開発に巨額の金を投資した東洋の国では、今や「財政出動」の名目で、誰も使わぬ本物の高速道路に公的補助を出し続けるべきかどうかでもめている。今、むだな公共事業をつづければ、将来さらに自分の首を絞めるのは明らかなのに、そのことすら気づかないエコノミストたちが存在するのは不思議である。
お祭りの時代は終わったのだ。正気に返って、本当に意味のある投資は何かを考え直す時である。
1996年の夏。私は中東で、ある会社の役員会議室に座っていた。私の隣にはCAP Gemini Americaの上級コンサルタント。そして目の前には米国人とアラブ人の役員たちが、豪華な会議テーブルを囲むように並んでいる。
会議の議題は、「この会社のKPI=Key Performance Indicesとは何か」だった。会議は隣にいる米国人コンサルタントがリードしていく。私と彼は、この会社にERPパッケージSAP
R/3を導入するプロジェクトを請け負っており、要求分析をやっていた。すでに日常業務の分析はすんで、今や、役員から見たソフトの必要機能を定義する段階に来ていた。
SAP R/3は財務諸表をリアルタイムに見せることができる能力が売りだ。しかし経営の舵取りには、財務諸表の数字だけでは不十分なことは明らかである。では、いったいどの数字に着目し、どの尺度を用いて、会社の方向や速度を計りたいのか。それがテーマだった。
しかし、このコンサルタントは、いきなりこの命題にとりかからずに、まず単純な一つ質問を役員たちに出したのである。「いったい、この会社の使命
Mission は何か？ それを簡単なセンテンスで言うと、どう表現されるのか」と。そして、こうつづけた。
会社というものは、たとえそれがどんな小さなものであれ、何らかのMission Statementを背負っているはずである。そして、そのMissionを達成するための、４つか５つの戦略
Strategyが確立されていなければならない。そのStrategyが明確であれば、その達成度を測る指標としてのKPIも、自ずから明らかになるはずである・・・
米国流の論理でいうトップダウンの経営理念とはこういうものなのか－－横で聞いていた私は、率直に感心した。私は中小企業診断士として多少は経営学についても学び、また、企業経営には中心となる理念が必要だ、と考えはじめたところだったから。
「ところで。」と、そのコンサルタントはつづけた。
「皆さん方の会社にMission Statementなどが存在しないだろうことは、じつは重々承知している。」－－こう言うのである。
「だから私も目標達成のための戦略について、あえて問いただしたりはしない。むしろ、役員の皆さんがおのおの自分の担当する範囲で、何を物差しとして選びたいか、率直に言っていただきたい。」
つまり、現実家の彼は、中東のこの合弁会社が自国の利権を守るために米国資本に作らせた、<<便宜的結婚>>の産物であることを知っていたのである。その結果、KPIは戦略実現を助ける道具ではなく、定常業務改善のためのメーターにすぎなくなることも承知していたのだった。
目的を持たないシステムは、自己の安定化と存続が目的となる。これが人間系のからむ全てのシステムに共通する特徴だ。いや、人間のからまない通常のエコシステム＝生態系だって、そう「解釈」することはできる。しかし生態系には自己意識も意味づけもない。一方、困ったことに人間はつねに意味をもとめて生きる動物だ。
お金儲けが企業の究極的なゴールである－－こういう議論を読むたびに、私は、Ｇ・Ｋ・チェスタートンの
「徹底して現世的な人間には、じつは現世のことはよく理解できないものだ」
という言葉を思い出す。人はお金がなくては生きてはいけないにもかかわらず、お金のためだけでは喜びをもって働けないからだ。人はパンのみにて生きるにあらず。どんな仕事であれ、それを多少は「好きだ」と思えるところがなければ続けられない。まことに不思議なことだ。
「好きだ」と思えるところに、人は価値を、そして意味を見いだす。人が生きていくとは、自分にとっての意味を再生産しつづけることに他ならないのだろう。
いま、私たちが対決しなければならない相手は、「存続だけが自己目的化してしまった日本企業の病」だ。数値目標でしかない理念、抽象的で無内容な理念ではなく、意味のある経営哲学をつくり上げていくプロセス、それが求められている。
思うに、そのような「意味」を、ただ単に外部のコンサルタントから与えられても、それは決して自分の身には付かないだろう。自分で考え発見したことでなければ、本当の自分の意味にはならない。であるならば、はたの人間ができるのは、答えではなく問いを与えること、なのかもしれない。
コンサルタントにできることはせいぜい、理念という名前の「ヒント」を提示すること、そしてそれを人間集団の中で磨き上げるプロセスを整備していくことなのではないか。そう最近は思っているのである。
ＳＣＭからマテリアル・マネジメントへ
（2002/1/19）
「Supply Chain」という言葉を私がはじめて聞いたのは、今から約６年前のことだ。そのころ私は、米国のシステム・インテグレーターと一緒に、ある石油メジャーの関連会社にSAP
R/3を納入するプロジェクトに関わっていた。そこで扱ったのは、プラント保守で必要とする予備品で、その資材管理と調達をメインとする、Sourcing中心の業務だった（予備品の所要量はMESの一部であるCMMSすなわちComputerized
Maintenance Management Systemで計算した）。が、それでもサプライチェーンという概念の持つ力を実感するには十分だった。
そのあとしばらくして私は、「サプライチェーン・マネジメントがわかる本」という入門書をＳＣＭ研究会の仲間とともに書くことになる。この本ではもっぱらサプライチェーンの計画系の機能に焦点を当てたため、上記のような実行系の地味な部分はあまりふれていない。サプライチェーン・マネジメントの中心命題は“需要と供給のバランシング”であり、ＪＩＴ思想の強い日本では計画系への理解がひどく手薄なためだった。
ところで、実行系は地味だと書いたが、これはいざやってみるとかなり手強い仕事である。とくに、取り扱う資材＝マテリアルの種類が千を超えると格段にむずかしくなる。上記プロジェクトではSAP
R/3のMMモジュールを中心に、SD, QMなどの一部を利用したが、品目マスタのエントリーは万を超していた。これにBOMと購買情報を付け加えるのだから、まさにデータの藪の中である。
品目数が増えると、何かがちがうのか？ 単にデータの量的な差であって、システムの機能の違いにはならないはずではないか？ －－そう考える人もいるだろう。
しかし、無論ぜんぜんちがうのである。量的な差は質的な変化をうながす。これが理解できるかどうかが、情報技術者としての駆け出しとプロの違いだと言ってもいい。
品目マスタ、英語で言うMaterial Masterには、およそ製造業で扱う「マテリアル」のありとあらゆるバリエーションに耐え得るだけの能力がなくてはいけない。マテリアルといったとき、そのモノが持つ質料と形相、機能と構造が十全に識別可能な形でサポートされていなくてはならないのである。
私の働くエンジニアリング業界では、プロジェクトごとに「マテリアル・コントローラー」と呼ばれる職能の人を置く。プロジェクトで扱う品目数は直接資材だけでも、ゆうに万を超すから、コントロール専門職がいなければトラッキングすることだっておぼつかない。しかし、それでも、マテリアルの需給バランスを先読みして動かす、真の意味の「マテリアル・マネジメント」はまだまだ出来ていない。後追いのコントロールがせいぜいなのだ。
多くの製造業では、BOM情報がバラバラで一元管理できずに悩んでいる。MRPの教科書にはいかにも易しそうに書いている部品表だって、じつは非常に奥の深いものなのだ。
製造業とはマテリアルを供給することで価値を生産する業態のことである。そして、製造業にとって「マテリアル・マネジメント」は今やもっとも大きな課題であると言ってもいいだろう。
Follow me!
