前回のエントリーでは、プロジェクトマネジメントをする上で大切にしてることを取り上げました。
参考：若々しい脳を取り戻す ｢プロジェクトマネジメント思考｣ のススメ
好評だったので、今回はその続編として ｢プロジェクトマネジメントと想定外｣ について書いてみます。
プロジェクトでは予想外のことが起こります。思いもよらないことが次々に発生します。問題が出てきて解決したと思ったら、別の問題が表面化します。解決しても、新たな問題が発生することの繰り返しです。問題がほんと次から次に出てきて、もぐらたたきのような状況です。
そもそも想定外とは何か
想定外への対処の前に、そもそも想定とか想定外とは何かを考えてみます。
想定外への考え方について勉強になったのは、失敗学を提唱する畑村洋太郎氏の著書である ｢想定外｣ を想定せよ！ - 失敗学からの提言 でした。
本書では想定とは、人間が意図的・人為的につくる境界であるします。
ここまでは考えるという範囲を線引し、その内側が想定、外側が想定外になります。境界をつくることで、はじめてその中で考えることができるのです。逆に言うと境界の外側（想定外）には考えが及びにくいことになります。
想定は人が勝手につくった境界内にすぎないので、想定外 = 絶対起こらないのではなく、想定外のことは確率が低いものの起こりえます。適切な境界設定であれば想定外のことが発生する確率は低いのですが、境界設定が不正確であれば想定外のことも起こる可能性が高くなるのです。
想定外のことは起こる可能性がある、という認識が重要です。
想定外にどう対応するか
想定外のことは起こりえるという前提のもとで、想定外にどう対応すればよいのでしょうか。
プロジェクトマネジメントに限らず、仕事全般や日常生活でも大切な視点です。
アプローチとしては2つあります。
- 想定外をシュミレーションして想定を広げておく
- 想定外が起こった時に被害を最小化する
以下、それぞれについてご説明します。
想定外をシュミレーションして想定を広げる
頭の中で想定外のことも考えるようにするアプローチです。
想定 = 考える境界なので、境界設定がそもそも妥当なのかを問います。あえて境界の外に目を向けてみるのです。ただし、やみくもに境界の外にシュミレーションを広げすぎてもいけません。
参考になるのは、先ほどの ｢想定外｣ を想定せよ！ - 失敗学からの提言 で紹介されていた ｢逆演算｣ という方法です。
逆演算とは、結果から逆算して原因を考えるシュミレーション方法です。トラブルや失敗という結果をまずは考え、そこからなぜその結果が起こったのかの原因を推測します。
逆演算が有効だと実感するのは、結果から原因へという時間を巻き戻して考えるだけで、｢そういえばこんな可能性もある｣ と気づくことがあるからです。
例えば、上司（クライアントでもよいです）にレポートを提出するケースで考えてみます。
起こりそうな結果（トラブルや失敗）は、① 提出期日に間に合わない、② 上司やクライアントがレポート内容に満足しない、です。
① の提出遅れの原因は、そもそものスケジュール見通しが甘かった（上司の期日設定が無茶だった）、スケジュール内のある工程で予想外の遅れが発生した、です。
逆算法では、前者のスケジュール見通しが甘い要因は何があり得るかと、結果から原因の順に掘り下げていきます。
② の相手が満足しなかった場合も同様です。満足しなかったという結果は、何が原因になるかを考えます。
そもそも上司やクライアントの期待値を把握していなかったなのか、期待値は理解しているが満たせなかったか（例：仮説が不十分・結論や提案の方向性が違う・根拠が弱い・データが不適切）、と逆算します。
理想は、逆演算もするし、原因 → 結果の時間軸通りの順番でも、両方の視点で考えておくことです。
これは ｢売る側の視点｣ と ｢買う側の視点｣ 、｢提供サービス視点｣ と ｢ユーザー視点｣ の両方で考えることに通じます。相手の視点で考えると見える景色が全然違うように、結果 → 原因と、原因 → 結果の複眼の視点があることで気付きが多くなります。
想定外が起こった時に被害を最小化する
いくら綿密なシュミレーションをしても、完璧な想定外対策にはなりません。
先に書いたように、想定外とは考える領域の外なので、どれだけ事前に考えておいても想定外は発生します。境界を広げれば広げるほど考えることが増えるので、どこかで線引をせざるを得ません。
事前対策とともに重要になってくるのが、想定外のことが起こった場合にどう対応するかです。発生した時にいかに被害を最小化するかです。
今までの自分の経験から、いくつかポイントがあります。
1. 事実の確認
まずやるべきは状況確認です。
想定外という予想していなかったこととはいえ、起こってしまった以上は早急な対処が必要です。初動で大切なのが何が起こったのかを正確に把握することです。事実確認で精査が足りないと、その後の復旧や今後の対策にも全て影響してしまいます。
2. 復旧
すぐの対応としての応急処置です。復旧では根本的な解決にはならないこともありますが、これ以上被害が大きくならないように、とりあえず止血をします。
3. 原因究明
復旧の目処が立ってきたら、並行して行なうのがなぜ想定外のことが起こったかの原因究明です。｢失敗学｣ では原因究明と責任追及は分けて考えることを提唱していますが、これも大事なポイントです。
4. 今後の対策
原因が把握できたら対策を検討します。
復旧で応急処置をできたとしても、根本的な治療をしておかないと同じようなことがまた起こりかねません。想定外のことが起こるというはポジティブに捉えれば、それを次に活かすことができる、知見がたまり教訓にできるということです。
想定外事象という具体を抽象化する、得られた知見は他にも応用できないかを考えます。
想定外のことが起こった時にもう1つ重要だと思っているのが、いい意味で開き直ることです。
真剣に対処しますが、必要以上に深刻にならないことです。動揺しすぎてパニックになってしまうと二次災害や三次災害が起きかねません。ミスがミスを呼ぶのを避け、被害を最小限に抑えるためです。
起こってしまった以上はその現実は変えられないので、今からどうするかです。過去は変えられませんが、現実を見据え正しく対応し、未来は変えることができると信じることです。
想定外というトラブル中でも、いかに自分自身をこういう精神状態に回復できるかも大切にしたいです。
まとめ
プロジェクトマネジメントにおいて、想定外にどう対応するかを整理してみました。今回のエントリーのポイントをまとめです。
- 想定とは人為的につくる境界。想定をつくることで人はその中で考えることができる。逆に言えば想定外のことは考えが及びにくい。想定外は起こりえるという認識を持つ
- 想定外の対処法 ①：頭の中で想定範囲を広げ想定外のことに目を向ける。この時に有効なのが ｢逆演算｣ 。起こりそうなトラブル・失敗という結果から原因をWhyで掘り下げる。結果 → 原因、原因 → 結果の複眼で見るとさらに効果的
- 想定外の対処法 ②：事前対処をいくらやっても想定外は起こりえる。よって、発生した時にいかに被害を最小化するかも大切。事実確認、短期的リカバリー、原因究明、今後の対策を冷静に考える。いい意味で開き直る精神状態も大事。過去は変えられないので、現実に正しく対応することで未来は変えられる