進捗管理の考え方：炎上を防ぐのではなく、遅延をコントロールする方法

進捗管理は、やっている。WBSも作った。Backlogにチケットも切っている。定例で進捗確認もしている。

PMとして「何もしていない」わけではない。それなのに、気づけばタスクチケットはいつの間にか山積みになっている。遅延は、だいたいギリギリで発覚する。事業部からの「大丈夫ですよね？」という一言に、自信を持って返事ができない。

ちゃんとやっているはずなのに、なんでうまくいかないんだろう？もっと上手いやり方があるんじゃないか？

現場のPMなら、一度は感じたことがあるのではないでしょうか。

進捗管理といえば、WBSを作ってタスクとスケジュールを管理するもの。もし、そう思っているとしたら、そもそもの進捗管理の考え方や設計の仕方がズレている可能性があります。

この記事では、

• 進捗管理の目的の再定義
• 本当は何を管理すべきなのか
• PMが設計すべき進捗管理の仕組み

を、構造的に解説していきます。

この記事でわかること

• 進捗管理の本質を説明できるようになる
• 「遅延を早く検知する設計」という視点が持てる
• うまくいかない状態から抜け出す構造が見える

なぜ「進捗管理していても」炎上は起きるのか？

進捗管理と聞いて、どんなイメージを持つでしょうか。多くの人は、次のようなものを思い浮かべると思います。

• WBSを作ってタスクを洗い出す
• 定期的に進捗をチェックし、オンスケを維持する

確かに、これは間違っていません。実際、多くのPMはこのような進捗管理を行っています。それでも、なぜか管理はいつの間にか破綻し、タスクは山積みになり、遅延して炎上する。そんな状況を経験したことがある人も多いのではないでしょうか。

「もっと、うまく進捗管理できていれば、炎上せずに済んだのに」

そう思ったことがあるPMの方に、まず伝えたいことがあります！

そもそも、進捗管理がうまくできていても、炎上を完全に防ぐことはできません。

なぜなら、炎上の原因は進捗管理だけではないからです。

プロジェクトが炎上する原因はさまざまです。要件が膨らむ、技術力が不足する、後になって仕様の漏れが発覚するなど、その要因は本当に多種多様です。

だからこそ、「進捗管理をちゃんとやれば炎上は防げる」という考え方は間違っています！

一方で、進捗管理が機能していなければ、炎上の確率が高まるのも事実です。そして、進捗管理を正しく設計し、実行できていれば、炎上の可能性を下げることはできます。

手遅れになる前に異変を検知できるかどうかは、進捗管理にかかっているからです。

ということで、次に「進捗管理の目的」を改めて確認していきます。

進捗管理の目的を再定義：本質は「遅延の早期検知」

いくら進捗管理を徹底しても、炎上を完全に防ぐことはできません。
だとしたら、進捗管理は何のために行うのでしょうか。

多くのPMは、進捗管理の目的を「オンスケを維持すること」だと捉えています。確かに、計画通りに進められるに越したことはありません。しかし、プロジェクトは得てして計画通りには進みません。そもそも、不確実性の塊だからです。

そして通常、プロジェクト計画は、ある程度の遅延が発生することを前提に立てられています。 つまり、遅延そのものが問題なのではありません！問題なのは、遅延に気づくのが遅れ、手遅れになることです。

だからこそ、進捗管理で本当に重要なのは「遅延の早期検知」です。
この前提に立つと、進捗管理の目的は次のように再定義できます。

進捗管理の目的
スケジュールの遅延に、いち早く対処できる状態を作ること

オンスケを維持することではなく、遅延にいち早く気づき、対処可能な状態を作っておくこと。これが進捗管理の目的です。言い換えると、遅延を「コントローラブルなもの」にする仕組みを作ることとも言えます。

遅延しないようにすること自体が目的なのではありません。遅延が発生しても、対処できる状態を維持することが、進捗管理では重要です。

そのため、進捗管理とは、WBSをひたすら詳細化することでも、タスクチェックを細かく頑張ることでもありません。 遅延を早期に検知し、対処できるようにするための「設計」を行うことが重要になります。

次に、その設計を行う前提として、そもそも進捗管理では「何を管理すべきなのか？」について解説していきます。管理対象が分からなければ、進捗管理を設計することはできないからです。

進捗管理で管理するもの

改めて、進捗管理では何を管理すればいいのでしょうか。

名前から考えると「進捗」を管理するのですが、そもそもなんの進捗かというと「タスク」です。ということで、進捗管理で管理する対象は「タスク」です。

では、このタスクの「何」を管理すればいいのでしょうか。少し分解して考えてみます。
イメージとしては、次のように分けると理解しやすいです。

タスクの進行状況を管理する

まずは、タスクの進行状況です。ここでは、大きく次の3点を管理していけば十分です。

• 予定通り着手できているか
• 遅延が発生しているか
• 問題が発生していないか

単に「遅延しているか」だけを見るのではありません。そもそも着手できているのか、オンスケに見えていても問題を抱えていないか、といった点も含めて確認していきます。

タスクの内容を管理する

次に、タスクの内容そのものです。進行状況だけでなく、タスクの中身も管理することで、遅延をより早い段階で検知できるようになります。

主に、次のような観点を見ていきます。

• タスクの粒度
• INPUT / OUTPUT
• 完了条件

タスクの粒度が大きすぎると、やることが多くなり、スケジュールも長くなります。その結果、遅延が見えにくくなり、管理も難しくなります。

また、タスクのINPUTやOUTPUTが定義されていないと、着手してから余計な調整や確認が発生し、想定以上に時間がかかります。完了条件が曖昧なタスクも、クローズの判断ができず、遅延につながりやすくなります。

（※ タスクの効果的な切り方については、別記事で解説予定です）

このように、タスクを適切に分解し、進行状況と内容の両方を管理することで、遅延を早期に見つけ、対処しやすくなります。

ただし、すべてのタスクを人の目で細かく追い続けるのは現実的ではありません。いくら時間があっても足りないからです。

だからこそ、人が頑張るのではなく、仕組みで解決する必要があります。そのために、次の章では、進捗管理の「設計」について解説していきます。

進捗管理の設計図

遅延を早期に検知し、対処していくための進捗管理では、次の3つを設計することが重要です。

1. タスクの可視化
2. 定例チェック
3. リスケ

「設計する」と聞くと少し大袈裟に感じるかもしれませんが、要はあらかじめ型を決めたうえで運営するということです。行き当たりばったりで対応するのではなく、決めた型に沿ってアクションしていきます。

こうした型を持つことで、プロジェクト全体として、安定した進捗管理ができるようになります。

なお、この3つは、どれか1つだけやればよいというものではありません。3つをセットで設計・運営していくことがポイントです。イメージとしては、次のようにつながっています。

以降では、それぞれについて、どのように設計し、どのように運営していくのがよいのかを順番に解説していきます。

① タスクの可視化

進捗管理で最も重要なのが「タスクの可視化」です。

なぜなら、可視化されていないものは管理できないからです！
だからまずは、何がなんでもタスクを可視化する。これが進捗管理の第一歩になります。

そのうえで、次の観点を決めていくことで、タスクの可視化を設計していきます。

• 可視化の場所
• タスク発生のルール
• タスクの粒度
• 可視化する項目

可視化する場所を設計する

まずは、タスクを可視化する「場所」を決めます。

小規模プロジェクトであればExcelのWBS、中規模以上であればJiraやBacklogなどのツールを使うのがおすすめです。

いずれにせよ重要なのは、進捗管理の対象である「タスク」を一箇所で把握できる状態を作ることです。「ここを見れば、プロジェクト全体のタスク状況が分かる」という場所を決めましょう。

ただし、開発などで複数のベンダーが関わる場合は、あえて分散管理を選ぶケースもあります。例えば、次のような体制です。

• 企画・プロジェクト管理：本社
• 受注管理システム：A社
• 発注管理システム：B社

この場合、本社のPMは自社のタスクを管理し、各ベンダーのタスク管理はベンダー側のPMに任せます。本社のPMは、ベンダーからの共有や報告をもとに進捗を把握します。

ただし、各ベンダーのタスクや進捗をいつでも確認できる状態にしておくことが重要です。「聞かないと分からない」「資料をもらわないと見えない」という状態を作らないようにしましょう。

タスク発生ルールを設計する

可視化する場所が決まったら、次は「いつ・どうやって可視化するか」を設計します。

タスクは、さまざまなタイミングで発生します。MTGの最中、チャットのやり取りの途中など、発生源はバラバラです。

だからこそ、タスクが発生したらどうするかを、あらかじめルールとして決めておきます。基本的な考え方はシンプルで、タスクが発生したら、決めた可視化場所に必ず書き込む、です。

これを、プロジェクトで使っているツールを前提にルール化します。例えば、Backlogを使っている場合は次のようになります。

ルール：タスクが発生したら、必ずBacklogに可視化する

とてもシンプルですが、あえて明文化することが重要です。あわせて、NGルールも決めておくと効果的です。

• 口頭のみでのタスク依頼はNG
• チャットのみでのタスク依頼はNG

可視化されていないタスクは、存在していないのと同じです。だからこそ、必ずタスクが可視化されるように、ルールで縛ることが重要になります。

タスク粒度を設計する

ここからは、タスクの中身についての設計です。

「Backlogにタスクを起票してください」と伝えるだけでは、どうしても人によってタスクの書き方がバラバラになります。細かく書いてくれる人もいれば、ざっくりとしか書かない人も出てきます。

そこで、この章では「タスクの粒度」をどう揃えるかを設計します。

タスクの粒度は、主に次の観点で考えると整理しやすくなります。

• 期間の長さ
• 作業の多さ
• OUTPUTの多さ

期間が長ければ長いほど、タスクの粒度は大きくなります。作業内容やOUTPUTが多くても、同様に粒度は大きくなります。基本的に、タスクの粒度は大きいよりも小さい方が管理しやすく、望ましい状態です。

そのため、粒度が大きいタスクがそのまま登録されないよう、あらかじめルールを決めておきます。例えば、次のようなルールです。

• 1週間以上かかるタスクは分割する
• OUTPUTが複数あるタスクは分割する

プロジェクトを進めていくと、どうしても例外は発生します。ただ、こうしたルールがあることで、「これは例外なのか」「ルール違反なのか」を判断できるようになります。

まずは、ベースとなるルールを作ること。それが、タスクの粒度を揃えるうえで最も重要です。

可視化項目を設計する

最後に、タスクとして可視化する項目を設計します。

管理する立場としては、できるだけ細かく記載してほしいと思いがちです。一方で、作業する立場からすると、記載項目は少ない方が嬉しい。だからこそ、ここは多すぎず、少なすぎずのバランスが重要になります。

まずは、基準となる項目を整理します。

• 概要
• 目的
• 手順
• 完了条件
• INPUT
• OUTPUT
• 担当
• 着手日
• 期限日

最低限、これらの項目は押さえておきたいところです。ただし、プロジェクトの規模や、参加メンバーのスキルレベルに応じて、適宜調整していきましょう。

また、タスクを自分で実行するのか、他人に依頼するのかによっても、記載の粒度は変わります。自分でやるタスクであれば、多少省略しても問題ありません。一方で、他人に振るタスクの場合は、記載が不足していると作業が止まりやすくなります。

可視化項目は、管理のために増やすものではありません。作業がスムーズに進むために、必要な情報を揃える。その視点で設計することが大切です！

② 定例チェック

タスクの可視化を設計できたら、次は定例チェックの設計です。

とはいえ、「プロジェクトのタスクを定例で確認する」という話なので、やること自体はそれほど難しくありません。ここでのポイントは、定型化することです。

毎回、同じ観点で、同じ流れでチェックを繰り返すことが、進捗管理では重要になります。

チェックが不定期だったり、日によって観点がブレたりすると、遅延の早期検知や対処ができなくなります。だからこそ、ここも「定型化できる形」で設計していきます。

決めることは、大きく次の2つです。

• どの定例でチェックするか
• 何をチェックするか

どの定例でチェックするか

まずは、どの定例でタスクをチェックするかを決めます。基本的には、すべての定例MTGでチェックしても問題ありません。

例えば、企画定例では企画系のタスクを、ベンダー定例では開発系のタスクを確認する、といったように、定例の性質に合わせてチェック対象を分けるのも有効です。

何をチェックするか

次に、定例の中で何をチェックするかです。ここは、次の観点で確認すれば十分です。

• 遅れているタスクはないか
• 未着手のタスクはないか
• 期間が長すぎるタスクはないか

定例MTGの中で、すべてのタスクの中身を細かく見る時間はありません。そこで、まずはスケジュールと状態に着目してチェックします。

最後の「期間が長すぎるタスクはないか」は、粒度が大きすぎるタスクを見つけるための観点です。直接的な遅延検知ではありませんが、将来の遅延リスクを早めに見つけるという意味で重要なチェックポイントになります。

③ リスケ

定例チェックで遅延が検知された場合は、リスケの判断を行います。

進捗管理を「オンスケを維持するためのもの」と捉えていると、あまりリスケは行われません。どちらかというと、オンスケを維持するために何をすべきかを考え、アクションでカバーしようとします。例えば、残業で対応したり、人を追加したり、といった対応です。

それ自体が悪いわけではありません。ただし、それでは進捗管理ができている状態とは言えません。結局のところ、遅延をプロジェクトメンバーの頑張りによって吸収しているだけで、PMが進捗をコントロールできているとは言えないからです。

プロジェクトメンバーに無理を押し付けるのではなく、PMがタスクやスケジュールを調整することで進捗をコントロールする。その方が、プロジェクト全体としての疲弊は少なくなります。

だからこそ、進捗管理の設計として、遅延を検知したらリスケを検討するという選択肢をPMは持っておきましょう。

まとめ

ここまで、進捗管理について見てきました。

WBSを作る。
タスクを管理する。
定例で進捗を確認する。

これらはどれも間違っていません。でも、それだけでは進捗管理として十分とは言えません。。

進捗管理で大事なことは、オンスケを維持することではなく、遅延を早期に検知し、対処できる状態を作ることです。言い換えると、遅延を「気合」や「頑張り」で乗り切るのではなく、PMがコントロール可能なものにすることです。

そのために、この記事では次の3つをセットで設計することを紹介しました。

• タスクを可視化する
• 定例で定型的にチェックする
• 遅延を検知したらリスケを検討する

どれか1つだけを頑張っても、進捗管理はうまく機能しません。3つがつながってはじめて、遅延を早く見つけ、判断し、対処できるようになります。

また、進捗管理は「PMがすべてを把握し続ける」ことでもありません。プロジェクトが大きくなるほど、PMが全部を把握することは不可能です。

人が頑張る前提ではなく、仕組みで自然と異変に気づける状態を作ることが重要です！

もし、

• タスクは管理しているはずなのに、いつも遅延に気づくのが遅い
• 定例をやっているのに、進捗が安定しない
• 気づけばメンバーの頑張りに頼った進行になっている

と感じているのであれば、一度、進捗管理の「やり方」ではなく「設計」を見直してみてください。

進捗管理は、センスや根性の話ではありません。設計すれば、再現できるものです!!

よくあるNGパターン

プロジェクトをやってるとよく見かけるNGパターンです。参加しているプロジェクトがこうなっていたら要注意！

タスクが可視化されていない

MTGでの口頭のやり取りだけ、チャット上のやり取りだけで、タスクが可視化されていないパターンです。

確かに、会話の中から「これもやった方がよさそう」というタスクが生まれることはよくあります。ただ、それをそのままにせず、プロジェクトで決めた場所（Backlogなど）にきちんと可視化することが重要です。

タスクが可視化されていないと、管理することができません。管理できない状態では、次のようなリスクが生じます。

• 重要なタスクなのに、いつの間にか忘れられてしまう
• 遅れていても、誰も気づけない
• PMの知らないところで工数が消費されている

進捗管理の土俵に乗せるためには、まずは可視化すること。
進捗管理は、可視化から始まります。

タスクやチケットが山積みになっている

一応、タスク自体は可視化されているものの、量が多すぎて管理不能に陥っているパターンです。特に、プロジェクトの中盤以降でよく見られます。

立ち上げ当初はタスクの可視化や管理ができていたのに、進むにつれて徐々に破綻していく。この場合、可視化そのものではなく、タスクの粒度や書き方、定例チェックの運用に問題があることが多いです。

例えば、次のような状態になっていないかは要チェックです。

• 本当にやる必要のあることだけがタスク化されているか
• 期限が長すぎるタスクが放置されていないか
• 担当者が明確に設定されているか

山積みになったタスクを整理するには、これらの観点で棚卸しを行うしかありません。

まずは、不要・不急のタスクをクローズし、最低限やるべきタスクだけを残します。そのうえで、進捗管理のルールを見直し、仕切り直してリスタートすることが重要です。

関連記事