危機における技術のマネジメントとは

「どうだ、状況は?」
「かなりヤバイ。温度が上がってきている。液面も落ちてきた。」
「困ったな。一番の問題は容器内の圧力だろう。今どれくらいある?」
「計器のトラブルでよく分からないんだ。表面温度から見てたぶん7~8気圧くらいになってる」
「設計圧力は?」
「4.5だ。5や6くらいまでなら持つ自信はある。でも8となると、正直厳しい。」
「時間との勝負だな。安全弁をふかせるしかないか。ポンプさえきちんと回せれば抑え込めるはずなんだが。」

エンジニアは、こういうしゃべり方をする。ちなみに、上の会話は創作である(念のため)。エンジニアの会話は、数字と見込みと判断と、そして感覚からなっている。これは、科学者や、役人や、政治家や、法律家の話し方とはずいぶん違う。科学者は「ヤバイ」という言葉遣いはしない。科学者は論理的に確実なことしか言わないし、論理的でないことを言えば、科学者でなくなってしまう。政治家は耐圧性能に対して自信を述べず、法律家は「時間との勝負だな」とは言いはすまい(たまには言うかもしれないが、彼らの時間感覚はだいたい月単位である)。


前回
も書いた通り、わたしはエンジニアだ。エンジニアリング業界で働き、周りも技術屋ばかりである。だからエンジニアがどういうしゃべり方をするかよく承知しているし、技術屋同士の話が一番分かりやすい。世間ではよく「科学技術」と一括りにするが、この二種類はかなり違う。科学は真理への探求心が主軸にあるが、技術屋は徹頭徹尾、目的合理性と実用の観点で動く。技術の対象は(たいてい)複雑な系である。必ずしも全ての情報が手に入るとは限らない。そこで、入手可能な数値的データから、系の状態について推測し判断することを求められる。かりに論理的に確実でなくても、経験的に因果関係があれば、なんらかの手を打つ。「一応、念のため」とか「気は心さ」などと口にしつつも。

ここで「技術者」といわずに「技術屋」とわざわざ書いている点に注意してほしい。エンジニアとは生計を得るための商売である。聖職とかではない。そこに自尊も卑下もあるのだし、だから対象から距離をとって正気を保っていられるのだ。技術屋は不確実性の中にいる。そして、一定の制約条件下で判断を下さなければならない。判断のためには、なんらかの価値基準がいる。こうした、不確実性と制約と判断が、エンジニアの直面する日常的問題である。

だからエンジニアを使う時には、それに合った使い方、マネジメントの仕方を理解する必要がなる。とはいえ定常的なオペレーションにおける技術屋のマネジメントについては、ここで詳しく述べるまでもないだろう。『PDCA』という言葉は全国的に流通しているからだ。計画を立て結果を検証し、必要に応じて改善のサイクルを回すことは、普通の企業だったらどこでも行っている。

ここで論じたいのは、技術的な問題発生時、それも重大な危機的問題の発生時のマネジメントでだ。そもそも『問題』とは、“現状が期待と乖離した状況”を指すのだが、それにも軽重がある。普通は三段階、すなわち、プロジェクトやオペレーション全体を止めてしまう可能性のある重篤な問題(英語でいえばShow Stopper)と、当面は迂回可能な問題と、後日修正すれば済む軽微な問題とにレベル分けされる。ABCなどのランクで区別されることも多い。大事なことは、Aランクの危機的問題と、BCランクの問題では、マネジメントの仕方を変える必要がある点である。

Aランクの危機的問題においては、マネジメントは次のことに集中しなくてはならない。
1 リソースを動員する
2 外部影響を遮断する
3 代替案を出させて決定に責任をとる
以下、意味を説明しよう。

1 リソースを動員する
マネジメントは、問題解決に当たる技術者に対して、必要なリソースを可能な限り動員・調達するべく努力してほしい。『リソース』が何を意味するかについては、最近解説したばかりなので、ここで詳しくは繰り返さない。技術者が問題解決に必要としているリソースは人であるかもしれないし、特殊な道具・機械・設備かもしれないし、あるいはユーティリティ(電力・燃料・水等の用役)かもしれない。一口に人と言っても、専門家の場合もあるだろうし力仕事の労力の場合もあるだろう。何であれ、必要と思われるものは、可能な限りすみやかに調達する。そのためのロジスティックスも手当てする。これがマネジメントの第一の仕事である。

リソースは、最初からできるかぎり多めを動員する。足りなくて困るよりは、多すぎて迷う方がましだからだ。戦力の逐次投入が、一番いけない。わたしの知る優秀なプロジェクト・マネージャーやプロジェクト・スポンサーはたいてい、問題発生時のリソース投入の判断が早くて正確である。しかもリソースが多すぎて現場が混乱しないよう、その整理と差配も同時に考えている。

2 外部影響を遮断する
これはエンジニアを問題解決に集中させるためにぜひ必要なことだ。ここで外部影響とは、「外部からの影響(雑音)」と、「外部への影響(波及)」の両面を指す。危機的問題の発生時は、経営トップをはじめ、顧客やら監督官庁やら地域コミュニティからメディアにいたるまで、ありとあらゆるステークホルダが疑問や注文を投げかけてくる。現場の担当技術者がこれらに対していちいち資料を作って答えていたら、肝心の「考える時間」が取れなくなる。そこでマネジメントの第二の仕事は、担当者に代わってコミュニケーションを引き受けることで、担当者を雑音から遮断し、問題に専念させることである。

「外部への影響」の遮断とは、問題事象がなんらかの形で物理化学的に近隣施設やコミュニティに影響を与えている時に必要となる。むろん、物理的遮蔽や化学的中和は技術者の仕事である。マネジメントの仕事とはそうではなくて、遮断による経済面・心理面・法律面での影響について交渉し対処しておくことである。本当に必要なら、行政を説得し近隣住民を予備的に避難させることも案の一つである。かりに現時点で直接の危険性がなくとも、それによって技術者のとれる選択肢の幅が拡がるなら、十分に意味がある。

3 代替案を出させて決定に責任をとる
これがマネジメントの第三の、そして一番重要な仕事である。マネジメントとは、担当者に仕事のやり方を指示命令することではない。技術に関しては、技術者が一番よく知っているのだ。大事なことは、技術者に問題解決のための複数の選択肢を考えさせ、その中の一つをマネジメントの責任の下で選ぶことである。複数の選択肢について、それぞれの技術的可能性、有効性、コスト、時間、影響、リスクなどを簡潔にまとめさせる。そして、総合的判断の下、最善と思われるものを選ぶ。

担当技術者に選ばせない理由は二つある。担当者は問題事象に集中しているため、より大きな観点からの得失が見えにくくなっているおそれがある。たとえば、技術屋というのは、自分が面倒を見てきた装置やら製品やらシステムが可愛い。だから、できるかぎりは破壊から守ろうと無意識に考える。しかし、「それはもう捨てろ」と命じるのが、マネジメントの役割なのだ。「過去つぎ込んだ金や時間への執着は忘れろ、それはSunk Costだ」と言わなくてはならない。もう一つの理由は、当然のことだが、結果に対する責任を引き受けるためである。かりに技術者のリコメンド案をそのまま受け入れる場合であっても、責任はマネジメントに残る。うまくいかなかった時の非難は、マネジメントが受け取る。うまくいったら担当者を賞賛する。これがアカウンタビリティーの原則というものである。

以上の三つの仕事を煎じ詰めれば、マネジメントの仕事とは技術者を「支援する」ことだ、と分かるだろう。現場に乗り込んで陣頭指揮、とか、一刀両断に問題を解決、といったかっこいい「リーダーシップ」を世間では求めたがる。マネージャーも現場感覚は必要だから、現場には行くべきだと思う。だが、あいにく、技術的問題に関しては、技術者が解決するしかないのだ。技術のマネジメントとは、脚光を浴びず、非難ばかり浴びる仕事である。それは当然なのだ。なぜなら、危機における技術のマネジメントとは、『支援』の別名だからである。
by Tomoichi_Sato | 2011-03-24 22:45 | リスク・マネジメント | Comments(0)
<< サプライチェーンの再生力 計画技術者の目から見た「計画停電」 >>