なぜリスク管理は形骸化するのか

　ITシステム開発プロジェクトにおいて、リスク管理を行うことの重要性は誰もが認識していることと思います。しかし、十分に行われているプロジェクトは多くはありません。

　なぜでしょうか？

　リスク管理の仕組みの悪さや、リスク管理の知識不足が理由として挙げられることが多いようですが、大きな理由は別にあるように思えます。

　1つには、リスク管理の考え方が企業文化に馴染まないということです。

　プロジェクトで抽出したリスクを、利用部門や経営層に公開して対応状況を報告することは、重要なことです。しかし、例えばプロジェクトマネジャー（以下、PM）が、
「40%の確率で、リリースが3カ月延びます」
と報告した場合、”PMとしての能力が低い”、”やる気が無い”などと見なされることがあります。
　もし、
「なんとか頑張って予定通りリリースさせます」
という、”やればできる”という考えを強く持つPMが近くにいたら、PMは交代となるでしょう。このような環境では、PMはリスク管理をプロジェクト内部で留める方が良いと判断し、リスク管理の効力が弱まることになります。“前向き”の考え方が強い企業ほど、この傾向があると思われます。

　不思議な話ですが、これと似た現象があります。

　期日は必ず守ると約束したものの、結局期日に間に合わず、連日過酷な長時間労働により何とか3カ月超過で終わらせたPMは、その会社で英雄扱いをされる事があります。一方、半年前に3カ月延伸を申し出たPMは、低い評価をされることが少なくありません。

　また、リスクをプロジェクト内部で管理する場合でも、リスクの数が多く挙がらないという問題があります。

　PMはリスクを抽出する際、一人では限界があるため、プロジェクトメンバーに抽出を依頼します。しかし、大抵多くは挙がりません。それは、メンバーには、積極的に挙げる動機が無いからです。メンバーはプロジェクトの成否に対し直接の責任は無く、担当のパートさえ実施できていれば責任を問われることはありません。よって、自身のパートのリスクは関心を持ちますが、プロジェクト全体のリスクについては強い関心を持ちにくいのです。
　自身のパートのリスクでさえ、PMに”能力が低い”とみなされることを恐れ、積極的に出せないということがあります。これはプロジェクト内のグループ、グループ内のチームといったどの階層でもあります。リスク管理の重要性を認識しているIT技術者の間でさえ、悪い未来を口に出すことはなかなか難しいものです。
　
　このように、リスク管理が形骸化してしまうのは、単純に仕組みや知識レベルの問題だけが理由なのではなく、そもそもうまくいかない側面があるのです。

関連サービス