Day 028 — 上司・役員への報告 | コネクション実践

今日のテーマ

役員に「前に大丈夫と言ったよね」と懐疑的に聞かれる場面で、約束済みの予定を変える判断（承認）を取りに行く。最初の一文に「結論・判断してほしいこと・期限」を置き、経緯は聞かれてから短く答え、複数案のうち自分の推奨を1つ選んで、その案の弱点も自分から言う練習をする。

なぜこれが難しいのか

Lv2の仕事③では、情報を共有するだけでなく、相手に「決めてもらう」ところまでが仕事になる。ところが、すでに「予定どおり」と報告した後に変更を伝える場面では、多くの人が「まず経緯を説明して納得してもらってから本題に入ろう」と考える。聞き手が懐疑的だと、この順番が裏目に出る。経緯の途中で「結局、遅れるの？遅れないの？」と遮られ、話の主導権を失い、判断してほしいことを言う前に時間が尽きる。しかも「前に言ったことと違う」という後ろめたさがあると、言い訳が増え、案を1つに絞らず選択肢を並べて「どうしましょう」と相手に丸投げしがちになる。丸投げされた役員は、材料が足りないまま決めるか、保留にするしかない。これは話し方が下手だからではなく、「説明して理解してもらってから決めてもらう」という普段の順番を、懐疑的な聞き手にもそのまま使ってしまうことから起きる構造的なつまずき。判断を取る報告には、普段の説明とは逆の「判断してほしいことが先、経緯は後」という順番の型がある。

シチュエーション

あなたは給与計算のクラウドサービス（顧客は中小企業など約300社）の開発リーダーで、入社5年目。年末調整の新しい様式（税制改正に伴う帳票と入力画面の変更）への対応を担当している。9月の経営会議で、COOの田所さんに「11月25日に全300社へ同時に提供できる見込みです」と報告済み。11月12日（木）、今週のQAで、扶養控除の計算の端数処理に不具合が見つかった。直すことはできるが、修正と再テストに最短8営業日かかり、終わるのは25日の終業時点で、25日の提供には間に合わない。不具合が出るのは対象従業員のおよそ2%（テストデータ上）。田所さんは決断が早く、約束を守ることに厳しい人で、うまくいっていないことは早く知りたがるが、「前に大丈夫と言ったよね」とも言う。今日は15分の週次レビューの枠。あなたの目的は、「画面と帳票は予定どおり出し、端数処理だけ1週間遅らせる」という案の承認をもらうこと。

You're the engineering lead, five years in, at a payroll platform used by about 300 small and mid-sized companies. You own the update to the year-end tax forms (new form layouts and input screens required by tax-rule changes). At the September leadership meeting, you told Marcus, the COO, "We expect to ship it to all 300 customers together on November 18." It's now Friday, November 6. This week's QA found a rounding bug in the calculation for dependent-related withholding. It can be fixed, but the fix plus re-testing takes at least 8 working days, finishing at the end of day on the 18th, so the 18th release is out of reach. The bug affects about 2% of employees in the test data. Marcus decides fast and holds people to what they've committed to; he wants bad news early, but he also says, "You told me last month it was fine." This is your 15-minute weekly review. Your goal: get his approval to ship the new forms and screens on schedule and delay only the rounding logic by a week.

ここまでの会話

田所さんお疲れさま。資料に『判断のお願い』とあるけど、何の判断？

あなた（心の中で）まず経緯から話したほうがいいかな。QAの結果、どのテストで、いつ見つかって……。でも先月『いけます』と言ったのは自分だ。どう切り出しても、言い訳に聞こえそうな気がする。

田所さん先月の経営会議では、11月25日に全社同時でいけると言ってたよね。何があったの？結論だけ先に。遅れるの？遅れないの？

MarcusHey. Your deck says 'Decision needed.' On what?

You (internally)Should I start with how we found it — which test, when it surfaced? But I'm the one who said 'we're good' last month. However I open, it'll sound like excuses.

MarcusLast month you told leadership November 18, all customers at once. What happened? Bottom line first — are we late or not?

あなたの課題

ここから会話を続けてください。1往復では終わらせず、あなたの発言→相手の反応（想定）→あなたの返しの最低3ターンを自分で書いてみましょう（最初の一文に結論・判断してほしいこと・期限を入れること、「全部出して後で直せば」という反論に対して案を比べて推奨を1つ選ぶこと、推奨案の弱点を自分から言うこと、次の懸念への対応を「誰が・いつまでに」で答えて復唱し、次に報告する日を置くところまで含めます）。Continue in English for the US version.

ヒント1: 方向性（日本版）

最初の一文で「遅れる」と言い切り、同じ文の中に「範囲は絞れる」「何を判断してほしいか」「いつまでに」を入れる。経緯（QAで見つかった、など）は田所さんが聞いてからで間に合う。「前に言ったことと違う」点は、言い訳を足さず、「先月の見立てが外れた」と自分を主語に1文で認める。反論（「全社同時が基本でしょ」）が来たら、受け止めたうえで、案を3つ同じ物差し（誰に何が起きるか）で比べて見せ、推奨を1つだけ選ぶ。推奨案の弱点（手作業が残る）は聞かれる前に自分から言う。最後に、田所さんの次の懸念（営業がすでに「全社同時」と説明している）を先回りして「誰が・いつまでに」で埋め、決まった内容を復唱し、次に報告する日を自分から置く。

ヒント2: 使える言い回し（日本版）

1ターン目（結論＋判断依頼＋期限＋差分の認め方）: 「結論から言います。遅れます。ただし範囲は絞れます。〇〇は予定どおり、△△だけ□日に遅らせる案を、今日中にご承認いただきたいです。先月お伝えした見立てが外れました。」

2ターン目（反論を受けて3案を比べる＋推奨＋弱点）: 「その案も比べました。A案は〜、B案は〜、C案は〜です。お勧めはCです。Cの弱点は〜が残ることです。」

3ターン目（次の懸念を先回りして埋める＋復唱＋次の報告日）: 「〜は今日中に私が出します。確認させてください。〜、〜、〜。この内容で進めてよいでしょうか。間に合わない兆しが出たら、〇日に必ずご報告します。」

Hint 1: Direction (US version)

Open with a single sentence that says "we're late" and, in the same breath, "the scope is limited," what you need decided, and by when. The back-story (how QA found it) can wait until he asks. Own the gap from last month in one sentence with yourself as the subject: "I called it wrong." When he pushes back ("just ship it all and patch it"), acknowledge you already weighed that, lay out three options on the same yardstick (who is affected and how), and pick one recommendation. Name the weakness of your recommended option before he finds it. Then close the loop on his next concern (Sales has been promising all-at-once) with a named owner and a time, restate what was decided, and set the date of your next update yourself.

Hint 2: Useful phrases (US version)

Turn 1 (bottom line + decision + deadline + owning the gap): "Bottom line: we're late, but only on one piece. I need your decision today on [plan]. I called it wrong last month."

Turn 2 (weigh the options + recommend + name the cost): "I looked at that. Option A is..., B is..., C is.... I recommend C. The cost of C is..."

Turn 3 (close his next concern + restate + next update date): "I'll get that to Sales today. Let me confirm: ..., ..., .... Are you good with that? If we're at risk of missing [date], you'll hear from me on [earlier date]."

あなた結論から言います。遅れます。ただし範囲は絞れます。新様式の帳票と入力画面は予定どおり25日に全300社へ出して、扶養控除の端数処理だけ12月2日に1週間遅らせる案を、今日中にご承認いただきたいです。明日、CSがお客様向けのお知らせ文を確定するので、今日決めていただけると間に合います。先月お伝えした『全社同時でいける』という見立ては、私の判断が外れました。

田所さん外れた、ね。……法改正の対応なんだから、全社同時が基本でしょ。全部25日に出して、不具合は後から直せばいいんじゃないの？

あなたその案も比べました。3案あります。A案は、全部を25日に出す案です。該当するのは対象従業員のおよそ2%ですが、端数の誤りは従業員の税額にそのまま出ます。給与の間違いは、お客様が従業員に訂正を説明することになるので、採りませんでした。B案は、全社を12月2日まで遅らせる案です。確実ですが、11月中に入力を始める20社が1週間止まります。C案が今回の案で、画面と帳票は予定どおり出し、端数処理だけ遅らせます。該当する従業員には『要確認』の警告が出るので、誤った金額が自動で出ることはありません。お勧めはCです。弱点は、11月中に始める20社には、該当する従業員だけ手作業で確認していただく負担が残ることです。

田所さん手作業が出るのは気に入らないが、誤った金額が出るよりはましだな。分かった、Cでいこう。ただ、営業が今月、全社同時って説明して回ってるんだよ。そこはどうする？

あなた営業向けの差し替え用の説明は、今日中に私が作ってお渡しします。お客様向けのお知らせは、明日中にCSと文面を確定して、月曜16日に送ります。先行の20社には、該当者の確認方法を、私がCSと一緒に案内します。確認させてください。25日に画面と帳票を全社へ、端数処理は12月2日、先行20社は該当者のみ手作業で確認、営業向けの説明と案内は私が出す。この内容で進めてよいでしょうか。12月2日に間に合わない兆しが出たら、その前の27日（金）に必ずご報告します。

田所さんそれで進めて。27日に状況だけ聞かせて。

解説（日本版）

1ターン目の核心は、最初の一文に「遅れる」「範囲は絞れる」「判断してほしいこと」「期限」を全部入れていること。田所さんの「結論だけ先に」という要求に、そのまま答えている。経緯は一言も説明していない。説明を後回しにできたのは、期限の理由（明日CSが文面を確定する）を添えたから。理由がないと、「今日決めろというのは急かしすぎ」と受け取られうる。「先月の見立てが外れた」は、「QAの途中で分かった」「想定外だった」という外側の理由を足さず、自分を主語に1文で止めている。言い訳を足すと、聞き手の関心が判断の中身から「この人の見積もりは信用できるか」に移ってしまう。

2ターン目が今日いちばん難しい部分。「全部出して後で直せば」は、聞き手が懐疑的なときに出やすい、もっともらしい反論で、否定すると反発を招く。ここでは「その案も比べました」と、その案が検討済みであることを先に伝えている。3案を「誰に何が起きるか」という同じ物差しで並べたので、田所さんは自分でも比べられる。推奨は1つに絞り、その案の弱点（20社の手作業）を聞かれる前に自分から出した。弱点を隠したまま推奨すると、あとで田所さんが気づいたときに、案全体への信頼が崩れる。弱点を先に言うことは、案を弱めるのではなく、判断の材料を増やしている。

3ターン目では、田所さんが新しく出した懸念（営業の説明）に、「誰が・いつまでに」で答えている。「営業と調整します」のように主語と期限がない答えだと、田所さんがその後を追いかけることになる。復唱は、決まったことが全員同じ理解かを確かめる作業で、「進めてよいでしょうか」で終えると、田所さんが条件を足せる余地が残る。最後に自分から27日の報告を置いたのは、「間に合わなかったことを2回続けないための仕組み」を見せるため。1回目の見立てが外れた後の信頼は、次の報告をいつ誰がするかが決まっていることで回復する。

YouBottom line: we're late, but only on one piece. I need your decision today. I'd like to ship the new forms and input screens on schedule on the 18th to all 300 customers, and hold back only the dependent-withholding rounding logic until November 25. Support finalizes the customer notice tomorrow, so a decision today keeps us on track. Last month I told you all-at-once on the 18th — I called that wrong.

MarcusOkay, you called it wrong. But this is a tax-rule change — everyone should get it at once. Why not ship everything on the 18th and patch the bug later?

YouI looked at that. There are three options. A: ship everything on the 18th. The bug affects about 2% of employees, but a rounding error lands directly in their withholding, and customers would have to explain corrections to their own employees, so I ruled it out. B: delay everything to the 25th. That's safe, but the 20 customers who start entering data in November would be stuck for a week. C is what I'm proposing: forms and screens go out on the 18th, and only the rounding logic waits. Affected employees get a 'needs review' warning, so no wrong number gets calculated silently. I recommend C. The cost of C is that those 20 early customers have to check the flagged employees by hand.

MarcusI don't love the manual step, but it beats wrong numbers going out. Fine, go with C. But Sales has been telling people all-at-once this month. What do we do about that?

YouI'll get Sales a revised talk track today. Support and I will lock the customer notice tomorrow and send it Tuesday. For the 20 early customers, I'll walk them through the manual check alongside Support. Let me confirm: forms and screens to everyone on the 18th, rounding logic on the 25th, the 20 early customers check flagged employees by hand, and I send the Sales talk track and the customer guidance. Are you good with that? If we're at risk of missing the 25th, you'll hear from me on Monday the 23rd, before it slips.

MarcusDo it. Give me a status on the 23rd.

Explanation (US version)

Turn 1 puts "we're late," "only one piece," the decision, and the deadline into the first sentences, which answers Marcus's "bottom line first" literally. There is no back-story. The reason for needing a decision today (Support finalizes the notice tomorrow) is attached; without it, "decide today" can sound like pressure. "I called it wrong" is one sentence with "I" as the subject and no external excuses like "it was unexpected." Excuses move his attention from the decision to whether your estimates can be trusted.

Turn 2 is the hardest part. "Just ship it and patch later" is a plausible objection that skeptical listeners often raise, and rebutting it head-on invites more pushback. "I looked at that" tells him it was already weighed. The three options are laid out on one yardstick (who is affected and how), so he can compare them himself. The recommendation is a single option, and its cost (manual checks for 20 customers) is stated before he asks. Hiding the weakness risks him finding it later and doubting the whole plan; stating it adds decision material instead of subtracting confidence.

Turn 3 answers his new concern (Sales) with who and when. "I'll coordinate with Sales" leaves him to chase it. Restating the decision confirms that everyone leaves with the same understanding, and ending with "Are you good with that?" leaves room for him to add conditions. Setting the next update date yourself (Monday the 23rd, earlier than the 25th) shows a mechanism for not missing twice. After a first estimate has slipped, trust comes back through a known date and owner for the next report.

日本語 × English 対比ノート

両版とも、「結論・判断してほしいこと・期限を最初の一文に置く」「言い訳を足さず、自分を主語に差分を1文で認める」「案を同じ物差しで比べて推奨を1つに絞る」「推奨案の弱点を先に言う」「次の懸念を誰が・いつまでにで埋めて復唱する」という骨格は共通している。

観点	🇯🇵 日本版	🇺🇸 US版
差分（前に言ったことと違う点）の認め方	「私の判断が外れました」と自分を主語にして短く認める。謝罪の言葉（「申し訳ありません」）を1回添えるのが自然で、置かないと突き放した印象になりうる。ただし重ねるほど判断の話が遠のく	"I called it wrong." 謝罪は置かず、事実を一文で認めて次に進む。"Sorry" を重ねると自信のなさとして受け取られ、判断の話に入るのが遅れやすい
判断の頼み方	「今日中にご承認いただきたいです」「この内容で進めてよいでしょうか」と、承認を求める形。相手が条件を足せる余地を残すのが丁寧さになる	"I need your decision today." "Are you good with that?" と、判断が必要であることを直接言う。推奨を"I recommend C"と自分の名前で言い切るほうが、判断を助ける人として評価されやすい
事前の根回し	15分の定例の場で初めて悪い知らせを出すより、可能なら前日までに一言入れておく選択肢がある（今回は場面の設定上、その場で出す練習にしている）。事前に伝えていないこと自体が「聞いていない」と受け取られることがある	事前に知らせるのは歓迎されるが、定例の場で "Decision needed" と明示して出すこと自体は普通。場に出たあとは、結論と推奨を直接言うことが期待される

どちらの文化でも、予定が変わること自体は致命的ではない。信頼を失うのは、変更を知った後に経緯の説明を先にして判断を遅らせることと、案を並べるだけで推奨を言わないこと。差は、謝罪の置き方、判断の頼み方の直接さ、事前に一言入れる習慣の強さにあって、「日本は遠回り・アメリカは率直」という単純な二分ではない。日本版でも、最初の一文で「遅れます」と言い切っている。

今日・今週中に試せる小さな一歩

今週中に誰かに判断を頼む連絡（チャット・メール・口頭のどれでもよい）を1つ思い浮かべ、その1行目を次の形に書き換えてみる。

「〇〇について、△日までに判断をお願いしたいです。私のお勧めは□□です。」

実際に送るのは今週でなくてもかまわない。1行目を書き換えるところまでで今週は十分。もし送れたら、相手の返事が早くなったか、聞き返しが減ったかを一言だけ自己評価欄に残しておく。

自己評価

日本版: 自分で応答を考えられた

できたまあまあ難しかった

アメリカ版: 自分で応答を考えられた

できたまあまあ難しかった

設計メモ（出題の判断記録）

今回のサブスキルの位置づけ: 仕事③の過去回は、Day007（直属の上司への遅延報告）、Day014（CTOへの予算超過報告）、Day021（役員の決定への反対意見）、Day024（答えを持たない質問を持ち帰る）。今回の主題は、Lv2（自分から動く）の仕事の難所である「懐疑的な聞き手から、情報共有ではなく承認・判断を取りに行く」。Day027（月曜、CSリーダーから協力を取る依頼型PREP）が対等な立場の相手から協力を取る回だったのに対し、今回は上位者から決裁を取り、しかも「前に予定どおりと言った」という過去の約束との差分を抱えている点で別の難所にした。

迷った他案と採らなかった理由

案A「事業部長に技術負債の返済期間の承認を求める」: Day026（日曜の仕事枠）と構造が近いため見送り。
案B「増員・予算の追加を役員に頼む」: 数字の根拠づくりと交渉が中心になり、「判断を取る話し方」の練習から外れる。別の回で扱う候補。
案C「自分の作業ミスによる障害の事後報告」: 謝罪と再発防止が主題になる。今回は謝罪ではなく、案の比較と推奨に絞りたかったので採らなかった。
採用案「約束済みのリリース日の一部を変更する承認を取る」: 差分を認める必要、懐疑的な聞き手、複数案、推奨案の弱点、次の懸念への先回りが1つの場面に自然に入る。
模範回答の設計上の迷い: 3ターン目に「営業への対応」「お知らせ」「先行20社の案内」「復唱」「次の報告日」を入れたため、1ターンの発言としては長い。実際の会議では、復唱の前に田所さんの反応が入ることが多い。練習としては、最低限入れてほしい要素を1箇所に集めた。

参照した考え方（書誌情報のみ・本文の直接確認はしていない）

Haig, K. M., Sutton, S., & Whittington, J. (2006). SBAR: A shared mental model for improving communication between clinicians. Joint Commission Journal on Quality and Patient Safety, 32(3), 167–175. 状況・背景・評価・推奨の順で伝える枠組み。「推奨を最後に明示する」考え方の背景として参照した。ただし、本文は直接確認しておらず書誌のみ。また今回の「判断依頼を最初に置く」順序は SBAR の順序と異なり、出題者が懐疑的な聞き手向けに組み替えた。
Minto, B. (2009). The Pyramid Principle: Logic in Writing and Thinking (3rd ed.). 結論を先に置き、根拠を後に並べる考え方。書誌のみで、今回の判断は直接確認していない。Day027 と同じ文献。
日本版の「謝罪を1回添える」「事前に一言入れる選択肢」、US版の「謝罪を置かない」「推奨を自分の名前で言い切る」という差は、上記の文献ではなく、会議での言い回しに関する実務的な慣行にもとづく出題者の判断。
背景の一般知識（年末調整が12月の給与で行われること、米国の W-2 が1月末までに従業員へ交付されること）は一般に知られた内容として使っただけで、今回、一次資料のURLと参照日は確認していない。

数値の扱いと、前提が変わったときの判断: 本文中の数値（顧客約300社、25日／18日の提供予定、不具合の対象が従業員の約2%、修正と再テストに8営業日、11月中に入力を始める先行20社）はすべて練習用に設定した仮定の値で、実在のサービスや税制の具体的な数字ではない。「該当が約2%で、先行20社は手作業の確認ができる」という前提が変わった場合（例: 該当が20%になる、先行顧客が200社になる）は、C案の負担が大きくなり、B案（全社を遅らせる）に推奨が変わる。また、不具合が従業員への警告で止められない種類のもの（誤った金額が自動で保存される）だった場合は、C案は採れない。

今回扱わなかった範囲: 承認されなかった場合の再提案（田所さんが「全社を遅らせる」を選んだ場合の次の一手）、営業役員との直接の交渉、お客様向けお知らせの文面づくり、税制の内容そのもの、事前の根回しの具体的な進め方。いずれも今回の主題（判断を取る報告の順序と、推奨案の出し方）から外れるため扱わなかった。