一度信用を失うと、その後どれだけ正確に報告しても信じてもらえなくなります。
私はこれを、ある案件の後半でやりました。毎週きちんと定例をやって、報告書も出していたのに、途中から顧客の質問がどんどん細かくなり、最後は「その数字の根拠を出してください」と言われるようになりました。
報告を怠っていたわけではありません。出していた内容が、判断に使えるものではなかったというだけです。
この記事は、説明責任という言葉を定義から説明するものではなく、報告しているのに信用されない状態がなぜ起きるのかを扱います。認識のズレそのものについては認識齟齬がプロジェクトを壊す？成功に導くマネジメント術に分けました。
目次
1. 「順調です」を3か月続けた結果
何が起きたのかを先に書きます。
その案件では、序盤から少しずつ遅れが出ていました。ただ、どれも「来週には巻き返せる」程度の遅れです。なので私は定例で「おおむね順調です」と報告していました。嘘ではありません。その時点では、本当に巻き返せると思っていました。
3か月ほどそれが続いて、終盤で巻き返せないことが確定しました。そこで初めて「2週間ほど遅れます」と報告しました。
顧客の反応は、遅れそのものへの怒りではありませんでした。「先月まで順調と聞いていたのに、なぜ急に2週間なのか」という話です。これは完全にこちらの落ち度で、遅れは急に発生したのではなく、3か月かけて積み上がっていたものでした。私はそれを毎週見ていながら、報告していませんでした。
ここから先が本当に大変で、それ以降は何を報告しても「本当にそうなのか」と確認されるようになりました。信用を失うと、報告に必要な工数そのものが増えます。細かい根拠を求められるので、報告資料の作成に時間を取られ、その分また進捗が落ちる。この悪循環に入ると、抜けるのにかなり時間がかかります。
2. 信用されない報告の3つの型
自分の失敗と、部下の報告を受ける側になってから見えたものを合わせると、信用されない報告には型があります。
丸めすぎる報告。 「順調です」「おおむね問題ありません」。私がやったのがこれです。受け取る側は判断材料をもらえないので、何も判断できません。そして判断材料がないまま時間が経ち、最後に大きな変更を告げられると、それまでの報告が全部疑わしくなります。
事実だけで対策がない報告。 「テストで不具合が30件出ました」で終わる報告です。事実としては正確なのですが、受け取った側は「で、どうするのか」を自分で考えることになります。これが続くと、報告を受けること自体が負担になります。原因の見立てと、次に何をするかがセットになって初めて報告として機能します。
確度が示されない報告。 「来週には終わります」と言われたとき、それが確実なのか希望的観測なのかが区別できません。実際には後者であることが多く、そのまま予定を組まれると外れます。
三つに共通するのは、受け取った側が判断できる形になっていないことです。説明責任というのは、情報を出す義務というより、相手が判断できる形にして渡す義務なのだと思うようになりました。
3. 悪い数字を先に出す
失敗を踏まえて、今は報告の順番を変えています。
以前は、進捗の説明をしてから、最後に懸念事項を話していました。今は逆で、悪い話から先に出します。
理由は二つあります。一つは、後回しにすると時間切れで飛ぶからです。定例の終盤は決まって時間が押していて、そこに置いた議題は「じゃあ次回に」となります。もう一つは、良い話の後に悪い話をすると、隠していた印象を与えることです。
具体的には、次の順で話すようにしています。
- 現時点で計画から外れているもの（数字で）
- その原因と、こちらの見立て
- 打つ手の案と、判断が必要なこと
- 順調に進んでいる部分
4番目は最後で構いません。順調なものについては、相手は何も判断する必要がないからです。
これを始めてから、報告の場が「説明を聞く会」から「相談する場」に変わりました。悪い話を早く出すと、相手も一緒に考える側に回ってくれます。これは想定していなかった効果でした。
4. 確度を分けて伝える
もう一つ変えたのが、見通しを言うときに確度を添えることです。
「来週終わります」ではなく、次のように分けます。
- 確定：作業が終わっていて、確認するだけの状態
- 見込み：想定通りに進めば終わる。前提が崩れたらずれる
- 未確定：やってみないと分からない部分が残っている
特に機械学習の案件では、三つ目が頻繁に発生します。データを見るまで分からない、学習させてみるまで分からない、という作業が普通にあるからです。ここを「見込み」として報告してしまうと、外れたときに信用を削ります。
正直に「この部分は今の段階では読めません」と言うのは、最初はかなり勇気が要りました。プロとして頼りなく見えるのではないかと思っていたからです。ただ、実際にやってみると、読めないことを読めないと言う方が信用されます。外れる予定を自信満々に出す方が、はるかに損をします。
読めない部分をどう見積もりに落とすかはリスクマネジメントの役割とプロジェクトの成功に書きました。
5. トラブルのときに何を出すか
障害や大きな問題が起きたときは、少し扱いが変わります。
このとき一番やってはいけないのが、原因が分かるまで黙っていることです。調査中は報告することがないように感じますが、相手にとっては「何も情報がない時間」が最も不安になります。そして、その間に話が上の方へ独自に伝わっていきます。
私が使っているのは、原因が分からなくても次の三つは出す、という決め方です。
- 今分かっている影響範囲（分かっていない範囲も明示する）
- 現在やっていること
- 次にいつ続報を出すか
三つ目が意外と効きます。「1時間後にまた連絡します」と言っておけば、相手はその間は待てます。何も言わないと、10分おきに問い合わせが来て、対応している人の手が止まります。
なお、こうした情報がそもそも現場から上がってこない場合は、報告の型以前の問題です。そちらはリスク管理の重要性：ITプロジェクトでのベストプラクティスに書きました。私自身、「確認してから持ってきて」という言い方で情報を止めていたことがあります。
6. まとめ
説明責任を果たしているかどうかは、報告を出したかどうかでは決まりませんでした。受け取った側が判断できる形になっているかで決まります。
私の失敗を整理すると、こうなります。
- 「順調です」で3か月丸めた結果、遅れが確定した時点で信用ごと失った。
- 信用を失うと、報告に求められる粒度が上がり、その工数でさらに進捗が落ちる。
- 悪い話を先に出す順番に変えたら、報告の場が相談の場になった。
- 読めない部分を「読めない」と言う方が、外れる予定を出すより信用される。
派手な手法の話ではありませんが、この四つを変えただけで、報告にまつわるやり取りはかなり楽になりました。
報告の中身がそもそもズレる原因については認識齟齬がプロジェクトを壊す？成功に導くマネジメント術に、情報の流れそのものの設計はチームワークを高める：ITプロジェクト管理におけるコミュニケーション戦略に書いています。管理全体の枠組みはITプロジェクトマネジメントの基礎とその重要性です。