（改行）
リスク管理には手順がある
リスク管理とはプロジェクトの成功のめに危険（リスク）を管理（マネジメント）することです。
リスクを管理することなんてできるのか？といわれそうですが、早く見つけて早めに対処していくことがプロジェクトを成功させるためには必要です。
ところが、多くのプロジェクトではそのリスク管理ができていません。
たいがいのプロジェクトマネージャは問題なく進むと信じていますし、リスクを管理するというよりは、問題が表面化してはじめてことの大きさに気づくことも少なくありません。
チーム内やプロジェクトの進捗の報告を読む人にリスクに対する感度の高い人がいればいいのですが、そうでなければ問題が大きくなるまで気づかないという致命的な問題になることもあります。
リスクマネジメントは難しく、結局現場やそれを見守るマネージャの力量に任されるというのが現実です。
リスクは早期発見・早期対策
病気と同じで、プロジェクトのリスクは「早期発見・早期対策」が重要です。
僕が関わっていたプロジェクトでは、その「早期発見・早期対策」ができずに大炎上してしまったことがあります。
新規のプロジェクトを率いていたチームリーダーは、他部門と仕様調整に難航し当初考えていたような計画では進んでいませんでした。
その辺りの問題を含め、「順調ではない」ことをたびたびアラートとして発していました。
しかし、なぜかプロジェクトマネージャはその問題を「そんなに大きな問題じゃない」と高をくくっていたせいで、何の対処も行われないまま数ヶ月が過ぎてしまいました。
僕は周りから見ていて新規のプロジェクトにしては人の割り当ても少ないので、「大丈夫ですか？手伝いますよ」とそのプロマネに進言していたものの、「大丈夫だ」ということで済まされていました。
しかし、数ヶ月経ってテストを開始する頃、問題は発覚します。
仕様通りに作られていない箇所がどんどん発見され、バグとして登録されたのですが、まさにバグの山。
しかも一つ一つは他部門との仕様調整が必要なものが多く、修正にはとても時間がかかります。
そして、とてもテスト期間内には修正できないような量になり、その後大量の人を投入して仕様の調整やバグ潰しをしました。
結果的に、半年以上の大幅遅れで導入となりました。
この問題は「早期発見・早期対策」で完全に解決できる規模のものではなかったかもしれませんが、早く着手すればもっと小規模な炎上で済んだかもしれません。
プロジェクトマネージャの判断ひとつがプロジェクトを大炎上させることもあります。
リスクはあらかじめ出しておく
リスクは何かその後のプロジェクトの進捗に影響を与えそうだとかなえたとき、早めにアラートを出す、ということがとても重要になります。
ところが、それぞれ経験によって同じことに直面しても大きな問題と感じなかったり、そもそも問題と感じなかったり、自分の中で何とか片付けたいという気持ちが起きてしまいます。
そうならないように、まずはこういうことが大きな問題につながる可能性がある、ということをチームメンバーで共有しておく必要があります。
そうすることで「これってリスクに関係するかな？」というような考えが出ることで、早めにアラートが出ることにつながる期待があります。
リスクに関しては具体的なもので、かつそれが起きたときにどういう対処があり得るか、誰に相談すべきか、といったことを決めます。
まずはリスクを見える化しておくということが有効でしょう。
とはいえ、それがうまく機能するかはそれをうまく活用できるか、ということに関係します。
リスク管理を機能させる
リスク管理をしている会社であっても、そのリスクとして挙げるものがあまり起こりえないものだったり、簡単に思いつくものであることも少なくありません。
確かに、「リスクを挙げよう」と検討を始めても、なかなか適切なものが挙げられないことも多いのが現実です。
リスク何がリスクなのかをわかっていなければ、問題が発生しても担当者が解決すべきことと思うかもしれません。
出てきたリスクは、まずは優先順位を決めて管理していくことです。
管理するためには、継続的にレビューをしていくことが欠かせません。
一定の間隔で見ていくことで、リスクマネジメントしていないことに気づくことがあります。
プロジェクトの進行中は、ついついプロジェクトを進めることばかりに目が行き、リスク管理を忘れがちになります。
また、プロジェクトが進行することで、初期の頃にはぼやっとしていたリスクがもっと具体的に見えてきたり優先順位が変わったり、あるいは別のリスクが浮上していることに気づくこともあります。
プロジェクトの実情に合わせて、リスクの優先順位を変えたり、リスクをより具体的なものに絞り込んだり、あるいは新たなものを追加して改めて見直すことが有効でしょう。