高速鉄道や巨大建築物といった大きなプロジェクトのなかでは、成功するものもあれば失敗するものもある。 それはなぜか、という問いに経済地理学者で、オックスフォード大学とかコペンハーゲンIT大学で教えているプロジェクトマネジメントの研究者が答えた本*1
データから巨大プロジェクトの失敗率を調べて、事例で失敗と成功の差を描いていて読んでいておもしろい。地下鉄や巨大建築物のノウハウが仕事にすぐ参考になるとはあまり期待はしていなかったけれど、意外と役立ちそう。
ノウハウとして、ピクサーの映画撮影では、脚本をつくってから簡単な絵コンテで通してつくってスタッフで声もあてて内部で通してみてからシナリオを修正する、というループをたくさんまわすことで、実制作の手戻りを避けているとか、ビルバオ・グッゲンハイム美術館をつくったフランク・ゲーリーは設計を3D CADでつくって試行錯誤・検証してから建築を開始することで施工中のトラブルをなくしている（そうしないことで失敗したのはシドニー・オペラハウス）といった、しっかり計画する、そして素早く実行するということの重要さが映画でも建築でも同じような手法をとっていることに感心した。
そして、プロジェクトの失敗率の高さと、失敗時の損失の大きさ（ファット・テールと表現していた）はやっぱり大きい。システム開発プロジェクトを見慣れていると、よくあるよね、と思っていてもやっぱりたいへん。国家プロジェクトでは見積もりを小さく見せたい政府の意向で失敗率もさらに増えてしまうという問題もある。
中でもITプロジェクトのリスクの高さは、ほかのプロジェクトと比べることで改めて驚かされる。巨大な建築物や航空宇宙プロジェクトにも匹敵しているのは衝撃的だ。
このITプロジェクトについてはあまり深堀りされていないけれど、スタートアップについてはエリック・リースの「リーン・スタートアップ」をひいて計画の重要さにふれている。最終成果物がみえないなかで、実験し学習しながら探索的にプロダクトをつくっていくというのも広義の計画だという。生成AIで開発自体がはやくなっている現在、より重要かもしれない。
エリック・リースは、スタートアップの置かれている環境が「とてつもなく不確実」なため、開発したプロダクトが市場に受け入れられるかどうかを事前に知ることは不可能だと指摘する。 「顧客がほしいと口で言うものや、ほしがると私たちが考えるものではなく、彼らが本当に求めているものが何なのかを学ぶ必要がある」と彼は書いている。そしてそれを知るためには、「実験」をするしかない。
そして、これは、シリコンバレー的プロジェクトだけではなく、アポロ計画のような巨大プロジェクトで、ロケットを周回軌道にのせる、乗組員が月着陸船に移動する、着陸船と母船をドッキングする、といったステップをひとつひとつ検証したことと通じているという。
ほか、おもしろエピソードとして、イギリスで高速鉄道をひくときに、工事中に歴史的遺物がでて計画が遅れることの対策として、事前に専門の考古学者全員と顧問契約を結んだというのがよかった。安くはないけれど、プロジェクトを中断するコストに比べればずっと安くすみ理に適っていたという。そしてイギリス史上最大級の考古学プログラムとして大々的に宣伝し、イメージアップを実現したというのもよい。
読んでいての疑問としては、東海道新幹線や東京タワーといった、高度経済成長期の巨大プロジェクトはなぜうまくいったのか、というものがある。 もめがちな土地確保リスクが少ないとか、環境リスクアセスメントをまったく気にしていなかったとかはあるだろうし、黒部ダムのように今より命が安かったというもあるかもしれない。戦争を経験していた技術者が多かったこととかもあるだろうか？
最近だと、中央リニアや北陸新幹線延伸はかなり厳しそう。これはプロジェクトマネジメントというよりも、土地制約のなかでの地中掘削の限界とも感じるし、この本のノウハウがったとしてもどうあるべきだったかはわからない。 いっぽう、大阪関西万博は、なんとかかろうじて間に合って結果的にある程度は成功したけれど、開催にこぎつけるまでのプロジェクトマネジメントがどうだったのかは知りたい（まあ訴訟リスクなどもあるだろうので公開されることはしばらくはないかもしれないけれど）。
最後、巻末にあった11のコツを引用する
１「マスタービルダー」を雇おう
マスタービルダーとは、中世ヨーロッパの大聖堂を建設した熟練した棟梁に与えられた称号とのこと。これが一番重要とのこと。経験には価値がある。 しかし人はどうマスタービルダーになるのだろう。マスタービルダーのもとで経験を積むのがよいのだろうけれど、そういう観点で職場を選ぶのはよいかもしれない。
２「よいチーム」を用意しよう
マスタービルダーと一緒に仕事をしてきたチームが一番とのこと。それはそうなんだけど・・・
３「なぜ？」を考えよう
プロジェクトの目的を明確にする。新技術の検証なのか、既存資産の利用なのか、そうではなくて顧客の体験なのか。手段にこだわるとつらいプロジェクトになるというのはわかる。
４「レゴ」を使ってつくろう
モジュール化し分割することでリスクを減らせる。ヒースローのターミナル5や、中国のコロナ病棟など。
クルミドコーヒーの影山さんの「ゆっくり、いそげ」を連想した。かなりいい本だと思ったけど内容全く覚えていない・・・、また読み返そう。
５ ゆっくり考え、すばやく動こう
計画時点で試行錯誤し、実行は早く。実行が長いとそれだけリスクにさらされるとのこと。ただ、これはそれはそうだけど、だれもゆっくり実行しようとは思っていないのでは・・と思った。
６「外の情報」を取り入れよう
みな、自身のプロジェクトをユニークだとは思うけれど、近いプロジェクトはあるはずでそれにかかったコストを調べることで見積もりの精度はあがる、ということ。 しかし内製するITプロジェクトで費用や期間を集計するのはたいへんだ・・・。
７「リスク」に目を向けよう
はい
８「ノー」と言って手を引こう
ITプロジェクトマネジメントの重要な方法論。
９「友好な関係」を築こう
問題が起きていないうちから関係者たちとリレーションをつくっておくことで、いざというときに助けてもらう
10「地球」をプロジェクトに組み込もう
はい
11 最大のリスクは「あなた」
楽観主義と自信過剰に注意しなければ・・・
プロジェクトマネジメント本としては大昔にNASAの本を読んだのもおもいだした。 巨大プロジェクトを常勝させる組織力・人間力・技術力を身につけたいものです（しかし巨大プロジェクトは心身に悪い・・・）
