先日新聞に、ある著名なリスク管理の専門家の言葉が載っていた。内容は「リスクというのはある程度許容しないと、結局、全体としてのリスクが高くなる。リスクをある程度受け入れるという感覚が必要ではないか」というような趣旨であった。
もう少し調べてみるとこの専門家は「いたずらに危険性を騒ぎ立てず、リスクの程度を可能な限り定量化して評価し、合理的な対策を立てることが重要」という見解を持っていることが分かった。これはまさに、そのままシステム開発プロジェクトにも当てはまるリスク管理の考え方であろう。
プロジェクトマネジメントの参考書などを見ても必ず「リスク管理」という言葉は出てくるし、その重要性もITエンジニアであれば頭では分かっているはずだ。しかし実際のプロジェクトを見ると、意外にこのリスク管理をきちんとやっていないケースが少なからずあるようだ。いわゆる「課題管理」と混同している場合が多いのである。
大まかに分類すれば、課題は既に発生して顕在化している事象、一方のリスクはまだ発生はしていないが、プロジェクトが進捗していく過程で危険や損害に遭遇する潜在的な可能性といえるだろう。リスクというのは見えないし、発生するかどうか分からないので、その管理が難しいことは確かである。しかし難しいからこそ、リスクをきちんと想定しておくことが重要だ。そうしないと、ある日リスクが顕在化したときに、右往左往することになる。
あるプロジェクトのテストフェーズのレビューに立ち会ったときのことだ。プロジェクトには遅延が発生しており、その対策が話し合われた。プロジェクト計画書にはリスク管理という言葉があったが、レビュー会議の席上では、マスタースケジュールやWBS、課題管理表はあるもののリスク管理に関する資料がない。プロジェクトの状況と遅延のリカバリー策がプロジェクトマネジャーから説明されたが、課題への取り組みは熱く語られるのに、やはりリスクに対する言及はない。
そこで筆者は「説明のあったリカバリー策を実行する上でのリスクはなんですか？」と質問してみた。するとプロマネは「リスクですか？課題はすべて出しましたが。とにかく遅延をリカバリーするためにはこの計画でいくしかないと考えています」と予想通りの回答であった。「リスクとはこのリカバリー計画が想定通りにいかない阻害要因となるものがあるかないか、それをあらかじめ考察することです。例えば…」とリスクを指摘していくと、いくつも出てきたのである。
例えば、このリカバリー計画では土日の作業も予定されていた。しかし調べてみると、社内レイアウト変更工事の予定が曖昧で、作業できない日が数日生じる可能性が判明した。それらの日を外して再計画すると非常にタイトなスケジュールになってしまう。そこで、リスクが発現しないよう、回避策をとった。まず、ユーザーにも休日出勤を依頼し、テスト結果をその場で確認してもらうことで時間短縮を図った。また、リカバリー計画よりもテスト進捗が遅れる状況になった場合の想定もなかった。その場合に備え、テスト項目や既に課題となっているバグ修正などの優先順位を再度見直すこともユーザーに依頼した。
実際にこのプロジェクトでは、当初のリカバリー計画通りにはいかなかった。だが、そのリスクを想定してユーザーも準備していたので、優先度を下げた課題対策の一部を本番稼働後の保守に回すということで落ち着いた。
プロジェクトのスケジュールが押してくると、どうしても希望的観測で走りたくなる。だがそういうときこそ、リスク管理をきちんと行うことが必要であることを忘れてはならない。それがまずできていなければ、冒頭の専門家の言葉にある「リスクをある程度許容する」ことなどできない。
