ITプロジェクトの実践～リスク・マネジメント～ 最終回 リスク・マネジメントに挑戦してみよう｜建設情報クリップ

 

 

---

 
前月号ではWBS（Work Breakdown Structure）をもとに現実的なスケジュールを立てる方法を紹介した。
これによりプロジェクトは、あらかじめスケジューリングされた項目に従って作業を進めることができる。
しかし、しっかりした計画を立てても、予定外の事象により納期遅延につながることもある。
予定外の事象には、どの様に対処すれば良いのだろうか？
運を天に任せるのではなく、「備える」ことが大切だ。
今回は、備えるための技術、リスク・マネジメントについて解説する。
 
 

「リスク」、「リスキー」という言葉は、日常会話の中でもよく使われますが、
その意味を問われると正確に答えられる自信がない方も多いのではないでしょうか。
 
プロジェクトマネジメント（PM）の世界では、リスクは、
「もしそれが発生すれば、プロジェクトにマイナスまたはプラスの影響を及ぼす不確かな事象」と定義されています。
「もしそれが発生すれば」そして「不確か」と表現されているように、リスクは、まだ発生していない事象であることがわかります。
顕在化して悪い影響を与える状態になったものは「問題（issueまたはproblem）」となります。
「リスク」と「問題」の違いはしっかり認識しておきましょう。
 
また、発生すればプロジェクトに何らかの影響を及ぼすものがリスクで、発生しても影響がないものはリスクではありません。
マイナスのリスクは発生させないように、プラスのリスクは活かすようにコントロールします。
通常、ITプロジェクトのリスク・マネジメントでは、マイナスのリスクを対象にします。
 
先を見越して事前に対処することを考えるのがリスク・マネジメントです。
起こった問題への対処はイッシュー・マネジメントと呼びます。
投資理論家であるピーター・バーンスタイン氏によると、
リスクという言葉は、「勇気を持って試みる」という意味のイタリア語「Risicare（リシカーレ）」という言葉に由来しているそうです。
リスク・マネジメントは、チャレンジを成功させるために必要な技術とも言えます。
 
 

ITプロジェクトのリスクについて考えてみましょう（図-1）。
 

 
もともとITプロジェクトは、ソフトウェアが形のないロジックの集合であることから、
要求仕様が曖昧で、よく定義されていない状態でプロジェクトを始めなければならないことが往々にしてあるなどハイリスクです。
システムの停止が社会の混乱に結びつくようなシステムや
納期遅延が組織の信用失墜やビジネス機会の損失につながるようなシステムを開発する場合は、
品質リスクや納期遅延のリスクを徹底的に排除するアプローチが必要です。
 
一方、近年、経営の質を向上させるための戦略的なシステムやネットを利用した便利で新しいサービスが注目を集めています。
こうしたシステムやサービスの開発は、合理化や省力化を狙うシステムに比べて、要求も捉えにくく難易度も高くなります。
また、新技術や新しい開発方法など未経験の領域が増えると失敗へのリスクも高まります。
ときにはリスク覚悟で進めることも必要で、リスクとうまく付き合っていくアプローチが求められています。
 
トム･デマルコ氏は、リスク・マネジメントのことを「おとなのプロジェクトマネジメント」と表現しています。
起こったことに対処するだけでなく、あまり考えたくないことも含めて、
起こりそうな問題からプロジェクトを守るために、大人になって対処することの大事さを説いています。
 
 

単に「リスクを洗い出しましょう」と言っても、それぞれ思い描くものが異なるかもしれません。
通常、「○○に対するリスク」のように修飾語をつけて表します。
今回扱っているのは、プロジェクト・リスクですから、
「プロジェクトの成功を阻むリスク」ということになりますが、これでもまだ漠然としています。
 
あるプロジェクトは、利用者の要求する機能をすべて実装して、納期どおりに、品質も満足する状態でリリースされました。
ベンダー側はコスト超過になっていますが、発注側は、請負契約で追加請求はなかったので予算内で収まっています。
このプロジェクトは成功プロジェクトでしょうか？
少なくともベンダー側は、コストを守れなかったので成功プロジェクトとは言えません。
では、発注側は成功プロジェクトでしょうか？
ここまででは、まだ不十分です。開発したシステムが利用され、目標とした成果をあげて初めて成功プロジェクトとなります。
このようにプロジェクト成功の条件は、ステークホルダー（利害関係者）によって変わってきます。
それぞれプロジェクトへの期待が異なるからです。
 
リスク・マネジメントの第一歩は、プロジェクトの成功を定義することから始まります。
ベンダー側なら例えばQCD（Quality、Cost、Delivery）や顧客満足度の目標値を設定し、
目標値を守れないリスクを洗い出していきます。
発注者側は、加えてシステムの効果を目標として設定し、それを阻むリスクを洗い出していきます。
 
 

リスク・マネジメントの大まかな流れを図-2に示します。
この流れに沿って主な手法を見ていきましょう。
 

 

最初のステップは、「リスク特定」ですが、これが最も重要です。
リスク特定とは、リスクに気付くことです。
重大なリスクもがあって気付かなければ、対策の立てようがありません。
そして気付くのが遅くなれば、対処が後手に回り、影響は大きくなります。
 
それでは、リスクの洗い出しに効果的な方法を見ていきましょう。
3つの代表的な方法を紹介しますが、それぞれ単独で使うこともあれば、組み合わせて使うこともあります。
 
1つ目はチェックリストです。
PMO（ProjectManagement Office）などにより準備されたチェックリストを使います。
チェックリストは、通常、過去のプロジェクト経験からまとめます。
ITプロジェクトは似たような要因で混乱することが多く、
他のプロジェクトで起こったことは、担当するプロジェクトでも起こる可能性があるという観点でチェックします。
共通的なリスクを抽出するのにチェックリストは効果的ですが、
チェックリストだけではプロジェクト固有のリスクを抽出することができません。
そのため、2つ目と3つ目にご紹介するブレーンストーミングとRBS（Risk Breakdown Structure）を活用します。
 
2つ目のブレーンストーミングは、よく知られたアイデア発想の方法です。
複数人で集まり、ルールに則りたくさんのアイデアを出していきます。
リスク・マネジメントにおいてブレーンストーミングは、潜在しているリスクを探すために行いますが、
色々な角度で自由にアイデアを出すこの方法は非常に有効です。
特に新規性の高いプロジェクトは、未経験ゆえにリスクを洗い出すことが困難です。
ブレーンストーミングで、アイデアを出し合うことで、1人で考えても出てこないようなリスクを発見することが可能になります。
経験者や専門家を交えると有効です。
 
3つ目はRBSです。
図-3の例をご覧下さい。
 

 
この図、どこかで見覚えがありませんか？
そうです、7月号で紹介したWBSです。
WBSは、作業（Work）を漏れなく分解（Breakdown）し、構造化（Structure）して、見える化する手法でした。
RBSも同じ考え方です。
リスクとなる要素を漏れなく分解し、構造化して、見える化します。
リスクは網羅的に洗い出すことが重要ですが、
大規模で複雑なプロジェクトのリスクを洗い出すには、RBSのように構造化できる手法が有効です。
上位の要素から漏れなく分解していくことで、気付きを促進しリスクの洗い出し漏れを少なくします。
 
RBSは、ブレーンストーミングの前に作ることをお勧めします。
ある程度テーマを区切って実施するとアイデアが出やすくなります。
例えば、テーマを「納期遅延のリスク」とするより、「基本設計が遅れるリスク」とした方がアイデアが出やすくなります。
また、RBSだけでなくアイデアの創出を促進するために、準備したキーワードからリスクを連想させる方法や
WBSからプロジェクトの進め方をイメージしてリスクを連想する方法も活用するとよいでしょう。
 
リスクを洗い出すために3つの方法をご紹介しました。
洗い出したリスクは、リスク登録簿（図-4）に記載します。
リスク登録簿の各項目は、リスク・マネジメントの流れに沿って埋めていきます。
 

 

リスク分析では、リスクの優先度を決めます。
前ステップのリスク特定によって、多数のリスクが洗い出され、リスク登録簿には大小さまざまなリスクが記載されます。
しかし、これらすべてに対処するのは、コスト、スケジュール面で現実的ではありません。
優先度が高いものについて対処するようにします。
優先度については、一般的に2つの尺度で決めます。
 
1つは「発生確率」です。
リスクは不確実な事象のことですが、ほぼ発生しないものや、高確率で発生するものなどがあります。
これをランク付けして評価します。
目的はリスクの優先度を決めることなので、ランクは5段階でも3段階評価でも構いません。
2つ目の尺度は、「影響度」です。
もし発生した場合のコスト、スケジュール、品質などに与える影響度です。
これもランク付けして評価します。
このようにして、2つの尺度で評価したランクをリスク登録簿に記載します。
 
優先度は、図-5のようなリスクマップを書いて決めます。
 

 
発生確率が高く、影響度が大きい①のゾーンは対策を検討する優先度が高いリスク、
発生確率が低く、影響度が小さい③のゾーンは優先度が低いリスクとなります。
では、②の発生確率は高いが、影響度は小さいリスク、
逆に④の発生確率は低いが、影響度の大きなリスク、これらはどう考えればよいでしょうか。
②は、実際に分類してみると「設計ミス」など、起きてからの対応方法が今までの経験からわかるリスクが多いと思います。
④は、コストとのバランスを考え慎重な判断が必要です。
安全性に関わるリスクは優先的に対応を検討します。
 

リスク対応計画では、優先度の高いリスクへの対応方法を検討します。
リスクへの対応方法としては、以下の4つがあります。
 
①リスク回避　リスクの排除、無影響化
②リスク移転　影響、責任を第三者や相手に移転
③リスク軽減　発生確率や影響を軽減
④受容　リスクへの事前対処をせず受け入れる
 
①の「リスク回避」は代替案やスペックのグレードアップなどによりリスク自体を排除します。
 
②の「リスク移転」の代表は保険ですが、契約形態によるコントロールもよく使われます。
請負は、受託した業務を責任を持って完成させる契約でベンダー側がリスクとリターンに責任を持ち、
準委任は、業務の代行などを行う契約で発注側がリスクとリターンに責任を持ちます。
準委任から請負契約に切り替えると、ベンダー側へリスクが移転されますので、リスク費分、価格の見直しが発生します。
 
③の「リスク軽減」策としては、予備費の確保、予防策の検討、不測事態への対応計画立案などがあります。
予備費は、問題が発生したときに備えて確保しておく費用です。
プロジェクトの初期段階では、
リスクは洗い出せてもどれぐらいの影響があるか予測できないものや漏れているリスクがあるかもしれません。
発生した問題への対応には予定外の費用がかかります。
予備費を確保しておくことは、プロジェクトの安定した運営に極めて重要です。
 
④の「受容」もリスク対応策です。
「何もしないでも大丈夫」と見切るリスクや「起こったら仕方がない」と割り切るリスクもあります。
大事なことは、「受容する」と明確に意思決定することです。
 
「（2）リスク分析」で対応すると決めた各リスクの具体的な対応内容を検討し、リスク登録簿に記載します。
なお、プロジェクトの混乱につながるリスクや発注側がトリガーになり得るリスクについては、
積極的に共有し一緒に対応を検討します。
 

リスク・コントロールでは、プロジェクト全期間にわたりリスクを監視し、
リスク登録簿を更新しながらリスクへの対応をコントロールしていきます。
 
プロジェクトの進捗に伴い、新たなリスクが発生したり、リスクの発生確率や影響度が変わることがあります。
また、環境変化などプロジェクト外部の要因がトリガーになるリスクは、
トリガーが明確で顕在化したことを見つけやすいのですが、
内部の要因がトリガーになるリスクは、徐々に進行することが多く、問題の認識が遅れます。
リスクや問題は早期発見が肝心です。思わぬ問題が起こらないように継続してリスクを監視・管理してくことが大切です。
 
 

プロジェクト完了時点で、そのプロジェクトのリスクはなくなります。
ですが、組織としてリスク・マネジメントを向上させるための大事な仕事が残っています。
ITプロジェクトは似たような要因で混乱することが多いため、
他のプロジェクトの経験をチェックリスト化することが有効だと述べました。
プロジェクトを振り返って発生した問題を分析し、
次に続くプロジェクトに活かすために教訓を組織として蓄積・共有化することが重要です。
振り返りを終えてプロジェクトは完了します。
 
 
本連載では、3回にわたってIT プロジェクトを成功に導くためのプロジェクトマネジメントの基本的なテクニックを解説しました。
どれもすぐに使えて効果が高いテクニックですので、ぜひ活用してください。
 

 
 
 
〔編注〕
プロジェクトマネジメントにつきましては、「積算資料」2013年10～12月号に「プロジェクトマネジメントの薦め ～ ITプロジェクトを成功に導く～」も掲載しております。
 
第1回：なぜプロジェクトマネジメントが大事なのか？《前編》
第1回：なぜプロジェクトマネジメントが大事なのか？《後編》
第2回：プロジェクトマネジメントの知識体系《前編》
第2回：プロジェクトマネジメントの知識体系《後編》
最終回：プロジェクトマネジメント・オフィス《前編》
最終回：プロジェクトマネジメント・オフィス《後編》
 
 
 

［1］PMI（Project Management Institute）「プロジェクトマネジメント知識体系ガイド（PMBOKⓇガイド） 第5版 日本語版」、
　　 PMI、2013
[2] ピーター・L・バーンスタイン「リスク－神々への反逆」（青山護訳）、日本経済新聞社、1998
[3] トム・デマルコ、ティモシー・リスター「熊とワルツを リスクを愉しむプロジェクト管理」（伊豆原弓訳）、日経BP社、2003
[4] 初田賢司「システム開発のためのWBSの作り方」、日経BP社、2012
[5] 初田賢司「本当に使える見積もり技術 改訂第3版」、日経BP社、2013
 
 
 
ITプロジェクトの実践～スコープ・マネジメント～ 第1回 WBSを作ってみよう
ITプロジェクトの実践～タイム・マネジメント～ 第2回 スケジュールを作ってみよう
 
 
 
【出典】

---

月刊積算資料2014年9月号

 
 

最終更新日：2014-12-26

 

ピックアップ電子カタログ