LESSON 30分

悪いニュースの伝え方

ストーリー

金曜の午後。あなたは焦っていた。

来週月曜がリリース日なのに、テストで重大なバグが見つかった。 修正には最低2日かかりそうだ。

「渡辺さんに報告しなきゃ......でも、怒られるかな...... 月曜までに何とかなるかもしれないし......」

渡辺マネージャーがたまたま通りかかった。

「何か困ってるのか？」

あなたは意を決して報告した。

「実は......リリース前テストで重大なバグが......」

渡辺マネージャーは真剣な表情で聞いた後、こう言った。

「報告してくれてありがとう。金曜の今聞けたから、 週末のうちに関係者に連絡して、月曜の対応を準備できる。 もし月曜の朝に聞いていたら、パニックになっていたよ」

なぜ悪いニュースを早く伝えるべきか

時間と選択肢の関係

問題発生                                   期限
  │                                        │
  ▼ ← 早期報告                              ▼
  │   選択肢: A, B, C, D, E               │
  │   時間的余裕: 十分                      │
  │                                        │
  │         ← 中間報告                      │
  │           選択肢: A, B, C              │
  │           時間的余裕: ある程度           │
  │                                        │
  │                    ← 直前報告           │
  │                      選択肢: Aのみ      │
  │                      時間的余裕: なし    │

報告が遅れるほど、選択肢が減り、対応が厳しくなります。

早期報告で得られるもの

早期報告のメリット遅延報告のデメリット
対策の選択肢が多い「やるしかない」の一択
マネージャーが調整できる調整する時間がない
チームの応援を得られる1人で抱え込む
信頼が維持される「なぜ言わなかった」と信頼を失う
ストレスが軽減される不安が膨らみ続ける

悪いニュースの伝え方フレームワーク: STAR

要素英語内容
SSituation（状況）何が起きているか
TTiming（時間的影響）いつまでに影響があるか
AAction（対応策）どう対応する予定か
RRequest（依頼）相手に何を求めるか

適用例1: リリース遅延

S: リリース前テストで決済処理の重大バグが見つかりました。
T: 修正に最低2日かかるため、月曜のリリースに間に合いません。
A: 対応案は2つあります。
   A案: リリースを水曜に延期し、バグを修正してからリリース
   B案: 決済機能を除外して月曜にリリースし、水曜に決済機能を追加リリース
R: どちらの案で進めるか、判断をお願いします。
   また、関係者への連絡はこちらで行います。

適用例2: 見積もり超過

S: ユーザー検索機能の実装が、見積もりの5SPより大幅に複雑でした。
T: 当初の金曜完了が来週水曜にずれ込む見込みです。
A: 全文検索のインデックス設計に想定外の工数がかかっています。
   田中さんにフロントエンド部分を先行して進めてもらい、
   バックエンドの遅延の影響を最小化します。
R: 来週のスプリントスコープの調整について相談させてください。

適用例3: 自分のミス

S: テスト環境のデータベースを誤って削除してしまいました。
T: テスト環境が使えない状態で、チーム全体のテスト作業に影響しています。
A: バックアップから復元を進めています。2時間以内に復旧見込みです。
   再発防止として、削除コマンドに確認プロンプトを追加します。
R: テスト作業中のメンバーへの周知をお願いできますか。

伝え方のNG集

やってはいけないこと

NG行動理由代わりにすべきこと
報告しない・隠す問題が大きくなるだけ小さいうちに報告する
言い訳から始める聞き手の信頼を失う事実から始める
他人のせいにするチームの雰囲気が悪くなる自分の関与部分に焦点を当てる
感情的になる冷静な判断を妨げる事実と対策を淡々と伝える
対策なしで報告する「じゃあどうするの？」と言われる必ず対応案を用意する

言い回しの改善例

NG: 「仕様書が曖昧だったので遅れました」
OK: 「仕様の解釈に齟齬があり、手戻りが発生しました。
     今後は実装前に仕様確認のレビューを入れます」

NG: 「多分大丈夫だと思います」
OK: 「現時点の情報では対応可能な見込みですが、
     調査結果を明日までに報告します」

NG: 「すみません、すみません......」
OK: 「状況の報告が遅れ申し訳ありません。
     現在の状況と対策を説明させてください」

報告を受ける側の心構え

チームの心理的安全性を高めるために、報告を受ける側も重要な役割を持ちます。

良い反応

「報告ありがとう。早く教えてくれて助かった」
「原因は後で分析しよう。まず対応を考えよう」
「何かサポートできることはある？」

悪い反応（心理的安全性を壊す）

「なんでもっと早く言わなかったんだ」 ← 次から報告しなくなる
「こんなことも想定できなかったのか」 ← 挑戦を恐れるようになる
「誰のせいだ」 ← 犯人探しの文化になる

エスカレーションの判断基準

どのレベルまでエスカレーションすべきかの判断基準です。

レベル基準エスカレーション先
チーム内で解決1日以内に解決可能、影響がチーム内チームリーダー
マネージャーに報告スケジュール影響あり、スコープ変更の可能性直属のマネージャー
部門長にエスカレーション他チーム・他部門に影響、リリース延期部門長
経営層にエスカレーションビジネスに重大な影響、顧客影響CTO/VP

迷ったら「上」に報告する

エスカレーションが不要だったら「報告ありがとう」で済みます。しかし、エスカレーションが必要だったのにしなかった場合、取り返しがつきません。迷ったら報告する。

まとめ

ポイント内容
基本原則悪いニュースほど早く伝える
フレームワークSTAR（状況、時間的影響、対応策、依頼）
対策を持つ問題だけでなく、対応案をセットで報告する
NG行動隠す、言い訳、他責、感情的、対策なし
エスカレーション迷ったら上に報告する

チェックリスト

  • STARフレームワークで悪いニュースを構成できる
  • 対応案をセットで報告する重要性を理解した
  • 言い回しのNG例と改善例を知っている
  • エスカレーションの判断基準を持っている

次のステップへ

次は演習です。ここまで学んだ報告の基本フレームワーク、デイリースタンドアップ、進捗報告書、悪いニュースの伝え方を使って、報告シミュレーションに挑戦しましょう。

推定読了時間: 30分