ベント・フリウビヤ、 ダン・ガードナー著「BIG THINGS どデカいことを成し遂げたヤツらはなにをしたのか？」 の感想メモです。
サブタイトルに「どデカいことを成し遂げたヤツらはなにをしたのか？」とあるが、巨大プロジェクトの自慢話が書いてあるわけではない。どちらかというと、巨大プロジェクトが如何に失敗しているのか、というのを分析した話である。サブタイトルの付け方に失敗して対象する読者層が間違っているような気もするのが、いわゆる、行動経済学を応用したプロジェクトマネジメントの話になる。
まだ第１章とちょっとを読んだばかりだけども、面白そうなのは確かなので記録を残しておこう。ツイッターだと、消えてしまいそうなので。
参考文献と論文
巻末には参考文献と著者らが書いた論文集が載っている。なので、通常のビジネス本とは違い、なんらかの根拠がある（あるいは偽根拠があるｗ）ことが示されているので、それらの文献にあたれば数々の発言の再現を確認できるだろう。
Full article: The Empirical Reality of IT Project Cost Overruns: Discovering A Power-Law Distribution https://www.tandfonline.com/doi/full/10.1080/07421222.2022.2096544
ファットテールの図などが載っているメインとなる論文だろう。
フィッティングする数式もある。が、果たしてこれが過剰なフィッティングでしかないのかは分からない。参考にしたプロジェクトは1万件を超えるのでサンプリングとしては十分である。そのデータも公開されているらしい。
第1章は序章
第1章は、いくつかの具体的なプロジェクトの例に過ぎない。「ゆっくり考えて、素早くはじめる」という（たぶん）「ファスト＆スロー」の中に書かれている内容の追随になっていると思う。
これは第１章を読んだばかりだけど
- 失敗学
- 「アジャイルな見積もりと計画づくり」
- 「失敗の本質」
あたりが思い浮かぶ。
実は、10年前だったか CCPM を知って、ITプロジェクトに応用しようとして、そのテールの分布を計算していた時期がある。ほぼ同時期（自分より2,3年前になるが）コーン氏が同様のことをやっていて、テールの部分を数式化してマネジメントソフトウェアとして販売していたという実績がある。しかし、現在の彼のサイトを見ると解るが、このソフトウェアはない。実は開発会社はつぶれていて（あまり売れなかったのだろう）、今では小さな？コンサル会社になっている。この手法だが、マネジメントソフトウェアにしてもあまり意味がない。属人性が強すぎるので、テールの分散が広くPM個人に依存してしまうからだ。私個人の経験でも、大きく失敗しないPMは、常に大きく失敗しない個人的な手法を持っている。これは20年著っとの個人的な経験で幾人か知っている。逆に、大きく失敗するPMは常に失敗する。
失敗するPMがあまり顕在化されないのは、一度失敗してしまった（大きく赤字になってしまった）PMはこの業界から一瞬で消え去ってしまうか、あるいはこの著作のように「大きなプロジェクトを任された」という実績にて、次のプロジェクトに参画するためだ。失敗学的な「失敗」を定義されないまま、別の会社のプロジェクトに組み込まれることが多い（いわゆる根性があるとか最後までやりぬくとか体力があるとか、あるいは権力に従うとか）ので、プロジェクトを失敗させやすいPMは常にプロジェクトを失敗させる可能性を含んでいる。
この部分、「BIG THINGS」に書かれているかはわからないのだが、文化的な進化論のひとつである。第2章以降を読み進めるとわかるかなと。
第2章以降は行動経済学に沿う
第2章以降は、行動経済学の各ナッジについて解説することになる。行動経済学が眉唾だと思う人にはちょっと向かないかもしれない。ちょっと言い過ぎ（都合のよい事象を出し過ぎ）な感もあるが、リチャード・セイラー著「実践行動経済学」を読んでいれば大丈夫だろう。
各種の決め台詞っぽい名づけ（「コミットメントの錯誤」とか「戦略的虚偽表明」とか）に引き付けられる向きもあろうが、ここは眉唾してスルーしておくのがベターだ。具体例は、各論文にでてくるだろうから。
「要求仕様の探求学」では、要件定義工程での品質の作り込み（品質の上げ方）の手法が書かれている本である。結構古いのとウォーターフォール開発の頃の著作なので、昨今のアジャイル開発では向かないが、最近の反アジャイル思想の中で、開発途中では品質は上がらない、というような話がでてきたときには「要求仕様の探求学」を出してみるとよい。G.M.ワインバーグの著作である。まずは、「品質とは何か？」をきちんと定義してから、議論してみるのがよい。
2000年頃のITプロジェクトは確実に他業界よりも遅れていたのだが、本書をみていくとプロジェクト進行に関してはITプロジェクトは追いついている印象を受ける。むしろ、2002年から始まるアジャイル開発のノウハウが本書の各章にでてくる。
現時点（2024年時点）で、ITプロジェクトでは成功と失敗（みずほ銀行、COCOAの失敗、ガバメントクラウドの失敗…途中？）の差は大きく、大規模プロジェクトや官庁プロジェクトの失敗が目をひく。で、当たり間のことだが、失敗プロジェクトを見習いたいわけではなく、成功プロジェクトの秘訣を（あるいはプロジェクトを失敗させない要素を）ピックアップしておきたい。
- 第2章の「早く決めたい衝動」については、アジャイル開発により、まず手を付けてプロトタイプを顧客に見せるという手法がITプロジェクトでは可能になっている。ゆえに、全体を決めなくても、最初の一歩を踏み出すほうがITプロジェクトでは良い。ただし、その後は最初のプロトタイプに縛られない工夫が必要である。官庁系のプロジェクトで大きく失敗するのは、ここの「熟考のし過ぎ」あるいは「官僚の作る５か年計画に縛られる」に原因がある。
- 第3章の目標をはっきりとさせるは、PMBOKにおけるプロジェクト計画書やプロジェクト憲章にあたる。CCPMでは、目的から各タスク（WBSでもよい）を導き出して無駄なタスクを作り出さない手法がある。本書では「フローチャートを「逆」から埋める」という書き方がされていて、「バックキャスティング」という用語を使う。
- 第4章は、いわゆる設計で使う「ポンチ絵」のことであり、システム構成図であったりシステム概要であったりする。試作品を作り「イテレーション開発」を行うことを勧めている。
- 第5章と第6章お場合は、経験から学ぶことと、過去のプロジェクトから計画見積もりをすることを示している。ITプロジェクトでは、PDCAやファンクションポイント法などの見積もり法がある。ファンクションポイント法は今はほとんど使われていないが、過去の似たプロジェクトを参考にしながら目の前のプロジェクトを試算するのはIT業界では普通に行われている。おそらく建築業界よりもプロジェクトの単位が短くなった（WEBプロジェクトでは2,3か月というのがざらである）ので、進化のサイクルが早くなったと考えられる。
- 第6章で、マイルストーンではなくインチストーンの提案をされているが、アジャイル開発あるいは最近のITプロジェクトでは「チケット駆動」という形でインチサイズの「チケット」が使われる。スクラム開発のバックログがそれにあたる。
- 第7章は、アジャイル開発の手順そのものである。
- 第8章のチーム作りに関しては、「ピープルウェア」がある。本書でも「リーン開発」が言及されている。また、IT業界で流行っている「心理的安全性」≒テスト駆動などの手法がある。
- 第9章は、IT業界が得意とするモジュール化やコンポーネント化の話になる。マイクロサービスやAzure FunctionsやAWS Lambda のサーバーレス技術もそれにあたるだろう。WEB API もこれにあたる。「反復開発」なんて当たり前のようにやっている。
という訳で、残りは「終章」しかないのだけど、BIG THINGSの本に書いてある内容は「行動経済学」がベースになっているわけだが、その現実的な手法としては「アジャイル開発」のさまざまな手法あるいはここ2000年以降のITプロジェクトが培ってきたノウハウや経験に等しいことが伺える。
まあ、それでもみずほ銀行のシステム統合や遅々として進まないガバメントクラウドやデ庁のしぐさもあるわけで、ITプロジェクトだからといって成功するわけではない。ゆえに、失敗プロジェクトに身を投じないだけの思慮をプロジェクトリーダーやマネージャは必要とされていると私は考える。
ちょっと興味深いので、ダニエル・カーネマン著「ファスト＆スロー」を読んでから、また追記しよう。
