【感想・ネタバレ】アドレナリンジャンキー プロジェクトの現在と未来を映す86パターンのレビュー

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

[ブクログ · ★★★★★]

ソフトウェア開発をやっているとほとんどのパターンに見覚えを感じる。

特に印象深いパターンは
・マニャーナ：スケジュールの期限が長すぎると切迫感が無く仕事が進まない
・幸福礼賛会議：士気が高いように見せることが、個人の成績評価を大きく左右する
・ベンチに人なし：組織をスリム化しすぎて、重要なメンバーが一人欠けたら破綻する

など。他のパターンもとても風刺が効いている。

この本を読んでからは、
「あのチームは幸福礼賛会議の匂いがする」
「このスケジュールの切り方だとマニャーナに陥るかもしれない」
などと、パターン名で状況を振り返ることができやすくなった。

[ブクログ · ★★★★★]

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

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

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

(T_T)←ちょっと涙目

[ブクログ · ★★★★★]

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

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

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

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

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

[ブクログ · ★★★★☆]

計画に対する乖離を早い段階で把握し、手遅れになる前に適切な対策を打てるかどうかが、プロジェクトの成否に大きく関わってきます。そのために、プロジェクト・マネージャーはプロジェクトのQCDに関するデータを収集して現状を分析しようとします。（監視・コントロール）
しかしながら、こうしたQCDデータに現れない事象がプロジェクトを思わぬ方向に導くことも少なくありません。

本書は、こうしたプロジェクトの「兆候」を86のパターンに抽象化してユーモラスな名前を付けて紹介しています。
中には自分の身に覚えのあるパターンも沢山あって耳が痛い限りですが、ありがちなものをピックアップして目に見えるところに書き出しておくだけでも役に立つのではないでしょうか。独特のネーミングも相まって、印象に残るトッピクスが多いと思います。
内容としては、チームビルディングやファシリテーションなど「人」に関する教訓めいたものが多い印象です。

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

[ブクログ · ★★★★☆]

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

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

[ブクログ · ★★★★☆]

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

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

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

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

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

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

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

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

[ブクログ · ★★★☆☆]

あるあるの宝庫、読んでいて面白い。示唆もある。
ただ、面白いが優先していて、今のプロジェクトになにを生かすのかは探しづらい本

[ブクログ · ★★★☆☆]

システム開発あるあるを集めた本です。
あるあるを並べただけなのですぐに役立つものでもなさそうですが、いつかどこかできな臭い案件に出会ったとき、それを言語化する役に立てば本書を読んで良かったということになるのでしょう。
案件が上手くいかないのはみんな分かっていても、それを証明するのは難しいというのは確かになと思いました。

[ブクログ · ★★★☆☆]

エンジニアの組織の中での「あるある」が紹介されています。ただそれらに対しての答えを示してある「あるある」はあまりありません。

それらの「あるある」を知るには、とてもいい本です。

[ブクログ · ★★★☆☆]

開発チームにおけるアンチパーたん、もしくはあるある話集。
判りきっていることの再確認をするための本。

[ブクログ · ★★★☆☆]

自分の周りでもたしかに思い当たるパターンが多かった。特にダメな方のパターンはわかってて流されてるところもあるかも。。。

[ブクログ · ★★★☆☆]

デマルコ大好きなので即買いだったんだけど…

システム開発のあるある本。
一個一個にうなづける所は多いけど、1項目２～３ページじゃねぇ？
良さそうな題材を選んで、もう少し掘り下げてほしかった。

共著だからそんなもんなのか？