雑ノート(仮)

適当なメモ。

「熊とワルツを」を読んだ

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

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

リスク管理の古典です。ダンスの本ではありません。

なぜ読んだか

管理側より技術寄りのキャリアを進みたい私が、プロジェクト管理色が強いこの本を読んだ理由を書きたいと思います。

伊藤淳一さんのブログで紹介されていたから

伊藤さんのブログをよく参考にしていますが、もし中学時代の自分に本を薦めるならと題されたエントリーで一般書籍に混じって唯一の技術書として紹介されていたため、前から気になっていました。

別のテスト本でリスク管理について書かれた内容が理解できず、引っかかっていた

メンバーの体調不良や自然災害によるスケジュールの遅延をリスクとして書き出したことを「それはリスクではない」と怒ったエピソードが記されていますが、なぜ体調不良と地震はリスクの一部でないのか腑に落ちませんでした。

そのためリスク管理というものに対して引っ掛かりを感じていました。

Amazonサイバーマンデーセールで半額だったから

これが1番の理由雨だったりします。

上記のような様々な理由により本書を読むことにしました。

概要

本書の概要については訳者解説のこの1文が的確に表していると思います。

本書は、リスク管理の一部を面白おかしく取り上げた本と考えてはならない。本書で解説している内容は、リスク管理の王道であり、正統派である。リスク管理の基本的な考え方、アプローチ、網羅している技法、用語など、リスク管理のガチガチの専門書と比べて何の遜色もない。これ一冊を読めば、リスク管理のすべてを把握できるといってよい。これで、リスク管理の基本は学習できたと自信をもっていただきたい。

訳者解説より

リスク管理の王道を行く1冊ということですね。

リスク管理とは

私が本書から読み取ったリスク管理を以下にまとめます

それぞれリスク= 望まない結果の原因となるもの*1 について以下のアクションを行う

  • リスク発見:ブレーンストーミング&選別
  • エクスポージャー分析:実現する確率と影響を数値化、移行*2指標の定義
  • 危機対応計画:リスクが実現したときの対応シナリオを計画する
  • 軽減:危機対応措置の実施、移行前に取るべき対策の選定
  • 継続的な移行監視

なお、管理するリスクからコアリスクが漏れていないことを確認する。 コアリスクとはソフトウェア開発の歴史上、トラブルの頻度が高いものを 経験的に網羅したもの。

  • 内在的なスケジュールの欠陥
  • 要求の増大
  • 人員の離脱
  • 仕様の崩壊
  • 生産性の低迷

新しく知ったこと

ナノパーセント日

ベストエフォートでの納品日のこと、納品可能になる可能性を累積でグラフに表すと、初めて0%出なくなる日が来るはずです。この日をナノパーセント日と呼びます。

この日付を基準に、各リスクが移行する確率や移行時の遅れなどを期待値にして計算し、納品できる可能性を累積で表したグラフを書くことができます。

ここまでリスクが整理できていると、リスクのシミュレーションを元に現実的な納品可能日が確率的に可視化できます。

詳しくは書きませんが、ちゃんとしたプロジェクト管理はここまでしっかり見積もるのか、と少し感心しました。

価値も可視化する必要がある

なぜリスクを受け入れるか、というとその先にある価値を手に入れるためです。「これから作るシステムがどの程度重要か」という点はリスクと同じ解像度で可視化しておく必要があります。でないと、リスクを犯す理由を説明できなくなるからです。

価値はリスクを相殺する

潜在価値が高ければ重大なリスクでもとる価値がある。潜在価値が低いのなら、たいていのリスクはとるべきではない。

21章より

価値が低いとデスマーチになりがち

どうしても納期に間に合わせないといけないからデスマーチになる、ではなくて、大して価値のないものを作っているから人が追加してもらえない、 という視点でデスマーチを見ています。

全体を通しての感想

  • 前半は面白かったので1日で50%ほど読むことができたが、後半で読むペースが落ちた。私の経験不足のせいだと思う。
  • どうやら、臭いものに蓋をするのは日本特有ということではなく、アメリカでもそうらしい。
  • 現場では対処できないリスクはリストから外すような空気・圧力がかかる。封印されたリスクは移行時に再び向き合うことになる。そうならないためにリスク管理が必要。

疑問・わからなかったこと

  • 私の経験不足が原因で「そんなのアリ?」と思う箇所が何点もありました。
    • どうしても間に合わない場合は段階的に納品する、という方法が紹介されていましたが、一般的にこういうことが許されるのかどうかわからない。
  • 自分が作っているものの価値
    • 日頃から全く意識していませんでした。
    • 派遣とか委託で中抜きが何度も入ると、結局いくらでシステムを作っているのかわからない。

アジャイル開発

本書はウォーターフォール的なマネジメントを前提に書かれていますが、

工期が1年のシステムだと、1年前に欲しかったシステムしか作れない、だから仕様変更のための余裕は必ず必要と書かれています。

仕様変更は起きるのが当たり前、という態度が見れます。 備える、備えないの前に、それを吸収できないプロセス自体どうなんだ?と思いました。

アジャイル/XPのノウハウが成熟してきた今日にもし本書が書かれるならどういう記述になるのか気になるところです。

ちなみに本書がアジャイルの入門として進めていた本がこちらです

エクストリームプログラミング

エクストリームプログラミング

逸話(雑学)

気送管

気送管 - Wikipedia

著者のデマルコがフランスの中央市場の経理システムをシステム化したエピソードが掲載されていました。システム化する前は領収書を気送管と言われる管の中を風で飛ばして経理情報の集約をしていたそうです。

にわかには信じがたいのですが、昔はこんなものを使っていたのですね。

デンバー国際空港の自動手荷物処理システム

あとがきによるとソフトウェア工学の論文で非常によく取り上げられるマネージメントの失敗例だそうです。

agnozingdays.hatenablog.com

教養として知っておくといいことがあるかもしれません。。。

https://ja.wikipedia.org/wiki/デンバー国際空港

おまけ:なぜ「体調不良」と「震災」はリスクではないのか

体調不良

本書の中に答えはありませんでしたが、ググったら以下のようにありました。

メンバーの病欠は常に発生するリスクであり、PMはそれを想定して、従来からある程度の予想を立ててスケジュールに余裕を持たせているのであれば、あえてリスクとして管理する必要はありません。

「新版プロジェクトマネジメント標準 PMBOK入門」より

新版 プロジェクトマネジメント標準 PMBOK入門

新版 プロジェクトマネジメント標準 PMBOK入門

本書の内容に即して考えれば、コアリスクの

  • 人員の離脱
  • 生産性の低迷

あたりで管理するから、個別のリスクとしてあげなくて良い、ということでしょうか。

震災*3

7章で解説されています

万一発生した場合、プロジェクトどころではなくなるから。

*1:望まない結果そのものではない。例えばスケジュールの遅れはリスクが引き起こした結果そのものでありリスクではない

*2:リスクが実現すること

*3:7章には隕石の例で書かれていますが、一応天災つながりで