読者です 読者をやめる 読者になる 読者になる

quattro_4's diary

また同じ過ちを繰り返すと気付かんのか!?

熊とワルツを - リスクを愉しむプロジェクト管理 感想

熊とワルツを - リスクを愉しむプロジェクト管理

熊とワルツを - リスクを愉しむプロジェクト管理

ピープルウエアの後に読んだ ( ピープルウエア 感想 - quattro_4's diary )
ピープルウエアに比べると、少し退屈な部分がある
プロジェクト管理表とか書くのが専門の人などには良いかもしれない

要約すると、みんな「できない」ことを見ないふりをして「できる」と言うことしか許されず、プロジェクトは失敗する
リスク管理と銘打てば、「できない」が許容される
リスク管理は機械的にできる


心に残る部分けっこうあった

第1部

  • 第3章 デンバー国際空港再考
    • 準備は完璧だと主張して、ほかの誰かが最初にボロを出すことを期待する瀬戸際作戦
    • それまでは、あのソフトは強気なスケジュールにしたがって進められ、成功するように管理されていた
    • 4年かかるプロジェクトを2年でやろうとしているのであり、そんなプロジェクトがふつう期限までに完成するはずがないと気づいていた。だが、こうした徴候はすべて無視された。
  • 第4章 リスクを管理すべき理由
    • この業界には、「やればできる」思考が蔓延している。そのせいで、「できない」ことを示すような分析は叩かれる。
    • リスク管理をすれば、多少の「できない」思考は許容される。リスク管理のしくみを導入すれば、...
    • 失敗から失敗へと渡り歩く仕事には気持ちが入らない。士気の低下、燃え尽き、離職率の上昇といったコストは大きい。
    • 自分たちのプロジェクトに問題がふりかかったとき、ほんとうに誰もこの事態を予見できなかったと言いきれる人はいるだろうか。ほとんどいないはずだ。問題が勃発する前には、かならずといっていいほど何らかの予兆がある。われわれは、そのような予兆にあえて気づかないように自分を訓練してしまっている。リスク管理とは、この訓練を解除するものである。

第2部

  • 第7章 運
    • みずから強気なスケジュールだと言いきるようなプロジェクトは最悪だ
    • 幸運をつかみきれなかったときに衝撃を受け、失望し、落胆したふりさえすれば、運にたよる計画にしたがったこと自体は問題なしとされる。

第3部

  • 第8章 不確定性を数量化する
    • N(ナノパーセント日)- 「確率がゼロではない最初の日」。限りなくゼロに近い。
    • 過去に予測を立てた経験からNを予想する方法を知っているが、次に誤ってNを納期としてあつかってしまう。
  • 第9章 リスク管理のしくみ
    • 組織が過去数年のプロジェクトで遭遇した問題を上位20件ほどリストにすると、次のプロジェクトで使うリスク・リストのたたき台としてちょうどよい。リスク管理の仕事は、こうしてまったく機械的に始めることができる
    • リスクについてできることは、次の四つである。避ける、抑制する、軽減する、かわす
      • リスクをかわそうと計画する場合、天に祈るのが通例である
      • 最初の三つにはコストがかかる。
      • リスク管理は、プロジェクトについて心配することとは違う
      • 全部で12項目の短いリスク・リストしかなかったとしても、12個すべてかわせる確率はきわめて低いはずだ。リスク1個あたりの実現確率が10パーセントにすぎないとしても、12個のうちひとつ以上が襲いかかってくる確率は、ほぼ75パーセント
    • リスクエクスポージャー
      • リスク・エクスポージャーとは、抑制コストの「期待値」である。リスク・エクスポージャー =コスト×確率
        • リスクの発生する確率が20パーセントで、発生した場合に100万ドルのコストがかかるとしたら、リスク・エクスポージャーは20万ドルである
    • ショーストッパー
      • 発生すると何もかも犠牲になるため、容易にコストを決められないリスクに出くわすことがある。
  • 第10章 リスク管理の手順
    • プロジェクトの納期と目標を別々に設定するというのは、いままでとはまったく違った発想だ。ほとんどの企業には、ずっと次のようなルールがあった。 スケジュール=目標=N ←あきれた式
    • スケジュール>∨目標>∨N ←この方がい
    • この業界は、早く終わるという第三の結果を事実上不当なものとみなすことで、期日どおりに完成する確率をほぼゼロにしているのだ
  • 第13章 ソフトウエア・プロジェクトのコア・リスク
    • 1月にプロジェクトを開始し、10カ月後にXを納品することになっていたとしたら、その10カ月が終わる頃には、もうXはビジネス・パートナーがほんとうに求めるものではなくなっている。ほんとうに求めているのはX+である
    • 人びとは合意することになっている。協力することになっている。根深い対立があってそれができなくても、表向きは取り繕われることが多い。プロジェクトは誤ったあいまいな目標を掲げたまま進む。誰もその目標に満足していないが、しばらくの間は我慢できる
  • 第14章 リスク発見プロセス
    • 不文律
      • 1.マイナス思考をするな。
      • 2.解決策が見つからない問題を持ち出すな。
      • 3.問題だと証明できないことを問題だと言うな。
      • 4.水をさすな。
      • 5.すぐに自分で解決を引き受けるつもりのない問題を口に出すな

第4部

  • 第18章 価値の数量化
    • コスト効果分析の「効果」の方があいまいになるとともに、「コスト」の方に厳密さが要求されるようになった
    • コストと効果は同じ精度であらわす必要がある
    • 概して、効果がまったく数量化されない場合には、効果がないものと考えた方がいい


このシリーズ読んで思うことは、プロジェクトの問題は世界共通
(日本のITは... と憂うのは違うのかなと思った)
自分が思うことも、他人がやっていることも、物語の登場人物のように誰でもそうなるということ。


くま - ザ・クロマニヨンズ


Speed 1/5
★★★★☆