TOPプロジェクト管理> リスク管理の計画プロセス

「即活用!企業システムにおけるプロジェクト管理」

第8回:リスク管理

著者:システムインテグレータ  梅田 弘之   2005/2/7
前のページ  1  2   3  次のページ
説明の中で、(I1)や(S2)などの記号が出てきますが、これは第1回で使ったプロジェクト管理状況チェック表のNo.と対応しています。チェック表で明らかになった問題点に対応する部分は、特に注意して読んでみてください。
リスク管理の計画プロセス

   計画プロセスの作業は、プロジェクト開始時にリスクを洗い出し、その対策を考えておくことです。PMBOKでは、リスク管理計画を立て、リスクを特定し、リスクの定性分析と定量分析を行い、リスクの大きさに応じた対策を立てるという5つのプロセスを定義しています。これら全てを個々のシステム開発プロジェクトに適用するのは大仰過ぎるので、プロジェクト管理手法「PYRAMID」では「リスクの特定と対策」というポイントだけを実装しています。

   計画プロセスで大切なのはリスクをあげつらうだけでなく、それに対する対策をきちんと立てることです(R1)。リスクを洗い出すのは比較的簡単です。「開発メンバーが集まっていない」「メンバーが技術に不慣れ」「ユーザーの仕様がなかなか決まらない」などなど、たくさんのリスクがあげられるはずです。

リスクの例
  • 開発メンバーが集まっていない
  • メンバーが技術に不慣れ
  • ユーザーの仕様がなかなか決まらない

   難しいのは、これらのリスクに対する適切な対策を立てて実行することです。ついつい「リスクは分かっているけど、現状どうしようもない。がんばってくれ!」という精神論に置き換えられてしまいますが、これではデスマーチは必須です。開発メンバーが足りないのなら「実際に社内外にメンバー集めをアプローチする」、技術に不慣れなら「スキルのあるメンバーを探すかトレーニングする」、ユーザー仕様が決まらないなら、「ユーザーに指摘してスケジュールを見直してもらう」など取り行うべき対策とアクションはあるはずです。

対策とアクション

   PYRAMIDでは、このようなリスクと対策を文書化し、具体的な対策を明確にすることが重要と考えています。図1は、PYRAMIDにおける「リスク要因管理表」のテンプレートです。プロジェクト計画段階において考えられるリスクを分類ごとに洗い出し、その具体的対策とセットで書き出します。このようなドキュメントをもとにして、プロジェクトマネージャとプロジェクトリーダ、プロジェクトリーダとプロジェクトメンバ間でリスク情報を共有します。
情報を共有することで、協議の上で立てた対策がきちんと実行されているか相互監視され、対策が推進されるのです。

   リスクには、発生確率と影響度合いという2つのファクターがあります。「相手の会社が倒産する」などは、発生確率は低いがその影響度が大きいリスクですし、「客先の仕様がころころ変わる」などは、発生確率が高いがその影響度は(内容にもよりますが)限定されるリスクと言えます。PMBOKでは、定性分析および定量分析でこれらのファクターを分析し、リスクに重みを付けて優先順位をつけるように定義されています。しかし、ここではもっと簡略化してリスク度という5段階の重み付けだけを入れるようにしています。

PYRAMIDの「リスク要因管理表」テンプレート
図1:PYRAMIDの「リスク要因管理表」テンプレート
(画像をクリックするとEXCELファイルをダウンロードできます。/26KB)



リスク管理の管理プロセス

   管理プロセスの基本は
トラッキングコントロールです。状況を常に把握(トラッキング)し、正しい方向に導く(コントロール)することが"管理"なのです。プロジェクト管理におけるトラッキングには、次のようなものがあります。プロジェクト管理の3大要素であるQ(品質)、C(コスト)、D(スケジュール)に加えて、リスクも重要なトラッキング対象だということがわかります。

  • 品質のトラッキング
  • コストのトラッキング
  • スケジュールのトラッキング
  • リスクのトラッキング

   ところで皆さんの周囲に、状況報告だけさせて管理した気になっている管理者はいませんか?情報を聞くだけで、具体的対策を指示しないのでは"管理"になりません。トラッキングとコントロールがセットになって初めてマネージメントと言えるのですが、そういう名ばかり管理者が非常に多いのが現在のIT業界の課題だと言えます。

   プロジェクト計画時に予見するリスクは「リスク要因管理表」にまとめますが、リスクはプロジェクトの実行段階にも次々と現れます。PYRAMIDでは、このようにプロジェクト遂行中に発見されたリスク(問題点)を別フォーマットに書き出してコントロールします。図2は、このテンプレート「課題・問題点リスト(残件リスト)」で、使用目的としては"残件リスト"としての役割を強くしています。人間は嫌なことは忘れてしまいたいという本能がありますので、問題点を放置しないように必ずリストに記載するようにしましょう(R2)。

PYRAMIDの「課題・問題点リスト(残件リスト)」テンプレート
図2:PYRAMIDの「課題・問題点リスト(残件リスト)」テンプレート
(画像をクリックするとEXCELファイルをダウンロードできます。/19.5KB)



前のページ  1  2   3  次のページ



著者プロフィール
株式会社システムインテグレータ  梅田 弘之
東芝、住商情報システムを経て1995年にシステムインテグレータ社を設立。 常駐・派遣主体の労働集約的な日本のソフトウェア業の中で、創造性にこだわってパッケージビジネスを行っている。 国際競争力のない日本のIT産業が、ここから巻き返しを図るための切り札は「プロジェクト管理」だと信じ、実践的なプロジェクト管理手法「PYRAMID」を自社開発している。


INDEX
第8回:リスク管理
  常駐・派遣型から脱却できない理由
リスク管理の計画プロセス
  リスクの監視と管理は現場・現物