「プロジェクトの成否はキックオフの時点で決まっている」と2008年1月号特集では書いた。実はあの表現は半分正しいが，半分は間違っている。計画は必ず破綻する。キックオフの時点で予期しなかった出来事は必ず起こる。大事なことは，精緻な計画を立てることではない。計画が破綻してなおプロジェクトをうまくいかせることを目指すべきなのだ。それには，途中で計画を組み替えればよい。スケジュール，体制，マネジメント，スコープ――を適切なタイミングで，適切な形に組み替えればよい。

　これは「日経SYSTEMS」という雑誌で温めていた特集「プロジェクトを組み替えよう」の企画書の冒頭である。これを編集会議にかけて，皆の意見をもらい，2008年の半ばくらいに実現できないかなと目論んでいた。ところが，今年になって日経SYSTEMSの編集部からITpro編集部に異動になり，この企画は日の目を見ることなく埋もれてしまっていた。

　この企画は，何となく思い付いたものではない。

　日経SYSTEMSの2008年1月号で「プロジェクトの基盤を作ろう」という特集を掲載し，プロジェクトが始まる前の準備とキックオフの重要性を訴えた。同じく2007年3月号では「プロジェクトの記録を残そう」という特集で，プロジェクトが終わった後の完了報告書を通じたノウハウや教訓の残し方を探った。いずれも，読者から非常に高い評価と反響を頂くことができた。こうしてプロジェクト開始前と完了後のテーマを追求して，あと残っていたのがプロジェクトの最中の話であった。それは「組み替える」というキーワードで語れると思うのである。

　日経SYSTEMSという雑誌は，開発の現場に密着した雑誌である。取材する相手も読者の多くも，ツールやシステムを相手に現場で手を動かしている担当者である。そのあたりが，取材先や読者にマネジメント層が多い日経コンピュータや日経情報ストラテジーと大きく違う。私はその雑誌（前身である日経システム構築，日経オープンシステムを含む）で6年間，記者として働いた。その6年で取材先の方に見せてもらったドキュメント類は，数えていないから正確には分からないが，100種類は超えていると思う。

　たくさんのドキュメントを見て感じることは，プロジェクトは計画通りにはいかないものだということだ。スケジュール表の右肩に「Ver.○○」とあったり，体制図には「○月○日改訂」と書かれていたりする。キックオフから稼働までの間に，何回かの組み替えを経ていることを意味している。「途中で事情が変わって，計画を練り直したんです」といったコメントは何度となく聞いた。

　「どういうタイミングでプロジェクトの組み替えを判断するのだろうか」「どういう観点でプロジェクトの組み替えを実施するのだろうか」というのが，私の興味である。デスマーチの火を消すために，あるいはデスマーチに陥る一歩手前のプロジェクトを正常な状態に戻すために何をどうすればよいか。PMBOK（プロジェクトマネジメント知識体系）ガイドを読み込んでも，なかなか具体的にはイメージできない。

　冒頭の企画書はこんなふうに続く。

Part1　問題提起「計画書は最後までドラフト」
　×プロジェクトが硬直している
　×組み替えのタイミングが適切でない
　×組み替え方が間違っている

Part2　現場の組み替え術
　(1)スケジュールを組み替える
　(2)体制を組み替える
　(3)マネジメントを組み替える
　(4)スコープを組み替える
　(5)人材育成を組み替える

Part3　破綻の予兆を示す10のサイン
　組み替えのタイミングを見極める。

　実は，この企画書を最近，日経SYSTEMS編集部に所属する30代のN記者に託した。N記者は以前「プロジェクトの火消し術」という特集を執筆したことがあり（関連記事），この分野に興味と知識を持っている。編集部にはそれぞれ独立した意思決定があるから，その企画を彼がどうするか，編集部としてどう判断するかは私の関与できるところではないし，無理強いするつもりもない。今は一読者として，掲載の方向で動いてくれないかなとだけ思っている。