巨大プロジェクトの成否を分ける要因はなんなのか、多数のプロジェクトを分析した結果をまとめている。ソフトウェアに限らず、全てのプロジェクトのリーダーや責任者、意思決定者が読むべき一冊。 最終章にここまでのまとめが記載されている。その中で自分が気になったところをピックアップ。
マスタービルダーを雇おう、良いチームを用意しよう
深い専門知識をもち、プロジェクトを成功に導いた実績のある人、マスタービルダーを雇う。また、マスタービルダーが選んだ優秀なチームを雇う。
経験というのは軽視されがちである。国際的な事業で、経験のない国内の事業に発注するのようなことは政治的にはありがちだが、普通に考えると経験のない会社や人に任せるのはリスクでしかないことがわかる。
「なぜ？」を考えよう
プロジェクトを始める前に、プロジェクトの目的（なぜ）を考える。プロジェクト自体が手段であるのだから、プロジェクトが存在するためにはその目的がなければならない。目的が手段になっていることが往々にしてある。目的が共有されていないと、実行フェーズで進めるとあれもこれもと追加でやりたいことが出てきてしまい、コストが超過してしまう。
「レゴ」を使って作ろう
レゴが小さなブロックを組み合わせて大きな作品を作れることのように、モジュールで分割し、小さいものを繰り返し開発して大きなものを作る。 繰り返し開発できりうと学習を重ねることができ、品質向上とスピード向上を実現できる。
ゆっくり考え、すばやく動こう
政治的な判断で十分検証がなされずに始められたプロジェクトほど失敗する確率が高い。
計画段階で検証して詳細な計画を作る、そして実行は迅速に可能な限り早く終了できるようにする。 期間が延びれば延びるほど問題発生のリスクが高まる。
計画では、机上の計画だけではなく、プロトタイプなどを作って計画にフィードバックをする「行動」を備える。
Amazonでも意思決定を高速に行うために担当に意思決定権を持たせているが、それもOne Way Doorかどうか、可逆的な決定かどうかでプロセスが異なる。後戻りできるような決定は担当者レベルでさっさと進めてしまうが、後戻りできないような決定の場合は上位上司や経営層を含めて慎重に意思決定する。
「外の情報」を取り入れよう
自分のプロジェクトが数ある中の一つという視点を持ち、参照クラスを使って予測を立てデータに基づいて予測する。参照クラスというのは自分のプロジェクトと似たようなプロジェクトの情報である。つまりは、自分のプロジェクトは特別と言って独自の予測をするのではなく、過去の類似プロジェクトの数値をもとに予測するということ。
「リスク」に目を向けよう
リスクにはキャリアを破壊する威力がある。過去のプロジェクトからリスクを特定して軽減する。
多くのプロジェクトは正規分布ではなく、裾野の長いファットテールのプロジェクトである。つまり当初見積もりの数倍ものコストを生み出す可能性がある。ITプロジェクトもファットテールである。このテールを切り落とすためのリスク管理が、過去のプロジェクトを分析して、リスクを特定して軽減するというもの。
