良書だった、プロジェクトベースの仕事に関わっている人に一読をお勧めしたい。リーン・スタートアップへのアンチテーゼ的な書籍かと思って読み始めたが、そうではなかった。やり直しの効かない原子力発電とかダム建設のようなプロジェクトにおいても、成功させるためのアプローチの根本は同じであった。
以下、読書メモ。
「綿密な計画がカギ」
リーン・スタートアップの発想に立つと、MVPをリリースして顧客の反応から学習することが重要になるが、これはソフトウェア産業に特有なものである。建築など多くの巨大プロジェクトは実行フェーズに入ってしまったらやり直しは効かない。（建物を建てて顧客の反応を見て、建て直すことはできない。）
ただ、どのようなプロジェクトでも計画フェーズにおいて、実験と経験学習が可能である。例えば建築であれば模型やソフトウェア上での制作は可能であるし、映画撮影であればシナリオやラフスケッチ段階でのレビューができる。こういった試行もコストがかかるものであるが、実行フェーズにおける修正に比べれば微々たるものである。「実用最小限のプロダクト」が無理ならば「仮想最大限のプロダクト」を試すといい。
「すばやく考え、ゆっくり動く」に陥りがちなのは、「慎重に考えるよりも早く一つに決めたい」、「最初に浮かんだことに固執してしまう」、「複雑な事象を実際よりも正確に理解していると錯覚」等の人間の習性があるから。また、承認を取るために意図的に計画を小さく見積もる戦略的虚偽表明などの政治的な動きもある。
「自分は何を達成したいのか？」をじっくりと考えてて、早く着手したい衝動を抑える必要がある。常にバックキャスティングで物事を考えることが重要。
「スモールシング戦略」
1つの大きいものを作るのは、標準の既製品は使えず、カスタム多く、前例も使えず、複雑化。巨大だと「完成」するまでお金を生まない。時間が長く、ブラックスワンにさらされる。
素早く作るための最適解は「多くの小さいものを作ること。」小さいものは単純であるし、反復により学習ができる。「このプロジェクトの基本の構成要素は何だろう？何度もくり返しつくるうちに、スキルと効率を高められるものは何だろう？」と考えることが重要。反復をあえて埋め込む、ブロックのように組み立てられないかを考える。
ソフトウェアにおいては同じものを繰り返し作るという分解はしづらいので、どのような単位で分割していくのか、が肝になりそうだ。自分の過去の経験においても、大きなプロジェクトにおいても機能単位の小さい単位で高頻度にレビュー、設計が固まった部分から実装を進める手法においてはチームメンバーの意思疎通も高速化し、プロジェクトが高速化したこと経験がある。
ごく当たり前のことを論じているようにも思えるが、大きな組織や利害関係者が多いプロジェクトにおいては実践が難しい。この発想がより多くの人々に広がるとよいのではと感じた。
また捉えようによっては、大きなプロジェクトに限定されず仕事の進め方全般にも応用できる考え方であり、勉強になる書籍だった。