存在しているだけで役に立つもの

これも、前回と同じ頃の話だ。

その日、わたし達は午前中の新幹線で出張に出ることになっていた。朝一番でオフィスに集まり、明日までの二日間の打合せで必要な書類一式を最終確認し、一緒にでかける手はずだった。ところが、プロジェクト・チームの一人が、なかなか出社してこない。彼は制御システムの担当で、その日の午後に、自動制御システム・メーカーと打合せする際の中心だった。気を揉みつつも、他のメンバーと書類の確認を続けていたら、ようやく40分近く遅れて、彼がやってきた。

--どうした。遅かったな。待ってたぞ。

「すみません。ちょっと家内が入院するんで、病院まで送ってました。」

--なんだ、奥さんが病気なのか。それは心配じゃないか。

「いえ、病気じゃないんです。だから出張は行けます。大丈夫です。」

--病気じゃないのに、病院に行ったの?

「今日が出産の予定日だったので・・。」

 あきれて、わたしは怒鳴った。

--そんな大事なこと、なんでもっと前に言わないんだ! 出張なんか行かなくていい。制御ベンダーとは俺が話をつけるから、書類を全部、すぐ渡せ。

「でも。」

--でもじゃない。向こうは命がけでやってるんだぞ。お前がそばにいなくてどうする!

彼は「わかりました」と小声でいって、書類を取り出すとすぐに会社を出ていった。わたしは重くなったかばんをかかえ、他のメンバーに合図して新横浜に向かった。

新幹線の車中で、書類を読みながら、今日の交渉のシナリオを考えてみる。わたしがその時おいかけていた新工場づくりのプロジェクトは、まだ提案段階のものだった。客先は何も言わないが、もう一社,競合相手が陰で動いている気配が強い。製造工程の中核装置は、客先のコア技術でもあり、客先が自分で設計・調達する。ただ、周辺工程をふくめて工場内にはかなりの物流量があり、クリーン度も必要とされるため、自動化された物流搬送が要求される。もちろん、建物も空調設備がごつい。そんな中、見えない相手と技術・価格の両面で勝負するのは容易ではなかった。顧客自身の要求仕様も、トータルの生産量や建物の面積などはあるが、細かい部分がない。というのも、製品が多品種受注生産である上に、技術革新が早く、顧客自身5年後に何をどれだけ新工場で作っているのか、予想もできないのだ。

競争の上で一番むずかしいのは、エンジニアリング会社であるわたしの勤務先に、メーカーのような目に見える具体的な『技術』がないことだった。この製品を見てください、どうです、このスピードと静音性! みたいなセールスがきかないのだ。わたし達がもっているのは、目に見えない“まとめの技術”、納期とコストと品質の制約の中で、複雑な新工場プロジェクトをまとめ上げる技術だ。すなわち「プロジェクト・マネジメント技術」が唯一最大の売り物なのである。

だが、これに顧客はどれだけの価値を認めてくれるのか。エンジ会社など通さずに、自分で直接メーカーからモノを買った方が安いじゃないか、と考える日本企業は少なくない。エンジ会社は毎年、何千億円の単位で工場の資機材を世界中から調達しているので、かなりのバイイング・パワーをもっているのだが、それでも国産の特殊な製造機械の分野は、自分達の方がプロで安く買えると、わが顧客も信じていた。だから、目に見えない“まとめ技術”に価値を見いだしてもらうためには、工場全体をスムーズに動かせる仕組みを提案し印象づけるしかない。そのため、制御システムが重要になるのだ。

ところで、ああは言ったけれども、正直なところわたしはPLCなどの制御系システムはあまり得意ではない。じゃあ何系が得意なんだと問われるとこまるけれども、制御よりももう少し上位系の、いわゆる製造実行システム(MES = Manufacturing Execution System)ならば、いくらか経験がある。

いわゆる中央制御室などのある大規模プラントでは、DCSと呼ばれる集中制御システムに、プラント各所の温度・流量・圧力などの計測データがすべて集められる。そこでDCSは制御ロジックに従ってフィードバック制御などのリアルタイム計算をして、各機械の起動停止や調節弁の開閉などの指示信号を送り出す仕組みになっている。プラント内の数万点のデータを1秒周期で取り込んでは計算し送り出す訳だから、扱うデータ量は膨大である。だから当時のDCSでは、1週間程度くらいしか履歴データを保持しなかった。そこで、DCSの上位に、Historianと呼ばれる別のシステムをつなげて製造実行管理に用いるのである。Historianのソフトは特殊な圧縮アルゴリズムをそなえていて、リアルタイムの測定データを数年分保持でき、しかもタイム・スタンプをキーとしたRDBみたいに扱うことができる。

しかし、そこまで規模の大きくない工場では、PCとPLCの組合せで制御と製造管理を行うというのが、当時の主流だった。その方が価格としてもずっと安くなるが、どこまでパフォーマンスを出せるかが鍵になる。そのための見積交渉が今回の打合せの主目的だった。技術論に深入りされると、ちょっとつらい。ただ、今朝遅刻してきた担当者が作った仕様書は、かなり詳細にできているので、何とか乗り切るしかない。彼は寡黙だが、仕事は正確で真面目だった。真面目もいいが、まだ子どもがいるとはきいていないから、奥さんは初産ではないか。ちょっと度が過ぎている・・。

それにしてもプロジェクト・マネジメントの価値とは何かな、とわたしは考えた。どうしたらそれを計量化して、顧客にも見える化できるのか。プロジェクトの価値とは何か、それを構成するアクティビティの価値はどう測るか、そしてプロジェクト・マネジメントの価値とは--こうした問題は、当時からわたしの主要なテーマだった。プロジェクトの価値を金銭的に評価し、それを、各アクティビティの貢献に分解する方法については、その後、リスク確率という概念を導入するときれいに数式化できることに気がついて、わたしの学位論文に結実した(興味がある方は「リスク確率に基づくプロジェクト・マネジメントの研究」を参照されたい。Amazonから購入可能である)。

しかし、プロジェクト・マネジメントの価値評価については、当時も今も、いまだに解けていない問題である。プロジェクト・マネジメントという行為は、それ自体は何も具体的なプロダクトを生みださない。当時はわたしも仕様書を作っていたが、それは設計者の佐藤がやっている作業であって、プロマネを兼務している方の佐藤の仕事ではない。プロジェクト・マネジメントというは、財務会計的に言うならば『間接業務』なのである。では、その間接業務は、プロジェクトの価値にどう貢献しているのか。

経済学風な言い方を借りれば、価値には使用価値と交換価値がある。使用価値は効用、交換価値とは市場価格といってもいい。プロマネという人材の市場価値なら、考える事はできる。しかしプロジェクト・マネジメントはモノではないから、交換価値は考えにくい。「サービス」ととらえることは可能だが、具体的な個別プロジェクトのマネジメントだけを、市場にとりだしてサービスとして売ることはできるのか? わたしには疑問である。

そもそも、最初から最後まで順調な仕事では、プロジェクト・マネジメントなんて、ほとんど何もすることがないはずなのだ。優秀なチーフ・デザイナーが気の利いた基本設計をする。それを実直なエンジニア達が詳細設計に展開する。そして辣腕の調達マンが手配し、百戦錬磨の工事管理部隊が業者を采配していく。小規模なプロジェクトなら、それで一丁上がりである。だとすると、プロマネの使用価値などないから、客観的な計量はできないことになる。何も機能しないのに、価値があるという議論など成り立たない・・。どうどうめぐりになって、わたしの思考は途切れた。

その日の午後の打合せは、何とか前向きに終わった。わたしの能力と言うよりも、制御メーカー側の技術者が優秀だったおかげである。一番の問題は、制御システムに冗長性をどう確保するかだった。いや、制御系に限らず、工場を作る際につねに問題になるのが、冗長性の確保である。冗長な機器構成は、ある意味では余裕であるが、見方によっては単なるムダにしかならない。冗長化すれば、それだけコストが高くなる。競争環境下では、コストは安い方が有利だ。だが、冗長性をけずってしまうと、いざというときにシステムが動かず、可用性が下がってしまう。ただし、この費用はすぐには見えない。表面的な価格だけを見ると、冗長性を削った方が安くなる。

だから、欧米系で本当に第一級のグローバルな企業は、ふつう、工場設計における『設計思想』として、どこにどこまで冗長性を持たせるかの指針を、文書で定めており、われわれもそれに従って見積もることになる。まあ、そうした文書があっても、しばしば解釈で揉めるのだが、日本企業でこのような指針を明文化しているところは稀だ。このときの顧客も、もちろん持っていなかった。しかし、この制御メーカーは、スタンバイ機を通常は別の軽い用途に使用しておき、いざというときだけフェイルオーバーする方法が可能だと提案してきた。あとは、明日、顧客との打合せで、この方式を飲んでもらえばいいだろう・・。

ホテルに戻って夕食をとり、リラックスしているときに、急にふと気がついた。冗長化したバックアップ機というものは、本来は普段、何の仕事もしていない。だが、それは価値があるのだ。なぜなら、いざというときに、システム全体が倒れずにすむからだ。機能していなくても、存在するだけで価値があるもの。それは目の前にあったではないか。その価値は、すべてが正常に動いている普段は、まったく目に見えない。しかし、いざというときになると役に立つのだ。プロジェクト・マネジメントというものもよく似ている。順風満帆なときは、別に大した仕事はしていない。物事が難しくなったり環境が急変したときに、その真価が現れるのだ。つまり、リスク環境下でこそ、マネジメントの価値は測れるのである。

何となくほっとして寝ようとしたら、部屋に電話がかかってきた。今朝、遅刻した彼からだった。奥さんは無事、出産されたらしい。おめでとう、とわたしは言った。「いてくれて助かったと、家内は感謝していました。」そう彼は答えた。「自分はそこにいただけで、何もできなかったですけれど。」

何もできなくても、存在しているだけで役に立つことが、この世にはあるのだ。


<関連エントリ>
 →「MES(製造実行システム)とは何か」 (2009-09-09)
by Tomoichi_Sato | 2014-10-05 23:52 | プロジェクト・マネジメント | Comments(0)
<< パーソナル時間管理のベーシック あなたは、どう考えるの? >>