「この遅延は、〇〇さんの作業が遅かったためです」——上司からそう説明するよう求められたとき、PMとして何を感じますか。事実の一部は合っているかもしれませんが、そのまま伝えることに違和感を覚えるPMは少なくないはずです。
遅延原因を個人責任として説明することの問題は、再発防止につながらないことです。「次からはもっと速く作業してください」という結論になっても、なぜ遅延が起きたのかの本質は変わりません。また、チーム内の信頼が損なわれ、次に問題が起きたときに報告がさらに遅れる悪循環に入ります。
本記事では、遅延原因を個人責任にしないための事実整理の方法を整理します。
個人責任にすると再発防止にならない
遅延の原因を「〇〇さんの問題」として処理することのリスクを先に確認します。
チームのメンバーが「遅延を報告すると責められる」と感じると、次の遅延が起きたときに早めに報告しなくなります。「なんとかしてから言おう」という心理が働き、発覚が遅れます。
また、特定の個人を原因とした説明は、プロセスや環境の問題を見えなくします。同じプロセス・同じ環境で別の担当者が同じ作業をしたとき、同じ問題が起きる可能性が高いままです。
事実と評価を分ける
遅延原因の整理を始めるとき、まず「事実」と「評価・解釈」を分けてください。
「〇〇さんの作業が遅かった」は評価です。事実は「当初3日を想定していた作業に、実際は8日かかった」です。この事実に対して「なぜ8日かかったのか」を掘り下げることが、整理の出発点になります。
事実を起点に話を進めると、「想定より時間がかかった作業の中で何が起きていたか」を具体的に確認することができます。
原因を5分類で見る
遅延の原因を次の5分類で整理してください。
1. 見積もりの問題——当初の作業見積もりが甘かった。技術的な難しさ、外部依存の複雑さ、テスト工数を過小評価していた。担当者の問題ではなく、見積もりプロセスの問題として扱います。
2. 依存関係の詰まり——前工程の遅延、外部連携先の対応遅れ、確認や承認を待つ時間が予定外に長くなった。担当者が主体的にコントロールできない部分です。
3. 前提・仕様の変更——要件変更や認識のズレが途中で発覚し、手戻りが発生した。変更管理プロセスの問題として整理します。
4. 確認待ち・意思決定待ち——顧客確認、社内承認、ツールのアクセス権対応などの外部要因で、担当者が動けない時間が生じた。
5. 技術的な詰まり——想定していなかった技術的な問題が発生した。これは担当者の経験や技術力に関係することもありますが、「詰まったときに誰に相談できる体制があったか」というプロセスの問題でもあります。
ほとんどの遅延は、この5分類のどれかひとつだけが原因ではなく、複数が絡み合っています。
上司・顧客への説明の型
事実の整理が終わったら、上司や顧客への説明に変換します。
「〇〇機能の開発で当初3日が8日になりました。主な要因は、外部API連携の仕様確認に想定より時間がかかったこと（依存関係）と、テスト工数が見積もりに含まれていなかったこと（見積もり）の2点です。次回以降、外部連携が含まれるタスクについては見積もり時に依存先の確認期間をバッファとして含めます」という形が基本です。
個人の名前を出さずに、事実と要因と再発防止策が伝わる説明になっています。
再発防止につなげる
5分類の整理ができると、再発防止策が具体的になります。
見積もりの問題であれば見積もりプロセスの改善、依存関係の問題であれば依存先の早期確認を計画に組み込む、確認待ちの問題であれば確認期限の管理方法の見直しなど、次の案件から実際に変えられることを決められます。
「注意を払います」「気をつけます」では再発防止として機能しません。「次の案件では〇〇を変える」という具体的な変更を、チームで合意してください。
遅延原因の整理を次の見積もりに活かす方法
遅延原因を整理した結果は、次のプロジェクトの見積もりに直接活かせます。「どの作業で予定より多く時間がかかったか」が把握できれば、次回の見積もり時に同じ種類の作業に適切なバッファを設定できます。
具体的には、「設計フェーズで想定の1.5倍かかった」「テスト修正ループが予定より2サイクル多かった」という事実を記録しておきます。次のプロジェクトで類似の作業が出てきたとき、この記録が見積もり精度を上げる材料になります。
遅延原因の整理を「今回の反省」で終わらせず、「次回の見積もりデータ」として蓄積する習慣が、PMとしての案件精度を年単位で高めていきます。
原因整理をチームビルディングに活かす
遅延原因の整理は、責任追及ではなく「チームとして学ぶ」という文脈で行うことで、チームのモチベーション維持にも役立ちます。
ファシリテーションのポイントは「誰が悪かったか」ではなく「どのプロセスが機能しなかったか」に問いを向けることです。「タスクの完了条件が曖昧だったため、完了したつもりで進んだ」「依存関係の確認が週次定例でしか行われず、ブロックの発見が遅れた」という形でプロセスの問題として語られると、担当者が自責なく参加できます。
建設的な原因整理の経験が積み重なると、チームは「問題があれば早めに言える」という心理的安全性が高まります。炎上の早期発見と炎上後の回復力は、この心理的安全性に大きく依存しています。
遅延原因の整理を顧客説明に活用する
遅延原因を整理した結果は、顧客への説明材料としても活用できます。「なぜ遅延したのか」を問われた際に、「〇〇の作業で予定より〇人日超過したことが主因でした。背景には〇〇という前提の見落としがありました」という形で答えられると、顧客の信頼回復に有効です。
感情的な謝罪より、「事実と原因の整理を伴った説明」の方が顧客に伝わりやすいです。顧客は「なぜ起きたのか」を知りたがっています。その問いに答えられる準備が、遅延原因の整理の実際の価値です。
整理した原因と再発防止策を書面で顧客に提出することで、「言葉だけでなく、対策を考えた」という姿勢を示すことができます。口頭での謝罪に加えて書面で原因と対策を渡す習慣が、受託開発PMとしての信頼を長期的に高めます。
原因整理の場で出た意見を「次の行動」につなげる
遅延原因の整理の場で出た意見は、具体的な「次の行動」に落とし込んで終わらせてください。「コミュニケーションが不足していた」という意見が出た場合、「具体的には何を・いつから・誰が変えるか」まで合意することが重要です。
「週次定例に加えて、木曜日に15分の進捗確認を追加する」「タスクの完了定義を着手前に全員で確認する」という形で、行動が特定されると実行されやすくなります。曖昧な改善方針のまま終わると、1ヶ月後に同じ問題が繰り返されます。
原因整理の場の価値は「問題を言語化すること」ではなく「次の行動を合意すること」です。ファシリテーターとして、意見が出たら「では具体的にどうするか」を必ず問いかけることで、会議を行動につなげてください。
遅延原因の整理は「誰が悪かったか」を明らかにする作業ではなく、「次に同じことが起きないためにプロセスをどう変えるか」を考える場です。チームが責任ではなく改善に集中できる場を作ることが、PMのファシリテーション力として問われています。
チームの信頼を守りながら遅延原因を整理し、再発防止につなげるスキルは、炎上予防・立て直しパックの中で体系的に学べます。法人でのPM育成については法人向けPM育成ページもご参照ください。