アドレナリンジャンキー の商品レビュー

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

2022/09/04

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

2020/12/30

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

2020/08/07

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

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

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

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

2019/02/18

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

2019/01/20

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

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

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

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

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

2018/11/15

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

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

2018/10/13

今年読んだSE読み物系では一番よかったです。

システム開発プロジェクトのアンチパターンが
沢山乗っています。

笑えいたいけど、笑えない。

本書に紹介されている状況を察知し、
楽しい開発をしていきたいものです。

2015/06/04

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

2014/03/23

http://kashiwabaray.com/blog/index.php?itemid=381

Jolt Awardsを受賞した作品となります。失敗プロジェクト、成功する組織の姿を描いた1冊となります。プロジェクトを経験した人なら頷ける数々の事例。今後プロジェクトに参加していく上でも参考になる情報があります。なかなか面白い1冊でした。

■魂を貸す
プロは技術に魂を売らず、魂を貸す。
問題と解決策を区別できることは、魂を貸す者になるための第一歩である。次の一歩は、どれほど優れた技術であっても、明日にはもっと優れたものがあらわれると知ることである。
1つのことを信じ切ることは怖いことである。世の中も人も常に変化し、常に進化し続ける。現状に満足してしまえば、退化が始まる。日々変化する人間であろう。変化に適応しよう。変化を楽しめる人間になろう。

■わかりません
「わかりません」という言葉は、信頼の宣言だと考えてよい。組織全体で人びとが安心して「わかりません」と言えることは、人びとが安心して助けを求められるということだ。このような組織は、あらゆる階層で真に協力を推し進め、その成果を得ることができる。
あなたは「わかりません」と言えるだろうか？いろいろなチームに属していれば、一度は「わかりません」と言えない空気のチームがあったのではないだろうか。もし、言えないとしたら、それは健全な組織ではない。健全な組織であれば本当のことを安心して言える文化がある。
せっかく同じ目標に向かって働いているのだ。いい組織、いいチームを作りたいものである。

■明日には日が昇る
次のインテレーション（計画中のインテレーション）の生産性が、その前のインテレーション（完了したばかりのインテレーション）で経験した実際の生産性と同程度だと想定するのだ。確実に言えるのは、プロジェクトに将来不運が訪れる確率はゼロではないということだ。ならば、それなりの備えをしておくべきである。
計画に遅れが生じると、次はもっと生産性が上がるという前提でリカバリ案を出すことがある。しかし、総じて生産性は変わらない、もしくは下がることが多い。現実的な案を出すとともに、常に不運が訪れることを想定してそれなりの備えをしておくべきである。

【1読書1アウトプット】
わかりませんと言ってみる

2014/01/18

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

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

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

(T_T)←ちょっと涙目