🎬 シナリオ
今日は 10/4(日)。前回の統合(Day039)は「何を諦めるかを選ぶ」場面だった。今回は選んだ後の話。MOps チームの「注文後体験」ライン(エンジニア2名)は、7/8 の部長会で意思決定メモを通し、8/18 に「配送日時のセルフ変更」をリリースした。購入者が注文履歴から、出荷指示の前なら配送日時を自分で変えられる機能。
7/8 の意思決定メモ(抜粋)
狙い: 配送日時変更の問い合わせ(4〜6月平均 月6,200件)を減らす
見込み: 6,200 × 出荷指示前の割合 70% × セルフ変更を使う割合 60% ≒ 2,604件(約40%削減)
工数: 20人日(単一見積もり)、リリース 7/31/Value vs Effort: 「クイックウィン」
見直しの基準: リリース8週後に削減率25%未満なら見直す/Approver: EC事業本部長
狙い: 配送日時変更の問い合わせ(4〜6月平均 月6,200件)を減らす
見込み: 6,200 × 出荷指示前の割合 70% × セルフ変更を使う割合 60% ≒ 2,604件(約40%削減)
工数: 20人日(単一見積もり)、リリース 7/31/Value vs Effort: 「クイックウィン」
見直しの基準: リリース8週後に削減率25%未満なら見直す/Approver: EC事業本部長
8週が過ぎた。10/2 に届いた数字(演習シナリオ上の設定値)
| 項目 | 値 | 出所 |
|---|---|---|
| 9月の配送日時変更の問い合わせ(4週を月換算) | 5,080件(−18.1%) | 実測 CS タグ |
| 台風2回による増分 | 約280件(ほぼ全部が出荷後) | 導出 物流の遅延件数×昨年の率 |
| 台風分を除いた問い合わせ | 4,800件(−22.6%) | 導出 |
| 問い合わせ時点で出荷指示前だった割合 | 45%(ログ突き合わせ、作業2日。7/8 時点では未測定) | 実測 今回初めて |
| 残った問い合わせの内訳 | 出荷後 3,690件(うち台風280)/出荷前なのに問い合わせた 1,390件 | 実測+導出 |
| 出荷前1,390件の内訳(300件抜き取り) | ゲスト購入でログイン不可 52%(約723)/画面を見つけられない 30%(約417)/住所変更も含む 18%(約250) | 実測→導出 |
| 実際の工数 | 41人日(2.05倍)、リリース 8/18(予定 7/31) | 実測 |
| 問い合わせ1件の CS 対応コスト | 600円 | 実測 委託単価 |
| 月の出荷件数 | 約155,000件(11〜12月は約1.6倍) | 実測/仮定(倍率) |
| 注文後体験ラインの S20(10/12〜10/23)の空き | 9人日 | 実測 計画中 |
工数が増えた内訳(エンジニアリードの振り返りメモ)
| 増えた分 | 人日 | 何が起きたか |
|---|---|---|
| 倉庫ごとの締め時刻 | +9 | 8月稼働の西日本倉庫は締め12:00(東日本14:00)。テスト段階で判明。稼働は物流の7月の計画書に載っていた |
| 物流の出荷指示ステータス API の遅れ | +7 | 物流側の優先度変更(7/22)で2週遅れ。暫定の CSV 取り込みを作って後で差し替え |
| ゲスト購入対応を途中で追加し断念 | +5 | 7/30 の週にマーケ要望で追加、認証の作りが合わず断念。判断記録なし |
💬
CS部長「40%減ると聞いて、委託の席数を10月から2席減らす話を進めていた。18%では足りない。見込みはどこで間違えたのか、はっきりさせてほしい」
💬
経理部長「41人日、外注単価で約205万円かけた。ここで止めたら全部無駄になる。続けて回収してほしい」
💬
マーケ部長「40%の約束に届かなかったのだから、この機能は失敗。11月のギフト繁忙期の前に、別の施策に人を回すべき」
🛠️
エンジニアリード「見積もりが甘かったのは自分の責任。ただ、API の遅れはこちらではどうしようもなかった」
📌
PdM「10/8 の見直し会で Approver に続けるか・やり方を変えるか・止めるかを決めてもらいたい。犯人探しにはしたくない。どの前提が外れたのか、それは当時分かったことなのかを分けて書き、これから先の損得だけで案を比べてほしい。11月の繁忙期前にリリースするなら、10/9(金)までに決めて S20 に入れる必要がある」
📝 課題
あなたのタスク: 10/8 の見直し会に出す振り返りと方針転換の資料一式を作ってください。
- 決定の振り返り表: 前提ごとに「当時の値/実際/当時知り得たか/分類(決め方の欠陥・運・当たり)」
- 効果のずれの分解: 見込み2,604件 → 実際1,400件(台風分を除く)の差を、前提ごとに分ける
- 工数のずれの分解: 20 → 41人日を WBS の中の誤差と WBS の外に分け、三点見積もりで防げたかを答える
- 継続・転換・中止の比較表: 3案以上。かかった41人日は入れず、これから先の効果と工数で比べる
- 転換案のユーザーストーリー(受け入れ条件つき)とリスク登録簿(Day042 の5×5)
- 物流チームとの依存の約束: 何を・誰が・いつまでに・どんな形で・間に合わないときどうするか
- 1ページの見直しメモ: 決めること・期限・推奨・次の見直し基準・決め方の改善・採らなかった案
🔍 ヒント(段階的開示)
ヒント1: 結果と決め方を分ける
「結果が悪かった=決め方が悪かった」ではない。「運が悪かった」で片付けてもいけない。前提ごとに当時、妥当な手間で知り得たかを問う。
ヒント2: 運の分を先に除く
台風の分を除いてから基準(25%)と比べる。除いても届かないなら、運では説明できない。
ヒント3: 見込みの式を1項ずつ置き換える
2,604件は3つの数の掛け算。どれを実測に置き換えると、どれだけ減るか。
ヒント4: 三点見積もりの守備範囲
三点見積もりは「分かっている作業の幅」を出す道具。WBS に無かった作業(他チームの遅れ・途中で足したスコープ)は、どの道具で扱うべきだったか。
ヒント5: 205万円は判断に入れてよいか
続けても止めても戻らない費用は、比べる数字に入れない。経理部長とマーケ部長の言い分を、それぞれ「これから先」の数字で言い直すとどうなるか。
ヒント6: 出荷後の人の本当のジョブ
残った最大の塊(出荷後3,690件)の購入者は、「店で日時を変えたい」のか、それとも別のことをしたいのか(JTBD)。
ヒント7: 次の基準の置き方
11月は出荷が増える。「件数」で次の基準を置いてよいか。
📚 背景知識・用語解説
🎲
結果で決め方を評価しない(resulting): Annie Duke は、結果の良し悪しで決め方の良し悪しを判断してしまう誤りを "resulting" と呼んだ。振り返りでは当時持っていた情報と、妥当な手間で取れた情報に照らして決め方を評価する。「外れた=失敗」でも「運が悪かった」でも、次の決定で同じ欠陥が残る。
一次資料: Annie Duke, Thinking in Bets, Portfolio, 2018(書籍。記憶による要約・未照合)
一次資料: Annie Duke, Thinking in Bets, Portfolio, 2018(書籍。記憶による要約・未照合)
🤝
責めない振り返り(blameless postmortem): Google SRE 本の Postmortem Culture の章は、個人やチームを責めずに書くことを求め、関わった人は "did the right thing with the information they had" と仮定する。責める文化では、人が問題を表に出さなくなる。今回はエンジニアリードの「自分の責任」を受け取らず、「見積もりの仕組みに依存とスコープ追加を書く欄が無かった」ことを問う。
一次資料: Google, Site Reliability Engineering, Ch.15 sre.google(参照日 2026-10-04)
一次資料: Google, Site Reliability Engineering, Ch.15 sre.google(参照日 2026-10-04)
🕳️
サンクコスト(埋没費用): すでに払って取り戻せない費用。人は「すでに投資した」ことを理由に、これから先は損な選択でも続けてしまう傾向がある(10の実験で示された)。41人日(約205万円)は続けても止めても戻らない。比べてよいのはこれから先の工数と効果だけ。
一次資料: H. R. Arkes & C. Blumer, "The psychology of sunk cost", OBHDP 35(1), 124–140, 1985, doi:10.1016/0749-5978(85)90049-4(Crossref で書誌確認、参照日 2026-10-04)
一次資料: H. R. Arkes & C. Blumer, "The psychology of sunk cost", OBHDP 35(1), 124–140, 1985, doi:10.1016/0749-5978(85)90049-4(Crossref で書誌確認、参照日 2026-10-04)
↪️
継続か転換か(pivot or persevere): Eric Ries The Lean Startup(2011)は、決めた間隔で「続けるか、仮説の一部を変えるか」を決める会議を勧める。転換は「やめる」ではなく、学んだことを残して、外れた仮説だけを取り替えること。(書籍。記憶による要約・未照合)
この週の道具とのつながり
| 曜日の回 | 今日どこで使うか |
|---|---|
| PM-計画 Day040(三点見積もり) | 工数のずれの分解。防げた部分と防げない部分を分ける |
| PM-リスク Day042(登録簿・5×5) | 転換案のリスク登録簿。物流への依存をリスクとして行にする |
| PdM-要求 Day043(ユーザーストーリー) | 転換案を縦に切ったストーリーと Given-When-Then |
| PdM-優先順位 Day044(Value vs Effort) | 「クイックウィン」判定の見直しと案の比較(効果÷工数) |
| PM-推進 Day041(バーンアップ) | 工数が増えた経過をスコープの線と完了の線で見る |
| PdM-リサーチ Day045(JTBD) | 出荷後に日時を変えたい人の本当のジョブから転換先を決める |
✅ 模範解答 — 1. 決定の振り返り表
| # | 7/8 の前提 | 当時の値(出所) | 実際 | 当時、妥当な手間で知り得たか | 分類 |
|---|---|---|---|---|---|
| P1 | 問い合わせ件数 | 月6,200件 実測 | 平常月は同水準 | — | 当たり |
| P2 | 出荷指示前の割合 | 70% 仮定(平均20時間から推した) | 45% | 知り得た。ログ突き合わせで2日。着手まで5日あった | 決め方の欠陥 |
| P3 | セルフ変更を使う割合 | 60% 仮定 | 約50% | 一部。セルフキャンセルの利用率48%が社内にあった | ほぼ当たり |
| P4 | 工数 | 20人日(単一) | 41人日 | 分けて見る(3.) | 混在 |
| P5 | 9月の外部要因 | 想定なし | 台風で約280件増 | 知り得なかった | 運 |
| P6 | 見直しの基準 | 8週後に25% | 台風分を除き22.6% | — | 良かった点(今日の会議ができる) |
🧭
読み方: 台風分(運)を除いても 22.6% で、基準の25%に届かない。主な理由は P2 で、これは当時2日で測れた。一方、P6 で見直しの基準を先に決めていたことは残すべき習慣。
前提の仕分けクイズ
表を見る前に、自分で分類してみる。ボタンを押すと答えと理由が出る。
2. 効果のずれの分解
見込み(7/8) 6,200 × 70% × 60% = 2,604件(42%)
P2 を実測に置き換え 6,200 × 45% × 60% = 1,674件(27%) ← P2 で −930件
P3 を実測に置き換え 6,200 × 45% × 50% ≒ 1,400件(22.6%) ← P3 で −274件
台風(運) −280件 → 見かけの削減は 1,120件(18.1%)
残った 5,080件 = 出荷後 3,690件(平常 3,410 + 台風 280)+ 出荷前なのに問い合わせた 1,390件
- 見込みとの差 1,204件のうち約77%(930件)が P2。P3 は約23%
- 出荷後の 3,410件(平常)は、この機能では最初から減らせない塊だった
- 「40%に届かなかったから失敗」は半分だけ正しい。出荷前の人(2,790件)の約50%は自分で変えており、機能は狙いどおり動いている。外れたのは「狙った塊の大きさ」
3. 工数のずれの分解(20 → 41人日)
バーンアップ: スコープ(総量)の線と完了の累計の線(人日)。点線は 7/8 の計画(7/31 に20人日)。
完了のペースは週5〜9人日でほぼ一定。遅れたのは作業が遅かったからではなく、スコープが3回増えたから(Day041 と同じ読み方)。
もし三点見積もりをしていたら(O/P は振り返りで本人に付けてもらった値 仮定)
| 作業パッケージ | O | M | P | E=(O+4M+P)/6 |
|---|---|---|---|---|
| 変更画面 | 2 | 3 | 5 | 3.2 |
| 変更できるかの判定 | 3 | 4 | 7 | 4.3 |
| WMS への日時変更の連携 | 3 | 5 | 9 | 5.3 |
| 配送日時の再計算 | 2 | 3 | 5 | 3.2 |
| メール通知 | 1 | 2 | 3 | 2.0 |
| テスト・リリース | 2 | 3 | 5 | 3.2 |
| 合計 | 13 | 20 | 34 | 21.2(σ≒1.5、95%で約23.7) |
📏
三点見積もりでは防げなかった。 実績41人日は95%の線(約23.7)の倍近い。増えた21人日はすべて WBS の外 から来ている。
| 増えた分 | 人日 | 当時知り得たか | どの道具で扱うべきだったか |
|---|---|---|---|
| 倉庫ごとの締め時刻 | +9 | 知り得た(物流の7月の計画書) | 要求の確認(物流を Contributor に入れ、変更可否の判定ルールを聞く) |
| 物流の API の遅れ | +7 | 遅れは知り得なかった。依存があることは分かっていた | リスク登録簿(他チーム依存の行と、遅れたときの代わり) |
| ゲスト購入の追加と断念 | +5 | 追加は自分たちの判断 | 変更管理(足すときは何を外すかと一緒に記録) |
4. 継続・転換・中止の比較表
41人日(約205万円)はどの案でも戻らないので表に入れない。効果は平常月の件数、1件600円。回収率は 仮定。
| 案 | 中身 | 狙う塊 | これから先の効果(月) | これから先の工数 | 効果÷工数 |
|---|---|---|---|---|---|
| B. 転換: 出荷後は配送業者へ案内 | 出荷指示済みのとき、エラーではなく追跡番号つきで業者の受け取り変更リンクを出す。出荷完了メールにも載せる | 出荷後 3,410件 | 3,410×20%(幅10〜30%)≒ 682件・約41万円 | O3/M4/P8 → E 4.5人日 | 約152件/人日 |
| A. 継続: 今の機能を広げる | ゲスト購入もメールのリンクから変更(723×40%)+導線改善(417×30%) | 出荷前の残り 1,140件 | 289+125 ≒ 414件・約25万円 | O6/M8/P14 → E 8.7人日(本人確認の設計が要る) | 約48件/人日 |
| C. 中止 | 機能を閉じる | — | −1,400件・約−84万円 | 保守が月1.5人日減る(約7.5万円) | 損 |
| D. 物流に締め時刻の後ろ倒し | 出荷前の割合を増やす | 出荷後の一部 | 不明 | MOps 0、物流と倉庫の費用 | 判断できない |
- B を先、A は B の結果を見てから。B は効果÷工数で A の約3倍で、S20 の空き9人日に入る
- B と A は狙う塊が重ならないので、両方で 1,400+682+414 ≒ 2,496件(約40%)。ただし B の幅は大きく(10%で341件、30%で1,023件)、この40%を新しい約束にはしない
- 繁忙期(出荷約1.6倍、仮定)は B の効果が月約1,090件に増える見込み。10/30 リリースなら間に合う
🧩
なぜ B なのか(JTBD から): 出荷後にエラーを見た後で問い合わせた6人の言い分は全員「受け取れない日に届いて、不在票と再配達のやり取りになるのが嫌」。店で日時を変えたいのではなく、受け取れる日に届けばよい。出荷後でも配送業者の会員サービス(例: ヤマト運輸 クロネコメンバーズ、参照日 2026-10-04)で受け取り日時を変えられる。7/8 のメモは「店の画面で変える」という手段を前提にしていた。(インタビュー6人は少なく、回収率20%は仮定のまま。見直し基準で確かめる)
試算してみる
回収率と季節の倍率は 仮定。案の順番と桁を見るためのもの
5. 転換案(B)のユーザーストーリーとリスク登録簿
| ID | ストーリー | pt 目安 |
|---|---|---|
| US-B1 | 出荷準備に入った注文の配送日時を変えたい購入者として、注文履歴から追跡番号つきで配送業者の受け取り変更ページへ移りたい。受け取れない日に届いて再配達のやり取りになるのを避けるため | 3 |
| US-B2 | 出荷完了メールを受け取った購入者として、メールから直接、配送業者の受け取り日時を変えたい。注文履歴を開かずに済ませるため | 2 |
| US-B3 | CS 担当として、問い合わせの前に購入者が業者案内を見たかを区別したい。B の効果を4週後に確かめるため | 2 |
US-B1 の受け入れ条件
Given 東日本倉庫から出荷指示済みの注文(配送業者: ヤマト運輸、追跡番号あり)
When 購入者が注文履歴で「配送日時を変更」を押す
Then エラーではなく「この注文は出荷準備に入りました。配送業者のページで受け取り日時を変更できます」と表示し、
追跡番号と、業者の受け取り変更ページへのリンクを出す
Given 出荷指示済みだが、追跡番号がまだ発行されていない注文
When 購入者が「配送日時を変更」を押す
Then 「追跡番号の発行後(通常○時間以内)に、出荷完了メールでご案内します」と出し、問い合わせ窓口も併記する
Given 配送業者が物流から取得できない注文
When 購入者が「配送日時を変更」を押す
Then 追跡番号と、取り扱いのある配送業者の一覧(各社の受け取り変更ページ)を出す
リスク登録簿(Day042 の尺度: 確率1〜5 × 影響度1〜5、赤≥15/橙10〜14/黄7〜9/緑≤6)
| ID | リスク(原因→事象→影響) | 確率 | 影響 | 点 | 対応 | オーナー | 見直し |
|---|---|---|---|---|---|---|---|
| R1 | 物流の「倉庫→配送業者」の情報が取れない → 業者リンクを出せない → B の効果が出ない | 3 | 4 | 12 橙 | 軽減: 依存の約束。間に合わなければ業者一覧(US-B1 の3つ目) | MOps | 10/14 |
| R2 | 購入者が業者側で日時を変える → 注文履歴と食い違う → 問い合わせ | 4 | 2 | 8 黄 | 軽減: 注文履歴に「業者で変更した日時は反映されません」 | MOps | リリース2週後 |
| R3 | 10/30 に出せない → 繁忙期に間に合わない | 2 | 4 | 8 黄 | 判断日 10/23: US-B3 を後回しにして B1・B2 だけ出す | 注文後体験ライン | 10/23 |
| R4 | 回収率20%を測らないまま A に進む(P2 と同じ失敗) | 3 | 3 | 9 黄 | 軽減: リリース2週後にリンクのクリック数とその後の問い合わせを測る | PdM | 11/13 |
| R5 | 業者ページの URL 変更 → リンク切れ | 2 | 3 | 6 緑 | 受容: 週1回のリンク確認 | MOps | 毎週 |
6. 物流チームとの依存の約束
7/8 の決定で効いた外れ方の1つは「物流への依存が、計画にもリスク登録簿にも載っていなかった」こと。今回は依存を約束の表にして双方のリードが確認する。
| 何を | 誰が | いつまでに | どんな形で | 間に合わないとき |
|---|---|---|---|---|
| 倉庫ごとの配送業者(業者コード) | 物流 | 10/14(水) | 既存の出荷実績 CSV に列を1つ足す(新しい API は作らない) | MOps が追跡番号の形式から推定。推定できなければ業者一覧 |
| 締め時刻を変えるときの事前連絡 | 物流 | 変更の2週間前 | 依存台帳(共有シート)+ MOps の Slack に通知 | MOps が月1回、倉庫ごとの締め時刻を突き合わせる |
| 出荷指示ステータスの意味が変わるときの連絡 | 物流 | 変更の2週間前 | 同上 | 同上 |
| 業者コードを使う側の変更の連絡 | MOps | 変更の1週間前 | 同上 | — |
🔗
頼む側(MOps)が一番小さい形(CSV に列を1つ)で頼み、間に合わないときの代わりを自分の側に持つ。相手の遅れで自分のリリースが止まらないようにする。
7. 見直しメモ(10/8 見直し会用・1ページ)
配送日時のセルフ変更(8/18 リリース)の見直し — 続けるか・やり方を変えるか・止めるか
- 決めること
- 注文後体験ラインの S20(空き9人日)を何に使うか
- 期限
- 10/9(金)。過ぎると S20 に入らず、繁忙期前(10/30)のリリースに間に合わない
- Approver
- EC事業本部長(7/8 と同じ)/Contributors: CS・経理・マーケ各部長、エンジニアリード、物流リード
- 結果
- 台風分を除いて −22.6%。基準25%に届かず、見込み40%の約半分
- 外れた理由
- 出荷前の割合を70%と置いたが実際は45%で、当時2日で測れた。機能は出荷前の人の約半分に使われ、狙いどおり動いている
推奨: B(転換)を S20 に入れる。A は B の2週後の数字を見て決める。C(中止)は採らない
- B は残った最大の塊(出荷後3,410件)を狙う唯一の案で、効果÷工数が A の約3倍
- C は今の効果(月約84万円)を捨てて月約7.5万円の保守を浮かせるだけ。「41人日かけたから」続けるのではない。これから先も月約84万円を生むから残す
- B は小さく(4.5人日)、外れても閉じやすい
CS 部長へ: 委託の席数の削減は、B の4週後(11/27)の数字を見てから。今約束できる削減は22.6%まで。
次の見直し基準(件数ではなく出荷1,000件あたり。繁忙期は出荷が約1.6倍になるため)
| B の4週後(11/27)の出荷後の問い合わせ(出荷1,000件あたり、今 22.0) | 判断 |
|---|---|
| 18.7件以下(15%以上減) | B を続け、A に進む |
| 18.7〜19.8件(10〜15%減) | 案内の文面と出す場所を直して、さらに4週見る |
| 19.8件超(10%未満) | 回収率の仮定が外れた。インタビューをやり直し、D を検討 |
決め方の改善(プロセスの宿題)
- 前提の表に「出所(実測/導出/仮定)」と「測るのにかかる日数」の列を足す。測るのに1週間以内の仮定は、測ってから決める
- 他チームへの依存は、計画の時点でリスク登録簿に1行ずつ書き、相手のリードに確認してもらう
- スコープを足すときは、何を外すかと一緒に判断記録を残す
- 残す習慣: 見直しの基準と日付を、決める時点でメモに書くこと
| 反対意見 | 意見 | このメモでの受け止め方 |
|---|---|---|
| マーケ部長 | 「40%に届かなかったので失敗。人を別の施策へ」 | 出荷前の人には狙いどおり効いている。B は4.5人日。11/27 に10%未満ならこの意見に沿って人を回す |
| 経理部長 | 「205万円が無駄になるので続けて回収」 | 結論は同じだが理由が違う。205万円は続けても止めても戻らないので、判断には使わない |
🗂️ 採らなかった案
| 案 | 判断 | 理由 | 判断が変わる条件 |
|---|---|---|---|
| A を先にやる(ゲスト購入対応から) | 次点(B の後) | 効果÷工数が B の約1/3。本人確認の設計が要り、7月にも断念している | ゲスト購入が全注文の30%超に増えている、または B の回収率が10%未満 |
| C 中止 | 不採用 | 今の効果(月約1,400件・約84万円)を捨てる | 保守費が効果を上回ったとき(例: WMS の作り直しで月10人日以上) |
| D 物流に締め時刻の後ろ倒し | 宿題 | 倉庫運用と集荷時刻が絡み、MOps の Approver の権限では決められない | 物流が来期の倉庫運用を見直すとき(効果を数字で渡す) |
| 業者 API で出荷後も店の画面から変更 | 不採用(今回は) | 業者ごとの API 契約が要り11月に間に合わない。ジョブには業者のページで足りる | B の回収率が低く、理由が「業者のページに行くのが面倒」と分かったとき |
| 見込みを下げて基準を満たしたことにする | 不採用 | 基準を後から動かすと、見直しの仕組みそのものが意味を失う | — |
🧭 なぜこう作るのか
1
前提ごとに「当時知り得たか」を書いた。 P2 は2日で測れた(直す)、台風は知り得なかった(直さない)と分けると、プロセスの宿題が1つに絞れる。
2
台風の分を先に除いた。 除かないと「運が悪かった」という言い訳と「台風で18%しか出なかった」という過小評価が両方できてしまう。
3
効果のずれを掛け算の項ごとに分けた。 「差1,204件のうち930件が P2」と言えると、反論ではなく次の手の話になる。
4
三点見積もりで防げたかを正直に検算した。 答えは「防げなかった」。WBS の外から来る増加はリスク登録簿と変更管理で扱う。道具ごとの守備範囲を知ることが大事。
5
サンクコストを表から外し、反対意見で名指しした。 経理部長と結論は同じでも理由が違う。書いておかないと、次に止めるべき案を同じ理屈で続けてしまう。
6
転換先をジョブから決めた。 「店の画面で変えたい」は手段で、ジョブは「受け取れる日に届けばよい」。出荷後3,410件が「減らせない塊」から「別の手段で減らせる塊」に変わった。
7
次の基準を「出荷1,000件あたり」にした。 件数で置くと、繁忙期に効いていても増えて見える。
8
依存を、頼む側が代わりを持つ約束にした。 「遅れないで」と頼むだけでは7月と同じことが起きる。
🔀
別の判断もありうる: A を先にする判断も成り立つ。ゲスト購入が伸びている、またはセキュリティ部門がゲスト向けリンクの方式を用意済みなら、A の工数は小さくなり順番が入れ替わる。CS の席数削減が経営計画に織り込み済みなら「確実な小さい効果(A)を先に取る」方が組織の損が小さい、という判断もある。この資料の役目は、どちらを選ぶにしてもこれから先の損得と、次に何で確かめるかが書かれた状態で Approver が決められるようにすること。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 結果が悪かったので「決め方が悪かった」と結論する | 運で外れた部分まで直そうとし、手順が重くなるだけ | 前提ごとに「当時知り得たか」を書く |
| 「運が悪かった」で片付ける | 測れた前提(P2)が見過ごされ、次も同じ外れ方をする | 運の分を除いた数字でも基準と比べる |
| 担当者の見積もりの甘さを責める | 人が問題を出さなくなる。増分の大半は WBS の外 | 仕組み(依存の欄・変更管理)を直す |
| かかった費用を理由に続ける/止める | これから先の損得と関係ない数字で決める | 比較表からかかった費用を外し、外したと明記 |
| 外れた仮説ごと機能を捨てる | 当たっていた部分まで失う | 外れた前提だけを取り替える(転換) |
| 見直しの基準を後から緩める | 基準を決める意味がなくなる | 基準は動かさず、届かなかった事実から次の手を決める |
| 次の基準を季節で変わる件数で置く | 繁忙期に効いていても増えて見える | 出荷1,000件あたりなどの比率で置く |
🏢 実務での使いどころ
リリースした機能が見込みに届かないのは珍しくない。多くの組織で起きるのは「誰の見込みが甘かったか」の話か、何も振り返らずに次の施策へ移ることのどちらか。同じ型は、A/B テストの結果が見込みの半分だったときの継続判断、外部ベンダーの遅れの後の立て直し、OKR 未達の振り返りにそのまま使える。
- 経営層・Approver: 「失敗か成功か」ではなく「どの前提が外れ、次に何で確かめるか」を受け取る
- CS・経理: 見込みをもとに別の計画(席数削減・予算)を進めていることがある。次の約束は確かめられた数字までにとどめる
- 他チーム(物流): 依存は「お願い」ではなく、期限・形・代わりを書いた約束にする
- エンジニア: 見積もりのずれを「自分の責任」として抱え込まない。WBS の外から来た分を分けて示すのが、次の見積もりを良くする一番の材料
転用できるテンプレート
決定の振り返り表: 前提 | 当時の値(出所) | 実際 | 当時、妥当な手間で知り得たか | 分類(決め方の欠陥/運/当たり)
効果のずれの分解: 見込みの式の項を1つずつ実測に置き換え、項ごとの差を出す。運の分は先に除く
工数のずれの分解: WBS の中の誤差(三点見積もりの幅) | WBS の外(依存・スコープ追加)| どの道具で扱うべきだったか
継続・転換・中止の比較: 案 | 狙う塊 | これから先の効果 | これから先の工数 | 効果÷工数(かかった費用は入れない、と明記)
依存の約束: 何を | 誰が | いつまでに | どんな形で | 間に合わないとき(頼む側が持つ代わり)
見直しメモ: 決めること | 期限 | 結果 | 外れた理由(1行)| 推奨と理由 | 次の見直し基準(比率で)| 決め方の改善 | 反対意見と受け止め方
➡️ 次のステップ
- 11/27 に B の結果が出たと仮定して、3つの判断それぞれの次の1か月の計画を三点見積もりで書く
- 7/8 のメモを「決め方の改善」4項目を入れて書き直すと、どこが変わるか(P2 を測ってから決めていたら、そもそもこの機能を作ったか)
- 自分への問い: CS 部長に「では席数はいつ減らせるのか」と聞かれたら、確かめられた数字だけで1分で答えられるか
- 自分への問い: マーケ部長が正しかった場合(B が10%未満)、自分の推奨のどの前提が外れたことになるか。今のうちに言えるか
🚧 扱わなかった範囲(この演習の限界)
- 回収率(B 20%・A 40%/30%)、繁忙期の出荷1.6倍、三点見積もりの O/P、外注単価(1人日5万円)は仮定。B の効果の幅(月341〜1,023件)が大きいことを本文に残した
- 出荷後に問い合わせた人へのインタビューは6人で、ジョブの確からしさは十分ではない。次の見直し基準で確かめる設計にした
- ゲスト購入向けリンク(A)の本人確認の方式、追跡番号を画面やメールに出すことの法務確認は扱っていない
- 配送業者ごとの受け取り変更サービスの条件(会員登録の要否、変更期限)は、ヤマト運輸の会員サービスのページの存在だけを確認した。他社の条件と、規約上リンクしてよいかは未確認
- 物流の締め時刻(D)の費用と効果は試算していない(MOps の権限の外のため宿題)
- CS の委託席数の削減計画がどの程度経営計画に入っているかは扱っていない
- 「実測」ラベルの数値は演習シナリオ上の設定値。外部の一次資料は Web 2点(Google SRE 本 Ch.15、ヤマト運輸 クロネコメンバーズ、参照日 2026-10-04)と論文1点(Arkes & Blumer 1985、Crossref で書誌確認)。Duke(2018)と Ries(2011)は書籍の記憶による要約で未照合