今日のフォーカス
相手が失うもの（地位・8年の仕事・お金と信頼）を正確に名指しし、中身を曲げずに、その喪失に見合う言葉と手順を選ぶ。
新任テックリードの「正しいルール」の告知がシニアの怒りを呼んだ理由を、文言ごとに SCARF の5領域で診断する（Q1）。8年続いた自社製品の廃止で、作ったリーダー・チーム・CS・顧客がそれぞれ移行のどの段階にいるかを見立て、最初の30日を設計する（Q2）。自社のバグで3,870万円の過大請求を出した翌日、謝罪の効果と本社法務の「責任を認めるな」の間で、何を事実として認め、何を保留するかを決める（Q3）。
SCARF（Rock 2008）
地位・確実性・自律性・関係性・公平性。告知文を出す前の点検リストとして使う。脳科学の裏づけは強くない。
Transitions（Bridges 1991）
変化は日付で起きる出来事、移行は手放す心理的過程。移行は「終わり」から始まり、ニュートラルゾーンを経て「新しい始まり」へ。
謝罪の6要素（Lewicki ら 2016）
最も効くのは責任の承認、次が修復の申し出。許しの要請は最も効果が小さい。能力の違反では認める方が信頼が戻る（Kim ら 2004）。
Q1
★★★☆☆ 基本
SCARF——「障害を減らすための正しいルール」の告知に、なぜシニアが怒ったのか
シナリオ — 配送ルート最適化SaaS（エンジニア32人） / 着任3ヶ月の新任テックリード
直近四半期の本番障害7件のうち5件が本番DBマイグレーション起因（顧客影響 合計11時間）仮定。あなたは #eng-all に投稿した。
最近マイグレーション起因の障害が多すぎます。来週月曜から、本番DBマイグレーションはすべてプラットフォームチームの承認を必須とします。例外は認めません。詳細はConfluenceを参照してください。
1時間後、在籍10年・40回無事故のシニア、ケンジが返信（スタンプ12個）。
つまり俺たちは信用されてないってことですね。承認待ちで何日止まるんですか。
5件のうち4件は直近半年に入った2チームのマイグレーションだった仮定。
問い
- SCARF の5領域で、投稿のどの文言がどの領域の脅威を生んだかを対応づけて診断せよ
- 「本番マイグレーションに第三者確認を入れる」中身は維持したまま、行動の順序・ケンジとの対話・投稿の書き直しを設計せよ
- SCARF をこの場面で使う限界と注意点を述べよ
「中身が正しいのに通らない」原因の多くは、告知の言葉と手順が地位・見通し・裁量を一度に奪うことにある。鍛えるのは3点：(a) 反発を「感情的な抵抗」とまとめず、どの言葉が何を奪ったかを特定する、(b) 反発を受けて中身まで撤回しない、(c) 反発の中の正当な運用上の要求（承認の所要時間）を見落とさない。
判断の軸：目的（障害を減らす）に必要な制約はどこまでか。それ以上の制約（例外ゼロ・全員一律・所要時間不明）は、目的に寄与しないまま5領域すべてに脅威を上乗せしていないか。
模範解答の核心
ケンジの返信の前半はStatus・Relatedness、後半はCertainty・Autonomyへの反応。後半は承認SLAが無いというルール設計の穴でもある。謝るのは言い方と相談しなかったことで、中身（第三者確認）は変えない。リスク区分・所要時間・期限つき試行・経験者の知見の活用で、5領域を脅威から報酬の側へ動かす。
① 文言と SCARF 領域の対応
| 文言 | 領域 | なぜ |
|---|---|---|
| 「障害が多すぎます」 | Status | 誰の障害かを分けず全員へ、しかも公開チャンネル。40回無事故の人も「起こす側」に含まれた |
| 「すべて…承認を必須」 | Fairness／Relatedness | 5件中4件は特定2チーム。無関係な人にも同じ制約。「プラットフォーム＝門番」の線引き。着任3ヶ月の新任が古参に課す構図 |
| 「例外は認めません」 | Autonomy | 選択の余地ゼロ。列の追加まで同じ手続き |
| 「来週月曜から」「詳細はConfluence」 | Certainty | 所要時間・基準・承認者が本文に無い |
| （相談なしの決定） | Autonomy／Status | 「あなたの経験は要らない」と受け取られる |
② 中身を維持したままの再設計
当日・公開
「言葉が足りませんでした。信用していないという意味ではありません。今日ケンジさんと話して、明日あらためて投稿します。」——中身の議論は公開の場でしない
当日・1対1
障害5件の内訳を見せる（ケンジのチームは0件）。「40回無事故の手順は何ですか」と聞き、チェックリストの原案にしたいと頼む。「何日止まるか」に数字で答える（営業時間内4時間以内仮定）。譲れない一線（第三者確認は入れる）も伝える
翌日まで
ケンジ＋障害を起こした2チームのリード＋プラットフォームで30分。リスク区分とチェックリストを決める
翌日・再告知
下の書き直し案を投稿。6週間の試行、数字で見直すと予告
先四半期の本番障害7件のうち5件がマイグレーション起因で、顧客影響は合計11時間でした。個人の問題ではなく、確認の仕組みが無かったことが原因だと考えています。来週から6週間、次を試します。
・後方互換の変更（列・テーブルの追加など）：チェックリスト（ケンジさんたちの手順をもとに作成）で自己確認し記録を残せば承認不要
・ロックを伴う変更・削除・型変更：プラットフォームのレビュー。営業時間内4時間以内に返答
・緊急時は当番1名の確認で可
6週間後に「障害件数」と「承認待ち時間」で見直し、合わなければ変えます。
・後方互換の変更（列・テーブルの追加など）：チェックリスト（ケンジさんたちの手順をもとに作成）で自己確認し記録を残せば承認不要
・ロックを伴う変更・削除・型変更：プラットフォームのレビュー。営業時間内4時間以内に返答
・緊急時は当番1名の確認で可
6週間後に「障害件数」と「承認待ち時間」で見直し、合わなければ変えます。
③ SCARF の限界と使い方
- 神経科学の裏づけは強くない：Rock（2008）は実務家向け誌の論考。「社会的脅威＝身体的脅威と同じ脳反応」は社会的排除の研究（Eisenberger ら 2003）からの拡張解釈で、5領域も検証された尺度ではない。告知前の点検リストとして使う。
- 診断は仮説：怒りの中心が Status か Certainty かは、1対1で確かめる。
- 過剰適用の罠：反論をすべて脅威反応と見なすと、中身の妥当な指摘まで聞き流す。
迷った他案と採らなかった理由
- 撤回して現状に戻す：顧客影響11時間の原因が残る。「大声で決定が覆る」前例になる。
- 「決まったこと」と押し切る：分割マイグレーションなどの抜け道が生まれ、再発リスクは下がらない。
- 全員説明会：Status の対立が観客つきで拡大する。個別 → 少人数 → 全体の順を採った。
- 前提が変わったら：原因が全体に広がっていたなら、リスク区分の免除は弱め、一律レビューから始めて緩める。
実践への応用
実務・キャリアへの展開
- セキュリティポリシー導入：MFA必須化・本番アクセス申請制は Autonomy と Certainty を奪う。所要時間と例外手続きを最初の告知に書く。
- スタートアップの承認フロー導入：創業メンバーには「今まで信用されていたのに」という Status の脅威として届く。理由と、彼らの知見を設計に入れることを先に示す。
- グローバル：米国チームには理由と数字を先に、日本チームには事前の個別相談を先に。どちらも Certainty と Autonomy への配慮。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q2
★★★★☆ 標準
Bridges の移行モデル——8年続いた製品と、それを作ったチームの「終わり」を先に扱う
シナリオ — 中堅企業向け勤怠・給与SaaS / VPoE
8年続いた自社製「オンプレ連携エージェント」（通称「橋」）を廃止し、クラウドAPI連携に一本化することが3ヶ月前の経営会議で決定。利用顧客46社（ARRの約9%）、移行期限9ヶ月仮定。担当の連携チーム5人（リーダーのミホは在籍8年で「橋」の生みの親）はAPIプラットフォームチームに合流（雇用・処遇は不変）。2週間前の全社告知の中心は「開発速度が上がり、連携先が3倍に増える」という将来像だった。
2週間後：ミホは会議で発言しない／メンバー1人が転職活動中らしい／CSから「顧客に何と説明すれば」／顧客の情シスから「またベンダーの都合か。8年前に稟議を通したのは自分だ」。
問い
- 「変化」と「移行」の違いを説明し、ミホ・メンバー・CS・顧客の情シス・あなた自身が3段階のどこにいるかを位置づけよ。告知の何が問題だったか
- 「終わるもの／終わらないもの」を明示し、最初の30日で誰に・誰から・何を・どの順で伝えるかを設計せよ
- 「ミホに移行プロジェクトのリーダーを任せる」案の利点とリスク、あなたならどう進めるか
リーダーは「新しい始まり」を語りたがるが、Bridges の中心的主張は移行は「終わり」から始まること。終わりを扱わずに将来像を売ると、失う側は「自分の8年は否定された」と受け取る。鍛えるのは (a) 人ごとに段階が違う（決めた側は3ヶ月前に終わりを済ませている）ことを見抜く、(b) 誰が何を失うかを具体的に書き出す、(c) 失う本人に役割を渡すことが敬意にも残酷にもなりうると判断する力。
判断の軸：伝える順序は「影響が最も大きく、最後に知ると最も傷つく人から」。反応を「抵抗」と呼ぶ前に、各人が何を失いかけているかを書き出す。
模範解答の核心
告知の問題は、失う側に「終わり」を言わず、決めた側の「新しい始まり」だけを語ったこと。まずミホとの1対1で告知の不備を認め、「終わるもの／終わらないもの」を明言し、8年を数字で振り返って過去を否定せずに終わらせる。ミホへのリーダー役は任命ではなく打診、PMと品質責任者を分け、2週間考える時間と断る自由を渡す。
① 終わるもの・終わらないもの
| 終わるもの | 終わらないもの |
|---|---|
| 「橋」の新機能開発（即日） | 46社との関係と各社の担当 |
| 「橋」の保守（9ヶ月後） | 5人の雇用・処遇・一緒に働く関係 |
| 「連携チーム」という名前 | 顧客ごとの勤怠データの例外パターンの知識（無いとAPI移行で同じ問題を再発させる） |
② 最初の30日
1〜3日目
ミホと1対1（あなたから）。APIの話はしない。「告知で『橋』の8年に触れなかったのは私の誤り」と認め、何が一番引っかかっているかを聞く
4〜7日目
メンバー各自と1対1（ミホが望めば同席）。合流後3ヶ月の仕事を具体的に示す。転職活動中らしい人を問い詰めず、見通しを渡す
2週目
「橋」の8年を振り返る会。支えた給与計算を数字で示し、「当時はオンプレが多く最適だった。前提が変わった」と説明する（終わりに印をつける）
2週目
CS に説明資料と相談窓口。顧客通知より先に。FAQ・顧客ごとの移行難易度・誰に聞けばよいか
3〜4週目
顧客への個別説明（営業＋連携チーム）を4Pで。並行稼働3ヶ月と移行支援。情シスには「8年前の導入判断は当時正しかった」と明言し、社内での立場を守る
毎週
短い状況共有。情報が途切れると不安が噂で埋まる
③ ミホにリーダーを任せる案
| 利点 | リスク |
|---|---|
| 例外パターンを最もよく知る／顧客の信頼がある／新しい始まりの中の役割（Part）で地位が守られる | 終わりを済ませていない人に「自分の作ったものを片づける役」を課す／移行を遅らせる・旧方式を守る利害の衝突／本人にとって残酷になりうる |
進め方：2回目以降の1対1で「移行の品質責任者（例外パターンの移植と検証）」と「移行全体のPM」を分けて提示し、どちらを担うか、どちらも担わないかを2週間考えて返事してもらう。断っても評価に影響しないと明言する。PMは別の人を置き、ミホが品質側を担うのが、知識と利害の衝突を分けられる配置。
迷った他案と採らなかった理由
- 廃止の決定を見直す：反応の強さは決定の誤りを示さない。判断の前提（ARR9%・保守コスト）は変わっていない。
- 顧客への説明を最優先：CS と連携チームが言葉を持たないまま出ると、ばらばらの説明が混乱を生む。
- 時間が解決するのを待つ：ニュートラルゾーンは放置で長引き、市場価値の高い人から辞める。兆候はすでに出ている。
- 前提が変わったら：期限が3ヶ月（OSサポート終了など）なら儀式は短縮し、役割の明確化と顧客対応を最優先にする。
実践への応用
実務・キャリアへの展開
- レガシー刷新：維持を担ってきた人は最大の知識保有者で、最も多くを失う人。移行計画の前に「誰が何を失うか」の表を作る。
- M&A後の製品統合：買った側は新しい始まり、買われた側は終わりにいる。統合計画に「終わるもの・終わらないもの」を明記する。
- 起業家のピボット：初期顧客と初期メンバーは創業者より遅れて終わりを迎える。マラソン効果の最も分かりやすい例。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q3
★★★★★ 応用
謝罪の6要素と法務の板挟み——自社のバグで顧客に損害を出した翌日、何を言い、何を言わないか
シナリオ — 請求・決済代行SaaSの日本法人（米国デラウェア州の親会社傘下） / エンジニアリング責任者
金曜リリースの為替換算の丸め誤りで、大手小売A社のエンドユーザー1,240人に6日間で計3,870万円の過大請求。A社コールセンターへの問い合わせ900件仮定。原因はレビューの見落としと境界値テストの不足。
A社の担当役員：「まず御社の責任者がきちんと謝罪に来るべきだ。原因と再発防止策を説明してほしい」
米国本社法務：「『責任』『過失』という語を使うな。言ってよいのは "We regret any inconvenience this may have caused." まで。責任上限（直近12ヶ月の手数料＝2,400万円）を超える請求の余地を作るな」
社内：実装した入社2年目のユウタは強く落ち込み、チームには「レビューした人も悪い」という空気。明日午後、代表とあなたがA社を訪問する。
問い
- 謝罪の6要素で (a) 法務の文言、(b) A社が期待する謝罪、を診断せよ。日米の謝罪の意味の違いにも触れよ
- 明日の訪問で「誰が・何を話し・何を話さないか」と、今夜本社法務へ出す対案を設計せよ
- 社外で責任を認めることと社内のブレームレスは矛盾するか。ユウタとチームに訪問の前後で何をするか
謝罪は「誠意」ではなく、どの構成要素が入っているかで効果が測られている技術であり、同時に法的な意味を持つ発言でもある。研究知見・日米の意味の違い・法務の懸念の正当な部分と過剰な部分・社外の責任と社内の心理的安全性、の4つを同時に扱う。「法務に全面服従」「法務を無視して全面謝罪」の両極は、どちらも根拠をもって退けられる。
判断の軸：違反は能力の問題か、誠実さの問題か。事実は確定しているか。この2つで、認めることの利点と不利が入れ替わる。
模範解答の核心
法務の文言は、最も効く2要素（責任の承認・修復の申し出）を両方欠く。「当社のリリースが原因（事実）」は認め、「過失・賠償範囲（法的評価）」は保留する線で、代表が謝罪し、3,870万円の全額返金とコールセンター費用の負担、5営業日で報告書を約束する。法務には、日本語の発言の逐語訳と意味を添え、リスクを比べて示す。社外の組織としての責任と社内のブレームレスは矛盾しない。
① 6要素による診断
| 要素 | 法務の文言 | A社の期待 |
|---|---|---|
| 後悔の表明 | △ "any" "may have" でぼかす | ○ 責任者が来て直接 |
| 何が起きたかの説明 | × | ○ 原因の説明 |
| 責任の承認（最も効く） | × 意図的に除外 | ○ |
| 悔い改めの宣言（再発防止） | × | ○ 再発防止策 |
| 修復の申し出（次に効く） | × | ○（返金と負担は当然の前提） |
| 許しの要請（最も効果が小さい） | × | － 期待していない。省いてよい |
"inconvenience" は3,870万円の過大請求を「不便」と呼ぶことになり、翻訳されて届いた時点で謝罪ではなく軽視になる。Maddux ら（2011）によれば、日本では謝罪が関係修復のための反省の表明として使われ、必ずしも法的な非の自認を意味しないが、米国では非の自認と結びつきやすい。法務の懸念は米国の枠組みでは合理的だが、日本のA社には「責任者が来て非を認めない」が最悪の組み合わせとして届く。
② 訪問の設計と法務への対案
| 内容 | |
|---|---|
| 誰が | 代表（謝罪と約束）＋あなた（技術説明）。ユウタは連れて行かない。個人名も出さない |
| 話すこと | ①「当社がリリースした処理の誤りにより、お客様1,240名に過大請求が発生しました。当社の責任で起きたことであり、深くお詫び申し上げます」②原因：丸め誤りを、当社のレビューとテストの仕組みで防げなかった ③修復：3,870万円はエンドユーザーへ全額返金（手順と日程）、コールセンター対応費 約135万円導出 900件×1,500円（仮定）の負担 ④再発防止：5営業日以内に原因報告書、当面の境界値テスト追加 |
| 話さないこと | 過失の有無の法的な言い回し、間接損害（売上減・信用毀損）の賠償範囲の約束、報告書前の推測 |
リスク比較
(a) 法務の文言のまま → 経営レベルへのエスカレーション、契約解除と公表のリスク。A社の年間取引額 1.8億円仮定は責任上限2,400万円より桁が大きい。(b) 事実の承認＋上限内の修復 → 損失の範囲が限定される
返金の整理
返金は損害賠償ではなく、誤って受け取ったお金を返すこと。責任上限の計算に含まれるかは契約文言次第（要確認）
逐語訳
「当社の責任で起きたことであり、深くお詫び申し上げます」の英訳と、日本の商慣行での意味（関係修復のための責任の引き受けで、賠償範囲の自認ではない）を並べて承認を得る。書面は日本の弁護士の確認を通す
受け入れる点
書面では「過失」の語を使わない。賠償範囲には口頭でも触れない
注意：これは法的助言ではなく交渉の設計。実際の文言は日米双方の弁護士の確認が必要。
③ 社外の責任と社内のブレームレス
矛盾しない。同じ原則の表と裏。社外に引き受けるのは組織の責任（当社の確認の仕組みが防げなかった）で、社内で個人を責めない理由も同じ（1人の見落としで本番に出る仕組みが問題）。社外で「仕組みの問題」と言いながら社内で個人を責めれば、社外への説明が嘘になる。
- 今夜：ユウタと1対1。「明日は代表と私が会社として謝りに行く。謝るのは会社で、君個人ではない」。原因調査に加わるかは本人に選ばせる。睡眠や自責の強さにも注意を払う。
- チームへ：「レビューした人も悪い」を止め、振り返りは「誰が」ではなく「なぜ仕組みが通したか」（境界値テストの基準・為替処理のレビュー観点が無い）で行うと宣言する。
- 訪問後：A社の反応と約束（返金・5営業日の報告書）を共有し、報告書の作成を仕組みの改善として全員で担う。
迷った他案と採らなかった理由
- 法務に全面的に従う：最も効く2要素を欠いた謝罪は信頼を戻さず、契約解除のリスクが責任上限を大きく超える。
- 法務を無視して全面謝罪・賠償も約束：代表とあなた個人が社内規程違反の責任を負う。報告書前に範囲を約束すれば後で撤回し、2度目の信頼毀損を招く。
- 調査完了まで訪問を延期：「まず責任者が来ること」を求められている。延期は逃げと受け取られ、謝罪の効果も時間とともに下がる。
- 前提が変わったら：原因が当社かA社の設定ミスか未確定なら、事実の承認も保留し「共同で調査する」約束と後悔の表明にとどめる。
実践への応用
実務・キャリアへの展開
- SaaSの障害報告：テンプレートに6要素の欄（何が起きたか／当社の責任の範囲／修復／再発防止）を置くと、担当者が変わっても質がぶれない。
- 規制産業：「事実の承認」と「法的評価」の線を事前に法務と合意した定型文を用意しておくと、事故の翌日に迷わない。
- グローバル起業：日本の顧客と米国の投資家・法務に、同じ出来事を2つの意味体系で説明し直す技術は、資金調達や人事でも要る。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
扱わなかった範囲・参照文献
| 問 | 扱わなかった範囲 |
|---|---|
| Q1 | 承認4時間・試行6週間は仮定値（処理能力から導いていない）。SCARF各領域の重みを測る方法（検証された尺度が無い） |
| Q2 | 顧客ごとの移行難易度、移行費用の負担、契約上の通知期間。転職活動中のメンバーの処遇交渉 |
| Q3 | 日米の謝罪の証拠としての扱い・責任上限と返金の関係は法的助言ではなく要確認事項。米国各州の apology law（多くは医療分野）の詳細。謝罪研究の多くは場面を文章で示す実験で、B2B の実取引への当てはまりには限界がある |
- David Rock, "SCARF: a brain-based model for collaborating with and influencing others", NeuroLeadership Journal, Issue 1, 2008
- Eisenberger, Lieberman, Williams, "Does Rejection Hurt? An fMRI Study of Social Exclusion", Science, 302(5643), 2003
- William Bridges, Managing Transitions: Making the Most of Change, Addison-Wesley, 1991
- Lewicki, Polin, Lount, "An Exploration of the Structure of Effective Apologies", Negotiation and Conflict Management Research, 9(2), 2016
- Kim, Ferrin, Cooper, Dirks, "Removing the Shadow of Suspicion…", Journal of Applied Psychology, 89(1), 2004
- Maddux, Kim, Okumura, Brett, "Cultural Differences in the Function and Meaning of Apologies", International Negotiation, 16(3), 2011
- 書誌情報をもとに記載し、本ファイル作成時に原文は再確認していない。数値は書誌以外すべて仮定値または導出値
今日のまとめ・次回へ
次回への接続（明日: IQ-B 批判的思考・認知バイアス）
Q2で経営は「連携先が3倍」と将来像を語り、Q3で法務は「責任を認めれば賠償が膨らむ」と予測した。どちらも自分の立場から見えるリスクと利益だけを大きく見積もっている可能性がある。明日は、立場による見積もりの偏りを認知バイアスとして検出し、数字で確かめる力を鍛える。