ダン・ガードナーのレビュー一覧

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

約2万件のプロジェクトを調査。そのうち予算と工期と便益を達成したのは0.5%。その原因を探る。組織や集団が誰得な結論を出してしまうのは何故かと常々考えていたが、かなり核心に触れる内容。BP必読。櫻井祐子氏の翻訳大変読みやすい。翻訳者で本を読みたくなるレベル。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

オリンピックなどのイベント、ランドマーク建設、高速鉄道プロジェクト等のコストと工期の見積が当初よりも大幅に超過する問題を解決する方法

ひとつは、経験。
もう一つは「プロスペクト理論」ではなく「参照クラス」だ。
→参照クラスとは過去の似た事例を参照すること。参照クラスという日本語の響きのダサさが良い。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

ひと通り読んで、終章のまとめに腑に落ちた。

プロジェクトの推進担当として、新規性や創造性を求められるばかりに、自分のプロジェクトが固有であるように考えてしまう。
本書では「経験」を重視する考え方を細かく解説しており、高価かつ大きなプロジェクトには必須の考え方だと実感した。

「急いで行きたいなら1人で行きなよ。遠くへ行きたいならみんなで行きなよ。」という言葉の通り、
チームでの戦い方として非常に勉強になった。

◾️実践したいこと
①最終目的を設定してゴールを見失わない
⇒共有して良質なチームビルドする、リスクマネジメントの意味でも友好関係も大切にする

②他者や自分、外部プロジェクトで蓄積された「経験」をレゴ式に組み立てる
⇒自分のプロジェクトが一般的にはどのグループに分類されるのか考察したい

③起こりうる失敗は事前検証し、素早く実行に移す
⇒上記に集中するために「やらないこと」を決める

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

目的を明確にし、ピクサー式に練り上げると、無駄なリソースを積み上げずに、大きな成果が得られる。モジュラー式の開発とすることで、計画通りに遂行できるだけでなく、完成前から収益を得ることも可能。
特別なことは言ってないが、事例を交えて説得力がある。だからといって、じっくり考え、素早く行動できるか？と問われると、これがなかなか難しい。ある程度じっくり考えたら、行動しながら目的と照らし合わせて、小さなフィードバックを繰り返すのが現実的と思う。
グッゲンハイムビルバオに、興味をもった。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

個別見積もりではなく、同様の案件の標準を見積もりに。

新しい技術ではなく、実績のある技術で。

似た案件の経験者を、チームで連れてきて、モチベーションをあげる。

モジュール化して、とにかく習熟度を上げる。エンパイヤステートビルは、上から下まで同じものの積み重ね。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

BIG THINGS　どデカいことを成し遂げたヤツらはなにをしたのか？
著：ベント・フリウビヤ, ダン・ガードナー
訳：櫻井祐子

本書では、プロジェクトの失敗と成功をもたらす、普遍的な要因が考えられている。その要因とは、人間の心理メカニズムと権力である。

心理と権力は、高層ビルの建設からキッチンのリフォームまで、あらゆる規模のプロジェクトに影響を及ぼす。誰かがビジョンを描き、それを計画に落とし込み、それを実現しようとするときには、心理と政治の影響が避けられない。

ビジョンを計画に落とし込み、首尾よく実現させるためには、「ゆっくり考え、すばやく動く」が最も大切である。

構成は以下の10章から成る。
①ゆっくり考え、すばやく動く
②本当にそれでいい？
③根本を明確にする
④ピクサー・プランニング
⑤経験のパワー
⑥唯一無二のつもり？
⑦再現的クリエイティブ
⑧一丸チームですばやくつくる
⑨スモールシング戦略
⑩見事で凄いものを創る勝ち筋

自身の周りでは「BIG THINGS　どデカいこと」を成し遂げようと切磋琢磨されている方がたくさんいる。成し遂げるには道は一つではなく、パターン化されるものではない。しかし、過去から学び、それを仲間に今に活用することはできる。

キーワードである「ゆっくり考え、すばやく動く」。もちろん何が「ゆっくり」で何が「すばやい」のか、そもそも「どデカい」とは何かに対しても仲間を思い浮かべながら読み進めていた。

出来るなら、「どデカいこと」を成し遂げるのを傍観するのではなく、おかがましいことかもしれないがそれを近くで出来るなら中から共に励みたい。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

ITシステム開発に従事している身として多くの失敗プロジェクトを見てきたが、認知していた原因と認知できていなかった原因を知ることができた。

計画の重要性は分かっていたつもりだが見積もりの際に同様のプロジェクトとの比較はやらない時もままあるので注意

特に8章のチーム作り、9章のスモールシング戦略はITシステムでも活かせるはず。
読んだ内容を活かして失敗プロジェクトを減らしたい。
それがすべてのエンジニアの大きな便益になるはず

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

表現が非常にわかりやすい。

行動経済学の本を読んでいた後なので細かい用語などがわかった上で、さらにわかりやすく過去のプロジェクトに落とし込んで説明されていた。
過去に習うことの重要性も、ただ真似をしろではなく、データから見えること、人間の行動に落とし込まれていてわかりやすい。

大きいプロジェクトがある仕事をしているわけではないが、一つ一つの取り組みに活かせる内容が多かった。
何か一つのプロジェクトや、仕事での取り組みに悩んでいる人は、解決策としてではなく、自身の行動の指針の一つとして参考になると思う。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

特にこだわりなく手に取ったのだが、仕事に非常に生かせる内容だった。いや、タイミングが絶妙だったのだ。たぶん一年前、もしくは半年前でさえ、本書を読んだとて「ふーんなるほど」で終わったかもしれない。上層部が「このVUCAの時代にうんたらすんたら」、「仮説思考でうんたらすんたら」、「悩むより動けうんたらすんたら」、まぁそう言う割には形になるプロジェクトの方が少ないのではと言う印象が拭えなかったのだが、なるほど本書が指摘する「早く考えゆっくり実行する」パターンが多いのだ。
同僚やら上司やらに、目をかっ開いてこれを読めと言いたくなるが、言うたとて読むわけもないので、私だけがこっそり本書に追随しようかと思う。

ということで、以下、デカい物事を成功させる秘訣を個人的にメモ。
1. マスタービルダー（プロジェクト実現に必要な経験値全てを持つ人）を雇う。もしくは自らの実践知を生かす。
2. 良いチームを選ぶ。マスタービルダーに選んでもらうとなおよし。優れたチームならアイデアが更に改善される。
3. プロジェクトを行う目的、最終ゴールから考える。フローの右から考える。
4. 小さいパーツを積み重ねて大きな成果を出す。
5. ゆっくり考え素早く動く。
6. 外の情報を取り入れる。ほとんどのプロジェクトは唯一無二ではなく、何らかのカテゴリーに含まれる。過去のデータからリスク予測する。
7. リスクに目を向ける。リスクは起こさないような対応策を立てる。
8. プロジェクト成功に必要な人材、予備費を含む資金が十分得られないなら、そのプロジェクトから手を引く。
9. チームメンバーやステークホルダーと友好な関係を築く。
10. SDGsを意識する。
11. 思い込みや過信が一番のリスク。つまり、自分自身。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

タイトルは内容をミスリードしている。どでかい事を創造するのは、とにかくやってみる事が肝要、という楽観バイアスをタイトルから想像させるが、著者が伝えたいのはその全否定。
プロジェクトマネジャーとしてのスタンスは、著者の主張に激しく同意する。
残念だったのは、日本語訳がamateurなところ。同じ訳者の優秀な訳本を過去に読んできたので、何で？って思う。

Think Slow, Act Fast
ゆっくり考え、すばやく動く

「見たものがすべて」だと、つまり必要な情報や知識がすべて手元にあると思い込んではいけない

１．マスタービルダーを雇おう
２．よいチームを用意しよう
３．なぜ？を考えよう
４．レゴを使ってつくろう
５．ゆっくり考え、すばやく動こう
６．外の情報を取り入れよう
７．リスクに目を向けよう
８．ノーと言って手を引こう
スティーブ・ジョブズ「私は自分がしてきたことと同じくらい、してこなかったことに誇りを感じる」
９．友好な関係を築こう
１０.地球をプロジェクトに組み込もう
１１.最大のリスクはあなた

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

タイトル通り巨大プロジェクトの例が多い。しかし、プロジェクトの規模にリスクとリターンが比例するだけであって、中小のプロジェクトでも計画通りにゴールにたどり着くためのポイントは同じである。
自社のこれまでを思い返して深く頷いてしまうような金言が多かった。

〈学びのポイント〉
・ゆっくり考え、すばやく動く。
・マスタービルダーを雇う。百戦錬磨には千金の価値。
・政治的影響と心理的影響がプロジェクトの始動を急かす。都合の良い見積もりをさせる。
・ITプロジェクトはファットテール。
・バイアスを排除するために、独自性バイアスにとらわれず、過去のケースを参考にする。
※参照クラス予測法（RCF法）
・Whyから始めよ。フローチャートを逆から埋める。
※例　プレスリリースとFAQを企画段階で書く（ジェフ・ベゾス）
・なぜ、という問いが意味を持つのは、心理的安全性が保たれ、意思決定者が聞く耳を持っているときだけ。
・スモールシング戦略。巨大だと完成まで便益を生まない。モジュール性。小さいもので大きいものを作る。
・初の試みはチャンスよりリスクが大きい。先行者利益はほぼ幻。
・最初から貯金を多く持つ。経験がない時点で「赤字」。
・最大のブラックスワン・マネジメントは（十分な計画に基づいて）プロジェクトを早く終わらせること。
・コストは予想を上回り、便益は予想を下回る。
・最低入札が最低コストとは限らない。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

大規模プロジェクトが失敗する要因と、失敗リスクを軽減するアプローチ研究を紹介。

とても「あー…」と思い当たる内容が多く、これから関わるプロジェクトには意識していこうと思うマインドセットが盛りだくさんでした。良書。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

切り口が秀逸かつ普遍的すぎる、全商売人が目鱗だろう名著。「多動力」を始め、「まず動け」宗教が蔓延っている日本でこそ読まれるべき米国ベストセラー経営書。
建築家といった分かりやすい対象に限らず、多くの人と予算が動く、商業クリエイター、マーケターにとって必読すぎる一冊。

骨太なアカデミック知見と最新データの組み合わせで、「大規模プロジェクトとは何か？」を根本的に捉え直す。

最後の最後に飛び出す、原発開発と風力発電発電の大きすぎる違いの話が衝撃的だった。
それぞれの商売人が「私にとってのレゴは何か？」を見つけることから、始めていきたい（本書を読まないと意味不明な文章だけど、非常に核心的な指摘だった）。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

束の間の休止期間に向けて、プランニングの指南書読んでみた。
本書のターゲットは主として企業や国が主体となる施作だが、個人単位にも落とし込んで読めるので、何かやり遂げたい事がある人は読んで損はない。
刺さったのは以下のポイント。（ちなみに個人的に語学力向上、食関連の資格取得の計画がある…）
①手段も目的も「本当にそれで良いのか」
→比較検討した上での手段と目的か、直感の思い込みや感情だけで走っていないか確認すべき。
②「目的」は掘り下げ切れているか。
→一見ゴールに見える美術館新設計画は、町の経済発展（目的）の手段。美術館を完成させるだけでなく、お金を落としてもらう美術館にする工夫がマスト。目的が何か、曖昧にせずに突き詰めて考えること。
③自他の経験を活用し、実験を繰り返そう
→計画はベストプランになりがちなので、実績ベース（実践知）を踏まえて、各計画に創意工夫を凝らそう。
④正しい予測とリスク管理
→自分の計画と似てる例（できれば成功例）に倣う。実例のトラブルも踏まえる。長期計画なら、実働を最短にすることで、トラブル生起の期間短縮。
⑤モジュール性を高める
→単純作業の積み重ねにする。ビル作りも箱を作って積み重ねる方が効率的。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

THINK BIG的なことかと思ったら全然違った。大きなプロジェクトを成功させるには計画だ大事だということ、バイアスに惑わされないこと、過去の事例を参考にし、自分のプロジェクトのみが特別だと思わないこと、モジュール化すること。事業を作るにあたって大切にしなければいけないことをちょうどいいタイミングで読めた。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

プロジェクトを成功させる要点は、
•ゆっくり考え、すばやく動く
•モジュール単位で小さく作り、組み立てることで大きなプロジェクトを完成させる
（そうすることで、実行者の学習能力を反映させることでスピードアップできる）
の二つが肝なのかなと思いました。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

大型プロジェクトがなぜ計画通り進まないのか。ほとんどのメガプロジェクトが、予算超過、期間延長、便益過小の3つに陥ってしまうのはなぜか。著者は1万6000を超えるプロジェクトのデータベースを集め、予算・工期・便益の3点をクリアするプロジェクトはわずか0.5%だという。
直感に頼らずに計画に時間をかけ、不測の事態が起こる確率を減らすためにできるだけ短期間で実行する、「ゆっくり考え、すばやく動く」が成功のカギだとする。

成功例として挙げているのが、度重なる試作で完成度を上げたグッゲンハイム・ビルバオやピクサーの映画作り、パーツを共通化し作業者の熟練度を上げていったエンパイア・ステート・ビルの建設、経営者から現場作業員まで一丸となって「歴史を作る」という気概で建設したヒースロー空港のターミナル5(T5)など。

逆に数ある失敗例の中でも本書で触れているのが、工事中に問題が噴出し工期が遅れていった「すばやく考え、ゆっくり動く」プロジェクトのカリフォルニア高速鉄道、性急な着工で大幅に予算超過したシドニーのオペラハウス、毎回前の大会の経験が生かされないオリンピック（永遠の初心者症候群）、60年と150億ドルを使った高速増殖炉もんじゅ、など。
東芝の原子力事業や三菱重工のMRJなども、何が問題だったのか掘り下げて扱ってほしい。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

私が在職していた会社でも最初は大失敗を繰り返して来ました。何年も失敗を経験して来て編み出した技がこの本に集約されていて驚きました。でも一部反論したいところもあったりしますけど、概ねポイントは掴んでる本だと思います。

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

これは良い本だった。

序章
失敗するプロジェクトに共通する特徴「すばやく考え、ゆっくり動く」
「ゆっくり考え、すばやく動く」が答え

1章　ゆっくり考え、すばやく動く
じっくり計画が成功の鍵
輸送プロジェクトもITプロジェクトも、「予算超過、工期遅延、便益過小」というパターンは、大まかには同じだった。
世界中どこでも同じパターンが見られた。
確率分布には、極端な外れ値がずっと多く裾の厚い、「ファットテール」と呼ばれるものもある。
ITプロジェクトはファットテール
小型プロジェクトもファットテールを免れない。
「厳しい期限」は間違っている
まず考え、それから動く。余裕があれば、計画にたっぷり時間をかけても問題ない
制作に入ると「コストが一気に膨らむ」
計画を立てるためには考える必要があるが、創造的で多面的で注意深い思考は、ゆっくりとしたプロセス
プロジェクトはうまくいかなくなるのではない。最初からうまくいっていないのだ。

2章　本当にそれでいい？
早く決めたい衝動に賢く抗う
「まず行動」が視野狭窄を生む
人は慎重に考えるより早く1つに決めたい（固定化）
わかっていても「直感」を信じたくなる
人は「最初に浮かんだこと」に固執してしまう
人が作業にかかる時間を実際よりも少なく見積もってしまう傾向にある（ホフスカッターの法則）
実行したいのは「前に進んでいる」感じがほしいから
計画立案の前進は、プロジェクトの前進、それも最もコスト効率の高い前進
「見たものがすべて」だと、つまり必要な情報や知識がすべて手元にあると思い込んではいけない
早く決めてしまわないことを肝に銘じておこう

3章　「根本」を明確にする
目的がくっきり頭にあれば間違った道具は取らない
「ゆっくり」することそれ自体がよいわけではない
よい計画を立てた結果として「ゆっくり」になるのであって、「ゆっくり」すればよい計画ができるのてはない
「答え」の前に「問い」がくること
「なぜそれをするのか」をまず固める
プロジェクトを始めるときには、手段と目的のもつれをほどいて、「自分は何を達成したいのか？」をじっくり考え、心理メカニズムのせいで性急な結論に飛びつきたくなる衝動に、なんとかしてストップをかけなくてはならない。
フローチャートを「逆」から埋める
迷ったら「概要」に立ち返る
目的が「明確」になるまで掘り下げる

4章　ピクサー・プランニング
アイデアは「灰色のモヤモヤ」から始まる
人間は工夫を重ねて学ぶことに長けている
よい計画は、実験または経験を周到に活用する。優れた計画は、実験と経験の両方を徹底的に活用する。
「試作品」で完成しておく
フランク・ゲーリーすごい
ピクサーは脚本から観客のフィードバックまでのサイクルを8回くり返す
このプロセスは信じられないほど労力がかかるが、そうするだけの4つの理由がある
1.自由に実験することができる
2.アウトラインからディテールまで精査、検証される
3.説明深度の錯覚という基本的な認知バイアスを克服するのに役立つ
4.コストの差が歴然
大型プロジェクトではトラブルが起こるのは確実で、「いつ」起こるかだけが問題だからだ
計画を立てる間に、打てるだけの手を打っておこう。そして、計画はエクスペリリ（実験＋経験）をもとに、ゆっくり、徹底的に、反復的に立てよう。
リーン・スタートアップ方式は、私のアドバイスとまったく矛盾しない。
計画立案は「能動的なプロセス」である。計画立案には「行動」が伴う。
「仮想最大限のプロダクト」方式、それはテクノロジーの利用が欠かせない

5章　「経験」のパワー
最初から「貯金」がある状態で始める
先行者利益は誇張されすぎている
パイオニアとして市場に参入した企業の半数近くが倒産していたのに対し、フォロワー企業の倒産率は8%にとどまった。また、生き残ったパイオニア企業の平均的な市場シェアが10%だったのに対し、フォロワー企業のシェアは28%だった。
アップルがブラックベリーを追ってスマートフォン市場にすばやく参入したように、「ファスト・フォロワー」となって、先行者から学ぶことがよい
オリンピックはすべて予算超過、つねに初心者によって計画、実行される。永遠の初心者症候群
「反復」が上達をもたらす
「熟練した直感」は正しいことが多い
人間が所有し利用できる最も有用な知識の多くは、形式知ではなく、「暗黙知」である。
政治力学の学びも大事
全体にとっての善が何であるかを知り、それを実現する能力である「実践知」を得るには、形式知以上のものが、すなわち長年の経験からしか得られない知識が必要
経験がない時点で赤字

6章　唯一無二のつもり？
想像との「ズレ」をなくす
失敗の根本原因は、実行以外の部分、実行が始まるずっと前の「予測」にあることが多いのだ。
アンカリングと調整、つまりアンカーの質が重要、人は直近に見た数字に簡単に引っ張られる
「参照クラス」
予測者が内部情報を無視することはほぼないが、外部情報を見過ごすことは多い。そしてそれが命取りになる。
参照クラスのデーターコスト、工期、便益、その他あなたが予測したいものに関するデーターをアンカーにしよう。そして必要な場合は、あなたのプロジェクトと参照クラスの平均的なプロジェクトとの違いを踏まえて、アンカーを調整しよう。これがあなたの見積もりになる。この上なく簡単な方法だ。
調整が必要になるのは、あなたのプロジェクトのコストが参照クラスの平均値よりも高く／低くなるという、明確で強力な理由がある場合だけだ。
判断を迷ったら調整しなくていい
調整は、バイアスが忍び込む隙なのだ。調整しすぎると、バイアスにとらわれないアンカーの価値が失われてしまう。
これを「参照クラス予測法（RCF法）」と名付けた、「ファスト&スロー」でも太鼓判を押されている
ブラックスワン・マネジメント（リスク管理）
初期の遅れはブラックスワンを起こしやすくする
マイルストーンならずにインチストーンでリスク管理

7章　再現的クリエイティブ
「創造はロマン」vs「創造は管理できる」
物語vsデータは物語が勝ってしまう
ただ、現実にはデータが圧勝である
計画フェーズに創造性は宿る

8章　一丸チームですばやくつくる
「一体感」で全員の士気を高める
百戦錬磨の実行部隊には千金の価値がある
必要なものを「ただち」に支給する
自分のありのままの考えや気持ちを気兼ねなく言える状態を、「心理的安全性」と呼び、士気を高める
チーム作りには「コスト」をかける

9章　スモールシング戦略
小さいものを積み上げて巨大にする
モジュール性
自由自在にスケールを変えられる
「モジュール」「美しい」「高品質」はすべて同時に成立する概念なのだ。
ファットテールではないプロジェクトタイプは太陽光発電、風力発電、化石燃料発電、送電、道路のたった5つだ。つまりこれらはほかのタイプと違って、壊滅的に失敗するリスクがそれほど高くない。この幸運な5タイプに共通する特長は何か？モジュール性が非常に高い、または極端に高いのだ。
誰も行きたがらない恐ろしい場所ーには、核棄物貯蔵、オリンピック開催、原子力発電所建設、ITシステム構築、水力発電ダム建設が並ぶ。これらはどれも喪型的な「1つの大きいもの」型のプロジェクト
小さいものをすばやくスケールアップできるから、個人でも小さい実験を通して大きいことができる。

終章　「見事で凄いもの」を創る勝ち筋
メガプロジェクト研究が導く11の経験則
1.マスタービルダーを雇おう
2.よいチームを用意しよう
3.なぜ？を考えよう
4.レゴを使ってつくろう
小さいモジュール性を見つけてそれを使って大きくしよう
5.ゆっくり考え、すばやく動こう
十分な時間をかけて、詳細な実証済みの計画を立てよう
6.外の情報を取り入れよう
視点を「プロジェクト」から、プロジェクトが属する「タイプ」にシフトする
7.リスクに目を向けよう
8.ノーと言って手を引こう
9.有効な関係を築こう
10.地球をプロジェクトに組み込もう
11.最大のリスクはあなた
行動バイアス

BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？

チームで大きなことを成し遂げることが苦手で、いつも一人か多くて２人で物事を進めることが多い。
でも会社で大きなシステム導入が控えていて、失敗したくなかったのでこの本を手に取った。

読み終わった後、プロジェクトってこんな風に進めればいいんだって思えた。特に空港建設のエピソードが心に残った。当時の人があのころを思い出して「あのチームでの仕事はよかったなぁ」ってしみじみしてるのを読んでて、そう思ってくれるようなチームを作りたいなと思った。

失敗はコストの問題だけじゃなくて、その人の才能が広がる機会も失うという考え方にもハッとした。プロジェクトの責任の重さを改めて感じた。

チームで何かを成し遂げたい人はもちろん、一人で目標に向かって頑張ってる人にもおすすめ。大型プロジェクトの話だけど、個人の目標にも使えるヒントがたくさん詰まってるので。