【感想・ネタバレ】熊とワルツを リスクを愉しむプロジェクト管理のレビュー

トムデマルコ / ティモシーリスター / 伊豆原弓

[ブクログ · ★★★★★]

リスク見積もるのは難しいよなぁ。Risk Mitigation CostとRisk Exposure Costをどう適切に見積もるか。高過ぎてもダメだし、低すぎてもあれだし。プロジェクトマネジメントにおけるリスクの考え方の基本。

[ブクログ · ★★★★★]

そもそもシステム開発プロジェクトにおけるリスク管理とは何なのか、から具体的なハウツーまでコンパクトにまとめられており、非常に有益に感じた。
特にリスクを分析していく過程で「誰が負うべきリスクなのか？」は重要な観点に思えた。なぜなら「誰が」の選択肢が観点として無いまま分析を進めると、結果自身が負えるリスクしか直視しない（手に負えないリスクは無視する）という行動を度々目にするから。
しかし、理屈をわかっていてもうまく実践されないのがリスク管理の常だが、これも随所に引用されるウィリアム・キングドン・クリフォードの「信念の倫理」を使ってうまく解説してくれる。
曰く、信念こそが人がリスクから目を背ける理由となりえるものであり、確たる証拠もないのにリスクをないものと取り扱うのは罪である、というようなことが書かれている。
邪かどうか、信念の性質に関わらず、信念そのものが現実から目を遠ざけリスク軽視という罪を生み得る。うーん、深い。

[ブクログ · ★★★★★]

熊とワルツを踊る = リスクの評価、抑制、軽減を行うこと。
インクリメンタル開発の下りを読んで、今時だとアジャイル開発でやってそうだなーと思ったら関連文献に XPエクストリーム・プログラミングが載ってた

[ブクログ · ★★★★★]

何故、欧米人が新しいことや難しいことに取り組むことを「チャレンジング」と言うのかが分かる。すなわち、こういったことはすべて、リスクを取ることになるからだ。リスクとその成果を如何に数値化するか、を求めている。

[ブクログ · ★★★★★]

置き土産に @you_got 殿からいただいた（んだよね？）本。リスク管理について正面から理論的に述べています。著者が言うナノパーセント日がふつう期限になっちゃうんだけど、リスク図を見せながら「その日にできる確率はナノパーセントです。その2か月後までにできる確率なら70％です」なーんて言っても「ガタガタ言わずに期限までに上げろや」ってなるんだよなー。で直前になって、遅らせることができる機能を1.5次開発に回すってことになる。アジャイルとは言ってないけど、インクリメンタルな開発で機能を分けて段階的に納品するといいよってことをこの本でも言っていた。あと、「完成が遅れるプロジェクトのほとんどは、あまりにも工期が短いためだ」というのは印象的。開発の稟議を通すのに、あーでもないこーでもないってやってるからなんだよなー。えらい人自らがプロジェクトを失敗へと導いている。

[ブクログ · ★★★★★]

リスク対策を洗い出して検討しておく。たったそれだけのことが出来ないプロジェクトがどれほど多いことか。リスク管理に敏感になり始めた人に必読の本。

[ブクログ · ★★★★☆]

語り口は軽く、とても読みやすい。プロジェクトマネジメントにおける、今でも「あるある」とうなづけるような例と陥りがちな罠が語られており、今も昔も変わらない（むしろ悪化している）現状に若干絶望したりもする。
入門本とも言えるし、内容もかなり王道的。
切り口は「リスクマネジメント」であり、プロジェクトマネジメントについて学習してもなお敢えて目を逸らしがちな部分について芯を食った説明をしている。
良本でした。

[ブクログ · ★★★★☆]

プロジェクトがどうしてうまく進めることができないのか。
それはその前の分析をしていないからである。
その分析はどのような観点で発掘していくべきなのか。

リスク管理という観点で、プロジェクトを検分していく書籍。
5部、23章に渡ってリスク管理とその分析について焦点をあてて論が展開されます。

書籍の中で、著者が経験したまたは周りで発生した事例を上げながらどうすれば良かったのかについて討論やデータを持ってプロジェクトを検分していきます。

その中で印象に残ったのは以下です。

- 「不確定性」を数量化する。
経験則に頼らず、可能性を言語化して提示していくこと

- 価値性のあるコンポーネントを分析して提供していく。
プロジェクトで優先すべき価値ある機能を提供して継続するかの天秤にかけること

- 「リスク管理」は「おとなのプロジェクト管理」だ
不愉快な現実と、起こりうる悪い事態を認識して備えておくこと

リスク管理を背負ってプロジェクトを遂行することがあります。
その時に、熊と踊るために準備をしないといけないと気が引き締まる思いでした。

[ブクログ · ★★★★☆]

リスク管理について書かれた本。
私ぎ勉強になったと感じたのは、リスクの管理手順がより具体的に書かれているところである。
中では、リスクの扱い方法として、回避、抑制、軽減、かわすの4要素があると記載されており、
回避、リスクを伴う部分をやらないこと
抑制、リスクが発生した時のために時間と資金を準備しておくこと
軽減、リスクが発生する前に抑制コストを軽減する措置をとること
受容、なにもしないこと
とある。
実際のプロジェクトだとどう扱うか、などと対比してみると、原則が理解できると思う。

[ブクログ · ★★★★☆]

ソフトウエアのリスク管理について書いてある。TOCのゴールドラットとかぶっているところもあり、信頼できる。マネージャーならどうせリスクを背負わなきゃならないんだから、それを楽しみましょ。

[ブクログ · ★★★★☆]

ソフトウェア開発におけるリスク管理について書かれた本。といってもソフトウェア開発に限らずいろいろなプロジェクトに適用できると思う。 リスクが発生しないように管理し、リスクが発生したときのためにどのように準備をしておき対処をするか、というのは実際にやってみると非常に難しいのだが、3部の「リスク管理の方法」が考え方や手法として参考となる。 何度か読んで実践することが大事だと痛感している。 本書を託していったTさんに幸あれ。

[ブクログ · ★★★★☆]

☆4
本編よりも、付録A「信念の倫理」に強く共感したよ！私が科学好きなのも、知ることが楽しいのも、全てここに繋がってた。
世代を重ねて蓄積された人類の財産にアクセスしながら、これからも責任をもって、注意深く私の信念を言葉にしていきたいと思ったよ。
リスク管理は、もっと大きな仕事を扱うようになったら徐々にこの本から取り入れていけばいいかな、と思った。
読み物としても、飽きずに面白く読めたよ。

[ブクログ · ★★★★☆]

前半は抽象的で啓蒙的な内容。ソフトウェア開発に限らず様々なプロジェクト管理に適用できる「考え方」が記述されている。
後半は実践的な内容となり、リスク管理が業務に組み込まれている環境でなければ取っ付きにくい。

[ブクログ · ★★★★☆]

[読んだ理由]==================
「100人のプロが選んだソフトウェア開発の名著」にあった。PM、特にリスク管理って全然わからないので一度読んでみたいと思った。


[読んだ後の感想]==============
主なポイントは下記かなぁ、と思った。
・プロジェクト着手前に、想定しうる最悪のリスクまで徹底的に出しきっておく。
・「やらなければならない」作業だけでなく「やらなければならないかもしれない」作業も予想しておくべき。
・「コスト」と同様に「効果」も数量化すべき。でないとプロジェクトの「効果」が測れない。
・プロジェクトの最短だけでなく最遅の完成期日も予測し、その両方の結果から現実的な期日を予想する。
・リスクの大きな作業は極力先に済ませる事で、プロジェクトの柔軟性を極力確保する。


[読書録]======================


■第一部：なぜリスクを管理するのか
リスクのないプロジェクトには手を付けるな。全くリスクのないプロジェクトに手を出すのは負け組だ。必ずといっていいほど、何もえるものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。


■第二部：なぜリスクを管理しないのか
リスク管理をすべきでない理由の一つ：はっきり不確定幅を決めると、出来の悪い仕事を許すことになる。
⇒SWマネージャは「予測と目標は同じである」という標準ルールに従う傾向がある。しかしリスク管理のルールによれば、マネージャはいつも部下が最高の仕事を目指して努力するように目標を設定すべきである。その一方、クライアントや上層部に約束をする時には、目標とは全く別の予想を使うべきである。

「間違えるのは構わないが、不確かなのは駄目だ」と言うルールが自分の会社に当てはまったら、おしまい。このルールの意味は、約束した納期に間に合わなくても良い、大幅に遅れても構わないが、その日までの間、期日に間に合いそうもないといってはならないということだ。

「近づく電車が見えない症候群」「選択的近視」：
⇒これを避けるには、リスク管理をはじめる時点で、思いつく限りの破滅的な結果を並べて見ること。
つまらない心配事より、悪夢を攻撃せよ。

SWプロジェクトでは概して、且つために特別なことをするより、負けの程度を抑えるほうが大事なのだ。この仕事では、どんな組織も負けることがある。他の時に勝ったことがあろうがあるまいが、負けた時に最も痛手を受けたものが本当の負である。


■第三部：リスク管理の方法
SWプロジェクトマネージャの殆どは、「やらなければならない」作業についてはほぼ正確に予想できるが、「やらなければならないかもしれない」作業は正しく予想できない。

この業界は、予定より早く終わるという第三の結果を事実上不当なものとみなすことで、期日通りに完成する可能性をほぼゼロにしているのだ。いい加減なスケジュールを許さないがために、むしろいい加減なスケジュールが例外ではなく当然になっている。

全体リスクの不確定性は、成否を決める各々の原因の不確定性を積み重ねた結果である。

Ｎ（ナノパーセント日：その日に完成する可能性がゼロではない最初の日）：
人は楽観的な声質を持っており、過去の経験から、可能な範囲で最も楽観的なスケジュールであるNを見積もることにはかなり熟達している。しかし、Nに完成すると約束するのではなく、本当に約束すべき納期を決定するためのデータとしてNを使うことが重要。

プロジェクトでも損は早めに出してしまうに限る。其の様なときは一旦主導権を失い、成り行きに任せることになる。しかし、早めにそうしておけば、強みを温存しておいて主導権を取り戻すことができる。システムのウチ技術的に軌跡に頼る部分は、初期のバージョンに組み込むべきである。そうすれば、奇跡が起きなかったとしても、いざというときの選択肢が最大限に多い。

インクリメンタル開発計画：
・制約の1つ：詳細設計図に、設計の分割を最低レベルまで全て示さなければならないこと。通常は、高レベルの設計を適当に済ませて設計が完了したと宣言し、後の設計分割作業はコーディングの副産物として行われているのが現状。
・メリット：区切りが多いため、プロジェクト要員の士気が保たれる。状況が目に見えやすい。プロジェクトの最後に残るのはほとんど余計なお飾りの機能だと分かり、その部分をカットできる可能性がある。


■第四部：数量化の方法
コストと効果は同じ精度で表す必要がある。「どうしても要るのだ」としか効果を言い表せないのなら、コストも「相当かかるだろう」とするべきである。

開発者と発注者の説明責任は平等であるべきだ。発注者には、価値が生み出されることを確認する責任がある。ところが、我々のアンケートによれば、企業はプロジェクトの完了後に、効果を実現できたかどうかを追跡調査していない。

製品が大きくなることでコストが比例以上に増大するとしたら、製品を小さくすればコストを比例以上に節約できるはずだ。システムの中で価値コスト比率の低い部分を削減することは、時間と予算に対する制約を緩める最も簡単な方法。ソフトウェア開発者は「もっと小さなソフトウェアを」をスローガンにしようと考えるべきだというと妙に聞こえるかもしれないが、そのほうが有利なことは明らかだ。

デスマーチの正当化にいつも使われるのは、プロジェクトの重要性である。「このプロジェクトは極めて重要なものだから、プロジェクト要員には精一杯頑張ってもらわねばならない」。だが、プロジェクトがそれほど重要なら、どうして会社はそれを適切に遂行出来るだけの時間と資金を使えないのか。

我々の経験では、デスマーチプロジェクトに共通する性質として、予想される価値が低いことがある。どうしようもなくつまらない製品を世に送り出すためのプロジェクトなのだ。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが成果を上回ることが明らかだからだ。


■第五部：嘘か真か

[ブクログ · ★★★★☆]

プロジェクトにおけるリスク管理の大切さを説いた本。著者本人の体験等ケーススタディがしっかりと書かれているので読み易かった。
目に見えない潜在的なリスクを想定して、(想定したリスクが起こる前、起こった後の)対策を考えておき、しっかりと全体の工程をウォッチしていくという事が大切なんだと思った。が、まだまだ今のプロジェクトへうまく適用させる方法が思いつかない･･･(;_;)
まだまだ消化できてないのだろうなぁ･･･
また、もう一度読んでしっかりと消化しておきたいと思った。

[ブクログ · ★★★★☆]

リスクを回避するのではなく、リスクを計測し管理する手法を提唱する良い本です。主な対象はプロジェクトの管理責任にある方、またはその上層部だと思います。

[ブクログ · ★★★★☆]

まず非常に楽しい。コミカルに書かれていて読みやすい。
しかし内容は怖い。ソフトウェア開発におけるリスク管理が形骸であることを幾つもの面や事象から指摘している。
ゆえにとても面白い。
しかしデマルコ／リスターの本は面白く、とても納得いくのだが、著者自身も作中で書いているようにこれを現場に導入するにはハードルが高い。
しかし現状の不足、目指すべき高みを意識できる良著。

[ブクログ · ★★★★☆]

定番図書のひとつ～
プログラム主体の立場からすると、やらなければいけない事項
というよりは、やって欲しい事項が記載されている。
内容としては7年前といささか古いので、その後の進展が
あるかもしれない、その点については他の人に譲る。

むしろ巻末に付随している、ウィリアム・キングドン・クリフォードの
「信念の倫理」の抜粋が、個人的にはこの本を読んでの最大の収穫だった。
（暴論だが、この論文の理念を具象化した一つが本書・・・？）

[ブクログ · ★★★★☆]

さすがデマルコという感じの読みやすく分かり易い本になっていると思います。
リスク管理の定義、なぜリスク管理をしないか(できないか)から始まり、リスク管理の方法へと続くが、小難しい数式等を用いず理解し易いです。
この本を読むと、どうして多くのプロジェクトで
「何か奇跡的な事が起きるかのような楽観的なスケジュールを立てるのか」
について理解できると思います。

[ブクログ · ★★★★☆]

リスクとはそもそも何か、というところから始まって、リスク管理がうまくいかない理由について述べられている。そしてリスク管理が行われない理由についても述べられている。（例：早く終わる可能性のあるスケジュールをひくことが許されないなど）この項が一番参考になった（苦笑）。
あと身にしみて感じるところがあったのが、問題の原因はより早い時期に発生しているが、問題を認識し始める時期（天罰期という　笑）についての説明とその対処法。バージョンごとにリリースするというのが意外と現実的な方法だと分かった。
この本が扱う範囲は入門から中級までかなり広いと思うがリスク管理をやる上で読んでおいてよい1冊だと思う。[2007/1/4]

[ブクログ · ★★★★☆]

ちょうど、あるプロジェクトでリスクマネジメントについて非常にナーバスになっていたときいに読みました。

プロジェクトマネジメントのなかでのリスクの考え方について随分参考になりました。
ナーバスになりすぎないで、早めはやめの対応が重要であることを説いており、実際の場面でも応用の聞く内容だったと思います。

[ブクログ · ★★★☆☆]

リスクに対する考え方が平易に説明されています。書かれたのがかなり昔で、いま活かせるかというと難しいと思いました。まずは計測すること。確率分布的にリスクを捉える点や上層部に対してどういう説明をすべきかまで言及されており、あらためて勉強になりました。

[ブクログ · ★★★☆☆]

タイトルのセンスが抜群。ほれぼれ。
リスクがないプロジェクトには価値がない。
熊とワルツを踊らなきゃ。

で、私が結構勘違いしていたのが、これはシステム開発者の方向けの本だったのですね。
かといって全然身の回りに使えないわけではなく、むしろプロジェクト管理においての基本的なことを学べてなるほどなーと思いました。
自分の仕事に関連したプロジェクトのひとつに大規模なシステムの開発があって、私は直接関わったことはないもののとにかく様々なトラブルトラブルでスケジュールが遅れ、コンサルが入ってベンダーを叱りまくってお尻を叩いて叩いて幹部級まで呼びつけてとかまぁとにかくいろいろありました。
でも、こんなにトラブルって通常よくあることなんですか？という問いに対してコンサルさんは程度の差はあれどあります、驚くべきことではありませんと答えていたのも印象的で。そんなもんなんですね。

この本にも出てきた「ナノパーセント 日」、つまり何にも問題なくプロジェクト達成できる最楽観スケジュールでみんな考えがちなんだろうね。考えがちというか、政治的事情やらなにやらでお尻が決まってしまってデスマーチ不可避になるとかね。

「不確定性の幅は、その組織の開発プロセスにどれだけノイズがあるかで決まる（p67）」というのがこの本のキーとなる文章。

[ブクログ · ★★★☆☆]

なぜリスクを管理するのか。なぜリスクを管理しないのか。リスク管理の方法。数量化の方法。嘘かまことか。訳の問題なのか日本語の文章がわかりづらい。リスクのないプロジェクトには手をつけるな。コアリスク、スケジュールの欠陥、要求の増大、人員の離脱、仕様の崩壊、生産性の低迷。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが効果を上回ることがあきらかだからだ。

[ブクログ · ★★★☆☆]

リスクをとらない（回避する）だけのプロジェクトに価値はない。

新しい領域に足を踏み入れる場合、必ず何かしらのリスクは存在するもので、生み出そうとする価値が大きければ大きい程、リスクが発生する可能性も高くなる。

リスクを取らないということは、新しい領域へのチャレンジがなくプロジェクトメンバーや会社の成長にもほとんど寄与しない。

リスク管理の正しい方法を知ることで、新しく、そして価値のあるプロジェクトへ安心して参画することが可能となる。

本書はそんなリスク管理のノウハウを具体的に示しています。

私自身は大規模なプロジェクトへの参画経験がまったくないため、実感をもって本書のノウハウを吸収することはできませんでしたが、いつの日か役に立つのではと思っています。

[ブクログ · ★★★☆☆]

リスクを積極的に取りましょう、リスクをコントロールしましょうと言う本。
リスク管理の方法などが書かれている。

当時、客先に飛ばされて１プログラマだったから活かし用が無かったけど、今見たら違うのかも？

[ブクログ · ★★★☆☆]

リスク管理に注目したデマルコの著作。「リスクが無いプロジェクトは、やる価値もない」とリスク回避をこき下ろした上で、納期に遅延(リスク)を見込まずに、バラ色の未来だけを描いてスケジュールを引く従来の慣習を「子供の遊び」と厳しく批判する。10年後には「ピープルウェア」と並ぶ古典になっているかもしれない。