本記事の概要
プロジェクトにおいて「順調に進んでいます」という報告を受ける際、PMは多様な可能性を想定しておく必要があります。メンバー個々人で「完了」の基準がわずかに異なっていたり、予期せぬ技術的課題を強い責任感から一人で抱え込んでいたりするなど、言葉の背景には様々な変数が潜んでいるためです。
こうした見えないリスクを早期に拾い上げ、手遅れになるのを防ぐために、私が実践した内容を下記項目に分けて記載しています。
- WBSを物差しとした進捗確認
- 完了条件の共通理解
- 能動的なリスク検知
「HWとSWが密結合するIoTシステム」の開発に基づいています。
このシステムは、センサーが取得した生データ（物理量）をバックエンド等で高度に加工・分析し、ユーザーに意味のあるデータとしてWebUI（Next.js）上の時系列グラフに可視化・制御する構造を持っています。
1人目のSWエンジニア兼PMとして、この不確実性の高い開発をコントロールした知恵を共有しています。
WBSでの進捗確認の徹底
進捗の基本リズムとして週1回のWBS確認を定例化しつつ、WBSをチーム共通の「絶対的な物差し」として位置付けました。WBSは進捗管理をするものだろう、と思われるかもしれませんが進捗管理、プロジェクト管理には様々なツールが存在する中で情報が分散してしまうことを防止する狙いもありました。
個人の判断による勝手なスケジュール変更やタスクの先送りを防ぐため、「変更が発生する、あるいは変更したい場合は必ず事前に連絡・合意する」という運用ルールを徹底。遅延の兆候を検知した際は即座に臨時の確認を行い、その場でWBSを公式に再構築することで、常にチーム全体が同じ正確な地図を持って進める体制を整えました。
完了条件のすり合わせ
単に進捗の言葉だけを受け取るのではなく、「前後のタスクとの依存関係」および「何をもって完了とするかの定義（DoD）」を丁寧に対話ですり合わせました。
あらかじめ認識を合わせておくことで、「実装は終わったが受入基準を満たしていない」といった認識ズレによる終盤の予期せぬ残り作業を回避しました。
日常業務の高負荷を検知
メンバーからの遅延報告がない場合でも、勤務状況に想定以上の高負荷（長時間の残業など）が見られた際は、PM側から能動的に状況を確認しました。
責任感から一人で課題を抱え込み、稼働時間で無理にカバーしようとする事態を防ぐためです。「何か詰まっている要因はないか」と早期に声をかけてブロッカーを取り除くことで、自律的な開発を尊重しつつ、チームの破綻を未然に防ぐ環境を作りました。
振り返り
成果
進捗管理の本質は、監視や疑念ではなく「前提条件を揃え、不確実性に対するセーフティネットを張ること」です。
共通の物差し（WBS）の規律ある運用、丁寧な認識合わせ、そして孤立を防ぐ目配り。この3つのアプローチを組み合わせることが、持続可能で精度の高いプロジェクト推進につながります。
振り返り
- リソースが限られている場合はある程度権限を委譲することになるが進捗管理は単一のツールを使用する
- 長年同じ環境で仕事をしていたら問題ないかもしれないが、タスクの完了条件は人それぞれ異なる場合があるのでしっかり共通認識をとる
- 高負荷の稼働は頑張りの賜物だが、いつ何時心が疲れるかわからないので本人の申告とは別にリスクとして拾うことは必要