「システム開発プロジェクトで、進捗をきちんと守ることなんて到底無理ですよ。いいシステムを作ろうと思うほど、進捗が遅れるんですから。雑誌作りだって同じでしょう？」。

　日経SYSTEMS 2010年8月号で「進捗遅れをなくそう」という特集を担当するにあたり、懇意にしているITエンジニアのAさんに相談したところ、特集の意義を真っ向から否定された。

　記者は言葉に窮した。自分で言うのも何だが、記者は進捗（締め切り）遅れの常習犯である。自分のことを棚に上げて、システム開発プロジェクトの進捗遅れに意見する資格はない。

　それでも、一点思うところがあったので指摘した。経験的に言って、進捗を遅らせたほうがいい記事になるとは限らない、ということだ。むしろ進捗通りに進んだときのほうが、記事の出来はよいように思う。

　記者の指摘に対し、Aさんは「システム開発でも同じかもしれない」と答えた。単純な話、進捗を守ると余裕期間を終盤まで温存できるので、テストや修正に時間をかけられる。いいシステムを作るためには、進捗遅れをなくす努力が欠かせない。結果的に、Aさんは特集の意義を認めてくれた。

原因は見積もりと要件定義だけでない

　こうして特集に取りかかったものの、いきなり根深い問題に突き当たった。プロジェクトの進捗が遅れる大きな原因は、見積もり精度の低さや要件定義の不備にあるというのだ。どちらもすぐに解決できるものではない。

　ほかに突破口はないのだろうか。思案に暮れつつ、取材を進めた。すると、解決の糸口が見えてきた。

　きっかけとなったのは、「あの人が担当したプロジェクトは遅れない」と周りから評されるプロジェクトマネジャーへの取材である。そういうプロジェクトマネジャーは例外なく、見積もり精度の低さや要件定義の不備のほかに、進捗遅れの大きな原因を三つ指摘した。

　一つ目は、プロジェクトマネジャーが進捗遅れをなかなか発見できないことだ。メンバーからの進捗報告は「9割は終わった感じです」といった感覚的なものが多く、仕掛かり中の工程やタスクの進捗状況を正確につかめない。対策としては、進捗遅れの先行指標となる情報（残業時間の増加など）を収集することなどがあるという。

　プロジェクトの課題が放置される、というのが二つ目の原因である。プロジェクトで次々と発生する課題は一般に課題管理表で管理する。この管理表の運用が形骸化することが少なくない。課題管理表をフルに活用し、迅速かつ確実に課題を解消することが求められる。

　三つ目の原因は、チームメンバー一人ひとりの進捗遅れに対する意識が必ずしも高くないことである。特に進捗遅れが常態化し、「遅れているのは自分だけじゃない。何とかなるだろう」という雰囲気が蔓延したときが危険だという。

　こうなると、プロジェクトマネジャーがいくら口を酸っぱくして進捗を守るように訴えても、受け流されてしまう。チーム全体で危機感を共有することが重要になる。