今日の文書 — プロジェクト計画書
プロジェクト計画書（Project Management Plan） — 決まった目的とスコープ（今回はPRDで合意済み）を、誰が・いつまでに・どの人員と予算で届けるかを書き、承認者から人と時間を預かるための文書。PRDが「何を作るか」なら、計画書は「それをどう届けるか、何が崩れたら届かないか」。
この文書の勝負どころ: 前提条件と制約が明記されているか。 PMBOK の定義では、前提（assumption）は「計画のために、証明なしに真・確実とみなしている要因」、制約（constraint）は「プロジェクトの実行を制限する要因」（出典は設計メモ）。この区別が計画書で効くのは、扱い方が逆だから:
| 前提（assumption） | 制約（constraint） | |
|---|---|---|
| 正体 | 本当かどうかまだ分からないが、本当だとして計画を組んだもの | 本当だと分かっていて、動かせない（動かすには誰かの決裁が要る）もの |
| 計画書に書くこと | 確かめる日・確かめる人・外れたときの影響 | 誰が決めたか・変えられるか・変えられるなら誰が |
| 書かないと何が起きるか | 外れてから気づく。承認者は「聞いていない」 | 動かせるものを動かせないと思い込む（または逆） |
| 今日の例 | 千葉さんが2/5〜4/20に専任でいられる | 判定日8/3（経営会議が決めた。延長しない） |
よくある失敗は、前提の欄に「関係部署の協力が得られること」と書くこと。これは確かめようがなく、外れたら他人のせいにできる——前提ではなく、名前のない依頼である。
シナリオ
あなたは株式会社ノヴァストア EC事業本部・販促システム部の MOpsチームマネージャー・宮田（Day004〜Day019の続き）。
2029年1月24日の確認会で、購入完了画面のLINE ID連携導線のPRD（Day019）は案C（おすすめ商品の上に置き、4週で見直す）で合意した。作るのはサイト開発部の購入フローチーム（リード: 森さん）、2/5着手・5/7公開・3人月（360万円、中期計画で承認済み）、8/3に判定、未達なら8/10に外す。
人員の配置を決めるのは森さんではなく、サイト開発部長の藤田さん（新登場）。サイト開発部は毎月初めの案件会議で部の人員配置を決めるので、宮田はプロジェクト計画書を 2029/1/29（月） に藤田部長へ送り、2/1（木）10:00 の案件会議で承認を得たい。
ところが1/26（金）に、状況が1つ変わった。
- 同じサイト開発部の決済チームが、後払い決済の追加（6/1公開。決済代行会社との契約で日付が固定）の結合テストに、千葉さんを3/19〜4/6の3週間、全日借りたいと藤田部長に申し入れた。千葉さんは以前、決済画面を作った本人で、LINE導線の主担当（2/5〜4/20専任の予定）
- 千葉さんが3週抜けると、開発の終わりがGWのリリース凍結（4/27〜5/6。サイト開発部のルール）にかかり、受入が凍結明けにずれて公開は5/21（2週遅れ）になる
- 判定日8/3は動かない（中期計画で経営会議が決め、「延長しない」とDay018で決めた）。公開が遅れると、そのぶん測れる期間が減る
- 読み手: 藤田部長（他部署の部長＝Lv2）。カタログの主な読み手は「実行チーム・承認者」で、承認者がそのまま他部署の部長なので、ルール5（間接読み手）は使わない
読み手プロファイル
| 項目 | 内容 |
|---|---|
| 誰が読むか | 藤田部長（サイト開発部長）。2/1の案件会議で、森さんと決済チームのリードも同席する |
| 何を判断するために読むか | ①自部署の人（主に千葉さん）を、2/5〜4/20この案件に預けてよいか ②決済チームの申し入れとどちらを優先するか ③この計画が崩れたとき、自部署に何が返ってくるか |
| 何を知っているか | 自部署の案件と人の割り振り。GW凍結のルール（自分で決めた）。後払い決済の6/1が契約で動かないこと |
| 何を知らないか | 中期計画でこの導線が決まった経緯。8/3の判定と、公開が遅れると何が起きるか。MOps側が出せる人（佐伯さん）がいること |
| 何を気にしているか | 6/1の後払い決済を落とさないこと（部の最優先）。他部署の案件に人を取られて、自部署の案件が遅れること。GW凍結の例外を求められること。計画が崩れたとき「サイト開発部が遅れたせい」にされること |
| 読む時間と場面 | 案件会議の前に5分。案件会議では1件10分で決める。細部は森さんに任せる |
この読み手が変わると何が変わるか: 読み手が 森さん（実行チームのリード） なら、前提の確かめ方と週ごとの作業の割り振りが先に来て、判定の話は短くてよい（PRDで共有済み）。経営企画の秋山さん なら、人員の話はほぼ要らず、「公開が遅れたら8/3の判定がどう変わるか」と中止の条件だけでよい。高梨部長（自部署の上司） なら、MOpsから佐伯さんを3週出すことの了承が中心になる。今回は人を配置する他部署の部長が読むので、自部署の負担と、決済チームの申し入れとの比較を先に置く。
4段階で見る — 「4. 前提条件と制約」
同じプロジェクト計画書の 「4. 前提条件と制約」 を4段階で書き分けたもの。計画書で最も差が出るのは、日程表や体制図ではなく、何が崩れたらこの計画が届かないかを書くこの部分。タブで精読、「横に並べる」で差を一望できる。
行数でも字数でもBestが最短（Best 619字＜Better 650字）。前提3つ・制約3つを「決める1点（A1）」に縮め、表は全文の4章へ移したため。
前提が「協力が得られること」など確かめようのない文。
揺れている前提（千葉さんの3週）に触れず、
「5/7厳守」「リスク: 特になし」。前提A1〜A4と制約C1〜C4を正しく分けて並べた。
ただし、どれが外れそうか・外れたら何日遅れるか・
いつ誰が確かめるかがない。5/7と8/3が同じ重さ。A1に★既に揺れている（公開5/21）。影響と確かめる日つき。
制約に決めた人と動かせるか。5/7は制約から外した。
遅れても8/3は動かず、要る差が1.6→1.9→2.1pt。冒頭は「千葉さんを出すか」の1点。A/B/Cを
「判定の余裕」と「サイト開発部の負担」で比較、推奨C。
6/1と凍結の例外は求めない。5/28見込みで止める。既定は案B。"Cooperation will be obtained",
"resources will be secured": no owner, no date.
"Risks: None at this time."Assumptions and constraints correctly split.
No impact, no "validated by", no "set by".
7 May and 3 Aug look equally fixed.A1 marked AT RISK with impact (go-live 21 May).
Constraints show "set by -> can it move?".
Slip vs fixed 3 Aug: gap needed 1.6 -> 1.9 -> 2.1pt."Decision requested": Chiba A/B/C with margin
and cost to Site Development. "We are not asking you to..."
Stop point 28 May; default Option B at noon on 2 Feb.4. 前提条件・制約
【前提条件】
・関係部署の協力が得られること
・仕様変更が発生しないこと
・必要な要員が確保されていること
・LINE側の仕様に変更がないこと
【制約】
・5/7リリース厳守（中期経営計画の施策のため）
・予算内で実施すること
・品質を落とさないこと
【リスク】
・特になし（発生時は都度協議）4. Assumptions and Constraints
Assumptions
- Cooperation from relevant departments will be obtained
- No specification changes will occur
- Necessary resources will be secured
- No changes to LINE specifications
Constraints
- 7 May release is mandatory (mid-term plan initiative)
- Must be completed within budget
- Quality must not be compromised
Risks
- None at this time (to be discussed as they arise)英文の計画書で "Cooperation ... will be obtained" や "Necessary resources will be secured" を前提に書くと、誰も持ち主のいないリスクとして読まれる。"Risks: None at this time" は、英語圏のPMOやスポンサーにはリスクを洗い出していない合図と受け取られる。
4. 前提条件と制約
4.1 前提条件
A1 購入フローチームのエンジニア1名（千葉）が2/5〜4/20に専任で開発・受入を行う
A2 LINE連携はMOpsの既存連携API（カート放棄リマインドで使用中）を呼び出して実現する
A3 対照群の振り分けは既存のA/Bテスト基盤で会員ID固定にできる
A4 導線の文言・デザインは2/16までに1案で確定する
4.2 制約
C1 予算: 3人月（360万円、中期経営計画で承認済み）
C2 公開日: 2029/5/7
C3 GWのリリース凍結期間（4/27〜5/6）は本番反映できない
C4 判定日: 2029/8/3（中期経営計画で決定）
4.3 前提が成立しない場合は、リスク管理表で管理するBadから何が変わったか:
- ③事実と解釈の分離が動いた。前提（本当だと仮に置いたこと）と制約（動かせないこと）が正しく分かれ、どちらも具体的な名詞と日付になった。「協力が得られること」のような確かめようのない文が消えた
- ②読み手適合が動いた。人の名前（千葉）と期間が出たので、藤田部長は自部署の誰の話かが分かる
- ⑤想定反論が少し動いた。GW凍結（C3）が書かれ、「凍結期間に出すつもりか」という疑問に答えている
- 多くの計画書はこの水準で承認される。 PMBOKの型としても正しい
まだ足りないもの（ここが今日の本題）:
- どの前提が外れそうかが分からない。 A1〜A4が同じ重さで並ぶ。実際にはA1は1/26に既に揺れている。藤田部長は、自分が今日決めることがこの表の中にあると気づけない
- 外れたら何が起きるかがない。 「A1が外れたら公開が2週遅れる」が書かれていないので、決済チームへ千葉さんを出すことの代償が見えない
- 確かめる日と人がない。 A2は2/16の設計レビューで分かる、A3は1/24に既に確かめた。確かめ終えた前提が前提のまま残っている
- 制約に「誰が決めたか・動かせるか」がない。 C2（5/7）とC4（8/3）が同じ形で並ぶが、C2はこの計画の都合で置いた日、C4は経営会議の決定で重さが違う。C3は藤田部長自身のルールで、例外を出せるのは読み手本人
- 前提と制約がぶつかる場所が書かれていない。 公開が遅れても判定日は動かない。遅れた分だけ測る期間が減り、判定に届きにくくなる。これがこの計画で一番大事な関係なのに、どこにもない
- 「リスク管理表で管理する」は、この表を読む人に判断を返さない宣言になっている
4. Assumptions and Constraints
4.1 Assumptions
A1 One Checkout Flow engineer (Chiba) is dedicated from 5 Feb to 20 Apr (build and UAT)
A2 The LINE link uses MOps's existing link API (already used for cart reminders)
A3 The holdout can be assigned by member ID on the existing A/B testing platform
A4 Prompt copy and design are fixed (one version) by 16 Feb
4.2 Constraints
C1 Budget: 3 person-months (JPY 3.6M, approved in the mid-term plan)
C2 Go-live: 7 May 2029
C3 No production releases during the Golden Week freeze (27 Apr-6 May)
C4 Decision date: 3 Aug 2029 (set by the mid-term plan)
4.3 Assumptions that fail will be tracked in the risk registerAssumptions / Constraints の型は正しい。ただし英語圏のスポンサーが必ず聞く "Which of these is at risk, and what happens if it fails?" と "Who set this constraint, and can it move?" に答えていない。
4. 前提条件と制約（サイト開発部 藤田部長へ）
前提（本当だとして組んだもの。外れたときの影響 ／ 確かめる日）
A1 千葉さんが2/5〜4/20に専任 ★既に揺れている（1/26 決済チームから3/19〜4/6の借用依頼）
3週抜けると開発の終わりがGW凍結にかかり、公開は5/21（2週遅れ） ／ 2/1の案件会議
A2 LINE連携はMOpsの既存APIを呼ぶだけで済む — 外れたら+0.5人月 ／ 2/16 設計レビュー（佐伯）
A3 文言・デザインが2/16に1案で決まる — 1週遅れるごとに公開も1週遅れる ／ 2/16（MOps）
確かめ終えて外したもの: 振り分けを会員ID固定にできる（1/24 森さんが確認）
制約（動かせないもの。決めた人 → 動かせるか）
C1 判定日8/3・延長しない — 経営会議（2028/9 中期計画） → この計画では動かさない
C2 予算3人月（360万円） — 同上 → 超えるなら高梨部長から再申請
C3 GW凍結4/27〜5/6 — サイト開発部のルール → 例外を出せるのは藤田部長。今回は求めない
（5/7公開は制約ではない。12週を測るためにこちらで置いた日）
前提と制約がぶつかる所: 公開が遅れても判定日（C1）は動かず、測る期間が減る
公開5/7→12週・判定に要る差1.6pt ／ 5/21→10週・1.9pt ／ 5/28→9週・2.1pt（見込み2.0ptを超える）Goodから何が変わったか（★ここが今日の学習の中心）:
読み手プロファイルの各項目に、変更を1対1で対応させている。
| 読み手プロファイルの項目 | Betterで行った変更 |
|---|---|
| 藤田部長が判断すること「千葉さんを預けてよいか」「決済チームとどちらを優先するか」 | A1に★「既に揺れている」をつけ、1/26の申し入れと、3週抜けたときの影響（公開5/21）を同じ行に書いた。確かめる日を「2/1の案件会議」にした＝この会議そのものが前提を確かめる場だと示した |
| 藤田部長が知らないこと「公開が遅れると何が起きるか」 | 最後の2行で、前提（公開日）と制約（判定日）がぶつかる所を数字で出した。公開が1週遅れるごとに、判定に要る差が上がる。5/28まで遅れると、作っても判定に届かない見込みになる |
| 藤田部長が気にすること「GW凍結の例外を求められないか」 | C3に「例外を出せるのは藤田部長。今回は求めない」と書いた。読み手自身が持つ制約を、読み手が動かせると認めたうえで、動かさないと先に言った |
| 藤田部長が気にすること「崩れたときサイト開発部のせいにされないか」 | 各前提に確かめる人を書いた。A2・A3はMOps（佐伯・MOps）が確かめる。崩れたときに誰の前提だったかが、最初から分かる |
| Goodの「5/7」と「8/3」が同じ重さで並んでいた | 制約ごとに決めた人と動かせるかをつけ、5/7は制約から外した（「12週を測るためにこちらで置いた日」）。動かせない日は8/3だけだと分かる |
| 確かめ終えた前提が残っていた | GoodのA3（振り分け）を「確かめ終えて外したもの」に移した。前提の表はまだ分からないものだけにする |
前提は「外れたら何が起きるか」を書いて初めて読み手の役に立つ: 前提をいくら正確に並べても、外れたときの影響がなければ、読み手にはどれを守ればいいかが分からない。影響を日数と人月で書くと、前提は「守ってほしいことの優先順位」に変わる。
それでも残っている問題（Bestで扱う）:
- A1が揺れていると知らせただけで、どうするかを藤田部長に選べる形で出していない。 「千葉さんを出す／出さない」の2択では、出さない場合の決済チームの困りごとが見えない
- MOpsが出せる人（佐伯さん）がいることを、藤田部長は知らない。第3の案があるのに、表に出ていない
- 「作る意味がなくなる日」で何をするかがない。 5/28まで遅れる見込みになったとき、作り続けるのか止めるのか
- 決まらなかったときの動きがない。 2/1に決まらないと、2/5の着手が宙に浮く
ここで動いた軸: ③事実と解釈の分離（揺れている前提と確かめ終えた前提の区別、制約の出どころ）、②読み手適合（読み手自身の制約の扱い）、⑤想定反論（「凍結の例外を求めるのか」への先回り）。
4. Assumptions and Constraints (for Mr. Fujita, Site Development)
Assumptions (impact if wrong / validated by)
A1 Chiba is dedicated 5 Feb-20 Apr. AT RISK: on 26 Jan the Payments team asked for him 19 Mar-6 Apr
Losing 3 weeks pushes build into the Golden Week freeze; go-live moves to 21 May / 1 Feb meeting
A2 The LINE link only calls MOps's existing API. If not: +0.5 person-months / 16 Feb design review (Saeki)
A3 Copy and design are fixed by 16 Feb. Each week late moves go-live a week / 16 Feb (MOps)
Validated and removed: member-ID holdout assignment works (confirmed by Mr. Mori, 24 Jan)
Constraints (set by -> can it move?)
C1 Decision on 3 Aug, no extension - Executive Committee (mid-term plan, Sep 2028) -> fixed for this plan
C2 Budget 3 person-months (JPY 3.6M) - same -> any overrun needs re-approval via Mr. Takanashi
C3 Golden Week freeze 27 Apr-6 May - Site Development rule -> only you can grant an exception; we are not asking for one
(7 May is not a constraint: we chose it to get 12 weeks of data)
Where they collide: if go-live slips, 3 Aug does not, so we measure for fewer weeks
7 May -> 12 weeks, needs a 1.6pt gap / 21 May -> 10 weeks, 1.9pt / 28 May -> 9 weeks, 2.1pt (above our 2.0pt estimate)"AT RISK" を前提の行に直接つけるのは、英文のステータス報告・計画書でよく使う型（RAGのAmber/Redに近い）。"we are not asking for one" は、頼んでいないことを明言する英文の定型で、読み手の警戒を先に解く。"Validated and removed" で、確かめ終えた前提を表から外したことを見せている。
2/1（木）の案件会議で、藤田部長に決めていただきたいこと（1点）
千葉さんを、決済チームの結合テスト（3/19〜4/6）に出すか（推奨: C）
案 千葉さん LINE導線の公開 8/3の判定に要る差（見込み+2.0pt） サイト開発部の負担
A 出さない 5/7（12週） 1.6pt。余裕0.4pt 決済の結合テストを外部に頼む 約90万円〔仮定〕
B 出す 5/21（10週） 1.9pt。余裕0.1pt、ほぼ五分 なし
C 出す。穴はMOpsの佐伯が埋める 5/7、遅れて5/14 1.6〜1.7pt 森さんのレビュー+0.1人月。佐伯の変更は森さんが承認
6/1の後払い決済（契約で固定）を優先していただいて構いません。決済チームの依頼を断ることは求めません
GW凍結（4/27〜5/6）の例外も求めません
作る意味がなくなる日: 公開が5/28（9週）以降になる見込みが立った時点で開発を止め、中止を経営企画の秋山さんに諮る
決まらなかったら: 2/2（金）12:00 に案Bで進め、余裕が0.1ptになることを宮田が秋山さんへ報告するBetterから何が変わったか:
- ①結論の位置が動いた。冒頭を「藤田部長に決めていただきたいこと（1点）」にした。前提の表（Better）は全文の4章へ移し、揺れている前提A1だけを、決める形にして先頭に出した
- ②読み手適合が動いた。表の列に「サイト開発部の負担」を入れた。藤田部長の判断基準は「LINE導線が間に合うか」ではなく「自部署が何を負うか」。案Aの約90万円も、案Cのレビュー負荷も、自分から書いた
- ④次の行動が動いた。作る意味がなくなる日（公開5/28以降の見込みで止めて秋山さんに諮る）と、決まらなかったときの既定（2/2 12:00に案B）を置いた
- ⑤想定反論が動いた。「6/1を犠牲にしろと言うのか」「凍結の例外を求めるのか」の2つに、求めないと先に書いて潰した。そのうえで既定を、MOpsに不利な案Bにした。決まらないとき、相手の部の最優先を守る側に倒す
- 第3の案（C）を足した。 「出す／出さない」の2択は、どちらかの部が損をする。MOpsが人を出して穴を埋める案は、藤田部長が知らなかった選択肢で、宮田にしか出せない
Bestの方が短い理由（実測 Bad12・Good12・Better14・Best10行。字数でもBest619字＜Better650字で、Day018・019と違い行数と字数の両方でBestが最短）: Betterの前提3つと制約3つは、Bestでは決める1点（A1）に縮み、残りは全文の4章へ移した。藤田部長が会議で決めるのは千葉さんの使い方であって、前提の一覧を読むことではない。代わりに、案Cと、負担の列と、止める日を足した。
今回はBestまで作るべきか: Best必要。揺れている前提の持ち主が、読み手本人（人の配置を決める藤田部長）だから。前提を知らせるだけ（Better）では、藤田部長は会議の10分で決済チームの申し入れと比べられない。ただし、1/26の申し入れがなく、どの前提も揺れていなければBetterで十分。そのときの計画書は承認を得るための文書で、決めてもらうことがない。Bestの「決めていただきたいこと」を無理に作るのは過剰品質。
Decision requested at the 1 Feb (Thu) planning meeting (1)
Should Chiba join the Payments integration test (19 Mar-6 Apr)? We recommend C
Opt Chiba LINE prompt go-live Gap needed on 3 Aug (est. +2.0pt) Cost to Site Development
A Stays on this project 7 May (12 wks) 1.6pt; 0.4pt margin Payments test outsourced, about JPY 0.9M [assumed]
B Joins Payments 21 May (10 wks) 1.9pt; 0.1pt margin, a coin flip None
C Joins Payments; MOps's Saeki covers 7 May, or 14 May if late 1.6-1.7pt +0.1 person-month review for Mr. Mori; he approves Saeki's changes
We are not asking you to put the 1 June deferred-payment launch (fixed by contract) at risk.
We are not asking for a Golden Week freeze exception.
Stop point: if go-live is forecast for 28 May (9 wks) or later, we stop the build and ask Ms. Akiyama (Corporate Planning) to cancel.
If undecided: we proceed on Option B at noon on 2 Feb, and Miyata tells Ms. Akiyama the margin is down to 0.1pt."We are not asking you to ..." を2回続けるのは、他部署の上位者に対して要求の上限を先に区切る英文の型。"a coin flip" はやや口語だが、"approximately 50% likelihood" より短く、確率の感覚が正確に伝わる（社外向けなら "roughly even odds" に）。"Stop point" で、作る意味がなくなる条件を先に約束している。
日英差分ノート
1. 「〜が得られること」は、日本語では依頼、英語では持ち主のいないリスク
日本語の計画書の「関係部署の協力が得られること」は、丁寧な依頼の言い換えとして読まれ、誰も気に留めない。英語の "Cooperation from relevant departments will be obtained" は、英語圏のスポンサーには "owned by whom? validated when?" の答えがない前提として読まれ、計画の弱さの証拠になる。英語版では前提の各行に impact / validated by をつけ、依頼は前提ではなく "We need X from Y by date" と依頼として書く。日本語版でも同じ書き分けの方が強い。
2. 「厳守」と "fixed"：強さより、出どころ
「5/7リリース厳守」は日本語では強い決意の表明で、出どころを問われにくい。英語の計画書では "fixed" / "hard constraint" と書くと、ほぼ必ず "Set by whom?" と聞かれる。英語版では制約ごとに set by -> can it move? を書く。今回それを書いたら、5/7は制約ですらなかった（こちらで置いた日）ことが分かった。出どころを書く作業そのものが、制約の誤分類を見つける。
3. 求めないことを言うかどうか
日本語では「6/1を優先していただいて構いません」と書かなくても、相手は察してくれることが多い。ただし察しに任せると、他部署の部長は最悪の要求（6/1を遅らせろ）を想定して身構える。英語では "We are not asking you to ..." と明言するのが定型で、要求の上限を区切る。日本語でも、他部署の上位者には書いた方が会議が短くなる（Lv2の読み手は前提を共有していないので、察しの土台がない）。
頻出表現
| 日本語 | English | トーンの強さ |
|---|---|---|
| 前提（本当だとして組んだもの） | assumption | 中立。impact と validated by をつける |
| 既に揺れている | at risk | 強い。理由と日付を同じ行に |
| 確かめ終えて外した | validated and removed | 中立 |
| 制約（動かせないもの） | constraint / fixed | 強い。set by を添える |
| 決めた人・動かせるか | set by -> can it move? | 中立 |
| 〜は求めません | we are not asking you to ... | 中立。相手の警戒を解く |
| 作る意味がなくなる日 | stop point / kill criterion | 強い。条件を数字で |
| 決まらなかったら | if undecided, we proceed on ... | 中立。既定を置く |
| ほぼ五分 | a coin flip / roughly even odds | 口語 / 中立 |
| 協力が得られること | cooperation will be obtained | 弱い・危険。英文では書かない |
差分5軸まとめ
| 軸 | Bad | Good | Better | Best |
|---|---|---|---|---|
| ① 結論の位置 | 欄を埋めただけ | 前提→制約の順に並ぶ | 揺れている前提に★、ぶつかる所を最後に | 冒頭が「決めていただきたい1点」と推奨 |
| ② 読み手適合 | 書き手の事情だけ（「厳守」） | 人の名前と期間が出た | 読み手自身の制約（GW凍結）を、動かせると認めて動かさないと言った | 表の列が「サイト開発部の負担」 |
| ③ 事実と解釈の分離 | 確かめようのない「〜こと」 | 前提と制約を正しく分けた | 影響・確かめる日・決めた人を書き、5/7を制約から外した | 見込み2.0ptに対する余裕（0.4／0.1pt）を案ごとに出した |
| ④ 次の行動 | 「都度協議」 | 「リスク管理表で管理」 | 確かめる日と人（2/1・2/16） | 止める日（5/28見込みで中止を諮る）と、2/2 12:00の既定 |
| ⑤ 想定反論 | 「リスク: 特になし」 | GW凍結を書いた | 「凍結の例外を求めるのか」に先回り | 「6/1を犠牲にするのか」に、求めないと明言。既定をMOpsに不利な案Bにした |
Best版・全文
日本語版 全文を見る
プロジェクト計画書: 購入完了画面のLINE ID連携導線（Web） 2029年1月29日 MOps 宮田 宛先: 藤田部長（サイト開発部） 写し: 森さん（購入フローチーム）、高梨部長（販促システム部）
1. 2/1（木）10:00の案件会議で、藤田部長に決めていただきたいこと（1点）
千葉さんを、決済チームの結合テスト（3/19〜4/6）に出すか（推奨: C）
| 案 | 千葉さん | LINE導線の公開 | 8/3の判定に要る差（見込み+2.0pt） | サイト開発部の負担 |
|---|---|---|---|---|
| A | 出さない | 5/7（12週） | 1.6pt。余裕0.4pt | 決済の結合テストを外部に頼む 約90万円〔仮定〕 |
| B | 出す | 5/21（10週） | 1.9pt。余裕0.1pt、ほぼ五分 | なし |
| C（推奨） | 出す。3週の穴はMOpsの佐伯が埋める | 5/7。立ち上がりが遅れれば5/14（11週） | 1.6〜1.7pt | 森さんのレビュー+0.1人月。佐伯の変更はすべて森さんが承認してから入れる |
- 6/1の後払い決済（決済代行会社との契約で固定）を優先していただいて構いません。決済チームの依頼を断ることは求めません
- GW凍結（4/27〜5/6）の例外も求めません
- 案Cで佐伯が抜ける3週分のMOpsの作業（LINE一斉配信の配信枠の改修）は5月へ送る。高梨部長の了承済み
- 決まらなかったら: 2/2（金）12:00 に案Bで進め、判定の余裕が0.1ptになることを宮田が経営企画の秋山さんへ報告する
2. 目的と成功の基準（PRD 1/19版の要約）
- 中期計画（2028/9 経営会議）で、FY2029末にLINEのID連携率を37.5%→42%にすると決めた。その打ち手のひとつが、購入完了画面の連携導線
- 2029/8/3（金）に、導線を見せた人と見せない10%の対照群の差で判定する。判定の基準は「12週で約2,700人の追加連携」（中期計画の+1.1ptを人数に直したもの）。12週・表示約17.1万人なら、差+1.6ptにあたる
- 未達なら8/10（金）までに、設定1つで外す（PRDのG3）
3. 範囲
PRD（1/24合意）のとおり。Webの購入完了画面のみ。アプリ・連携特典・他の連携導線・多パターンテスト・LINEログインはやらない（PRD 3章のN1〜N5）。
4. 前提条件と制約
前提（本当だとして組んだもの）
| # | 前提 | 外れたときの影響 | 確かめる日・人 |
|---|---|---|---|
| A1 | 千葉さんが2/5〜4/20に専任 | 既に揺れている（1/26 決済チームから3/19〜4/6の借用依頼）。3週抜けると開発の終わりがGW凍結にかかり、公開5/21 | 2/1 案件会議・藤田部長 |
| A2 | LINE連携はMOpsの既存連携APIを呼ぶだけで済む | +0.5人月。予算（C2）を超えるので再申請 | 2/16 設計レビュー・佐伯 |
| A3 | 文言・デザインが2/16に1案で決まる | 1週遅れるごとに公開も1週遅れる | 2/16・MOps（宮田） |
確かめ終えて前提から外したもの: 対照群の振り分けを既存のA/Bテスト基盤で会員ID固定にできる（1/24 森さんが確認）。
制約（動かせないもの）
| # | 制約 | 決めた人 | 動かせるか |
|---|---|---|---|
| C1 | 判定日8/3、延長しない | 経営会議（2028/9 中期計画） | この計画では動かさない |
| C2 | 予算3人月（360万円） | 同上 | 超えるなら高梨部長から再申請 |
| C3 | GWのリリース凍結 4/27〜5/6 | サイト開発部のルール | 例外を出せるのは藤田部長。今回は求めない |
5/7公開は制約ではない。12週を測るためにこちらで置いた日。
前提と制約がぶつかる所: 公開が遅れても判定日（C1）は動かず、測る期間が減る。
| 公開 | 測れる週数 | 表示人数（見込み） | 判定に要る差 | 見込み+2.0ptとの比較 |
|---|---|---|---|---|
| 5/7 | 12週 | 約17.1万人 | 1.6pt | 余裕0.4pt |
| 5/14 | 11週 | 約15.7万人 | 1.7pt | 余裕0.3pt |
| 5/21 | 10週 | 約14.3万人 | 1.9pt | 余裕0.1pt |
| 5/28 | 9週 | 約12.8万人 | 2.1pt | 見込みを超える。作っても届かない見込み |
5. 体制と工数（3人月）
| 人 | 役割 | 期間 | 工数 |
|---|---|---|---|
| 千葉（購入フロー） | 開発・受入の主担当 | 2/5〜4/20 | 2.5人月 |
| 森（購入フロー リード） | 設計・コードレビュー | 2/5〜4/20 | 0.3人月 |
| デザイナー（購入フロー） | 導線のデザイン（1案） | 2/5〜2/16 | 0.2人月 |
| 佐伯（MOps） | 連携APIの説明、案Cなら3/19〜4/6に開発の穴埋め | 2/16、3/19〜4/6 | MOps負担（予算外） |
| 宮田（MOps） | 計画・週次報告・判定 | 全期間 | MOps負担（予算外） |
6. 日程
| 日付 | 内容 | 担当 |
|---|---|---|
| 2/1（木） | 案件会議で千葉さんの配置を決定 | 藤田部長 |
| 2/5（月） | 開発着手 | 千葉 |
| 2/16（金） | 設計レビュー（A2）、文言・デザイン確定（A3） | 佐伯・宮田・森 |
| 4/9（月）〜4/20（金） | 受入 | 千葉・宮田 |
| 4/23（月）〜4/26（木） | 予備 | — |
| 4/27（金）〜5/6（日） | GW凍結（本番反映なし） | — |
| 5/7（月） | 公開 | 千葉 |
| 6/4（月） | 4週の見直し（おすすめ商品のクリック率） | 宮田が報告、森さんが判断 |
| 8/3（金） | 判定 | 宮田 |
| 8/10（金） | 未達なら外す | 購入フローチーム |
7. 報告と止め方
- 毎週月曜、宮田が藤田部長・森さん・高梨部長へ1枚で報告する（公開見込み日と、判定に要る差を毎回書く）
- 公開の見込みが5/28以降になった時点で開発を止め、中止を秋山さんに諮る。期間を延ばして判定日を動かすことは求めない
- 前提が外れたら、その週の報告の先頭に書く
English 全文を見る
Project Plan: LINE ID-link prompt on the order-complete page (web) 29 January 2029 Miyata, MOps To: Mr. Fujita (Site Development) Cc: Mr. Mori (Checkout Flow), Mr. Takanashi (Promotion Systems)
1. Decision requested at the 1 Feb (Thu) 10:00 planning meeting (1)
Should Chiba join the Payments team's integration test (19 Mar-6 Apr)? We recommend C.
| Option | Chiba | LINE prompt go-live | Gap needed on 3 Aug (est. +2.0pt) | Cost to Site Development |
|---|---|---|---|---|
| A | Stays on this project | 7 May (12 weeks) | 1.6pt; 0.4pt margin | Payments test outsourced, about JPY 0.9M [assumed] |
| B | Joins Payments | 21 May (10 weeks) | 1.9pt; 0.1pt margin, a coin flip | None |
| C (recommended) | Joins Payments; MOps's Saeki covers the 3 weeks | 7 May; 14 May (11 weeks) if ramp-up is slow | 1.6-1.7pt | +0.1 person-month review for Mr. Mori; every change by Saeki is approved by Mr. Mori first |
- We are not asking you to put the 1 June deferred-payment launch (fixed by contract) at risk, or to turn down the Payments team
- We are not asking for a Golden Week freeze exception
- Under Option C, Saeki's 3 weeks of MOps work (broadcast capacity changes) moves to May. Mr. Takanashi has agreed
- If undecided: we proceed on Option B at noon on 2 Feb (Fri), and Miyata tells Ms. Akiyama (Corporate Planning) the margin is down to 0.1pt
2. Goal and success criteria (summary of the 19 Jan PRD)
- The mid-term plan (Executive Committee, Sep 2028) raises the LINE ID-link rate from 37.5% to 42% by end FY2029. This prompt is one of the levers
- On 3 Aug 2029 (Fri) we compare users shown the prompt with a 10% holdout. The rule is about 2,700 extra linked users in 12 weeks (the plan's +1.1pt in people). With about 171,000 users shown in 12 weeks, that is a +1.6pt gap
- If missed, the prompt is removed by 10 Aug (Fri) with one setting (PRD G3)
3. Scope
As agreed in the PRD on 24 Jan: the web order-complete page only. Non-goals N1-N5 (app, incentives, other entry points, variants, LINE Login) stand.
4. Assumptions and constraints
Assumptions
| # | Assumption | Impact if wrong | Validated by |
|---|---|---|---|
| A1 | Chiba is dedicated 5 Feb-20 Apr | At risk (26 Jan request from Payments for 19 Mar-6 Apr). Losing 3 weeks pushes build into the freeze; go-live 21 May | 1 Feb meeting, Mr. Fujita |
| A2 | The LINE link only calls MOps's existing API | +0.5 person-months; exceeds budget (C2), needs re-approval | 16 Feb design review, Saeki |
| A3 | Copy and design fixed by 16 Feb | Each week late moves go-live a week | 16 Feb, MOps (Miyata) |
Validated and removed: holdout assignment by member ID works on the existing A/B platform (Mr. Mori, 24 Jan).
Constraints
| # | Constraint | Set by | Can it move? |
|---|---|---|---|
| C1 | Decision on 3 Aug, no extension | Executive Committee (mid-term plan, Sep 2028) | Not in this plan |
| C2 | Budget 3 person-months (JPY 3.6M) | Same | Overrun needs re-approval via Mr. Takanashi |
| C3 | Golden Week release freeze, 27 Apr-6 May | Site Development rule | Only you can grant an exception; we are not asking for one |
7 May is not a constraint; we chose it to get 12 weeks of data.
Where they collide: if go-live slips, 3 Aug does not, so we measure for fewer weeks.
| Go-live | Weeks measured | Users shown (est.) | Gap needed | vs our +2.0pt estimate |
|---|---|---|---|---|
| 7 May | 12 | about 171,000 | 1.6pt | 0.4pt margin |
| 14 May | 11 | about 157,000 | 1.7pt | 0.3pt margin |
| 21 May | 10 | about 143,000 | 1.9pt | 0.1pt margin |
| 28 May | 9 | about 128,000 | 2.1pt | Above the estimate; not worth building |
5. Team and effort (3 person-months)
| Who | Role | When | Effort |
|---|---|---|---|
| Chiba (Checkout Flow) | Lead developer, build and UAT | 5 Feb-20 Apr | 2.5 PM |
| Mori (Checkout Flow lead) | Design and code review | 5 Feb-20 Apr | 0.3 PM |
| Designer (Checkout Flow) | Prompt design (one version) | 5-16 Feb | 0.2 PM |
| Saeki (MOps) | API walkthrough; under C, covers build 19 Mar-6 Apr | 16 Feb; 19 Mar-6 Apr | MOps (outside budget) |
| Miyata (MOps) | Plan, weekly report, decision | Throughout | MOps (outside budget) |
6. Timeline
| Date | What | Owner |
|---|---|---|
| 1 Feb (Thu) | Planning meeting decides Chiba's allocation | Mr. Fujita |
| 5 Feb (Mon) | Build starts | Chiba |
| 16 Feb (Fri) | Design review (A2); copy and design fixed (A3) | Saeki, Miyata, Mori |
| 9-20 Apr | UAT | Chiba, Miyata |
| 23-26 Apr | Buffer | - |
| 27 Apr-6 May | Golden Week freeze | - |
| 7 May (Mon) | Go-live | Chiba |
| 4 Jun (Mon) | Week-4 review (recommendation CTR) | Miyata reports, Mori decides |
| 3 Aug (Fri) | Decision | Miyata |
| 10 Aug (Fri) | Remove if missed | Checkout Flow team |
7. Reporting and stop point
- Every Monday Miyata sends a one-page update to Mr. Fujita, Mr. Mori and Mr. Takanashi, always stating the forecast go-live and the gap it implies
- If go-live is forecast for 28 May or later, we stop the build and ask Ms. Akiyama to cancel. We will not ask to move the decision date
- Any failed assumption goes at the top of that week's update
完成の定義チェックリスト
計画書を出す前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
今日の演習
Bad例の【前提条件】4行を、前提の表（前提 ／ 外れたときの影響 ／ 確かめる日・人）に書き直す。条件: ①4行のうち、前提ではなく依頼や願望であるものを見分け、依頼は「誰に・何を・いつまでに」の1行に移す。②残った前提には、今日のシナリオの数字（3週・5/21・+0.5人月など）を使って影響を書く。③1つは「確かめ終えて外したもの」にできないか考える。
読み手を変えて、同じ計画書の「前提条件と制約」の部分を、決済チームのリード（千葉さんを借りたい側）向けに書き直す。 決済チームのリードは6/1の後払い決済を落とせない立場で、宮田の計画は「自分たちの依頼を邪魔するもの」に見えている（Lv3に近い読み手）。条件: ①6/1を守ることを、この文書の前提として先に書く（決済チームの前提を、こちらの計画の制約として受け入れる）。②案Cで佐伯さんが入るとき、決済チームに何も負担が生じないことを、結合テストの期間・千葉さんの稼働（3週全日）で具体的に示す。③決済チームの結合テストが延びて千葉さんの戻りが4/6より遅れた場合の、LINE導線の公開日と判定に要る差を、今日の表を使って1行で書く。④Betterで止めるか、Bestまで書くかを理由つきで決める。
取り組む前のヒント
- 前提を書く前に、「これが外れたら誰が困るか」を人の名前で書き出す。誰も困らないなら、その前提は書かなくてよい
- 「〜が得られること」「〜が確保されること」と書きかけたら、それは前提ではなく依頼。相手と期日を決めて依頼の欄へ
- 制約は決めた人を書くと、正体が分かる。自分で置いた日は制約ではなく目標日。今日の5/7がそれ
- 罠: 遅れても動かない日（判定日・契約日・法令の施行日）がある計画では、遅れの影響は「何日遅れる」ではなく「何が減る」で書く。今日は測る期間が減り、判定に要る差が上がった
- 罠: 揺れている前提の持ち主が読み手本人のとき、知らせるだけで止めない。決められる形（案と負担）にして出す
実務での使いどころ
プロジェクト計画書は、憲章（PMO#1、Day003）で「やってよい」が決まり、PRD（企画#2、Day019）で「何を作るか」が決まった後に、「どう届けるか」を人と時間の持ち主から預かるために書く。今日の計画書は、Day019のPRDを、人員を配置する他部署の部長の言葉に降ろしたもので、判定の基準はDay018から、「外せる作り」はDay019から引き継いでいる。続編として、WBS / スケジュール線表（PMO#3）は千葉さんの2.5人月を週単位に割り、案Cで佐伯さんが入る3週の作業を切り出す回に、リスク登録簿（PMO#4）はA1〜A3を確率×影響で並べ直す回に、ステータスレポート（PMO#6）は「毎週の報告に公開見込み日と判定に要る差を書く」を実際に書く回にできる。
この回の設計メモ（迷った他案・扱わなかった範囲・出所）
迷った他案と採らなかった理由
- 読み手を森さん（実行チーム）にする案 — カタログの主な読み手に合うが、森さんは千葉さんの配置を決められない。今日の勝負どころ（揺れている前提）の持ち主は人を配置する部長なので、承認者の藤田部長にした
- 案Dとして「GW凍結中に公開する（藤田部長に例外を出してもらう）」を表に入れる案 — 公開が早まるのは最大1週程度で、GWは購入が最も多い時期。他部署の画面を、その部の凍結ルールを破って変えることになり、森さんの指標（おすすめ商品）にとっても最悪の時期。読み手が嫌がることを知っていて案に並べるのは、交渉の手として不誠実だと判断し、「求めません」と明言する方を採った。前提が変わり、凍結期間が短縮されたら（例: 5/1まで）見直す
- 既定（決まらなかったら）を推奨の案Cにする案 — 案Cは他部署（MOps）の人が自部署のコードに入るので、藤田部長の了承なしに進めてはいけない。了承がない状態で進められるのは案Bだけ。既定は、読み手の承認なしで実行できる案にする
- 公開が遅れたら判定に要る差は1.6ptのまま据え置く案 — PRDの1.6ptは「12週で約2,700人」から出した値で、本当の基準は人数の方。期間が減っても1.6ptで判定すると、中期計画の基準（2,700人）より甘い判定になる。人数を基準にし、週数ごとに差を計算し直した
- Betterで前提の確率（A1: 70%など）を書く案 — 確率に根拠がない。根拠のない数字を置くより、「既に揺れている」という事実（1/26の申し入れ）を書いた方が強い
扱わなかった範囲
- 計画書の他の章（コミュニケーション計画、品質計画、調達計画）。PMBOKの計画書は十数の補助計画を含むが、今回は比較セクションを前提と制約に絞り、全文も7章に抑えた。全文はPMBOKの計画書の網羅ではない
- 案Cで佐伯さんが他部署のコードに入るときの権限・レビュー手順の詳細（全文では「森さんが承認してから入れる」の1行のみ）
- 後払い決済の結合テスト自体の計画（決済チームの文書）。外部委託90万円は仮定で、見積もりは取っていない
- リスク登録簿としての確率×影響の評価（PMO#4の回に回す）
数字と概念の出所
- 会社・人物・日付はすべて架空。新登場: サイト開発部長・藤田さん、購入フローチームのエンジニア・千葉さん、決済チーム（リードは名前を出していない）。佐伯さん（MOps）はDay008・Day010から
- 〔仮定〕（シナリオ内で置いた値）: 決済の結合テストの外部委託 約90万円、案Cの立ち上がりで最大1週遅れる、A2が外れたときの+0.5人月、工数の内訳（千葉2.5・森0.3・デザイナー0.2人月）、見込み+2.0pt（Day019の案A・Cの仮定を引き継ぎ）
- 〔導出〕は作成時に Python で計算した: 判定に要る差＝2,700人÷表示人数。表示人数は12週171,000人（Day019）を週数に比例すると仮定して、11週156,750→1.72pt、10週142,500→1.89pt、9週128,250→2.11pt。実際は短い期間ほど重複が少なく1週あたりの人数は多めになるので、この比例の仮定は要る差をやや大きめに見積もる側。千葉さんの2/5〜4/20は11週≒2.5人月（4.33週/月）。曜日（2029/1/24水・1/26金・1/29月・2/1木・2/2金・2/5月・2/16金・3/19月・4/6金・4/9月・4/20金・4/23月・4/26木・4/27金・5/6日・5/7月・5/14月・5/21月・5/28月・6/1金・6/4月・7/30月・8/3金・8/10金）は作成時に確認した。公開日から7/30までの週数（5/7→12、5/14→11、5/21→10、5/28→9）も計算で確認した
- 前提・制約の定義（assumption: "considered to be true, real, or certain without proof"／constraint: 実行を制限する要因）: PMBOK Guide の用語定義。2026-10-05 の作成時に検索結果の要約で確認した（PMBOK本文は未読）
- RAG（Red/Amber/Green）のステータス表記、"stop point / kill criterion" の用法は、一般的な実務知識として書いた。出典ページは今回取得していない（記憶による）
- 分量（行数）は、各コードブロックの行数を作成後にスクリプトで数えた実測値
何が起きているか:
これは怠慢ではなく、「前提条件・制約は計画書の決まった欄だから埋める」という通念から生まれる形である。過去の計画書から欄ごと写すと、こうなる。