トム・デマルコのレビュー一覧

デッドライン ソフト開発を成功に導く101の法則

トムデマルコ / 伊豆原弓

分野としては管理工学でしょうか。プロジェクト管理の教科書ですが、内容が小説仕立てなので、要点を抽象的なモデル事例として学べるので、初学者に最適だと思います。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

[読んだ理由]==================
「100人のプロが選んだソフトウェア開発の名著」にあった。PM、特にリスク管理って全然わからないので一度読んでみたいと思った。


[読んだ後の感想]==============
主なポイントは下記かなぁ、と思った。
・プロジェクト着手前に、想定しうる最悪のリスクまで徹底的に出しきっておく。
・「やらなければならない」作業だけでなく「やらなければならないかもしれない」作業も予想しておくべき。
・「コスト」と同様に「効果」も数量化すべき。でないとプロジェクトの「効果」が測れない。
・プロジェクトの最短だけでなく最遅の完成期日も予測し、その両方の結果から現実的な期日を予想する。
・リスクの大きな作業は極力先に済ませる事で、プロジェクトの柔軟性を極力確保する。


[読書録]======================


■第一部：なぜリスクを管理するのか
リスクのないプロジェクトには手を付けるな。全くリスクのないプロジェクトに手を出すのは負け組だ。必ずといっていいほど、何もえるものはない。そうでなければ、とっくの昔に誰かが片づけているはずだ。


■第二部：なぜリスクを管理しないのか
リスク管理をすべきでない理由の一つ：はっきり不確定幅を決めると、出来の悪い仕事を許すことになる。
⇒SWマネージャは「予測と目標は同じである」という標準ルールに従う傾向がある。しかしリスク管理のルールによれば、マネージャはいつも部下が最高の仕事を目指して努力するように目標を設定すべきである。その一方、クライアントや上層部に約束をする時には、目標とは全く別の予想を使うべきである。

「間違えるのは構わないが、不確かなのは駄目だ」と言うルールが自分の会社に当てはまったら、おしまい。このルールの意味は、約束した納期に間に合わなくても良い、大幅に遅れても構わないが、その日までの間、期日に間に合いそうもないといってはならないということだ。

「近づく電車が見えない症候群」「選択的近視」：
⇒これを避けるには、リスク管理をはじめる時点で、思いつく限りの破滅的な結果を並べて見ること。
つまらない心配事より、悪夢を攻撃せよ。

SWプロジェクトでは概して、且つために特別なことをするより、負けの程度を抑えるほうが大事なのだ。この仕事では、どんな組織も負けることがある。他の時に勝ったことがあろうがあるまいが、負けた時に最も痛手を受けたものが本当の負である。


■第三部：リスク管理の方法
SWプロジェクトマネージャの殆どは、「やらなければならない」作業についてはほぼ正確に予想できるが、「やらなければならないかもしれない」作業は正しく予想できない。

この業界は、予定より早く終わるという第三の結果を事実上不当なものとみなすことで、期日通りに完成する可能性をほぼゼロにしているのだ。いい加減なスケジュールを許さないがために、むしろいい加減なスケジュールが例外ではなく当然になっている。

全体リスクの不確定性は、成否を決める各々の原因の不確定性を積み重ねた結果である。

Ｎ（ナノパーセント日：その日に完成する可能性がゼロではない最初の日）：
人は楽観的な声質を持っており、過去の経験から、可能な範囲で最も楽観的なスケジュールであるNを見積もることにはかなり熟達している。しかし、Nに完成すると約束するのではなく、本当に約束すべき納期を決定するためのデータとしてNを使うことが重要。

プロジェクトでも損は早めに出してしまうに限る。其の様なときは一旦主導権を失い、成り行きに任せることになる。しかし、早めにそうしておけば、強みを温存しておいて主導権を取り戻すことができる。システムのウチ技術的に軌跡に頼る部分は、初期のバージョンに組み込むべきである。そうすれば、奇跡が起きなかったとしても、いざというときの選択肢が最大限に多い。

インクリメンタル開発計画：
・制約の1つ：詳細設計図に、設計の分割を最低レベルまで全て示さなければならないこと。通常は、高レベルの設計を適当に済ませて設計が完了したと宣言し、後の設計分割作業はコーディングの副産物として行われているのが現状。
・メリット：区切りが多いため、プロジェクト要員の士気が保たれる。状況が目に見えやすい。プロジェクトの最後に残るのはほとんど余計なお飾りの機能だと分かり、その部分をカットできる可能性がある。


■第四部：数量化の方法
コストと効果は同じ精度で表す必要がある。「どうしても要るのだ」としか効果を言い表せないのなら、コストも「相当かかるだろう」とするべきである。

開発者と発注者の説明責任は平等であるべきだ。発注者には、価値が生み出されることを確認する責任がある。ところが、我々のアンケートによれば、企業はプロジェクトの完了後に、効果を実現できたかどうかを追跡調査していない。

製品が大きくなることでコストが比例以上に増大するとしたら、製品を小さくすればコストを比例以上に節約できるはずだ。システムの中で価値コスト比率の低い部分を削減することは、時間と予算に対する制約を緩める最も簡単な方法。ソフトウェア開発者は「もっと小さなソフトウェアを」をスローガンにしようと考えるべきだというと妙に聞こえるかもしれないが、そのほうが有利なことは明らかだ。

デスマーチの正当化にいつも使われるのは、プロジェクトの重要性である。「このプロジェクトは極めて重要なものだから、プロジェクト要員には精一杯頑張ってもらわねばならない」。だが、プロジェクトがそれほど重要なら、どうして会社はそれを適切に遂行出来るだけの時間と資金を使えないのか。

我々の経験では、デスマーチプロジェクトに共通する性質として、予想される価値が低いことがある。どうしようもなくつまらない製品を世に送り出すためのプロジェクトなのだ。デスマーチになる本当の理由は、あまりにも価値がないので、普通のコストでプロジェクトを進めたらコストが成果を上回ることが明らかだからだ。


■第五部：嘘か真か

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

トムデマルコ / ティモシーリスター / 伊豆原弓

プロジェクトにおけるリスク管理の大切さを説いた本。著者本人の体験等ケーススタディがしっかりと書かれているので読み易かった。
目に見えない潜在的なリスクを想定して、(想定したリスクが起こる前、起こった後の)対策を考えておき、しっかりと全体の工程をウォッチしていくという事が大切なんだと思った。が、まだまだ今のプロジェクトへうまく適用させる方法が思いつかない･･･(;_;)
まだまだ消化できてないのだろうなぁ･･･
また、もう一度読んでしっかりと消化しておきたいと思った。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

リスクを回避するのではなく、リスクを計測し管理する手法を提唱する良い本です。主な対象はプロジェクトの管理責任にある方、またはその上層部だと思います。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

トムデマルコ / ピーターフルシュカ / ティムリスター / スティーブマクメナミン / ジェームズロバートソン / スザンヌロバートソン / 伊豆原弓

たぶん、IT業界で働く人が読むと、面白い本。あまりよくない方面の業界あるあるネタが書いてます。
日本企業独特のことかと思ったら世界中同じなんだなぁと気付かされました。ただ、解決法っていうものは書いてない(書けない？)ので、こうなってたら危ないよって気づくための本と思います。

デッドライン ソフト開発を成功に導く101の法則

トムデマルコ / 伊豆原弓

ソフトウェア開発プロセスを、小説仕立てで語っている。なので、読んでいてとてもおもしろい。
ただ、物語の舞台が非現実的かなーと思った。というのも、自分のような一介のエンジニアには、到底想像もできないようなプロジェクト規模だから。
でも、もしかしたら世の中には、物語の舞台と似たようなプロジェクトを管理している人はいるのかも？（きっといるよね）

本の内容については、自分のようなエンジニアでも直面したことある、もしくは直面しそうな事象を取り上げている。事実、自分でも「あー、こんなことあったなー」とか、「自分のことだ・・・」とか思うような内容だった（逆に、こういうことに直面するのは自分だけじゃない、ある意味、正常なことなのかもと思ったが）。
特に、15章以降は、多くのエンジニアが直面したことのある話題ではなかろうか。主人公がメモっていることは、画期的な解決方法ではないにしろ、きっと参考になると思う。

出版された当時と比べて、今はいろいろな管理・開発手法が生まれて、そして流行っている。しかし、多くの人が直面するプロジェクトの問題点の本質的な部分は、今も昔も変わらないんだと思う。
そういった点を踏まえ、この本で学べることを、現在主流の管理・開発手法でいかにして解決を図るかというアプローチが、この本の良い使い方なのかなあと思う。

プロジェクト管理者でなくても、ぜひ、一読していただきたい。読み始めたらとまらないはず。
ちなみに、物語の最後でほろっとした。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

まず非常に楽しい。コミカルに書かれていて読みやすい。
しかし内容は怖い。ソフトウェア開発におけるリスク管理が形骸であることを幾つもの面や事象から指摘している。
ゆえにとても面白い。
しかしデマルコ／リスターの本は面白く、とても納得いくのだが、著者自身も作中で書いているようにこれを現場に導入するにはハードルが高い。
しかし現状の不足、目指すべき高みを意識できる良著。

デッドライン ソフト開発を成功に導く101の法則

トムデマルコ / 伊豆原弓

どうやったらプロジェクトが成功するのか？を小説仕立てで気持ちよく読ませてくれる本。人が多くてもプロジェクトは頓挫するとか、プレッシャーを与えても効率は上がらないとか、なかなか示唆に富んだ本。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

トムデマルコ / ピーターフルシュカ / ティムリスター / スティーブマクメナミン / ジェームズロバートソン / スザンヌロバートソン / 伊豆原弓

プロジェクト管理に役立つか？と言われると、そうでもない。が、読んでいて面白い。
自分の状況と照らし合せると笑えない。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

定番図書のひとつ～
プログラム主体の立場からすると、やらなければいけない事項
というよりは、やって欲しい事項が記載されている。
内容としては7年前といささか古いので、その後の進展が
あるかもしれない、その点については他の人に譲る。

むしろ巻末に付随している、ウィリアム・キングドン・クリフォードの
「信念の倫理」の抜粋が、個人的にはこの本を読んでの最大の収穫だった。
（暴論だが、この論文の理念を具象化した一つが本書・・・？）

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

トムデマルコ / ピーターフルシュカ / ティムリスター / スティーブマクメナミン / ジェームズロバートソン / スザンヌロバートソン / 伊豆原弓

開発プロジェクトにおける「ありがちなパターン」集。ダメなパターンが多めですが、「こんな感じのことをしていると、うまくいくこともある」というパターンもあります。パターンのバリエーションは豊富なので、「良かれと思ってやっていることも、ダメなパターンに陥ることもあるんだ」と気が付くところも多々ありました。
基本的にパターン集なので、これらのパターンから参考とすべきところや、改善すべきところを自分で見つけて実践していくことで、この本を初めて有効に活用できます。逆に、この本からプロジェクト運営・管理の具体的な改善方法を教えてもらいたい、と思って読むと、単なる「あるある集」で終わってしまうでしょう。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

トムデマルコ / ピーターフルシュカ / ティムリスター / スティーブマクメナミン / ジェームズロバートソン / スザンヌロバートソン / 伊豆原弓

トム・デマルコとアトランティック・システムズ・ギルドのメンバーが、ソフトウェア開発現場に見られる様々な「パターン」を淡々と描いた一冊。うーむ、描写が的確すぎて、どれも笑えん……。

帯の惹句は「トム・デマルコの最高傑作」だが、彼の最高傑作は依然としてピープルウェアだと思う。しかし、アドレナリン・ジャンキーが素晴しい一冊であることに変わりはない。

アドレナリンジャンキー プロジェクトの現在と未来を映す86パターン

トムデマルコ / ピーターフルシュカ / ティムリスター / スティーブマクメナミン / ジェームズロバートソン / スザンヌロバートソン / 伊豆原弓

プロジェクトを失敗に陥れるさまざまな要因を、ユーモラスに語っている本。

失敗要因は笑うためではなく、学ぶためにある。

＞弱いチームの方が、強いチームより決定や行動を「保留」する傾向がはるかに強い

強いチームになるためには、意志決定や行動を迅速に行える覚悟が必要なのである。
時間が一番貴重な資源であり、一呼吸おいたらすぐ実行という自分の考え方と一致する。

＞約束がなされたか、また、それは正確にどのような約束だったかについて、約束した側と受け手側の解釈が異なっていると、約束のシステムは崩れる

コミュニケーション不足が大きな問題に繋がることを示唆している。
自分だけのメモに終わらず、相手と一緒に確認して、やっと約束のシステムが出来る。
以心伝心という発想は、結局双方向に良くない。

＞どんなに機能を付け足して飾りたてても、デザインはよくならない。むしろデザインを美しくするには、そぎ落とすことである

同感！
「良いデザインとはシンプルで実用的である」という自分の信念に一致する。
また、ここから「決断とは断つことである」という教訓も学べる。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

さすがデマルコという感じの読みやすく分かり易い本になっていると思います。
リスク管理の定義、なぜリスク管理をしないか(できないか)から始まり、リスク管理の方法へと続くが、小難しい数式等を用いず理解し易いです。
この本を読むと、どうして多くのプロジェクトで
「何か奇跡的な事が起きるかのような楽観的なスケジュールを立てるのか」
について理解できると思います。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

リスクとはそもそも何か、というところから始まって、リスク管理がうまくいかない理由について述べられている。そしてリスク管理が行われない理由についても述べられている。（例：早く終わる可能性のあるスケジュールをひくことが許されないなど）この項が一番参考になった（苦笑）。
あと身にしみて感じるところがあったのが、問題の原因はより早い時期に発生しているが、問題を認識し始める時期（天罰期という　笑）についての説明とその対処法。バージョンごとにリリースするというのが意外と現実的な方法だと分かった。
この本が扱う範囲は入門から中級までかなり広いと思うがリスク管理をやる上で読んでおいてよい1冊だと思う。[2007/1/4]

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

トムデマルコ / ティモシーリスター / 伊豆原弓

ちょうど、あるプロジェクトでリスクマネジメントについて非常にナーバスになっていたときいに読みました。

プロジェクトマネジメントのなかでのリスクの考え方について随分参考になりました。
ナーバスになりすぎないで、早めはやめの対応が重要であることを説いており、実際の場面でも応用の聞く内容だったと思います。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

ソフトウェアは人間関係ビジネス。ITのプロジェクトで発生する問題は主に技術的なものより社会学的なもの(ピープルウェア)。オフィスで感情を刺激する最大要因は自尊心を傷つけられること。その自尊心は大抵アウトプットの量より質に結び付けられる。出荷拒否権限。開放型オフィスへの(筆者の)ヘイト。フロー状態を途切れさせない。ホーンブロワーの考えは、現代では公然と言えば袋叩きに遭うだろうが、個人的には現実に即していると思う。自信のない権威主義体制では服装や髪型に至るまで統制され、会社としての価値創造力は失われていく。最良のイノベーションでも成果を出すには反抗的リーダーシップが必要。イノベーター自身が偉大なリーダーである必要はないが、誰かがその役回りを担う。勤務時間の分割はギアチェンジに要する時間も増え、結果集中を要する設計・開発作業の進捗が割を食うが、こうした問題は往々にしてエンジニアが自分の能力不足が原因と思ってしまう。全体を通してめちゃくちゃ斬新なことを言ってるわけではなく、ずれてはいないが多くは著者の経験則ベースで根拠や出典が少なく、いまいち刺さらなかった。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

エンジニア、さらに言えばプログラマの働き方に対する本。プログラマはどう働くべきか、周囲は彼らを活用させるためにどうすればいいのかを説明している。
ものすごく簡単に言えば、互いにコミュニケーションが取れる状態をチーム内に構築する、周囲（マネージャなど）は彼らの邪魔になることはしない（邪魔になること:電話を掛けたり電話対応させたり集中力が途切れるようなこと）などが挙げられている。それと似たようなことが実例とともに繰り返し述べられているのがこの本の主な内容である。実際にはプログラマが成長する際の学習環境についてなども含まれている。
さて、そうするとプログラマが勝手気ままに周囲に対してふるまえるかのように読めてしまうが、そうではなくここでいうプログラマはそれぞれ第一線で活躍できるような技量を持った存在のことであり、ぴよぴよのプログラマが好き勝手に要求していいわけではない。そんなひよこが成長できるような学習環境も提供するのが環境の責務であると述べているのは先述の通りだが、どちらかというとやはり自身で作業・責務の最適な姿が見えるプロフェッショナルなプログラマを対象としている。
そしてそれは書末にある「自由電子」という語に集約される。よい軍隊のように前線で各個人が高い能力でもって判断・連携する組織的な活動というイメージがぴったりあう。

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

トムデマルコ / ティモシーリスター / 伊豆原弓

リスクに対する考え方が平易に説明されています。書かれたのがかなり昔で、いま活かせるかというと難しいと思いました。まずは計測すること。確率分布的にリスクを捉える点や上層部に対してどういう説明をすべきかまで言及されており、あらためて勉強になりました。

ピープルウエア 第3版 ヤル気こそプロジェクト成功の鍵

トム・デマルコ / ティモシー・リスター / 松原友夫 / 山浦恒央 / 長尾高弘

開発に関わっていて漠然と思っている悩み・課題が、多く言語化されている感覚。

経営陣やビジネス側へはなかなか伝わらない部分だし、現実的に全てこの本の通りにはならないこともあるだろうけど、組織で共通認識されていると物事がスムーズに進む気がする。