1.2 なぜプロジェクト管理が必要か｜手戻り費用の話

第1章 1.2 ← 1.0 プロジェクト管理とは

なぜ管理するのか——手戻りの費用は、気づいた工程で決まります

「管理なんてしなくても、優秀な人が集まれば回る」。これは半分は本当です。優秀な人が集まれば、多くのことはうまくいきます。それでも予定が崩れるときの崩れ方には、決まった形があります。この記事は、その形を説明します。

同じ間違いでも、費用は工程で変わります

ある機能の仕様に、関係者ふたりのあいだで食い違いがあったとします。この食い違い自体は、大きいものでも珍しいものでもありません。問題は、それがいつ表に出るかです。

要件定義の段階で気づけば、打ち合わせを1回開いて、資料を書き直せば終わりです。詳細設計まで進んでいれば、設計書を直し、影響範囲を調べ、関係者に説明することになります。製造以降なら、作ったものを直し、テストをやり直し、場合によっては納期を再交渉します。本番稼働後なら、そこに利用者への案内とデータの修正が加わります。

間違いの中身は最初から最後まで同じです。変わっているのは、気づいた時期だけです。

手戻りは、例外ではなく常態です

これは理屈の上の話ではありません。ROUTE06が2025年10月にIT関連職325名を対象に実施した調査では、85.2%が「半数以上の案件で手戻りが発生している」と回答しています。同じ調査で、要件定義における最大の課題として属人化を挙げた人が50.8%、要件の書き方のばらつきを挙げた人が54.5%、成果物と仕様の乖離を挙げた人が44.9%でした。

つまり手戻りは、運が悪かった案件で起きる事故ではなく、多くの現場の標準状態です。そしてその引き金の多くが、上流での言葉の食い違いにあります。

この事実は、管理の目的をはっきりさせてくれます。手戻りをゼロにすることは目標になりません。手戻りが起きる工程を、少しでも左に寄せることが目標です。

崩れるときは、突然ではありません

予定が大きく崩れたプロジェクトを後から振り返ると、ほぼ必ず同じことが分かります。誰かは、かなり前から気づいていたのです。

気づいてはいたが、言わなかった。理由はいろいろあります。まだ確信がなかった。取り返せると思っていた。定例の場で言い出す雰囲気ではなかった。上長に持っていくほどの話ではないと思った。他の人も気づいているはずだと思った。

この「気づいてから言うまでの時間」こそが、プロジェクトが壊れる場所です。実際の作業ミスよりも、この沈黙のほうがずっと高くつきます。二日の遅れは二日で済みますが、二日の遅れを一か月黙っていた場合、その一か月ぶんの誤った前提の上で他の人が作業を続けてしまいます。

日本の現場でいちばん効くのは、言葉を揃えることです

上流での食い違いの多くは、技術的な難しさから来ていません。同じ言葉を、ふたりが別の意味で使っていたことから来ています。

「完了」がそうです。開発側は「動くようになった」を完了と呼び、依頼側は「業務で使えるようになった」を完了と呼びます。「対応します」もそうです。言った側は「検討します」のつもりで、聞いた側は「やってくれる」と受け取ります。「顧客」「本番」「暫定」「一次リリース」——どれも、確認せずに三か月進める材料になります。

ここで効くのが、日本の現場に元からある道具です。議事録は単なる記録ではなく、合意の範囲を確定する文書として機能します。だから、あとで揉めそうな言葉ほど、議事録の中で具体的に書き換えておく価値があります。「移行完了」ではなく「移行後3営業日、業務が止まらずに回ること」と書いておけば、そこで一度確認が入ります。その場で30秒、あとで三週間の差になります。

もうひとつ、実務的に大きいのが決裁の速さです。稟議が2週間止まっているあいだ、チームは推測で作業を続けます。推測が外れれば手戻りになります。承認待ちは「何も起きていない期間」に見えますが、実際にはリスクが積み上がっている期間です。だから、止まっている承認は課題として扱うべきものです。

管理を増やすことが答えではありません

ここまで読んで「では管理を厚くしよう」と考えるのは、たいてい逆効果です。報告資料を増やし、会議を増やし、細かい進捗率を集め始めると、現場の時間が削られ、報告のための報告が生まれます。数字は毎週きれいに揃うのに、実態は何も見えていない、という状態はよくあります。

効くのは量ではなく、どこに効かせるかです。上流に薄く効かせるほうが、下流に厚く効かせるより安くつきます。要件定義の段階で言葉を揃える30分は、テスト工程での3日を防ぎます。この非対称性が、第1章でいちばん覚えて帰っていただきたいことです。

ABではこう見えます

「早く気づく」を仕組みにするには、気づいたことを置く場所が必要です。AB Projectsでは、まだ起きていない懸念も課題として登録できます。「この認識、合っていないかもしれない」という段階のものを担当者と期日つきで置けるので、確信が持てるまで黙っている必要がなくなります。

言葉を揃えるほうは、プロジェクトWikiが向いています。「このプロジェクトでの『完了』の定義」を1ページ書いて、関連するタスクから参照しておけば、途中参加の人も同じ意味で使えます。議事録も同じ場所に置けるので、「あのとき何と決めたか」を探す時間がなくなります。

このページで使った言葉

手戻り

先の工程に進んだあとで前の工程に戻ってやり直すことです。工程が進むほど、戻る距離が長くなり費用が上がります。くわしく →

要件定義

何をつくるのか、どこまでやるのかを決めて文書にする工程です。ここでの曖昧さは消えず、必ず後工程で費用に変わります。くわしく →

課題管理表

すでに起きている問題を、担当者・期限つきで一覧にした表です。まだ起きていない懸念を扱うリスク管理表とは分けて考えます。くわしく →

議事録

打ち合わせの記録ですが、日本の実務では合意内容を確定する文書として扱われます。あとで解釈が割れたときの拠りどころになります。くわしく →

属人化

特定の人しか分からない・できない状態になっていることです。その人が抜けた瞬間に止まるため、進捗が良く見えていても危険な状態です。くわしく →

エスカレーション

自分の権限で決められないことを、決められる人に上げることです。遅れるほど選べる手が減るので、早さがそのまま価値になります。くわしく →

あわせて読みたい