「困ったら相談してください。」
「何かあれば早めに共有してください。」
プロジェクトではよく聞く言葉です。
しかし実際には、「何をもって困ったと言えるのか」は人によって判断が異なります。
あるメンバーは30分で相談します。
一方で、あるメンバーは3日間悩み続けます。
これでは、相談するタイミングは個人の判断に依存してしまいます。
そこで重要になるのが、「問題が起きる前兆」を設計することです。
前兆はプロジェクトによって違う
前回の記事では、助けを求めるシグナルを標準化する重要性について紹介しました。
しかし、「何をシグナルにするのか」はプロジェクトによって大きく異なります。
つまり、すべてのプロジェクトに共通する前兆は存在しません。
PMは、そのプロジェクトで何が問題の前兆になるのかを考え、設計する必要があります。
ウォーターフォール型のシステム開発で見られる前兆
例えば、ウォーターフォール型のシステム開発では、次のような前兆があります。
- レビュー指摘件数が急に増えた
- 同じ仕様への質問が繰り返される
- WBSは完了しているのにレビューが終わらない
- タスクの更新が止まっている
これらは、まだ問題ではありません。
しかし、後になって品質問題や納期遅延につながる可能性があります。
EPCプロジェクトで見られる前兆
私が多く経験してきたEPCプロジェクトでは、少し違う前兆があります。
- 他部署からの回答が返ってこない
- 承認待ちが長期間続く
- 設計変更依頼が増えてきた
- 資材納期が変更になった
どれも、その時点では問題になっていません。
しかし放置すると、工程全体へ影響します。
だからこそ、この段階で関係者が集まり、相談や調整を始める必要があります。
アジャイル開発でも前兆は存在する
アジャイル開発では毎日コミュニケーションがあります。
それでも、問題の前兆は存在します。
- 同じタスクが何日も「進行中」のまま
- デイリースクラムで毎日同じ内容を話している
- レビュー待ちが増えている
- ベロシティが急に落ちた
このような変化は、チームが何かにつまずいているサインかもしれません。
前兆には共通する4つの型がある
プロジェクトによって前兆は異なります。
しかし整理してみると、大きく4つの型に分類できると私は考えています。
① 時間
一定期間、状態が変わらないことです。
例
- 承認待ちが3日以上続く
- タスク更新が止まっている
- 回答待ちが長期化している
② 数量
件数や量が急に変化することです。
例
- レビュー指摘件数
- 不具合件数
- 設計変更件数
③ 状態
本来あるべき状態から外れていることです。
例
- レビュー未実施
- Blocked状態
- テスト未着手
④ 変化
普段とは違う変化が起きることです。
例
- 質問が急に増える
- 会議への参加者が減る
- 進捗が急に悪化する
PMが本当に設計するべきもの
ここまで考えると、PMの役割は問題が起きた後に対応することではありません。
また、メンバーへ「早めに相談してください」とお願いすることでもありません。
本当に設計するべきなのは、
「この前兆が現れたら、相談・レビュー・調整を始める。」
というルールです。
つまり、
前兆 → コミュニケーション
を設計することです。
これが、人に依存しないコミュニケーションマネジメントにつながります。
まとめ
相談のタイミングを人に任せると、どうしても遅れが発生します。
だからこそPMは、「何が問題の前兆なのか」を考え、その前兆が現れたら自然とコミュニケーションが始まる仕組みを設計する必要があります。
プロジェクトごとに前兆は異なります。
だからこそ、プロジェクト開始時には、
「このプロジェクトでは、何を前兆として監視するのか。」
をチームで話し合うことが、コミュニケーションマネジメントとリスクマネジメントをつなぐ第一歩になるのではないでしょうか。
おわりに
皆さんのプロジェクトでは、「問題」を管理できていますか。
それとも、「問題の前兆」を管理できていますか。
プロジェクトの成功を左右するのは、問題が起きた後の対応ではありません。
その前にどれだけ前兆に気付き、適切なコミュニケーションにつなげられるかが重要だと私は考えています。
これはCTAサンプルです。
内容を編集するか削除してください。
