📚 ナレッジベース

プロジェクト進行管理

最終更新 2026年04月26日 ／ 21_ナレッジベース/セールス/プロジェクト進行管理.md

プロジェクト進行管理

進捗報告 × トラブル対応 × デッドライン管理が、契約継続率を決める。

30秒で全体像

観点 一言
核心 受注後の進行管理がリピート・紹介・解約防止のすべてを決める
キーワード 進捗報告 / トラブル対応 / デッドライン / 期待値マネジメント
使う人 PM / アカウントマネジャー / FS
読了目安 6-8分

プロジェクト進行管理の3本柱

graph TB
    A[① 進捗報告<br/>定期・先回り] --> CORE[継続率最大化]
    B[② トラブル対応<br/>初動と透明性] --> CORE
    C[③ デッドライン管理<br/>余裕を持って前倒し] --> CORE

    style CORE fill:#fce4ec

① 進捗報告：先回りで信頼を積む

沈黙は不安を生む。報告のないPMはトラブルがあると勘違いされる。

報告サイクルの基本

頻度 内容
週次 サマリー + 今週の進捗 + 来週の予定 + リスク
隔週/月次 KPI数値 + 改善施策 + 次月の戦略
即時 想定外イベント発生時（5分以内に第一報）

報告の3要素

事実 → 解釈 → アクション の順で報告
① 事実：「実際にあったことからお伝えします」
② 解釈：「ここから私の考えです」
③ アクション：「次にやることはこれです」

② トラブル対応：初動と透明性

トラブルは隠した瞬間に最大化する。透明性が信頼を守る唯一の道。

トラブル対応の5ステップ

graph TB
    T1[1. 即時報告<br/>5分以内に第一報] --> T2
    T2[2. 影響範囲の特定<br/>過剰でなく正確に] --> T3
    T3[3. 暫定対応の実施<br/>応急処置] --> T4
    T4[4. 恒久対応の設計<br/>再発防止策] --> T5
    T5[5. 振り返りと共有<br/>同じ轍を踏まない]

    style T1 fill:#ffebee
    style T5 fill:#c8e6c9

トラブル時のNG例

# NG 結果
1 報告を遅らせる 不信感 + 二次被害
2 影響範囲を過小に伝える 後で発覚して致命的に
3 言い訳から入る 責任転嫁と捉えられる
4 担当者ベースで解決する 組織として再発防止できない

③ デッドライン管理：余裕を持って前倒し

「ギリギリで間に合う」は事故の前触れ。前倒し納品が信頼を生む。

バッファ設計の原則

プロジェクト規模 バッファ目安
小（1週間以内） 20%（約1日）
中（1ヶ月以内） 25%（約1週間）
大（3ヶ月以上） 30%（数週間）

期日の守り方

「いつまでに」を必ず明文化
- 口頭の約束は 必ずSlack/メール で残す
- 担当者ベースでなく チームのカレンダー に登録
- 3日前に再確認 のルーチン

期待値マネジメント

クライアントが事前にどんな期待を持つかを相手任せにしない
放置すると過剰期待・間違った期待が発生し、クレームに繋がる。

キックオフ時の期待値調整

項目 確認内容
ゴール 数値・期日・成果物の3点を明確化
役割分担 クライアント側 vs SCALE側で誰が何をやるか
タイムライン フェーズごとのマイルストーン
リスク 想定リスクと対応策を事前共有

「先に言えば説明、後で言えば言いわけ」

クライアントへの要望は面談の冒頭に布石を打つ
商談の最初にポジショニングを伝えることで、価格や進行への納得感を高める。

例：
- 「今回のプロジェクトでは月次報告の他に、随時のSlack共有も入れてもらえますか」
- 「成果が出るまで通常2-3ヶ月かかります。最初の1ヶ月は土台作りに使わせてください」

PM のKPI管理

KPI 目安
契約継続率 90%以上
報告納期遵守率 95%以上
トラブル初動 5分以内に第一報
顧客満足度（NPS） 8以上

今日からやるアクション

  • [ ] 週次報告 のフォーマットを統一
  • [ ] トラブル時の 5分ルール をチーム周知
  • [ ] 全タスクに 20-30%バッファ を設定
  • [ ] キックオフで 期待値調整シート を必ず使う
  • [ ] 要望は 冒頭に布石 で伝える
  • [ ] 月1回 振り返りミーティング を実施

関連ノート