人気ブログランキング | 話題のタグを見る

プロジェクトの《心配》を捕捉する

リーダーはつらい。

そう思っている人がどれほど多いかは、正確には知らない。いやいや、リーダーであることは、素晴らしい、ぜひ、人の上に立つべきだ。リーダーシップを発揮して、人を動かそう——わたし達の社会は、そんなメッセージに満ちている。人間は生まれつき競争心を持っているし、この世は競争原理でドライブされている。だからみんな、リーダーを目指すべきだ、リーダーの地位は喜ばしい、という事になっている。

でも、はたして本当にそうか。

リーダーは心配の多い仕事である。一介のエンジニアから、リーダーのポジションに上がると、自分自身の技術のこと以外に、面倒見なくてはいけないことが増える。部下や後輩や外注先の仕事ぶり、彼らの能力や勤務状況、すぐに進歩し変転していく技術の通用力、そして顧客の要求や機嫌など・・。これらを見極めた上で、WBSを決めスケジュールの線表を引き、そして費用や納期の交渉までしなくてはならない。

顧客も納期も自分の部下の顔ぶれも、自分で選んだものではない。え? 見積提案書をつくったのは自分だろうって? だが、どうみても無理筋な納期要求をしてきている顧客案件を、厳しい競争環境下で取ってきたのは営業だ。だが、彼らは注文書を受け取ったら、さっさといなくなる。外注先も、上司が過去の経緯で決めてしまった。自分がのぞみ通りに絵を描いたのは、テクニカルな部分を除くと、極めて小さい。

・・というような事例は、まあ珍しくない。だから、中間管理職に昇格したとたんメンタルをやられたとか、プロジェクト・リーダーをやらされそうになったから会社をかわった、といった話も耳にすることになる。

なお、わたしはここまで(前回の記事を含めて)あえて、「プロジェクト・リーダー」という言葉を使ってきた。わが国の、とくにIT業界では、この用語が一般的だからだ。本サイトの以前からの読者は、わたしが「プロジェクト・マネージャー」の呼称を一貫して使ってきたことを、ご存じかも知れない。PMBOK Guide(R)でも、そうなっている。マネージャーとリーダーは、本当は違う。マネジメントとリーダーシップも、相当に違う。

だが、英語では異なった意味になるマネージャー、リーダー、コントローラー、アドミニストレータの4つの語は、日本語ではみんな『管理者』と訳される。日本の方がそうした概念については大ざっぱであり、英語のような緻密な区分をしない。

ただ、面白いことに、プロジェクト・リーダーの上に「プロジェクト管理者」がいる組織図は、よく見かける(「プロジェクト責任者」の場合もある)。どう違うのか。どうやら職位が違うらしい。前者のリーダーは現場で汗をかく人だが、後者は部長クラスで、キックオフと中間レビューミーティングくらいしか、顔を出さない。どういう「責任」をとってくれるかも、今ひとつ定かではない。

責任」という言葉は、じつは問題やトラブルと密接な関係がある。「あのプロジェクトは素晴らしい成功だったが、その責任は彼にある」、という言い方は誰もしない(もちろん英語でもない)。責任がある、責任を取る、といった場合、なんらかの望ましくないトラブルが生じたケースに限られる。だから、責任者というのは、プロジェクトの《心配事》を、前もってケアすべき立場にある。つまり、前回の記事に書いた「危険予知」である。

さて、ここでもう一つ、英語と日本語の言葉の違い、あるいは概念の違いについて、ふれなければならない。それがリスクriskという語である。

リスクとは、危険だろうか?

ふつう、危険の反対概念=安全、だと考えられている。安全とは、危険がないこと、すなわちリスクがない状態だ、と。

ところが、国際標準の世界では、そうは考えない。安全の定義は、「受入不可能なリスクがないこと」(ISO/IEC Guide51)とされているのだ。つまり、安全な状態とは、受入可能なリスクが、いろいろと残っている状態のことを指すである。何だそれ?

じつは、日本語の「危険」に相当する英語は、ハザードHazard、ペリルPerril、リスクRisk、デンジャーDangerと、4つある。彼らは、これを使い分けている。

たとえば、救命具なしにボートを漕ぎ出すのはリスキーRiskyだが、嵐の海にボートを漕ぎ出したらデンジャラスDangerousだ、という。リスクはまだ可能性の段階だが、デンジャーはほぼ確実に危険である。

ちなみに、ハザードは危険源という訳語を、JISでは採用している。たとえば高圧電流の通電が、ハザード(危険源)だ。普通、それは防護や絶縁をする。しかし絶縁不良で漏電、となるとペリルに「昇格」する。そこに人が近づいたり可燃物があったりする可能性があると、さらにリスクになる。そして・・

繰り返すが、リスクは可能性の状態にある。そしてリスクには、大小がある。これを洗い出して、対策を考えるのが、リスク・アセスメントである。対策とは、必ずしもリスクを除去することではない。リスクが「受入可能」な状態にすることも、リスク対策である。

別な言い方をすると、絶対安全はない、という見方を、ISOなどを決めた人びと(ほぼ欧米人)は取っているのだ。安全か危険か、白か黒か、という風に世の中を見ない。現実世界には、大小様々なリスクがあって、自分にとって許容可能な範囲はどこかを考え、その領域を広げる努力をしよう、とするのである。これを、Risk-based Approachという。日本語の訳は、まだない。

リスク・アセスメントで使う主要な道具が、Risk Breakdown Structure(RBS)であり、その結果をリスク登録簿に書き込む。

Risk Breakdown Structureとは、プロジェクトのリスクが生じるエリア(源泉)を階層的にブレークダウンした図で、WBSの階層表現図に、ちょっと似ている。最上位にプロジェクト全体のリスクがあり、それを、たとえば外部リスク・技術リスク・組織リスク・マネジメントリスクなどに分解し、さらに外部リスクは市場環境・天候気象・公衆衛生などに分解してある。そして、その単位で考え得るリスク項目を洗い出すのである。まあ、リスクの源泉つまり危険源(ハザード)の分解なので、本当はHBSとよぶべきだろう。

洗い出したリスクは、リスク登録簿(Risk Registry)に記録する。リスク登録簿は、シンプルな表である。整理番号、リスク項目(説明)があり、さらに、発生確率、影響度、リスク点数(スコア)、優先度の欄が並ぶ。そして、その右側にはリスク対応戦略(分類)、そして具体的な対応策と、そのリスクをケアする責任者の欄がある。実務ではもう少し欄を追加することもあるが、これが最大公約数だろう。

プロジェクトの《心配》を捕捉する_e0058447_21300220.png
リスク・アセスメントは、プロジェクトのリーダーが一人で作ることも可能だが、できればキーパーソンを入れて複数人で行うのが望ましい。一人だとどうしても、見方が限られる。ことなる視点から、「あれもありうる」「これもあるんじゃない」とやりとりする方が、ベターだ。そして、リスク登録簿を完成させる。

このリスク洗い出しと対策議論のプロセスによって、参加者の脳内でさまざまなシミュレーションが行われ、その一部は言語化されていく。じつは、ここが非常に大切なのだ。というのも、「幽霊見たり枯れ尾花」という諺があるとおり、人を一番消耗させるのは、見えない物事への心配・不安なのである。

リスク登録簿とは、そうした心配事を捕捉した、いわばプロジェクトの心配事リストである。それが言語化され、具体的に見えてくれば、個々のリスク事象の発生確率や影響度自体は変わらなくても、自分の側の検知能力や対応能力が上がるのだ。

だから、できあがったリスク登録簿は、プロジェクト・メンバー、および上位管理職(つまり「プロジェクト管理者」「責任者」)とに共有することが大事である。もちろん本当は、プロジェクト責任者こそ、このリスク・アセスメントのセッションに、一緒に参加すべきなのだ。

なお、あえてちょっとだけ、余計なことを書こう。それは、「リーダー」と「責任者」の関係についてだ。わたしは、多くのプロジェクト・リーダーの悩みは、実はその上司である管理者なり責任者レベルが果たすべきマネジメントの不足を、下のリーダー層で補おうとして生じているのではないか、と思っている。いいかえると、戦略レベルの不足を、戦術レベルで何とか挽回しようとしている。あるいは、将校の不在を、下士官が補おうと、無理しているから、悩みが深いのではないか。

わたしは「プロジェクト&プログラム・アナリシス研究部会」をかれこれ、10年も続けてきたし、その中で「プロジェクト懇話会」も開いてきた。プロジェクトの運営に悩む人達の話も、それなりに聞いてきたが、多くの事例では、出発時点からムリがあって、さらに上司が支援を十分していない、と感じられた。それは契約条件だったり、顧客の性質だったり様々だ。ともあれ、会社組織がプロジェクトに必要な手当てをしないまま、現場リーダーに遂行を丸投げしている印象を、しばしば持つのである。

上司たる「責任者」のマネジメントがなぜ、ちゃんと機能しないのか。上司が多忙すぎるのか、他にトラブルを抱えて火消しに回っているのか、それともマネジメントという職務をちゃんと教育していないのか。理由は定かではない。ともあれ、「責任者」が責任を果たしていないように思えた。この人達が、プロジェクトの心配を事前に捕捉しておいてくれれば、現場のリーダーがあんなに消耗しなくてもよかったはずなのだ。

でも、どうやら、こうした組織構造は、一朝一夕には、なおらないかもしれない。だとしたら、現場を率いるリーダークラスが、せめて実務に役立つリスク・アセスメントの進め方を、身につけて欲しいと思っている。だから、(前回の繰り返しになるが)11月16日と23日の二日間コースで、プロジェクト・マネジメント研修を組むことにしたのである。

研修セミナー名称:
プロジェクトマネジメント研修 ~リスクマネジメント編~

日時:11月16日・23日 各10:00~17:00
講師
  八卷 直一氏(静岡大学工学部 名誉教授)
  佐藤 知一氏(日揮(株) 博士(工学)/静岡大学 客員教授)
  串田 悠彰氏((株)未来生活研究所 博士(工学))

参加申込み:


なお、最後に、一つだけつけ加えたい。リスク・アセスメントで重要なのは、言うまでもなく、リスク対策の立案である。ところで、実際にやってみると分かるのだが、現在のPMBOK Guide(R)にあげられている、4種類のリスク対応戦略(回避・転嫁・軽減・受容)だけでは、なんだか十分ではないのだ。

そこでこのセミナーでは、リスク発生の構造にまで立ち戻って、必要な対応戦略をもっと充実させている。ただ、そのためには問題事象の原因分析まで、理解する必要がある。おまけにPMBOKの枠組みを超えてしまう。このため上記の研修では、PMP試験対策としてのPDUは発行していない。その点をご了承いただければ幸いである。


<関連エントリ>



by Tomoichi_Sato | 2021-10-17 21:39 | プロジェクト・マネジメント | Comments(1)
Commented at 2021-10-20 13:27 x
ブログの持ち主だけに見える非公開コメントです。
<< 書評:「反知性主義―アメリカが... 危険予知:プロジェクト・リーダ... >>