シナリオ
あなたは引き続き Priya Anand — Director of SRE, Anchorpoint Systems(B2B決済インフラ、ARR約$40M)。物語上の日付は 11/12(木)17:00 UTC、CEO Hannah が主催する四半期投資家セッション(Zoom、約40人)。持ち時間は 6分(ライブデモ約2分+質疑)。
検証レイヤー(DR-2026-014)は 10/23 の試験で本物の障害での切り替えが中央値 2分34秒に遅れた。Aiko の規則(Meridian は CloudEdge と自社監視が割れたときだけ投票)を入れ、11/10 に再試験。基準は結果の前に決めた3つ。10/28 の投資家向けアップデートで Hannah は「11/12 にライブで見せる」と全員に書いた。
11/10 再試験の結果
→ 11/16(月)稼働を確定。11/20〜12/1 は変更凍結(Black Friday・Cyber Monday)。
画面に映すダッシュボード(試験環境)
Failover verification — TEST ENVIRONMENT
タブで走行1と走行2の最終状態を切り替えられます。走行2では、Meridian が途中で必ず灰色(NO DATA)になる——設計どおりだが、知らない人には故障に見える。
重要なコンテキスト
見る場所を先に言い、待ちを説明で埋め、灰色を設計として予告し、代償も含めて数字で結論を言う
ライブデモの観客は話し手の声で成否を判断する。黙ると「失敗」と読まれる
CloudEdge の原因は NDA の対象。過去の3回は "alerts our own monitoring did not confirm"。"false" と言わない
結果の前に決めた。合格を誇張しない・8秒を小さく見せない・壇上でも同じ規則
タスク
パート1 — ライブデモの実況(約2分)
- 冒頭で、何を見せるか(1つだけ・その後に質疑)を言う
- 画面の左(3つの信号)と右(数字1つ)を非技術者の言葉で説明する
- 走行1: 起きる前に「どこを見るか」、起きた後に「9/15 との違い」を一文で
- 走行2: 待ちの間に「何を待っているか」と「なぜ2回か」を説明する
- 灰色の Meridian を、故障ではなく設計として(起きる前に)説明する
- 今日の秒数・再試験の数字・払った代償・基準・結論
パート2 — 質疑
Priya, one minute fifty-two against a two-minute cap. That's eight seconds. Sounds like luck to me. And with Black Friday two weeks out, why not just wait until December?
- 反論を認めつつ、8秒が「何に対する」余裕かを言い直す
- 6回という標本の小ささを自分から認め、どう追うかを言う
- 待つ代償と、悪化したときの戻し方・担当者を言う
パート3 — デモが失敗したときの一言(準備用)
走行2で、2分を過ぎても切り替わらなかった場合に壇上で言う2〜3文。
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
ヒント(段階的開示)
ヒント 1 — 構成・方向性
パート1は「予告 → 画面の地図 → 走行1(見る場所 → 結果 → 9/15との違い)→ 走行2(待ちの説明 → 灰色の予告 → 結果)→ 数字・代償・基準・結論」。原則は「起きる前に言い、起きたら短く確認する」。数字は4つまで(63秒・61秒・1分52秒・旧52秒)。パート2は「認める → 8秒の意味を言い直す → 標本の小ささを先に → 待つ代償 → 戻し方と担当者」。パート3は基準と同じ規則で失敗を判定し、やり直さない。
ヒント 2 — キーフレーズ・表現
- パート1:
"One thing live, then questions."/"Watch the top two lines."/"here's what you're waiting for"/"You'll see Meridian go grey. That's not a fault."/"The bar, set before the test, was ..." - パート2:
"Fair challenge."/"less than half of a month's downtime allowance"/"Six runs is a small sample"/"waiting has a cost too" - パート3:
"counts as a fail, same as in the test"/"Monday's go-live waits until we know why"
ヒント 3 — 骨格テンプレート
パート1:
[走行1: 何の再生か + 見る場所 + down/up で割れる + 動かない + 9/15 との対句]
[走行2: 試験環境・合成 + 約1分 + 待っているもの(2回・30秒間隔)+ なぜ2回か]
[灰色の予告 + 割れたときだけ投票] [There. 63秒]
[再試験の数字 + 旧方式との差 = 代償 + 前に決めた基準 + 月曜に稼働]
パート2:
パート3:
モデル解答(C1〜C2相当)
Thanks, Hannah. One thing live, then questions.
On the left, three signals watching our main region: our cloud provider's status feed, a second vendor called Meridian, and our own monitoring. On the right, the one number that matters: how long until customer traffic moves.
▶ Run 1 starts — replay of INC-088First run. This is a replay of September 15th, one of the three alerts our own monitoring did not confirm. Watch the top two lines. The provider says down. Our own monitoring says up. They disagree, so nothing moves. On September 15th, we moved traffic. Today, we don't.
▶ Run 2 starts — main region cut off (≈60 s wait)Second run. Now a real outage. We're cutting off the main region, in a test environment, with synthetic traffic. This part takes about a minute, so here's what you're waiting for. Our own monitoring needs two failed checks in a row, thirty seconds apart. One failed check is noise. Two is an outage.
⚪ Meridian panel turns grey (expected)You'll see Meridian go grey. That's not a fault. Meridian reports every couple of minutes, so we don't wait for it. It only votes when the other two disagree.
✅ FAILOVER · 63 sThere. Both say down, and traffic moved in sixty-three seconds.
Tuesday's re-test, six outages: median sixty-one seconds, worst one minute fifty-two. The old system did fifty-two, so we paid about nine seconds to stop the unnecessary switches. The bar, set before the test, was seventy-five seconds and two minutes. We met both. We go live on Monday.
... Sounds like luck to me. And with Black Friday two weeks out, why not just wait until December?
Fair challenge. Eight seconds is the margin on our own cap, not on our promise to customers: even the worst run used less than half of a month's downtime allowance. Six runs is a small sample, so we'll report every real event through December in the January update. And waiting has a cost too. The old system is the one that moved traffic three times this year on alerts we couldn't confirm. If the new one misbehaves, Tomás, who runs Black Friday on-call, can switch back to the old one in under five minutes.
That's past two minutes, so on this stage it counts as a fail, same as in the test. I won't rerun it until it works. Aiko will read the logs today, Monday's go-live waits until we know why, and Hannah will tell all of you what we find on Friday.
語数は wc -w の実測(231語/94語/50語)。
解説
構成分析
重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
Watch ... | 命令形で視線を指示。プレゼンでは失礼にならない |
noise | 意味のない一時的な失敗(監視の定番の比喩) |
go grey | 灰色になる。go red / go green とダッシュボード実況で頻出 |
There. | 「ほら」。結果が出た瞬間の合図 |
we paid X to do Y | Y のために X を代償にした。トレードオフの定番 |
the bar | 合否の基準。clear the bar / raise the bar |
Fair challenge. | 挑まれたことを正面から受ける |
margin on X | X に対する余裕。「何に対して」を明示 |
downtime allowance | 停止の許容量。error budget の非技術者向けの言い方 |
switch back | 元に戻す。roll back より非技術者に通じる |
counts as a fail | 不合格として数える |
文化的ポイント
| 日本の職場で起きやすいこと | 英米の投資家向けプレゼンで期待されること |
|---|---|
| デモ中は操作に集中し、無言になる | 待ちの間こそ話す。所要時間を先に言う |
| 「こちらをご覧ください」 | 位置と中身を言う。Zoom ではポインタは見えない |
| 想定外の表示が出てから「仕様です」 | 起きる前に予告する |
| 成功の数字だけを並べる | 代償を自分から数字で言う |
| 鋭い質問に全面撤退、または否定から入る | "Fair challenge." で受け、数字の意味を言い直す |
| デモ失敗で「もう一度やらせてください」 | 失敗として数え、次に何が起き、誰がいつ伝えるかを言う |
数字の根拠(出所の区別)
| 数字 | 区分 | 中身 |
|---|---|---|
| 10/23 の結果・基準(3/3・75秒・2分)・旧方式 52秒 | シナリオ設定 | Day 169 から引き継ぎ |
| 11/10 再試験(3/3・61秒・1分52秒)・デモの 63秒 | シナリオ設定 | 本問のための設定 |
| 余裕 8秒/代償 約9秒 | 導出 | 120 − 112 / 61 − 52 |
| 月の許容 約4分19秒(259.2秒) | 導出 | 30日 × 1,440分 × 0.01%(停止時間 ≒ 切り替え時間の仮定つき) |
| 最悪 = 月の許容の 43% | 導出 | 112 / 259.2 = 0.432(python3) |
| 待ち 約60秒 | 設定+導出 | 確認間隔30秒 × 2回 + 切り替えの実行 |
| 11/10 火・11/12 木・11/16 月・11/20 金 | 確認済み | python3 の strftime('%a') |
| 17:00 UTC = 9:00 PST | 導出 | 米国は 11/1 に夏時間終了。PST = UTC−8 |
| 旧方式へ5分以内に戻せる | シナリオ設定 | 実在の手順の実測ではない |
| パート1 231語 ≒ 約1分45秒 | 実測/仮定 | 語数は wc -w。話速 130〜140語/分は一般的な目安で一次資料未確認。声に出しては測っていない |
迷った他案と採らなかった理由
(1) 待ちの60秒をどう使うか
| 案 | 採らなかった理由 | 前提が変われば |
|---|---|---|
| A. 黙って画面を見せる | 60秒の沈黙は失敗にしか見えない。Zoom では接続の問題とも区別がつかない | 対面で数字が秒ごとに動くなら、10秒程度は黙ってよい |
| B. 雑談・冗談で埋める | 注意を主題からそらし、結果の受け止めが雑になる | 待ちが3分以上で説明が尽きる場合 |
| C. 録画を流す | Hannah が「ライブで」と全員に書いた。当日黙って変えると約束違反 | 事前に録画と告知していれば最も安全 |
| D. 採用 | 所要時間を先に言い、待っている中身と灰色を予告する | |
(2) Derek への答え方
| 案 | 採らなかった理由 | 前提が変われば |
|---|---|---|
| E. "It's not luck — we passed all three." | 否定から入ると議論になり、余裕の小ささに答えていない | — |
| F. "You're right, we should consider waiting." | 決定責任者が壇上で決定を揺らすと「基準は誰も動かさない」が崩れる | Derek が新しい事実を示したなら「持ち帰る」とだけ言う |
| G. 統計で答える(n=6 の信頼区間) | 非技術者40人には伝わらず、6点では幅が大きすぎて安心材料にならない | 技術系の投資家だけ、または書面の補足なら分布図を添える |
| H. 採用 | 認める → 8秒の意味 → 標本の小ささを先に → 待つ代償 → 戻し方と担当者 | |
(3) "false" という語
| 案 | 判断 |
|---|---|
| I. 過去の3回を "false alarms" と言う | 不採用。CloudEdge の警報の誤りを公に断定し、NDA と法務との約束に反する |
| J. 代償の文を "false switches" にする | 不採用。自社の切り替えを指すつもりでも、聞き手が区別する保証が無い。Grace に事前確認できれば可 |
| K. 採用: "unnecessary switches" | 自社の判断(切り替える必要が無かった)だけを言い、警報の真偽に触れない |
よくある日本人のミス
ワンランク上の表現
- "If this goes sideways, here's what happens next." — デモの前に失敗時の手順を予告する、さらに強い型
- "That's the price of ..." — 代償を名詞で言う
- "Nothing up my sleeve: same bar, same rules, live." — 「仕掛けは無い」。場が和んでいるときだけ
この問題で扱わなかった範囲
- CloudEdge が沈黙する本物の障害: Meridian の票を待つので最悪側に寄る。「発展」に回した
- 6回の結果の統計的な扱い: 非技術者向けの場では使わない判断(他案 G)。社内の決定記録では扱うべき
- "false switches" を Grace に事前確認する手順: 他案 J に記録。法務とのやりとり自体は扱わない
- デモ環境の準備(録画のバックアップ・回線・権限): 実務では必須だが英語の練習の範囲外
- Aiko(東京、深夜2時)の参加の是非: Day 170 から残る時差の課題
- 業界の実物との対応(Principles of Chaos Engineering、AWS Well-Architected の game day、Google SRE の error budget、SEC Regulation FD): いずれも記憶による要約で、原文を再取得して確認していない(参照日 2026-10-08)。詳細は MD 版
次のステップ
- 発展: Ben Whitaker が "What if the provider doesn't say anything at all during a real outage?" と聞いた。Meridian の票を待つこと・最悪側に寄ること・それでも2分以内だったことを、NDA に触れず30秒(60〜80語)で答える
- 次回予告(Day 172・金曜): Report/Doc × Engineering