早い段階からプロジェクトの阻害要因となるリスクを洗い出して対応策を立案・実施する。さらに，対応策の実施状況を的確にトラッキングすることで，リスクをコントロール下に置く。こうした「リスク・マネジメント」を確実に実施してリスクの顕在化を未然に防止することが，プロジェクトの成功には必須となる。
布川 薫／日本IBM
今回は，情報システム開発プロジェクトで極めて重要な「リスク・マネジメント」について解説する。
リスクとは，プロジェクトの計画通りの目標達成を阻害する，潜在的な問題のことである。プロジェクトにどんなリスクが潜んでいるのかを識別してその影響の大きさを評価し，リスクを顕在化させないため，あるいは万一顕在化しても影響を最小限にとどめるための対応策を策定・実行する。このサイクルをプロジェクトの全期間を通じて繰り返し実施するのが，リスク・マネジメントだ。プロジェクトを成功させるためには不可欠なプロセスなので，ぜひ正確に理解して欲しい。
重要になる技術の「最適化」
リスク・マネジメントの説明に入る前に，最近のプロジェクトで特に気を付けるべきことに触れておこう。
最も注意すべき点は，どのようなシステム形態や開発方法を採用するかが，リスクの多くを左右するようになってきたことである。このため，ハード，ソフト，ネットワーク，開発方法を十分に最適化（Optimization）することが，プロジェクトの成否を決めるカギと言ってもいいほど重要になっている。
最適化とは，パフォーマンスやトランザクション量，セキュリティといった品質要件，プロジェクト期間，開発・支援体制，開発・運用コストなどを総合的に考慮したうえで，ユーザー企業の要求に最も適したシステム形態や開発方法を決定することである。この最適化の検討を誤ると，最初から大きなリスクをはらむことになる。プロジェクトの失敗は約束されたようなものだ。
最近は，上流工程でプロトタイプを作成してリスクや有効性を検証する「スパイラル型」や，一定期間に複数の開発サイクルを繰り返す「イタラティブ（反復）型」の開発プロセスを採用するケースが増えている。こうした場合には，開発過程で作業量が増大しないよう歯止めをかけることが，リスク・マネジメントの観点から極めて重要になってきている。
要件定義もまともに行わないまま，やみくもにスパイラル型やイタラティブ型の開発に入ると，必ずといってもいいほど「いつまでたっても開発が収束しない状態」に陥り，大幅なプロジェクトのオーバーランにつながる（図1）。これを防ぐためには，しっかりとしたプロジェクト・スコープの検討と開発計画の策定，開発途中での仕様変更への対応とコントロールが必須となる。
 |
| 図1●無計画にスパイラル型やイタラティブ型の開発に入ると，開発を繰り返すたびに変更や不整合が多発し，いつまでたっても収束せず，コスト超過となる |
リスク・マネジメントの流れ
以上の基本を踏まえたうえで，情報システム開発プロジェクトにおけるリスク・マネジメントについて解説を進めよう。
図2に，リスク・マネジメントの一般的な手順を示した。図に示すようにリスク・マネジメントでは，まず「リスクの識別」（図2のP1）と「リスクの定量化」（図2のP2）を実施する。
 |
| 図2●リスク・マネジメントのプロセス（DFDで記述） |
リスクの識別は，プロジェクトで起こると予想されるリスク項目（リスクに名前を付けて区別できるようにしたもの）を洗い出す作業のことである。
リスクには，プロジェクト・マネジャーがその影響をコントロールできる「内部リスク」（開発コストの見積もり，開発工程や手法の選定など）と，プロジェクト・マネジャーによるコントロールの及ばない「外部リスク」（法律や制度の改正とその時期，社会情勢の変化，新製品の発売時期など）がある。リスクの識別では，内部リスクと外部リスクの両方について，どのような要因によって何が引き起こされるか，どのような結果を避けるべきなのか，といった観点で検討しなければならない。
一方のリスクの定量化とは，洗い出したすべてのリスク項目の発生しそうな時期や，発生する確率，影響の大きさなどを評価して定量化（金額換算）する作業のことだ。
リスクの識別と定量化は，プロジェクトの提案時，計画時といった早い段階で実施する。ほとんどのリスクは，プロジェクトの初期段階から対応する必要があるため，早い段階でのリスクの識別・定量化は必須と言える。リスクの識別・定量化の結果は，分類／整理したうえでリスクのリストとして，きちんと文書化しておく。
プロジェクト開始後も，継続的にリスクの識別・定量化を行う。リスクは，プロジェクトの進行に従って常に変化していくものだからだ。例えば，新システムに組み込みを予定していた新製品の納入が遅れると，スケジュール遅延やコスト超過，品質不良につながり，ひいては契約上のペナルティの引き金になることもある。また，プロジェクト進行過程におけるチーム・メンバーの士気の低下が，スケジュール遅れやバグに直結することも多い。
特に，各フェーズの完了時には，必ず識別・定量化の見直しを実施するべきだ。プロジェクト・マネジャーが把握したリスク状況は，月次報告などで定期的に上位のマネジャーにレポートする。
