Re: プロジェクトはなぜ炎上するのか？そして何が必要か？

以前、こんな記事を書きました。

記事の中ではプロジェクトの炎上への対策とプロジェクト譜（以下、プ譜）という手法を紹介していました。
そしてプ譜への興味からPufuというファンサービスを立ち上げ、
その後、キックプ譜という公式サービスが公開され、プ譜というプロジェクトの全体像を捉えるツールが整う中、私がプロジェクトを考える原点の「プロジェクトの炎上とはなにか」を改めて考えてみたいと思います。

プロジェクトの炎上とは何か？

プロジェクト炎上とは何かですが、不思議なもので以前の記事で実はプロジェクトの炎上とは何かを書いていませんでした。

不明確な事柄を潰しながら進んでいくので、やってみないとわからないことも多く、対策が後手に回ります。その結果プロジェクトは炎上し、品質、コスト、納期を達成することができなくなります。

note: プロジェクトはなぜ失敗するのか？そして何が必要か？

敢えて汲み取るなら、『対策が後手に回っている』状態でしょうか。
暗黙的に、品質、コスト、納期（以下、QCD）の未達成が失敗であり、それは炎上であると思っていたのでしょう。

改めてプロジェクトの炎上について考えてみます。
プロジェクト炎上というからには、燃えていて、中にいる人が身を焦がしており、苦しみ悶ている状態でしょう。外からはプロジェクトが燃えている様が見える、内では身を焦がし燃えている。

実際には物理的に燃えているわけでなく、そう感じる状態として、個人・組織がダメージを受け続け、耐え忍び、瓦解しそうな状態がプロジェクトの炎上ではないでしょうか。プロジェクトの炎上は単純に量的に測れるものではなく、炎上していると感じるという主観的要素も含まれます。

炎上していると感じるには個人と組織でも存在しており、極端な表現をすると個人は生命の危機、組織は存続の危機を感じる状態が炎上状態と考えます。個人では、精神的、肉体的ダメージの蓄積、組織では資金、人材、信用へのダメージが蓄積されていくと危機を感じ炎上になります。

【個人レベル】
　・精神的ダメージ、肉体的ダメージ　→　生命の危機
【組織レベル】
　・資金的ダメージ、人材的ダメージ、信用的ダメージなど　→　存続の危機

プロジェクトでQCDが満たせていなくても、個人・組織にダメージがなければ炎上しているとは感じないでしょう。単純にプロジェクトの失敗で終わりです。
ただ、QCDが満たせていないと、個人・組織のダメージに相関関係が生まれやすいです。QCDが満たせてないので、個人・組織へのダメージが生まれ、ダメージを追うのでさらにQCDが満たせなくなる悪循環が生まれます。
では、QCDを満たせばプロジェクト炎上は回避できるのでしょうか？
QCDを満たせていたとしても、個人・組織へのダメージが大きければ、プロジェクトメンバーは炎上したと感じるでしょう。
少なくともQCDはプロジェクト炎上の絶対的指標ではないので、闇雲にQCDを満たせばプロジェクト炎上を回避できるという考え方は間違いでしょう。

プロジェクトの炎上を防ぐには？

プロジェクトの炎上についてどうすればいいのか考えてみます。
ダメージの大きさは感覚的要素もあるので、絶対量ではなく、主体の相対的に評価します。プロジェクトの遅延を例にすると、

ストレス耐性の弱いPM経験の浅いAさんの場合
周囲からの叱責や責任感から個人がストレスを受けて胃に穴が空くような状態になれば、個人として炎上している状態。

ストレス耐性の強いPM経験豊富なBさんの場合
想定どおりの遅延であり、リカバリー策や延期交渉手段を持っており、
心理的に余裕を持っている状態。

このように、同じ遅延であっても個人の気質、経験で炎上の体感は異なります。組織レベルにおいても、組織の相対的影響で数百万規模の失敗であれば、大きな問題もないケースもあれば、存続に関わる場合もあるでしょう。

AさんのケースからBさんのケースにシフトするにはどうすればいでしょう。ひとつは、心理的余裕を持ちつつ、プロジェクトを制御可能な状態にし続けることでしょうか。
それを満たすためには、下記の営みが必要です。

1. 状況を把握し、全体を俯瞰する

2. 炎上箇所を見極める

3. 炎上箇所に対処のパッチを当てる

1.状況を把握し、全体を俯瞰する
状況把握は以前記事にしたプ譜の得意とするところで、獲得目標、勝利条件、中間目的、施策、廟算八要素を認識します。実際にプ譜を書くがいいですが、書くまで至らないときは頭の中でプ譜を書くのも手です。

2.炎上箇所を見極める
炎上箇所の見極めは、プ譜の中で、要素の欠落、矛盾、不足を考えます。ここでは状況把握のプ譜に書いていないことを考えるので知的要素が強い活動です。アンチパータンと照らし合わせることも有効です。

3.炎上箇所に対処のパッチを当てる
炎上箇所にパッチを当てるというのは、リソースの充当、優先度や期日の再調整、前倒し等で被害を未然に防ぐまたは軽減し、プロジェクト活動を円滑にしていきます。

プロジェクトの改善はPlan(計画)→Do(実行)→Check(評価)→Action(改善)ではなくCheck(評価)→Action(改善)→Plan(計画)→Do(実行)を繰り返すのがあっている気がします。

まとめ

改めてプロジェクトの炎上について考えてみました。「まとめ」というほど思考はまとまっていないですが、プロジェクトを可視化するだけでなく、状況を読み解き、行動することが炎上を遠ざけるというのが今の考えになります。
炎上プロジェクトがある限りまだまだ思考は続きます。
長文を読んでいただきありがとうございます。
プロジェクト炎上についてご意見あればコメントいただけますと幸いです。