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

プロジェクトマネジメントをする方は必読だと感じた。 この本に書いてあるノウハウをまとめて壁に貼っておこうと思う。 数値による根拠や、Amazonやピクサーの実例も挙げられており、内容に説得力を感じた

なぜプロジェクトは失敗するのか？失敗を避けるためにはどうすればいいか、が（一応）書いてある。面白いです。仕事を見直した…

群馬県立図書館から借りて読了。 タイトルを見て読んだ人は裏切ると思う。実は小さなステップをしっかり踏んで大成を成す出来事が多かったんですね。。。！

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

個別見積もりではなく、同様の案件の標準を見積もりに。 新しい技術ではなく、実績のある技術で。 似た案件の経験者を、チームで連れてきて、モチベーションをあげる。 モジュール化して、とにかく習熟度を上げる。エンパイヤステートビルは、上から下まで同じものの積み重ね。

これは良い本だった。 序章 失敗するプロジェクトに共通する特徴「すばやく考え、ゆっくり動く」 「ゆっくり考え、すばやく動く」が答え 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　どデカいことを成し遂げたヤツらはなにをしたのか？ 著：ベント・フリウビヤ, ダン・ガードナー 訳：櫻井祐子 本書では、プロジェクトの失敗と成功をもたらす、普遍的な要因が考えられている。その要因とは、人間の心理メカニズムと権力である。 心理と権力は、高層ビルの建設からキッチンのリフォームまで、あらゆる規模のプロジェクトに影響を及ぼす。誰かがビジョンを描き、それを計画に落とし込み、それを実現しようとするときには、心理と政治の影響が避けられない。 ビジョンを計画に落とし込み、首尾よく実現させるためには、「ゆっくり考え、すばやく動く」が最も大切である。 構成は以下の10章から成る。 ①ゆっくり考え、すばやく動く ②本当にそれでいい？ ③根本を明確にする ④ピクサー・プランニング ⑤経験のパワー ⑥唯一無二のつもり？ ⑦再現的クリエイティブ ⑧一丸チームですばやくつくる ⑨スモールシング戦略 ⑩見事で凄いものを創る勝ち筋 自身の周りでは「BIG THINGS　どデカいこと」を成し遂げようと切磋琢磨されている方がたくさんいる。成し遂げるには道は一つではなく、パターン化されるものではない。しかし、過去から学び、それを仲間に今に活用することはできる。 キーワードである「ゆっくり考え、すばやく動く」。もちろん何が「ゆっくり」で何が「すばやい」のか、そもそも「どデカい」とは何かに対しても仲間を思い浮かべながら読み進めていた。 出来るなら、「どデカいこと」を成し遂げるのを傍観するのではなく、おかがましいことかもしれないがそれを近くで出来るなら中から共に励みたい。

目的をはっきりさせてじっくり計画しろ 計画段階で試行錯誤しろ 早く決めたいと思うな 自分だけでなく他人の経験も活用しろ 自分のプロジェクトは特別じゃない（ようにしろ） 部分を細かく分けてリスクをコントロールしろ

システム開発でいうところのアジャイルの考え方に近いなと思った。システム開発の話で出なく、建築の話中心でとても分かりやすい。自分がシステムの世界で仕事をしているので、他の業界でも同じようなアプローチが有効であることは新たな発見だった。 一方で具体的な計画の立て方や、プロジェクトの分け方などの方法の記載はないので、その先の参考書籍があるとさらに良いのではと思う。

オリンピックや高速鉄道など、大型プロジェクト案件でなぜ遅れや予算オーバーが頻発するか、の話。それを回避するには、計画に時間を使い、実行はなるべく早く済ませ、ブラックスワンの出現確率を下げるべし、とのこと。モジュール化の議論も賛同できるところはあるが、容易にスケールできるものばかりやっていると強者ばかりが強くなり、強者と弱者の差は広がるばかり。この本を読み始めた最初はおもしろいとかんじましたが、最後はあまりしっくりこない本でした。

2025年5月1日読了。鉄道やビル建設、ITシステム構築などの「ビッグプロジェクト」のほとんどがコスト・スケジュール超過により「失敗」している事実をデータから明示し、成功と失敗の差を分けるもの・留意すべき点は何か？を明らかにする本。「ITプロジェクトは失敗する」んだよね、こうはっきり言われると反論したくなるが確かに自分の経験からもプロジェクトは失敗することが前提…。コスト・納期の面で成功しているプロジェクトもこの世には存在しているのだが、人間の「楽観性」「独自性」などのバイアスがいかにプロジェクトを誤った方向に導くか、という点はいちいち納得する。優秀な人材をアサインしたうえで「わかっていてもできない」政治的・文化的要因をいかに取り除けるか、が最重要ポイントなのだなあ…。「莫大なコストをかけて『やりきった』プロジェクトがもたらした文化的価値」に関する考察も非常に興味深い。要は「生存者バイアス」ということか。

ITシステム開発に従事している身として多くの失敗プロジェクトを見てきたが、認知していた原因と認知できていなかった原因を知ることができた。 計画の重要性は分かっていたつもりだが見積もりの際に同様のプロジェクトとの比較はやらない時もままあるので注意 特に8章のチーム作り、9章のスモールシング戦略はITシステムでも活かせるはず。 読んだ内容を活かして失敗プロジェクトを減らしたい。 それがすべてのエンジニアの大きな便益になるはず

表現が非常にわかりやすい。 行動経済学の本を読んでいた後なので細かい用語などがわかった上で、さらにわかりやすく過去のプロジェクトに落とし込んで説明されていた。 過去に習うことの重要性も、ただ真似をしろではなく、データから見えること、人間の行動に落とし込まれていてわかりやすい。 大きいプロジェクトがある仕事をしているわけではないが、一つ一つの取り組みに活かせる内容が多かった。 何か一つのプロジェクトや、仕事での取り組みに悩んでいる人は、解決策としてではなく、自身の行動の指針の一つとして参考になると思う。

2025/3/29 「1910年から1998年までに実施されたプロジェクトのコスト見積もりは、最終コストを平均28%も下回っていた。」 予算・工期・便益の3点ともクリアするプロジェクトは、わずか0.5%だ。 学者の言う「固定化(ロックイン)」とは、ほかに選択肢があるかもしれないのに、それが唯一の選択肢であるかのようにふるまい、結果として予想以上のコストやリスクを負ってしまう、人や組織にありがちな傾向をいう。 心理的要因と政治的要因を、独立した別個のものとみなさないよう、気をつけてほしい。これらの要因は互いに補強し合うことが多く、大型プロジェクトではその傾向が強い。 　政府や官僚的企業にとって、この手の分析はお手のものだ。カリフォルニア高速鉄道のプロジェクトはまさにそうやって、着工までの10年以上を「計画立案」に費やし、膨大な資料や数字を作成しながら、計画らしい計画を生み出すことができなかった。 　これに対し、よい計画立案は、模索し、想像し、分析し、検証し、試行錯誤する。これは時間のかかるプロセスだ。つまり、よい計画を立てた結果として「ゆっくり」になるのであって、「ゆっくり」すればよい計画ができるのではない。 　よい計画を生み出すのは、幅広く深い「問い」と、創造的で厳密な「答え」である。ここで注意してほしいのは、「答え」の前に「問い」が来ることだ。問いが答えの前に来るのは当たり前、いや、当たり前であるべきだが、残念なことにそうなってはいない。プロジェクトは必ずと言っていいほど、答えから始まる。 「なぜ?」という問いかけが意味を持つのは、全員が気兼ねなく発言でき、意思決定者が聞く耳を持っているときだけだ。「多くの関係者が、ファイアフォンはうまくいくはずがないと思っていた」と、ジャーナリストでアマゾンに関する本を数冊書いているブラッド・ ストーンは結論づける。「だが頑固なリーダーに議論を挑み、打ち負かすだけの気概や賢さを持つ者は1人もいなかったようだ」 　右から左へ考えることが難しいのは、それが自然なことではないからだ。私たちにとって自然なのは、「見たものがすべて」と考え、目の前にあるものだけに集中することである。 そして、クールなアイデアに惚れ込んでいるときや、プロジェクトの設計にのめり込んでいるとき、細部に没頭しているときはなおさら、右端のボックスは目に入らない。トラブルが始まるのはここからだ。 　しかし、先行者利益は誇張されすぎている。ある重要な研究は、市場をいち早く開拓した「パイオニア」企業と、パイオニア企業を追って市場に参入した「フォロワー」企業を比較した。 　50種の製品にわたる500のブランドのデータを分析したところ、パイオニアとして市場に参入した企業の半数近くが倒産していたのに対し、フォロワー企業の倒産率は8%にとどまった。また、生き残ったパイオニア企業の平均的な市場シェアが100%だったのに対し、フォロワー企業のシェアは28%だった。 　参照クラスのデータ――コスト、工期、便益、その他あなたが予測したいものに関するデータ―をアンカーにしよう。そして必要な場合は、あなたのプロジェクトと参照クラスの平均的なプロジェクトとの違いを踏まえて、アンカーを調整しよう。これがあなたの見積もりになる。この上なく簡単な方法だ。 　RCF法の精度はずば抜けて高い。一般的な予測とRCF法による予測の精度の差は、 プロジェクトタイプにもよるが、私がデータを収集したプロジェクトタイプの半数以上で、 RCF法のほうが30%ポイント以上精度が高い。 　なぜだろう? 自分たちのプロジェクトは違うと感じたからだ。「今回は違う」は、独自性バイアスの決まり文句である。結局、教科書が完成したのは8年も後のことだった。 　現代の認知バイアス研究の第一人者であるカーネマンでさえ、独自性バイアスの餌食になるのなら、私たちがバイアスにとらわれやすいのも無理はない。この罠を避けるために、 つねに意識して警戒を怠らないようにしなくてはならない。 　最後の理由は最も単純だ。データの問題である。平均値を計算するのは簡単だが、そのためにはデータを入手しなくてはならない。それが難しい。 大型プロジェクトのブラックスワン・マネジメントは、複数の手法を組み合わせて行うのが一般的だ。 プロジェクトの初期段階に資機材調達や政治的決定の遅れが生じると、ブラックスワン的状況が起こりやすいこともわかった。 「見事で凄いもの」を創る勝ち筋 ―メガプロジェクト研究が導く1の経験則 1「マスタービルダー」を雇おう 2 「よいチーム」を用意しよう 3 「なぜ?」を考えよう 4 「レゴ」を使ってつくろう 5ゆっくり考え、すばやく動こう 6「外の情報」を取り入れよう 7「リスク」に目を向けよう 8「ノー」と言って手を引こう 9「友好な関係」を築こう 10「地球」をプロジェクトに組み込もう 11 最大のリスクは「あなた」

このタイトル（原題は”HOW BIG THINGS GET DONE”でほぼ同じ意味）は内容を正確に表しているんだろうか。より正確には『どのようにしてメガプロジェクトは失敗するか』の方が主眼のような気がした。 膨大な事例に紙幅を割いて（巻末の参考資料ページの厚さにビビる）、本書はいかに世界中の数々のメガプロジェクトが失敗してきたか、その理由を事細かに説明してくれる。ここでいう失敗は、具体的には予算超過・工期遅延・便益過小を指す。あらゆるプロジェクトを研究した結果、なんと予算・工期・便益の３つともをクリアするプロジェクトはたったの0.5%しか無かったらしい。 失敗しないために必要なことは、「ゆっくり考え、すばやく動く」こと。 急いては事を仕損じる、の諺通り、結論や予算の見積もり、リスク予測などを急ぎすぎたがために失敗してしまった数多くの事例が傍証となっている。 そしてこのことは何も国家規模の大プロジェクトに限ったものではなく、住宅リフォームや社内プロジェクトなどの個人レベルのものにも共通する普遍的な法則なようだ。確かに、深く考えずに始めた行動は失敗しがちだ。身に覚えがある。 とはいえビジネスの世界では「走りながら考えろ」「巧遅より拙速」「時は金なり」の考え方が主流だし、「深く考え抜いてから始めろ」は理想的だけど現実には厳しいんじゃないかな、とも思う。だからこれだけ無数のプロジェクトの失敗があるんだろうけど。 我が国からは高速増殖炉もんじゅの事例が紹介されていた。2020TOKYOオリンピックも紹介されるかと思ったが、オリンピックはむしろ失敗するメガプロジェクトとしては定番のものらしく、幸か不幸かモントリオールオリンピックに紹介の座を譲っていた。コスト超過の金メダルはこの大会だったらしい。 終章には「どうすればプロジェクトは成功する“可能性が高くなる”のか」が短くまとめてある。そこに書いてあるのは、そりゃそうだろう、と言いたくなるような拍子抜けなほど普遍的なことばかりだ。畢竟、どんな名著でも手短にまとめてしまうとごくごく一般的なクリシェになってしまうのかもしれない。 まとめからは取りこぼされた枝葉末節にこそ、それぞれの本のエッセンスは詰まっている。

プロジェクトマネジメントの本だった。小さく繰り返しやれ。アジャイル方式。原発建設だって 小型の原発いっぱい作れ。みたいな。イテレーション回せ。

やっと読了 読みにくいわけではなく、たくさん思い当たることがあって、読むたびに考えてしまうため。まとめを手元に何かあれば振り返ろう。

プロジェクトが計画通りに進まない原因は実行部分ではなく、実行に移る前の予測・計画・見積もり部分にある 以下、心に残った言葉 ・行動あるのみという言葉に当てはまるのは、可逆的な意思決定のみ ・直感は形式知以上に実践知（経験からしか得られない意識）が重要

タイトルは内容をミスリードしている。どでかい事を創造するのは、とにかくやってみる事が肝要、という楽観バイアスをタイトルから想像させるが、著者が伝えたいのはその全否定。 プロジェクトマネジャーとしてのスタンスは、著者の主張に激しく同意する。 残念だったのは、日本語訳がamateurなところ。同じ訳者の優秀な訳本を過去に読んできたので、何で？って思う。 Think Slow, Act Fast ゆっくり考え、すばやく動く 「見たものがすべて」だと、つまり必要な情報や知識がすべて手元にあると思い込んではいけない １．マスタービルダーを雇おう ２．よいチームを用意しよう ３．なぜ？を考えよう ４．レゴを使ってつくろう ５．ゆっくり考え、すばやく動こう ６．外の情報を取り入れよう ７．リスクに目を向けよう ８．ノーと言って手を引こう スティーブ・ジョブズ「私は自分がしてきたことと同じくらい、してこなかったことに誇りを感じる」 ９．友好な関係を築こう １０.地球をプロジェクトに組み込もう １１.最大のリスクはあなた

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

2025年1月25日、渋谷の試飲調査の帰り立川駅構内の書店「ペーパー・ウォール」にて。英語で海外らしい感じ、中に天才というワードも出てきてた。 ●2025年5月26日、東京大学・書籍部にあった。セッションで寄った日。 ダニエル・カーネマンがコメントよせてる。

失敗できない重要案件に関しては、じっくりと考え抜き準備し、実行は迅速に行う。小さなことの積み重ねでおおきいことを成し遂げる。の２つがポイントと理解。

大規模プロジェクトが失敗する要因と、失敗リスクを軽減するアプローチ研究を紹介。 とても「あー…」と思い当たる内容が多く、これから関わるプロジェクトには意識していこうと思うマインドセットが盛りだくさんでした。良書。

タイトルから想像するに、成功事例がたくさん書かれているのかと思いきや失敗事例とその原因やどうすればよかったのかについて触れられている。最後に勝ち筋を11つ紹介されているため、それまでの章と対比で読むのも面白いかもしれません。

やや3寄りの4。内容は良いのだが、口語チックな翻訳のせいなのか、日本語として読みづらい感あり。 デカいプロジェクトがことごとく予算オーバーやスケジュール遅れになる原因と、プロジェクトの本質が垣間見れる。 書いてあるノウハウはしごくもっともなこと。でも、そういう基本が大事なんだろうなと思う。

巨大プロジェクトを成功させる方法、失敗させる原因について 自分の仕事の経験にドンピシャで当てはまっていた（失敗することばかりやっていた）

大規模なプロジェクトほど失敗するのは、メンツや権力、早く決めたがる思考などが重なり、計画時点ですでに失敗してるから。「すでに失敗してることを公表して恥をかきたくない」から、最初の失敗はより大きな失敗へと膨らみ、もう取り返しがつかなくなる。 技術云々ではなく、人間の精神的な弱さと、一度に完璧を作るのは無理、という2つの現実を思い知らされた一冊だった。

働き方も大きく変わった今、大規模なプロジェクトは無理だなとの感覚あり、どの章も深く頷きながら読めました。

3、5章が参考になった キッチンリフォームの例が出てきてやや混乱するが、そもそもこの本は「どデカいこと=不可逆なプロジェクト」を扱っているということを念頭において読むとポイントを見逃さないで済みそう。 普段の仕事にも活きそうな内容でした。

それなりに大きなITプロジェクトに携わっていて、どうしてこんな上手くいかないんだと思って購入。客も偉そうだが別にプロジェクトを回せているわけではなかったので、どうしたものかと思っているところこの本が新刊棚に。結論としては「UNIXという考え方」にあるようなことがデータで示されており、また、実践的な予算の組み方も載っており、大変参考になった。これから参画するプロジェクトや自分のプロジェクトに活かしたいと思う

本書はあらゆるプロジェクトの企画立案から実行・完了までの指針となる教科書だ。これまで世界中で行われたプロジェクトを紐解いて、それらがなぜ成功したのか、あるいはなぜ失敗したのかを事実ベースで紹介している。筆者らが示す知見は私たちの日常生活にも適用でき、個人的な成功にも寄与できるだろう。内容はいずれも平易ですぐに読み通すことができる。

タイトルから連想する話とは読んでみて違ったけど、大きなプロジェクトを期限内、予算内に終わらせることの難しさや、最後の地球温暖化にまで言及していて読んでいて面白い本だった。

バイアスによって、当初の見積りや予測の甘さが指摘されている。 リスクにどれだけ目を向け、その軽減策を打てるか？ 特に独自性バイアス、今回は特別、他とは違う、という考えを捨てて、大きいカテゴリーに分類したときの数あるひとつ、と捉えること。 そしてその同じカテゴリーのデータを集めて、参照クラス法に基づいて、コストや期間・時間、得られる効果などを測る。 大小に関わらず、プロジェクトを進めていくにあたっての掟となる本だった。

プロジェクトマネジメント（定められたQCDに向かうこと）は大なり小なり必ず仕事や生活の中で必要とされるスキル．ビジネスパーソンは読んで損しない内容ではなかろうか． フランク・ゲーリーの美術館，ぜひ行ってみたいな． ------- だめ→素早く考え、ゆっくり動く 　→慌てて行動、ゆっくり公開 良い→ゆっくり考え、素早く動く 急がば回れが成功のコツ →ただゆっくりすればいいのではない。良い計画を立てた結果としてゆっくりになる。 →良い計画には幅広く深い"問い"と創造的で厳格な"答え"がある →問いが、答えに先行する。答えから始まることもあるがそれは失敗をまねく 考えるフェーズ→企画や設計→金がかからない、少人数→やりなおせる 成功プロジェクト事例 →エンパイアステートビルディング →必要とする梁の数までわかったうえで建築 メガインフラ、メガIT、メガイベント →筆者の研究結果によると、メガプロジェクトでQCDのすべ手を達成した事例は0.5% ファットテール分布 複雑系 ブラックスワン →系の構成要素の動的な相互作用が、非線形的反応により甚大な影響をもたらす →例　砂漠での突風によるコンテナ船のスエズ運河の封鎖 →"起こるべくして起きた事故" 最初からうまくいかないフラグ →計画と称したビジョンや願望だけの内容 →「実行」フェーズに映るだけでも人は満足。その後問題勃発 →実行に移り、前に進んでいる感、が欲しい →"タスクを計画しているときよりも、実行している方が生産的だと感じてる" 予測の失敗 →ベストケースで見積もりがち プロジェクトはそれ自体が目的であることはなく、手段に過ぎない "右から左へ考える" フローチャートをゴールから遡る形で目的の最善手段を導く →いわゆるバックキャスティング →シリコンバレーは"顧客体験"から始める →Amazonではまず顧客向けの短いPRとFAQを書く、 プランニング ピクサープランニング ズームインとアウトを繰り返す アイデアは"灰色のモヤモヤ"から始まる ビルバオ・グッゲンハイム美術館(フランク・ゲーリー) →クライアントの目的に立ち返った打ち手 →模型とCADによる綿密な試行錯誤→計画 ピクサーの映画作り 一言でわかるキャッチーなテーマ→12ページのあらすじ→脚本を入れたラフなストーリー→ ↓ 全体・最上流から始めて部分へ。 レビューを重ねまくって精緻化 実用最小限のプロダクト mvp 計画立案は試行、学習、反復を伴う能動的な活動。 静的、抽象的、形式的な行為とみなす姿勢こそが 計画立案の障壁 経験値 →人にだけ集積するものではない。モノや技術もそのたまもの →枯れた技術を使うことの良さ、先人の経験の恩恵をあやかれるから →技術は「凍れる経験」 オリンピックは分析可能な大会全てで予算を超過している 独自性バイアス →我が子を特別に思う →このプロジェクトはこんな独自性があるんだと誇張に走る →見習うべき前例から学ぶ気概が失われる →RCF法による見積もり チームビルディング アイデンティティ、目的意識、心理的安全性 →イギリスの空港ターミナル拡張PJ、T5 スモールシング戦略 モジュール性 →一つの巨大なものを作るのではなく、小さいものを積み上げる →レゴブロック、ウェディングケーキ →統計的に太陽光発電や風力発電PJは成功しやすく、原子力発電はパフォーマンスが悪い →原発は、完成しないと価値を発揮できない、経験が乏しくカスタマイズありき、ブラックスワンの影響を受けやすい →成果物の分割、工程の分割、対象の分割 スケールフリーなスケーラビリティ モジュール生があれば試行錯誤、反復、部分的な価値発揮ができる 11の法則 ・実践知の確保 ・良いチームの確保 ・なぜ？を考える ・レゴを使って作れないか ・ゆっくり考え、素早く動く ・外から学ぶ、参照クラス予測 ・リスクの列挙、対策 ・ときにはノーという。選択と集中 ・有効な関係維持 ・地球をプロジェクトに組み込む ・最大のリスクは自分自身。

個人的には面白かった。 プロジェクトを予算内・期日内に終わらせる難しさと、モジュール化（反復性）の有用性は確かにその通りと思う。 著者の推す、ゆっくり考え、素早く動くは、リスクを狭め、迅速にプロジェクトを完遂すること。 アリストテレスの言うフロネシス（実践知）を持つ人はみな、生涯を通じて自分なりの経験則を磨き改良を重ねる。 大事なのは勝つことではなく、負けないこと そのために、唯一無二のプロジェクトではなく、より大きなカテゴリーの一部として数ある一つという視点でデータを集め、参照クラス予測を立てる。 データに反映された経験から学びリスクを軽減する。そうした正確なプロジェクトへの理解が大事。

実行重視の対象を「可逆的」な意思決定に限定する。 ディッピングポイント、ファスト・スロー、超予測力読めば読まなくていい

日程や予算において、計画を大幅に超過した大型プロジェクトは、枚挙にいとまがない。 例えば、オリンピック・パラリンピック(東京でもそうだった)、原子炉(すったもんだの果てに廃炉が決まったもんじゅは、後始末を含めると60年、150億ドル以上をつぎ込み、発電量はゼロ)、東芝が原子炉でつまずいたことも該当するだろう。現在工場が進行中の大阪万博も、既に何度も予算の追加が行われ(我々大阪府民の税金が使われる)、工事が本当に間に合うのかヒヤヒヤもんだ。 本書は、このような大型プロジェクトが失敗している原因を検証し、少ないが成功事例の特徴を挙げて、プロジェクトの遂行には何が大切なのかを導いてくれる。 一般人が大型プロジェクトの責任者になることは稀だろうが、会社においては、小さなプロジェクトリーダーになることもあるだろう。 その時の心構えに役立つのではないだろうか。 ・迅速な実行を確保するために、計画立案に思慮と労力を注ぐこと。 ・プロジェクトにさらにリソースをつぎ込むかどうかを判断するには、「今現在」理に適っているかどうかだけを考えること。それまでかけたコストは考慮に入れるべきではない。 ・よい計画を生み出すのは、幅広く深い「問い」と、創造的で厳密な「答え」である。重要なのは「答え」の前に「問い」が来ること。 ・プロジェクトは、それ自体が目的であることはなく、目的を達成する手段に過ぎない。 十分な情報をもとに、「何のために、なぜやるのか」を明確に理解すること、そして最初から最後までそれをけっして見失わないことが、成功するプロジェクトの基本だ。 ・顧客がほしいと口で言うものや、ほしがると私たちが考えるものではなく、彼らが本当に求めているものが何なのかを学ぶ必要がある。そしてそれを知るためには、実験をするしかない。 ・プロジェクトの最大の障壁は、計画立案を静的で抽象的、形式的な行為とみなす、その姿勢にある。 ・人間が所有し利用できる最も有用な知識の多くは、形式知ではなく、「暗黙知(=感じとる知識)」である。 ・豊富な実践知を持つプロジェクトリーダーは、プロジェクトの最大の資産だ。あなたがプロジェクト運営者なら、そんなリーダーを雇おう。 ・よい計画は経験または実験を最大限に活用し、優れた計画は経験と実験の両方を最大限に活用すること。そして最高の計画とは、経験と成功経験を持つプロジェクトリーダーとチームによって、実験を最大限に活かして立案され、実行に移される計画だ。 ・チーム員でアイデンティティと目的意識、基準を共有すること。プロジェクトの関係者全員が、発言する権利と責任を持っていると感じられるような環境を整えること。心理的安全性は重要だ。 トーマス・エジソンの次の格言は、救いになる。 「1万回失敗したのではない。うまくいかない方法を1万通り見つけるのに成功したのだ」

大きなプロジェクトを計画通りやり遂げるための考え方、方法について書かれた本。 基本的なことばかりではあるが、基本の積み上げこそ物事を成し遂げるために重要であると改めて認識できたのが良かった。 最後に著者が11の経験則をまとめているが、この中でも特に大事だと思った事を上げておきます。 マスタービルダー(実績のあるプロ)を雇う 良いチームを用意する レゴ(小さなもの)を使ってつくろう ゆっくり考え、すばやく動こう 外の情報を取り入れよう ノーと言って手を引こう 地球(社会的課題)をプロジェクトに組み込もう 最大のリスクはあなた

大規模プロジェクトがなぜ予算超過や期限超過が常態化しているのか、どうやれば成功するのか、膨大な事例の研究から導き出す力作。面白かった。 ざっくり言うと、 ・時間をかけて計画し、その上で素早く作る。 ・計画段階でトライアンドエラーして、不確定要素を取り除く ・成果物をモジュール化して、繰り返し作業で拡張出来るようにする みたいな感じ。 建築についての事例が多いので、IT屋としては、現場への応用に若干悩むところ。 なお、モジュール化に関しては、若干著者の思想が入っているかな。反原発・再生可能エネルギー推進派なのかな？　思想に対してどうこう言うつもりはないけど、なんか最後の方の文章がそれまでと違うテイストになったのに違和感があったので、記しておく。

・大抵のPJは失敗する。しかも想像以上のコスト増、納期増で。 ・走りながら考える、は失敗する。そうならないために必要なのは企画。実行の前のコストがかからないタイミングで熟慮。 ・ピクサープランニングのように何度も試す。MVPも基本的には同じ。 ・バックキャストが大切。why。 ・実行のポイントは経験者のチームを組むこととモジュール化。

HOW BIG THINGS GET DONE: The Surprising Factors That Determine the Fate of Every Project, from Home Renovations to Space Exploration and Everything In Between しくじり先生とプロジェクトXみたいな事例がたくさん載っていて興味深い。そして失敗事例で思い当たることが多すぎる笑笑。

感想 まずは考える。完璧だと思えるプランを組み立てる。一から作る必要はない。これまでの経験の中から使えるパーツを探す。それから動く。

始める前から勝負を決めておく はじめてから突然悪くなったりどんどん悪くなることはない、始める前から悪くなっている 勝てる環境が整ったら始める まずは勝てる環境を整える

ビッグプロジェクトを成功させるためには、「ゆっくり考え、素早く動く」ことが大切。 コストの過小評価と便益の過大評価を行わないようにすること、チーム作りはコストをかけて心理的安全性を高めることをしていく。