🎬 シナリオ
MOps チームは、11/2（月）10:00 に受付開始する「お歳暮ギフト」（Day037 でスプリント計画を立てたラッピング・のし対応。凍結は 10/28）に合わせて、販促クーポンの仕組みを用意している。今日は 9/27（日）。マーケティング部は、すでにこう告知した。
「受付開始記念 先着5,000名様 お歳暮ギフト 1,000円OFF（税込5,000円以上）Webでもお電話でも」
9/24 発送のカタログDM（18万通）とサイトの予告ページに掲載済み
9/24 発送のカタログDM（18万通）とサイトの予告ページに掲載済み
関係する事実（演習シナリオ上の設定値）
| 項目 | 値 | 出所 |
|---|---|---|
| クーポン予算 | 500万円（5,000枚×1,000円）。稟議承認済み。超えるには CFO の追加稟議 | 実測 稟議書 |
| 8月の役員会での約束 | Day032 の併用事故（想定180万→実績320万円）の再発防止として「クーポン原資は上限到達で自動停止」と報告済み | 実測 議事録 |
| Web 側の枚数上限 | 注文確定のたびに即時判定（実績あり） | 実測 |
| 電話注文 | 外部委託のコールセンター 40席。委託先の受注システムに入る | 実測 契約 |
| 委託先 → 自社の連携 | 30分ごとの CSV。リアルタイム API は無い | 実測 契約 |
| 委託先のクーポン機能 | コードごとに受付上限数を設定でき、委託先の中では即時に止まる。変更は SV が行い反映まで約5分 | 実測 委託先回答 |
| リアルタイム API を作る場合 | 8週間・240万円 → 11/2 に間に合わない | 実測 見積書 |
| 委託先に管理画面の権限 | 情報セキュリティ委員会の承認が要る。次回 11/10 | 実測 規程 |
| 電話の処理能力 | 40席×60分÷平均通話7分 ≒ 1分あたり約5.7件 | 導出 |
| 昨年の受付開始日の注文 | Web 2,640件／電話 610件（電話 19%） | 実測 |
| クーポン利用率 | 対象注文の80% | 仮定 |
| S20（10/12〜10/23） | ギフト機能の残り 19pt（G4 のし名入れプレビュー 5pt、G7 確認メールの贈り先表示 3pt を含む）。予測ベロシティ 18〜22pt | 実測 計画中 |
💬
経理部長「500万円を1円も超えないで。8月に役員会で『上限で自動停止する』と約束したばかり。ラグで超えました、は通らない」
💬
マーケティング部長「『先着5,000名』と書いた以上、Web と電話で順番が狂うのは困る。Web で終了した後に『電話ならまだ使えた』と知られたら、SNS で叩かれる」
💬
CS部長「一度『使えます』と言ったお客様に、後から取り消しの電話はしない。『終了』の後に『再開』するような表示もやめてほしい。問い合わせが倍になる」
🛠️
エンジニアリード「Web は即時に数えられる。でも電話の注文は30分遅れでしか届かない。30分の見えない時間がある限り、『超えない』『全体で先着順』『表示が途中で揺れない』の3つを同時には満たせない。どれを諦めるかを決めてほしい」
📌
PdM「前回（Day029）は要求を組み替えて両立させた。今回は組み替えても両立しない。何を諦めるかを選び、損失を数字で示し、誰がいつまでに決めるかまで書いた意思決定メモを 10/7（水）の部長会に出したい。10/9（S19 最終日）までに決まらないと S20 に入らない」
📝 課題
あなたのタスク: 10/7 の部長会に出す意思決定の資料一式を作ってください。
- 要求の分解表: 3部長＋エンジニアリードの表層の要求と真因を分け、組み替えで両立できるかを1行ずつ検討する
- トリレンマ表: 3条件のうち2つを取る案を3つ並べ、誰が・何を・どれだけ失うかを数字で書く
- 損失の試算: 電話比率が 19% からずれた場合（12%・26%）の各案の損失
- 1ページの意思決定メモ: 決めること・期限・DACI・推奨・反対意見・判断が変わる条件
- S20 への影響と当日の運用: 必要な作業と pt、11/2 当日に何を見てどう止めるか
- 採らなかった案: 2つ以上、理由と判断が変わる条件つきで
🔍 ヒント（段階的開示）
ヒント1: 組み替えは「効かないことを確かめるため」に試す
Day029 と同じく表層と真因を分ける。ただし今回は、組み替えが効かない理由を書けることが「選ぶ」前提になる。
ヒント2: 原因は意見の違いではなく制約
両立しない原因は 30分の見えない時間。これを外す手段（API・管理画面の権限）が期限内に使えるかも確かめる。
ヒント3: 各案の「損」と「上限」
3つのうち2つを取る案は機械的に3つできる。大事なのは各案で誰が損をするか、その損に上限があるか。
ヒント4: 按分の基準を疑う
「昨年の1日の注文比率 19%」で分けてよいか。Web は午前に集中し、電話は席数で頭打ちになって1日続く。締め切り時刻までの需要で比べるとどうなるか。
ヒント5: 超過の上限の出し方
電話が1分に受けられる件数 × 見えない時間（30分＋止める連絡5分）× 利用率。
ヒント6: 誰が決められるか
予算を超える案は、今の決定者の権限の中で、期限までに決められるか。
📚 背景知識・用語解説
🔺
トリレンマと CAP の考え方: 分散システムには、分断（partition）が起きたとき一貫性と可用性を同時には守れない、という CAP定理がある。「Web と電話の間に30分の見えない時間がある」状態は分断が続いているのと同じ構造で、注文ごとに「止めて一貫性を守るか、受けて超過のリスクを取るか」を選ぶことになる。Brewer は、分断のときの選択を "Cancel the operation and decrease availability, or proceed and risk inconsistency" と書く。一方で「3つのうち2つ」は単純すぎるとも言い、分断を検知し、分断中は危ない操作を制限し、復旧後に補償する管理の仕方を示す（案B はこの「補償」にあたる）。
一次資料: Eric Brewer "CAP Twelve Years Later: How the 'Rules' Have Changed" IEEE Computer 2012（InfoQ 転載、参照日 2026-09-27）
一次資料: Eric Brewer "CAP Twelve Years Later: How the 'Rules' Have Changed" IEEE Computer 2012（InfoQ 転載、参照日 2026-09-27）
🔁
要求の再定義が効く場合と効かない場合: Day029 では、真因（評価損の圧縮・ブランド保護）を見ると「誰に届けるか」という別の軸で両方を満たせた。再定義が効くのは真因どうしがぶつかっていないとき。今回は真因のレベルで「超えない」と「順番を狂わせない」が直接ぶつかる。
👤
DACI: Driver（関係者を集め、期限までに決定させる）、Approver（決める人。1人だけ）、Contributors（知見を出すが決定権は無い）、Informed（結果を知らされる）。対等な部長3人の合意を待つと 10/9 を過ぎる。Approver を1人決めることで「決まらない」を避ける。
一次資料: Atlassian Team Playbook "DACI" atlassian.com（参照日 2026-09-27）
一次資料: Atlassian Team Playbook "DACI" atlassian.com（参照日 2026-09-27）
🗣️
反対意見の記録（Disagree and Commit）: 賛成できない決定には敬意を持って異議を唱え、決まった後は全力で取り組む。メモに反対意見を書くのは、判断が外れたとき、どの前提が違ったかを後で確かめるため。
一次資料: Amazon "Leadership Principles" amazon.jobs（参照日 2026-09-27）
一次資料: Amazon "Leadership Principles" amazon.jobs（参照日 2026-09-27）
⚖️
按分の基準: 枠を分ける比率は「全体の注文比率」ではなく枠が尽きるまでの時間帯の需要比率で決める。同じ19%でも、締め切りまでに電話が使う枚数はもっと少ない。
✅ 模範解答
1. 要求の分解表
| 誰 | 表層の要求 | 真因（なぜ譲れないか） | 組み替えで両立できるか |
|---|---|---|---|
| 経理部長 | 500万円を1円も超えない | 役員会に「上限到達で自動停止」と約束した。超えれば再発防止策が機能しなかったことになる | ✕ 上限を緩めるのは真因そのものを崩す。緩めるなら CFO の判断で、経理部長の権限を超える |
| マーケ部長 | Web と電話で順番を狂わせない | 18万通に告知済み。後から知られたときの不公平感と炎上 | △ チャネル別の枠を事前に明示すれば告知の文言（合計5,000名・Webでも電話でも）とは矛盾しない。ただし「全体で早い順」ではなくなる |
| CS部長 | 取り消しの電話をしない／終了→再開の表示をしない | 取り消しは苦情に、表示の揺れは問い合わせ倍増に | △ 事前に予告した1回の枠移し（翌日10:00）なら「揺れ」ではなく「予定」として扱える |
| エンジニアリード | どれを諦めるか決めてほしい | 電話は30分遅れでしか見えない。外す手段（API 8週間・権限 11/10）は間に合わない | ✕ 制約は技術と契約から来ており、11/2 までには外せない |
🧱
結論: 経理の真因（上限で止まる）とマーケの真因（全体で先着順）は、30分の見えない時間を挟んで直接ぶつかる。組み替えでは両立しない。どれかを諦める選択が要る。
2. トリレンマ表（3つのうち2つを取る）
取りたい条件を2つ選ぶと、対応する案と、誰が何を失うかが出る。
| 案 | 取るもの | 諦めるもの | 仕組み | 誰が何を失うか（電話比率19%） | 損失に上限は |
|---|---|---|---|---|---|
| A. チャネル別の枠 | 超過ゼロ／揺れない | 全体で先着順 | Web 4,250・電話 750。各システムの中で即時に止まる。電話枠の残りは予告のうえ翌日10:00に Web へ1回だけ移す | 「全体の早い順なら使えた」お客様が約10人（比率がずれると最大約210人） | ある（超過0円） |
| B. 共有の枠＋遅れを受け入れる | 全体で先着順／揺れない | 超過ゼロ | Web が即時に数え、電話分は30分ごとに足す。5,000枚で Web を止め、SV 経由で電話も止める（約5分） | 経理: 予測で約47枚（約4.7万円）超過。上限は約160枚（約16万円・予算の3.2%）。役員会の約束を文言どおりには守れない | ある（席数×35分） |
| C. 一時停止と再開 | 超過ゼロ／全体で先着順 | 表示が揺れない | 残り160枚で Web を一時停止し、次の CSV で電話分を確定してから残りで再開 | お客様: 「確認中」「再開」を見る。チーム: 新規処理に 8pt、G4・G7 を落とし、凍結直前にクーポン判定を触る | 当日の不具合リスクは上限を書けない |
📐
按分を 4,250／750 にした理由: 1日の比率（19%）で分けると Web 4,050／電話 950。しかし Web は受付直後に集中し、電話は1分約5.7件で頭打ち。電話比率19%なら、全体で5,000枚に達する13:13ごろまでに電話が使うのは約740枚。1日の比率で分けると Web が約210人分損をする。
3. 損失の試算（電話比率がずれた場合）
前提 仮定: 30分ごとのクーポン需要（Web＋電話）1,700／1,100／750／620／500／430／370／330／300…（10:00〜）。電話は比率ぶんの需要と席数（30分約138枚）の小さい方
電話比率 12%: 全体の先着順なら電話 約540枚・終了12:57 → 案A で Web 側の約210人が損／案B 超過 約34枚（3.4万円）
電話比率 19%: 電話 約740枚・終了13:13 → 案A 約10人／案B 約47枚（4.7万円）
電話比率 26%: 電話 約910枚・終了13:35 → 案A で電話側の約160人が損／案B 約57枚（5.7万円）
案B の上限 = 電話の最大ペース 4.6枚/分 × 最大の見えない時間35分 ≒ 160枚（16万円） 導出
電話比率 12%: 全体の先着順なら電話 約540枚・終了12:57 → 案A で Web 側の約210人が損／案B 超過 約34枚（3.4万円）
電話比率 19%: 電話 約740枚・終了13:13 → 案A 約10人／案B 約47枚（4.7万円）
電話比率 26%: 電話 約910枚・終了13:35 → 案A で電話側の約160人が損／案B 約57枚（5.7万円）
案B の上限 = 電話の最大ペース 4.6枚/分 × 最大の見えない時間35分 ≒ 160枚（16万円） 導出
試算してみる — 需要の形は上の仮定。桁と向きを見るためのもの
🔑
読み方: 案A の損失は按分がどれだけ外れるかで決まる。案B の損失は金額として小さく上限も書けるが、「役員会の約束を破るか」という別の種類の損失を伴う。種類の違う損失は数字だけでは比べられない。だから決める人（Approver）が要る。
4. 意思決定メモ（10/7 部長会用・1ページ）
11/2 お歳暮早割クーポン（先着5,000名）の Web・電話の枠の持ち方
- 決めること
- 「超過ゼロ」「全体で先着順」「表示が途中で揺れない」のうち、どれを諦めるか
- 期限
- 10/9（金）。過ぎると S20（10/12〜）の計画と委託先への設定依頼（5営業日）が凍結 10/28 に間に合わない
- 両立しない理由
- 電話の注文は30分遅れでしか見えず、外す手段（API・管理画面の権限）は 11/2 に間に合わない
| DACI | 誰 | 理由 |
|---|---|---|
| Driver | PdM（資料作成: MOps エンジニア） | 情報を集め、10/9 までに決定させる |
| Approver | EC事業本部長 | キャンペーン損益の責任者。ただし案B は予算超過を伴い、この権限だけでは決められない（CFO の追加稟議） |
| Contributors | 経理部長・マーケ部長・CS部長・エンジニアリード・委託先SV | 各案の損失の見積もりに責任を持つ |
| Informed | CFO・コールセンター委託先・物流部門 | 結果に合わせて準備する |
推奨: 案A（チャネル別の枠 Web 4,250／電話 750）
- 文言として破る約束が無い。告知は「合計5,000名・Webでも電話でも」。案B は「上限到達で自動停止」を文言どおりには守れない
- 今の Approver の権限の中で、10/9 までに決められる。案B は CFO の稟議が期限までに通る保証が無い
- 案C は凍結直前にクーポン判定を触る。年間で最も注文が集中する日の1つに不具合が出たときの損失は、上限が書けない
- 案A の損失は按分の見直しで小さくできる。比率を事前に明示し、翌日10:00 の枠移しも予告する
| 反対意見 | 意見 | 推奨がこれを受け入れる形 |
|---|---|---|
| マーケ部長 | 「チャネル別の枠は『先着』の精神に反する。4.7万円で済むなら案B が良い」 | 金額の比較としては正しい。判断が変わる条件1に入れた |
| CS部長 | 「Web が先に終わると電話が殺到する」 | Web 終了の表示に電話枠の残りを30分ごとの更新値で正直に出す。11:00〜14:00 は IVR で残数を案内 |
判断が変わる条件
- 10/21 までに CFO が上限515万円（超過の上限16万円込み）を事前承認 → 案B に切り替える（設定の差だけ。新しい開発は不要）
- 委託先が CSV を5分間隔にできる → 案B の上限は約46枚（約4.6万円）に下がり、案B を推す理由が強くなる
- 10/9 までの予約・問い合わせから電話比率が26%以上と見込まれる → 按分を Web 4,100／電話 900 に直す
11/2 以降の宿題: 春ギフト（3月）までに、委託先 API（240万円）か SV への管理画面権限（11/10 委員会）で見えない時間そのものを無くす。
5. S20 への影響と当日の運用
| 作業（案A） | pt | 備考 |
|---|---|---|
| Web 側の上限を 4,250 に設定し、残数表示に「電話枠の残り（○時点）」を追加 | 2 | 既存の即時判定を使う。新しい判定ロジックは作らない |
| 電話 CSV の取り込みから電話枠の残りを出す集計 | 1 | 既存の取り込みに列を1つ足す |
| 翌日10:00 の枠移しの手順書とリハーサル | 1 | 手動の設定変更。二重に移さない確認手順 |
| 委託先への上限 750 の設定依頼と当日の連絡手順 | 0 | 10/19 までに依頼（5営業日） |
| 合計 | 4 | S20 の 19pt ＋4 ＝ 23pt ＞ 予測上限 22pt → G7（3pt）を 11/16 リリースへ。G4 は残す（案C なら 8pt で G4・G7 とも落ちる） |
| 時刻・きっかけ | 見るもの | 動き | 担当 |
|---|---|---|---|
| 9:30 | Web 上限 4,250・委託先上限 750 の設定 | 違えば 10:00 の受付を止めてでも直す（Go/No-Go） | MOps・委託先SV |
| 10:00〜 30分ごと | Web の使用枚数、CSV の電話使用枚数 | サイトの残数表示を更新 | MOps |
| Web 枠 4,250 到達 | 新しい注文にクーポンが付かないこと | 「Web 枠は終了。電話枠の残り約○枚（○時点）」 | MOps |
| 電話が1分7件を超える | 委託先の待ち時間 | IVR を「電話枠の残り」案内に切り替え | CS |
| 18:00（電話受付終了） | 電話枠の残り | 翌日10:00 に Web へ移す枚数を確定し、サイトで予告 | MOps・マーケ |
| 異常（Web で上限超えの付与を1件でも検知） | 管理画面の付与数 | Day036 の緊急停止スイッチで付与を止める | MOps |
🗂️ 検討した案と採らなかった理由
| 案 | 内容 | 判断 | 理由 | 判断が変わる条件 |
|---|---|---|---|---|
| A. チャネル別の枠 | Web 4,250／電話 750 | 推奨 | 約束を破らず、今の Approver の権限と期限の中で決められる | B・C の条件が満たされたとき |
| B. 共有の枠＋遅れを受け入れる | 超過の上限16万円 | 条件付きで次点 | 役員会の約束を文言どおり守れない。CFO の稟議が間に合う保証が無い | 10/21 までに CFO が上限515万円を事前承認 |
| C. 一時停止と再開 | 残り160枚で Web を止め、CSV で確定して再開 | 不採用（今回は） | 8pt。凍結直前にクーポン判定を触る。表示の揺れで問い合わせ増 | 凍結が2週間遅い、または平常時のキャンペーンで一度試せていた場合 |
| D. Web 限定に変更 | 電話ではクーポン不可 | 不採用 | DM に「お電話でも」と書いた。電話で注文する高齢の贈り主を切る | DM の発送前だった場合 |
| E. 委託先 SV に管理画面の権限 | 電話でも即時に残数を確認・予約 | 不採用（今回は） | 情報セキュリティ委員会が 11/10。審査と研修が間に合わない | 11/10 の委員会で春ギフト向けに承認された場合 |
| F. 委託先のリアルタイム API | 見えない時間を無くす | 不採用（今回は） | 8週間・240万円 | 3月の春ギフトに間に合うなら来期予算で検討 |
🧭 なぜこう作るのか
1
組み替えを「効かないことを確かめるため」に書いた。 いきなり「選ぶしかない」と言うと「もっと考えれば両立できるのでは」と差し戻される。✕ の理由が技術と契約の制約（30分・11/10・8週間）だと示せば、選ぶ段階に進める。
2
案を「何を諦めるか」で並べた。 部長それぞれが、自分の要求がどの案で犠牲になるかを1行で読める。
3
損失に上限があるかを列にした。 案C の「当日に不具合が出るリスク」は上限を書けない。上限の書けない損失は、金額が小さく見えても避ける理由になる。
4
按分の基準を疑った。 1日の比率19%をそのまま使うと Web が約210人分損をする。何の比率かを確かめるのは Day036（放棄率の出所）・Day037（1稼働日あたりに直す）と同じ姿勢。
5
推奨の理由に「誰の権限で決められるか」を入れた。 期限までに決められない案は、良い案でも選べない。書いておくと「では CFO に聞こう」という次の一手（条件1）が自然に出る。
6
反対意見を、推奨がどう受け入れるかと並べた。 対立の記録ではなく、次の判断の入口として残る。
🔀
別の判断もありうる: 案B を推奨にする判断も十分成り立つ。予測の超過は約4.7万円で、お客様から見た「先着」の分かりやすさは案B が一番よい。案B を推すなら「約束の趣旨は『上限の無い超過を防ぐこと』で、上限16万円を事前に承認すれば趣旨は守れる」と主張し、CFO の承認を 10/9 より前に取りに行く。分かれ目は社内統制の約束を文言で守るか、趣旨で守るか。この資料の役目は、その判断を Approver が数字を見ながらできるようにすること。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「技術的に無理です」とだけ伝える | 選択肢が無いので部長会は判断できない | 「どの2つを取るか」の選択肢の形で出す |
| 3案の良いところだけを並べる | 誰かが損をすることが見えず決まらない | 「諦めるもの」「誰が何を失うか」の列を必ず作る |
| 按分を1日の注文比率で決める | 午前に集中するチャネルが不利になる | 枠が尽きるまでの時間帯の需要で比べる |
| 部長全員の合意を待つ | 10/9 を過ぎ、何もしないのと同じになる | Approver を1人決め、他は反対意見として記録 |
| 反対意見を書かない／「調整済み」と書く | 外れたとき、どの前提が違ったか確かめられない | 反対意見・受け入れる形・判断が変わる条件を並べる |
| 小さく見える金額で決める（「たった4.7万円」） | 金額以外の損失（統制の約束・当日の不具合リスク）が抜ける | 損失の種類と、上限があるかを分けて書く |
🏢 実務での使いどころ
エンジニアが意思決定の資料を書く場面で一番多いのは、技術の制約でビジネス側の要求が全部は通らないとき。同じ型は、在庫の即時連携ができない倉庫と「在庫切れを売らない」「注文を止めない」の両立、外部決済の障害時に「受けて後で決済」か「止める」か、複数店舗・モールで共有する限定数の商品、などにそのまま使える。
- 経営層・部長会: 技術の話を「どの2つを取るか」の選択に翻訳して渡す。決めるのは Approver、エンジニアは損失の数字に責任を持つ
- 経理・法務: 金額だけでなく「約束を破るか」という種類の損失を持っている。数字で比べられないものがあることを資料の中で認める
- 委託先: 制約の多くは契約から来る。次の契約更新で CSV の間隔や API を条件に入れれば、同じトリレンマは起きない
転用できるテンプレート
要求の分解表: 誰 | 表層の要求 | 真因 | 組み替えで両立できるか（✕/△と理由）
トリレンマ表: 案 | 取るもの | 諦めるもの | 仕組み | 誰が何を失うか（数字） | 損失に上限はあるか
損失の試算: 読みがずれた場合（例: 比率 ±7pt）の各案の損失
意思決定メモ: 決めること | 期限（逆算の根拠） | DACI | 推奨と理由 | 反対意見と受け入れる形 | 判断が変わる条件 | 宿題
実行への影響: 必要な作業と pt | 押し出されるもの | 当日の運用（きっかけ・見るもの・動き・担当）➡️ 次のステップ
- 当日の運用表をリスク登録簿（Day031 の形）に書き直す。「按分が外れる」「委託先の上限設定ミス」「電話の殺到」を発生確率×影響度で並べる
- 春ギフトに向けて、委託先 API（240万円）の投資判断を「見えない時間が無ければ防げた損失」を根拠に PRD にする（PdM-要求）
- 自分への問い: マーケ部長に「4.7万円でブランドが守れるなら安い。なぜ案B にしないのか」と言われたら、条件1を使って1分で答えられるか
- 自分への問い: 11/2 の結果、電話比率が12%で約210人が損をしたら、振り返りで何を確かめるか（按分の前提か、決め方か）
🚧 扱わなかった範囲（この演習の限界）
- 需要の時間帯の形とクーポン利用率80%は仮定。試算は損失の桁と、比率がずれたときの向きを示すためのもの。実際には昨年の時間帯別の注文ログで作り直す
- チャネル別の枠が景品表示法など法令上問題ないかは判断していない。告知の文言と運用が矛盾しないことを法務に確認する前提
- 電話殺到時の追加席の費用、IVR の文言は扱っていない
- 分散システムとしての正確な設計（予約と補償、枠の自動移動など）は案C・F の説明にとどめた
- 今週の JTBD（Day038）は直接使っていない。お歳暮の贈り主にとってクーポンはジョブではなく「条件」なので按分の不公平はジョブを壊さない、という見方は推奨の補強になりうるが、インタビューの裏付けが無いので根拠に入れていない
- 「実測」ラベルの数値は演習シナリオ上の設定値。外部の一次資料は Web 3点（Brewer 2012 InfoQ 転載・Atlassian DACI・Amazon Leadership Principles、参照日 2026-09-27）