nDiki : 熊とワルツを

リスク トム・デマルコ リスク管理 開発 キックオフミーティング ソフトウェアプロジェクトマネジメント 見積もり 書評 会議 プロジェクトマネジメント ゆとりの法則 お薦めの本 仕様 歯医者 コミュニケーション メール ミーティング 新幹線

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

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

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

• 第2章 リスク管理はおとなのプロジェクト管理だ (2004-10-25)
• 現代の経営(上)読了 (2005-01-31)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• ナノパーセント日 (2005-10-26)
• 開発スタッフ怪我をして入院 (2004-10-26)

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

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

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

(熊とワルツを p.15)

新幹線の中で読む。

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

• トム・デマルコ / ティモシー・リスター 熊とワルツを (2004-10-22)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• 私的10大ニュース2004 [ work ] (2004-12-31)
• 「プロジェクトマネジメント」はどうやって勉強すれば良いですか? (2006-11-22)
• 開発スタッフ怪我をして入院 (2004-10-26)

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

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

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

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

• ナノパーセント日 (2005-10-26)
• 今日のさえずり - 京都の小学校のコンピュータ室にいったら、Squeak が (2008-03-06)
• 今日のさえずり - これ Emacs なのよね (2010-01-26)
• 今日のさえずり - ささやかな気持ちDES (2008-11-07)
• 今日のさえずり - 壊れた金具の代わりに南京錠 (2009-04-14)

■ 熊とワルツを読了

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

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

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

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

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

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

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

[ 書評 ] [ お薦めの本 ]

• ピープルウェア読了 (2004-05-25)
• トム・デマルコ ゆとりの法則 - 誰も書かなかったプロジェクト管理の誤解 (2004-04-17)
• このやり方でやると「すごいこと」が起きる。 (2005-06-08)
• 「コンサルタントの秘密」 (2007-06-03)
• 問題とは「あるべき姿」と「現状」の「ギャップ」である (2006-10-13)

■ ナノパーセント日

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

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

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

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

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

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

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

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

• Joel on Software - 必読書 (2008-08-14)
• スクラッチから書き直したくなるプログラマは、書き直したプログラムもまたスク... (2008-06-14)
• 本社にいた「すごい会議」読者とミーティング (2005-12-20)
• 準備委員会キックオフミーティング (2005-11-19)
• ソフトウエア開発 55の真実と10のウソ読了 (2004-06-08)