nDiki : 熊とワルツを

トム・デマルコ / ティモシー・リスター 熊とワルツを

来週の移動中の読み物として買っておく。

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

第2章 リスク管理はおとなのプロジェクト管理だ

チーム・リーダー 「この件については明日会議を開きますが、事態は悪化しそうです」

プロジェクト・マネージャー 「では会議をやめよう」

(熊とワルツを p.15)

新幹線の中で読む。

いつもながらトム・デマルコの著書は明快。 普段プロジェクトではっきりとしないけれど何となく心にひっかかっているものが、しっかりと書かれている。 素晴しい。

[ プロジェクトマネージャー ]

開発スタッフ怪我をして入院

家に返ってたまったメールをチェック。 開発スタッフが顔に数針縫う怪我で入院との連絡。 スケジュールの調整願いが入っていた。

怪我大丈夫かなぁ。縫うぐらいだから結構大変なのかも。心配。 はやく回復して欲しい。

不謹慎かもしれないが、同時にまさに今読んでいる「熊とワルツを」の内容が頭に浮かぶ。 最近たてた短期間プロジェクトに配置した開発に重要なスタッフなので、まさにリスク移行が発生。 今後はきちんとリスク管理を考えていかねば。

熊とワルツを読了

歯医者の待合い室で読了。

「ゆとりの法則」でもリスク図がでてくるのだが、ここではなぜその曲線になるのかという点には触れられていなかった。

「熊とワルツを」ではきちんとそれについても説明されている。 過去のリスクに関するデータにもとづくモンテカルロ法。 なるほど。 そういえばモンテカルロ法なんてあったけなぁ。 自分では適用した事がなかったから存在自体忘れていた。

ということで本に登場するリスク図は主にこの業界のデータから導かれた確率分布だと。 そういうことか。 まぁあくまでざっくりとしたラインではあるが、無いよりは何倍も良い。

しかし実際に自分のプロジェクトで使ってみようとすると、なかなか手強そうだ。 手順まで丁寧に説明されているので、やれそうなものなのだがやはり不確定なものというのはとらえがたい。

まずは少しずつ、自分のかかわっているプロジェクトのリスク・リスト作りからはじめるべきか。 しかし例によって時間が。

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

---

[ 読書ノート ] [ お薦めの本 ]

ナノパーセント日

ミーティングで、あるプロジェクトのスケジュール遅れが議題になった(参加していないプロジェクト)。

リクエスト側と開発側で、仕様の誤解による手戻りが大きな原因のようである。

• リクエスト側と開発側が物理的に離れていたため、顔を合わせたキックオフミーティングを行わなかった。
• その後のコミュニケーションも不足であった。

あたりが問題か。 物理的な距離の壁はデカイ。

それから、β版リリース日がナノパーセント日(あるいはそれよりも前)であった可能性も高いように思えるが、その点はどうか。

(Naney 注:リスク図の)曲線の左側が水平になる地点が、「確率がゼロではない最初の日」である。しかし、限りなくゼロに近い。この日までに完成する確率は1ナノパーセント程度なので、この地点をN(ナノパーセント日)と呼ぶ。-- 熊とワルツを, p.65

自分も「これどれぐらいでできる?」と言われると、つい奇跡的最短期間を口にしがちである。 気をつけねば (もっとも、見積もりとは関係なく期日がセットされていて内容で調整ということも多いが)。

---

[ ソフトウェアプロジェクトマネジメント ]