仕事③: 先週「見送り」とされた提案を持ち直す。判断を受け止め、違いと依頼を先に言い、却下の理由に答え、止める基準を相手に決めてもらう
先週「見送り」と判断された提案を、1週間後にもう一度持っていく。蒸し返しに聞こえないよう、最初の一文で「先週の判断を受け止めた」「今日は何が違うか」「何をいつまでに決めてほしいか」を言い、却下の理由を相手の言葉で言い直してから、それに答える形で小さくした案を出す。押し返されたら言い返さず、止める基準を相手に決めてもらうところまでを練習する。
あなたは、美容室・整体院向けの予約管理SaaS（契約店舗 約1,800、管理者アカウント 約4,200）の会社で、開発チームのリーダーをしている（入社6年目）。先週の金曜、事業部長の小野寺さん（営業出身・解約率の目標を背負っている・判断は早い）に「全店舗の管理者ログインに二要素認証（SMSコード）を必須にしたい」と提案し、「オーナーさんは年配の方も多い。ログインで詰まったら問い合わせが増えて、それが解約につながる。今は見送り」と判断された。
その後、2つのことが分かった。1つは、ログを見ると、顧客名簿をCSVで書き出せる権限を持つアカウントは約500（全体の約12%）で、そのうち月1回以上書き出しているのは約180しかないこと。もう1つは、大口顧客のヘアサロンチェーンA社（40店舗・年約600万円）の情シス担当から、来年度の取引先セキュリティチェックシートに「管理者ログインの多要素認証」の項目があり、回答期限は10/31、「なし」だと3月の契約更新の評価で減点になる、と連絡があったこと。
あなたは案を作り直した。「CSVを書き出すときだけ二要素をかける。まず営業担当のいない50店舗で30日試す」。今日は金曜、小野寺さんとの定例の15分。
You lead an engineering team at a scheduling SaaS company for salons and spas (about 1,800 locations, about 4,200 admin accounts). Last Friday you proposed to Dana, the GM of the business unit (came up through sales, owns the churn target, decides fast), that every admin login require two-factor authentication by SMS code. Dana said no: "A lot of our owners aren't tech people. If they get stuck logging in, they call support, and frustrated owners churn. Not now."
Since then, you've learned two things. First, the logs show only about 500 accounts (about 12%) have permission to export the client list as a CSV, and only about 180 of those export at least once a month. Second, your largest customer, a 40-location salon chain (about $45K a year), sent its annual vendor security questionnaire. It asks whether admin logins use multi-factor authentication. Answers are due October 31, and their IT lead told you a "no" will count against you at the March renewal.
You've reworked the proposal: require 2FA only when someone exports the client list, and pilot it for 30 days at 50 locations that don't have an assigned account rep. It's Friday, your standing 15-minute one-on-one with Dana.
ここから会話を続けてください。1往復では終わらせず、あなたの発言→相手の反応（想定）→あなたの返しの最低3ターンを自分で書いてみましょう。日本版・アメリカ版それぞれで、次の4点を含めます。
ターン1は、謝罪の前置きを入れていない。代わりに「そのとおりだと思っています」で先週の判断を受け止め、「同じ案ではありません」で違いを宣言し、依頼を「試してよいかだけ」と小さく区切り、期限（来週水曜）を置いた。これで、小野寺さんの「先週決めたよね？」に対して「覆しに来たのではない」が最初の数秒で伝わる。
ターン2が今日の一つ目の山場。小野寺さんは「対象が減っても同じじゃない？」と懐疑から入っている。ここで「セキュリティ上どうしても必要なんです」と言い返すと、相手の懸念（解約）には答えていない同じ話になる。模範回答は、まず相手の懸念を「詰まる→問い合わせ→解約」の連鎖として相手の言葉で言い直し、新案がその連鎖の入口（毎日のログイン）を切っていることを数字（約500、うち月1回以上は約180）で示している。A社の件も「セキュリティ要件」としてではなく、小野寺さんが責任を負う「解約」の言葉で出した。入れても入れなくても解約リスクがある、と比べる土俵を相手の関心にそろえている。
ターン3が二つ目の山場。「殺到したらどうするの」に「大丈夫です」と保証すると、外れたときに自分の信用を失ううえ、相手は不安を抱えたまま判断することになる。模範回答は、止める基準（週10件・解約1件）と戻し方（スイッチ1つ・5分）を用意したうえで、基準そのものを小野寺さんに決めてもらっている。小野寺さんが「5件にして」「営業がついてる店は外して」と条件を足したのは、反対ではなく、自分の判断として引き受けたサイン。ここで「10件でも大丈夫だと思いますが」と押し戻さないのが大事。
ターン4は、足された条件を含めて全体を復唱し、開始日・停止条件・報告日・報告の形（1枚）を自分から置いた。最後の「全面展開は別で決める」は小野寺さんの線引きで、ここで「12月には全面で」と先取りしない。今日取りに来たのは試行の承認であって、全面導入ではない。依頼を小さく区切ったことが、最後まで一貫している。
断られた場合の締め方（模範回答とは別の分岐）: 小野寺さんが「それでも今はやめておこう」と言ったら、「分かりました。どういう数字が出たら再検討の余地がありますか」と条件を聞き、「A社さんの回答期限が10/31なので、10/23の定例でもう一度だけ5分ください。そこで、A社さんへの回答を『予定なし』にするか決めたいです」と、次の判断の日付と、判断しないことの帰結を置いて引く。
Turn 1 skips the apology and leads with the three things Dana needs: last week's call was right, this is different, and here's the exact decision and deadline. In a US one-on-one, "You made the right call" plus new information is enough to make re-raising feel legitimate rather than like relitigating.
Turn 2 is the first hard part. Dana opens skeptical ("Same problem, though"). Arguing "but security really matters" would leave Dana's actual concern untouched. Instead you restate Dana's own causal chain (locked out → support calls → churn), then show the new version cuts it at the start (daily logins unchanged; 500 accounts can export, 180 do monthly). The chain customer is framed as churn risk, which is the metric Dana owns, so both options are now compared on Dana's terms.
Turn 3 is the second hard part. "What if support gets flooded?" invites a promise you can't keep. Instead you hand over the kill switch: a default threshold, a five-minute rollback, and "What number would make you pull the plug?" When Dana tightens it to five and adds a condition, that's Dana owning the decision. You take it without negotiating back up to ten.
Turn 4 reads everything back, including Dana's added conditions, sets the start date, stop criteria, report date and format, and asks permission for the exact questionnaire wording. Dana draws a line ("a full rollout is a separate decision"), and you accept it plainly. You came for a pilot approval, and you leave with exactly that.
If it's still a no (a different branch from the model answer): "Got it. What would you need to see to revisit this?" Then: "Their deadline is the 31st. Can I get five minutes on the 23rd so we decide what we tell them?" If Dana still says no after that, commit to it out loud ("Okay, I'll answer 'not currently' and drop it") instead of raising it a third time without new data.
両版とも、骨格は同じ。先週の判断を受け止める→今日は何が違うかを言う→依頼を小さく区切って期限を置く→却下の理由を相手の言葉で言い直す→新案がその理由のどこに答えるかを数字で示す→新しい事実は相手の関心（解約）の言葉で出す→止める基準を相手に決めてもらう→足された条件ごと復唱する→全面展開という相手の線引きを受け入れる。違いが出るのは次の4点。
| 観点 | 🇯🇵 日本版 | 🇺🇸 US版 |
|---|---|---|
| 持ち直すことへの前置き | 長い謝罪は入れないが、「先週の判断はそのとおりだと思っています」と判断そのものを立てる一言を置く。気になるなら「蒸し返すようで恐縮ですが」を1回だけ添えてもよい | 謝らない。"You made the right call on the full rollout." で受け止め、"This isn't the same pitch." と新情報で正当化する |
| 依頼の言い方 | 「試してよいかだけ、決めていただきたいです」と判断を相手に預ける形 | "I need a yes or no by Wednesday." と二択と期限を直接示す |
| 止める基準の渡し方 | 「この基準でよいか、もっと厳しくするか、決めていただけますか」と、相手が条件を足せる余地を明示する | "What number would make you pull the plug?" と数字そのものを相手に言わせる |
| それでも断られたとき | 「どういう数字が出たら再検討の余地がありますか」と条件を聞き、次の定例で5分もらう。事前に営業課長など周辺に話を通しておく根回しも選択肢 | 条件を聞き、日付を置き、それでも No なら "Okay, I'll drop it" と口に出して従う（disagree and commit） |
どちらの文化でも避けたいのは、却下の理由に答えないまま同じ案を強い言葉で言い直すこと（「でもセキュリティ上どうしても必要で」）、そして相手を飛ばしてさらに上の役員に持っていくこと。前者は「聞いていない」、後者は「信用していない」と受け取られ、提案の中身とは関係なく関係を損なう。持ち直してよいのは新しい事実か、相手の懸念に答える変更があるときで、それが無いなら待つ方がよい。
最小の一歩（1分）: この1〜2か月で、上司や他部署に断られた・保留にされた提案や依頼を1つ思い出す。そのとき相手が言った理由を、相手の言葉のままメモに1行で書く（「忙しいから」ではなく、相手が実際に言った言い回しで）。書けたら達成。持ち直さなくていい。
余裕があれば: その1行の理由に答える「小さくした版」を1文で書いてみる（対象を絞る・期間を区切る・止める条件をつける、のどれか1つでよい）。送らなくていい。もし「新しい事実」が1つでもあるなら、次の1on1の議題メモに1行だけ入れておく。
今回のサブスキルの位置づけ: 仕事③の過去回は、Day007（ベンダー起因の遅延報告）、Day014（予算超過の報告）、Day021（役員の方針への反対意見）、Day024（その場で答えられない質問を持ち帰る）、Day028（Lv2 最初の金曜。遅延を認めたうえで「一部だけ遅らせる」案の承認を取る）。Day028 は「初めて判断を求める」場面だった。今回は Day028 の次回W3候補のうち「承認が却下されたときの再提案」を採った。Lv2 の難所（懐疑・反対から始まる聞き手から、承認・判断を取る）を、一度断った相手というもっとも懐疑の強い形に置いた。新しい型は2つ。「却下の理由を相手の言葉で言い直し、そこに答える変更として出す」と「止める基準を相手に決めてもらう」。
直近回との重なりの確認: Day036（水・W2）も「懐疑的な相手に止める判断を預けて承認を取る」構造だった。今回は、相手（現場のベテラン→事業部長）、場（会議→1on1）、懐疑の理由（過去の失敗→自分が一度下した判断）が異なる。「止める鍵を渡す」の手つきは意図して重ねた（会議で練習した型を、上位者との1on1で使う）。業種は直近の金曜（給与計算・配送・学習サービス・SNS・社内システム移行）と重ならない予約管理SaaSにした。
迷った他案と採らなかった理由
参照した考え方（書誌情報のみ・本文の直接確認はしていない）
数値の扱い: 本文中の数値（契約店舗約1,800、管理者アカウント約4,200、出力権限約500・約12%、月1回以上の出力約180、A社40店舗・年約600万円／US版 約$45K、回答期限10/31、試行50店舗・30日、停止基準 週10件→5件、10/19開始、11/20報告）はすべて練習用に設定した仮定の値。日付の曜日（10/14 水曜、10/19 月曜、10/23・11/20 金曜）は 2026 年の暦で確認した。
今回扱わなかった範囲: 却下の場で即座に食い下がる場合（Lv4）、上司を飛ばして上位者に持っていく判断（Lv3）、他部署（CS・営業）との利害調整（Lv3）、試行結果を報告して全面導入の承認を取る場面（次回以降の候補）、A社への回答文の書き方、二要素認証の方式選定などの技術判断、そして今回の型で実際に承認率が上がるかの測定（本スキルは練習台であり、効果は未測定）。
次回W3候補: 自分の担当範囲の質問に答えられないとき（案A）、試行結果を報告して全面展開の承認を取る（今回の続き。結果が基準ぎりぎりだった場合）。