例会部会
先号  次号

「第154回例会」報告

PMAJ 例会部会 岡崎 博之:11月号

【データ】
開催日: 2011年9月22日(木) 19:00~20:30
テーマ : トラブルを乗り越える
~イシュー・マネジメントの理論と実際~

講師 : 日揮株式会社
佐藤 知一氏

首都圏を直撃した台風15号が去った翌日9月22日(木) 154回例会が開催された。今回の講演タイトル『トラブルを乗り越える』が示すトラブルそのものである台風15号がもし1日遅れていたらどうなっただろう、3月の東日本大震災のことも思い出しながら会場に向かった。
講演は、世の中に『運・不運』があると思うかとの問いかけから始まった。
多数の参加者と同様に『運・不運』はあると感じた。台風15号が過ぎ去り、本日の例会が開催できたのは正に運そのものではないか。

講演の内容は
1. 問題(イシュー)の素顔を考える
2. イシュー・マネジメントの基本
3. トラブルの原因分析
4. 問題発生からのリカバリー
5. むすび
で構成された。

1. 問題(イシュー)の素顔を考える
[ マニャーナ の世界 ]
佐藤氏がベネズエラのプロジェクトで体験した問題で得た教訓
Asta manana =『明日、間に合うな』
が紹介された。
現場事務所から客先に通信できなくなった。通信ケーブル(光ファイバ)の切断事故が原因で、状況把握、対策立案そして復旧工事に至るまでの様子が細部に至るまで語られた。そして何日たっても復旧しないことで、Asta manana が意味することは『今日はできない』ということを悟った。
ここで紹介した事例だけでなく、問題(イシュー)は2つの種類がある。
「テクニカル、またはリーガルな問題」と「リソース、パフォーマンスの問題」の2つである。
テクニカル・リーガルの問題は構造が明確であり、容易かどうかは別にして応急処置、原因究明、再発防止ははっきりしている。
リソース・パフォーマンスの問題は構造が見えにくく、原因が漠然として分かりにくい、そのため適切な対応策がとれないまま時間だけが経過していくことになる。このため、「リソース・パフォーマンス」の問題は「人材」「リーダーシップ」の問題に転嫁されてきた。
そしてPMBOKの8つの知識エリアを使い、プロジェクト問題に階層性があることが示された。最深層のコミュニケーション障害およびリスク管理不全に起因して問題が発生し、表層のコスト超過問題に至る図式である。

2. イシュー・マネジメントの基本
はじめに課題と問題の違いが示された。
課題とは、『あるべき理想の姿』にむけて、現実を変えていくための行動を指すものである。英語では、assignment, challenge, task と能動的な表現となる。
問題とは、『期待していた状況と現実のギャップ』を指すものである。英語では、issue, problem と表現される。
日本では課題と問題を区別なく使っていることが多い。

PMBOKではリスクを顕在化させないようにする事前対策を重視している。これに対して、佐藤氏は
       可能性 × 影響度
リスク = -------------------------
         対応能力

というリスク評価式を示された。

この式の意味するところは可能性・影響度が大きくても、対応能力によりリスクをコントロールできることである。
したがって、自然災害のように「可能性(発生確率)」をコントロールできない場合は「影響度」を小さくするか、「対応能力」を大きくすることが方策となることがわかる。

イシュー(問題)とは、潜在的なリスクが顕在化し現実に起きてしまったトラブル事象である。プログラム/プロジェクトという互いに調和して活動するアクティビティの集合体にイシューが発生すると、調和を崩していくことになる。小さなイシューはある種の「アラーム(警報)」でもあり、マネジメントが早期に検知し早期に対策を打つことが必要となる。イシューを早期に検知できない体制は、それ自体が大きなリスクを抱えることになる。

3. トラブルの原因分析
ここでは、プロセスフローによるトラブル(夜道をあるいて転んで足を捻挫する事象、タイタニック号の事象)の分析が示された。
この分析の中で、トラブル分析手法 、根本原因 、間違った対策、原因分析からわかることの説明を紹介する。

トラブル事象分析手法は信頼性工学・品質管理学・安全工学・人間工学等からFTA、FMEA、VTA、RCAなどが提案されているが、決定打はない。
これらの手法の違いは、目的意識や検討対象の違いからくるものであり、自分の目的に適合したものを工夫して用いることが肝要である。
分析手法は事後検証に用いるもので、原因究明と再発防止を目的としなければならない。どの手法であっても責任追及の手段とすると、本当の原因が出てこなくなることに注意しなければならない。

根本原因(Root Cause)とは「理性的に同定された基本的原因で、かつマネジメントにより解決可能であるもの」で、「誰の立場で考えるか」によって根本原因は異なることになる。
間違った対策の一つである、「ルールをつくるだけで、学びをうながさないこと」では人の行動は改善しないだけでなく、それ自体が次の同種トラブル発生の根本原因となる。

原因分析から分かることは、大きなイシューには「直接の技術的原因」と「背景にあるマネジメント的原因」という2つの原因があることである。

4. 問題発生からのリカバリー
問題、根本原因と同様に問題解決も「技術的解決」と「マネジメント的解決」の2種類ある。この2つの解決方法の違いを事例を元にした解説が行われた。(資料に詳細が掲載されている)

危機的問題へ対応するためにはつぎの3つのポイントがある。
1. リソースを総動員する。小出しにして後手に回るのでなく、一気に十分なリソースを投入することで先手を取る。
2. 外部影響を遮断する。「対策に専念できるように外部からの影響を遮断する」ことと「外部へ悪影響を与えないための措置を講じる」ことである。
3. 代替案を出させて決定に責任をとる。担当者に問題解決策を複数提案させ、マネジメントの責任で選択する。ここにアカウンタビリティの原則を紹介する。権限は委譲できるが責任は委譲できない。これは技術者の提案に対する選択責任はマネジメントにあることを意味する。うまくいかなかったときの非難はマネジメントが受け、うまくいったときは担当者を賞賛する。

プロジェクトの成功とプログラムの成功について
HD DVD からの撤退という事例から、開発(プロジェクト)の成功と事業(プログラム)の成功は異なることが示された。
すなわち一つのプロジェクトが失敗したからといって、その上位にあるプログラムも失敗するわけではない。

5. むすび
学んで思わざれば、すなわち暗し。
思うて学ばざれば、すなわち危うし。

感想
プログラムとしてシステム運用を学んでいる筆者にとって、今回の講演においていくつかの気づきがあった。
1. 問題・原因・解決にはテクニカルな側面とマネジメントの側面という2つの側面で分類することの意義。
2. PMBOKの知識エリアでプロジェクトの問題の階層性を表現することの有用性。
3. リスクの評価式 :リスク = [可能性] × [ 影響度] / [ 対応能力 ]
分母の 対応能力 を鍛えることでリスク軽減を示せること。
4. 運の方程式 :運・不運があると思うのは (外乱)が(己の対応能力)を超えているときである。
5. 間違った対策は、次の同種トラブル発生の根本原因となること

佐藤様の豊富な体験に基づく事例と、聴き取りやすい話し方により、非常に充実した90分でした。ご講演ありがとうございました。
また佐藤様のブログ 『 タイム・コンサルタントの日誌から』は自分にとって役立つ情報が満載です。こちらもご覧いただければと思います。
ページトップに戻る