遅延を報告するときの型——事実・影響・選択肢の3点で伝える

遅延の報告は、「事実・影響・選択肢」の3点を、この順番で、短く書くと伝わりやすくなります。謝罪や経緯の説明から入ると、読み手は「結局どうなるのか」を探しながら読むことになり、判断が遅れます。私はディレクターとしても、自分で手を動かす実装担当としても遅れを報告する側に立ってきましたが、揉めにくくなったのはこの型を決めてからでした。

遅れに「気づく」仕組みは以前週次レビューの記事で書きました。今回はその次、気づいた遅れを相手にどう渡すかの話です。

報告が揉めるのは、判断材料が後ろにあるから

遅延報告でよくある書き出しは「大変申し訳ありません。実は先週から〜」です。誠実に見えますが、読み手が知りたいことは別のところにあります。

• いま何が、どれだけ遅れているのか
• それで自分の予定の何が変わるのか
• 自分は何を決めればいいのか

この3つが本文の後ろに埋もれていると、相手は質問を返すしかありません。そのやり取りの間にも日数は進みます。謝罪が不要という意味ではなく、謝罪は判断材料のあとに一言添えれば足りる、と私は考えています。

1. 事実：数字と日付だけで書く

最初の段落には、解釈を入れずに事実だけを置きます。

• 遅れている対象（例：お問い合わせフォームの実装）
• 予定と見込み（例：11/8完了予定 → 11/13見込み、5営業日）
• 原因は一文で（例：外部APIの仕様確認に想定以上の日数がかかったため）

原因を長く書きたくなるのは、たいてい自分を守りたいときです。経緯は聞かれたら答えればよく、最初の報告では一文に留めます。「〜かもしれない」も避け、わからない部分は「11/6に確定します」と、わかる日を書きます。

2. 影響：相手の予定に翻訳する

次に、その遅れが相手側の何に効くかを書きます。ここが抜けると、事実だけ渡されても相手は重さを測れません。

書き方	相手が受け取るもの
実装が5日遅れます	「それで？」が残る
確認開始が11/15→11/20になります	自分の予定表と照らせる
公開日11/30には影響しません	安心してよいかがわかる

ガントチャートで依存を引いておくと、この翻訳がしやすくなります。遅れたタスクがクリティカルパス上にあるかどうかで、公開日に効くかが決まるからです。影響がない場合も「影響なし」と明記します。書かないと、相手は最悪の場合を想像します。

3. 選択肢：決めてほしいことを問いの形にする

最後に、相手に決めてもらう選択肢を2〜3個並べます。

• A案：公開日を12/4にずらし、範囲はそのまま
• B案：公開日は守り、フォームの自動返信を第2弾に回す
• C案：確認期間を5日から3日に縮める（確認側の負担が増える）

それぞれに失うものを一言添え、私ならどれを選ぶかも書きます。ただし決めるのは相手です。そして「11/6までにご判断いただけると、どの案でも間に合います」と、判断の期限を付けます。期限がないと、選択肢を出したこと自体が宙に浮きます。

送るタイミングは「確定してから」ではなく「気づいてから」

遅れが確定してから報告すると、選択肢がほとんど残っていません。私は「見込みがずれた」と気づいた時点で、わかっている範囲を送るようにしています。

この考え方は障害対応の文脈でも語られています。GoogleのSRE本「Managing Incidents」の章では、コミュニケーション担当を置き、関係者へ定期的に状況を更新する役割が説明されています。制作の遅延は障害ほど急ぎませんが、「状況が固まるまで黙る」より「決まった間隔で途中経過を渡す」ほうが、相手が動ける点は同じだと感じます。続報の日付を最初の報告に書いておくと、相手も追いかける必要がなくなります。

明日から試せる一手

報告用のテンプレートを1つ、手元に作っておいてください。見出しは「事実」「影響」「選択肢（判断期限つき）」「次の報告日」の4つだけで十分です。遅れに気づいたとき、白紙から文章を考えると、どうしても謝罪と言い訳から書き始めてしまいます。枠が先にあれば、埋めるだけで判断材料が前に並びます。