Booklog - アドレナリンジャンキー プロジェクトの現在と未来を映す 86 パターン
Tom DeMarco, Peter Hruschka, Timothy Lister, Steve McMenamin, James Rovertson, Suzanne Robertson, 伊豆原弓
はじめに ~ 1 アレクザンダーのパタン・ランゲージに倣いプロジェクトのパターンを集めた本。 アドレナリンジャンキー。誰もがいつも猛烈に忙しく、計画性がなく緊急性・切迫度の高さだけで仕事を選ぶ組織。 そこでは急ぎの仕事を徹夜残業や休日出勤で忙しく仕上げることが仲間の証。 アドレナリン中毒を直せる病院は存在せず、治すには急ぎの仕事を優先順位をつけて自制して取り組むしかない。 こういう組織いくつか実体験あるわ。概ねできないことを隠すために忙しくしてる。 目次だけでも腹いっぱいになれる内容あるわ。前から順に読む必要もないが頭から読むことにした。
2025-11-13, read count: 1, page: i ~ xi, 1 ~ 4, pages read: 15
2 ~ 6 スピード勝負。本能的に切迫感を持ってい遅れが成功にもたらす意識がある組織。その逆には行動は伴わない。 死んだ魚。プロジェクト初日から達成できないことを知りながら何も言わない人々。 幸福礼賛会議。儀礼的に健全であるように見せかけ実際はその逆な会議。 乳母。チーム一人一人の才能を育て上げるマネージャー。 関連痛。根幹の問題でなく枝葉の問題を対処してしまう。 各パターンなるべく短く一言で表現するようにしてみる。 死んだ魚は、勇敢な人が経営者や上層部に伝えても変わらなかった結果でも生まれるというのが実感としてある。 わたしの理解では、マネージャの仕事が準備なのと同じで、始まる前から組織が腐っているわけ。
2025-11-14, read count: 1, page: 5 ~ 19, pages read: 15
7 ~ 10 マニャーナ。「いつかそのうち」では仕事は片付かない。切迫感を持って取り組む必要がある。 アイコンタクト。任務が緊急・複雑なほど同じ場所で仕事をする必要性が高まる。熱心なメンバーを 1 か所に集めると奇跡が起こる。分散化されたチームには追加のコストがかかる。 ムードリング。プロジェクトの定量的な状況を示さず、感情的な雰囲気だけを報告することは、プロジェクトに危機をもたらす。 信者。メソドロジーの信奉者は状況に応じた判断ができず、プロジェクト思考を妨げることがある。 信者とはなるべく関わらないようにしてるが、マニャーナ、ムードリングは常々起こるしその 可能性に注意している。 アイコンタクトは、自分がリモートワークながらその有用性は知っているので、伝家の宝刀という認識。
2025-11-15, read count: 1, page: 20 ~ 34, pages read: 15
11 ~ 15 魂を貸す。技術に魂を売る者はそれに固執し離れられなくなる。プロは技術に魂を貸し、問題解決に必要な新しい技術があればそれ受け入れる。 レミングサイクル。プロセスを調整することで批判・失敗する恐怖から逃れるために標準プロセスを守り続け失敗する。 ベンチに人なし。コスト削減を重視するあまり交代要員を準備せず結果代打が必要なときに準備に時間を浪費する。 フェイスタイム。地理的に分散したチームは本来難しい。でも 1 か所に顔を集める機会を重ねることで互いの善意の関係性を築くことができる。 「どうしてミケランジェロになれないんだ?」。生産性の向上を期待して導入するツールにも使いこなすための技能が必要。給料の安さだけで人を雇うとツールの性能は発揮できない。 今の会社ではほとんどの人に会ったことがないので、本書に従えばチームとして 120% の性能は発揮できてないのだろうな。 1 人でやる分には困ってないけど。
2025-11-16, read count: 1, page: 35 ~ 47, pages read: 13
16 ~ 20, 閑話 ダッシュボード。弱いチームではダッシュボードは晒し台になる。強いチームでは判断を促し未来予測に使われることで成功の確率を高める。 永遠の議論。一度決まったことに延々メンバーが不平不満を漏らして貴重な時間を浪費する。明確な意思決定プロセスを示すのがマネージャーの責務。 子犬と老犬。若者の学びの姿勢・高揚感が組織の学びのリズムを作る。老兵も若者のリズムに触れて学習のペースを高める。若者を雇わない会社はリスクを避けているだけ。 映画評論家。プロジェクトの成否に興味なく自分だけは成功する自身を持った傍観者。批判だけする人。傍観者はプロジェクトの目標が分離した一例であり、成功率を下げる。 一人一役。自分が何の役割を期待されているか理解し自信を持って責任を引き受ける。このパターンの組織は目的意識を持って取り組む。役割が不明瞭であればうろたえ、全員が責任を担えば何一つうまくいかない。 プロジェクトことば。無害なことばに隠れた不穏な意味。「ベストプラクティス」はわたしも気をつけて使うな。思考放棄ですごく無責任に聞こえるときもある。 ダッシュボードだけパターンと言うかツールの話。 一人一役の全員が責任を持つやつは傍観者効果に近い。
2025-11-17, read count: 1, page: 48 ~ 67, pages read: 20
21 ~ 25 ロシア式。機能面以外の要求を蔑ろにするとユーザビリティを落として嫌われる。 自然な権威。能力があるところに権威が生まれ、権威がある人が決定を下すのが健全。逆は階層組織での決定。 静か過ぎるオフィス。活気を失った組織のメンバーは無為に過ごす。 白線。プロジェクトが明確な境界≒外部とのインタフェースを定義することでスコープが定まる。 沈黙は同意とみなされる。権力がある方は往々にして沈黙を同意とみなす。ノーと言うか難しければ約束リストを作るだけで「同意しなければ同意とみなさない」状態にできる。 不自然な権威と沈黙は同意は関連があるな。歪な権威構造が歪な同意を生むんだわ。
2025-11-18, read count: 1, page: 68 ~ 79, pages read: 12
26 かかし。かかしは手っ取り早く作れるソリューション。間違いを含むこともある。人は一から作るより改良するほうが得意なので、要求を引き出せる。 今日は障害対応で読む時間なし。
2025-11-19, read count: 1, page: 80 ~ 82, pages read: 3
27 ~ 32 いつわりの緊急任務。リスクを回避するのは悪手だが、ありもしないリスクをでっち上げて少ない予算で緊急対応にしても得られるものはない。その結果本質的なビジネスに着手できないのも最悪手。 [時間]に切り札を奪われる。時間が差し迫ってから増員しても機能しない。また時間が足りなければできたはずの機能の完成させることができなくなる ルイス&クラーク。ビジネスの問題領域の探索のためプロジェクトに初期投資することで可能性を探れる。仮にプロジェクトに価値がない場合も不要なコストをかけずに済む。 ちびた鉛筆。過ぎたコスト削減は人を削り組織から離脱させ長期的に競争力を失わせる。 リズム。チームから生まれる一定のリズムがある。 1 週間、 1 ヶ月、半年は長過ぎる。リズムに合わせるという健全なプレッシャーが駆動力になる。決してマネージャーリズムを強制すべきでない。 残業に見る予兆。プロジェクト初期からの残業は熱意の表れでなく恐怖の表れである。失敗、解雇、非難など恐怖の文化が根付いている。 ネガティブなパターンはケチケチしてるのが多いな。そこがゆとりの法則と対立するんやろな。
2025-11-20, read count: 1, page: 83 ~ 97, pages read: 15
33 ~ 36 ポーカーの夕べ。仕事以外の目的での交流がチームの結束を高める。 エセ品質ゲート。品質チェックには形式と内容の 2 つがある。形式だけのエセ品質チェックでは意味の欠陥を見逃す。 テストの前のテスト。テストできるようにするためのテスト。製品だけでなくプロセスや文書にも適用できる。 サイダーハウス・ルール。チームの当事者でない人が作ったルールは実情に適さず守られない。ルールを作るならチームの一員になる必要がある。 33 はフルリモートになってできなくなったが昔は良くっやったな。ただ結束力は高まるが技術向上や学びと直結しないのも悩みどころというのが実感。 35 は今で言うシフトレフトの話。 34 は今でもレビューで難しい点ではあるな。
2025-11-21, read count: 1, page: 98 ~ 109, pages read: 12
37 ~ 40 まず話す、次に書く。短時間で効率的な決定を下すには会話をする必要があり、その結果を残すには文書化する必要がある。この両方をうまく使い分けることを忘れた組織が多い。 ダボハゼ。プロジェクトも個人も自分に過剰な負荷をかける傾向がある。プロジェクトであればマネージャーが権力者からの圧力を避けるためチームに負荷をかけ、個人は良かれと思って過剰な仕事を追う。ただし過剰な仕事量は仕事のスピードを落とすことになる。 アトラス。チームリーダーがあらゆることに長けていることで、次世代のリーダーが育たない、より規模の大きいチームにスケールしない、代替できないというリスクになる。 裸の組織。オープンを謳う組織は過剰な情報量をメンバーに詰め込み注意力をなくさせる。 アトラスのバス係数 1 の話はスタートアップにも通ずるが今のところそれに対する対処法をわたしは知らない。 裸の組織は、詰め込むのが悪いのであってオープンであること自体は問題ないと思う。問題は必要な情報も得られない組織であり、そういうところは未だ多い。
2025-11-22, read count: 1, page: 110 ~ 122, pages read: 13
41 ~ 45 ピア・プレビュー。採用プロセスにチーム自身が関与することで人柄や技術面のミスマッチを避けられる。マネジャーの選出でも同様に使える。 シュノーケリングとスキューバダイビング。プロジェクトには俯瞰して全体を見る視点と深く調べる視点の両方が必要。 いまいましいインターフェイス。システム設計では外部インタフェースが最重要でありそれを知っているマネジャーは誤った仮定を立てる可能性に気を配る。 ブルーゾーン。決められた権限の範囲を超えた自律的な行動がプロジェクトに最良の結果をもたらすことがある。善意の秩序破りが価値を生むのとは逆に決められたことしかやらないことは阻害要因になる。 ニュースの改良。ネガティブな報告が正しく伝わらない。多くは恐怖の文化によりもたらされる。 わたしもブルーゾーンを謳歌してるのでわかるが、想像以上にグリーンゾーンで胡座かいてるヒトが大多数。 グリーンゾーンの人たちにはもっと自律性発揮してほしいけどそこを強制するのも違うし悩ましい。
2025-11-23, read count: 1, page: 123 ~ 139, pages read: 17
46 ~ 50 真実はゆっくり告げる。問題の兆候を知りたくない組織では、早く悪い真実を告げるマネジャーは生き残れず、生き残ったとしてもそれ以降ゆっくり真実を告げるようになる。これをスケジュール・チキンという。 エンドゲームの練習。プロジェクトの最終レビューに向けて常に練習しておくことでリリースの精度を高められる。 ミュージックメーカー。 IT 組織には音楽を嗜む人が極端に多い。 ジャーナリスト。状況報告を正確にすることが仕事だと勘違いするマネジャーがいるが、マネジャーの最大の目標がプロジェクトを成功裏に終わらせることだというを忘れている。 空席。ユーザーエクスペリエンスの任務を請け負う人がいないことで、プロジェクトの他の要素が揃っていてもユーザーにとって役に立たなさそうな製品ができてしまう。 ミュージックメーカーについてはそんなこと感じたことない。界隈の人がこの業界に就職してきたってのはごく少数あったけど。これは米国特有なのか日本がそうじゃないのか不明。
2025-11-24, read count: 1, page: 140 ~ 153, pages read: 14
51 ~ 56 いとこのビニー。チームメンバー同士が最良の結果を目指して激しく議論する。それは仲間内の安全さがあるからで経営陣がリーダーの発言には同じようにならない。 機能のスープ。人々が欲するバラバラの機能をアナリストがビジネスプロセスと関連付けて整理する。また設計者がプロジェクトにスコープと境界を明確にして必要ない機能を取り込まない。これらを怠るとチグハグの多機能で役に立たないシステムになる。 データエラーの真犯人。多くの場合システムのデータには誤りや破損がある。バックアップから復旧することもできるが多くは地道な修正作業が必要になる。 その名は「ベン」。仕事を愛し、難しいことも楽しんでやってのける人がいる。もし彼らに過剰な仕事を割り振って彼らが楽しく感じなくなったら仕事を辞めてしまう。そしてそのチームはかけがえのない人材を失う。 ミス・マナーズ。仕事の結果とその仕事をした人を一緒くたにして正しく評価でいない組織。 知力の集中。複数のプロジェクトに並行して関わると、コンテキストスイッチにより知的最大出力を落とす。 知力の集中みると、副業をいくつも回せる人は知的最大出力を落としても平気な仕事をしてるんやろなと仮定できるな。わたしはよーやらんので一点集中。
2025-11-25, read count: 1, page: 154 ~ 168, pages read: 15
57 ~ 62 「野球に泣くなんてのはないんだ!」。知的労働に於いても感情の発露はある。それは仕事への情熱の現れでもある。 暴力脱獄。対立からくる意見の相違をコミュニケーションの失敗とするのは原因から目を逸らしてるだけ。対立があるものだと認めて確率された対立解決手法に頼る方が余っ程建設的。 期日は必ず守る。必ず期日を守るチームは必ず品質基準を下げる。時間が進むほど人・技術・スコープ変更の手札がなくなって、最後にきれるのが時間・品質基準のどちらかだから時間を守ると品質を失う。 フード++。一緒に調理し食事することがチームに親近感を生み結束を高める。食べ物が人を結ぶのは、仕事のミーティングをしたり見込み客と強力なコネを築くのにカフェを使うのも同様。 ほったらかしの成果。プロジェクトの最終成果物で重要なのは製品だが、それ以外が要求されるのはプロジェクト内外のスポンサーがいるから。もしスポンサーなしに作成される成果物があれば、それは必要ないかスポンサーを探すべきだ。 隠れた美。プロジェクトの成果物の機能美をマネジャーが理解し評価する・しないによって設計者に与える影響は大きい。それが美しい仕事を評価できる人を増やすことにもつながる。 結束力が必ずしもチームの火力に繋がらんのがあるから難しいわ。機能美が余計なものと思われるのもあるあるや。そういうの本質的な価値を見失ってる。
2025-11-26, read count: 1, page: 169 ~ 184, pages read: 16
63 ~ 65 わかりません。わからないと真実を伝えることが単に調べて回答すると伝われば協力を呼ぶこともある。真実を伝えられないのなら非難されるかも知れないといった恐怖が組織にはびこっているかも。 レイクウォビゴンの子供たち。レイクウォビゴン効果は自分を平均以上と認識するバイアスだが、組織におけるレイクウォビゴン効果はメンバーの優劣を曖昧にし、弱点を見逃し、改善の機会を失わせる。 共同学習。プロジェクトの初めからすべて理解していることはあり得ない。作り手と消費者の両方が互いに学び合う必要がある。 プロジェクトが進行しアイデアが固まるよりも前に早い段階で学習を始める。意思疎通にはモデリング言語が最適であることが多い。 レイクウォビゴンもあるあるやな。誰にも対しても良くないが、一部の真実を知りたくない層がいるからこの状況が生まれる認識。共同学習は今では方法論に組み込まれてることが多いか。 ただその方法論に固執して本質が見失われていることも多いから、こういうパターンで理解しておくのは有用そう。
2025-11-27, read count: 1, page: 185 ~ 194, pages read: 10
66 ~ 69, 閑話 魂の仲間。アジャイル界隈で見られるゲリラ的チームは従来型(Waterfall)のルールと全く違うが、どく初期の数バージョン開発を探索的に行うようなイノベーションを志向する領域で素晴らしく機能する。まがい物に注意。 十字穴付きネジ。明らかに優れたアイデアでも受け入れられるまでに時間がかかる。 1 つのアイデアが受け入れられなくても、何度も地道に継続することで実績が伴いアイデアが受け入れられやすくなる。 イノベーションの予測。マネジャーはプロジェクトの開発におけるイノベーティブな側面と高い精度の完成予測を両立しなければならない。これに有効なのが反復的な開発である。 マリリン・マンスター。開発者をコストセンターと考える組織では、如何に優秀な開発者でも評価され裁量を得ることはない。イノベーションや品質を重視する組織では開発者を評価し相応の自由が与えられる。ただしそれも行き過ぎるとプロジェクト進行を阻害するような機能不全に陥る。 編集室の残骸。なんとなく内容が想像つくものもあれば全くつかないものもあるな。
2025-11-28, read count: 1, page: 195 ~ 208, pages read: 14
70 ~ 85 ブラウン運動。プロジェクトの最初に明確なビジョンを策定する必要がある。ビジョンがない状態で人を増やしても一貫性のないバラバラな計画になる。 音吐朗々。プロジェクトの目標≒ビジョンを常に見えるところに置く。バラバラな個人的目標やステークホルダーの目標があってもプロジェクトの最大の目標が軌道を修正する。 安全弁。チームの息抜きが生産性を高める。息抜きはチームから内発的に生まれるののである必要があり、経営層や人事部から与えられたり奨励されても誰も利用しない。 バベルの塔。プロジェクトの共通言語は想像よりの経時的環境的変化で共通の理解を失う。 リスクの大きさ次第では言葉を厳密に定義すべきときもある。成功するチームでは問題領域の学びを言葉に反映させて洗練させていく。 サプライズ。オーバーワークに対して報奨で応じる組織は決して報われない。メンバーがはした金で抱き込まれたと思ったり、当然の権利であると請求されたりするようになる。 冷蔵庫のドア。プロジェクトの計画・進捗・設計といった情報をいつも全員の目に見える場所に開示することは、プロジェクトメンバーに何を重視し何を重視しないかを伝える機会になる。 開示された情報は各メンバーの業績に対する自負であると共に、他のメンバーに対する信頼を示すことにもなる。 たまたま今日読んだセクションの多くは情報開示という透明性に関連するところがいくつかあった。 わたしも重視するところだが、多くの経営層は低レイヤの人たちが「ショックを受けないように」公開しないことを選ぶので、率直に信頼されてないんやろなと考えている。
2025-11-29, read count: 1, page: 209 ~ 224, pages read: 16
76 ~ 80 明日には日が昇る。楽観的なマネジャーは過去の進捗遅れが例外で未来は順調に進むと考えるが、実際そうはいかない。 これは遅延の可能性が証明できないからでもある。 XP の「昨日の天気」手法では過去の生産性で次の反復の生産性を予測する。 パイリングオン。ステークホルダーの支援を装った機能追加がプロジェクトを失敗させる。反復開発では本質的な機能を先に開発するため耐性がある。 変更の季節。プロジェクトのスコープは必ず途中で調整が必要になる。 プロジェクト初期ほど変更を許容しやすいが頻繁な変更は流れを中断する。 比較的短期の反復開発であれば反復の切れ目で変更しやすい。 製紙工場。プロジェクトの状況報告のために大量の文書を作成する必要があるのは重要な作業から目をそらせてしまう。代わりにチームが定めた客観的な測定値を使う。 オフショアの愚行。チームが複数の拠点に分散されタイムゾーンも違えばコミュニケーションのコストが増大する。 オフショア開発を成功させるための助言。迅速な作業を必要とする反復は 1 カ所に集約、チームの耐上がりには時間を要する、国内チーム同様に明確なビジョンをが必要。
2025-11-30, read count: 1, page: 225 ~ 240, pages read: 16
81 ~ 86 訳者あとがき等。 作戦会議質。プロジェクトが専用に会議室を持つことが成功する可能性を高める。それは成功に対して投資する意思であり、プロジェクト状況を張り出す場所でもあり、チームの結束を高める場所でもある。 何のにおい?。組織の中にいると、その腐った匂いや生命力あふれる匂いに慣れていて気づかない。気づくには匂いに慣れていない人を連れ込む必要がある。 身につかない教訓。プロジェクトの最後に開かれる反省会はプロジェクト外への文句になってただの息抜きになる。プロジェクト内部に変化を起こすのは難しいからだ。 それでも必ず次のプロジェクトでとるアクションに繋げる必要がある。また反復の足袋に中間レビューとして反省会を行うのも良い。 生半可なアイデアの美徳。生半可なアイデアでも、そのアイデアが改良のたたき台となり議論を呼びアイデアを発展させる。これにはすぐに実現できないようなアイデアでも潰さず、またアイデアを口にしても個人的な批判や嘲笑を受けない組織でないとできない。 リーク。作業実績時間が予定を上回ったり監視が厳しいことで、それから逃れるために他の作業に実績時間を繰り延べる。リークは報告上の問題でなく、いつの間にかプロジェクトのコントロールを失わせ低品質な製品が出来上がる。 テンプレートゾンビ。テンプレートが固定化し、テンプレートを埋めればプロジェクトが成功すると狂信した組織では、モデルやその他の役に立つアイデアが使えなくなる。 これで持ってるデマルコ本は終わり。本書はパターン集なのもあり思い出したときに気になるパターンを読み返すのも良さそうだ。
2025-12-01, read count: 1, page: 241 ~ 267, pages read: 27
Years (2)
Books (31)
- Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう
- People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け
- Slack ゆとりの法則
- アドレナリンジャンキー プロジェクトの現在と未来を映す 86 パターン
- エッセンシャル思考 最少の時間で成果を最大にする
- サンダー・キャッツの発酵の旅 世界中を旅して見つけたレシピ、技術、そして伝統
- サンダー・キャッツの発酵教室
- スーパーエンジニアへの道 技術リーダーシップの人間学
- デッドライン ソフト開発を成功に導く 101 の法則
- ピアリング戦記 日本のインターネットを繋ぐ技術者たち
- ピクルスと漬物の歴史
- ピープルウエア ヤル気こそプロジェクト成功の鍵 第 3 版
- プログラマーのための CPU 入門 CPU は如何にしてソフトウェアを高速に実行するか
- プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ
- プログラミング F#
- プログラミングの心理学 25 周年記念版
- ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング
- 世界の作りおき野菜 みんなに愛される味付けの魔法
- 世界の納豆をめぐる探検
- 世界一流エンジニアの思考法
- 入門・倫理学
- 分子調理の日本食
- 型システムのしくみ TypeScript で実装しながら学ぶ型とプログラミング言語
- 実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう
- 家庭の低温調理 完璧な食事のためのモダンなテクニックと肉、魚、野菜、デザートのレシピ 99
- 本を読む本
- 演奏するプログラミング、ライブコーディングの思想と実践
- 熊とワルツを リスクを楽しむプロジェクト管理
- 男のスコッチウィスキー講座 100 蒸留所 巡礼試飲旅
- 習慣と脳の科学
- 魏武注孫子