🎬 シナリオ
MOps チームは、販促メールの配信を自社運用の配信サーバから配信SaaS「M社」（架空）へ移す案件を 9/7 から進めている。今日は 10/12（月・祝日）。明日 10/13（火）の定例に残りの見通しを出す。
なぜ移すのか
| 項目 | 値 | 出所 |
|---|---|---|
| 1日の販促メール送信数 | 平常 約18万通、年末ピーク 約60万通 | 実測 |
| Gmail 宛ての割合 | 約41% | 実測 |
| 旧サーバの対応状況 | ワンクリック配信停止（List-Unsubscribe-Post）未対応。DMARC は p=none、alignment が一部崩れている | 実測 |
| Gmail の大量送信者要件 | 1日5,000通超: SPF・DKIM・DMARC、ワンクリック配信停止、迷惑メール率 0.30% 未満。2024年2月1日から | 一次資料 Google Email sender guidelines（参照日 2026-10-12） |
| 旧サーバの機器保守契約 | 11/30 まで。延長は月80万円 | 仮定 |
動かせない日付
- 年末商戦の変更凍結: 11/20（金）〜1/6（水）
- 新しい送信IPは 2週間かけて送信量を段階的に増やす（IPウォームアップ）。段階切替 Q2 は 11/5〜11/19
- → Q2 より前の残り7件は 11/4（水）終業までに終わっている必要がある。間に合わないと切替は 1/7 以降
体制とキャパシティ（10/13〜11/4 = 稼働16日）
| メンバー | 役割 | 割り当て | 人日 |
|---|---|---|---|
| 石井 | バックエンド。B1・B2 を担当 | 100% | 16.0 |
| 今井 | バックエンド。会員基盤と兼務 | 60% | 9.6 |
| 柴田 | フロントエンド・テンプレート | 40% | 6.4 |
| 合計 | 32.0 | ||
9/7 の三点見積もりと、終わった作業の実績（人日）
| ID | 作業 | 種類 | O / M / P | E | 実績 | 実績比 |
|---|---|---|---|---|---|---|
| A1 | 送信ドメイン認証（SPF/DKIM/DMARC） | 基盤 | 1 / 2 / 4 | 2.17 | 2.0 | 0.92 |
| A2 | SaaS 初期設定・権限・送信IP | 基盤 | 1 / 1.5 / 3 | 1.67 | 1.5 | 0.90 |
| B1 | 会員リスト同期（夜間差分 → SaaS API） | 外部連携 | 3 / 5 / 9 | 5.33 | 9.5 | 1.78 |
| B2 | バウンス・苦情の Webhook 受信 | 外部連携 | 2 / 3 / 6 | 3.33 | 6.0 | 1.80 |
| T1 | テンプレート移行 第1群（定型通知 8本） | テンプレ | 2 / 3 / 5 | 3.17 | 3.5 | 1.10 |
| T2 | テンプレート移行 第2群（キャンペーン 7本） | テンプレ | 2 / 3 / 5 | 3.17 | 3.0 | 0.95 |
| T3 | テンプレート移行 第3群（ステップメール 6本） | テンプレ | 2 / 3 / 5 | 3.17 | 4.0 | 1.26 |
| C1 | ワンクリック配信停止（RFC 8058） | 新規仕様 | 2 / 4 / 7 | 4.17 | 4.5 | 1.08 |
| 終わった8件の計 | 26.17 | 34.0 | 1.30 | |||
計画に無かった作業: X1 旧テンプレートの文字コード（ISO-2022-JP → UTF-8、機種依存文字の置換を一括で）2.5人日 ／ X2 法務: 配信停止リンクの文言確認 0.5人日
残りの作業（11/4 までに終わらせるもの）
| ID | 作業 | 種類 | O / M / P | E |
|---|---|---|---|---|
| B3 | 開封・クリックのイベント取り込み（Webhook → DWH） | 外部連携 | 3 / 4 / 8 | 4.50 |
| B4 | 配信結果の日次CSV取り込み（旧レポート互換。SFTP） | 外部連携 | 2 / 3 / 5 | 3.17 |
| T4 | テンプレート 第4群（会員ランク通知 5本） | テンプレ | 2 / 3 / 5 | 3.17 |
| T5 | テンプレート 第5群（カート・再入荷 6本） | テンプレ | 2 / 3 / 5 | 3.17 |
| T6 | テンプレート 第6群（季節・その他 6本） | テンプレ | 2 / 3 / 5 | 3.17 |
| C2 | 配信頻度の上限（1人に週3通まで。新しい要望） | 新規仕様 | 2 / 3 / 6 | 3.33 |
| Q1 | 並行配信テスト（社内宛 2,000アドレスへ旧・新で同じ配信） | テスト | 3 / 4 / 7 | 4.33 |
| 計 | 24.83 | |||
石井さんのメモ（B1・B2 が延びた理由）
📝
B1: API が毎秒10件までで、120万件の初回同期が通らなかった。差分と分割で作り直して +3.0。配信停止フラグの意味が旧と新で逆で +1.0。
B2: Webhook の署名方式が文書と違った。サポートの回答待ち2営業日（実作業 +1.0）。同じイベントが最大3回届くので重複排除に +1.5。受信の土台は B3 でもそのまま使えるはず。ただ、開封・クリックのイベントが同じ署名方式かはまだ見ていない。
B2: Webhook の署名方式が文書と違った。サポートの回答待ち2営業日（実作業 +1.0）。同じイベントが最大3回届くので重複排除に +1.5。受信の土台は B3 でもそのまま使えるはず。ただ、開封・クリックのイベントが同じ署名方式かはまだ見ていない。
関係者の発言
🗣️
チームリード: 「終わった分で 1.3倍。残り 24.8 × 1.3 = 32.3。キャパ 32.0 なので、ほぼちょうど。このまま行けると思う」
CRM担当課長（長谷川）: 「年末は配信が多い。頻度の上限（C2）は年末に欲しかった。ただ、切替が年明けにずれるのは困る」
インフラ課長（江口）: 「切替が 1/7 以降になるなら、12月・1月の延長（160万円）を 10/30 までに申し込む必要がある」
CRM担当課長（長谷川）: 「年末は配信が多い。頻度の上限（C2）は年末に欲しかった。ただ、切替が年明けにずれるのは困る」
インフラ課長（江口）: 「切替が 1/7 以降になるなら、12月・1月の延長（160万円）を 10/30 までに申し込む必要がある」
📝 課題
あなたのタスク: 10/13（火）の定例に出す残りの見通しの資料一式を作ってください。
1
実績比の表（原因タグつき）: 終わった8件と計画外2件の原因を「一回限り」「繰り返す」「見積もり誤差」「計画外作業」に仕分ける
2
残作業の見積もり直し表: 残り7件ごとに、そのまま／実績比をかける／積み上げで見積もり直す、を決めて理由を書く
3
4つの方法の確率比較: ①元のまま ②一律1.3倍 ③EBS（実績比を乱数で引く） ④原因別。32.0人日以内の確率
4
選択肢別の確率表と分岐ルール: B3 の前提が未確認であることを踏まえ、確認の中身と結果ごとの動きを先に決める
5
見積もり直しの記録: 元の見積もりを消さずに、何をいつなぜ変えたか
6
定例向け1ページ: 一言の答えと、長谷川課長・江口課長に決めてほしいこと
7
採らなかった案: 2つ以上、理由と「判断が変わる条件」つき
💡 ヒント（クリックで開く）
ヒント1: 1.3倍だった作業は何件ある？
「全体で 1.3倍」は 0.9倍と 1.8倍の混合。8件の実績比を並べると、1.3倍前後の作業は1件も無い。
ヒント2: 延びた原因は払い終えたか
B1・B2 の延びを1つずつ見る。土台を作り終えた（一回限り）なら、残りに 1.8 をかけると二重払い。「SaaS の文書に書いていない制約」は別の受け口でも出る（繰り返す）。
ヒント3: プロジェクトの中の参照クラス
テンプレート移行は同じ型が6群。終わった3群の実績比（1.10・0.95・1.26）が残り3群のいちばん良い手がかり。平均1つにせず、3つのどれもありうると扱う。
ヒント4: 計画外作業は別に持つ
X1・X2 は見積もりの誤差ではない。実績比に混ぜると原因が見えなくなる。「残りの計画の何%くらい出るか」を幅で持つ。
ヒント5: PMBOK の EAC
EVM の完成時総コスト見積もり（EAC）は、差異が「一時的」か「今後も続く」かで計算を分ける。チームリード案は全差異を「今後も続く」と見なした計算。
ヒント6: 確率を一番動かす前提を確かめる
B3 が 1.8倍になるかどうかで確率は大きく動く。それが半日の確認で分かるなら、先に確認して、結果ごとにやることを決めておく。
ヒント7: 何%を目指すか
間に合わないと 160万円と、年末の大量配信をワンクリック配信停止の無い旧サーバで送ること。損失が大きいので 90% 以上を目指す。
📚 背景知識・用語解説
途中で見積もり直す: 実績が出たのに元の見積もりのまま進めるのも、全部に同じ倍率をかけるのも、実績を半分しか使っていない。どの種類の作業が、なぜずれたかを読み、残りのどこに引き継ぐかを決めるのが見積もり直し。
Evidence Based Scheduling（EBS）
Joel Spolsky が 2007 年に公開した方法。過去の作業ごとに「見積もり÷実績」（velocity）を記録し、残りの見積もりを過去の比から乱数で1つ引いて割り直す。これを繰り返して終わる日の分布を出す。この演習では逆数の「実績÷見積もり」を実績比と呼ぶ。
- 一次資料 Joel Spolsky, "Evidence Based Scheduling", Joel on Software, 2007-10-26（WebFetch で確認、参照日 2026-10-12）。作業を最大16時間に分けること、不具合修正の時間を元の作業に付け直すことも求めている
- 弱点: 過去の比を区別なく引くので、「払い終えた原因」で大きくずれた作業の比も残り全部にかかりうる。④（原因別）はそこを直す
一時的な差異と、今後も続く差異（PMBOK の EAC）
EVM では、差異が一時的なら「残りは元の見積もりどおり」、今後も続くなら「残りを現在の効率（CPI）で割る」と分けて計算する（PMBOK ガイド第6版 §7.4.2.2。書籍・記憶によるもので本文は未照合）。チームリード案「残り全部に 1.3」は全差異を今後も続くと見なした計算。EVM はテーマ1-6で扱う。
プロジェクトの中の参照クラス
参照クラス予測（Flyvbjerg 2006, Project Management Journal 37(3)）は似た過去案件の実績の分布で補正する方法。同じ型の作業がプロジェクト内で繰り返されるなら、終わった分がいちばん近い参照クラス。ただし3件しかないので平均1つで代表させない。
計画外作業（発見された作業）
見積もった作業が延びたのではなく、表に無かった作業が増えたもの。終わった計画 26.17人日に対して X1・X2 で 3.0人日（11.5%）。ただし2件とも一回限りなので、残りでも同じ率とは限らない → 0〜11.5% の幅で持つ（仮定）。
🧩 原因の仕分けクイズ
それぞれの出来事は、残りの作業の見積もりにどう効くか。4つのどれかを選んでください。
✅ 模範解答
1. 実績比の表（原因タグつき）
黄色の縦線は全体平均 1.30。1.3倍前後だった作業は1件も無い。
| ID | 実績比 | 何が起きたか | 原因 | 残りへの引き継ぎ |
|---|---|---|---|---|
| A1・A2 | 0.92・0.90 | 手順書どおりの設定 | 誤差 | 同種の作業なし |
| B1 | 1.78 | API 毎秒10件の上限で作り直し（+3.0） | 繰り返す | B4（まだ誰も触っていない SFTP の受け口） |
| B1 | 〃 | 配信停止フラグの意味が逆（+1.0） | 一回限り | 引き継がない |
| B2 | 1.80 | 署名の方式が文書と違った（+1.0・回答待ち2日） | 一回限り（開封・クリックは未確認） | B3: 確認するまで分からない → K1 |
| B2 | 〃 | 同じイベントが最大3回 → 重複排除（+1.5） | 一回限り | 土台は B3 で使う |
| T1〜T3 | 1.10・0.95・1.26 | T3 は差し込み変数の書式違い | 誤差 | T4〜T6 にこの3つの比を使う |
| C1 | 1.08 | ほぼ見積もりどおり | 誤差 | C2・Q1 は8件全体の比 |
| X1 | — | 文字コード変換を全テンプレート一括で | 計画外・一回限り | 実績比に入れない。率で別に持つ |
| X2 | — | 法務確認 | 計画外・一回限り | 〃 |
🔎
1.8倍の2件の延び（合計 +6.8人日）のうち 約半分の +3.5 は一回限り。B1 の +3.0（API の上限）だけが「繰り返す」型。
2. 残作業の見積もり直し表
| ID | 元の E | 扱い | 新しい値 | 理由 |
|---|---|---|---|---|
| B3 | 4.50 | 積み上げで見積もり直す | 2 / 3.5 / 7（E 3.83） | 受信の土台は B2 で作った。残るのは DWH 取り込みと年末の件数（1日 最大 約300万イベント）。署名方式は未確認 → K1 |
| B4 | 3.17 | × B1・B2 の比 | E 約5.7 | 新しい受け口。「文書に無い制約」は繰り返す型 |
| T4〜T6 | 3.17 ×3 | × T1〜T3 の比 | E 約3.5 ×3 | 同じ型の作業の実績 |
| C2 | 3.33 | × 8件の比 | E 約4.1 | 似た作業なし |
| Q1 | 4.33 | × 8件の比 | E 約5.3 | 〃 |
| 計画外 | — | 計画の 0〜11.5%（一様） | — | X1・X2 は一回限り。0% とも言えないので幅で 仮定 |
3. 4つの方法の確率比較
β-PERT 分布と実績比の抽選を 4万回（Python、乱数の種 20261012）。キャパ 32.0人日。
| 方法 | 中身 | 平均 | 85% の工数 | 32.0以内の確率 |
|---|---|---|---|---|
| ① 元のまま | 9/7 の O/M/P＋計画外 | 26.3 | 28.4 | ほぼ100% |
| ② 一律1.3倍（リード案） | O/M/P すべて ×1.30 | 34.1 | 36.9 | 21% |
| ③ EBS | 元の E × 8件の比のどれか | 32.2 | 36.1 | 50% |
| ④ 原因別 | 表2 | 31.1 | 34.5 | 64% |
- ②は一回限りの延びまでテンプレート・C2・Q1 にかけている。「ほぼちょうど」は平均どうしの比較で、確率にすると約2割
- ④でも 64%。そのまま進めてよい数字ではない
- B3 も 1.8倍になると ④ は 16% まで落ちる。この前提が最も効く
4. 確認作業と分岐ルール
K1: B3 の受信の土台が使えるか（石井 0.5人日、10/14 終業まで、結果は 10/15 朝会）— 検証環境で開封・クリックを10件ずつ発生させ B2 の受信口で署名検証が通るか／一度 500 を返して再送の回数・間隔を見る。
| K1 の結果 | やること | 確率 |
|---|---|---|
| 使える | C2 頻度上限を 1/7 以降へ（案B） | 96% |
| 使えない | C2 と B4 を 1/7 以降へ。11〜12月はマーケ分析担当が SaaS 画面から週1回 CSV を手で出す（週30分） | 97% |
5. 選択肢別の確率表
| 案 | 中身 | 確率（B3 が 1.8倍なら） | 85% | 失うもの |
|---|---|---|---|---|
| A 全部 | 残り7件すべて | 63%（16%） | 34.5 | なし（ただし遅れたら全部 1/7 以降） |
| B C2 を後へ | 頻度上限は切替後 | 96%（62%） | 29.8 | 年末の頻度上限 → 配信計画を「1人週3通以内」で組む運用で代替 |
| C B4 を後へ | 手作業 0.5人日を加算 | 97% | 28.8 | 11〜12月の週次レポートが手作業 |
| D B と C | ほぼ100%（97%） | 24.0 | 両方 | |
| E 人を借りる | 上野さん 50%×10日、立ち上がり 1.0 → 実質 +4.0 | 92% | 34.5 | 他チームに 5人日の穴 |
| 計画外の率（固定） | 0% | 5% | 11.5% | 20% |
|---|---|---|---|---|
| 案A | 82% | 67% | 44% | 18% |
| 案B | 99% | 97% | 90% | 72% |
キャパ感度（案B）: 30人日 87% ／ 31人日 92% ／ 33人日 98%。
👥
人を足して効くのは、手順書があってばらつきの小さい作業だけ。テンプレート（0.95〜1.26）なら効くが、B3・B4 のような「文書に無い制約」に当たる作業では立ち上がりで遅くなる。E は K1 が「使えない」かつ B4 の手作業が受け入れられない場合の予備。
🧮 試算ツール（ブラウザ内で乱数 1万回）
白線は目標の 90%。計画外は「0〜上限」の一様乱数。乱数の回数が少ないので、上の表と ±1〜2pt ずれることがある。
⚖️ 必要な確率の決め方
| 間に合わないと | 値 | 出所 |
|---|---|---|
| 旧サーバの保守延長（12月・1月） | 80万円 × 2 = 160万円（申し込み期限 10/30） | 仮定 |
| 年末ピーク（1日 約60万通、Gmail 約41%）を旧サーバで送る | ワンクリック配信停止の要件（2024-02-01〜）を満たさないまま、1年で最も多く送る | 実測＋一次資料 |
| チームの1月 | 切替作業 6人日以上が残る | 導出 |
Day047 は「間に合わなくても今までどおりに戻るだけ」だった。今回はお金と年末の到達率の両方を失うので 90% 以上を目指す。案A 63% は不可、案B 96% は届く。
🗂️ 見積もり直しの記録（元の値は消さない）
| 日付 | 作業 | 元（9/7） | 変更後 | 理由 | 根拠 |
|---|---|---|---|---|---|
| 10/12 | B3 | 3 / 4 / 8 | 2 / 3.5 / 7 | 受信の土台を B2 で作った | 石井メモ。K1 で再確認 |
| 10/12 | B4 | 3.17 | × 1.78〜1.80 | 新しい受け口。繰り返す型 | B1 の API 上限 |
| 10/12 | T4〜T6 | 3.17 | × 0.95〜1.26 | 同じ型の作業の実績 | T1〜T3 |
| 10/12 | C2 | 3.33 | 1/7 以降へ（案B 承認時） | 90% 以上に届かせる | 表5 |
| 10/15 予定 | B3・B4 | — | K1 の結果で分岐 | — | 表4 |
毎週の回し方: 毎週金曜に、終わった作業の実績比と原因タグを追記し、④で確率を出し直す。80% を下回ったら次の定例で外すものを決める（順番: C2 → B4 → T6 の一部）。
📄 定例向け1ページ（10/13）
配信SaaS 移行 — 11/4 までに残り作業が終わる確率と、決めてほしいこと
一言で: 今の範囲のままでは、11/4 までに終わる確率は約6割です。配信頻度の上限（C2）を年明けに回せば約96%になります。
なぜ約6割か: 終わった作業は平均 1.3倍かかりましたが、延びたのは SaaS と直接つなぐ2件（1.8倍）だけで、その延びの多くは土台づくり（払い終えた分）です。残りの作業ごとに原因を当てはめて計算し直しました。「全部 1.3倍」なら約2割、「元のまま」ならほぼ100% と出ますが、どちらも実績の読み方として不正確です。
10/15 にお知らせすること: 開封・クリックの受け取りに作った土台が使えるか（10/14 に半日で確認）。使えなければ旧レポート互換の CSV（B4）も年明けへ（11〜12月は週30分の手作業）。この場合も約97%。
間に合わない場合: 切替は 1/7 以降。延長 160万円と、年末の配信をワンクリック配信停止の無いまま送ることになります。
決めてほしいこと
- 長谷川課長: C2 を 1/7 以降に。年末の配信計画を「1人週3通以内」で組めるか
- 長谷川課長: K1 が「使えない」場合、B4 の代わりの手作業（週30分）を受け入れられるか
- 江口課長: 10/30 時点で確率が 80% を下回っていたら延長を申し込む、という線でよいか
🔀 検討した案と採らなかった理由
| 案 | 判断 | 理由 | 判断が変わる条件 |
|---|---|---|---|
| 原因別＋案B＋K1 の分岐 | 採用 | 96%（K1 が「使えない」でも 97%）。既存の機能を守り、まだ誰も使っていない新機能から外す | — |
| 一律1.3倍（リード案） | 不採用 | 一回限りの延びを全作業にかけ、必要以上に外すことになる | 原因が分からない、または多くが繰り返す型の場合 |
| EBS をそのまま | 参考 | 原因の区別が無く、B2 の一回限りの延びがテンプレートにもかかる | 終わった作業が数十件あり原因の記録が無い場合 |
| 案C（B4 を先に外す） | 次点 | 確率は同等（97%）だが、今あるレポートを壊して手作業を生む | 長谷川課長が「年末こそ頻度上限が要る」と言った場合（迷惑メール率 0.30% を守るにも効く） |
| 案E（人を借りる） | 予備 | 92%。他チームに 5人日の穴。案B で足りる | K1 が「使えない」かつ B4 の手作業が受け入れられない場合 |
| 段階切替を1週間に縮める | 不採用 | 新しい IP で急に送ると迷惑メール判定を受けやすい。見積もりの問題をインフラの安全で埋めることになる | SaaS が評判のある共有 IP での送信を許す場合 |
🧠 なぜこう作るのか
- 一律の倍率をかけず、原因で仕分けた。平均 1.3倍は 0.9倍と 1.8倍の混合。残りにかける倍率は作業ごとに違う
- 計画外作業を実績比から外した。X1 を混ぜると「テンプレートが 1.5倍」に見え、原因（一回限りの一括変換）が消える
- 4つの方法を並べた。同じ実績から「ほぼ100%」「約2割」「約5割」「約6割」が出る。読み方で答えが変わることを隠さない
- いちばん効く前提を半日の確認に変えた。B3 で 64% ↔ 16% と動く。結果ごとの動きは先に決める
- 外す順番を「新しい機能から」にした。移行で既存業務を壊すと、別の手作業と信頼の損失が生まれる
- 元の見積もりを消さずに記録した。上書きすると「SaaS 連携は 1.8倍だった」という参照クラスが次に残らない
↔️
別の判断もありうる: 長谷川課長が「年末こそ頻度上限が要る」と言うなら案C（97%）。その場合は旧レポートの手作業 週30分 を誰が持つかを同時に決める。
⚠️ よくある失敗パターン
| 失敗パターン | なぜ問題か | 改善策 |
|---|---|---|
| 「全体で X倍だから残りも X倍」 | 一回限りの延びまで残りにかける／続く延びを薄める | 作業ごとの実績比と原因を並べ、引き継ぎを作業ごとに決める |
| 実績が出ても元の見積もりのまま報告 | 1か月後に遅れが一度に表に出る | 毎週、実績比を追記して確率を出し直す |
| 計画外作業を実績に混ぜる | 見積もりの誤差か作業の増加か分からなくなる | 別の行にし、率で持つ |
| 見積もりを上書きする | 次の案件の参照クラスが消える | 元の値・変更後・理由・日付を残す |
| 平均と平均を比べて「ちょうど」 | 平均どうしが同じなら確率は約5割 | 85% の工数か、キャパ以内の確率で言う |
| 遅れに人を足す | 不確かな作業ほど立ち上がりで遅くなる | 手順書があってばらつきの小さい作業に限る |
🏢 実務での使いどころ
- エンジニアとして: 作業が延びたら理由を一行チケットに書く。石井さんのメモがあったから今回の仕分けができた
- テックリード・PM として: 「何%」を言うとき、どの読み方で出したかを添える。方法を変えて数字が良くなったときは特に
- 事業側と: 外す順番（新機能から、既存業務は守る）を先に合意しておく
- 経営層・インフラへ: お金が動く判断の日（10/30）に、確率を出す日を合わせる
実績比の表: 作業 | 元の E | 実績 | 実績比 | 何が起きたか | 原因（一回限り/繰り返す/誤差/計画外） | 引き継ぎ先
見積もり直し表: 作業 | 元の E | 扱い（そのまま/比をかける/積み上げ直し） | 新しい値 | 理由
方法の比較: 方法 | 平均 | 85% の工数 | キャパ以内の確率
分岐ルール: 確認の中身 | 期限 | 結果 | やること | 確率
見積もり直しの記録: 日付 | 作業 | 元 | 変更後 | 理由 | 根拠➡️ 次のステップ
- テーマ1-3「スケジュール線表」: K1（10/14）・分岐（10/15）・延長判断（10/30）・開発完了（11/4）・段階切替（11/5〜19）・凍結（11/20）を線表に。Q2 の2週間は人日でなく暦で効く制約
- 明日（PM-リスク）: 「SaaS の文書に無い制約」は繰り返す型の原因としてリスク登録簿の1行にできる
- 自分への問い: 10/23 に T4 が 1.6倍で終わったら、T5・T6 にかける比をどう変えるか
- 自分への問い: 終わった作業が 30件あり原因の記録が無いなら、③ と ④ のどちらを使うか
🚧 扱わなかった範囲（この演習の限界）
- 合計工数とキャパの比較で確率を出した。前後関係（B3 → Q1 など）と人ごとの割り当ては扱っていない。Q1 は最後にしか始められないので実際はここより少し低い
- 作業どうしは独立として扱った。B3 と B4 が同じ「SaaS の文書の質」に左右されるなら確率は楽観側にずれる
- 計画外の率（0〜11.5%）は仮定。固定した場合の感度は表5
- 一回限り／繰り返すの仕分けは石井さんのメモに頼った判断。K1 はその一部（B3）だけを確かめる
- Gmail 以外の送信者要件、特定電子メール法の表示義務は扱っていない
- PMBOK の EAC と節番号は記憶で本文未照合。Flyvbjerg 2006 も本文未照合
- 件数・工数・費用・キャパはすべて演習上の設定値
- 一次資料: Spolsky「Evidence Based Scheduling」（2007-10-26）・Google「Email sender guidelines」（WebFetch で確認、参照日 2026-10-12）
📊 自己評価
自分の回答（実績比の仕分け・選んだ案と確率など）
気づき・メモ（所要時間も）