投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
21章のみためになった。
どれほどのリスクをとる覚悟をするべきだろうか。プロジェクトがもたらす可能性のある価値を考慮する必要がある。価値を無視して実践できるリスク管理の理念などない。潜在価値が高ければ重大なリスクでもとる価値がある。潜在価値が低いのなら、たいていのリスクはとるべきではない。
デスマーチの正当化にいつも使われるのは、プロジェクトの重要性である。「このプロジェクトはきわめて重要なものだから、プロジェクト要員には精一杯がんばってもらわねばならない。」だが、このことがにはちょっとした謎がひそんでいる。プロジェクトがそれほど重要なら、どうして会社はそれを適切に遂行できるだけの時間と資金をつかえないのか。
共通する性質として、予想される価値が低いことにある。どうしようもなくつまらない製品を世に送り出すためのプロジェクトなのだ。
企業にとって最大のリスクは、価値にかんするリスクである。すなわち、価値の低いプロジェクトに無駄な労力をつぎこみ、価値の高いプロジェクトを逃して機会コストを負うことである。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
[読んだ理由]==================
「100人のプロが選んだソフトウェア開発の名著」にあった。PM、特にリスク管理って全然わからないので一度読んでみたいと思った。
[読んだ後の感想]==============
主なポイントは下記かなぁ、と思った。
・プロジェクト着手前に、想定しうる最悪のリスクまで徹底的に出しきっておく。
・「やらなければならない」作業だけでなく「やらなければならないかもしれない」作業も予想しておくべき。
・「コスト」と同様に「効果」も数量化すべき。でないとプロジェクトの「効果」が測れない。
・プロジェクトの最短だけでなく最遅の完成期日も予測し、その両方の結果から現実的な期日を予想する。
・リスクの大きな作業は極力先に済ませる事で、プロジェクトの柔軟性を極力確保する。
[読書録]======================
■第一部:なぜリスクを管理するのか
リスクのないプロジェクトには手を付けるな。全くリスクのないプロジェクトに手を出すのは負け組だ。必ずといっていいほど、何もえるものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。
■第二部:なぜリスクを管理しないのか
リスク管理をすべきでない理由の一つ:はっきり不確定幅を決めると、出来の悪い仕事を許すことになる。
⇒SWマネージャは「予測と目標は同じである」という標準ルールに従う傾向がある。しかしリスク管理のルールによれば、マネージャはいつも部下が最高の仕事を目指して努力するように目標を設定すべきである。その一方、クライアントや上層部に約束をする時には、目標とは全く別の予想を使うべきである。
「間違えるのは構わないが、不確かなのは駄目だ」と言うルールが自分の会社に当てはまったら、おしまい。このルールの意味は、約束した納期に間に合わなくても良い、大幅に遅れても構わないが、その日までの間、期日に間に合いそうもないといってはならないということだ。
「近づく電車が見えない症候群」「選択的近視」:
⇒これを避けるには、リスク管理をはじめる時点で、思いつく限りの破滅的な結果を並べて見ること。
つまらない心配事より、悪夢を攻撃せよ。
SWプロジェクトでは概して、且つために特別なことをするより、負けの程度を抑えるほうが大事なのだ。この仕事では、どんな組織も負けることがある。他の時に勝ったことがあろうがあるまいが、負けた時に最も痛手を受けたものが本当の負である。
■第三部:リスク管理の方法
SWプロジェクトマネージャの殆どは、「やらなければならない」作業についてはほぼ正確に予想できるが、「やらなければならないかもしれない」作業は正しく予想できない。
この業界は、予定より早く終わるという第三の結果を事実上不当なものとみなすことで、期日通りに完成する可能性をほぼゼロにしているのだ。いい加減なスケジュールを許さないがために、むしろいい加減なスケジュールが例外ではなく当然になっている。
全体リスクの不確定性は、成否を決める各々の原因の不確定性を積み重���た結果である。
N(ナノパーセント日:その日に完成する可能性がゼロではない最初の日):
人は楽観的な声質を持っており、過去の経験から、可能な範囲で最も楽観的なスケジュールであるNを見積もることにはかなり熟達している。しかし、Nに完成すると約束するのではなく、本当に約束すべき納期を決定するためのデータとしてNを使うことが重要。
プロジェクトでも損は早めに出してしまうに限る。其の様なときは一旦主導権を失い、成り行きに任せることになる。しかし、早めにそうしておけば、強みを温存しておいて主導権を取り戻すことができる。システムのウチ技術的に軌跡に頼る部分は、初期のバージョンに組み込むべきである。そうすれば、奇跡が起きなかったとしても、いざというときの選択肢が最大限に多い。
インクリメンタル開発計画:
・制約の1つ:詳細設計図に、設計の分割を最低レベルまで全て示さなければならないこと。通常は、高レベルの設計を適当に済ませて設計が完了したと宣言し、後の設計分割作業はコーディングの副産物として行われているのが現状。
・メリット:区切りが多いため、プロジェクト要員の士気が保たれる。状況が目に見えやすい。プロジェクトの最後に残るのはほとんど余計なお飾りの機能だと分かり、その部分をカットできる可能性がある。
■第四部:数量化の方法
コストと効果は同じ精度で表す必要がある。「どうしても要るのだ」としか効果を言い表せないのなら、コストも「相当かかるだろう」とするべきである。
開発者と発注者の説明責任は平等であるべきだ。発注者には、価値が生み出されることを確認する責任がある。ところが、我々のアンケートによれば、企業はプロジェクトの完了後に、効果を実現できたかどうかを追跡調査していない。
製品が大きくなることでコストが比例以上に増大するとしたら、製品を小さくすればコストを比例以上に節約できるはずだ。システムの中で価値コスト比率の低い部分を削減することは、時間と予算に対する制約を緩める最も簡単な方法。ソフトウェア開発者は「もっと小さなソフトウェアを」をスローガンにしようと考えるべきだというと妙に聞こえるかもしれないが、そのほうが有利なことは明らかだ。
デスマーチの正当化にいつも使われるのは、プロジェクトの重要性である。「このプロジェクトは極めて重要なものだから、プロジェクト要員には精一杯頑張ってもらわねばならない」。だが、プロジェクトがそれほど重要なら、どうして会社はそれを適切に遂行出来るだけの時間と資金を使えないのか。
我々の経験では、デスマーチプロジェクトに共通する性質として、予想される価値が低いことがある。どうしようもなくつまらない製品を世に送り出すためのプロジェクトなのだ。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが成果を上回ることが明らかだからだ。
■第五部:嘘か真か
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
熊とワルツを踊る = リスクの評価、抑制、軽減を行うこと。
インクリメンタル開発の下りを読んで、今時だとアジャイル開発でやってそうだなーと思ったら関連文献に XPエクストリーム・プログラミングが載ってた
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
先輩から借りた。思えばリスクを想定しないまま(または、わかってて放置したまま)走ることが、ままある。おこちゃまなPJ管理から抜け出さねば。。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
・良書。プロジェクトのリスク管理の入門書。
・投資クラスタで馴染みのリスク・リターンを他の事に生かせないかと思い読んでみた。
・モンテカルロ・シミュレーターとか面白そう。
・紹介されているリスク管理ツールRiskologyは、残念ながらダウンロードページが既に削除されている模様
・ただしグーグルのキャッシュから辿った所、ツール自体はまだ置いてある模様
・Riskology
http://www.systemsguild.com/riskology/RiskologyV4.xls
・マニュアル
http://www.systemsguild.com/riskology/RiskologyManual.pdf
・日本語マニュアル
http://www.jttk.zaq.ne.jp/bacae808/Risk_yaku/japanese.doc
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
http://kashiwabaray.com/blog/index.php?itemid=395
リスク管理がテーマの1冊となります。リスク管理は仕事でも重要となるので、参考となる1冊でした。「アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン」も面白かったですが、こちらもおすすめできる1冊です。
■リスクを管理すべき理由
―リスク管理は積極的にリスクをとれるようにする
一般的な企業文化の中でリスク管理が難しいのは、不確定なものを系統的にあつかうことになるからだ。
―リスク管理は不意打ちを防ぐ
この業界には、「やればできる」思考が蔓延している。そのせいで、「できない」ことを示すような分析は叩かれる。リスク管理をすれば、多少の「できない」思考は許容される。リスク管理のしくみを導入すれば、少なくともある程度の時間は、人びとにマイナス思考を許すことになる。
―リスク管理は成功するプロジェクトを作る
―リスク管理は不確定要素を限りあるものにする
無限の不確定要素の前では、人はリスクを避けるか、自暴自棄になるかのどちらかである。どちらも最悪だ。
―リスク管理は最小限のコストによる保険である
不確定要素がわかれば、自分の身をしっかり守るためにどれぐらいの備えが必要かもわかる。
リスクを管理した上でリスクを受け入れるのと、リスク管理をしないでリスクを受け入れるのは訳が違う。リスクを避けるのではなく、リスクに積極的に立ち向かおう。
【1読書1アウトプット】
リスクに積極的に立ち向かう
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
前半は抽象的で啓蒙的な内容。ソフトウェア開発に限らず様々なプロジェクト管理に適用できる「考え方」が記述されている。
後半は実践的な内容となり、リスク管理が業務に組み込まれている環境でなければ取っ付きにくい。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
☆4
本編よりも、付録A「信念の倫理」に強く共感したよ!私が科学好きなのも、知ることが楽しいのも、全てここに繋がってた。
世代を重ねて蓄積された人類の財産にアクセスしながら、これからも責任をもって、注意深く私の信念を言葉にしていきたいと思ったよ。
リスク管理は、もっと大きな仕事を扱うようになったら徐々にこの本から取り入れていけばいいかな、と思った。
読み物としても、飽きずに面白く読めたよ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
人々合意することになっている協力することになっている根深い対立があってそれができなくても表向きは取り繕われることが多い。
スペースシャトルの開発において、氷点下で仕様通りの性能を期待できないことを知っている人は大勢いた。しかしそれを言わなかった。それはそこら中の会社でも誰もリスクを口に出さない理由と同じである。以下のような不問律が企業文化ニコニコ漏れている。マイナス思考しない。解決策が見つからない問題を持ち出さない。問題だと証明できないことを問題だと言わない。水をささない。すぐに自分で解決を引き受けるつもり脳内問題を口に出すな。
破綻的結果についてのブレインストーミングをやってみる。
どうしてもいるものだという選定理由。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
なぜリスクを管理するのか。なぜリスクを管理しないのか。リスク管理の方法。数量化の方法。嘘かまことか。訳の問題なのか日本語の文章がわかりづらい。リスクのないプロジェクトには手をつけるな。コアリスク、スケジュールの欠陥、要求の増大、人員の離脱、仕様の崩壊、生産性の低迷。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが効果を上回ることがあきらかだからだ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
タイトルのセンスが抜群。ほれぼれ。
リスクがないプロジェクトには価値がない。
熊とワルツを踊らなきゃ。
で、私が結構勘違いしていたのが、これはシステム開発者の方向けの本だったのですね。
かといって全然身の回りに使えないわけではなく、むしろプロジェクト管理においての基本的なことを学べてなるほどなーと思いました。
自分の仕事に関連したプロジェクトのひとつに大規模なシステムの開発があって、私は直接関わったことはないもののとにかく様々なトラブルトラブルでスケジュールが遅れ、コンサルが入ってベンダーを叱りまくってお尻を叩いて叩いて幹部級まで呼びつけてとかまぁとにかくいろいろありました。
でも、こんなにトラブルって通常よくあることなんですか?という問いに対してコンサルさんは程度の差はあれどあります、驚くべきことではありませんと答えていたのも印象的で。そんなもんなんですね。
この本にも出てきた「ナノパーセント 日」、つまり何にも問題なくプロジェクト達成できる最楽観スケジュールでみんな考えがちなんだろうね。考えがちというか、政治的事情やらなにやらでお尻が決まってしまってデスマーチ不可避になるとかね。
「不確定性の幅は、その組織の開発プロセスにどれだけノイズがあるかで決まる(p67)」というのがこの本のキーとなる文章。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
正直、ふーん、というか、ああ、この人のいつものか。という感じ。リスク管理の観点としてはもちろん大事なことが書かれていたとは思うけど、それを学ぶにはこの人の本でなくていいかな。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
ソフトウェア開発におけるリスク管理について書かれた本。といってもソフトウェア開発に限らずいろいろなプロジェクトに適用できると思う。 リスクが発生しないように管理し、リスクが発生したときのためにどのように準備をしておき対処をするか、というのは実際にやってみると非常に難しいのだが、3部の「リスク管理の方法」が考え方や手法として参考となる。 何度か読んで実践することが大事だと痛感している。 本書を託していったTさんに幸あれ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
ソフトウエアのリスク管理について書いてある。TOCのゴールドラットとかぶっているところもあり、信頼できる。マネージャーならどうせリスクを背負わなきゃならないんだから、それを楽しみましょ。
投稿元:![ブクログ](//image.honto.jp/library/img/pc/logo_booklog.png)
レビューを見る
リスク管理について書かれた本。
私ぎ勉強になったと感じたのは、リスクの管理手順がより具体的に書かれているところである。
中では、リスクの扱い方法として、回避、抑制、軽減、かわすの4要素があると記載されており、
回避、リスクを伴う部分をやらないこと
抑制、リスクが発生した時のために時間と資金を準備しておくこと
軽減、リスクが発生する前に抑制コストを軽減する措置をとること
受容、なにもしないこと
とある。
実際のプロジェクトだとどう扱うか、などと対比してみると、原則が理解できると思う。