今日の最短ルート（15分しかない日）：1. 「読み手プロファイル」（30秒） 2. 「4段階で見る（日本語）」の Good と Better を見比べる（5分）※Goodは項目が整っていて1行ずつは正しい。ところがPRDの3つの目的と突き合わせると、仕事が9人日分抜けている（対照群・計測・外すスイッチ）。さらに24日の塊と、決定済みの案Cが反映されていない担当がある。Betterはそれを直し、森さんの時間（8人日）がどの週に当たるかまで見えるようにしたもの 3. 「今日の演習 → 15分版」をやる（10分）
今日の文書 — WBS / スケジュール線表
WBS（Work Breakdown Structure）/ スケジュール線表 — プロジェクトの仕事を、成果物の単位で漏れなく重なりなく分解した一覧（WBS）と、それを日付の上に並べた図（線表）。WBSは「何をやるか（範囲）」、線表は「いつやるか（時間）」で、別のもの。WBSがあって初めて、誰に何人日を頼むか、どこが遅れたら全体が遅れるかが言える。
この文書の勝負どころ: 100%ルール（範囲の全部が入っている）と、粒度（大きすぎず小さすぎない）。
「項目を並べる」ことは勝負どころではない。目的から逆に数えて、抜けがないかが本番である。典型は次の4つ。
| つまずき | 例（今日の題材） | 見つけ方 |
|---|---|---|
| 100%ルール（抜け） | 「実装」はあるが、成功の測り方（対照群・計測）と、外す手順がない | PRDの目的を1つずつ取り出し、それを満たす成果物がWBSのどこにあるかを指で追う |
| 粒度（塊と砂粒） | 「コーディング 24日」の隣に「文言修正 0.5日」 | 各項目の人日を並べ、10人日（80時間）を超えるものと、1人日未満のものに印を付ける |
| 担当（空欄・古い） | 3/19〜4/6の担当が、すでに決まった案Cと食い違う。「MOps」が誰か分からない | 担当の列を名前で読み、決定事項と日付を突き合わせる |
| 依存と予備 | 日付だけで、何が終わらないと次が始まらないか、遅れをどこで吸収するかが見えない | 一番長い鎖をたどり、予備が何日残るかを数える |
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day020の続き）。
2029年2月6日（火）。1/29に出したプロジェクト計画書（購入完了画面のLINE ID連携導線。Day020）は、2/1（木）の案件会議で案Cが決まった。千葉さん（購入フローチームの主担当）は決済チームの結合テスト（3/19〜4/6）に出る。その3週の穴は、MOpsの佐伯が埋める。佐伯が入れる変更はすべて森さんが承認してから取り込む。
- 宮田は、この計画をWBSと線表に落とす。公開は5/7（月）、判定は8/3（金）、未達なら8/10（金）までに設定1つで外す（Day020）
- 提出: 2/6（火）に購入フローチームの森さんへ（写し: 藤田部長、高梨部長）。確認会は 2/9（金）14:00（30分）。ここで、佐伯の3件の変更を森さんがいつ承認するかを決める
- 予算は3人月（360万円）。1人月＝21人日〔仮定〕とすると63人日。MOps（宮田・佐伯）の分は予算外（Day020）
- 動かせない日: GW凍結 4/27（金）〜5/6（日）は本番に出せない（サイト開発部のルール）。決済チームの6/1後払い決済は、契約で固定
- 読み手: 森さん（購入フローチーム リード。サイト開発部）。カタログの主な読み手は「実行チーム」。Lv2（距離のある読み手）に合わせ、ルール5により、森さんは実行チームの一員だが別の部署の人として設定した。購入完了画面のコードと千葉さんの空きは彼が握り、MOpsの言葉（連携フラグ、対照群、判定）は知らない
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 森さん（購入フローチーム リード）。藤田部長（サイト開発部長）と高梨部長（MOpsの上長）は写し。千葉さんには、森さんが自分の判断で見せる |
| 何を判断するために読むか | ①自分の時間（レビュー・設計・受入）と千葉さんの時間が、WBSのどこに当たるか確認し、受けるか ②佐伯の変更をいつ承認するか（枠の置き方） ③6/1の決済や自チームの他の仕事とぶつからないか |
| 何を知っているか | 購入フローのコード、既存のA/Bテスト基盤（1/24に会員ID固定の振り分けができると確認した本人）、千葉さんの空き、GW凍結のルール、2/1の決定（案C） |
| 何を知らないか | MOpsの連携APIの中身、「連携フラグ」「対照群」などMOpsの言葉、判定の基準（12週で約2,700人の追加連携）、なぜ公開が5/7でなければならないか |
| 何を気にしているか | 他部署（佐伯）が自分のチームのコードに入ること（品質の責任は自分）。レビューが読めない量で降ってくること。3/19〜4/6に千葉さんが抜けた穴と、凍結前の駆け込み |
| 読む時間と場面 | 確認会の前日（2/8木）に、チームの週次計画に載せる前提で1枚10分。自分の時間が何人日、どの週に当たるかを先に探す |
この読み手が変わると何が変わるか: 読み手が 千葉さん（実行する本人） なら、WBSは「自分の40人日が何から何へ流れるか」を中心に、完了の条件（何ができれば終わりか）を厚くする。藤田部長 なら、冒頭は「千葉さんの40人日と、予備4日で公開5/7が守れるか」の1行で、作業パッケージの表は付録に回す。今回は他部署の人が自チームのコードに入る承認を受ける森さんが読むので、森さんの時間がどの週に当たるかと、承認の枠の案を先に置く。
4段階で見る — 作業パッケージ表（冒頭）
以下は同じWBSの 「作業パッケージ表（冒頭）」の部分を4段階で書き分けたもの。差が出るのは項目の数ではなく、目的から数えて抜けがないか、塊と砂粒がないか、担当が決定事項と合っているかである。
タブで精読、「横に並べる」で差を一望できる（横並びは各段階の要点3行だけ）。
行数 10・15・13・10、字数 Bad76 → Good239 → Better702 → Best515字（空白を除く・実測）。Best は Better より短い（行数・字数とも）。
Bad
見出し6つだけ。「開発（3人月）」の1行に仕事の大半があり、「その他」「PM作業」が捨て場。
担当は部署名で、3/19〜4/6の千葉さんの不在もGW凍結も見えない。
「詳細は進めながら」で、森さんは自分の時間を週次計画に載せられない。Good
階層・番号・担当・日付が揃うが、2/1の決定（案C）が入っていない。
PRDの「測る」「外す」に当たる仕事が9人日分抜け、24日の塊と0.5日の砂粒が同居。
「連携フラグ」などMOpsの言葉で、森さんの時間はどこにも出ていない。Better
お願い（森さんの時間8人日の内訳）が2行目。承認が要る所に★。
PRDの3つの目的を作業パッケージに1対1で対応させ、塊を10人日以下に分けた。
だが承認の枠の案・予備の使い方・凍結の解釈・返事がないときの動きがない。Best
決めてほしいこと（案A〜C）と既定（枠を仮置き）が冒頭。案Cで予備が0になることも書く。
18の作業パッケージを1行に畳み、一番長い鎖と予備4日、使い切ったときの結果（5/14・1.7pt）を示す。
残り10.5人日＝A2の外れと一致、凍結の解釈は〔仮定〕で確認先つき。Bad
Six headings. "Development (3 person-months)" hides most of the work; "Other" and "PM work" are dumping grounds.
Owners are team names; Chiba's absence from 19 Mar to 6 Apr and the freeze are invisible.
"Decide as we go" gives Mori nothing to put in his weekly plan.Good
Hierarchy, numbers, owners and dates, but the 1 Feb decision (Option C) is missing.
Nine person-days of the PRD's "measure" and "remove" work are absent; a 24-day lump sits beside a half-day speck.
MOps jargon ("link flag"); Mori's own time appears nowhere.Better
The Ask (Mori's 8 person-days, itemised) is on line two; stars mark what needs his approval.
The PRD's three goals map one-to-one to work packages; lumps split to 10 person-days or less.
But no approval-slot options, no buffer logic, no freeze assumption, no default.Best
Decision needed (A-C) and a default (slots on the calendar) up front; the cost of C (buffer to zero) is stated.
Eighteen packages folded into one line; longest chain, 4-day buffer and the result of using it up (14 May, 1.7pt).
The 10.5 days left equal assumption A2 failing; the freeze assumption is flagged with an owner.Bad — 妥協して雑に作った状態 ／ 10行・76字
WBS（LINE導線）
・設計
・開発（3人月）
・テスト
・リリース
・PM作業
・その他
期間: 2/5〜5/7
担当: サイト開発部、MOps
※詳細は進めながら決めるBad ／ 10 lines
WBS (LINE prompt)
- Design
- Development (3 person-months)
- Testing
- Release
- PM work
- Other
Period: 5 Feb - 7 May
Owners: Site Development, MOps
Note: details to be decided as we go"Other" と "PM work" は、英語圏のレビューでは100%に見せる捨て場として最初に指摘される。"3 person-months" は予算で、分解ではない。英文の WBS の要素は成果物の名詞で書くのが型だが、ここでは活動の見出しが並んでいる。
Good — 型は満たしている ／ 15行・239字
WBS v1 MOps 宮田 2029/2/6（1/29の計画の日程を表にしたもの）
1 設計
1.1 デザイン作成 デザイナー 2/5〜2/16
1.2 設計書作成 千葉 2/5〜2/9
2 開発
2.1 コーディング 千葉 2/13〜3/16（24日）
2.2 ボタンの文言の修正 千葉 0.5日
2.3 連携フラグの付与 千葉
3 テスト
3.1 結合テスト 千葉 3/19〜4/6
3.2 受入テスト 千葉・宮田 4/9〜4/20
4 リリース
4.1 予備 4/23〜4/26
4.2 本番反映 千葉 5/7
備考: 担当「MOps」は結合テストでの連携API確認Badから何が変わったか:
- ②読み手適合が動いた。4つの段階に分かれ、番号が付き、担当と日付が入った。サイト開発部の人が慣れた形で読める
- ④次の行動が少し動いた。千葉さんの日付が見え、森さんは「千葉さんがこの期間に何かをする」と分かる
- 社内に出すなら、これで通る水準。 1行ずつに誤りはなく、1/29の計画の日程とも合っている
まだ足りないもの（ここが今日の本題）:
- 1/29の計画を日程にしただけで、2/1の決定が入っていない。 千葉さんは3/19〜4/6に決済チームへ出る
- PRDの目的から数えると抜けがある。 下の表
- 塊と砂粒が同居している。 「コーディング 24日」（192時間）は80時間の約2.4倍。「文言の修正 0.5日」は独立した項目にする大きさではない
- 「連携フラグの付与」がMOpsの言葉。 森さんは購入完了画面のどこを触るのか分からない
- 森さんの時間がどこにも出ていない。 コードレビューを何回、いつ求められるのかが分からない
| # | つまずき | 数字で見ると |
|---|---|---|
| ① 100%ルール | PRDの「測る」（対照群10%、計測）と「外す」（設定1つ）に対応する成果物がない | 対照群3人日＋計測4人日＋外すスイッチ2人日＝9人日〔導出〕。予算63人日の14% |
| ② 粒度 | 2.1が24日。2.2が0.5日 | 24日×8時間＝192時間＝80時間の2.4倍〔導出〕 |
| ③ 担当 | 3.1の担当が千葉さんのまま。「MOps」が佐伯か宮田か不明 | 3/19〜4/6の14営業日〔導出〕が、決定した案Cと食い違う |
| ④ 依存・予備 | 日付だけ。文言確定（2/16）より前に表示の作業を始めると手戻り。予備4日の使い道が書かれていない | 4/23〜4/26の4営業日〔導出〕 |
Good ／ 15 lines
WBS v1 MOps (Miyata) 6 Feb 2029 (from the 29 Jan plan's schedule)
1 Design
1.1 Create design Designer 5-16 Feb
1.2 Write design doc Chiba 5-9 Feb
2 Development
2.1 Coding Chiba 13 Feb-16 Mar (24 days)
2.2 Fix button wording Chiba 0.5 day
2.3 Set the link flag Chiba
3 Testing
3.1 Integration test Chiba 19 Mar-6 Apr
3.2 Acceptance test Chiba, Miyata 9-20 Apr
4 Release
4.1 Buffer 23-26 Apr
4.2 Deploy to production Chiba 7 May
Note: owner "MOps" means checking the link API during integration番号付きの階層と担当・日付があり、型は揃っている。ただし英語圏のレビュアーは "Does it add up to 100% of the scope?" と "What is each work package's deliverable?" をまず聞く。動詞で始まる項目（Create, Write, Fix, Set）は活動で、成果物ではない。
Better — 読み手に最適化されている ／ 13行・702字
WBS v2（購入完了画面のLINE導線） MOps 宮田 → 購入フローチーム 森さんへ 2029/2/6
お願い: 森さんの時間は計8人日。設計レビュー1、千葉さん分のコードレビュー4、佐伯分1.5、受入立会1、公開前の承認0.5。★が承認の要る所
PRDの3つの目的との対応: 出す=3.1・3.2／測る=3.3・3.4／外す=3.5・1.3。範囲外（アプリ・特典等）は入れていない
2 設計 2.1 導線デザイン（1案） デザイナー4 2/5〜2/16（文言・デザイン確定 2/16）
2.2 連携API呼び出しの設計書 千葉3 2/5〜2/7 2.3 設計レビュー 千葉1・森1 2/16
3 実装 3.3 対照群10%の振り分け（会員ID固定）千葉3 2/8〜2/13 ★ 3.5 外すスイッチ（設定1つ）千葉2 2/14〜2/15 ★
3.2 連携の呼び出しと戻り（失敗時は導線を出さない）千葉8 2/19〜2/28 ★
3.1 未連携の会員だけに出す導線 千葉9 3/1〜3/13 ★ 3.6 単体テスト 千葉3 3/14〜3/16 ★
3.4 計測イベント（表示・押下・連携完了） 佐伯4 3/19〜3/23 ★
4 結合 4.1 ステージングの結合テスト 佐伯6 3/26〜4/2 ★ 4.2 結合の指摘の修正 佐伯4 4/3〜4/6 ★
5 受入 5.1 受入テスト 千葉6（宮田が実施・森さん立会）4/9〜4/16 5.2 受入の指摘の修正 千葉4 4/17〜4/20
6 公開 6.1 本番反映 千葉1 5/7（森さんが4/26に公開前の承認 ★） 1.3 外す作業（8/10）購入フローチーム0.5
合計52.5人日（予算63人日）。予備4日（4/23〜4/26）。3/19〜4/6は千葉さんが決済チームへ。穴は3.4・4.1・4.2を佐伯が埋めるGoodから何が変わったか（★ここが今日の学習の中心）:
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 森さんが判断すること「自分の時間はどこに当たるか」 | 2行目に「お願い」を置き、8人日の内訳を出した。承認が要る作業パッケージに★を付けた。Goodでは森さんの時間が一切出ていなかった |
| 森さんが気にすること「他部署（佐伯）が自分のコードに入る」 | 佐伯の担当を3.4・4.1・4.2の3件に特定し、すべてに★を付けた。Goodの「MOps」という曖昧な担当を、名前と件数に変えた |
| 森さんが気にすること「3/19〜4/6の穴」 | 末尾に、決定済みの案Cを反映した（千葉さんは決済チームへ、穴は佐伯が埋める）。Goodは1/29の日程のままだった |
| 森さんが知らないこと「連携フラグ」 | 名前を、購入完了画面で何が起きるかの言葉にした（「未連携の会員だけに出す導線」「連携の呼び出しと戻り」）。MOpsの言葉は成果物の名前に使っていない |
| 100%ルール（Goodの①） | PRDの3つの目的（出す・測る・外す）を、作業パッケージに1対1で対応させた。3.3・3.4・3.5・1.3が増えた |
| 粒度（Goodの②） | 24日の塊を、3.1（9）・3.2（8）・3.3（3）・3.5（2）・3.6（3）に分けた。1つあたり10人日以下で、完了を数える単位になった。0.5日の文言修正は、3.1に含めた |
抜けを見つける手順: まずPRDの目的を1行ずつ書き出す。次に、その目的を満たす成果物を1つずつWBSに探す。見つからない目的は、作業の抜けである。逆に、どの目的にも対応しない作業パッケージは、範囲外（PRD 3章のN1〜N5）に入っていないかを疑う。
それでも残っている問題（Bestで扱う）:
- 森さんが決めることが「お願い」の1行に埋もれている。 佐伯の3件をいつ承認するかには複数の案があり、どれも予備や森さんの時間に跳ね返る
- 依存と予備が文字になっていない。 一番長い鎖と、予備4日を使い切ったときに何が起きるかが書かれていない
- 「凍結中は何ができないか」の解釈が書かれていない。 本番反映だけが止まるのか、承認済みの取り込みも止まるのかで、予備の意味が変わる
- 前提が外れたときの余裕が書かれていない。 予算に余りはあるのか、前提A2（連携APIを呼ぶだけで済む）が外れたら収まるのか
- 返事がないときの動きがない。 2/9に決まらなければ、3/19の週の承認が宙に浮く
ここで動いた軸: ②読み手適合（森さんの時間と承認、言葉）、⑤想定反論（①〜④の抜け・塊・担当・予備への先回り）、④次の行動（担当の名前と日付）。
Better ／ 13 lines
WBS v2 (LINE prompt on the order-complete page) MOps (Miyata) -> Checkout Flow (Mr. Mori) 6 Feb 2029
Ask: your time is 8 person-days in total: design review 1, code review of Chiba's work 4, Saeki's work 1.5, acceptance 1, pre-release sign-off 0.5. A star marks what needs your approval
Mapping to the PRD's three goals: show = 3.1, 3.2 / measure = 3.3, 3.4 / remove = 3.5, 1.3. Out of scope (app, perks, etc.) is not included
2 Design 2.1 Prompt design (one version) Designer 4 5-16 Feb (copy and design final 16 Feb)
2.2 Link-call design doc Chiba 3 5-7 Feb 2.3 Design review Chiba 1, Mori 1 16 Feb
3 Build 3.3 10% holdout split (fixed by member ID) Chiba 3 8-13 Feb * 3.5 Off switch (one setting) Chiba 2 14-15 Feb *
3.2 Link call and return (no prompt on failure) Chiba 8 19-28 Feb *
3.1 Prompt for unlinked members only Chiba 9 1-13 Mar * 3.6 Unit tests Chiba 3 14-16 Mar *
3.4 Measurement events (shown, clicked, linked) Saeki 4 19-23 Mar *
4 Integr. 4.1 Integration test on staging Saeki 6 26 Mar-2 Apr * 4.2 Fixes from integration Saeki 4 3-6 Apr *
5 Accept. 5.1 Acceptance test Chiba 6 (Miyata runs it, Mori observes) 9-16 Apr 5.2 Fixes from acceptance Chiba 4 17-20 Apr
6 Release 6.1 Deploy Chiba 1 7 May (Mori signs off on 26 Apr *) 1.3 Removal task (10 Aug) Checkout Flow 0.5
Total 52.5 person-days (budget 63). Buffer 4 days (23-26 Apr). Chiba is with Payments 19 Mar-6 Apr; Saeki covers 3.4, 4.1 and 4.2冒頭の "Ask:"（BLUF）で、読み手の仕事量を先に出した。"A star marks what needs your approval" は、読み手が自分の関与だけを拾い読みできるようにする英文の型。英語版は MOps の用語（link flag）を成果物名に使わず、画面で起きることで名付けた。
Best — 読み手が意思決定できる ／ 10行・515字
WBS v3 MOps 宮田 → 購入フローチーム 森さん 2029/2/6
決めてほしいこと（2/9（金）14:00）: 3/19〜4/6に佐伯が出す3件のPR（3.4・4.1・4.2）を、いつ承認するか。返事がなければ 2/9 17:00 に案Aで枠を仮置きする
案A 火・金10:00の30分枠（6枠。3/20は祝日で3/21（水））。PRは前日17:00まで。待ちは最大で営業日2日
案B 出たら24時間以内に承認。待ちは最短。森さんの割り込みが3回
案C 計測（3.4）を4/9以降へ回す。承認は2件、森さんは約0.5人日減る。予備4日が0になる
推奨はA。承認を自分の時間に入れられる。Bは4/5〜4/6に割り込みが重なる
WBS: 18の作業パッケージ。人日は合計52.5（予算63の83%）。残り10.5人日は、前提A2が外れたとき（+0.5人月＝10.5人日）の備え
一番長い鎖: 設計（2/16）→実装（3/16）→結合（4/6）→受入（4/20）→予備4日（4/26）→公開 5/7
予備を使い切ると、公開は5/14（11週）に遅れ、判定に要る差は1.6→1.7pt
凍結（4/27〜5/6）: 承認済みのものしか5/7に出せないと置いた〔仮定。藤田部長に確認〕Betterから何が変わったか:
- ①結論の位置が動いた。冒頭を「決めてほしいこと」にし、案A〜Cと推奨、返事がないときの既定を先に出した
- ②読み手適合が動いた。案ごとの結果を、森さんの言葉（承認を自分の時間に入れられる／割り込みが重なる）で書いた
- ③事実と解釈の分離が動いた。凍結の解釈を〔仮定〕と明記し、誰に確認するかまで書いた。予備を使い切ったときの結果（5/14、1.7pt）はDay020の表の数字を引いた
- ④次の行動が動いた。2/9 17:00の既定（枠の仮置き）、4/5 17:00のPR期限、4/26の公開前の承認
- ⑤想定反論が動いた。「予算は足りるのか」に、残り10.5人日が前提A2の外れ（+0.5人月）とちょうど等しいことを先に書いた。案Cを選んだときに失う予備も書いた（断る・減らす選択肢を判断の材料に入れる）
Bestの方が短い理由（行数。実測は下の「分量」）: Betterの18の作業パッケージの行は、Bestでは「18の作業パッケージ・合計52.5人日」の1行になり、表の全文は全文版（2章）に移した。森さんがその場で決めるのは承認の枠であって、18行を読み直すことではない。代わりに、案A〜C・一番長い鎖・凍結の仮定を足した。
今回はBestまで作るべきか: Best必要。他部署の人間が自チームのコードを変える承認を求める文書で、予備が4日しかなく、承認の置き方で予備が消えるため。ただし、MOps自身のチームだけで完結する小さな作業（自分たちの設定変更など）なら、Betterで十分で、案A〜Cは過剰になる。
分量（日本語・実測）: Bad10行、Good15行、Better13行、Best10行、字数（空白除く）Bad76、Good239、Better702、Best515字（EN 10・15・13・10行）。BestはBetterより3行・187字短い（行数・字数とも）。Goodより行数は5行短く、字数は276字長い。Better→Bestで減る型（Day036以来）。外したのはBetterの18の作業パッケージの行（全文の2章へ移した）。
Best ／ 10 lines
WBS v3 MOps (Miyata) -> Checkout Flow (Mr. Mori) 6 Feb 2029
Decision needed (Fri 9 Feb, 14:00): when do you approve Saeki's three PRs (3.4, 4.1, 4.2) between 19 Mar and 6 Apr? No reply by 17:00 on 9 Feb = we put Option A's slots on the calendar
A. Fixed 30-minute slots, Tue and Fri 10:00 (6 slots; 20 Mar is a holiday, so Wed 21 Mar). PRs in by 17:00 the day before. Longest wait: 2 working days
B. Approve within 24 hours of each PR. Shortest wait. Three interruptions for you
C. Move measurement (3.4) to after 9 Apr. Two approvals, about 0.5 person-day less for you. The 4-day buffer drops to zero
We recommend A. You place the approval in your own calendar. B stacks interruptions on 5-6 Apr
WBS: 18 work packages, 52.5 person-days in total (83% of the 63 budgeted). The remaining 10.5 person-days cover assumption A2 failing (+0.5 person-month = 10.5 person-days)
Longest chain: design (16 Feb) -> build (16 Mar) -> integration (6 Apr) -> acceptance (20 Apr) -> 4-day buffer (26 Apr) -> release 7 May
Use up the buffer and the release slips to 14 May (11 weeks); the required gap rises from 1.6 to 1.7pt
Freeze (27 Apr-6 May): we assume only approved work can go out on 7 May [assumption; to confirm with Mr. Fujita]"Decision needed" と既定 ("No reply ... = we put Option A's slots on the calendar") は英文の依頼の型。"We recommend A." は理由を同じ行に置く。末尾の "[assumption; to confirm with Mr. Fujita]" は、自分から弱点を明かして確認先を書く型で、英語圏のレビューで信頼される。
日英差分ノート
1. 「WBS / スケジュール線表」は日本語では1枚、英語のPM実務では別の成果物
日本語の現場では、WBSに日付と担当を書き込んで1枚の表にし、それを「WBS」と呼ぶことが多い。英語のPM実務（Wikipediaの要約では、WBSは「範囲の100%を成果物で分解したもの」で、スケジュールの手引きにはなるがスケジュールそのものではない）では、WBS（scope）と schedule は別の成果物として扱われる。今日のBestは、読み手が1枚で読めるよう、WBSの表に期間の列を足した。ただし予備や鎖の話は線表の側に置いた。英語版でも "Longest chain" "Buffer" は、WBSの表ではなく別の行に書いた。
2. 「〜対応」「〜作業」の名前は、日本語では通じるが、英語では成果物にならない
日本語では「連携対応」「文言修正」「テスト対応」のような動作を含む名詞が項目名になり、読み手も補って読む。英語の WBS の作法では要素を成果物の名詞で書く（"Link-call design doc" "Prompt for unlinked members only"）。"Fix button wording" "Set the link flag" のような動詞始まりは、activity（作業）であって work package（成果物の束）ではないと指摘される。日本語版でも、「何ができていれば完了か」を言える名前にする（今日の3.1・3.2）。
3. 「予備」は英語では2つに分かれる
日本語の「予備4日」は、遅れを吸収する余裕の総称として使われる。英語のPM用語では、float（slack: 作業が遅れても全体が遅れない余裕）と、schedule reserve / buffer（計画に意図して足した余裕）を分ける。今日の4/23〜4/26は、意図して置いた buffer であり、float ではない。英語版で "Buffer 4 days" と書くのは、この区別のため。buffer を使い切ったら公開が遅れると同じ行に書くのが、英文の約束の型。
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| 作業パッケージ | Work package | 中立。WBSの最下位の単位 |
| 100%ルール | 100% rule | 中立。範囲の全部が入っているかの検査 |
| 完了の条件 | Definition of done / Acceptance criteria | 中立。作業パッケージごとに |
| 決めてほしいこと | Decision needed | 強い・冒頭向け |
| 返事がなければ案Aで進める | No reply = we proceed with A | 強い・既定 |
| 予備 | Buffer / Schedule reserve | 中立。float（余裕）とは別 |
| 一番長い鎖 | Critical path | 中立。「クリティカルパス」の平易な言い換え |
| 〔仮定〕 | [assumption] | 中立。確認先を添える |
| 担当（責任者） | Owner / Responsible | 「MOps」のような部署名は避け、名前で |
| 承認が要る | Needs sign-off | 強い。誰がいつまでにを添える |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | なし。見出し6つ | 4段階の表が先頭。お願いなし | 「お願い」が2行目（森さんの時間8人日） | 冒頭が「決めてほしいこと」と推奨、既定 |
| ② 読み手適合 | 載せる側の都合だけ | WBSの標準の型に揃えた | 森さんの時間の内訳と★、佐伯の3件、画面の言葉の成果物名 | 案ごとの結果を森さんの言葉（自分の時間に入れられる／割り込みが重なる）で書いた |
| ③ 事実と解釈の分離 | 数字は予算の3人月だけ | 日付と人日はあるが、出所なし | 人日と日付の対応。抜けを目的から数えた | 凍結の解釈を〔仮定〕とし、確認先を書いた。予備消費の結果をDay020の数字で示した |
| ④ 次の行動 | 不明 | 担当は千葉さんと部署名 | 担当は名前、期間と★ | 2/9 17:00の既定、4/5 17:00のPR期限、4/26の承認 |
| ⑤ 想定反論 | 無視 | 一部触れる（備考のみ） | 4つのつまずき（抜け・塊・担当・読み手の言葉）を直した | 残り10.5人日＝A2の外れと一致、案Cで予備が0になることも自分から書いた |
Best版・全文
日本語版 全文を見る
WBS / スケジュール線表: 購入完了画面のLINE ID連携導線（Web） 2029年2月6日（火） MOps 宮田
宛先: 森さん（購入フローチーム） 写し: 藤田部長（サイト開発部）、高梨部長（販促システム部）
1. 決めてほしいこと（2/9（金）14:00 確認会）
3/19〜4/6に佐伯が出す3件のPR（3.4計測、4.1結合テスト、4.2結合の修正）を、森さんがいつ承認するかを、次のA〜Cから選んでください。2/9（金）17:00 までに返事がなければ、案Aで枠を仮置きします（カレンダーに入れるだけで、断れます）。
| 案 | 森さんの時間の使い方 | 佐伯の3件の待ち | 予備4日 | 結果の違い |
|---|---|---|---|---|
| A（推奨） | 火・金10:00の30分枠が6回（3/21（水）〔3/20は祝日〕、3/23、3/27、3/30、4/3、4/6）。PRの読み込み1.5人日は枠の外 | 最大で営業日2日（金に出た分は次の火曜） | 4日のまま | 承認を自分の時間に入れられる。4.2の最後のPRは4/5（木）17:00まで |
| B | 出たら24時間以内。読み込み1.5人日と割り込み3回 | 最短（1営業日以内） | 4日のまま | 森さんの割り込みが、4/5〜4/6の4.2に重なりやすい |
| C | 計測（3.4）を4/9以降へ。承認は2件、読み込みは約1.0人日 | 2件で短い | 0になる。4/9〜の受入に計測の4日が並ぶ | 森さんには最も軽い。受入で指摘が出たら公開が5/14に遅れる |
- 6/1の後払い決済（決済チーム。契約で固定）を優先していただいて構いません。千葉さんの3/19〜4/6の決済チームへの派遣は、2/1に決まったとおりです
- GW凍結の例外は求めません
- 佐伯が3週間で入れる変更は3.4・4.1・4.2の3件だけで、承認前には本番に出しません。購入フローの既存コードへの変更は、3.4の計測イベントを呼ぶ数行だけです〔仮定: 3.4の実装は3.1の画面に計測を呼ぶ形。設計レビュー（2/16）で確認〕
- 決まらなかったら: 2/9 17:00 に案Aの枠をカレンダーに入れます。森さんが断れば、宮田が案Bに切り替えます
2. WBS（作業パッケージ表）
★は森さんの承認が要るもの。人日は1人月＝21人日〔仮定〕。担当は名前（部署）。
| ID | 作業パッケージ（成果物） | 担当 | 人日 | 期間 | 完了の条件 | 森さん（人日） |
|---|---|---|---|---|---|---|
| 1.1 | 週次報告（1枚。公開見込み日と、判定に要る差を毎回書く） | 宮田（MOps） | 予算外 | 毎週月曜 | 前週の月曜までに報告済み | — |
| 1.2 | 4週の見直し（6/4）と判定資料（8/3） | 宮田（MOps） | 予算外 | 6/4・8/3 | 12週で約2,700人の追加連携に届いたかを1枚で示す | 6/4に判断 |
| 1.3 | 外す作業（設定1つの切替） | 購入フローチーム | 0.5 | 8/10 | 本番で導線が全会員に出ないことを確認 | — |
| 2.1 | 導線デザイン（1案） | デザイナー（購入フロー） | 4 | 2/5〜2/16 | 文言・デザインが2/16に1案で確定 | — |
| 2.2 | 連携API呼び出しの設計書 | 千葉（購入フロー） | 3 | 2/5〜2/7 | 1ページ。呼び出しの順番と失敗時の動きが書かれている | — |
| 2.3 | 設計レビュー | 千葉1・森1（佐伯・宮田は同席） | 2 | 2/16 | 設計書の指摘が反映済み。A2（連携APIを呼ぶだけで済む）を確認 | 1 |
| 3.1 | 未連携の会員だけに出す導線 | 千葉 | 9 | 3/1〜3/13 | 連携済みの会員には出ない。ステージングで2.1のデザインと一致 ★ | 1.5 |
| 3.2 | 連携の呼び出しと戻り | 千葉 | 8 | 2/19〜2/28 | 連携完了で戻ると画面が更新される。失敗時は導線を出さず、購入完了画面は壊れない ★ | 1.5 |
| 3.3 | 対照群10%の振り分け（会員ID固定。既存A/Bテスト基盤） | 千葉 | 3 | 2/8〜2/13 | 同じ会員IDは常に同じ群（1/24に森さんが確認した方式）★ | 0.5 |
| 3.4 | 計測イベント（表示・押下・連携完了） | 佐伯（MOps） | 4 | 3/19〜3/23 | 3つのイベントが、群別に集計できる ★ | 0.5 |
| 3.5 | 外すスイッチ（設定1つ） | 千葉 | 2 | 2/14〜2/15 | 設定を切ると全会員で非表示。3.3と同じPRで承認 ★ | （3.3に含む） |
| 3.6 | 単体テスト | 千葉 | 3 | 3/14〜3/16 | 3.1〜3.3・3.5のテストが通る ★ | 0.5 |
| 4.1 | ステージングの結合テスト | 佐伯（MOps） | 6 | 3/26〜4/2 | 購入→完了画面→連携→戻りの一巡が通り、計測に出る ★ | 0.5 |
| 4.2 | 結合の指摘の修正 | 佐伯（MOps） | 4 | 4/3〜4/6 | 指摘が0件。最後のPRは4/5（木）17:00まで ★ | 0.5 |
| 5.1 | 受入テスト | 千葉（宮田が実施） | 6 | 4/9〜4/16 | 受入の基準（PRD）を全部確認。森さんが立会 | 1 |
| 5.2 | 受入の指摘の修正 | 千葉 | 4 | 4/17〜4/20 | 指摘が0件 | — |
| 6.1 | 本番反映 | 千葉 | 1 | 5/7 | 5/7に本番で導線が出る。森さんが4/26（木）に公開前の承認 ★ | 0.5 |
| 6.2 | 公開直後の確認 | 宮田（MOps） | 予算外 | 5/7 | 表示・押下・連携完了の3つが本番で計測に出る | — |
合計: 千葉40・森8・デザイナー4・購入フローチーム（外す作業）0.5＝52.5人日〔導出〕。予算63人日の83%。MOpsの分（佐伯14人日、宮田）は予算外。
3. 100%の確認と重なりの確認
| PRDの目的 | 満たす成果物 | 確認 |
|---|---|---|
| G1 出す（購入完了画面で、未連携の会員に導線を見せる） | 3.1、3.2、2.1 | 抜けなし |
| G2 測る（対照群10%と比べて判定する） | 3.3、3.4、1.2 | 抜けなし。Goodでは抜けていた（対照群3＋計測4＝7人日） |
| G3 外す（未達なら設定1つで外す） | 3.5、1.3 | 抜けなし。Goodでは抜けていた（スイッチ2人日） |
| 範囲外（PRD 3章のN1〜N5: アプリ、連携特典、他の連携導線、多パターンテスト、LINEログイン） | なし | 入れていない |
- 重なりの確認: 4.1（ステージング。MOpsがAPIとの接続を確認）と5.1（受入。受入基準を満たすかを宮田が確認）は、指摘の出どころで分けた（4.2は結合の指摘、5.2は受入の指摘）。3.3と3.5は成果物が別で、PRだけ同じ
4. 線表（週単位。#は作業のある週）
2/5 2/12 2/19 2/26 3/5 3/12 3/19 3/26 4/2 4/9 4/16 4/23 4/30 5/7
2.1 デザイン #### #### .... .... .... .... .... .... .... .... .... .... .... ....
2.2 設計書 #### .... .... .... .... .... .... .... .... .... .... .... .... ....
2.3 設計レビュー .... #### .... .... .... .... .... .... .... .... .... .... .... ....
3.3 対照群10% #### #### .... .... .... .... .... .... .... .... .... .... .... ....
3.5 外すスイッチ .... #### .... .... .... .... .... .... .... .... .... .... .... ....
3.2 連携呼び出し .... .... #### #### .... .... .... .... .... .... .... .... .... ....
3.1 導線の表示 .... .... .... #### #### #### .... .... .... .... .... .... .... ....
3.6 単体テスト .... .... .... .... .... #### .... .... .... .... .... .... .... ....
3.4 計測(佐伯) .... .... .... .... .... .... #### .... .... .... .... .... .... ....
4.1 結合(佐伯) .... .... .... .... .... .... .... #### #### .... .... .... .... ....
4.2 修正(佐伯) .... .... .... .... .... .... .... .... #### .... .... .... .... ....
5.1 受入テスト .... .... .... .... .... .... .... .... .... #### #### .... .... ....
5.2 受入の修正 .... .... .... .... .... .... .... .... .... .... #### .... .... ....
予備4日 .... .... .... .... .... .... .... .... .... .... .... #### .... ....
GW凍結 .... .... .... .... .... .... .... .... .... .... .... #### #### ....
6.1 本番反映 .... .... .... .... .... .... .... .... .... .... .... .... .... #### - 一番長い鎖: 2.1（2/16）→3.2→3.1→3.6（3/16）→4.1→4.2（4/6）→5.1→5.2（4/20）→予備4日（4/26）→6.1（5/7）。すべて頭から順（先行の完了後に次が始まる）〔仮定: 依存はすべて「終わってから始まる」型。ずらして重ねる並行は見込んでいない〕
- 予備4日（4/23〜4/26）は、意図して置いた余裕。使い切ると公開は5/14（11週）に遅れ、判定に要る差は1.6→1.7pt（余裕0.4→0.3pt）〔Day020の表から〕
- 見込みが5/28以降になった時点で開発を止め、中止を秋山さんに諮る（Day020）
5. 森さんの時間（8人日がどの週に当たるか）
| 時期 | 内容 | 人日 |
|---|---|---|
| 2/5〜3/16（6週） | 設計レビュー1（2/16）、千葉さん分のコードレビュー4（3.1、3.2、3.3、3.5、3.6）。最も重い週は3/12の週（3.1のレビュー1.5＋3.6の0.5＝2人日） | 5 |
| 3/19〜4/6（3週） | 佐伯分の読み込み1.5（3.4・4.1・4.2の各0.5）＋承認の枠（案A: 30分×6） | 1.5 |
| 4/9〜4/20（2週） | 受入の立会 | 1 |
| 4/26 | 公開前の承認 | 0.5 |
6. 前提と、外れたときの余裕
| # | 前提 | 外れたときの影響 | 確かめる日・人 |
|---|---|---|---|
| A2 | LINE連携はMOpsの既存連携APIを呼ぶだけで済む（Day020） | +0.5人月（10.5人日）。残り10.5人日でちょうど収まる。ただし余裕は0 | 2/16 設計レビュー・佐伯 |
| 新1 | 凍結（4/27〜5/6）中は、承認済みのものしか5/7に出せない〔仮定〕 | 外れると予備が違う意味になる（凍結中も取り込めるなら、予備は実質増える） | 2/9 確認会・藤田部長 |
| 新2 | 1人月＝21人日〔仮定〕 | 20人日なら予算は60人日になり、52.5人日でも余りは7.5人日。A2が外れると超える | 2/9 確認会・高梨部長 |
7. 数字と出所
| 数字 | 値 | 出所 |
|---|---|---|
| 1人月 | 21人日 | 〔仮定〕 |
| 予算 | 3人月＝63人日（360万円） | 〔導出〕 Day020の3人月から |
| 千葉 | 40人日（2/5〜3/16の29営業日＋4/9〜4/20の10営業日＋5/7の1日） | 〔導出〕。営業日は祝日を除く |
| 3/19〜4/6の営業日 | 14日（3/20は祝日） | 〔導出〕。2029年の祝日は内閣府の暦で未確認（春分の日を3/20、振替休日を2/12・4/30と置いた） |
| 予備 | 4/23〜4/26の4営業日 | 〔導出〕 |
| 森 | 8人日 | 〔仮定〕。Day020の0.3人月（6.3人日）＋0.1人月（2.1人日）＝8.4人日を8に丸めた |
| 合計 | 52.5人日、63人日の83%、残り10.5人日 | 〔導出〕 |
| A2の外れ | +0.5人月＝10.5人日 | 〔導出〕 Day020 |
| 公開5/14のとき | 判定に要る差1.7pt、余裕0.3pt | Day020の表から |
8. まだ決まっていないこと
- 凍結中に取り込めるものの範囲: 藤田部長に2/9の確認会までに確認する
- 3.4の計測イベントの呼び出し方（3.1の画面に何行入るか）: 2/16の設計レビューで確認する
- 1人月の人日換算（21人日）: 高梨部長に2/9に確認する
- 見積りの根拠（各作業パッケージの人日が何で決まったか）: 本資料では置いた値で、千葉さんと2/7までにすり合わせる
English 全文を見る
WBS and Schedule: LINE ID-link prompt on the order-complete page (web) 6 February 2029 (Tue) Miyata, MOps
To: Mr. Mori (Checkout Flow) Cc: Mr. Fujita (Site Development), Mr. Takanashi (Promotion Systems)
1. Decision needed (review on Fri 9 February, 14:00)
Please choose when you approve Saeki's three PRs between 19 March and 6 April (3.4 measurement, 4.1 integration test, 4.2 integration fixes): A, B or C. If we have no reply by 17:00 on Fri 9 February, we put Option A's slots on the calendar (an invitation only; you can decline).
| Option | How you spend time | Wait for Saeki's three PRs | 4-day buffer | Difference in outcome |
|---|---|---|---|---|
| A (recommended) | Six 30-minute slots, Tue and Fri 10:00 (Wed 21 Mar [20 Mar is a holiday], 23 Mar, 27 Mar, 30 Mar, 3 Apr, 6 Apr). Reading the PRs, 1.5 person-days, happens outside the slots | At most 2 working days (a Friday PR waits for Tuesday) | Stays at 4 days | You fit approval into your own calendar. The last PR for 4.2 is due by 17:00 on Thu 5 April |
| B | Within 24 hours of each PR. 1.5 person-days of reading plus three interruptions | Shortest (within 1 working day) | Stays at 4 days | Interruptions tend to stack on 4.2 on 5-6 April |
| C | Move measurement (3.4) to after 9 April. Two approvals; about 1.0 person-day of reading | Short, with two PRs | Drops to zero. The 4 days of measurement sit inside acceptance from 9 April | Lightest for you. Any acceptance finding pushes the release to 14 May |
- You can put the 1 June deferred-payment launch (Payments, fixed by contract) first. Chiba's move to Payments from 19 March to 6 April stands as decided on 1 February
- We are not asking for a Golden Week freeze exception
- Saeki's three weeks of changes are 3.4, 4.1 and 4.2 only, and nothing goes to production before your approval. The change to existing checkout code is a few lines in 3.4 that call the measurement event [assumption: 3.4 hooks measurement into the 3.1 screen; to be confirmed at the 16 Feb design review]
- If undecided: we put Option A's slots on the calendar at 17:00 on 9 February. If you decline, Miyata switches to Option B
2. WBS (work package table)
A star means it needs your approval. One person-month = 21 person-days [assumed]. Owner = name (team).
| ID | Work package (deliverable) | Owner | Days | Period | Done when | Mori (days) |
|---|---|---|---|---|---|---|
| 1.1 | Weekly report (one page; states expected go-live and the gap needed) | Miyata (MOps) | outside budget | Mondays | Sent by the Monday of the following week | n/a |
| 1.2 | 4-week review (4 Jun) and decision pack (3 Aug) | Miyata (MOps) | outside budget | 4 Jun, 3 Aug | One page showing whether about 2,700 extra linked users were reached in 12 weeks | Decides on 4 Jun |
| 1.3 | Removal task (one setting) | Checkout Flow | 0.5 | 10 Aug | Prompt confirmed hidden for all members in production | n/a |
| 2.1 | Prompt design (one version) | Designer (Checkout Flow) | 4 | 5-16 Feb | Copy and design final on 16 Feb, one version | n/a |
| 2.2 | Link-call design doc | Chiba (Checkout Flow) | 3 | 5-7 Feb | One page; call order and failure behaviour stated | n/a |
| 2.3 | Design review | Chiba 1, Mori 1 (Saeki, Miyata attend) | 2 | 16 Feb | Review comments applied; A2 (the existing link API is enough) confirmed | 1 |
| 3.1 | Prompt for unlinked members only | Chiba | 9 | 1-13 Mar | Linked members do not see it. On staging it matches design 2.1 * | 1.5 |
| 3.2 | Link call and return | Chiba | 8 | 19-28 Feb | The screen refreshes after linking. On failure no prompt is shown and the page does not break * | 1.5 |
| 3.3 | 10% holdout split (fixed by member ID; existing A/B platform) | Chiba | 3 | 8-13 Feb | The same member ID always lands in the same group (the method you confirmed on 24 Jan) * | 0.5 |
| 3.4 | Measurement events (shown, clicked, linked) | Saeki (MOps) | 4 | 19-23 Mar | All three events can be counted by group * | 0.5 |
| 3.5 | Off switch (one setting) | Chiba | 2 | 14-15 Feb | Turning it off hides the prompt for all members. Approved in the same PR as 3.3 * | (in 3.3) |
| 3.6 | Unit tests | Chiba | 3 | 14-16 Mar | Tests for 3.1-3.3 and 3.5 pass * | 0.5 |
| 4.1 | Integration test on staging | Saeki (MOps) | 6 | 26 Mar-2 Apr | The full path (order, complete page, link, return) works and shows in measurement * | 0.5 |
| 4.2 | Fixes from integration | Saeki (MOps) | 4 | 3-6 Apr | Zero open findings. Last PR by 17:00 on Thu 5 Apr * | 0.5 |
| 5.1 | Acceptance test | Chiba (Miyata runs it) | 6 | 9-16 Apr | All PRD acceptance criteria checked. Mori observes | 1 |
| 5.2 | Fixes from acceptance | Chiba | 4 | 17-20 Apr | Zero open findings | n/a |
| 6.1 | Deploy | Chiba | 1 | 7 May | The prompt appears in production on 7 May. Mori signs off on Thu 26 Apr * | 0.5 |
| 6.2 | Post-release check | Miyata (MOps) | outside budget | 7 May | Shown, clicked and linked all appear in measurement in production | n/a |
Total: Chiba 40, Mori 8, Designer 4, Checkout Flow (removal task) 0.5 = 52.5 person-days [derived], 83% of the 63 budgeted. MOps's share (Saeki 14 person-days, Miyata) is outside the budget.
3. 100% check and overlap check
| PRD goal | Deliverables that meet it | Check |
|---|---|---|
| G1 Show (prompt for unlinked members on the order-complete page) | 3.1, 3.2, 2.1 | No gap |
| G2 Measure (compare with a 10% holdout) | 3.3, 3.4, 1.2 | No gap. Missing in the Good version (holdout 3 + measurement 4 = 7 person-days) |
| G3 Remove (one setting if the target is missed) | 3.5, 1.3 | No gap. Missing in the Good version (switch, 2 person-days) |
| Out of scope (PRD section 3, N1-N5: app, link perks, other link prompts, multi-variant tests, LINE Login) | None | Not included |
- Overlap check: 4.1 (staging; MOps checks the connection to the API) and 5.1 (acceptance; Miyata checks the acceptance criteria) are separated by where the finding comes from (4.2 fixes integration findings, 5.2 fixes acceptance findings). 3.3 and 3.5 are separate deliverables that share one PR
4. Schedule (weekly; # marks a week with work)
2/5 2/12 2/19 2/26 3/5 3/12 3/19 3/26 4/2 4/9 4/16 4/23 4/30 5/7
2.1 Design #### #### .... .... .... .... .... .... .... .... .... .... .... ....
2.2 Design doc #### .... .... .... .... .... .... .... .... .... .... .... .... ....
2.3 Design review .... #### .... .... .... .... .... .... .... .... .... .... .... ....
3.3 10% holdout #### #### .... .... .... .... .... .... .... .... .... .... .... ....
3.5 Off switch .... #### .... .... .... .... .... .... .... .... .... .... .... ....
3.2 Link call .... .... #### #### .... .... .... .... .... .... .... .... .... ....
3.1 Prompt display.... .... .... #### #### #### .... .... .... .... .... .... .... ....
3.6 Unit tests .... .... .... .... .... #### .... .... .... .... .... .... .... ....
3.4 Measure (Saeki).... .... .... .... .... .... #### .... .... .... .... .... .... ....
4.1 Integr. (Saeki).... .... .... .... .... .... .... #### #### .... .... .... .... ....
4.2 Fixes (Saeki) .... .... .... .... .... .... .... .... #### .... .... .... .... ....
5.1 Acceptance .... .... .... .... .... .... .... .... .... #### #### .... .... ....
5.2 Accept. fixes .... .... .... .... .... .... .... .... .... .... #### .... .... ....
Buffer 4d .... .... .... .... .... .... .... .... .... .... .... #### .... ....
GW freeze .... .... .... .... .... .... .... .... .... .... .... #### #### ....
6.1 Deploy .... .... .... .... .... .... .... .... .... .... .... .... .... #### - Longest chain: 2.1 (16 Feb) -> 3.2 -> 3.1 -> 3.6 (16 Mar) -> 4.1 -> 4.2 (6 Apr) -> 5.1 -> 5.2 (20 Apr) -> 4-day buffer (26 Apr) -> 6.1 (7 May). All finish-to-start [assumption: every dependency is "starts when the previous one ends"; no overlapping]
- The 4-day buffer (23-26 Apr) is deliberate slack in the plan. Use it up and the release slips to 14 May (11 weeks); the required gap rises from 1.6 to 1.7pt (margin 0.4 to 0.3pt) [from the Day020 table]
- If the expected release moves to 28 May or later, we stop development and ask Ms. Akiyama whether to cancel (Day020)
5. Your time (where the 8 person-days fall)
| When | What | Days |
|---|---|---|
| 5 Feb-16 Mar (6 weeks) | Design review 1 (16 Feb); code review of Chiba's work 4 (3.1, 3.2, 3.3, 3.5, 3.6). Heaviest week: 12 Mar (3.1 review 1.5 + 3.6 0.5 = 2 person-days) | 5 |
| 19 Mar-6 Apr (3 weeks) | Reading Saeki's PRs 1.5 (0.5 each for 3.4, 4.1, 4.2) plus the approval slots (Option A: 30 minutes x 6) | 1.5 |
| 9-20 Apr (2 weeks) | Acceptance observation | 1 |
| 26 Apr | Pre-release sign-off | 0.5 |
6. Assumptions, and the margin if they fail
| # | Assumption | Impact if it fails | Date and owner to confirm |
|---|---|---|---|
| A2 | LINE linking only needs a call to MOps's existing link API (Day020) | +0.5 person-month (10.5 person-days). The remaining 10.5 person-days just cover it, with zero margin | 16 Feb design review, Saeki |
| New 1 | During the freeze (27 Apr-6 May), only approved work can go out on 7 May [assumption] | If wrong, the buffer means something else (if merging is allowed during the freeze, the buffer is effectively larger) | 9 Feb review, Mr. Fujita |
| New 2 | One person-month = 21 person-days [assumption] | At 20 days the budget is 60 person-days and the margin after 52.5 is 7.5. If A2 fails, we exceed it | 9 Feb review, Mr. Takanashi |
7. Numbers and their sources
| Number | Value | Source |
|---|---|---|
| One person-month | 21 person-days | [assumed] |
| Budget | 3 person-months = 63 person-days (JPY 3.6M) | [derived] from Day020's 3 person-months |
| Chiba | 40 person-days (29 working days 5 Feb-16 Mar + 10 working days 9-20 Apr + 1 day on 7 May) | [derived]. Working days exclude holidays |
| Working days 19 Mar-6 Apr | 14 (20 Mar is a holiday) | [derived]. The 2029 holiday calendar was not checked against the Cabinet Office's list (vernal equinox set at 20 Mar; substitute holidays at 12 Feb and 30 Apr) |
| Buffer | 4 working days, 23-26 Apr | [derived] |
| Mori | 8 person-days | [assumed]. Day020's 0.3 person-month (6.3 days) + 0.1 (2.1 days) = 8.4, rounded to 8 |
| Total | 52.5 person-days, 83% of 63, 10.5 left | [derived] |
| If A2 fails | +0.5 person-month = 10.5 person-days | [derived] Day020 |
| If released 14 May | Required gap 1.7pt, margin 0.3pt | From the Day020 table |
8. Open questions
- What can be merged during the freeze: we ask Mr. Fujita before the 9 Feb review
- How 3.4 calls the measurement events (how many lines it adds to the 3.1 screen): confirmed at the 16 Feb design review
- Converting a person-month to person-days (21): we ask Mr. Takanashi on 9 Feb
- The basis for each work package's person-days: the values here are placeholders; we align with Chiba by 7 Feb
完成の定義チェックリスト
この文書種別を提出する前に必ず確認する項目。「雑・妥協」を防ぐための外部基準。
今日の演習
15分版（まずこれだけでもやる）
Bad例の「開発（3人月）」の1行を、5つ以上の作業パッケージに分解する。条件: ①名前は成果物の名詞（動詞始まりにしない）。②各項目に人日と担当（名前）を付け、合計が3人月（63人日）を超えないことを1行で確かめる。③PRDの目的が「出す・測る・外す」の3つだとして、3つとも分解の中に対応する項目があるかを確認する。
60分版
読み手を変えて、同じWBSを千葉さん（実行する本人）向けに書き直す。 千葉さんは自分の40人日が何から何へ流れるかを知りたく、3/19〜4/6に自分が抜ける間の引き継ぎが気になる。条件: ①作業パッケージごとに完了の条件を1行で書き、森さんの承認が要る箇所を除いて承認の枠の案は付録に回す。②千葉さんが抜ける3/16と、戻る4/9に、引き継ぎの成果物（何を誰に渡すか）を足す。③3.1（9人日）と3.2（8人日）を、さらに小さく分けるか分けないかを理由つきで決める。④Betterで止めるか、Bestまで書くかを理由つきで決める。
取り組む前のヒント
- 分解の前に、目的を1行ずつ書く。分解した後で、目的ごとに成果物を指で追うと、抜けは見つかる
- 名前に「対応」「作業」「調整」が付いたら、何ができていれば完了かを言えるか試す。言えなければ成果物の名詞に直す
- 担当の列は、決定事項と日付を突き合わせて読む。部署名は名前に置き換える
- 一番長い鎖は、先頭から順に終わりまでたどるだけで見える。そこに載っていない作業は、遅れても全体は遅れない
- 罠: 項目を並べて満足する。100%の対応表を書いて初めてGoodを抜ける
- 罠: 予備を「余裕があるから安心」と読む。どの作業が予備を食うかまで書いて初めてBestになる
実務での使いどころ
WBSは、プロジェクト計画書（PMO#2、Day020）の次に出る。計画書が「何を・なぜ・いつまでに」を書く文書なら、WBSはそれを人と日に割り当てる表。リスク登録簿（#4）は、今日の前提A2（連携APIを呼ぶだけで済む）と凍結の解釈をリスクとして登録する回にでき、ステークホルダーマップ / RACI（#7）は、今日の「森さんが承認する」を責任の表にする回になる。ステータスレポート（#6）は、今日の予備4日の消費を毎週報告する文書で、「公開見込み5/28以降で止める」（Day020）の判定が出る場所になる。
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
迷った他案と採らなかった理由
- 題材を新しい案件にする案 — WBSは計画書の下流の文書なので、Day020の続きにした（PRDの目的、前提A2、凍結、予備、千葉さんの派遣が既にある）。新しい案件だと、これらを置き直すだけで学習の中心から外れる
- 読み手を千葉さん（実行する本人）にする案 — 千葉さんは担当者で、配分を判断する人ではない。他部署の人間が自チームのコードに入る承認を受ける森さんにすると、佐伯の担当、承認の枠、予備への跳ね返りが自然に読み手の関心事になる。千葉さん向けは60分版にした
- WBSと線表を別の文書にする案 — 英語のPM実務ではWBS（範囲）とスケジュール（時間）は別の成果物。ただし森さんが1枚10分で読む前提のため、WBSの表に期間の列を足し、線表は別に添える形にした（日英差分ノート1）
- 作業パッケージを1〜3人日に細かく分ける案 — 完了を数えやすいが、管理の手間が増え、森さんがレビューする数も増える。1〜10人日に絞り、例外（1.3の0.5人日）は理由を書いた（設定1つの切替でも、日付と責任者が独立している）
- 森さんの時間を作業パッケージにする案 — 成果物ではなく関与なので、列にした。WBSの要素を「人の時間」で切ると、100%ルールの検査が崩れる
- 案Aを推奨かつ既定にする案 — Day020・036は推奨と既定が違う回だった。今回は、既定をカレンダーに入れるだけで断れる枠にしたので、推奨と同じでも読み手に負担を押しつけない。推奨と既定が一致することは本文で明記した
- 依存の4つの型（終わってから始まる、開始どうし、終了どうし、開始から終わり）を扱う案 — 実務では重なりを使うが、今日はすべて「終わってから始まる」と置いて前提に書いた。見落としは残りうる
扱わなかった範囲
- 人日の見積りの根拠（三点見積り、類似見積り、プランニングポーカー等）。値は置いたもので、本文の「まだ決まっていないこと」にすり合わせの日を書いた
- 資源の平準化（森さんの週ごとの負荷の調整）、アーンドバリュー管理
- 漸進的詳細化（ローリングウェーブ）、管理勘定（control account）、WBS辞書の全項目（今日は「完了の条件」の列だけ）
- アジャイル（ストーリー分割・バーンダウン）との比較
- 決済チームの6/1後払い決済のWBSと、千葉さんの派遣中の決済チーム側の工数
- 祝日の内閣府の暦の確認（春分の日3/20、振替休日2/12・4/30は一般則からの導出で、2029年の暦は未確認）
世界の実物と比べた扱いの量（実際に数えた）
WBSの中核概念を12個に数えた: ①100%ルール ②相互排他 ③成果物指向 ④作業パッケージの粒度 ⑤WBS辞書 ⑥階層とコード体系 ⑦依存関係とクリティカルパス ⑧見積り ⑨予備 ⑩漸進的詳細化 ⑪責任割当（RAM/RACI） ⑫管理勘定。扱ったのは6（①②③④⑥⑨）、簡易に扱ったのは3（⑤は完了の条件の列だけ、⑦は終わってから始まる型だけ、⑪は担当の列だけ）、扱っていないのは3（⑧⑩⑫）。6/12＝5割、簡易を含めて9/12＝7.5割。
数字と概念の出所
- 会社・人物・日付はすべて架空。再登場: 森さん（Day020）、千葉さん、佐伯、藤田部長、高梨部長、秋山さん。新登場: なし（デザイナーは役割のみ）
- WBSの概念: 2026-10-22 に en.wikipedia.org/wiki/Work_breakdown_structure を取得し、①「範囲の100%を含む」「子要素の合計が親に等しい」 ②「要素の間に範囲の重なりがない」 ③作業パッケージは測れて外注できる単位 ④「80時間」の目安（1つの作業が80時間を超えない）、報告期間より長くしない、「理にかなうなら」の3つのヒューリスティック ⑤WBSはスケジュールの手引きであってスケジュールそのものではない、を確認した。同日の検索では、100%ルール・成果物指向・相互排他・8/80ルールを、PMIの Practice Standard for Work Breakdown Structures を引く二次資料（epm.umd.edu、projectengineer.net、deltek.com など）が述べていることを確認したが、検索結果の要約までで、PMI標準の原文は未読。Wikipediaは「8/80ルール」という名前は使っていない
- float と schedule reserve（buffer）の区別、critical path の定義は記憶による（原文未確認）
- 〔仮定〕（本文内で置いた値）: 1人月＝21人日、森さんの8人日（Day020の0.3＋0.1人月からの丸め）、各作業パッケージの人日、凍結の解釈、依存の型。Day020から引いた: 3人月360万円、判定8/3、外す8/10、GW凍結、予備4/23〜4/26、5/14のときの1.7pt・余裕0.3pt、前提A2、案C、2/16の設計レビュー
- 〔導出〕は作成時に Python で計算した: 営業日（2/5〜3/16＝29日、3/19〜4/6＝14日、4/9〜4/20＝10日、4/23〜4/26＝4日）、各作業パッケージの開始・終了日（千葉の29日を2.2→3.3→3.5→2.3→3.2→3.1→3.6の順に割り当て）、合計52.5人日・83%・残り10.5人日、24日＝192時間＝80時間の2.4倍、9人日＝63人日の14%。曜日（2/6は火、金は2/9、3/16、4/6、4/20、4/27、8/3、8/10、月は3/19、5/7、6/4、3/21は水、木は4/5と4/26）は作成時に確認した
- 分量（行数・字数）は、各コードブロックを作成後にスクリプトで数えた実測値
何が起きているか:
これは怠慢ではなく、「WBSは見出しを並べれば形になる」という通念から生まれる形である。見出しと、分解は別の作業である。