タイム・コンサルタントの日誌から（2005年）
製品という名のシステム、工場という名のシステム （2005/11/15）
工場の性能とは何か（2005/11/08）
プロマネの鍵、貸します （2005/10/07）
納期短縮三箇条 （2005/09/21）
プロジェクト管理指標－－そのダイナミクスの構造 （2005/08/28）
プロジェクトにおける人的資源管理とは （2005/08/21）
プロジェクト採算管理は重要か （2005/07/13）
生産技術というお仕事 （2005/06/14）
プロジェクト・マネジメントの品質（その２）－－固有技術と管理技術
（2005/06/05）
プロジェクト・マネジメントの品質 （2005/05/21）
エネルギー産業のパラダイム・シフト （2005/04/27）
ICタグと、私の唯名論 （2005/04/18）
ＢＯＭデータ共有の夢と現実 （2005/03/21）
良い会議 （2005/02/15）
ＢＯＭ＝部品表の原点とは （2005/01/03）
製品という名のシステム、工場という名のシステム
（2005/11/14）
工業製品を、その成り立ちに応じて「モジュール型」「すりあわせ型」に分類したのは、『能力構築競争』などの著書で知られる東大経済学部の藤本教授だと言われている。工業製品の種類や範疇は無数にあるが、それを経産省工業統計のような品種別の縦割り分類で考えずに、ＢＯＭ（部品表）の構造上の特徴にしたがって位置づけをして見せた着眼は見事である。ほとんど構造主義的発想と言ってもいい。
「モジュール型」と「すりあわせ型」の違いは、部品を組み合わせて製品を作っていく際の設計の違いにある。前者は、部品群を単機能的な小単位（モジュール）に作り上げ、そのモジュールを組み上げて製品を作る。それに対して後者は、多数の部品を精密に組み合わせて製品を作る。モジュール型の製品においては、モジュール同士の間の界面はある程度、標準化されて決まっており、相手がどこのサプライヤーのどの製品であっても、組み合わさって機能する。これに対して、すりあわせ型の製品においては、部品はそれぞれ当該製品専用に作られており（言いかえれば個性を持っている）、組み合ってきちんと働く相手は決まっている。
ＰＣなどはモジュール型製品の典型である。ディスプレイ、キーボード、ＣＰＵ、マザーボード、ＨＤＤ等々はモジュール化されており、それぞれ業界標準のインタフェースに従って接合できる。だからマルチベンダー化がたやすくできる。これに対して自動車はすりあわせ型の典型であって、フィットのボディにカローラのエンジンを載せたりすることは絶対にできない。
これをシステム・エンジニア的な視点で見れば、モジュール型の製品は疎結合のシステムであり、他方、すりあわせ型は密結合のシステムである、と考えることもできる。すると、両者の長所と短所もおのずから想像できよう。密結合のすりあわせ型システムは、効率は高いが、改良・改善となると手をつけなければならない範囲が広く、保守はメーカーに頼らざるを得ない。これに対して、疎結合のモジュール型システムでは、オープンな仕様でモジュールを選べるから、価格的には安くできる可能性が高い。しかし、組合せの不整合（相性）のリスクがあるし、効率は多少落ちることになる。それぞれの産業がどちらの方向に行くかは、市場特性や製品の発展史などで変わり、どちらかが絶対的によいわけではない。
ところで、私のように製品を「システム」として捉える考え方は、あまり多くの人はしないようだ。たいていの人々は「システム」というと、コンピュータかソフトウェアか、あるいはコンピュータを内蔵したインテリジェントな機械類だけを想像するらしい。今どき、冷蔵庫だって炊飯器だってマイコン内蔵だが、“うちのシステムからビール出してよ”と頼んでいる人はたしかに滅多にいない。“今日のシステムはいい味がするなあ”とつぶやきながらご飯を盛る人も少ないかもしれぬ。
しかし、複数の異なる機能を持つ要素を組み合わせて、特定の意図した機能を全体で実現する仕組みのことを、本来は「システム」と呼ぶのだ。そこには別にコンピュータが介在しようとしまいと関係がない。ジェームズ・ワットが発明した蒸気機関には、機関の回転数を一定にするための巧妙な弁の仕組みも内蔵されており、安定制御のためのフィードバックが行えるようになっていた。文句なしに立派なシステムである。
システムというものの特徴は、要素だけをぽんぽんと並べても、全体の機能や性能を達成できないことである。この点が、少々、普通の実物経済の思考回路をはみ出す点だ。１＋１＋１で３ではなく５の価値を生み出そう、というのがシステムである。よく、製品の値段交渉のときに、部品の原価に立ち戻ってあれこれいう購買部門の人がいるが、それだったらあんた、自分で最適な部品の組合せ方を見繕ってみないさいよ、という気になる。そうした「システム設計」の知恵と、組合せで正しく動く「統合」のリスク低減に、価値を認めるべきなのだ。
システムのもう一つの特徴は、使い手の使い方と、環境条件によって、パフォーマンスが異なる点だ。自動車を、高速で飛ばすのか、町中でちょこちょこ動かすのかでは、平均速度も燃費も違う。無論、適した車種も異なる。これはシステムというものが単機能でない以上、当然のことだと思う。しかしこの点も、よく見逃されているようだ。
そして、実は「工場」というものも『システム』なのだ。そんなこと、どの生産工学の教科書にも書いていないが（少なくとも私は見たことがない）。工場もまた、複数の異なる機能の生産資源を組み合わせて、いろいろな製品の産出という機能を全体で実現するための仕組みである。始末に負えないことに、生産資源の中には“人間”という、えらく気むずかしくて再現性のわるい、モジュール化しにくい要素もある。環境も、使い方（生産方針・生産計画）もいろいろと変わる。
そして、工場というものがシステムである以上、それを構成するためのシステム・エンジニアという職種と、それを支える工場作りのシステム工学がなければいけないはずなのだ。何をどう流し、どう集積し、どこでボトルネックを緩和するのか。それが上手にできている工場と、単にモノを並べただけの工場では、同じ製品を作っても、生産性には雲泥の差が出る。こうしたことを、「日本帰りの進みつつある」製造業の人々に、もう一度よく考えてみて欲しいと私は願っている。
エンジニアリング会社で工場作りの仕事に従事していると、ときどき、工場の生産能力というものに関する、奇妙な誤解に遭遇することがある。ご承知の通りエンジニアリング会社というのは、顧客のために、顧客に成り代わって工場を設計し、実現する仕事を請け負う。ある意味では、製造業における生産技術部門、あるいは工務部門のアウトソーシング先だから、しばしば顧客の新製品づくり、あるいは新製造プロセスづくりのプロジェクトに協力することになる。
エンジニアリングは具体的なモノを売っているわけではなく、あくまで工場の設計・調達・プロジェクト管理能力などの、目に見えない『能力』を商品として売る行為だ。当然ながら、仕事の成果について、どれほどの実力があるのかが問われることになる。もっと具体的に言えば、「はたして新工場は必要な量だけ製品を作る能力を持っているのか」が問題になる。これを工場の性能保証と呼ぶ。
プロセス産業の世界では、しばしば製造プロセスの特許技術を海外先進企業から有償で導入することがある。たとえば、いまや世界の主要な産油国はあらそってＬＮＧプラントを作っているが、その中核となる深冷熱交換器とガスタービンは、事実上、米国企業が技術を握っている。ＬＮＧプロセスの性能（生産能力）が年産３００万トンの計画だとすると、エンジニアリング会社は、その性能保証を求められる。その保証の根本は、中核となる深冷熱交換技術のライセンサーに依存することになる。
ところで、ＬＮＧプラントというのは、ある意味で極めて特殊な工場で、そこで生産する製品はＬＮＧ１種類しかない。単品大量生産の工場なのである。それでは、多品種少量を志向した工場（つまり、現在では殆どの工場）では、生産能力は保証できるのだろうか。そもそも、多品種少量生産工場では、何を「生産能力」として定義するのだろうか。
意外にも、この問題は生産工学の教科書などを見ても、あまり書いていない。“明白すぎる”と思われているのかも知らないが、私にはそれほど自明なこととは思えない。連続生産の化学工場ならば、たしかに化学工学が計算式を教えてくれるが、ちょっとでもバッチ操作や切替が介在すると、話は簡単ではなくなる。まして機械組立加工や、食品・医薬品その他のディスクリートの世界では、どう定義すべきなのか。
私の答えは、こうだ。工場は生産資源の集合である。そこで、もし、ある製品が原材料から最終完成型になるまでに、１個当たり平均τ時間だけ、生産資源を占有すると仮定しよう。工場内の生産資源の総量をＣとする。すると、この工場がその製品だけを製造した場合、その生産能力Ｐは、
Ｐ＝Ｃ／τ （個／時間）
となるはずだ。この式は、生産能力は製造資源の量（たとえば加工ラインの数）に比例し、純粋な製造リードタイムに反比例することを教えている。もっとも、正確には、工場の始業・終業の効果を計算に入れなければならないが、ここでは省く。
では、複数の製品が流れるときはどうなるのか。品種間の段取替え時間を無視すれば、製品iがτiづつ製造資源を占有すると考え、積和を計算することができる。
Ｃ＝ΣＰiτi
この式をよく見れば分かるとおり、工場全体の生産能力（ΣＰi）というのは、どの製品をどれだけの割合で作るかによって変わってしまう。リードタイムの長い製品の割合が多ければ、能力は全体として下がるし、その逆も真なりだ。まして、品種切替の段取り時間は、現実には決して無視し得ない。
ということは、複数品種を生産する工場の「総合性能」は、生産計画に依存するわけだ。そして、工場の設計者は、もはや総合性能など保証できなくなる。なぜなら、生産計画は（誰でも知っているとおり）需要という外界の影響によって、どんどん変わりうるからだ。工場の性能は動的属性なのである。
これは、自動車の問題に置き換えてみるとよく分かる。自動車の走行速度は保証できるかといわれたら、テストコースでの最大速度だったら保証はできる。機械的性能の検証はできるからだ。しかし、町中での平均走行速度を保証しろと言われても、それはできかねる。とうぜん、道がどれくらい混んでいるかに依存するからだ。
したがって、エンジニアリング会社の立場に戻ると、できるのは単体製品の製造能力の保証だけ、ということになる。工場という物は、機械設備と作業者と空間からなる、巨大なシステムである。そのシステムの総合的パフォーマンスは、環境と運用方針によって変わる。それは静的なものではないので、せいぜいできることは、仮定をおいてシミュレーションをしてみせることなのだ。
私はこのことを、もっと多くの、製造業にたずさわる人が理解して欲しいと思う。工場の総合生産能力とは、それを運用するポリシーによって変わる。それは他人に保証させるべきものではない。どんなに高速なエンジンを積んだ車でも、１０ｍごとに信号で止まるような環境で使っていたら、それは無用の長物というべきものなのだ。
往年の名画『アパートの鍵貸します』に、忘れがたいシーンがある。終幕近く、主人公（ジャック・レモン）が上司に、いつものとおりアパートの鍵を貸してくれ、とたのまれる。彼は鍵を渡すのだが、上司はそれを見て、叫ぶ。「これは役員用バス・ルームの鍵じゃないか！」。
アメリカの会社には、どうやら役員専用のトイレがあるらしい。社長が平社員に混じって、社員食堂で平気で食事をする日本では、想像しにくい話だが、その鍵は、役員であることの象徴なのである。米国で暮らすと、あちこちに鍵が要るので、すぐ鍵束がじゃらじゃらと重くなってゆく。ことに自宅の鍵は、外敵から物理的に身を守る盾であって、決して人に貸すものではない。
そのアパートの鍵を、不倫の密会用に上司に貸すことで、主人公は代償として出世を手に入れてきた。そんな行き方がリスキーであることは、うすうす感じていただろう。しかし、その彼も、自分の部屋で、若い女性（シャーリー・マクレーン）が睡眠薬を飲んで倒れているのを発見したときに、はじめて潜在的な「リスク」が具体的な「イシュー（問題）」になって、身に降りかかったことを知るのである。
“プロマネを数人、貸してくれませんか”－－そんな依頼が、ときどきある。中には、“できれば派遣社員の単価で”という虫のいいオマケまでついたりする。腕のいいプロマネは利益の源泉であって、それを安い費用で貸し出したら、私の勤務先は干上がってしまう。プロマネを貸すことは、自分のアパートの鍵を貸すのと同じくらい重大なことなのだ。
それでは、プロマネの適正な価格はどのように決めるべきだろうか。これについて明確に書いた本は、まだ読んだことがない。私の会社の経営者は、腕の良いプロマネをどこからか連れてこられるのなら、１億円払っても惜しくないと考えるだろう。エンジニアリング業界では、大きなプロジェクトは予算額が１千億円を超える。プロマネがヘタをうったら、赤字だって数十億円に迫るだろう。これが仮に半分で済んだら、プロマネ代１億円だって安いものではないか。
アパートの扉や壁が、住人を外敵から物理的に守ってくれる存在なら、プロマネは巨大なリスクから会社を守ってくれる、扉の鍵にあたる存在なのである。古代の中国人は、万里の長城という途方もない壁をこしらえたが、この防護壁の機能は、門を守る将軍の一人が外敵に対して門を開いてしまったことで、完全に無に帰した。鍵は掌に握れるくらい小さい。材料でいえば原価は数百円だろう。しかし、リスクの観点から言えば、その価値はきわめて大である。プロマネも同じで、人件費単価で貸し借りできるものではない。
「プロジェクト・ダイナミクスの構造」にも以前、書いたとおり、プロジェクトの問題発生には階層的な構造がある。問題事象が最初に発見される場所は、コストである。しかし、その原因は、たいていスケジュール遅延かスコープ漏れである。それらは品質・調達・人的リソースの問題から引き起こされる。そして、遠因は、たいていリスク対処とコミュニケーションの失敗にある。リスクの感覚は、プロジェクト・マネジメントの根底課題なのである。
では、リスク感覚はどのように磨かれるのか。それは何よりも、経験の蓄積を通じて磨かれるのだ。プログラマの世界には若い天才がときどき現れるが、プロマネには若い天才は存在し得ない。それにくわえて、プロジェクト対象となる分野の固有技術についての一通りの理解がなければならない。そうでなければ、この先何が起こりそうか、どうして分かるだろうか。
プロマネに必要な三要素は、経験から得たリスク感覚と、固有技術への理解と、管理技術である。最初の二つは、組織の中で時間をかけて育てていくしかない。最後の一つだけは、座学でもある程度は身に付くし、たとえば「e工程マネージャー」のようなツールの形で借りてくることもできる。
こうしてみると、借り出したプロマネを、ぽーんと一人で見ず知らずの組織に放り込んで、プロジェクトが機能する訳がないことが分かる。プロジェクトとは複数の人間が共同して行なう仕事だ。周囲とのコミュニケーションのポイントも分からず、固有技術も分からず、過去の経験もなければ、リスクをマネージしようもない。
『アパートの鍵貸します』は、人生の危機を乗り越えたジャック・レモンが、地位や金銭を捨てて真実の愛情を手に入れるシーンで終わる。ビリー・ワイルダー監督は、その場面を繊細で美しい白黒の映像で撮っている。彼にとって一番大事なものは、貸し借りでは決して手に入らないものなのだ。
私はタイム・コンサルタントである。「時間の悩み」を抱えるクライアントに対して、解決へのアプローチを示すことで、プロフェッショナルとしてのビジネスを成立させている・・・と、自己紹介には書きたい。できれば。
しかしまあ、現実はなかなかそう甘く行かない。タイム・マネジメントの仕組みを提案するだけでは、なかなかビジネスにはならないのだ。生産スケジューリングやプロジェクト・スケジューリングの仕事をしていてつくづく感じるのは、『やっぱりコスト削減が優先』という圧力の強さである。製造業や流通業向けのＳＣＭシステム構築の課題は、物流費の削減が真っ先にくる。納期短縮は、「それもできたらやりたい」であって、部分目標でしかない。だから私は、パート・タイム・コンサルタントという存在だ。
コスト競争はすでに行き着くところまで行ってしまった。あとは非価格競争力の問題で、性能だとか品質だとかも大事だろうが、納期で勝負すべきだ。"Time
is Money"にも書いたとおり、私の主張はこの点にある。
ところで、うっかり作りすぎてしまった製品は、在庫となって財務諸表に現れる。それも不思議なことに、さも資産であるかのように。ところが、納期を遅れて売り損なった注文は、財務諸表のどこにも現れない。だから、それは見えないコストとなり、経営の関心の外になる。こういう心理的メカニズムが、どこかで働いているにちがいない。
それではもし、そうした心理的な霧が晴れて、納期短縮が重要だと気づいたら、どうしたら良いのか。私だったら、３箇条の処方箋を書く。
（１）「隘路に集中すべし」
クリティカル・パス（隘路）を見つけ、その短縮に集中すること。いうまでもないが、クリティカル・パス以外の作業をいくら努力して短縮しても、全体の納期は早まらない。この原理を、皆が理解する必要がある。これはとくに、新製品開発の納期において大事だ。むろん、設計に手こずりがちな受注生産形態でも共通の処方だが。
全員の目標を、納期短縮に向けることが、何よりも重要である。設計部門は性能を、購買部門は資材コストを、製造部門は作業効率を第一に動いていたら、誰が納期に責任を持つのか？
（２）「進捗を皆に見せるべし」
進捗が見えると、事前に準備できる。じつは、これが大きいのだ。バトンリレーも、事前の助走が大事だろう。人間は賢い存在で、先読みができる。言われたことだけをやるロボットとは違う。多くの企業では、部門の壁や、事業所の地理的な分散によって、他の仕事の進捗が見えて来ない。これを見えるようにしてやるだけで、納期は１－２割程度短くなると言っても過言ではない。
進捗がいったん後退したら、その事実を直視することも重要だ。とくに設計業務は、環境変化や客先の気まぐれで、いったん決まったはずのことが元に戻ってしまうことが多い。「こういう手戻りが生じる業態では、プロジェクト・スケジューリングの道具など使えますか？ 使えないでしょ？」などとセミナーで反論されたこともあるが、無論、使えるのである。
進捗というのは、“これまでどれだけ工数をかけたか（努力したか）”ではなく、“あとどれだけ仕事が残っているか”で測るべきものだからである。もし手戻りしたら、進捗率は下がるべきなのだ。それが事実なのだから、仕方がない。この質問者は、「進捗は下がってはいけない」という理屈（願望？）と現実把握を取り違えておられるのだろう。マネジメントというのは、客観的な事実認識からスタートすべきものなのだから。
（３）「時間はお金で買うものと思うべし」
納期短縮にはコストとリスクがつきまとう事を理解すること。納期を短縮するためには、ある程度先読みをして、準備や手配をかけておく必要がある。ここには推測が入るため、ずれや手戻りのリスクも生じる。急いだ分、余分なコストがかかってしまうのだ。これを逆に表現すれば、お金を節約しようとすると、時間がかかる、ということになる。
時間とお金との間には、トレードオフの関係がある。お金を取るか時間をとるか、マネジメントが指針を下すべきなのだ。「繁忙期には納期優先で考え、閑散期にはコスト優先で行こう」という顧客がいたが、これはとても立派なポリシーである。トレードオフの状況でどのような判断を下すべきかを定めた指針を、企業の「戦略」ないし「ポリシー」と呼ぶ。
そして、困ったことに、戦略もポリシーも持ち合わせていない会社が、じつはとても多いのだ。選ぶとなると必ず、目に見える「お金」になってしまう。だから私は、いつまでたっても、パート・タイム・コンサルタントでしかないのである。
PMBOK Guideの編纂者たちが、いわゆる「９つのマネジメント領域」を定義したとき、そこにProject
Integration Management＝プロジェクト統合管理を入れたのは卓見だった。これ以外の８領域、すなわち、コスト管理、時間（スケジュール）管理、スコープ管理、品質管理、人的資源管理、調達管理、リスク管理、コミュニケーション管理、は、それぞれが独立した管理対象範囲を持っている。
（ところで、以前「マネジメントと管理はどこが違うか」にも書いたとおり、私は『管理』という日本語が嫌いだ。だから、こうやって８回も９回もくり返して書かされると、ちょっとうんざりしてくる。管理という用語はあまりにも多義性の言葉で、あらゆる物事を曖昧に片づけてくれるので、ひどく便利な魔法の道具になってしまう。私は、仕事の内容を正確に表現したいので、普段はあえて、マネジメント／コントロール／アドミニストレーションの３つのカタカナ言葉を使うようにしている。）
さて、独立した対象範囲があるということは、いいかえると、指標化して管理しやすいということだ。その典型がコスト管理である。コストは誰の目にも明らかなお金の数字で表現される。そこには曖昧さはみじんもない。そして、指標として重要である。それも、ふつうは組織の階層を上に行けば行くほど、コストの重要性が増し、その他の領域、たとえば技術品質や人的資源などの重要性が小さくなっていく。平社員ならばコストを度外視して技術的達成に打ちこんだりするかもしれないが、経営者でそう行動する人は稀だ。
したがって、経営層がプロジェクトを見るときは、たいていの場合はコスト指標が最大の管理指標になる。だから、自社のプロジェクトの遂行能力を向上しようとすると、まず採算向上が目標になり、原価管理のツールがまっさきに整備される傾向が強い。
ところで、採算というものは、コストだけ「管理」していれば、目標を達成できるものだろうか？ じつは、採算の悪化している赤字プロジェクトの内部をよく調べてみると、もう少し別の事情が分かる。
たとえば、エンジニアリング業界での典型的な失敗プロジェクトは、次のようなパターンで起こる：まず、きびしい受注合戦の中で、かなり無理をした安値で受注する。そのままでは最初から赤字が予想されるので、プロマネは原価を下げるよう必死に努力する。この業界ではベンダー／サブコントラクターからの調達金額がコストのかなりの部分を占めている。そこで発注金額を下げるために、リスクはあるが安いベンダーを採用したり、あるいは延々と金額交渉に時間をかけざるをえない。
結果として、次第にプロジェクト・スケジュールが遅れてくる。おまけに、予算上の予備費を取れないために、プロマネはリスク要因に対処できる余地が無くなる。だが、プロジェクトでは予期できない突発事象が必ず起きるものだ。たとえば、安いベンダーの納品物がまるきり品質が低くて使えなかったり、あるいは途中で倒産してしまったり。こうして、プロジェクトはさらに遅れてしまう。しかたなく、スケジュールの挽回をはかるため要員をもっと投入する。こうしてコストはどんどんと膨らんでいく・・
おわかりだろうか。プロジェクトの採算が悪化する直接原因は、スケジュールにある。そして、スケジュール遅延の原因は、品質保証や調達の失敗にある。さらにその元をたどっていくと、コミュニケーションやリスクの問題につきあたる。
このように、ある管理領域で見つかった問題の根幹は、たいていは別の管理領域の失敗に起因するのだ。それは一種の玉突き現象に似ている。問題事象が最初に発見される場所は、コストである可能性が高い。数字で表わされ、鵜の目鷹の目でチェックされるからだ。しかし、コスト・オーバーランの原因は、たいていスケジュール遅延かスコープ漏れである。その原因は、さらに品質・調達・人的リソースの問題にある。そして、これらの遠因は、たいていリスク対処とコミュニケーションの失敗にあるのだ。だから私は、プロジェクト原価管理システムを構築すれば原価を管理できる、というような発想に反対なのである。
PMBOK Guideのいう管理領域は、すべてが独立で対等ではないことを知るべきだ。そこには、階層的な因果関係がある。それが、プロジェクトというものの、ダイナミクスを形づくっている。だからこそ、『プロジェクト統合管理』が必要だ、とPMIの先覚者たちは感じたのだろう。プロジェクト・マネジメントを考える者はみな、そのダイナミクス（動力学）をもっと真剣に学ばねばならないのだ。
プロジェクトにおける人的資源管理とは
（2005/08/21）
アメリカの新聞連載マンガに"Dilbert"というのがある。作者はScott
Adams。現代アメリカのハイテク企業における馬鹿馬鹿しさをとても辛らつに皮肉っており、毎日読むのを楽しみにしている（Webサイトでも１日遅れで読める）。ことに、主人公Dilbertと、彼の上司で無能なマネージャーとの対話をあつかった話は、いつも吹き出すほどに面白い。
米国のマンガは基本的に、時事問題を扱わないのが特徴だ。チャーリー・ブラウンのシリーズなどは、何十年前のものを読んでも、同じような感じで、いつまでも古びずに楽しめる。しかし、Dilbertはあえて最新のトピックや用語をネタに取り入れる。古くなる危険性をあえておかしつつも、ビビッドな問題意識をギャグにしているわけだ。
私の好きな話の一つに、Aliceという女性のベテランSEが、キャリアアップを望む若い事務職の女の子に、仕事について説明する話がある。「エンジニアになるには、何年もの訓練が要るの。」とAliceは説明する。「でも、エンジニアのボスになるのは、何の訓練も要らないのよ。」（ここで読者は、例の無能な上司を思い起こす）「あれって、スキル不要の、苦労のない労働なの。」これをきいて若い事務職の女の子は言う。「それなら、私にもできそうね。」
マネジメントは、何のスキルもトレーニングも無しで出来る仕事だ。そう断言すれば、反論する企業はいくらでもあるだろう。我が社では、かくかくの適性検査や昇格試験があり、またしかじかの管理者教育を実施している、と。しかし、少なからぬ日本人や米国人が、このDilbertのマンガに少しでも可笑しさを感じるのだとしたら、やはり無能な管理職が太平洋の向こう側にもこちら側にも大勢いることを示しているはずだ。
なぜ、マネジメントは"スキル不要の職能"と思われているのか。それは、マネジメントの地位と職能が不可分の状態になっているからだ。管理職の地位に配置されたら、部下を管理できる、と誰もが信じて疑わない。部下を管理するとは何か。部下に命令や目標を与え、部下を評価して賃金の格付けをすることだ、と思われている－－普通は。
だが、プロジェクトはちがう。「プロジェクト・マネージャーは管理する専門の職能だが、地位ではなく単なる役割だ」などと言うと、皆が目を白黒させてしまう（「生産計画ワンポイント講義の『役割（Role）としてのプロジェクト・マネージャー』参照）。職能と地位を分離して考えられないからだ。
年功序列の日本企業では、管理者の地位にはある程度、経験年数の裏書きがある。しかし会社の創始者の息子が『世襲』するケースもある。日本には、上場しているが内実は同族企業、という会社も多いので、そういうところでは、キャリアのない「若様」が、ポンと重要な地位につくことがある。地位につけば、すぐに管理の仕事を始める。こういう世界に働いていると、たしかに「管理はスキル不要の商売」と思いたくなる。じつは米国にだって欧州にだって世襲の会社は多い。だから彼らだって、同じように考えてるだろう。
しかし、ゴーイング・コンサーン、すなわち継続性が自己目的である企業とちがい、プロジェクトとはあくまでも特定目的を達成するための時限的な営為である。明確な目的を持つ組織では、管理者は「管理機能」を果すことが要求される。世襲とか年功序列だけで管理者を決めることは合理性に欠ける。そこで、しだいに地位と管理職能との分化か起こってくる。
さきほど、管理とは部下に命令や目標を与え、部下を評価して賃金の格付けをすることだ、と書いたが、じつは前半がマネジメント、後半が地位に関係する主な項目だ。後半はサラリーマンの生殺与奪の権限だが、これを抜きでどこまで人を動かすことができるかどうかが、プロジェクト・マネージャーにとって問われる『人的資源管理』の手腕なのである。そして、もしも失敗したら、その結果はプロジェクトの品質やスケジュールの失敗に現れてくるのだ（昇進や給与査定はプロジェクトとは関係ない領域だからである）。
PMBOK Guideは「マネジメントの９領域」を定義したが、じつは、プロジェクト管理の９領域は、このような形で、それぞれが独立しておらず、ある領域での失敗が別の領域に結果として現れてくるような関係性を持っている。このことについては、長くなってきたので、また次回語ろう。
はたしてプロジェクトの採算管理は本当に重要か、などというと、常識知らずのレッテルを貼られるかもしれない。とくに、受託開発をビジネスとしているシステム・インテグレーター（SIer）ではそうだ。システム開発プロジェクトは一つ間違うと、億の単位で赤字が発生し、他の数十のプロジェクトで稼いだ利益が吹っ飛びかねない。
だからプロジェクトの綿密な採算管理は必須だ。個別のプロジェクトがいかなる採算状況にあるのかを、マネジメントの側がチェックできる仕組みが求められている。いや、それだけでなく、部門単位でも収支の集計を行なって、採算で目標管理するべきだ－－こういう理由から、最近、大手のSIerではプロジェクト採算管理システムの構築が活発だ。そもそも、システム開発はお手のものだから、自社ニーズにマッチした仕組みを自社内で作ってしまおう。そう考えられておられる会社もかなりある。
でも、ちょっと待ってほしい。かりにあなたが、見知らぬ街でタクシーに乗っているとする。運転手に行き先を告げたが、いつ着くのか、いくらかかるのか、あなたはよく分からない。目安の時間と値段は、あるいは事前にたずねることもできただろう。しかし現実は道路渋滞のために、別の道を通っていたりする。そもそも、運転手は十分信用できるのかどうか。わざと回り道をして、とんでもない料金を請求するのではないか・・・
そんな疑いを持っているとき、あなたは、タクシーの料金メーター・システムが正確であれば大丈夫だ、と思うだろうか？ 着いたときにメーターを見て、金額に驚きはしないだろうか？ いやいや、乗っている最中も、３分おきにメーターを見て料金をチェックしているから問題はないのだ、と考えるのだろうか？ でも、目的地まであと何㎞あるのか分からないのに、現地点までの料金だけ正確に把握したからといって、いったい何の足しになるのだろうか？
プロジェクトの採算管理システムが重要だと信じている人は、タクシーの料金メーターをにらみつづけている乗客によく似ている。すでに過ぎてしまった結果だけを管理しているのだ。そんなのは「管理」の名に値しない。管理というからには、これから先の行為をどうすべきなのか、判断し指示できなければならないからだ。
そのためには、現時点までに費やしたコストと、現時点における進捗データが、完全にリンクしていなければ意味がない。タクシーでいえば、現在地から目的地までの距離が、リアルタイムに正確に分かっている必要がある。そうなれば、あといくら料金がかかって、最終的にいつ着くのかを推定できるだろう。おかしければ運転手に軌道修正を要求できる。そのためには、ＧＰＳとカーナビを積んでいるタクシーを選ぶべきだ。
同様に、プロジェクト採算管理システムを構築するのだったら、プロジェクトの進捗把握と残作業量を同時につかまえられる仕組みにしなければならない。進捗管理とは、「どれだけ進んだか（工数を費やしたか）」ではなく、「あとどれだけ仕事が残っているのか」で測るべきものだからだ。
その点は大丈夫さ。我が社はプロマネから残工数やETC（Estimate to Complete＝完了までの予想費用）をヒアリングして入力することになっているから。そう答えられた会社もある。でも、そのデータは、リアルタイムですか？
多くの会社では、採算の集計は月次に行なわれる。工数集計は人事・勤怠管理システムから集計し、外注費は発注検収システムから受け取る仕組みになっており、そうした会計処理の多くが月次だからだ。だが、システム開発が短納期化して、６－９ヶ月のプロジェクトが珍しくなくなってきた昨今、はたしてこれでリアルタイムの把握といえるだろうか？ へたをすれば、プロジェクト全体の１／６＝１７％の誤差が、集計遅れのために発生しているのだ。あなたは１日に４時間も遅れる時計を信用していられるだろうか？ 私はごめんだ。
採算管理は進捗管理とセットでなければ意味はない。会計処理ではないのだから、１円単位の正確さは不要だ。しかし、プロジェクトの進捗状況にひもづいたコストが、最大でも１週間以内に集計されてこなければ役には立たない。そのためには、進捗と消費工数を、プロジェクト・チームの構成員全員が、毎日入力できるようになっている必要がある。外注作業についても、同様に進捗（出来高）がリアルタイムに見えるべきだ－－「e工程マネージャー」の設計思想は、そこにある。
べつに我が製品だけを宣伝するつもりはないが、採算管理とはそういう観点から考えるべきものなのだ。プロジェクトの失敗は、たしかに採算割れに現れる。しかし、それは最終結果なのだ。タクシーの料金メーターだけを見ても、それは結果論に過ぎない。運転手が道を間違えているとき、それに途中で気づくためには、リアルタイムの進捗管理が必要なのである。
製造業にとって、製品開発のスピードは競争力のキーになる。製品開発は一般に、核となる要素技術の発明、ないし市場における新しい動向がきっかけになって始められる。むろん、業種によっては、毎年定常的に多数の新製品を出し続けるところも少なくない。そうしたケースでは、製品開発までの期間がきちんと「読める」状態にまで、管理レベルを上げていく必要がある。
プロジェクト・スケジューリングの技術に関わっているおかげで、最近は製品開発プロジェクトの相談に乗るケースが増えてきた。従来、製品開発とは「固有技術」だけの世界と思われていた。ところが、近年わずかづつではあるが、プロジェクト管理という「管理技術」も必要なのだと認識される企業が増えてきたようだ。
製品開発となると、ＢＯＭの話題に触れることも多い。今年のはじめに「ＢＯＭ／部品表入門」という本を上梓したこともあって、いかにスムーズに新製品のＢＯＭを構築できるかが議論のトピックになったりする。ことに、設計部品表（E-BOM）と製造部品表（M-BOM）が別立てになっている会社では、とくにその問題意識が強い。
ところで、製品開発プロジェクトの進め方を考える場合も、企業内のE-BOMとM-BOMの統合を進める場合も、どうやらキーになる部署があることに、最近気がついた。それが「生産技術部」である。名称は「生産企画課」だったり「製造技術センター」だったり、まちまちだが、ようするに製造工程を準備する職務をもった部署である。たいていの場合は本社ではなく工場にあり、しかも一種のスタッフ部門として扱われている。
この「生産技術」という職種が、その企業の中でどのように位置づけられているかが、どうやらスムーズな新製品開発や、ＢＯＭマスタ情報の信頼性確保に、大きく影響しているようなのだ。なぜか。それは、生産技術というお仕事の本質が、量産方法の設計と実現にあるからだ。
量産方法の設計とは何か。そもそも、新製品の青写真は、製品設計部門（たいていは本社機能にある）が図面に作る。この段階では、「何をつくるか」（What）が決まっているだけだ。しかし、製造業は、製品を低価格で安定して量産できてナンボの世界である。「いかにつくるか」（How）が大事なのだ。そして、それを決めるのが生産技術である。ここの段階であらためて、どの材料をどう加工して、いかに組み立てるかを検討する。そして、試作品をつくって性能や加工性を評価する。標準作業時間を決めて製造単価を割り出す。ついで主要な部品のサプライヤーを決め、外注する部分を決め、必要な製造装置の仕様を決めてメーカーに発注し、それを工場に据え付ける。
そして量産試作が行なわれる。これが品質的にも経済的にもパスして、はじめて製品は「商品」になるのだ。これが生産技術の主要な仕事である。副次的な仕事として、既設の工場設備の保全とか、据付け工事などの工務管理、製造工程の改善、標準作業の見直しなどがある。
そして、残念ながら、日本の多くの企業では、この生産技術部門の地位が、決して高くないのだ。嘘だと思ったら、あなたの会社で経営工学科出身の学生をどこに配属するか、考えてみるといい。経営工学は生産技術の主要な基礎学問である。そのキャリアパスが定まっていないとしたら、それは生産技術の位置が曖昧なのだ。あるいは、生産技術部門出身の取締役の数を数えてほしい。大抵の製造業の会社では、出世するのは製品開発か営業か財務部門出身者だ。トヨタ自動車のように、生産企画がエリートコースで、出身者が社長になれるような会社は、極めて例外である。
製品開発を重視するというのなら、設計図を現実に落しこむための生産技術を重視していなくてはならない。餅の絵を描くのがいくら上手でも、食べられなければ役に立たない。そして、美味しい餅をつくのは、生産技術部門の役割なのである。
プロジェクト・マネジメントの品質（その２）－－固有技術と管理技術
（2005/06/05）
「固有技術と管理技術を、御社では区別していますか。」－－私は最近、クライアント企業に対して、ときどきこうたずねることにした。プロジェクト・マネジメントにかかわる仕事の場合、この二つを区別しているかどうかが、その企業の質を計るカギの一つになるからだ。
たとえば、以前、こういうことがあった。ある大手ＳＩ企業と共同で事業をはじめることになり、製品開発プロジェクトのために、部下を派遣した。開発作業の主体は相手方が受け持つ形になり、プロジェクトの執務場所は先方のオフィスになっていた。こちらが派遣したのは、プロジェクト・マネジメント能力については信頼できるエンジニアだ。ところが、相手方のＳＥのリーダー・クラスの人が、彼に対してこう聞いたらしい。
「あなたは、われわれの開発技術も知らないのに、どうやってプロジェクトをコントロールしようというのか。そもそもJavaのプログラムを一行だって書いたことがあるのか？」
つまり、自分たちはプロの技術屋だから、管理と称して余計な口出しはしてくれるな、という意味のようだ。“じゃあ、そういうあんたはPERT/CPMやEVAを一度でもまともに実行したことがあるのか？ 標準のWBSコード体系はあるのか？”－－そう言い返したくなるところだが、むろん彼はそんな反論はしなかった。言っても相手は理解せず、喧嘩になるだけだろう。それではプロジェクト・マネジメントの最大項目の一つであるコミュニケーションが、最初から崩れてしまうからだ。
このやりとりには、技術屋の典型的な理解（ないし無理解）が見られる。このＳＩ企業には、固有技術と管理技術の区別がなかったのだ。Java等でのシステム開発は固有技術で、WBSによるコントロールは、管理技術に属する。固有技術は分野ごとに固有のもので、深堀していく性質のものだ。一方、管理技術はプロジェクトと名付けられる行為に共通に適用でき、水平に広がっていく性質を持つ。
ところが、多くの企業では、固有技術の経験を積んだ者が、そのまま管理職のポジションに上がって、「管理業務」をするようになる。せいぜい、“管理者研修”コースの中に、おざなりにでもＰＭ論が入っていれば上出来の方だ。こうして、プログラマがＳＥになり、ＳＥがプロマネに昇格していくという不可思議な進化論の体系が、ＩＴ企業の中にできあがる。製造業ならば、製品設計→開発企画→製品開発ＰＭ、というコースかもしれない。
品質管理とは、ターゲットとなる品質属性を実現するための営為だ。プロジェクトの成果物である製品やサービスの属性、つまり「What」の品質を決めるのは固有技術であり、プロジェクトの納期やコストや要員数などの属性、つまり「How」の品質を決めるのが管理技術である。両者は車の両輪だ。どちらが欠けてもプロジェクトはうまく行かない。
それなのに、多くの企業では両輪の大きさがずいぶん違う。管理技術の方がずっと小さいのだ。いや、ともすると「一輪車」で運転している。これで期日通り仕事が終わったらおなぐさみ、であろう。管理技術が乏しいと、根性でうめ合わせようということになりがちだ。根性論がとびかう職場は、管理技術欠乏症の兆候があると思っていい。
最初に述べた部下は、きちんと仕事を果して、期日通り製品を仕上げて帰ってきた。彼の仕事の仕方を見ながら、次第に相手方もその役割を、その重要性を認識しだしたのだろう。あなたが、彼の立場だったら、最初のやりとりの時にどういう行動をとるか、考えてみて欲しい。
たとえば、その打合のMOM（議事録）を書いて、パートナー両社に回覧し承認をもらって公式化するのも一つの方法だろう。これこれこういった議論があった、両者の意見が出されたが、結論には至らなかった－－こうした事実を記録するのも、MOMの役目である。そして、こまめにMOMを作成し公式化するのは、プロジェクト・マネジメントの主要な機能の一つなのだから。
ISO9000の品質システムは、大抵のいっぱしを気取る企業に導入され、運用されている。そして、疎まれてもいる。この標準規格自体は21世紀に入ってさらに思想を深化させ、今では品質マネジメントシステム（QMS）と自らを呼ぶようになった。しかし、率直に言って、日本企業でQMSを嬉々として運用している所には、私はほとんどお目にかかったことがない。皆が従っているが、内心は無用のものだ、と感じている。保険か税金のようなものだ、と。
私はいまだに、『品質』というものが良く分からない。私自身が製造業の品質管理部門で働いた経験がないせいだろう。工場建設のプロジェクトで品質検査をしたり、システム開発の統合テストを進めるやり方についてだったら、少しは分かっているつもりだ。構成図通りに製作され、指定の材料がつかわれ、仕様書通りに機能する。そういう検査が保証する品質は、『後ろ向き品質』と呼ばれる。軍隊の行進のように、皆がついて来ているかどうか、予定した到達点からずれていないかどうかを、後ろを向いてチェックする。フィードバック・コントロールである。
これに対して、『前向き品質』という概念がある。これは、より良き構造・材質・機能を「設計する」ことで品質を高めることを指す、と。そう参考書に記載もしたし（「プロジェクトマネージャ合格完全対策」）、そう人に言いもした。しかし、では、より良き品質とは何か。それは誰が決めるのか。どう設計で実現するのか。その方法論が必要だ。
ところで、最近北京に出張したおり、中国で活躍しておられる日本企業の方から面白い言葉を学んだ。それは『営業品質』だ。中国では最近まで訪問販売という形式が事実上法律で禁じられてきた。だから法人営業のスタイルがまだ確立していない。しかも営業マンは、周知の通り転職とジョブ・ホッピングの激しい雇用慣習の中で生きている。そこで、どうしても売上高に比例したインセンティブの比率を高くして、成果で競争させる方向にむかいがちだ。しかし、そうすると「営業品質が下がってしまう」というのだ。
営業の品質とは何か。セールスには素人の身で勝手に想像するならば、顧客との永続的な関係維持に寄与できる数々の要素なのだろう。見積を頼んでもすぐに出てこない。出ても間違いだらけで、こちらの意図を理解していない。発注すると納期に遅れる。間違った品物を送りつけてくる。数量が足らない。クレームをしても返事がない。なのに請求書だけは素早い－－こんな営業マンがいたら、私だって二度と頼むものか、と思うだろう。こうしたケースは営業品質が悪い、と呼んでもよさそうだ。
この営業品質というものは、そのメーカーが出荷してくる製品自体の品質とは別のものだ。素晴らしい製品を出してくる、しかし営業は最低、そんな会社もじじつ存在する。しかたなく買うこともあるが、ユーザは幸せではない。
してみると、顧客満足とは、つぎの式で表わされるように思える。
顧客満足＝ｆ（製品品質，営業品質）
関数型はよく分からぬが、おそらく足し算よりも掛け算に近い性質のものだろう。一方、製品品質は次のように定義される：
製品品質＝ｇ（構造属性群，材質属性群，機能属性群・・）
関数型は、ユーザの求める用途や価値観によって左右されるが、おおむね足し算型であり、重みは機能属性が高そうだ。
それでは、価格はどこに入るのか？ これは、営業属性だ。つまり、
営業品質＝ｈ（価格，支払方法，納期，納品精度，クレーム対応度・・）
となる。関数型は、よく分からない。中国では、今のところ圧倒的に価格因子で決まるらしい。しかし日本や他の先進国では、あとの項目の方がもっと重要度を帯びてくるに違いない。
ところで、生産管理の世界では、よく「品質はプロセスで作りこめ」と言われる。製造して、最後に製品検査で後ろ向き品質チェックをするのではなく、製造プロセスの各段階で品質を確保していかなければいけない、という意味だ。だとすると、営業品質にも同じ思想が適用できるに違いない。
受注生産の製品で、プロセスを切り回すのはプロジェクト・マネジメントの役割である。自社製品の開発でも同じだ。そこで、あらためて「プロジェクト・マネジメントの品質」が問題になってくる。ちょっと長くなってきたので、この項はあらためて論じることにしよう。
（注：拙編著「プロジェクトマネージャ合格完全対策」で品質の章を執筆しているのは、畏友・齋藤登志勝氏である）
エネルギー産業のパラダイム・シフト
（2005/04/27）
今年の春の花粉の飛散量は過去最大で、アレルギーになる人が多かった。「花粉症デビュー」なる言葉も登場したくらいだ。私も初めてマスクをして出歩くようになった。その理由として、昨年の夏が酷暑だったことがあげられている。しかも昨夏は後半からは台風上陸の連続だった。気象がどこか異常だ、多くの人がそう感じたにちがいない。
気象の変化と、地球温暖化現象と、大気中の炭酸ガスの増加が鎖のような因果関係をなしているのかどうかは、まだ厳密には検証されていない。しかし、科学的実証が無くとも、危険性があるならばそれを避ける手だてを考えるべきだ－－技術者だったら、たいていそう考えるにちがいない。温室効果のあるガスをなるべく排出しないよう、あるいは低減できるような方策が望ましい。そして、炭素税のような政策論は、その方向を後押しすべく働いている。
ところで、われわれプラント・エンジニアリング業界に働く人間は、最近の10年間で、目に見えないけれどもかなりはっきりした変化の潮流を感じている。それは、エネルギー源に関するシフトである。もっと言えば、燃料としての石油の退潮だ。
石油がエネルギーの主役を降りつつある、といえば、“この１バーレル６０＄の時代に何をのたもうているのだ、供給が需要に追いつかないから高値を生んでいるのに”と批判の声を浴びそうだ。たしかに、昨年『中国が買い占める世界のエネルギー資源』にも書いたように、今の原油相場は中国が石油の輸入国に転じたことが大きな原因である（もう一つの原因はアメリカの石油サプライチェーンが脆弱なことだ）。
しかし逆にいえば、この原油高が１年以上も続きながら、なおかつ世界の産業が崩壊せずにすんでいるのは、エネルギー源が他のソースにシフトしていることを表わしている。それは何かというと、天然ガスなのだ。天然ガスの進展が、最近のエネルギー構造を変えつつあるのである。
エンジニアリング会社の実感として言うと、最近の海外のビッグ・プロジェクトは天然ガス処理プラントばかりで、ほとんど石油精製プラントの仕事は無くなってしまった。２０年前と比率は全く逆転している。昔はプラントと言えば製油所作りが花形だったのに。
天然ガスの利点は二つある。ひとつは、発熱量に比較して二酸化炭素の発生量が少ないことだ（主成分がCH4のメタンであるため）。もう一つの利点は、発生源（ガス田）の近くで、硫黄や窒素など排ガス中の不純物の原因物質を取り除きやすいことである（石油はそうした物質の除去が難しく、石炭となるとほとんど困難だ）。
しかし短所もある。気体は貯蔵しにくく、運びにくいことだ。ガス・パイプラインもあるが、中進国・先進国では敷設にかなりの金がかかる。そこで液化して運ぶことになる。これがＬＮＧ＝液化天然ガスである。
このＬＮＧ製造プラントの技術が、この10年間でかなり進んでいる。一つの装置での処理能力がかなりアップしているのだ。10年前には１系列の装置で250万トン生産できればかなり大型だった。今ではその３倍以上のプラントが実現している。また、最近では全電化ＬＮＧプラントといって、圧縮機の駆動を電力で行なうタイプが現れてきた。
ＬＮＧプラントというのは、言ってみれば巨大な冷凍機なのだが、その中心機器となる圧縮機は、これまではガス・タービンで駆動していた。タービンを回す燃料は、プラント自身のガスを使ってきた。ガスを燃やして、それでガスの冷凍機を駆動していたわけだ。全電化プラントでは、これをモーター駆動で行なう。モーターは電力が回す。その電力はどこから来るかというと、まあ近くに設置する火力発電プラントからもらい、その燃料は（やはり）ガスである。
これでは間に発電器とモーターがはさまる分、エネルギー効率的にロスするだけではないか、と思うかもしれない。その通りだ。しかし、実はそれを上回る大きなメリットがある。それは、運転の自由度が増すことなのだ。自家燃料のガスタービンを圧縮機に直結している旧来のプラントでは、制御が非常に難しかった。とくに、大きな外乱やシャットダウンからの立ち上げが難しい。
これはある意味では当然のことで、プラント自身の（半）製品を利用してプラントを動かしているわけだから、全体が順調に稼働していることが安定稼働の条件なのだ。つまり、あまりにも良く統合され自己完結したシステムは、大きな外乱から回復することが難しい。このことは覚えておいた方が良い。もう１０年以上も不況のトンネルにいる、某国の経済システムを思い出せば、よく分かるだろう。
また、従来の直結駆動システムでは、プラントのレイアウトにも制約が大きかった。何よりも、このような巨大なガスタービンを作れるメーカーは世界でただ１社しかなかった（念のため書いておくが、米国の企業である）。ガスタービンは数年に一度、シャットダウンして保全する必要がある。そのために、プラント全体を数ヶ月間にわたって止めなければならない。そしてかなりの保全費用を払い続けなければならない。いいかえれば、世界のＬＮＧは米国の１企業に首根っこを押えられていた訳である。
このくびきを断ち切る意義は大きい。運転上・経営上の自由度が、はるかに増すからだ。オープンなモジュール構造のシステムは、稼働効率はあまり良くないが、構成の自由度という代償を得られるのである。
現在、オイル・メジャーも産油国も、原油高の余録によって巨額の資金調達が可能になってきている。したがって、いまや中東では新規大型プロジェクトの計画ラッシュである。ますます急速に、ガスへのシフトが進みそうな勢いだ。今後、石油は燃料としてよりも、化学工業の原料としての役割に期待されることになるだろう。
もっとも、天然ガスだって無尽蔵にあるわけではない。今の中東の状況は、少々バブル状態に近づいていると言えなくもない。米国や中国の経済に何らかの危機が訪れたとき、真っ先に影響を受けるのは世界商品としての石油・ガスである。そして、化石燃料は、やはり温室効果ガスを産み出し続ける点ではかわりがない。明日のエネルギーのパラダイム・シフトを見据えつつ、しかし明後日の代替手段を探し続ける努力を怠ってはいけないだろう。
「２年後から、ウチでとりあつかう主要商品は、品物にすべてRFIDをつけて納入するように。」－－米国最大のチェーンストアWal-Martが、2003年にこう厳かに宣言して以来、RFID（いわゆるICタグ）は一躍、サプライチェーンにおけるマテリアル・マネジメントの注目株になった感がある。わが国でもICタグのブームが急に到来して、メディアでは鳴り物入りの大騒ぎだった。
RFIDの技術アイデア自体は決して新しいものではないが、実用的なサイズと値段に向かって加速がついたのはここ数年間のことだ。しかし、まだなかなか小売業が要求する価格レベルや精度まで到達しないので、今年に入ってからは騒ぎも少しトーンダウン気味ではある。とはいえ、業界ぐるみで競争が進んでいるから、壁を破るのは時間の問題だろう。
ICタグは、流通段階におけるトレーサビリティ問題を解決するのにはたしかに有効に思われる。いわゆる「トレーサビリティ」には、製造段階の問題と流通段階の課題があるが、後者の方が格段にむずかしい。ふつうの工場は基本的に集中制御型だから、製造段階のロットトレースはICタグでなくても実現できる。
しかし流通段階、つまりサプライチェーンは分散協調型の制御システムだから、マテリアルのトラッキング・ロット単位に「自己証明」たるRFIDを添付する方がずっと便利なのである。それがパレットやバケット単位でなく、カートンや個装単位まで添付・識別可能であるところが大きい。
そして、ICタグには全世界共通の商品コード"EPC"をつける構想が進んでいる。この計画はEAN
+ UCC + AutoIDセンターの欧米３グループがリーダーシップをとっている。コード形式とフォーマットは64bitと96bitが提案され、Wal-MartもこのEPCを支持している。こうして、ICタグを読みとれば、サプライチェーンを流れているマテリアルが何であるかを同定できることになるはずだ。
そうなると、私が以前「ＢＯＭデータ共有の夢と現実」で描いた、マテリアルの同定の問題もきれいに解決するのだろうか？ 私は必ずしもそうは思わない。この問題を考えるとき、いつも例に出すのが、「岩手産の牛乳１リットル瓶と十勝産の牛乳２リットルパックは、はたして同一のマテリアルか？」という質問である。
販売するメーカーも、食品スーパーの担当者も、両者はまったく別ものだと言うだろう。値段も荷姿もまったく異なっている。チーズ工場の品質管理担当者も別ものだというに違いない。産地が違えば、乳脂肪率などが異なるからだ。しかし、同じ産地の牛乳でも、季節によっての違いの方がはなはだしいから、もしかしたら産地の分類は粗すぎると言うかもしれない。荷姿の違いは気にしないだろう。どうせタンクに貯蔵するからだ。
ところが、レストランの仕入係は、両者は同じ「ミルク」だと考えるかもしれない。コップに入れて出してしまえば、ほとんど客は違いが分からない。
こうしてみると、２種類のマテリアルが同一かどうかというのは、「その人の立場と観点による」ことが理解できよう。もしかりにAutoIDセンターが世の中の森羅万象のマテリアルに個別のID番号をふったとしても、ユーザ側は、どれとどれが同一な（代替可能な・互換性のある）ものかを認識する必要がある。さもないと複社購買や入札は不可能だし、製造段階での代替もできないことになる。
言いかえるならば、マテリアルの同一性とは、それ自体が持つ物質的な「構造」「属性」ではなく、使用者が期待する「機能」の観点から識別される。そして、機能とは、使用者と使用目的との関係で定まる、相対的なものだ。「絶対的な機能」なるものは無い。
これではなんだか禅問答のように聞こえるかもしれない。が、それはある意味で当たっている。なぜなら、この問題は、西洋哲学史における「実在論」と「唯名論」の有名な論争と相似形の議論だからである。実在論者は、事物のカテゴリーは「イデア」として客観的に実在する、と考える。犬と狐は別種の動物であって、それは人間がどう解釈するかには依らない、とする。一方、唯名論者は、事物のカテゴリーなどは人間が自分の都合で名前を付けたもので、絶対的な基準ではないと考える。犬と狐の区別は相対的なものだ、とするのだ。
私は本質的には実在論者だが、サプライチェーンにおけるマテリアル・マネジメントの観点についてだけ言えば、ほぼ唯名論者である。商品というものの区分は、便宜的なものでしかない。絶対的な区別を与える「イデア」は存在しない。そう考える。だから万国不変なイデアを定義して、それを標準として商売しようと言う動きに、私は懐疑的である。
「すりあわせ型」のサプライチェーンでは、事物の要求仕様は、つねに使用者側が決める。その要求は、つねに変転していく宿命を負っている。これがマーケット・インの市場の世界観である。カテゴリー実在型の主張は（たとえば電子部品業界などがそれに近いが）、どこかでプロダクト・アウト型の世界観に立っている。大げさに言えば、認識論の違いなのである
そして、かつて「ＩＴって、何？」に書いたように、『ＩＴは西洋哲学の非嫡子だ』と主張したくなるのは、こういう時なのである。
製造業におけるＢＯＭデータというものを、マテリアルの数量的な関係を記述したリストである、ととらえ直したとき、必然的に一つの疑問がわいてくる。それは、ＢＯＭデータは異なる企業間でも共有できないか、という問題である。
この問題は、こう言い直しても良いかもしれない：サプライチェーンの中で、ＢＯＭデータをユーザ企業とサプライヤー企業とが共有できるための条件とは何か？ 最近のように製造業において製品開発と製造が分業化（ないし分社化）して、ファブレス企業が出現するようになると、自社内だけでＢＯＭデータは自己完結できない。製品設計の結果を、ＢＯＭデータの形で外部に流通させざるを得ないわけである。
異なる企業間でＢＯＭの共有を行なうためには、少なくともマテリアル・マスタの中で、当該ＢＯＭに関連づけられる品目だけは、品目コードを共通化して持っていなければならない。あるいは、せめて互いに品目コードが翻訳可能（相互マッピング可能）である必要がある。私が「100Wの電球」３個を納入します、と顧客に告げたとき、顧客が「あ、60Wの電球３個ね」と理解されてはまずい訳である。そのためには互いに『100Wの電球』と認識し合える共通のコードが必要になる。
このような要求は、まず電子商取引の世界で強くなった。そこで、「マテリアルの電子カタログ」を作成しようという動きにつながった。電子部品業界におけるRosettaNetの成功は、その代表例である。そして、これに押される形で、他の分野でも電子カタログを業界標準として制定しようと言う動きが数年前から表面化している。その代表例がP-LIBである。
P-LIBというのは、ISO13584/IEC61360の略称で、ISO/IECにて制定された部品電子ライブラリの仕様を決める規格である。その規定内容はかなり抽象的なものだが、一応の合意は広い範囲で得られたといっていい。そして、活動の重点は電子カタログである「辞書」（＝製品分類を規定するメタデータ）の開発に移りつつある。(社)日本電気計測器工業会（JEMIMA）の計測機器に関するPLIB辞書の提案などが、国内でもなされている。産業界における認知度は正直言って、まだ高くない。
私の所属するプラント資機材分野ではどうかというと、STEP (ISO10303)という規格が90年代の中頃から、Shellなどを中心に提唱されてきた。これはPLIBの姉妹と言っていい。
しかし、その実態について言うと、決して普及は進んでいない。配管材料だけで数千種類のマテリアルが存在するが、業界内ではあいかわらず各社バラバラにコード体系を使用している状態だ。
なぜか。それは、電子部品と違って、プラント資機材が「すりあわせ型」部品である事による。言いかえれば、ユーザ側の指定する個別仕様で調達する慣習が強い業界なのである。
いわゆる「電子カタログ」ときくと、通販商品のカタログのようなものを連想するのが普通だろう。しかし、通販商品は、サプライヤー側がカタログを作成・所有していることに注意してほしい。これに対して、すりあわせ型の業界では、「電子カタログ」はバイヤー側の頭の中に存在するのだ。
くり返すが、これは情報技術の問題ではない。品目マスタの記述にP-LIBを使おうが使うまいが、「すりあわせ型」の製造業では、カタログ作成の主導権は使用者側にある。彼らにとって、業界内でカタログを共通化するメリットなど、あまり無い。なぜなら、通常の商取引では、お金を払う側の方が、力関係が強いのだ。
したがって、最初の問題に対しては、こう回答せざるを得ないだろう：その業界の構造が「すりあわせ型」ではなく「モジュール型」で、かつ製造外注が発達してない限り、ＢＯＭデータの流通はなかなか普及しがたいのである、と。
"Well, this was a good meeting."とRay氏は言った。工場の片隅に置いた粗末なテーブルに手をついて立ち上がる。ところは米国テキサス州ヒューストン市の郊外にある、制御システム・メーカーの組立工場の中。われわれ、つまり日米のエンジニアリング会社２社のIT技術者４人は、工場立会い検査に行った先の場所を借りて、別の案件で２時間ほどの打合せを終えたところだった。
Good meeting? そもそもミーティングにGoodもBadもあるのだろうか？ Ray氏が自分の車でオフィスに帰り、われわれが工場検査作業の続きにとりかかった後も、その疑問は頭を離れなかった。仕事の打合せはこれまで数限りなく出ている。その中で、本日の打合せが他と異なる点はとくになかったように思う。目的を確認し、条件や事実関係を明らかにして整理し、対応策を考え、お互いのアクション項目を取り決めた。それだけだ。そもそも、打合の良し悪しを評価する習慣がない。
社会人になって初めて出た、客先との本格的な打合せは、今でもよく覚えている。電力会社に対して、私のいた部門が一種の技術検討調査を請け負って、その中間報告について行ったのだ。私はタンク・タンカー・シミュレーションと経済性分析を手伝っていた。中心になって説明したのは私の先輩のリーダー格の人で、私は細部の確認程度の受け答えをしただけだ。あとは何もせずにじっと問答を聞いていた。
しかし、帰ってから、私はそのリーダーに厳しく叱られた。なぜなら、私がメモを取っていなかったからだ。打合をしたら、必ず打合覚書を書く。そこには出席者と日次・場所と議題・議論の内容を記し、アクション項目と分担を定める。そして客先にレビューしてもらい、承認印を押してもらう。決して“言った、言わない”の争いの種を残さない。それが仕事の基本なのに、お前はなぜメモも取らずにボーっとして聞いていたのだ！ 打合覚書のドラフトはお前が書け。そう言い渡されて、私は必死に問答の内容を思いだし、覚書のブランクフォームを埋めなければならなかった。
プロジェクト・マネジメントにおける文書主義の原則を、新米のうちに叩き込まれたのは、私にとっては良い教訓だった。電話で客先と重要なことを話したら、それも必ず「電話連絡確認書」に書くように。そうも教え込まれた。
それにしても、なぜ我々は仕事で打合を必要とするのだろうか。指図と報告の紙のやりとりだけで、なぜ仕事は完結しないのだろうか。初めから文書だけで仕事をすれば、いちいち会話のやりとりを思いだして書き留める面倒をせずにすむのに。
その理由は、紙を通じた我々のコミュニケーション能力に限界があるからだ。価格交渉のことを考えてみて欲しい。手紙のやりとりだけでは、いつまでたっても平行線が縮まらない可能性がある。打合の場で互いを拘束して、なんとか結論を出すべく努力する。互いの知恵と感情を駆使してかけひきをする。ネゴシエーションとは、合意できる妥協案という解決を共同で探すための場なのである。そして、なんとか解決できたという安堵感を共有する。人間は感情を共有するためにフェイス・ツー・フェイスのミーティングを必要とするらしい。
もう一つの理由は、認識の共有だろう。毎週行なう進捗ミーティングなどがそれにあたる。目的を確認し、状況を報告し合い、問題点をみつけて、仮説を共有する。人間は誰しも、自分のコンテキスト（文脈）の中でしか物事を認識しない。複数の人間が集まると、その文脈の偏りが少しは修正されるのだ。多面的にものごとをとらえることができるようになるのである。
だとすると、打合とは、認識を共有し、問題を解決できるめどが立ったとき、その機能を十全に果たすと考えることができる。さらに、そこで前向きな良い感情を共有できれば、より実りある会議だったと言えるだろう。そういうのが、『良い会議』なのだ。
良くない会議とは、その反対のミーティングだ。目的が不明で、報告はゆがめられ、認識は平行線、アクション項目は決まらず、問題は未解決のまま先送りで、互いに悪感情だけが残る。こんな会議は人生のムダだ。ただ一回しかない時間の浪費である。
あのときRay氏がGood meetingと呼んだのは、だとすれば正しかったのだ。そのあと我々４人は太平洋の両側に戻って、互いに並行作業を進めなければならない状況にあった。しかし、認識を共有でき、アクションと分担が明確ならば、共同作業はベクトルが合う。会議には、たしかに評価の尺度があった。ミーティングを持つごとに、良い会議だったかどうか、いつも自分でチェックしておくべきなのである。
知ってのとおり、ＢＯＭはBill of Materialの略語だ。今日の世界では、３文字略語にすると知的流通に乗りやすいという、不思議な法則がある。だから、誰もが気のきいた略語を発明したがっている。しかし、その原点である"Bill
of Material"という英語の正しい翻訳は、案外むずかしい。
英語のBillは多義的な言葉で、請求書からビラ、目録、手形、法案、起訴状まで、非常に広い意味を持っている。Spending
Billというと予算案のことだが、これは“浪費家のビル”とも読めるので、好景気で大盤振る舞いをしたがった前アメリカ大統領ビル・クリントンのあてこすりにも使われた。しかし、billの大本の意味は、「箇条書きされた目録・リスト」のことをさす。このことから、勘定書・請求書という最もよく使われる意味が出てくる。
カフェーやレストランで、注文の品が全部テーブルに届けられたとき、ウェイトレスがそっと裏返して置いていく紙切れ、あれがbillの原型だ。そこには、テーブルに供した料理品目の名称と数量、単価と合計金額が記載されている。客はおもむろにbillを表返して、内容を確認する権利を有する（そのせいか、米国ではcheckとも呼ぶ）。少なくとも西洋では、billを念入りにチェックするのは無礼でも何でもない。そして内容に同意したら金額を払う。サービスが気に入ったら、チップを置いてもいい。店は金額を記載した領収書を渡す。
レストランのbillとは何だろうか？ 食事という目的のために、一揃いテーブルに供給すべき料理品目のリスト。じつは、これこそがbill
of materialなのだ。「料理は部品や材料じゃないぞ！」とお思いの方もあろう。しかし、"material"という言葉は、別に部品に限られる訳ではない。製品もまたmaterialである。なんであれ、具体的に存在する事物はすべてmaterialである。そして、特定の目的のために揃えるべきmatreialの一覧表を、ＢＯＭと呼ぶのだ。
ＢＯＭを「部品表」と翻訳した人は偉かったと思う。とてもイメージのわきやすい、すぐれた意訳だ。しかし、『部品』という言葉を当てたがために、ＢＯＭから翻訳されずにこぼれてしまった語義があった。ＢＯＭを、あまりにもＭＲＰ（資材所要量計画）に密接に結びつけて、用語を固定しすぎた嫌いがある。
それに、多くの業界では「部品」という用語自体を使わない。たとえば、化学・製鉄・繊維・アパレル・出版・飲料・食品・医薬品などはいずれも立派な製造業だが、原料・材料・素材などと呼ぶことはあっても、「部品」という言葉はそぐわないのだ。
そこで、もう一度原点に返って、ＢＯＭという用語を検討してみよう。より抽象化された視点から、ＢＯＭの本質を再定義し直そう。そう考えて、私は新著『ＢＯＭ／部品表入門』を書いた。その冒頭に記した、
「ＢＯＭとは、マテリアルの数量的な関係を示した一覧表である」
との定義は、ＢＯＭをＭＲＰだけの狭い枠組みから解き放ち、マテリアル・マネジメント改革の切り札として位置づけることを可能にした。製造業の社内サプライチェーンを統括するための、いわばＤＮＡ情報がＢＯＭなのである。より多くの人が、bill
of materialという抽象概念の可能性の広がりを感じ取っていただければありがたいと願っている。
Follow me!
