『問題ありませんでした』の何が問題だったのか。PMOが考える、ルールより大切な判断基準

「今日は特に問題ありませんでした」

システムのリリース前に、複数日にわたるリハーサルを実施したときのことです。

私はこのプロジェクトではPMOを担当。PMではないものの、現場ではプロジェクト全体の状況を見ながら、各チームの調整をしたり、問題があれば拾い上げたりと、実質的に現場リーダーに近い動きをしています。

そのため、何かが起きたときには、
「プロジェクト全体として、計画どおり進んでいるか」
という視点で見ます。

今回、そこに大きな認識の違いがありました。

「問題なし」と報告された日のこと

リハーサルでは、本番と同じ流れで作業できるかを確認するため、タイムチャートを作っていました。

何時から何時まで、誰が何の作業をするのか。

関係者でタイムチャートをレビューして確定し、リハーサル中は、毎日その日の結果を報告する場も設けていました。

ある日、
「特に問題ありませんでした」
という報告を受けました。

ところが、リハーサルの約一週間後の別の打合せで、予定作業の一つが未実施なことが発覚。

私が最初に思ったのは、
「いや、それなら、なぜその日に言わなかったの？」
でした。

毎日の報告の場で
「予定していた作業ができませんでした」
と一言伝えてもらえれば、その場で確認できた話です。

ところが報告は、問題なし。

なぜなのか。

事情を聞いてみると、『問題』という言葉に対する認識そのものが、私とは違っていました。

「できなかった。でも問題は起きていない」

作業を実施しなかったこと自体には理由がありました。

ある人から、
「その作業は、その日にはできない」
と聞いたそうです。

できないものは仕方がない。
その作業をしなかったことでシステム障害が起きたわけでもない。
誰かの作業が止まったわけでもない。

だから、
「特に問題は発生していない」
という認識だったようです。

その人の中では筋が通っていますが、私にとっては、プロジェクトとして合意した計画と実際の結果に差分が生まれていること自体が報告対象で、その差分を把握することが重要なのです。

なぜ「作業をしなかった」だけでは済まないのか

今回、その未実施の作業で、すぐにトラブルが起きたわけではありません。それでも私は、プロジェクトとしてはNGだと考えました。

一つ目は、リハーサルの目的にそぐわないからです。

本番に向けて、
「この手順で実際に作業できるのか」
を確認するためのリハーサルなので、予定の作業が実施されなければ、別のタイミングで実施するかどうかを検討しなければいけません。

二つ目は、別の選択肢があった可能性です。

プロジェクト側に共有されていれば、PMや関係者を交えて代替案を検討できたかもしれません。時間を変えたり、別の手順で実施したり、別の担当者に確認することで解消されたかもしれません。

しかし現場だけで、
「できないらしいので、今回はやらない」
と判断してしまえば、その選択肢自体がなくなります。

そして三つ目。

私が特に気になったのは、
「そもそも、なぜ当日になって初めて『できない』と分かったのか」
ということです。

事前に確認できなかったのか。
タイムチャートをレビューした段階で気づくことはできなかったのか。
次のリハーサルや本番で同じことを起こさないために、何を変えればよいのか。

報告されなければ、こうした振り返りも行われません。
つまり今回の問題は、単に一つの作業をしなかったことではありません。
計画と実績に差分が生まれたのに、その差分がプロジェクトに共有されなかったこと。

そこが一番の問題でした。

ルールではなく、判断基準を共有する

今回のようなことが起きるたびに、
「作業できなかった場合は報告する」
「計画を変える場合は確認する」
とルールを追加すれば、今回と同じケースは防げるかもしれません。

しかし、仕事では想定外のケースが次々に出てきます。

100個のルールを作っても、101個目のケースは出てきます。
ルールが増えすぎれば、
「そんなルールがあったんですね」
と言われて、本末転倒の結果を招きます。

そこで必要なのは、細かな行動を一つずつ決めることではなく、「何を報告対象とするのか」という判断基準を共有することだと思います。

今回であれば、リハーサルの前に、

と伝えたうえで、次のような基準を示しておけばよかったのかもしれません。

• ほかのチームに影響する

• 自分だけでは、その判断の責任を持てない

• プロジェクトで合意した計画を変える

このいずれかに当てはまる場合は、現場だけで判断せず、プロジェクト側に返す。

一方、自分の作業の進め方や、結果に影響しない範囲での順番の変更まで、すべて確認する必要はありません。それではPMやPMOがボトルネックになってしまいます。

大切なのは、「自分で判断してよい範囲」と「プロジェクトに判断を返す範囲」の境界線を、事前に共有しておくことです。

「問題ありませんでした」を疑わなくて済むように

今回の本人にとって「問題ありませんでした」は嘘ではありません。

現場にとっての問題は、障害などのトラブルが起きること。
私にとっての問題は、計画と実績に差分が生まれること。

同じ言葉を使っていても、判断基準が違っていたのです。

だから、「普通は報告するでしょう」と言っても解決しません。価値観までそろえる必要もないと思います。

必要なのは、何かを始める前に、

「何を報告対象とするのか」
「どこから先は、自分だけで判断しないのか」

を共有しておくことです。

毎回、「本当に問題なかったのだろうか」と疑っていては、PMもPMOも疲れてしまいます。

ルールを増やす前に、判断基準を共有する。

「問題ありませんでした」という一言から、事前に境界線をそろえておくことの大切さを、あらためて感じました。

小さなズレを「問題なし」で終わらせないために

今回の出来事は、大きな障害にはなりませんでした。しかし、小さな認識のズレや共有漏れを放置した先で、プロジェクトは静かに壊れていきます。

「プロジェクトが静かに壊れる前に— 炎上を未然に防ぐ思考と実務（PM実録）」では、炎上前の小さな違和感をどう見つけ、判断し、動くかを、実際のプロジェクト経験をもとにまとめています。