進捗遅延 の 原因 と 対策

今回は「進捗遅延の原因と対策」についてまとめていきたいと思います。

「計画は正しい」ことを前提として、遅延原因をベースにその対策はどんなものが考えられるか、以下では具体例を出して見ていきます。 実務上は以下の内容が参考になるかと思います。

スキルミスマッチ

アサインしたメンバーのスキルとタスク難易度が一致しないことに起因する遅延。 基本的な対応はフォローを入れて過勤務対応になりますが、これで対応しきれなければメンバーチェンジも考えます。

報告例

  • 「初参画のため立ち上げに（予定以上に）時間がかかっている」
  • 「見積もりが甘かった（思った生産性が出ていない）」
  • 「（担当者スキルに対して）タスク難易度が高かったため」
  • 「品質が悪く手戻りが発生している」
  • 「レビューに時間がかかっている（指摘が多く発生して収束しない）」

対策例

  • 1か月以内に解消が見込める場合
    • フォローメンバーをつける。
    • 作業内容に関するガイダンスの実施する。
    • 着手前にレビュアーないし詳しいメンバーに修正箇所の説明を行うようにする。
    • 上記作業は追加作業なので過勤務対応とする（＝フォローするメンバーの行うタスクに対する投入工数が減ることがないようにする）。
  • 1か月以上かかるタスクの場合
    • 担当者を変更する。

追加タスク発生

計画時には見えていなかった課題が発見されたことによる追加作業（タスク）が発生したことに起因する遅延。 追加タスクによる遅延は様々な形の "遅延" で表れてくるため、報告も様々になります。

報告例

  • 「他の優先度が高いタスク（課題、レビュー）を対応していた」
  • 「原因不明のエラーが発生した」
  • 「見積もりが甘かった（タスクの漏れがあった）」
  • 「仕様未確定な箇所が見つかった」
  • 「仕様変更が発生した」
  • 「手戻りが発生した」
  • 「残レビューのみです（＝レビュー実施ができていない＝他タスク（課題、フォローなど）実施が発生している）」
  • 「承認依頼しているけど返答がないため止まっています（＝承認者が他の優先度が高い課題対応を行っている）」
  • 「問い合わせを投げているが返答がないため進められていません」

対策例

  • 課題が最も早く解決できる（作業に落とし込まれる）ようにする
    • 問題となっている要件や機能、障害に詳しいメンバーをアサインする
    • アサインできないのであれば問い合わせられるように調整する
  • 5-10人日以内の解消が見込める場合
    • 遅延原因となっている担当者の過勤務による対応
    • 先行しているメンバーによるフォロー
  • 10人日以上かかる見込みの場合
    • 増員
    • 別スケジュール作成

他チームタスク未完了

クリティカルパス上のタスクで他チームが実施するタスクが遅延しているために遅延してしまっているケース。

報告例

  • 「利用するモジュールが未完成のため完了できません」
  • 「環境構築が終わっていないため着手できません」
  • 「実施に必要な機材（サーバー、ネットワーク機器、検証端末、スマホなど）が揃わないため着手できません」
  • 「着手指示がないため進められません」

対策例

  • ボトルネックになっているチームに対して早く完了させるよう正式な場で伝える。
  • 先行着手できる他のタスクを実施することで工数上オンスケとなるようにする。

非効率なプロセス

作業プロセスに問題があるケース。 担当者は進めたくても思うように進められないために発生する遅延。

報告例

  • 「関係チームとのコミュニケーションロスが多く発生している」
  • 「承認・問い合わせに時間がかかっている」

対策例

  • 承認などでスキップできそうなプロセスがあるならスキップを検討する。 ただし、品質が落ちる懸念があるので観点だけは教育しておくなどの対策も併せて行う。
  • 手戻り覚悟で進める。 手戻りを行うタイミングは別途計画しておく。

非効率な環境

報告例

  • 「ネットワークが遅いため効率が上がりません（VPNを利用した遠隔地での開発）」
  • 「開発PCが遅い」
  • 「メモリが足りない」

対策例

  • インフラ周りの原因に対してはお金をかけて対策するしかないかと思います。。
  • セキュリティを犠牲にできるならVPNを止めるという手段も検討に挙げられるかもしれません。

非効率なメンバー

かなり目に余る状況でない限り報告されることはないと思いますが…。 個別に報告されたりするかと思います。 投入工数は予定通りだ 本人が非効率になっている原因があるのでもう一歩踏み込んで対策を考えます。

報告例

  • 「さぼってる（Yahooニュース、Twitter、Facebookなど）」
  • 「作業の優先順を間違った」
  • 「マルチタスク（切り替え時のオーバーヘッドが大きい）」

対策例

  • やる気がない場合
    • 担当者には休んでもらい、他のメンバーの過勤務でフォローします。
    • 可能であればメンバー変更します。
  • やる気はある場合
    • 毎朝「前日の実績」「その日やるタスク」の棚卸を行い、やるべきこと優先度を間違えないように管理します。

投入工数不足

そもそも投入工数が足りていないことによる遅延。 基本的には不足している工数を確保する対策を行います。

報告例

  • 「病欠のため」
  • 「他チームからの依頼事項を対応していたため」

対策例

  • やむを得ない事情の場合は他メンバーが過勤務することでフォローします。
  • 他チームからの依頼で調整できそうであれば依頼を断るか後で使った分の工数のリカバリをフォローしてもらうよう交渉します。

今回は「進捗遅延の原因と対策」についてまとめました。ポイントは以下の通りです。

  • なぜなぜ分析して原因を深堀する

今回の記事はお役に立ったでしょうか？お役に立ったならぜひシェアを！！

コメント

コメントを投稿

このブログの人気の投稿

進捗会議 の アジェンダ

今回は「進捗会議のアジェンダ」についてまとめていきたいと思います。 アジェンダの必要性 進捗会議に限らず、会議前にアジェンダを作ることで「会議の目的を共有して無駄をなくす」ことができるようになります。 アジェンダ作成するのも時間がかかりますが…アジェンダなしで会議を始めてしまうと「参加人数×会議が延びた時間」のコストがかかってしまいます。 面倒ではあるのですが、プロジェクト全体を考えるとアジェンダは作っておくべきな気がします。 進捗会議のアジェンダ 以下に記載している項目は進捗管理する上で確認すべき内容の一覧ですが、開発規模や開発フェーズによってアジェンダの内容は変わると思います。 「進捗」「品質」「課題」は進捗確認という意味で確認すべきポイントですが、これらは状況によってそれぞれ別会議を設けることがあるようです。 連絡事項の共有 進捗確認 品質確認 課題棚卸 依頼事項の確認 以下では上記項目のそれぞれについて具体的な内容を見ていきます。 連絡事項の共有 主に、以下のような「外から入ってくる情報」を共有します。 また「チームへ向けた注意喚起、改善依頼」などもここで行います。 マイルストーン プロジェクト全体にかかわるアナウンス 他チームからの依頼事項 メンバーに向けた注意喚起 進捗確認 進捗会議のメインはこの項目だと思います。 計画されたガントチャート（現場では "WBS" と呼ばれることが多い？）に対して実績を確認し、遅延原因を特定、遅延対策を検討、その場で適用可能な対策であれば対策実施の依頼まで行います。 ガントチャート 品質確認 「品質レポート」とまとめてしまいましたが…設計フェーズであればレビュー指摘件数やレビュー指摘内容について確認します。 テストフェーズであれば一般的によく聞く信頼度成長曲線や機能別、要件別、混入工程別の障害件数などを確認します。 進捗確認と同じですが、状況確認したうえで、障害が多発している箇所もしくはまったく出ていない箇所について、その原因分析、改善対策の検討、改善対策の実施依頼まで行います。 品質レポート 品質の分析について細かく行い始めるとこれだけでかなり時間がかかること...
続きを読む

はじめに

初回投稿なので、今回はこのブログを始めるにあたってどんなことを記載していくか…についてまとめておきたいと思います。 一言でいえば初心表明ですね。 いずれの項目も今までに書籍や勉強会で学んだ内容を踏まえて吐き出していきたいと考えています。 プロジェクト管理 一言で「プロジェクト管理」といってもその内容は多岐にわたります。 PMBOKで言えばスケジュール、スコープ、コスト、品質、人的資源、コミュニケーション、リスク、調達、ステークホルダー…など。 PMBOK とはいえ、机上の話だけでは面白くないので、もう少し実務よりな内容で記事を書けたらいいな、と考えています。 進捗定例（定例の運営、報告） WBS作成 問題解決 ロジカルシンキング プロジェクト管理の問題解決にも関係しますが、 「漏れダブり」なく考えられることは大切なことかと思っています。 ロジカルシンキングに関しては、一般的な話の組み立て方の考え方を中心に記事を書いていきたいと思います。 時間管理 最近は「業務効率化」などで話題ですね。 「業務効率化」と「時間管理」は密接な関係にある気がしています。 「効率化（＝生産性をあげる）」には自分の時間をいかにコントロールして生産性をあげるかを考える必要があると思っています。 書籍などから学んだこともそうですが、普段生活していて思いついた効率化があれば記事にしていきたいと思います。 クレーム対応 社外の人（お客様筆頭に協力会社など含む）を相手にするときだけでなく、社内でもチーム跨げば社外も同然なので、これも必要な知識な気がします。 数冊読んだ感じだと何かしらの法則はありそうなので、そこを記事にまとめていきたいと思います。 メンバー育成 プロジェクト管理に関連しますが、チームメンバーも集まりたては各人スキルいろいろなので、そこをそろえるためにも育てなければいけないと思っています。 世の中にはだいたい "基本" と呼ばれるものがあるんですね。 教育に関しても実際に書籍で学習したこと、それを適用してみてどうだったか、などを記事にしていきたいと思います。 今回は「このブログで書きたいこと」についてまとめました。ポイントは以下の通りです。 プロジェクト管理 ロジカルシ...
続きを読む