R先生との対話 - トラブルから『学ぶ』とはどういうことか

久しぶりにまたコンサルティングと人生の大先輩、R先生のところを訪ねた。ちょうど庭に花が陽光を浴びる季節である。

--このところPMO(Project Management Office)部門で、社内のプロマネさん達のコンサルのような支援のようなウォッチャーのような、自分でも判然としない仕事を主にしているのですが、最近とみに疑問に感じることがありまして。

「自分の仕事もよくわからん君がお目付役とは、そりゃプロマネ達も大変だろう。」

--そういわれると返す言葉もないんですが・・PMOってのは、ナレッジ・マネジメントというか、L&L(Lessons & Learns)を蓄積共有して、業務のプロセスを改善していく事が大事な機能の一つです。PMBOK Guide風に言えば、“組織のプロセス資産”を高める仕事です。そのL&Lに関連する疑問なんですが。

「アメリカ人の好きそうな概念だな。彼らは知識さえ持てば何でも乗り越えられると無邪気に信じてる。まあいい。それで疑問とは?」

--社内の規定では、プロジェクト・マネージャーは毎月、定型のレポートを上げることになっています。それ以外に、遂行途上でさまざまなトラブルにぶつかった際は、緊急性に鑑みて『アラート情報』を作成し発信することになっています。A4・1枚に入るような単純なフォーマットですが、こういう問題事象に遭遇した、現在これこれの対応処置をしている、似た状況下で同じ轍を踏まないよう、しかじかの防御策をとられたい。そんな内容になってます。ジョブが落ち着いたら、これをブラッシュアップしてL&Lとして正式に登録する仕組みです。

「別にそれはそれでいいんじゃないか。ちゃんと仕組みとして回りさえすれば。」

--そうなんですが、一つ気になることがあります。現在までに登録されたL&Lのデータベースを分析してみると、技術的なトラブル対策は多いのですが、マネジメント系のL&Lがいやに少ないのです。こういう金属材料の適用に気をつけろ、某国の法規ではこういう仕様の要求がある、輸送のミスで部材がバラバラになった、埋設管の設計で注意する点・・・テクニカルな知見は多い。なのに、プロジェクト・マネジメント業務そのものの教訓が少ないのです。引き渡しの契約条件でこうネゴすべし、下請けの倒産を避けるためこう手を打て、とか、無いわけではないのですが、圧倒的に少ない。専門機能部門の改善には役だっても、これじゃあプロマネの改善に結びつかないのです。

「君のところは、たしかマトリクス型の組織だったな? 設計専門部の他に、マネジメント部門がある訳か。」

--そうです。私の勤務先では、プロジェクト・エンジニアという名前のマネジメント専門職種が属する部門があって、その部門の、身分的には別に管理職でもない若手社員が、はるか年上の他部門のベテラン社員を使う、ということも珍しくありません。だからこそ、私みたいなPMOの職種が必要になるんです。

「そうか。ところで、最初に確認しておくが、仕事の教訓というのは(それをL&Lと呼ぼうが何と呼ぼうが勝手だが)、別にトラブル事例だけに学ぶべきものではない。むしろ、成功例からも学ぶべきなのだよ。そんな『アラート』とやらでは、うまくいっている事例の報告は上がってこないだろう? 片手落ちではないかな。」

--うーん、たしかに。

「上手なマネジメントというのは、トラブルが起きる前に未然に防ぐものだ。だから、プロジェクトに波風は立たない。静かに、スムーズに進んでいる仕事を、君は十分注意してウォッチしているかね? そっちの方が、ずっと教訓は多いんだ。なのに、問題事象や解決ばかりに皆の注意が向くようでは、自分でトラブルの種をまいて大騒ぎで刈り取る“問題児”の方が、かえって会社員としては目立って得をしかねまい。」

--おっしゃることはもっともだと思います。でも、だとすると、マネジメント系の教訓の種は、どうやったらもっとうまく拾えるのでしょうか? 形式化されたナレッジが無いと、いつまでたっても属人的スキル・ベースのマネジメントから進化できません。

「君は二つほど勘違いをしているよ。一つ目の勘違いは、大事なトラブルは緊急性の『アラート』で拾えると思い込んでいるところ。もう一つは、技術的トラブル事象とマネジメントとをバラバラに考えていることだ。」

--どういうことでしょうか。

「トラブルというものは、リスクが具現化して生じるものだ。リスクは知っているよね。リスクはトラブル事象そのものではなくて、それが生じる可能性のことだ。君のところでは、プロジェクト開始時点に、きちんとリスク・アセスメントはやっているかね?」

--そりゃ無論、やっていますよ。関係者全員がリスク・アイテムを総ざらえして、生起確率と影響度のマトリクスで評価して、リスク登録簿を作ります。登録簿は毎月アップデートすることを義務づけています。

「そうか。それで、リスクというのは、既知のリスク未知のリスクにまず分けられる。君の言う登録簿なるものに書き込んだものは、みんな既知のリスクだ。未知のリスクに対応するためには、用途を限定しないコンティンジェンシー・リザーブ(予備費)がプロマネに必要になる。」

--それも制度化しています。

「まあ急がずに聞きなさい。リスクはさらに、外部リスク内部リスクとに分類される。組織の外からやってくる事象と、内部で発生するリスクだ。為替変動だの、下請けの倒産だの、輸送中の事故だのは外部リスクだ。設計のチョンボ、情報伝達の不正確、メンバー同士の相互不信なんかが内部リスクだ。さて、緊急性の高いのは、どっちのリスクが具現化したトラブルだと思う?」

--う・・外部リスクですか。

「そうだ。たいていの外部リスクは、いきなりやってきて、皆の頭の上で炸裂する。誰もがそれに気がつく。ところがね、内部リスクは必ずしもそうじゃない。設計にミスがあったって、すぐその場では表面化しない。製作を経て、テストをくぐり抜けて、ようやく気がつく。コミュニケーションのミス、相互不信なんかも同様。こうしたリスクは、じわじわとしか具現化してこないから、気づきにくい。しかし、ボディーブローのように、確実にプロジェクトの志気やエネルギーを奪っていく。こっちの方がある意味、ずっと怖いのだ。君んところだけじゃないよ、製造業だってサービス業だって、同じように内部リスクは気づきにくい。
 さて、マネジメントに起因するリスクは、外部リスクか内部リスクか?」

--内部リスクですね・・そうか。

「そのとおり。『アラート』のような緊急通報型の仕組みを使っていたら、マネジメント自体に起因するボディーブロー型の内部リスクは、なかなか捕まえられないに決まっている。だから、そのためには別の仕組みが必要なんだ。では、君の第二の勘違いに行こうか。」

(この項つづく)
by Tomoichi_Sato | 2010-05-07 23:40 | プロジェクト・マネジメント | Comments(0)
<< R先生との対話(つづき) - ... ぼくらに英語は分からない >>