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

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

リスク見積もるのは難しいよなぁ。Risk Mitigation CostとRisk Exposure Costをどう適切に見積もるか。高過ぎてもダメだし、低すぎてもあれだし。プロジェクトマネジメントにおけるリスクの考え方の基本。

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

「ソフトウェア開発上の問題の多くは技術的というより社会学的なものである」という一文に激しく同意。ソフトウェアには人の働き方の変革を後押しする力があり、AIがコードを書いてくれる時代になったとはいえ、それを作り上げるのは依然人の仕事である。そうなれば社会学的なアプローチに触れないわけにはいかない。
本書は一般論的なHRMを学んだエンジニアリング組織のマネージャーが次に読むべき本として素晴らしい内容にまとまっている。一般論とソフトウェア開発の現実とのちょうど中間地点の程よい抽象度。
日本のソフトウェア開発プロジェクトの現場では、冒頭に挙げた「社会学的」な課題解決アプローチが欧米のそれよりも未発達らしく（訳者あとがきより）、これまで当たり前と思ってきた職場環境のあれこれや、プロジェクト管理上のあれこれが実はアンチパターンだったと知ることができる。
皮肉が効いた文体が特徴的な本書ではあるが、挙げられた数々のアンチパターンに対して同調し「だからうまくいかないんだよなあ」と嘆くだけでは意味がない。では何のため、どこから、どのようにして変えていこうか。という今日明日からの行動に落とし込んでいきたい。

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

そもそもシステム開発プロジェクトにおけるリスク管理とは何なのか、から具体的なハウツーまでコンパクトにまとめられており、非常に有益に感じた。
特にリスクを分析していく過程で「誰が負うべきリスクなのか？」は重要な観点に思えた。なぜなら「誰が」の選択肢が観点として無いまま分析を進めると、結果自身が負えるリスクしか直視しない（手に負えないリスクは無視する）という行動を度々目にするから。
しかし、理屈をわかっていてもうまく実践されないのがリスク管理の常だが、これも随所に引用されるウィリアム・キングドン・クリフォードの「信念の倫理」を使ってうまく解説してくれる。
曰く、信念こそが人がリスクから目を背ける理由となりえるものであり、確たる証拠もないのにリスクをないものと取り扱うのは罪である、というようなことが書かれている。
邪かどうか、信念の性質に関わらず、信念そのものが現実から目を遠ざけリスク軽視という罪を生み得る。うーん、深い。

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

プロジェクトマネジメントはツール、セオリーも大事なのだが、ここで述べているようなロジスティクス的なこと、人間関係やモチベーション管理の方が大事だろうなぁと改めて思わされた一冊。

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

本書籍は，仕事でのソフトウェア開発にまつわる，技術面よりは，それ以外の側面での，様々な事について書いています．読者層は，リーダー級のプログラマや技術職のマネージャ，経営者向けかなと思います．
本書籍は，初版は1987年のようで，33年過ぎた2020年時点では，本書籍で書いていることは，いくつかはテクノロジーが解決できているのもあると思いますが，多くは未解決と思います．
前述のとおり，本書はリーダ，マネージャ，経営者向けかなと思いますが，プログラマが自分自身の職場，または参画している（参画してきた）プロジェクトに，漠然とした疑問を持った時に読むのも良いと思います．
プログラマが，自分の居場所を良くするには，ほんのちょっとした，ささやかなアクションの積み重ねだと思います．

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

ほぼ全面的に同意できる内容だった。

・考える暇があったら仕事しろ？
・残業なんかくそくらえ
・早くやれとせかされれば、雑な仕事をするだけで、質の高い仕事はしない
・パーキンソンの法則は、ほぼ確実にあなたの部下には当てはまらない
・プログラマーはただ、仕事をするために身を隠す
・机の前に何時間座っていたかはどうでもいいことで、全神経を集中して仕事に取り組んだ時間が重要
・etc.

これらにピンとくるなら、読んでみて損はないと思う。
驚くべき点は、この本の初版が発行されてから既に30年が経っているという事だ。
もう一つの驚くべき点は、日本では今なお実現している企業はごく少数だという事だ。
一応断っておくと、この本に書かれている内容が古いからではない。

この本を本当に読むべきは、マネージャー層だろう。

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

冒頭に書かれている「実際のところ、ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」と書かれているとおり、人をどう活かすか、どのようにしたら活かせるか、いいチームを育てていくか、などなどについて書かれた本。 初版が1989年に書かれているということだけど、残念ながら今も人を交換可能なパーツとしてとらえ、プロセスで縛ればうまくいくという仕事の進め方をしているところが存在しているのではないかと思う。 中堅ソフトウェアエンジニア+ソフトウェアマネージャは読んでおくべき1冊であると思うけど、読んで何も変わらなければ先は暗闇でしかない。 ということで、とりあえず周りの人には薦めておくことにする。

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

熊とワルツを踊る = リスクの評価、抑制、軽減を行うこと。
インクリメンタル開発の下りを読んで、今時だとアジャイル開発でやってそうだなーと思ったら関連文献に XPエクストリーム・プログラミングが載ってた

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

二十歳過ぎぐらいの時にサラっと読んだ記憶があるが、その時はまるでピンと来なかった一冊。あれから十年近く経った今読むと、その理解度は（良くも悪くも）格段に上がったのは経験が無駄にはなってないという事だろうか。
本書を読んで最も驚く部分は、最近よく聞かれるホラクラシーだとかリモートワークだとかHRTだとかサーバントリーダーシップみたいな概念がまるっきり全部記載されている事だ。この本は約30年前に原著が出版されており、今回読んだ３版で追加されたのは最後の６部だけなので、持ち出す事例や訳のモダンさは変わったかもしれないが、そのエッセンス自体は変わってない事が伺える。この現実を噛みしめると、ソフトウェア開発の現場というのは釈迦の掌をいつまでもぐるぐる回ってるが如く、中々に進歩できない複雑な社会学なんだなぁと心の底から納得すると同時に激しい虚無感を感じる。
唯一の救いはこのようなソフトウェア開発における社会学の原典と、その派生系であるモダンな事例を伴った派生書が数多くこの世には存在するという事実。
ソフトウェア開発を上手くやりたいマネージャーはこの本を繰り返す読みつつ、現場で実践し、時には（37signals辺りを読んで）モダンな方法を取り入れながら少しづつ、ソフトウエア開発における人類の進歩を実現していくのだろうと感じる。

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

【目的】　ソフトウェア開発の問題における社会学的側面に注目し、どのようにマネジメントすべきかの指針を与える。

【収穫】　いかに人のやる気を引き出し、力を発揮してもらうか、ということがマネージャーの果たすべき役割と理解できた。

【概要】　■プロジェクトにおける問題の本質：　技術的な問題というより、人がに関する問題、すなわち社会学的なものが多くの原因である。
■生産性に関する錯覚：　生産性＝利益÷コスト。コストは、退職者の補充にかかるコストも含まれるべき。長時間残業やプロセスの機械化により生産性を上げたとしても、それで人が退職すれば、実際の生産性は下がる。また、人のやる気やコミュニケーションを無視して、新しい技術的な手法によって生産性が飛躍的に向上するというのは、錯覚である。
■生産性向上に果たす要因：　誰と一緒に働くか、オフィス環境が快適か、チームとして一つにまとまる目標があるか、官僚主義的な手順に縛られていないか、といったこと。
■メソドロジー（方法論）における問題と代替案：　書類の著しい増加、手法の不足、責任観念の欠如、全般的な意欲の低下。作業方法の統一を実現するには、教育研修、ツール導入、ピアレビュー実施などの方法がある。標準化が必要でも、10ページ以下のゆるいガイドラインにすべき。
■マネジメントに必要なこと：　無理な納期や品質削減や権限を振りかざすリーダーシップは彼らの生産性に対して有効な手段ではない。オフィス環境をよくする、目標を一致させる、小さくて簡単な成功を体験させる、信頼する、等によりチームのやる気を引き出すこと。

【感想】　プロジェクトマネジメントのうち、特に人に関わる部分に対して深い洞察が行われている名著。ソフトウェア開発に関わっていれば、必ず理解できる部分があると思われる。

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

ソフトウェアの開発組織に見られるパターンを、良いパターン、悪いパターン含めて小粋なタイトルで類型化。業務改善するにも、まずは現状を正確に把握することが大事なので、ソフトウェア開発以外でもチームで作業している業務の方なら何らかの気付きが得られるんじゃないでせうか。

例えば、一つ目のパターン、"アドレナリンジャンキー"。

「次から次へと緊急のプロジェクトがやってくる。誰もが猛烈に忙しい。それも、いつも。...多くのアドレナリン中毒組織は、何かにつけ顧客サービス倫理を持ちだす。切迫した事態に対応することを、みごとな機動力と勘違いしているのだ。...これこそがアジャイルと思っているが、間違いである。」

(T_T)←ちょっと涙目

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

少し変わった立場に立たされた主人公による、プロジェクト管理の経過を小説タッチで描いているのがこの一冊です。
私個人的には、ここに出てくる女性たちが良い味を出していて好きです。

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

システム開発のプロジェクト管理やマネージメントをする架空の物語。
おそらく架空の物語だから、内容の割には読みやすくすんなり入ってきやすい。
実際使う場面が出てくるかわからないが、納期に追われるプロジェクトを担当した際には読み返してみたい。

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

全てのプロジェクト管理者はこの本を読むべきだ。管理者だけでは無くソフトウェア開発に関わる経営者もだ。プロジェクトを成功させたいと思うのならこの本で得られる教訓は間違いなく役に立つ。

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

何故、欧米人が新しいことや難しいことに取り組むことを「チャレンジング」と言うのかが分かる。すなわち、こういったことはすべて、リスクを取ることになるからだ。リスクとその成果を如何に数値化するか、を求めている。

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

【すー】 フィクションのストリーを交えつつ、チームのモチベーションを維持する方法、残業やプレッシャーは悪だという理由など。サクセスストーリー仕立てで、読みごたえはライト。SEL以上には、読んで欲しい一冊。残業削減を目指す転機となった、心のバイブルです。

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

トム・デマルコを知るきっかけとなった1冊。
そりゃ、ご都合主義だとか色々批判もあるだろうし現実的じゃないけれど。いいじゃない、お話だもの。
少なくとも私は、この本を読み返すたびにワクワクして、仕事に対するやる気が出る。
理想の状態に近づくためには、まず最高のものを思い描けなければ。

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

買ってつんどくでした。
次に読んだときは，１０１の法則は読み飛ばしていました。

3度目に書評を書こうと思って読んだら、予想以上に面白かった。
最初の失業する人を、スパイが掠うという設定から度肝を抜かれました。

最後に幸せになる（ハッピイエンドな）ところがすごくよかったと思いました。
ソフトウェア開発者が幸せになるための一つの筋書きとして面白いと思います。

教訓はあくまでも読み取るもので、教えてもらうものではないかもしれません。
作業書（ワークブック）形式にして，経験だけ書いて，
教訓を各自で考えてみる形式にすると面白いかもしれません。

その後で，著者の教訓とのずれの原因としての制約条件の違いを検討するのはどうでしょうか。

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

私がプロジェクトマネジメントに興味を持つきっかけになった一冊。
小説仕立てで読みやすくプロジェクト管理の本質を学べる本です。
ソフトウェア開発だけでなく、小は現場のチーム運営から大は事業単位のプロジェクト運営にも役立ちました。

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

ストーリ仕立てで、その時々の出来事の中で学んだこと、感じたことを日記として記していく。
その日記が１０１の法則として現れる。

ストーリー仕立てなこともあり、とても頭に入ってきやすい。小難しい理論もない。

プロジェクトを評価するきっかけを与えてくれる良書だと思う。