想定外に振り回されないリスクコントロール – 「未知の未知」への対処方法

はじめに

プロジェクトでは想定外のトラブルが発生するため、事前にリスクを想定して問題の発生抑止や対処を計画します。
しかし全てのリスクを洗い出すことは難しく、想定外の事態が発生することがあります。

今回、リスク計画で洗い出せなかったリスクのコントロールについて解説します。
リスク管理については「リスクマネジメント」を参照してください。

リスクの「既知」と「未知」

リスクは「既知」と「未知」で分類できます。
「既知」とは知っている問題や対策のことであり、「未知」とは認識していない問題や対策のことです。
これらは次のように定義できます。

既知の既知
リスクの存在を知っており、情報も十分にある状態。
リスクや課題として把握されており、対策も立てやすい。
プロジェクト課題として対処する。

既知の未知
リスクの存在は知っているが、詳細や具体的な影響が不明。
リスクとしては認識されているので、事前に対策を取りやすい。
リスク計画で管理され、事前に回避策と対策を検討する。

未知の未知
そもそもリスクとして存在を知らない、予測もできないリスクや課題のこと。
経験では察知することが難しく、対策を取ることも難しい。
プロジェクト遂行中にリスク発見、顕在化する。

この３つの中で特に問題となるのは「未知の未知」です。
あらかじめリスクとして認知していないため、対策が後手に回ることが多いです。

「未知の未知」の対処

「未知の未知」に対処するためには、「早期にリスク検知する」「柔軟に対応できる仕組み」が大切です。
・早期にリスクを検知することで問題が大きくなる前に対処します。
・問題が発生しても柔軟に対応することで被害を最小限にします。

早期にリスク検知する

プロジェクト計画時のイメージ作り

プロジェクト計画では「いつ、どのようなイベントが発生するか」「どのようにステークホルダーと調整するか」など、プロジェクトをどのように進めるのかイメージしながら検討します。
このイメージの解像度をあげると精度の高いプロジェクト計画ができるのですが、そのイメージ作りの中で「どうすれば良いかわからない」「気になる点」が出てくることがあります。

そのような不明点が「未知の未知」になることが多いです。
計画時点でしっかりイメージすることで未知を洗い出し、「未知の未知」から「既知の未知」に変えることが出来ます。

プロジェクト監視の強化

リスク管理で想定リスクへの対処を検討しますが「未知の未知」は予知することが出来ません。
そのためリスクに気づくのが遅れ、対処が困難になることもあります。
そうならないために、新たなリスクが発生していないか監視する必要があり、その仕組みをプロジェクト運営ルールに組み込みます。
監視する内容について例を記載します。

・進捗、コスト、課題対応、テストなどの状況を数値などで見える化する
・懸念点がすぐに共有されるレポート体制を構築する
・リスク棚卸を定期開催する
・メンバ間のコミュニケーションを強化する

外部の視点を取り入れる

リスク感度はプロジェクト経験を積むことで培っていくものですが、全てのリスクを検知できる人はいないでしょう。
チーム内で検討しても気づけないリスクについてはプロジェクト外の人にアドバイスを受けることで気付きを得ることが出来ます。
特に未経験の作業が多いプロジェクトの場合は、経験者や有識者にヒアリングすることが有効です。

多くの視点を取り入れることで、様々な角度からチェックすることで気づかないリスクを減らします。

プロトタイピング、実践的アプローチ

これまで経験したことのない環境やタスクで作業する場合、実際に作業してみないとわからないことが多いです。

そのような場合はプロトタイピングを作成したり、次工程の作業を少しだけ先行着手するなど、本格的に作業を始めるまえにお試し作業を行うことで問題を発見することが出来ます。
事前に問題を発見できれば、本対応するときのリスクを減らすことが出来ます。

心理的安全性の確保

失敗や事故といったトラブルが発生したとき、とにかく迅速な対応が重要になります。
そのときにチーム内の雰囲気が悪かったり報告しづらい雰囲気があると、メンバが問題を隠蔽したり、報告が遅れてしまう可能性があります。

問題発生時のエスカレーションルールを策定することも大切ですが、問題発生時に報告するという心理的壁を低くするようなチーム作りをすることも大切です。

柔軟に対応できる仕組み

変化を前提としたプロジェクト計画

プロジェクトで想定外の事態が発生した場合、当初のプロジェクト計画では対処できない場合があります。
そのようなときはプロジェクト計画や運営方法を柔軟に変更することも必要になります。
あらかじめプロジェクト計画の変更ルールを設けたりするとよいでしょう。

ただし目先の問題だけ焦点を当て場当たり的な変更をしないように注意してください。
例えば「仕様調整が遅れた」「想定外作業でスケジュールが遅れた」などの理由でスケジュール遅延が発生したとします。
その遅延をリカバリするため設計書レビューを簡略化するよう計画変更した場合、品質低下につながり、その結果テスト工程で手戻り作業が大量発生してプロジェクト全体のスケジュール遅延となる可能性があります。

計画変更してもプロジェクト終結まで問題なく進められることを確認しながら検討してください。

予備リソースの確保

要員や予算を確保するとき、あらかじめ余力やバッファを考慮した計画にします。
「問題が発生しなければ上手くいく」ことを前提として、余力のないスケジュール設定をしたり工数見積もりを行ってしまうと、トラブルが発生した場合に対処するためのリソースが確保できません。
リスク対策費を計上したり、スケジュールにバッファ期間を設けるように計画を立てましょう。

しかし余力のない問題プロジェクトに途中から投入されるなど、予備リソースが確保できないケースもあります。
そのようなときは日頃からプロジェクト状況を上司に報告するなど、上層部をプロジェクトに巻き込むとよいです。
上層部の当事者意識にフックすることができれば、問題が発生したときにリソース確保する手段を取ってもらえる可能性が高くなります。
問題が発生したときに組織として対処できる環境を整えるため、状況報告は必要です。

プロジェクト振り返り

これは事後対応の話ですが、プロジェクトや工程終了時に振り返りを行うことは重要です。
「未知の未知」というのはプロジェクト経験を積んでいくことで減らすことが出来ます。
ただし漫然とプロジェクトを進めていても経験値にはなりません。
発生した問題の原因と対策を振り返り、その事象を認識することによって人は経験を積んでいきます。
この振り返りは一人で考えるのもよいですが、チームメンバなど複数人で会話することで様々な気づきを得ることができます。
是非とも、プロジェクト振り返りは実施するようにしましょう。