仕事①: 何も知らない相手にSDS法（要約→詳細→要約）で緊急トラブルを伝える
状況を何も知らない相手に、緊急のトラブル報告をSDS法（Summary-Details-Summary）で伝え、いきなり詳細やログの話に飛ばずに、相手が迷わず動ける状態まで運ぶ練習をする。
あなたはECサービスのバックエンドエンジニア。夜21時、オンコールのアラートで叩き起こされ、決済処理の一部でユーザーへの二重課金が発生していることが判明した。原因調査で手一杯なため、同じチームだが今は別プロジェクトにアサインされている同僚の田中さんに、インシデント対応Slackチャンネルに来てもらい、状況を伝えて調査を分担してもらう必要がある。田中さんは今回の件をまったく知らない。
You're a backend engineer at an e-commerce company. At 9pm, an on-call alert wakes you up: a subset of users are being double-charged during checkout. You're buried in the investigation, so you pull a teammate, Alex, into the incident Slack huddle to split up the work. Alex hasn't heard anything about this yet.
ここから会話を続けてください。1往復では終わらせず、あなたの発言→相手の反応（想定）→あなたの返しの最低3ターンを自分で書いてみましょう。まず一言で「何が・どのくらい深刻か」という結論を伝え、次に詳細（原因の仮説・影響範囲・発生時刻帯）を説明し、最後に依頼したい具体的なアクションを明確にするところまで含めます。日本版・アメリカ版それぞれで考えてみましょう。
1ターン目は原因やログの話に触れず、「二重課金が発生している」「緊急度が高い」という2点だけをまず言い切っている。これにより田中さんは、詳細を聞く前に「これは急ぎの重い話だ」という心構えができる。2ターン目でようやく詳細（時間帯・対象範囲・原因の仮説）に入るが、ここでも「仮説ですが」と不確かな部分を正直に区別しており、確定していない情報を確定情報のように話していない。3ターン目が最も重要で、抽象的な「調べておいて」ではなく「リトライ機能まわりのログを時系列で」という具体的な担当範囲を切り分け、最後に「今は影響範囲の特定が最優先」と最初の要約に戻ることで、田中さんが余計な調査に手を広げず一点に集中できる状態を作っている。
Turn 1 deliberately withholds the log dashboard and theory, giving Alex only the two things that matter most right away — what's broken and how urgent it is — so they mentally reprioritize before any technical detail lands. Turn 2 adds the details, but is careful to label the theory as unconfirmed ("that's not confirmed yet") rather than stating a guess as fact, which keeps Alex's own investigation open-minded instead of anchored on one idea. Turn 3 is the hardest part: instead of a vague "can you look into the retry stuff," it hands Alex one specific, boundaried task, then explicitly restates the priority (scope, not root cause) so Alex doesn't quietly wander into fixing something else that feels urgent but isn't the current bottleneck.
今週、誰かに何かを説明する機会（Slackメッセージ1本でもよい）があったら、書き始める前に「これを一言でまとめると?」を自分に問いかけ、その一文を最初の行に置いてから詳細を続けてみる。緊急のトラブルである必要はなく、進捗報告や依頼メッセージでも構わない。