仕事①: 経緯から書いた長文の依頼に「結局何を・いつまでに?」と返された後、文字の1行目から組み立て直し、相手のルールとぶつかる部分は逃げ道を用意して選んでもらう
経緯から書いた長文の依頼に、法務担当から「結局、何を・いつまでに見ればいいですか? 規約レビューは5営業日いただいています」と返ってきた場面から、文字だけの依頼を組み立て直す練習をする。スレッドの返信の1行目に「お願い・範囲・期限」を置き、理由（期限の根拠）は1つだけ、相手のルールと衝突する部分は言い返さずに「間に合わなかった場合の逃げ道」を自分の側で用意して、相手が選べる形にする。最後に、合意した内容を3行でまとめ直して、文字の上で「はい」をもらうところまで扱う。
あなたは美容室向けの予約管理SaaS（導入約2,300店）を作る会社のバックエンドエンジニアで、入社4年目。いま担当しているのは、無断キャンセル（予約したのに来店しない）のとき、お店がキャンセル料をアプリ上でお客さんのカードに請求できる機能で、リリースは10月22日（木）。
先週金曜の設計レビューで、この機能には利用規約の変更が必要だと分かった。変わるのは3か所（第12条の2「キャンセル料の決済」を新設、第15条「決済手数料」の変更、第21条「免責」に一文追加）。会社の決まりでは、規約の変更はお客さま（店舗）に効力が生じる日の2週間前までにお知らせすることになっている。10月22日に間に合わせるなら、お知らせは10月8日（木）に出す必要があり、その前に法務の確認が要る。
法務は2名のチームで、月に30件ほどの確認依頼を受けている。相手は法務の中川さん（企業法務8年。丁寧だが、締め切り直前に持ち込まれる依頼には厳しい。「規約のレビューは原則5営業日」という受付ルールを作った本人）。今日は10月5日（月）。5営業日だと、10月12日（月）がスポーツの日で休みなので、10月13日（火）になってしまう。
あなたは今朝10時12分、#legal-requests チャンネルに依頼を投稿した。
You're a backend engineer, four years in, at a company that makes booking software for hair salons — about 2,300 salons use it. You're building a feature that lets a salon charge a no-show fee to the client's card on file when someone books and doesn't show up. It ships on Thursday, October 22.
At Friday's design review, the team realized the feature requires changes to the Terms of Service in three places: a new Section 12A ("No-Show Fee Processing"), a change to Section 15 ("Payment Processing Fees"), and one added sentence in Section 21 ("Limitation of Liability"). The company's customer agreement says salons get 14 days' notice before changed terms take effect. To ship on the 22nd, the notice has to go out on Thursday, October 8, and Legal has to sign off before that.
Legal is a two-person team handling about 30 review requests a month. Your contact is Hannah, Senior Counsel — eight years in-house, polite, and not a fan of last-minute requests. She's the one who set up the intake rule: "ToS reviews: five business days." Today is Monday, October 5. Five business days puts you at Monday the 12th.
At 10:12 this morning, you posted in #legal-requests.
このスレッドへの返信を書いてください。1往復では終わらせず、あなたの返信→相手の反応（想定）→あなたの返信の最低3ターンを自分で書いてみましょう（1行目に「何を・どこだけ・いつまでに」を置くこと、期限の根拠は1つに絞ること、遅れたのはこちらの段取りだと1文で認めること、5営業日ルールには言い返さず「間に合わなかった場合の逃げ道」を自分の側で用意して相手が選べる形にすること、最後に合意内容を3行でまとめて文字の上で「はい」をもらうところまで含めます）。日本版・アメリカ版それぞれで考えてみましょう。
1ターン目は、相手の質問「何を・いつまでに」にそのまま答える形で、1行目に範囲（3か所だけ）・形（比較表）・期限（日付と時刻）を置いている。最初の投稿の「今週中に」は、書いた本人は金曜のつもりで、本当の期限は水曜だった。文字では「今週中」「なるべく早く」のような言葉が、読み手ごとに別の日に変わってしまうので、日付と時刻で書く。【お願い】【理由】のような見出しを使うのは、スレッドを後から読み返す人（中川さんのもう1人の同僚や、PM）が、どこがお願いかを探さなくて済むようにするため。背景（無断キャンセルが売上にどれだけ響くか）は、中川さんの判断には要らないので全部削った。遅れの原因は「こちらの段取りの問題です」と1文で自分の側に置き、それ以上は謝らない。謝罪を重ねると、それだけでまた長文になる。
2ターン目が今日いちばん難しい部分。中川さんの返事には、「時間がない」と「お知らせの期間そのものが足りないかもしれない」という、こちらが想定していなかった2つ目の論点が入っている。ここで「そこを何とか」とルールの例外を頼むと、中川さんが作ったルールを中川さん自身に破らせることになる。模範回答では、ルールには触れずに受け止めたうえで、間に合わなかった場合でもこちらが困らない道（請求の機能だけ止めておく）を出している。これで、お願いの中身は「無理をしてください」から「どちらにするか選んでください」に変わる。逃げ道を事前にPMと合意しておいたことが、ここで効いている。合意していない逃げ道を出すと、あとで「やっぱりできない」と取り消すことになり、信頼をもっと削る。また、中川さんが出した「不利な変更かもしれない」という論点を「ご判断の中心」として言い直しているのは、法務の専門的な判断を、こちらが軽く扱っていないことを示すため。
3ターン目は、PREP の最後の Point を文字でやる部分。中川さんの「前回も3日前でしたよね」は、今回の依頼への反対ではなく、繰り返しへの警戒。言い訳をせず「はい、前回も直前でした」と事実を認め、再発防止を「誰が・何を・いつまでに」の形で1つだけ約束している。そのあとに、決まったことを番号つき3行でまとめ直し、「この内容で進めてよいでしょうか」と聞いている。口頭なら「じゃあそれで」で終わる場面でも、文字では、まとめの1通がそのまま記録になる。中川さんの「はい」は、このまとめに対する「はい」なので、あとから「そういう意味ではなかった」がずれにくい。
Turn 1 answers her question in the shape she asked it — what and by when — with labeled lines. "Ask / By / Why" isn't decoration: in a channel thread, other people (her colleague, your PM) will skim it later, and labels let them find the ask without reading everything. The deadline is a date and a time, because "this week" was the original problem: you meant Friday, you needed Wednesday. The salon backstory is gone; it doesn't help her decide. "That's on us" owns the lateness in four words, without a paragraph of apology that would make the message long again.
Turn 2 is the hardest part. Hannah raises two things: no time before Wednesday, and a substantive legal question you hadn't anticipated (adverse change → maybe longer notice). Asking her to bend a rule she wrote would cost you trust. Instead, you acknowledge the rule and offer a fallback you control — ship with the fee switched off. That turns "please rush" into "please choose," and she can say no to the rush without saying no to you. The fallback only works because it's real: already built, already agreed with the PM. A fallback you have to walk back later is worse than none. Naming her legal question as "the part I can't answer" shows you're not treating her expertise as a formality.
Turn 3 is the final Point, in writing. "For the record, last spring too" is a pattern flag, not a rejection. You confirm it ("Fair — same thing happened"), commit to one concrete fix with an owner and a date, then recap in three numbered lines and ask a direct question. Her "Works for me" is a yes to the recap itself — which is now the record anyone can scroll back to.
両版とも、「1行目にお願い（範囲・形・日付と時刻）を置く」「期限の根拠は1つ」「遅れの原因は1文で自分の側に置く」「相手のルールに言い返さず、自分の側で逃げ道を用意して選んでもらう」「相手が出した専門的な論点を判断の中心として扱う」「番号つきで3行にまとめ、文字の上で『はい』をもらう」という骨格は共通している。違いが出るのは次の3点。
| 観点 | 🇯🇵 日本版 | 🇺🇸 US版 |
|---|---|---|
| 1行目の見せ方 | 「分かりにくくてすみません、お願いを整理し直します。」と短い詫びを1回置いてから、【お願い】【理由】の見出しで本文へ。文は敬語の依頼の形（「ご確認いただけないでしょうか」） | "Sorry — that was buried. Here's the ask." のあと、Ask: / By: / Why: のラベルで短い形に。ラベルつきの BLUF は社内の文書やチャットでよく使われ、そっけないとは受け取られにくい |
| 遅れの認め方 | 「こちらの段取りの問題です」「はい、前回も直前でした。すみません」。認めたうえで短い謝罪を添える | "That's on us." "Fair — same thing happened last spring." 責任の所在を短く言い切ることが「認めた」ことになる |
| 選んでもらう言い方 | 「どちらにするかを決めていただくことです」「ご判断の中心は〜の1点だと理解しています」。相手の判断を立てる形で、こちらの理解を確認しながら差し出す | "So it's your call." "That's the part I can't answer." 判断の権限が相手にあることを短く直接言う |
どちらも結論が先であることは同じで、日本版でも1行目はお願いそのものになっている。差は、ラベルの硬さ（【お願い】＋敬語か、Ask: ＋短文か）と、遅れの認め方（短い謝罪を添えるか、責任の所在を言い切るか）にある。「日本は遠回し・アメリカは直接」という二分ではなく、同じ結論ファーストを、どの丁寧さの道具で包むかの違いと考えるとよい。
今週、Slack・Teams・メールのどれかで誰かに何かを頼むとき、送信ボタンを押す前に、本文の中から日付を探す。
頼みごとが今週1つもなければ、先週自分が送った依頼のメッセージを1通開き、「期限が日付で書いてあったか」「それは何行目にあったか」を数えるだけで十分。書き換えて送れたら、返事が来るまでの時間がいつもと違ったかを、一言だけ下の自己評価欄に残しておく。
今回のサブスキルの位置づけ: 仕事①の過去回は、Day003（PREP法・延期報告）、Day010（SDS法・インシデント共有）、Day017（Why→What→How・新人への新機能説明）、Day027（依頼型PREP・遮られた口頭の説明の組み立て直し）。4回とも口頭で、相手がその場で反応してくれる形だった。Day027 で次回候補に挙げた「文字だけでの依頼」を、Lv2（自分から動く）の仕事側の難所「聞き手が懐疑から始まり、承認・判断・協力を取りに行く」に合わせて設計した。過去回に無かった練習は3つ: (1) 文字の1行目の設計、(2) 相手のルールと自分の期限が衝突したときに、例外を頼まず自分の側の逃げ道を用意して選んでもらうこと、(3) 合意を番号つきのまとめで文字の記録にすること。
迷った他案と採らなかった理由
ドメインの前提（出題者の理解。法的助言ではない）
参照した考え方（書誌情報のみ・本文の直接確認はしていない）
数値の扱い: 導入約2,300店、法務2名・月30件、変更3か所、2週間前／14日前のお知らせ、10月22日リリース、比較表A4で1枚、最初の投稿の約12行・お願いが15行目は、練習用の仮定の値。「5営業日で10月13日（火）」は、2026年10月12日（月）がスポーツの日（10月第2月曜）であることから導いた値（10/6・7・8・9・13）。US版の「Monday the 12th」は米国の多くの民間企業が10月第2月曜を休まない前提による。「お知らせは10月8日」は10月22日の14日前として導いた値。
前提が変わる場合
今回扱わなかった範囲: 規約の文言そのものの書き方、店舗へのお知らせ文、キャンセル料の決済に関わる法令（特定商取引法・消費者契約法など）の検討、返信が来ないまま期限が来た場合の催促、上長を経由して法務に頼むべき場合、メールで社外に頼む場合。今日の主題から外れるため、別の回で扱う。