「熊とワルツを」を読んだ
- 作者: トムデマルコ,ティモシーリスター
- 出版社/メーカー: 日経BP社
- 発売日: 2013/09/12
- メディア: Kindle版
- この商品を含むブログ (5件) を見る
リスク管理の古典です。ダンスの本ではありません。
なぜ読んだか
管理側より技術寄りのキャリアを進みたい私が、プロジェクト管理色が強いこの本を読んだ理由を書きたいと思います。
伊藤淳一さんのブログで紹介されていたから
伊藤さんのブログをよく参考にしていますが、もし中学時代の自分に本を薦めるならと題されたエントリーで一般書籍に混じって唯一の技術書として紹介されていたため、前から気になっていました。
別のテスト本でリスク管理について書かれた内容が理解できず、引っかかっていた
- 作者: 高橋寿一
- 出版社/メーカー: 翔泳社
- 発売日: 2014/01/08
- メディア: Kindle版
- この商品を含むブログを見る
メンバーの体調不良や自然災害によるスケジュールの遅延をリスクとして書き出したことを「それはリスクではない」と怒ったエピソードが記されていますが、なぜ体調不良と地震はリスクの一部でないのか腑に落ちませんでした。
そのためリスク管理というものに対して引っ掛かりを感じていました。
Amazonのサイバーマンデーセールで半額だったから
これが1番の理由雨だったりします。
上記のような様々な理由により本書を読むことにしました。
概要
本書の概要については訳者解説のこの1文が的確に表していると思います。
本書は、リスク管理の一部を面白おかしく取り上げた本と考えてはならない。本書で解説している内容は、リスク管理の王道であり、正統派である。リスク管理の基本的な考え方、アプローチ、網羅している技法、用語など、リスク管理のガチガチの専門書と比べて何の遜色もない。これ一冊を読めば、リスク管理のすべてを把握できるといってよい。これで、リスク管理の基本は学習できたと自信をもっていただきたい。
訳者解説より
リスク管理の王道を行く1冊ということですね。
リスク管理とは
私が本書から読み取ったリスク管理を以下にまとめます
それぞれリスク= 望まない結果の原因となるもの*1 について以下のアクションを行う
- リスク発見:ブレーンストーミング&選別
- エクスポージャー分析:実現する確率と影響を数値化、移行*2指標の定義
- 危機対応計画:リスクが実現したときの対応シナリオを計画する
- 軽減:危機対応措置の実施、移行前に取るべき対策の選定
- 継続的な移行監視
なお、管理するリスクからコアリスクが漏れていないことを確認する。 コアリスクとはソフトウェア開発の歴史上、トラブルの頻度が高いものを 経験的に網羅したもの。
- 内在的なスケジュールの欠陥
- 要求の増大
- 人員の離脱
- 仕様の崩壊
- 生産性の低迷
新しく知ったこと
ナノパーセント日
ベストエフォートでの納品日のこと、納品可能になる可能性を累積でグラフに表すと、初めて0%出なくなる日が来るはずです。この日をナノパーセント日と呼びます。
この日付を基準に、各リスクが移行する確率や移行時の遅れなどを期待値にして計算し、納品できる可能性を累積で表したグラフを書くことができます。
ここまでリスクが整理できていると、リスクのシミュレーションを元に現実的な納品可能日が確率的に可視化できます。
詳しくは書きませんが、ちゃんとしたプロジェクト管理はここまでしっかり見積もるのか、と少し感心しました。
価値も可視化する必要がある
なぜリスクを受け入れるか、というとその先にある価値を手に入れるためです。「これから作るシステムがどの程度重要か」という点はリスクと同じ解像度で可視化しておく必要があります。でないと、リスクを犯す理由を説明できなくなるからです。
価値はリスクを相殺する
潜在価値が高ければ重大なリスクでもとる価値がある。潜在価値が低いのなら、たいていのリスクはとるべきではない。
21章より
価値が低いとデスマーチになりがち
どうしても納期に間に合わせないといけないからデスマーチになる、ではなくて、大して価値のないものを作っているから人が追加してもらえない、 という視点でデスマーチを見ています。
全体を通しての感想
- 前半は面白かったので1日で50%ほど読むことができたが、後半で読むペースが落ちた。私の経験不足のせいだと思う。
- どうやら、臭いものに蓋をするのは日本特有ということではなく、アメリカでもそうらしい。
- 現場では対処できないリスクはリストから外すような空気・圧力がかかる。封印されたリスクは移行時に再び向き合うことになる。そうならないためにリスク管理が必要。
疑問・わからなかったこと
- 私の経験不足が原因で「そんなのアリ?」と思う箇所が何点もありました。
- どうしても間に合わない場合は段階的に納品する、という方法が紹介されていましたが、一般的にこういうことが許されるのかどうかわからない。
- 自分が作っているものの価値
- 日頃から全く意識していませんでした。
- 派遣とか委託で中抜きが何度も入ると、結局いくらでシステムを作っているのかわからない。
アジャイル開発
本書はウォーターフォール的なマネジメントを前提に書かれていますが、
工期が1年のシステムだと、1年前に欲しかったシステムしか作れない、だから仕様変更のための余裕は必ず必要と書かれています。
仕様変更は起きるのが当たり前、という態度が見れます。 備える、備えないの前に、それを吸収できないプロセス自体どうなんだ?と思いました。
アジャイル/XPのノウハウが成熟してきた今日にもし本書が書かれるならどういう記述になるのか気になるところです。
ちなみに本書がアジャイルの入門として進めていた本がこちらです
- 作者: ケントベック,シンシアアンドレス,Kent Beck,Cynthia Andres,角征典
- 出版社/メーカー: オーム社
- 発売日: 2015/06/26
- メディア: 単行本
- この商品を含むブログ (6件) を見る
逸話(雑学)
気送管
著者のデマルコがフランスの中央市場の経理システムをシステム化したエピソードが掲載されていました。システム化する前は領収書を気送管と言われる管の中を風で飛ばして経理情報の集約をしていたそうです。
にわかには信じがたいのですが、昔はこんなものを使っていたのですね。
デンバー国際空港の自動手荷物処理システム
あとがきによるとソフトウェア工学の論文で非常によく取り上げられるマネージメントの失敗例だそうです。
教養として知っておくといいことがあるかもしれません。。。
https://ja.wikipedia.org/wiki/デンバー国際空港
おまけ:なぜ「体調不良」と「震災」はリスクではないのか
体調不良
本書の中に答えはありませんでしたが、ググったら以下のようにありました。
メンバーの病欠は常に発生するリスクであり、PMはそれを想定して、従来からある程度の予想を立ててスケジュールに余裕を持たせているのであれば、あえてリスクとして管理する必要はありません。
「新版プロジェクトマネジメント標準 PMBOK入門」より
- 作者: 広兼修
- 出版社/メーカー: オーム社
- 発売日: 2010/01/26
- メディア: 単行本(ソフトカバー)
- 購入: 6人 クリック: 23回
- この商品を含むブログ (10件) を見る
本書の内容に即して考えれば、コアリスクの
- 人員の離脱
- 生産性の低迷
あたりで管理するから、個別のリスクとしてあげなくて良い、ということでしょうか。
震災*3
7章で解説されています
万一発生した場合、プロジェクトどころではなくなるから。