デッドライン の商品レビュー

トム・デマルコ(著者),伊豆原弓(訳者)

2024/07/29

ソフトウェアプロジェクト管理を題材にした小説となっている。先にピープルウェアを読んでおくとより楽しめる。

2022/07/12

◼️読んだ動機
Twitterで名著と言っている人がいて気になり読んだ

◼️感想
小説チックに書いてあり、各章の最後にその章のまとめのような文章がある形式だった。
小説の方は、あまり頭に入ってこず流し読みになったが、まとめの文章にはいいことが書いてあることが多く為になった。

◼️以下よかった箇所のまとめ
4章 正しい管理の4つの本質

- 適切な人材を雇用する
- その人材を適所に当てはめる
- 人々の士気を保つ
- チームの結束を強め維持する
それ以外のことは管理ごっこ

変更はあらゆるプロジェクトほ成功のために必要不可欠である

リスクを避けることはそれに伴う利益を持つ逃すことになる

5章　支配者
どれほど強い脅しをかけても最初に割り当てた時間が足りなければやはり仕事は完成しない

7章　管理者の採用
戦闘が始まる中には、管理者の本当の仕事はもう終わっている
新しく採用した人材には、1回は実証済みの能力レベルのプロジェクトを任せ、ほんとうに目標を拡大するのは次回とする

8章　リスク管理と生産性
- 短期的に生産性を高める方法などない。生産性は長期的な投資によって向上する
- 短期的な効果を約束するものは、インチキである可能性がたかい
- リスクを管理することによってプロジェクトを管理せよ

9章　人材管理の智将
- 成功を最大化するより、失敗を抑えることによって、全体的な成績を高めることができる
- 1日を無駄にする方法はいくらでもある…しかし1日を取り戻す方法は1つもない

11章　理想と現実
- 開発者を増やせば開発スピードが上がるわけではない
- 大人数のチームより、少人数のチームのほうが成果を上げる場合は多くある
- が、政治が蔓延ると少人数のチームは存続できない

14章　設計とデバッグの関係
- 優れたプロジェクトは、デバッグに費やす時間の割合が遥かに低い
- 優れたプロジェクトは、設計に費やす時間の割合が遥かに高い

15章　残業の効果
- プレッシャーをかけても思考は早くならない

19章　プロジェクトの人数
- 初期に人数が多すぎると、プロジェクトは（全員に仕事を与えるため）重要な設計作業をえない
- 設計が感染者する前に大勢に仕事を割り当てると人や作業グループ間のインターフェースを最小化できない
- このため、相互依存が高まり、会議が増え、やり直しが増え、フラストレーションがたまる
- 理想の人数配分は、プロジェクト期間の大部分を承認図のコアチームで行い、プロジェクト終盤に人数を大幅に増やすというもの
- 無茶なスケジュールのプロジェクトは、妥当なスケジュールのプロジェクトに比べ、完成までに時間がかかる

23章　101の教訓
- プロジェクトには目標の予想の両方が必要だ。この二つは違っていて当然である

2020/10/04

システム開発で起こる問題や課題とそれに対する考え方や心構えをストーリー形式で学べる本。

ストーリーは若干、非現実的だけど「PJあるある」がチリばめられているので参考になるとは思います。

2018/10/23

この本は、小説として星２つ。ソフトウエア開発プロセスの参考書としては星１つ。言いたいことがさっぱり分からん。きっとデマルコも、この本を書いたことを後悔しているに違いない。

2021/08/08

信頼する某SEの方からお薦めいただいた著書。プロジェクトマネジメントの要諦を小説仕立てにで教えてくれる。直観的にそうなんだろうなあというポイントがまとめられている。ただし、作り話であり、かつ、小説の中身もやや抽象的なため、実感がわきにくいのが残念。

・正しい管理の四つの本質
　適切な人材を雇用する。
　その人材を適所にあてはめる。
　人びとの士気を保つ。
　チームの結束を強め、維持する。
・変更は、あらゆるプロジェクトの成功のために必要不可欠である。
・人は安全だとわからないと変更を受け入れない。
・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。
・管理者は心、腹、魂、鼻でやるものだ。
　心で指揮をとる。
　自分の腹を信じる。（直感を信じる）
　組織に魂を吹き込む。
　くだらないものを嗅ぎ分ける鼻を持つ。
・優れたプロジェクトは、デバッグに費やす時間の割合がはるかに低い。
・優れたプロジェクトは、設計に費やす時間の割合がはるかに高い。
・相手を好きになり、気づかわなければ、人にちがうことをさせることはできない。相手を変えるには、相手の考えていることとその理由を理解し、尊重しなければならない。
・プレッシャーをかけても思考は速くならない。
・残業時間を増やすのは、生産性を落とす方法である。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・仕様書があいまいなのは、システムの利害関係者の間で対立が解決されていないしるしである。
・仕様書がお粗末だとは誰も言わない。自分の方が悪いのだと思い込みがちである。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには目標と予想の両方が必要だ。この二つはちがっていて当然である。

2018/02/28

プロジェクト管理の勉強をしようと手にとった本ですが、思ったよりも小説寄りでエンターテイメントでした。プロジェクト管理にまつわる人間関係洞察は確かになと思いました。それ以外の技法についてはとくに学べませんが、読んでるうちに感情輸入してベロックにイラついてしまうくらい面白かったです。

2018/01/14

感想は以下
http://masterka.seesaa.net/article/456199230.html

2016/05/07

2006年に一度読んだことがあるみたいだが記憶になかった。2016年に再読。プロジェクト管理をそこそこしてきた今だから納得できるし発見がある、読んでよかった。トムキンス、ラークサー、NNL、ベリンダ、無理矢理な導入と結末。
・正しい管理の本質、適切な人材を適所にあてはめ人々の士気を保ってチームの結束を強め維持する。
・リスクを管理することによってプロジェクトを管理せよ。
・プレッシャーをかけても思考は速くならない。
・管理者の怒りと侮辱は伝染する。
・管理者が部下を刺激するために侮辱を使うことは、部下ではなく管理者の能力不足のしるしである。
・入出力の完全なリストのない仕様書は、見込みなしである。
・理想の人数配分は、プロジェクト期間の大部分を少人数のコア・チームで行い、プロジェクトの終盤に人数を大幅に増やすというものである。
・会議は、重要ではない人物が出席しなくても心配のないように、小さくする必要がある。欠席者が安心するための最も簡単な方法は、議事予定表を発行し、それに厳密に従うことである。
・プロジェクトには儀式が必要である。
・病んだ政治を下から治療することはできない。
・倹約精神とは、失敗した企業の中で、その失敗の責任者が作った公式である。

2016/01/29

物語形式で展開される、とあるソフトウェア開発の物語。

さまざまな出来事により、プロジェクトマネジメントの要衝のおさえかた、実行の仕方、ものごとの進め方を学べる一冊でした。

読者がソフトウェア開発プロジェクトに関与しているなら、とても共感できる部分が多いと思います。

たとえば残業時間と生産性の話や、無駄な会議を減らす方法など。

また私自身、自分の経験をうまくあらわせなかったことが整理されていて役立ちました。特に設計段階は少人数で進め、製造で一気に人を投入するあたりは、うまくいったプロジェクトでも同じでした。頭を使うフェーズは、人が多すぎると「船頭多くして・・・」になりかねないと再認識です。

唯一、試してみたいけど怖くてできなさそうなのが、設計時間を圧倒的に費やし、設計段階でバグを潰すという考え方。これ、実際にやったら、ものすごいプレッシャーになると思います。だけど、クソみたいな設計で製造に入るよりも、きちんと机上で言葉で考えぬいてからのほうがいいんだろうなあという共感はできました。

2016/01/02

物語とともに教訓を得られるため、非常に分かりやすかった。
気づきのあった言葉をいくつか。
「日常のリスクに注意せよ」
日常のリスクに気づくために、KPT法を使うのは、非常に有用ですね、やっぱり。
「変更はあらゆるプロジェクトの成功のために必要不可欠である」
改善、改善ですね！
「入出力の完全なリストのない仕様書は、見込みなしである」
これ、妥協しないように気をつけないと。