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

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

ストーリー仕立てでプロジェクト管理の本質を説いた作品。

ストーリーは、架空の国モロビアに
ソフト開発の管理者である主人公が拉致されて、
国家プロジェクトのソフト開発の管理をさせられるというもの。
話はかなりぶっ飛んでいるんですが、
その過程で、管理についての様々な法則を導きだし、
管理についての法則をまとめていくという
至って真面目でタメになる内容でした。

作品自体は小説のようにサクサク読めて、
それでいてめちゃめちゃ面白い。
トム・デマルコの作品は初めて読んだんだけど、
言っていることはものすごく的を射ていて、
「うんうん」と納得しながら読み進められました。
私たちのような知的生産に関わる者としては、
いつの日か会社の総務や営業の方が、
この本の内容を理解してくれる日が来るのを
切に願います。

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

ある解雇されたソフトウェア開発が気がつけばソフトウェアで国を興そうという某国のプロジェクト管理者にされていた。
恵まれた環境、幾つかの実験、不意のトラブルの中であるべきソフトウェア開発のコツを見出していく・・・
プロセスでも技法でもない方法でソフトウェア開発を変えようとする著者デマルコが、小説風に示唆とユーモアたっぷりで送る一冊。
こんなに楽しくためになる技術関連書ってまたとないのでは。

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

[○11/09/10完読]ドムデマルコの本が出ている。期待！読まねば。ということで読みました。相変わらず面白い。最近「パターン・ランゲージ」なるものをちらほら見た記憶があります。本書もそれを参考にしているようです。プロジェクトや組織の中に見られるパターンをわかりやすく列挙していきます。「あーわかる」という私の感性もあながち間違いではないと少しは自信がつきました（笑
そのうち再読し、内容を簡潔にまとめてみたい気はします。

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

ストーリー仕立てで読みやすい。
読み進めると自然にマネジメントの法則が頭に入ってくる。
お勧めです。

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

置き土産に @you_got 殿からいただいた（んだよね？）本。リスク管理について正面から理論的に述べています。著者が言うナノパーセント日がふつう期限になっちゃうんだけど、リスク図を見せながら「その日にできる確率はナノパーセントです。その2か月後までにできる確率なら70％です」なーんて言っても「ガタガタ言わずに期限までに上げろや」ってなるんだよなー。で直前になって、遅らせることができる機能を1.5次開発に回すってことになる。アジャイルとは言ってないけど、インクリメンタルな開発で機能を分けて段階的に納品するといいよってことをこの本でも言っていた。あと、「完成が遅れるプロジェクトのほとんどは、あまりにも工期が短いためだ」というのは印象的。開発の稟議を通すのに、あーでもないこーでもないってやってるからなんだよなー。えらい人自らがプロジェクトを失敗へと導いている。

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

読み物としても面白い。
楽しみながら、ソフトウェア開発マネージメントで気をつけなければならない点を学べます。マネージメント入門に最適。

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

本書では、主人公トムキンスが旧ソ連のモロビア共和国でソフトウェア・プロジェクトを運営するという物語を通して、プロジェクト管理の教訓を分りやすく示しています。

内容的には、大規模プロジェクトで陥りがちな問題に対する初・中級者向けの教訓が中心となっています。

ただ、これまでの自分の常識が覆されるような目から鱗の事実も多く含まれており、小規模プロジェクトの経験しかない私でも大いに共感と収穫がありました。

何より物語自体が楽しくて、一気に読み終えてしまった程で、ぜひ会社の同僚にも勧めようと思っています。

論理的に論じられている指南書も確かに有用ですが、本書のような物語仕立てでの構成の場合、感覚的にノウハウを吸収できるため、特に初心者には非常に有効だと思いました。

ほんとにオススメです！

しばらくは著者の本を読み漁っていこうと思います。

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

ザ・ゴールのようなストーリー仕立てで、ソフト開発のプロジェクト管理について書いた本。良書。
立場が変わるたびに読み返したい一冊。
本棚行き決定ですね。

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

リスク対策を洗い出して検討しておく。たったそれだけのことが出来ないプロジェクトがどれほど多いことか。リスク管理に敏感になり始めた人に必読の本。

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

語り口は軽く、とても読みやすい。プロジェクトマネジメントにおける、今でも「あるある」とうなづけるような例と陥りがちな罠が語られており、今も昔も変わらない（むしろ悪化している）現状に若干絶望したりもする。
入門本とも言えるし、内容もかなり王道的。
切り口は「リスクマネジメント」であり、プロジェクトマネジメントについて学習してもなお敢えて目を逸らしがちな部分について芯を食った説明をしている。
良本でした。

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

マネジメントの学習のため購入。
技術よりも大事なものは人で、人格の尊重、相応しいオフィス、人材の選び方・育て方、結束したチームがもたらす効果、仕事は楽しくあるべきもの、仕事を生み出す組織作りの大切さを学べてためになった。

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

チーム開発で陥りがちな86のヤバいパターン集。10年以上前の本だけど、今でもありそうな「パターン」多し。このシリーズの特徴だけれど、章冒頭の写真と内容が深いところでつながっているその感覚に、アメリカっぽさを感じる。目次に各章のタイトルが書いてあるけれど、ポジティブな内容なのかネガティブな内容なのか、ぱっと見、判断しづらいのがやややや困る。どちらかに統一してほしかったな。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

p.5
プロジェクトの成功は関係者の緊密な対人関係によって生まれ、失敗は疎遠な人間関係の結果である。

p.11
プロジェクトには「触媒」が不可欠。
「触媒」＝不安定な状態にあるPJのまとめ役

p.22
早くやれと急かせれば、雑な仕事をするだけで、質の高い仕事はしない。
仕事を早くするためには、製品の品質と仕事の満足感を犠牲にせざるを得ない。

p.26
エンドユーザーの要求をはるかに超えた品質水準は、生産性を上げる一つの手段である。

p.40
ソフトウェア開発者の主な仕事は、ユーザー流の表現で表したユーザー要求を、厳密な処理手順に変換するための、人と人とのコミュニケーションである。これは、どんなにソフトウェア開発のライフサイクルを変えようと、絶対に必要な仕事であり、自動化できるはずがない。

p.41
管理者の役割は、人を働かせることにあるのではなくて、人を働く気にさせることである。

p.52
意外なことに、残業の真の目的は、仕事の量をこなすことよりも品質向上のためなのだ。（定時の時間帯は仕事に集中できない）

p.166
チーム編成の目的は、目標の達成ではなく、目標に向かって一体になることである。この目的が満たされたとき、チームのメンバーはずっと効率よく働く。

p.185
最大の成功は「管理」などないかのように、チームがなごやかに一致団結して働いたときである。最良の上司とは、管理されていることを部下に気づかせずに、そんなやり方を繰り返しやれる人である。

p.195
健全な会社にするための不思議な作用を生み出す戦略的要素
・品質至上主義を作り出す
・満足感を与える打ち上げをたくさん用意する
・エリート感覚を醸成する
・チームに異分子を混ぜることを奨励する
・成功チームを解散させないで保護する

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

システム開発をする上で、人の扱い方に特化した内容。共感できる文言が多かった。
おそらく平社員よりも、マネージャーに向けた一冊だが、新人でも読んで考え方を知ることができて良い本だった。

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

プロジェクトがどうしてうまく進めることができないのか。
それはその前の分析をしていないからである。
その分析はどのような観点で発掘していくべきなのか。

リスク管理という観点で、プロジェクトを検分していく書籍。
5部、23章に渡ってリスク管理とその分析について焦点をあてて論が展開されます。

書籍の中で、著者が経験したまたは周りで発生した事例を上げながらどうすれば良かったのかについて討論やデータを持ってプロジェクトを検分していきます。

その中で印象に残ったのは以下です。

- 「不確定性」を数量化する。
経験則に頼らず、可能性を言語化して提示していくこと

- 価値性のあるコンポーネントを分析して提供していく。
プロジェクトで優先すべき価値ある機能を提供して継続するかの天秤にかけること

- 「リスク管理」は「おとなのプロジェクト管理」だ
不愉快な現実と、起こりうる悪い事態を認識して備えておくこと

リスク管理を背負ってプロジェクトを遂行することがあります。
その時に、熊と踊るために準備をしないといけないと気が引き締まる思いでした。

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

人人人。をとにかく意識したチームマネジメント、プロジェクトマネジメントの手法、考え方の教本。

システム開発のプロジェクトに特化された部分もあるが、噛み砕いてみるとプロジェクトマネジメントの核を捉えている事がおおい印象でした。

私自身まだ、リーダーとしてマネジメントしているわけではないが、リーダーになる準備、来たときにはまた部分読みを繰り返したいとおもいました。

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

メンバの心を掴み、チームをまとめ、生産性を上げるために心に留めておかなければならないことが網羅されている。古典だが折に触れて思い出さなければならない。

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

リスク管理について書かれた本。
私ぎ勉強になったと感じたのは、リスクの管理手順がより具体的に書かれているところである。
中では、リスクの扱い方法として、回避、抑制、軽減、かわすの4要素があると記載されており、
回避、リスクを伴う部分をやらないこと
抑制、リスクが発生した時のために時間と資金を準備しておくこと
軽減、リスクが発生する前に抑制コストを軽減する措置をとること
受容、なにもしないこと
とある。
実際のプロジェクトだとどう扱うか、などと対比してみると、原則が理解できると思う。

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

いいパターンとアンチパターンがまぜこぜになっているのに気づくまで、ちょっと混乱というか読みにくかったです。

読んでいる最中にtwitterに書いたのをまるっとコピー。

「 "いい本"だと思うけど、自分の耳に心地好いパターンだけにうなずいているだけと"役に立った本"にならない予感。86パターンの中には耳が痛いものがあるはずで、それについて考えないと。 自戒を込めて。」

で、読むだけだと「あー、あるある！」で終わっちゃいそうなんだけど、この本を使ってMorning Beeをやったらなかなか良かったです。というわけで、読んだ後に人と話すのがオススメ。

あと、実はタイトルと共著者名についてモノ凄く恥ずかしい勘違いをしていたことは内緒だ(^^;