シナリオ
あなたは引き続き Priya Anand — Director of SRE, Anchorpoint Systems（B2B決済インフラ、ARR約$40M）です。ここまでの経緯と、これからの日程です。
今日は金曜（9/25）の11時。Marcusからメールで承認が届きました。ただし条件が2つ付いています。
Marcusの条件は鋭い指摘です。「2つの信号が両方そろったときだけ切り替える」設計は誤検知（false positive）を消す代わりに、CloudEdgeが障害を報告しない本物の障害では自動で切り替わらない（false negative）という新しい弱点を持ち込みます。これは受け入れたリスクとして記録に残す必要があります。
SREチームには、重要な判断を決定記録（decision record）として社内Wikiに残す決まりがあります。形式は Michael Nygard の ADR（Architecture Decision Record）を土台にした社内テンプレートで、番号は DR-2026-014 です。この記録を半年後に読む人は、今週のSlackもプレゼンも知りません。
もう一つ厄介な点があります。社内Wikiを検索すると、9/18の初版メモ（$180Kの誤った数字入り）が出てきます。決定記録の側でこの数字に触れなければ、半年後の誰かが$180Kを引用するかもしれません。
重要なコンテキスト
(1) 何を決めたか・誰が承認したかを日付つきで一目で (2) 採らなかった案（D・E）と理由を残す (3) 受け入れた弱点と未承認の継続費用を隠さない (4) 止める条件と見直す日 (5) 初版の$180Kの訂正
"as discussed"・"this week"・"tomorrow"・"the team" など、今週を知っている人にしか通じない言葉。日付は年まで書き、略語は初出で開く
タスク
社内Wikiに載せる決定記録 DR-2026-014 を英語で書いてください。下の見出しを埋めます。
Phase 4 の目安（300〜600語）を少し超えます。見出しが7つあり、各見出しを2〜3文で書くとこの量になるためです。
使える表現・フレーズ
カードをクリックすると英語フレーズを表示します。
ヒント（段階的開示）
ヒント 1 — 構成・方向性
決定記録は「説得の文書」ではなく「半年後の人への引き継ぎ」です。9/18のメモのように承認を取りにいく書き方（緊急性を訴える・相手の関心に合わせる）は要りません。基準は読み手が今週を知らなくても一人で判断できるかです。
- Summary だけ読んだ人が、何が決まり、失敗したらどうなるかを知れること
- Options Considered は、半年後に誰かが「Black Friday週だけ自動切替を止めればタダでは？」と言い出したとき、この記録を指せば済むように
- Consequences には都合の悪いことを。false negative と未承認の0.5 FTEが、この記録で一番価値のある部分
ヒント 2 — キーフレーズ（表現）
"Once this change ships (no later than November 6, 2026), automated regional failover will trigger only when CloudEdge's status API and our own synthetic checkout probes both report a failure.""The original request memo (September 18, 2026) cited a '$180K revenue impact'. That figure was total payment volume (TPV) rerouted, not revenue; the actual fee impact was about $600. Do not reuse the $180K figure.""We will assign two of our six SREs for three two-week sprints (September 28 – November 6, 2026) ...""Rejected as the primary plan ... Retained as the fallback.""A failure mode we are knowingly accepting: because both signals must agree, a real outage that CloudEdge does not report will no longer trigger automated failover.""Revisit by January 29, 2027, or earlier if CloudEdge changes its status API or we add a second cloud provider."
ヒント 3 — 骨格テンプレート
Status: Accepted — [日付] ([承認された範囲]). [承認されていない部分と期限].
Deciders: [名前（役職）] ... | Author: ... | Consulted: ...
SUMMARY
[いつから（完了期限）＋何が変わるか]. [10/23に不合格なら何をするか].
CONTEXT
[3回の誤検知: 期間と日付]. [いまの仕組みの弱点: 信号が1つ].
[3x / 6x → 試験済みの2倍]. [$750Kと前提3つ].
Note on figures: [初版の$180K → 正しくはTPV、手数料は約$600]. Do not reuse ...
DECISION
We will [人数・期間・日付・費用]. [仕組み: 両方が一致しなければ切り替えない].
OPTIONS CONSIDERED
D. [中身・費用]. Rejected as the primary plan because [理由と数字]. Retained as the fallback.
E. [中身]. Rejected because [理由].
No action. Rejected because [理由].
CONSEQUENCES
[良い結果]. [Observabilityの遅れ: 月で]. [false negative: 受け入れる理由と緩和策]. [0.5 FTE未承認].
CONFIRMATION & STOP CONDITIONS
On [日付] we will [5ケース（誤検知3件の再生＋本物の障害2種）と期待する動き]. If any case fails, [止める].
Revisit by [日付], or earlier if [トリガー].
モデル解答（B2〜C1相当）
DR-2026-014: Require independent confirmation before automated regional failover
Status: Accepted — September 25, 2026 (one-time cost only). The ongoing cost (0.5 FTE) is pending the FY2027 budget decision, due December 15, 2026.
Deciders: Marcus Webb (CTO, approver), Elena Torres (VP of Finance, co-approver)
Author: Priya Anand (Director of SRE) | Consulted: Diego Ruiz (Head of Customer Success)
Summary
Once this change ships (no later than November 6, 2026), automated regional failover will trigger only when CloudEdge's status API and our own synthetic checkout probes both report a failure. If this change does not pass its go/no-go test on October 23, 2026, we will run Black Friday through Cyber Monday (November 27–30, 2026) on human-approved failover instead.
Context
Between January and September 2026, automated failover fired three times on a false outage signal from CloudEdge's status API (INC-2026-003 on January 22, INC-2026-041 on May 7, INC-2026-088 on September 15). In all three cases our checkout path was healthy. The failover logic trusted a single vendor signal with no independent check.
The risk is highest at peak. Our secondary region has been load-tested to about 3x normal peak traffic; Black Friday is expected to reach about 6x. A false failover on that day would send twice the tested load into the secondary region. One such event in November would cost roughly $750K in SLA credits (assumptions: about $5M in November fee revenue × 60% on SLA-tier contracts × a 25% credit below 99.9% availability).
Note on figures: The original request memo (September 18, 2026) cited a "$180K revenue impact" for INC-2026-088. That figure was total payment volume (TPV) rerouted, not revenue; the actual fee impact was about $600. Do not reuse the $180K figure.
Decision
We will assign two of our six SREs for three two-week sprints (September 28 – November 6, 2026) to build a verification layer, at a one-time cost of $85K from the Q4 reliability budget. Failover will proceed only when both signals agree; if they disagree, nothing moves and on-call is paged. The work must be complete before the November 8, 2026 change freeze.
Options Considered
D. Disable automated failover for Black Friday week only (cost: $0). Rejected as the primary plan because every real regional outage would then wait on a human — an estimated 10–15 minutes, or a quarter to a third of our monthly 99.9% error budget. Retained as the fallback.
E. Scale the secondary region to 6x. Rejected because acquirer connection limits are set by contract and could not be raised before November. It would also leave false failovers in place.
No action. Rejected: the failure had already recurred three times, with about $750K of exposure at peak.
Consequences
False failovers caused by a single bad vendor signal should stop. In exchange, Observability Modernization slips about four weeks, from mid-December 2026 to mid-January 2027.
A failure mode we are knowingly accepting: because both signals must agree, a real outage that CloudEdge does not report will no longer trigger automated failover. At Marcus Webb's request, this case is part of the go/no-go test; the required behavior is a page to on-call within two minutes.
The ongoing 0.5 FTE for maintenance is not yet funded.
Confirmation & Stop Conditions
On October 23, 2026, we will run five cases: replay the three past false positives (must not fail over), inject a real failure that CloudEdge reports (must fail over automatically), and inject a real failure that CloudEdge does not report (must page on-call within two minutes). If any case fails, we will stop: both engineers return to Observability Modernization, Black Friday runs on Option D, and the author notifies all deciders the same day.
Revisit by January 29, 2027, or earlier if CloudEdge changes its status API or we add a second cloud provider. If the 0.5 FTE is not funded by December 15, 2026, that review must decide whether to keep, simplify, or retire the layer.
解説
構成分析
相対的な言葉が腐る実例（このシリーズの中で）
date -j -f %Y-%m-%d 2026-09-15 +%A → Tuesday で確認）。書いた週のうちは誰も気づきませんが、半年後に読む人は「月曜」と「15日」のどちらが正しいのかで迷います。決定記録では曜日も "this week" も書かず、年つきの日付とインシデント番号だけで出来事を指します。重要表現まとめ
| 表現 | 意味・ポイント |
|---|---|
Accepted — September 25, 2026 (one-time cost only) | 状態＋日付＋範囲。only が「それ以外は未承認」を示す |
pending ..., due December 15, 2026 | pending ＝ 未決。due で期限を付ける |
Do not reuse the $180K figure. | 記録の中で唯一の命令文。後の読み手への直接の指示 |
Rejected as the primary plan ... Retained as the fallback. | 却下と保持を対にする |
A failure mode we are knowingly accepting | knowingly ＝「承知のうえで」。リスク受容の定型 |
At Marcus Webb's request | 条件の出どころを人名で残す |
must not fail over / must fail over automatically | 試験の合格条件は must / must not。should にしない |
If any case fails, we will stop: | 止める条件。コロンの後に止めた後の動き |
Revisit by ..., or earlier if ... | 見直し日＋前倒しのトリガー |
文化的ポイント
| 日本語の傾向 | 英語の決定記録（ADR文化） |
|---|---|
| 議事録に「〜で合意」とだけ書き、誰が承認したかを書かない | Deciders に名前と役割（approver / co-approver）を書く。監査で最初に見られる |
| 「本件は別途検討」で未決事項を閉じる | 未決事項に期限と、決まらなかったときの扱いを書く |
| 誤りの訂正は、元の資料を差し替えて済ませる | 元の資料は残し、新しい記録に訂正を書く。何がいつ変わったかの履歴が残る |
| 採用しなかった案は書かない（結論だけ残す） | 採らなかった案と理由を書く。同じ議論の蒸し返しを防ぐのが主目的の一つ |
| 「リスクは低いと考えられる」とぼかす | 受け入れたリスクを具体的に書き、緩和策（2分以内のページ）と試験方法を添える |
数字の根拠（出所の区別）
シナリオ設定 仮定 導出 実測・確認済み
| 数字 | 区分 | 中身 |
|---|---|---|
| インシデント番号・日付（1/22, 5/7, 9/15） | シナリオ設定 | Day 155の「9か月で3回」を具体化。1/22と5/7は本問で新たに置いた |
| 3x / 6x | シナリオ設定 | Day 156から引き継ぎ |
| $750K | 導出（仮定の積） | $5M × 60% × 25%。Day 156・157と同じ数字 |
| 約$600 | 導出 | $180K × take rate 0.35%（仮定）＝ $630 |
| 10〜15分／a quarter to a third | 仮定＋導出 | 人の判断の時間は仮定。99.9%の月間許容時間 43.2分に対して 10÷43.2≈0.23、15÷43.2≈0.35 |
| 2分以内のページ | シナリオ設定 | Marcusの条件として置いた値。実務ではプローブの頻度から逆算する |
| 日程の曜日 | 確認済み | date で確認: 9/28 月、10/23 金、11/6 金、11/8 日、11/27 金、11/30 月、2027/1/29 金 |
| モデル解答の語数 約650語 | 実測 | wc -w で数えた値（見出し記号を除く） |
迷った他案と採らなかった理由
(1) 記録の形式
| 案 | 中身 | 採らなかった理由 | 前提が変われば |
|---|---|---|---|
| A. Nygard の5項目そのまま | Title / Context / Decision / Status / Consequences | 採らなかった案を書く欄がない。今回は「案Dは却下だが代わりの手」という位置づけが要 | 選択肢が実質1つの判断なら5項目で足りる |
| B. 9/18メモの体裁を流用 | Executive Summary / Evidence / Proposal | 承認を取るための構成。Status や止める条件の欄がない | 承認前（Status: Proposed）ならこちらが向く |
| C. 採用 | Nygard の5項目＋ MADR の Considered Options と Confirmation | 却下した案と試験方法を独立した見出しで拾える | — |
(2) 初版メモの$180Kをどう扱うか
| 案 | 中身 | 採らなかった理由 | 前提が変われば |
|---|---|---|---|
| D. 触れない | 正しい数字だけを書く | Wiki検索で初版が出てきたとき、どちらが正しいか分からない | 初版が社外に出ておらず削除できる運用なら可 |
| E. 初版を書き換える | $180K を消して正しい数字に差し替える | 承認がどの数字を根拠に進んだかの履歴が消える。監査では「承認時点の資料」が問われる | 結論に関係しない誤字なら書き換えで足りる |
| F. 採用 | 決定記録に訂正を書き、初版の冒頭に「DR-2026-014 の Note on figures を参照」の一行だけ足す | 履歴を残したまま、どちらから辿っても正しい数字に着く | — |
(3) Marcusの条件（false negative）をどこに書くか
| 案 | 中身 | 採らなかった理由 |
|---|---|---|
| G. 試験ケースにだけ書く | Confirmation の5ケース目として列挙 | 試験に合格すれば忘れられる。設計そのものの性質なので、合否と関係なく残る |
| H. 採用 | Consequences に受け入れたリスクとして、Confirmation に試験方法として | リスク（設計の性質）と確認（試験）を分けて残せる |
業界の実物との対応（参照日: 2026-09-25）
- Michael Nygard, "Documenting Architecture Decisions"（2011） — cognitect.com。5項目（Title / Context / Decision / Status / Consequences）、Decision は能動態の "We will …"、Status は proposed / accepted / deprecated / superseded、各ADRを「未来の開発者との会話」として段落の完全な文で書く（2026-09-25 にページを取得して確認）。
- MADR 4.0.0（2024-09-17 公開） — adr.github.io/madr。見出しは Context and Problem Statement / Decision Drivers / Considered Options / Decision Outcome / Consequences / Confirmation / Pros and Cons of the Options / More Information（2026-09-25 にページを取得して確認）。本問の Options Considered と Confirmation はここから取った。
- SOC 2 の変更管理（Trust Services Criteria CC8.1） — 変更が承認・試験されていることを求める基準として知られる。監査人を読み手に置いた理由。条文は本ファイル作成時に再確認していない（記憶による要約）。
よくある日本人のミス
| ミス | 原因 | 正しい表現 |
|---|---|---|
| "As discussed in the meeting yesterday, we decided to build the verifier." | 今週を知っている人にしか通じない言葉 | "On September 25, 2026, Marcus Webb and Elena Torres approved ..." |
| "It was decided that the verification layer will be implemented." | 受け身で、誰が決めたかが消える | Deciders に名前、本文は "We will build ..." |
| "Status: Approved." | 承認された範囲が分からない | "Accepted — September 25, 2026 (one-time cost only). The ongoing cost is pending ..." |
| "The 0.5 FTE will be considered later." | 未決事項に期限と扱いがない | "pending the FY2027 budget decision, due December 15, 2026. If it is not funded, ..." |
| "There may be some risk in rare cases." | 受け入れたリスクをぼかす | "A failure mode we are knowingly accepting: a real outage that CloudEdge does not report will no longer trigger automated failover." |
| "We will review this if needed." | 見直しの日付もトリガーもない | "Revisit by January 29, 2027, or earlier if CloudEdge changes its status API." |
| "The $180K in the previous memo was a mistake, sorry." | 記録の中で謝り、正しい数字と指示がない | "That figure was TPV rerouted, not revenue; the actual fee impact was about $600. Do not reuse the $180K figure." |
ワンランク上の表現
この問題で扱わなかった範囲
- 検証レイヤーの技術設計（照合の間隔、プローブ自体が落ちたときの扱い、タイムアウト値）: 「両方が一致しなければ切り替えず、on-call を呼ぶ」の一文だけ。技術設計書は別文書（Engineering週の題材）。
- FY2027予算での0.5 FTEの要求文書: 12/15の予算審議に出す文書は扱わない（Finance週の題材）。
- SOC 2 の証跡として何を添付するか（承認メールの保存・試験結果のログ）: 読み手に監査人を置いたが、証跡の集め方そのものは扱わない。
- 加盟店への連絡: Diegoは Consulted に名前を載せるだけにした（Sales/CS週の題材）。
次のステップ
- 発展: 10月23日の試験で5ケース目（CloudEdgeが報告しない本物の障害）だけが失敗した場合、DR-2026-014 の Status を何に変え、どの段落を書き足すか。元の記録への追記と、新しい記録（Supersedes DR-2026-014）のどちらで残すかを判断して書く
- 次回予告（Day 159・土曜）: 1on1/会話 × Operations — Observability Modernization から外れる2名のうちの1人と1on1。優先順位が変わった理由と、1月までの本人の担当を説明する