- Amazon.co.jp ・電子書籍 (348ページ)
感想・レビュー・書評
-
リスク管理が大事そうな案件が出てきたので読んでみた。リスク管理しよ…と思った
詳細をみるコメント0件をすべて表示 -
カテゴリ:プロジェクトマネジメント
オススメ度:★★(特定の人にオススメ)
オススメ先:プロジェクト形式の仕事をする社会人全般
残ったフレーズ:リスク管理は注意すべきところに注意を向ける ああ、あの迫ってくる電車のことですか。
アクション:リスク管理への活用
その他:古からの名著。熊とワルツを踊るようにリスクと付き合えというお洒落さ。軽快な語り口で読み進めやすい かつ 頭に入ってくる。中規模・大規模プロジェクトの担当者であれば読むべき。 -
確率分布での見積り、リスク分布
締切駆動のスケジュールから脱却できる -
プロジェクト管理について書かれた一冊。
少し古い本だが、現在読んでも、納得できる事だらけ。
ITプロジェクト管理で悩んだことが少しでもあれば、読んで損はない一冊ではないかなと。 -
付録の文章がプロジェクト管理を物語で言い得ていて面白かった
-
ITプロジェクトにおける陥り易いシチュエーションを、論理的に、時にユーモラスに。『プロジェクトの天罰期』には心当たりありあり。あとがきで触れられていた笑い話。多くの人はかく言った。“上司に聞かせたかった”と。 責任転嫁をする前に、先ずは各々でリスクを寛容し、なすべき変革をそれぞれ行うこと。
-
【目的】 リスク管理の目的、方法、数量化や影響測定など、実践的なリスク管理を適用するための内容を紹介する。
【収穫】 そもそも何がリスクであり、なぜリスク管理をすべきかという問いに答えられるようになった。
【概要】 ■リスクの定義とリスク管理: リスクは将来起こり得る出来事で、望まない結果を生むもの。あるいは、望まない結果そのもの。言い換えれば、リスクとはまだ起きていない問題であり、問題とはすでに実現したリスク。リスク管理とは、原因となるリスクを管理すること。そして、問題が発生する前の、抽象的な概念の段階で対策を考えるプロセスのことをいう。リスク管理の反対を「危機管理」といい、問題が発生した後に対策を考える。
■リスクと移行指標: リスクの1つ1つに何らかの移行指標がある。すなわち、何によってリスクを実現したかとみなすきっかけであり、すぐに気づくよう監視する必要がある。
■リスク管理の各要素: ①リスク発見…リスクに関するブレスト、対象とするリスクの選別、リスク発見のための継続的プロセス導入。②エクスポージャー分析…それぞれのリスクが実現する確率とその影響の数量化。③危機対応計画…リスク実現後の対応策定。④軽減…計画した危機対応が適切にできるようにする事前準備。⑤継続的な移行監視…管理するリスクを追跡し、実現有無を監視。
■リスク管理すべき理由: 積極的にリスクをとれるようにする。不意打ちを防ぐ。成功するプロジェクトを作る。不確定要素を限らせる。保険を掛ける。責任転嫁を防ぐ。一部が失敗したプロジェクトを救える。人材の成長機会を高める。注意すべきことに注意できる。
■管理しなくていいリスク: ①実現確率が極めて小さい、②実現したら今の仕事など大したことではなくなる、③影響が極めて小さく軽減する必要がない、④他人のリスク
■リスク図: 「完成する可能性がゼロでなくなる最初の日」をNパーセント日とし、そこから完成する確率が100%になるまでの点をプロットした不確定図のこと。
■5つのコアリスク: ①スケジュールの欠陥、②要求の増大、③人員の離脱、④仕様の崩壊、⑤生産性の低迷
■リスク軽減のインクリメンタル手法: クライアントに提供する価値と、リスクに関する過程条件の確認に基づいて、初期のバージョンに入れ込む機能の優先順位を決定する。WBS上の予定作業とバージョンnまでに完了する作業から現在稼得価値(EVR)を算出することで、今何パーセントの作業が完了しているかを表す。
■リスクの数量化: コストだけでなく効果も数量化の必要がある。数量化されない場合にはまったく効果がないものと考えた方がいい。
■リスク管理手順: ①リスク発見プロセスを使って、プロジェクトのリスクをまとめる。②コアリスクが全て含まれていることを確認する。③リスクごとに名前、番号、移行指標、影響、実現確率、エクスポージャー、危機対応措置、事前軽減措置をフォーマットに従い記入する。④ショーストッパーを仮定し、上層部に引き渡す。⑤Nパーセント日を見積もる。⑥リスクモデルを使ってリスク図を作成する。⑦リスク図を使って約束を発注者に伝える。⑧WBSを作成する。⑨製品上で入出力する全てのデータフローについて承認を得る。⑩設計を完全に分割する。⑪WBSと分割した設計をもとに作業を全体に対する比率で表す。⑫価値をコストと同じ精度で評価する。⑬要求を基本要素まで分解し、優先順位をつける。⑭インクリメンタル開発計画を策定する。⑮最終製品全体の受入仕様を作成し、バージョンごとの受入検査に分割する。⑯EVRと各バージョンの納品予定をグラフにする。⑰リスクを監視し、リスク実現したら危機対応計画を実行する。⑱プロジェクト中は、リスク発見プロセスを継続する。
【感想】 プロジェクト管理の学習の一貫として読了。リスク管理についてこれだけ具体的に語っている本は他にあまり見つからなかったため、PMBOKについて流し読みしてピンと来なかった部分が、よりわかるようになった。ただ後半の具体的な手法を実践していないため、まだ頭に入り切っていない。重要な内容が多いため再読したい。