管理職・リーダーの主な仕事内容は?
組織の目標設定
メンバー育成
顧客交渉
労務管理
いろいろ挙げられますが、管理職やリーダーにとって第一歩目の仕事は進捗管理でしょう。今回はどの業界の平社員でも使える進捗管理をお伝えします。
なぜ管理者は進捗管理をする必要があるのか?
進捗管理する目的は何なのか?
その答えが分かります!
- 進捗管理を体系的に理解したい
- マネジメントを学びたい
- プロジェクトの炎上を避けたい
進捗管理の流れ

進捗管理の目的は問題が発生した時、迅速に解決することです。
いつどこで問題が発生したか。
その問題の原因は何か。
問題を誰にどう報告するか。
これらは1つの流れで対応できます。
進捗管理の流れ
- 進捗確認
- 遅延検出
- 原因特定
- エスカレーション
複雑な管理方法や特殊な思考法は一切ありません。
体系的に流れをつかめば誰でも管理できます。
ではそれぞれのステップを詳しく解説しましょう。
進捗確認

最初のステップである進捗確認で最も重要なことは『計画値』と『実績値』です。
- 計画値:「いつまで」に、「どれくらい」進める必要があるか
- 実績値:「今まで」に、「どれくらい」進んだか
計画値は作業前の計画段階で設定する値のことです。
作業レベル、人員数、作業期間を鑑みて、1日あたりの適切な値を設定します。
大きな作業遅延やトラブルが起きない限り、計画値の変更はしません。
実績値はその日の作業実施件数の値です。
このように定量的に進捗を確認します。
また実行担当者に作業の不明点がないか、当日の作業内容の確認など定性的な確認も進捗確認に含まれています。
無理のない計画値の設定
実行担当者がストレスになる作業計画は管理能力として見過ごせません。
計画値には必ずバッファ(余裕)を持たせましょう。
開始バッファ:作業確認や導入に必要な時間を確保する
終了バッファ:遅延、手戻り、修正作業を見越した時間を確保する
進捗確認には無理のない計画値と実績値がある
遅延検出

作業にトラブルは付き物で、どんなシステムでも遅延になりうる障害は発生します。
しかし前章の進捗確認を日々行っていれば、遅延検出はすぐに気付けるはずです。
計画値と実績値が大きくズレたら遅延発生と判断できます。
ここで注意なのは『大きくズレる』の定義です。
例えば計画値と実績値が100件ズレていたら遅延でしょうか?
A 計画値:1,000 実績値:900
B 計画値:120 実績値:20
同じ100件のズレでも規模が違います。
ここは作業前の計画段階で『〇件ずれたら遅延と判断する』と定義しておきましょう。
そしてどの業界でもあり得る遅延パターンは以下の4パターンです。
これら各ケースに対して事前に遅延判断基準を設けておくと、かなり準備のいい管理者として見られるでしょう。
遅延あるある
- 単純に実績値が計画値に届いていない
- トラブル障害が多発している
- 未完了の確認事項が滞留している
- 後半まで保留が残っている
計画値と実績値が、計画時に決めた件数以上離れたら遅延となる
原因特定

遅延発生したら次は原因特定をします。
これは次のエスカレーションにも繋がる大事なフェーズです。
複雑な論理思考は不要で、原因特定の基本は『どこ』と『なぜ』です。
- どこ:機能/工程/場所/…などの単位で発生箇所を特定する
- なぜ:人/環境/システムに分けて発生原因を特定する
前提として毎日進捗確認を行っているので、いつどこで遅延が発生したかの特定は難しくないはずです。
問題はなぜ遅延が発生したかです。
遅延の発生原因は主に人/環境/システムのいずれかに分類できます。
発生原因別 遅延例
人
・メンバーの実績値が悪い
・レスポンスが遅い
環境
・作業準備が整っていない
・作業時間が限定される
システム
・作業難易度が高い
・障害が頻発する
またこの遅延原因を後続のエスカレーションで報告する必要があります。
エスカレ先は基本、上長や顧客です。
上記の遅延原因を定量的に表し、ツッコミ所のない理論武装した根拠にしましょう。
遅延原因を定量的な根拠で示す
エスカレーション

遅延が発生し、原因を定量的に判断できた状態です。
いよいよ報告ですが、エスカレーションには『速報アラート』と『詳細報告』の2段階あります。
- 速報アラート:スピード重視でチャットや口頭で報告する
- 詳細報告:正確重視で遅延の詳細を報告する
速報アラートの報告項目は以下です。
速報アラートフォーマット
報告目的:遅延が発生したため速報として遅延概要を報告します。
現在の進捗状況:進捗確認で計画値と実績値の乖離値
遅延箇所:原因特定の『どこ』の部分
遅延原因:原因特定の『なぜ』の部分を定量的に
今後の対応:現在遅延が発生しているため、後ほど確認する原因の詳細を含めて、顧客へエスカレしようと思います。
速報アラートのエスカレ先
速報アラートのエスカレ先は社内の上長に行います。
まずは社内で内容を精査してから顧客へ報告するためです。
下手に騒ぎ立てると顧客からの信用にも関わります。
詳細アラートの報告項目は以下です。
詳細アラートフォーマット
報告目的:進捗率をリカバリするための対応依頼として報告します。
現在の進捗状況:進捗確認で計画値と実績値の乖離値
遅延箇所:原因特定の『どこ』の部分
遅延原因:原因特定の『なぜ』の部分を定量的に
原因詳細:遅延の直接原因(実装ミス、仕様書ミスなど)
対応方針依頼①:進捗率をリカバリするための暫定対応の依頼
対応方針依頼②:恒久対応を提案するため、直接原因を深掘りして根本原因の特定を目的としたmtg依頼
どこまで対応するか
通常のエスカレーションでは、リカバリを目的とした対応依頼①までです。
しかし上記の詳細アラートフォーマットでは、別pjtで同様の遅延を発生させないために根本原因を解消するための恒久対応を策定しています。
作業期間の優先事項は何か、当たり前品質と魅力的品質は何か、顧客が求めるサービスは何か。
リソースは有限ですので、どこまで対応するかは上長や顧客と要相談です。
フォーマットに合わせて、速報アラートと詳細アラートを発報する
まとめ
進捗確認には無理のない計画値と実績値がある
計画値と実績値が、計画時に決めた件数以上離れたら遅延となる
遅延原因を定量的な根拠で示す
フォーマットに合わせて、速報アラートと詳細アラートを発報する
いかがだったでしょうか。
進捗管理とエスカレーションは別で考えていた人も多いと思いますが、違います。
進捗管理の中にエスカレーションが含まれています。
繰り返しになりますが、進捗管理の目的は問題が発生した時、迅速に解決することです。
その手段に進捗確認やエスカレーションがある形です。
他にも管理職の仕事は多岐に渡りますが、すべて目的と手段を理解すれば難しくはありません。
今後も管理職に求められる業務内容を発信できればと思います。