誰もが「順調です」と言う会議の違和感
週次の進捗会議で全員が「順調です」「予定通りです」と報告する。WBSを作って各タスクの担当者も決めた。進捗率も毎週更新している。それなのに、なぜか不安が拭えない。そして案の定、終盤になって「実は間に合いません」という報告が上がってくる。
私はPMOとして10年以上、複数のプロジェクトでスケジュールマネジメントを担当してきましたが、この「順調報告の中に隠れる遅延」を何度も目撃してきました。スケジュールマネジメントの本質は、遅延が顕在化してから対処することではなく、遅延の兆候を早期に察知することにあります。
中堅企業のPMやPMOの方々とお話しすると、「WBSは作ったけど、結局進捗管理に活かせていない」という声をよく聞きます。ExcelでWBSを作り、毎週進捗率を更新し、ガントチャートで可視化しているのに、なぜスケジュール遅延を防げないのでしょうか。
私はPMOとして10年以上、複数のプロジェクトで進捗管理を担当してきました。特に印象深いのは、ある100名規模の公共インフラ会計システム再構築プロジェクトです。WBSを丁寧に作成し、山積み表で工数を可視化し、毎週の進捗会議で数字を追っていました。にもかかわらず、プロジェクト中盤で『順調』と報告されていたタスクが実は50%も進んでいないことが発覚。原因は、報告者が『来週の会議までに追いつけば問題ない』という感覚で報告していたことでした。そこから私は『数字ではなく、成果物の実物を見る』運用に切り替え、週次で必ずコードや設計書のレビューを実施。すると本当の進捗が見えるようになりました。スケジュールマネジメントは『数字を集める』だけでは不十分で、『成果物を見る』ことが本質だと学んだ経験です。
この経験から私が学んだのは、WBSを作ること自体がゴールではなく、WBSを使って「何を見抜くか」が本質だということです。順調報告の裏側にある危険信号を、どうやって察知するか。それが今回のテーマです。
WBSがあっても進捗が見えない現場
多くの現場で、WBSは「作業の分解図」として存在しています。大項目、中項目、小項目と階層化され、各タスクに担当者と予定日が設定されている。一見、完璧に見えます。
しかし実際の進捗会議では、こんなやり取りが繰り返されます。
- 「設計書レビューは終わりましたか?」「はい、終わりました」
- 「テストケース作成の進捗は?」「8割くらいです」
- 「開発は予定通り?」「今のところ順調です」
表面的には問題なさそうに見えます。でも、この報告から本当の進捗状況は見えていません。設計書レビューが「形式的に終わっただけ」かもしれないし、テストケース作成の「8割」が本当に8割なのかも分からない。「順調」という言葉の定義が人によって違うかもしれません。
私が担当してきた案件の中には、最終月になって突然「実は設計段階から認識齟齬がありまして」と報告されたものもありました。毎週の進捗会議では一度も「遅延」という言葉が出なかったのにです。
進捗率という数字の罠
WBSの各タスクに進捗率を入力してもらう運用は、多くの現場で採用されています。「今週は60%まで進みました」「来週には完了予定です」といった報告をもとに、ガントチャートの色を塗っていく。
しかしこの進捗率、誰がどうやって決めているのでしょうか。
実は多くの場合、担当者の「感覚」で入力されています。「全体の作業量から考えて、このくらいかな」という主観です。特に開発系のタスクでは、コーディングが終わってもテストで予想外の手戻りが発生することがあります。コーディング完了時点で「90%」と報告していても、実際には50%程度しか進んでいなかった、ということが起きるんですよね。
また、WBSのタスク粒度が粗いと、進捗率はさらに曖昧になります。「要件定義」というタスクが1ヶ月のスケジュールで設定されていたとして、「要件定義の進捗は?」と聞かれても、答えようがありません。ヒアリングは終わったけど整理はこれから、というときに何%と答えればいいのか。
なぜWBSが機能しないのか
WBSが進捗管理に活かせない理由は、大きく3つあると私は考えています。30年のIT業界経験、特にPMOとして複数案件を横断的に見てきた立場から、その構造的な原因を整理します。
理由1:WBSが「作業分解」で止まっている
PMBOKでは、WBS(Work Breakdown Structure)は「プロジェクトスコープと成果物を細分化した階層構造」と定義されています。しかし現場では、この「分解」だけで終わっているケースが大半です。
作業を細かく分けることは重要ですが、それだけでは進捗管理には使えません。なぜなら、分解したタスク同士の「依存関係」や「クリティカルパス」が見えていないからです。
例えば、「設計書作成」というタスクが遅れていても、それが全体スケジュールにどう影響するかが分からなければ、対処の優先順位が判断できません。設計書が遅れても後続タスクに余裕があれば問題ないかもしれないし、クリティカルパス上にあれば即座に対処が必要です。
WBSは「何をいつまでにやるか」を示す計画書ではなく、「どのタスクが遅れたら全体が遅れるか」を見抜くための分析ツールでなければならないんです。
理由2:報告の粒度とタイミングが合っていない
多くのプロジェクトでは、週次で進捗会議を開催します。そこで各担当者から「先週の実績」と「今週の予定」を報告してもらう。これ自体は悪くないのですが、問題は「報告される情報」と「管理者が知りたい情報」がズレていることです。
管理者が本当に知りたいのは、「このタスクが予定通り終わるか」ではなく、「このタスクが遅れたら全体スケジュールがどうなるか」です。しかし担当者は自分のタスクの進捗しか見えていないので、全体への影響まで報告できません。
また、週次報告では遅すぎる場合もあります。クリティカルパス上のタスクで問題が発生した場合、1週間後の会議まで待っていたら手遅れです。日次でキャッチアップすべき情報と、週次でよい情報を区別する必要があります。
私が金融系プロジェクトで経験した変更管理では、影響範囲によって報告タイミングを変えていました。全体スケジュールに影響するものは即日報告、担当タスク内で吸収できるものは週次報告、という具合です。当時は「厳しすぎる」と感じましたが、この仕組みがあったからこそ本番障害ゼロを維持できたんですよね。
理由3:遅延の「兆候」を見る仕組みがない
スケジュール管理で最も重要なのは、遅延が確定してから対処するのではなく、遅延の兆候を早期に察知することです。しかし多くの現場では、「予定日を過ぎたら遅延」という事後的な管理しかできていません。
私が現場で使っている遅延兆候の指標には、こんなものがあります。
- 前週と今週で進捗率の伸びが鈍化している
- 「残り作業」の記述が曖昧になってきた
- 特定の担当者からの報告が遅れがちになっている
- 想定外の課題が複数発生している
- 関連部署への確認待ちが増えている
これらは単体では「まだ大丈夫」と判断されがちですが、複数重なると確実に遅延します。この兆候を捉える仕組みがWBSに組み込まれていないことが、多くの現場で遅延を防げない根本原因だと思います。
現場で使える3つのスケジュール管理手法
ここからは、私が実際に現場で使っている、あるいは使えると判断したツールや手法を紹介します。PMBOKの教科書的な内容ではなく、「明日から使える」実践的なアプローチです。
手法1:クリティカルパス分析を日常化する
クリティカルパスとは、プロジェクト全体の所要期間を決定する、遅延の余裕がない一連のタスク群のことです。PMBOKでも重要な概念として扱われていますが、現場で実践している人は意外と少ないんですよね。
私が10年以上PMOをやってきて確信しているのは、「全タスクを均等に管理しようとすると、肝心なタスクを見落とす」ということです。100個のタスクがあっても、本当に注視すべきは10〜15個程度です。その10個がクリティカルパス上にあるタスクです。
クリティカルパス分析を日常化するには、WBS作成時に必ず「先行タスク」と「後続タスク」を明記することです。ExcelでもMS Projectでも構いません。各タスクに「このタスクが終わらないと次が始められない」という依存関係を記録します。
そして週次会議では、クリティカルパス上のタスクを最優先で確認します。「設計書レビューは終わりましたか?」ではなく、「設計書レビューが遅れると、次の開発着手が遅れますが大丈夫ですか?」と聞くんです。担当者も、自分のタスクが全体に与える影響を意識するようになります。
手法2:山積み表で工数の偏りを可視化する
WBSでスケジュールを引いても、実際にその作業をする人のキャパシティを見ていないケースがあります。特定の担当者に複数タスクが集中していても、WBS上では「それぞれ予定通り」に見えてしまう。
私が現場で必ず作るのが「山積み表」です。これは、各担当者が週ごとにどれだけの工数を抱えているかを積み上げたグラフです。Excelで簡単に作れます。縦軸に工数(人日)、横軸に週、各担当者のタスクを色分けして積み上げていきます。
すると、「A氏は第3週に1人で10人日分のタスクを抱えている」といったことが一目で分かります。これは物理的に不可能なので、事前にタスクの再配分や外部リソースの投入を検討できます。
山積み表を作ると、もう一つ重要なことが見えてきます。それは「手待ち」です。特定の週に極端に工数が少ない担当者がいる場合、そこに他のタスクを割り当てることで全体のスケジュールを短縮できる可能性があります。
この手法は、PMBOKの「資源平準化」という概念に対応していますが、私は教科書通りではなく、現場で使いやすい形にアレンジしています。複雑な最適化アルゴリズムは使わず、Excelで目視できる形で十分です。
手法3:進捗報告に「残作業の具体」を必須化する
進捗率だけの報告では、本当の進捗は見えません。私が現場で実践しているのは、「残作業の具体的な内容」を必ず報告してもらうことです。
例えば、「テストケース作成 進捗80%」ではなく、「テストケース作成 80% 残り:異常系20ケースの作成と全体レビュー」と報告してもらいます。この「残り作業」の記述を見ると、本当に来週完了できるかが判断できます。
また、この残作業記述が曖昧になってきたら、それは遅延の兆候です。「残り:その他調整」「残り:細かい修正」といった抽象的な表現が出てきたら、黄色信号です。担当者自身が残作業を把握しきれていない、あるいは報告しづらい問題が隠れている可能性があります。
この手法は、ツールというより「運用ルール」です。特別なソフトウェアは不要で、ExcelやRedmineなど既存のツールでも十分実践できます。重要なのは、進捗報告のフォーマットを統一し、全員が同じ粒度で報告する習慣をつけることです。
ツールに頼りすぎない現実的な選択
スケジュール管理ツールは数多くありますが、私が30年見てきた限り、「ツールを導入すれば解決する」という考えは危険です。MS Project、Jira、Asana、Backlogなど、どれも優れたツールですが、本質は「どう使うか」です。
中堅企業の現場では、全員が高度なツールを使いこなせるとは限りません。むしろExcelベースで、シンプルだが本質を押さえた管理をする方が現実的な場合も多いです。私自身、今でもExcelとRedmineを併用しています。
ツール選びで重要なのは、「クリティカルパスが見える」「担当者の工数が見える」「残作業が記録できる」の3点です。この3点を満たせるなら、ツールは何でも構いません。高機能なプロジェクト管理ツールを導入しても、結局Excelに戻ってくるケースを何度も見てきました。
30年現場にいた私が思うこと
スケジュールマネジメントの本質は、計画を立てることではなく、「遅延の兆候を察知し続けること」だと私は考えています。完璧なWBSを作っても、それは計画時点の想定に過ぎません。プロジェクトは生き物で、日々状況が変わります。
私が金融系の厳格なプロジェクトで学んだのは、「順調報告を疑う習慣」でした。当時の上司は、毎週の進捗会議で必ず「本当に大丈夫か?隠れている問題はないか?」と問いかけていました。最初は「疑われている」と感じて不快でしたが、今振り返ると、あの問いかけが遅延の兆候を早期に引き出していたんですよね。
教科書と現場のギャップを埋める
私はPJM-A資格を持っていますが、資格試験で学ぶPMBOKと現場で求められるスキルには大きなギャップがあります。PMBOKは体系的で素晴らしい知識体系ですが、そのまま現場に適用できるわけではありません。
例えば、PMBOKではEVM(Earned Value Management)という進捗管理手法が紹介されています。計画価値、実績価値、実コストを比較して進捗を定量的に測る手法ですが、中小規模のプロジェクトでこれを厳密に運用するのは現実的ではありません。計算の手間が管理の手間を上回ってしまいます。
重要なのは、PMBOKの「考え方」を理解した上で、自分の現場に合った形にアレンジすることです。クリティカルパスの概念は活かしつつ、計算は簡略化する。EVMの発想は取り入れつつ、実際は進捗率と残作業のシンプルな管理にする。こうした「現場翻訳」が、実務家には求められます。
中小企業だからこそできる柔軟な管理
大企業や大規模プロジェクトでは、フォーマルな進捗管理プロセスが必要です。しかし中堅企業の10〜30名規模のプロジェクトなら、もっと柔軟で実効的な管理ができます。
私が今担当しているプロジェクトでは、週次会議とは別に「クリティカルパス上のタスク担当者」とだけ毎日15分の立ち話をしています。会議室も資料も不要です。「昨日何やった?今日何やる?困ってることない?」この3つを聞くだけ。たったこれだけで、遅延の兆候はほぼ100%キャッチできます。
形式にこだわりすぎると、本質を見失います。WBSもガントチャートも、あくまで「遅延を防ぐ」という目的のための手段です。その目的が達成できるなら、手段は何でもいいんです。
明日からできる小さな一歩
もしあなたが今、「WBSは作ったけど進捗管理に活かせていない」と感じているなら、まずこの一つだけ試してみてください。
次回の進捗会議で、各タスクの報告に「残り作業の具体的内容」を必ず含めてもらう。
進捗率だけでなく、「何が残っているか」を具体的に言語化してもらうんです。この一点を変えるだけで、見える景色が変わります。担当者も自分の作業を整理できますし、あなたも本当の進捗が見えるようになります。
スケジュールマネジメントは、高度な技術や複雑なツールがなくてもできます。必要なのは、「順調報告の裏を読む習慣」と「遅延の兆候に敏感になる感覚」です。そしてそれは、日々の小さな実践の積み重ねでしか身につきません。
私も30年かけて、ようやくこの感覚を掴めるようになりました。あなたも焦らず、一つずつ試してみてください。プロジェクトは毎回違いますが、遅延の兆候には共通のパターンがあります。そのパターンを自分の引き出しに蓄えていくことが、PMやPMOとしての成長だと思います。
コメント