仕事①: 期待より弱かった結果を、良い知らせから話して聞き返された後、両方の数字で言い直し、約束どおりやめたうえで小さな提案に判断をもらう
2週間前に協力をお願いした相手（Day027 の CS リーダー・松本さん）に、期待より弱かった結果を報告する練習をする。つい「いい知らせ」から話し始めてしまい、悪い数字をすでに手元に持っている相手から「正直、何件中何件分かったの? で、減るの?」と聞き返された場面から、結論を良い数字と悪い数字の両方で言い直し、約束していた「やめる」を自分から先に言い、そのうえで小さな提案に判断をもらうところまで扱う。
あなたは飲食店向けのモバイルオーダー（お客さんがテーブルの QR コードを読み取り、自分のスマホから注文するサービス。導入約450店）の会社のバックエンドエンジニアで、入社3年目。
2週間前（Day027）、CS チームリーダーの松本さん（CS 歴10年、店長さんからの信頼が厚く、チームの対応時間を守ることに厳しい）にお願いして、「注文が厨房に届かない」という問い合わせのときだけ、お客さんがどの画面で止まったかを選択肢から1つ選んでもらう記録を、9月30日（水）から10月13日（火）までの2週間つけてもらった。分からなければ「不明」でいい、という条件つき。そのときあなたは、「10月14日に件数と分かった原因を直接報告する」「何も分からなかったら、その日に項目は消す」「役に立っても、11月末に自動で取れるようになったら消す」と約束している。
2週間の結果は次のとおり。
あなたは準備の段階で、「半分以上は画面が分かるだろう」と見込んでいた。実際には「不明」が18件中11件だった。また、直すにはタブレット側の更新が要るので、自動で画面を取る改修と同じ11月末の更新まで、問い合わせ自体は減らない。
一方で、1つ使えそうなことに気づいた。注文はサーバーには届いているので、厨房タブレットの注文一覧で「更新」ボタンを押せば、その場で注文が出てくるはずだ。検証用のタブレット3台で Wi-Fi を20秒切って試したところ、3台とも「更新」で注文が表示された。
今日は報告の当日、10月14日（水）の15時。ランチのピークが終わった時間に、松本さんに15分もらって CS の島の横の打ち合わせスペースに座った。松本さんの手元には、CS の記録画面から出した集計の紙がある。
You're a backend engineer, three years in, at a company that makes mobile ordering software for restaurants — guests scan a QR code at the table and order from their own phone. About 450 restaurants use it.
Two weeks ago (Day 027), you asked Denise, the Support team lead — twelve years in restaurant support, trusted by the managers, fiercely protective of her agents' handle time — for a favor: on "order didn't reach the kitchen" tickets only, have agents pick which screen the guest got stuck on, from Wednesday, September 30 through Tuesday, October 13. "Unknown" was explicitly fine. You promised: "You'll hear from me on October 14th. If it tells us nothing, I pull the field that day. If it helps, it still comes out at the end of November."
Here's what came back:
Going in, you'd expected at least half the tickets to come back with a screen. They didn't — 11 of 18 were "unknown." And the fix requires a tablet update, so it ships with the auto-capture update at the end of November. Until then, the tickets won't go down.
One thing looks useful, though. Since the orders do reach the server, tapping "Refresh" on the kitchen tablet's order list should make the missing order appear right away. You tested it on three test tablets — killed the Wi-Fi for 20 seconds — and the order showed up after a refresh on all three.
It's Wednesday, October 14, 3:00 p.m. The lunch rush is over, and you've got 15 minutes with Denise at the small table next to the Support pod. She has a printout of the dropdown counts from the Support tool in front of her.
ここから会話を続けてください。1往復では終わらせず、あなたの発言→相手の反応（想定）→あなたの返しの最低3ターンを自分で書いてみましょう。含めること: (1) 結論を良い数字と悪い数字の両方で言い直す（何件中何件分かったか／分からなかったか、見込みと比べてどうだったか）、(2) 自分で約束した「やめる」を聞かれる前に自分から言う、(3)「減るのか」には減らない時期を正直に答えたうえで、その間にできることを判断をお願いする形で1つだけ出す、(4) 提案への反論（「効かなかったら余計こじれる」「また記録が増えるのでは」）に言い返さず、条件と報告日とやめる条件を添えてその場で「はい」をもらう。
1ターン目は、PREP の最初の Point を「両方の数字」で言い直す部分。松本さんは「不明」が多いことをすでに知っているので、こちらが良い数字だけを強調すると、残りを隠しているように見える。「いいほうから話してしまいました」と順番の誤りだけを短く認め、言い訳は足さない。数字は「分かった8件」と「分からない10件」を同じ文の重さで並べ、見込み（半分以上）と比べて「期待より弱い」と自分で評価している。評価を相手に言わせないことで、松本さんは「この人の報告は盛られていない」と判断でき、このあとの提案の数字も信じてもらいやすくなる。「松本さんが最初におっしゃったとおり」は、2週間前の反論が正しかったことを認める一言。最後に「項目は今日で外します」を聞かれる前に言っているのが大事なところ。少し成果が出た以上、延長を頼みたくなるが、それをすると松本さんが一番警戒していた「頼んだ項目がずっと残る」を自分で起こしてしまう。
2ターン目が今日いちばん難しい部分。「減るの?」に対して、「ただ」「一方で」から始めたくなるのをこらえ、「11月末までは減りません」を先に言う。悪い答えを先に言い切ってから、その間にできること（更新ボタンの案内）を出すと、提案が「悪い答えをごまかすための話題そらし」に見えない。提案の根拠は「検証用タブレット3台で試した」1つだけ。お願いの形も「やってください」ではなく「案内に入れるかどうかを決めてください」にして、判断を松本さんに預けている。CS の案内文は CS の持ち物なので、エンジニアが決めるものではない。
3ターン目は、提案への反論への対応。「出てこなかったら?」に対しては、こちらから「半分より少し多い」と効かない割合を言っている。ここで「たぶん大丈夫です」と言うと、1ターン目で作った「盛らない人」という信用を自分で崩してしまう。効かない場合を前提にして「一度だけ試して、出なければいつもの手順へ」「30秒くらい」と、失敗したときの損を小さくした。「また記録?」には、記録が要らない理由（ログで分かる）で答えている。2週間前の協力でいちばん負担だったのが記録だったので、それを増やさないことがこの場面で一番効く譲歩になる。締めは Day027 と同じく、報告日（11月4日）・やめる条件・自分が引き受けること（文面を書く）の3つ。「18件すべて、入力漏れがありませんでした」と数字で返しているのは、相手のチームの手間に具体的にお礼を言うため。
Turn 1 resets without an apology — "Fair — I led with the good part" names the mistake and moves on. The scorecard puts the win (8 found) and the miss (10 unexplained, 11 unknown) at the same volume. Stating the expectation ("half or better") and grading yourself ("came in under") is what makes the rest of the meeting credible: Denise now knows you won't spin the numbers. "You called it" gives her credit for the objection she raised two weeks ago. And "As promised, the dropdown comes out today" — said before she can ask — is the most important line. A partial win makes it tempting to ask for two more weeks; doing that would confirm her fear that fields never go away.
Turn 2 is the hardest. "Not until the end of November" has to come first, flat, with no "but" in front of it. Only after the bad answer is on the table does the recommendation land as help rather than deflection. "My recommendation:" states your view in the first person, which is the expected move in a US workplace; "Do you want that in your agents' script?" then hands the decision to the person who owns the script.
Turn 3 handles the pushback by volunteering the failure rate before she can push harder. Saying "it'll probably work" would undo the credibility you built in turn 1. Instead, you shrink the cost of failure — once, thirty seconds, then the normal flow — and remove the thing that actually cost her team two weeks ago: logging. The close mirrors the original deal: a date, a kill condition, and work you take on yourself. "Eighteen for eighteen" turns a generic thank-you into a specific one her team will hear.
両版とも、「聞かれた質問（何件中何件／減るのか）に数字と言い切りで先に答える」「良い数字と悪い数字を同じ重さで並べ、見込みと比べて自分で評価する」「相手の2週間前の予想が当たったことを認める」「約束していた『やめる』を聞かれる前に言う」「悪い答えを先に言い切ってから提案を出す」「効かない割合を自分から言い、失敗したときの損を小さくする」「報告日・やめる条件・自分が引き受けることで締める」という骨格は共通している。違いが出るのは次の3点。
| 観点 | 🇯🇵 日本版 | 🇺🇸 US版 |
|---|---|---|
| 順番の誤りの直し方 | 「すみません、いいほうから話してしまいました。数字から言い直します」。短い詫びを1回置いてから数字へ | "Fair — I led with the good part. Here's the scorecard." 詫びは入れず、誤りに名前をつけてすぐ数字へ。scorecard（成績表）で「良し悪し両方を出す」ことを予告する |
| 相手の予想が当たったことの認め方 | 「松本さんが最初におっしゃったとおり」。相手の見立てを立てる形で、敬語のまま認める | "You called it." 短く、相手の判断力を評価する言い方。持ち上げすぎず、事実として言う |
| 提案の出し方 | 「〜を案内に入れるかどうかを、決めていただきたいんです」。自分の推奨を前面に出さず、判断を相手に預ける形で差し出す（推奨は内容から伝わる） | "My recommendation: ..." と自分の推奨を一人称で言い切ったうえで "Do you want that in your agents' script?" と判断を渡す。推奨を言わずに選ばせると、かえって「考えていない」と見られやすい |
一方、「期待より弱い」と自分で言うこと（「正直、期待より弱い結果です」／"this came in under what I expected"）は、両方の版でほぼ同じ強さで入れている。結果を自分で採点する行為は、日本でもアメリカでも「盛らない人」という信用につながる。差は、それを包む丁寧さの道具（短い詫び・敬語・判断を預ける形か、詫びなし・一人称の推奨・yes/no の確認か）にある。
今週、誰かに結果や進み具合を伝えるとき（Slack の1行、朝会の一言、メールの冒頭、どれでもいい）、最初の1文に良い数字と、足りなかった数字を1つずつ入れる。
伝える場面が今週なければ、先週自分が送った報告を1通だけ開き、「悪いほうの数字は何行目にあったか」を数えるだけで十分。1行目に入れて送れたら、相手からの質問がいつもより少なかったかどうかを、一言だけ下の自己評価欄に残しておく。
今回のサブスキルの位置づけ: 仕事①の過去回は、Day003（PREP法・延期報告）、Day010（SDS法・インシデント共有）、Day017（Why→What→How・新人への新機能説明）、Day027（依頼型PREP・遮られた口頭の説明の組み立て直し）、Day034（文字の依頼の1行目）。5回とも「これから何かをお願いする／伝える」場面で、終わったことの結果を報告する場面は無かった。Day027 と Day034 で次回候補に挙げていた「10月14日の松本さんへの結果報告（期待より弱かった場合）」を、Lv2 の仕事側の難所「聞き手が懐疑から始まり、承認・判断を取りに行く」に合わせて設計した。新しい練習は3つ: (1) Point が2つある報告で両方を1文目に並べる、(2) 自分で約束した「やめる」を、成果が少し出たときに自分から実行する、(3) 悪い答え（減らない）を言い切った後に、小さな提案で判断をもらう。
日付の扱い: 実行日の今日（2026-10-12・月）はスポーツの日で、日本の多くの職場は休み。場面は Day027 で約束した報告日の10月14日（水）に置き、「明後日の本番の予行」として使えるようにした。Day034 では「未来の日付になる」ことを理由にこの案を見送ったが、今回は2日後で、報告日そのものが Day027 の約束として決まっているので採用した。
迷った他案と採らなかった理由
ドメインの前提（出題者の理解）
Last-Event-ID の仕組みがあり、WebSocket（RFC 6455）の規格そのものには取りこぼしを送り直す仕組みが無くアプリ側で作る必要がある、と理解している（参照先: WHATWG HTML Living Standard「Server-sent events」、IETF RFC 6455。原文の該当箇所は今回未確認）。直すには端末側の変更が要るので、修正は「11月末のタブレット更新」に入る、という設定。参照した考え方（書誌情報のみ・本文の直接確認はしていない）
数値の扱い: 仮定の値は、導入約450店、つなぎ直し約20秒、検証用タブレット3台、案内1回約30秒、「半分以上は画面が分かる」という見込み、7件の内訳、原因が一致した件数（4件＋4件）。導出した値は、18件（Day027 の「先月38件」÷30日×14日 ≒ 17.7）、不明11/18 ≒ 61%、原因判明8/18 ≒ 44%、未判明10/18 ≒ 56%（「半分より少し多い」）、先月の判明率9/38 ≒ 24%、次回報告日11月4日（水）＝10月14日の3週間後。「入力漏れ0件」はお礼を数字で言うための設定で、実際の運用では入力率が下がることも多い。
前提が変わる場合
今回扱わなかった範囲: 取りこぼしの技術的な直し方の詳細、残り10件の調査の進め方、店長さんへの個別のお詫び、CS の案内文そのものの書き方、文字での結果報告、上長を交えた報告。今日の主題から外れるため別の回で扱う。次回 W1 候補: 返信が来ないまま期限が近づいたときの催促の1行目（Day034 から持ち越し）、11月4日の松本さんへの2回目の報告（案内が効かなかった場合）。