Day 003 — プロジェクト・PMO:プロジェクト憲章(チャーター)

同じ憲章の「3. 成功基準と権限範囲」を、Bad → Good → Better → Best で書き分けて比べる
カテゴリ3 プロジェクト・PMO 1周目 — 味方・協力的な読み手 2026-09-14 (Mon) 読み手:直属の上司(MOpsチームマネージャー・宮田さん) 15分版 / 60分版

今日の文書 — プロジェクト憲章(チャーター)

プロジェクトを正式に立ち上げる前に、目的・成功基準・体制・権限範囲を確定し、関係者全員が同じ認識で動き出せるようにする文書。企画書が「やるべきか」を判断する文書だったのに対し、憲章は「やると決まった後、誰が何を決めていいのか」を確定する文書である。

この文書の勝負どころ:成功の定義と権限範囲が明確か。
「誰が」「いくらまで」「どこまで」を自分の判断で決めてよいのかが曖昧なまま進むと、後になって「それは聞いていない」「誰の判断だったのか」という揉め事の火種になる。

シナリオ

Day002からの続き。あなたは当社EC事業本部・販促システム部の MOpsチームメンバー。

Day002で企画した「休眠顧客リターゲティング配信機能」は、宮田さんとの1on1(9/17)で 案B(データが薄いセグメント限定の3週間スパイク開発、160万円) の着手が承認された。スパイクは9/21週〜10/9で実施し、62,400人からランダム抽出した8,200人への配信結果は復帰購買率1.7%(139人)、月間復帰売上57万円。一律配信換算(約33.8万円)の約1.7倍で、様子見基準(現行1.1%を上回るか)を明確にクリアした。

10/13(火)、高梨部長・宮田さんとの打合せで、案A(全休眠会員82,400人への本格展開、投資320万円、開発期間6週間)へ進むことが承認された。ところが翌10/14朝、宮田さんから「320万円・複数部門が絡むプロジェクトだから、PMO規定(PJ-007 プロジェクトガバナンス規程)でキックオフ前にプロジェクト憲章の提出が必要と総務から言われた。今週金曜(10/16)15:00のPMO定例までにドラフトを見せてほしい。来週月曜(10/19)10:00の高梨部長への説明にも、そのまま使える完成度にしておきたい」と連絡が来た。

  • 提出先(直接の読み手): MOpsチームマネージャー・宮田さん。PMO定例前にレビューして返してほしいという依頼
  • その先にいる読み手: 宮田さんのレビューを経た後、10/19に高梨部長へ説明し、その後データ分析チーム・CS部門・インフラ運用チームにも共有される
  • 面倒な事情①: データアナリスト0.5人のアサインについて、データ分析チームのマネージャーからまだ正式な合意を得ていない(10/16に確認予定)
  • 面倒な事情②: CS部門への問い合わせ対応体制の確認は依頼済みだが、回答はまだない(10/17期限)
  • 面倒な事情③: スパイクの成功(8,200人・1.7%)が、全体(82,400人)でも同じ比率になる保証はない

つまり宮田さんは、あなたの味方であり、この憲章の内容にそのまま自分の名前で高梨部長に説明する立場の人である。彼が今日確認したいのは「この文書のまま出して、後で自分が困らないか」であり、これがこの憲章の実質的な勝負どころ。

読み手プロファイル

項目内容
誰が読むかMOpsチームマネージャー・宮田さん(1名、直属の上司。プロジェクトのスポンサー代理としてPMOと高梨部長の間に立つ立場)
何を判断するために読むかこのドラフトのまま10/16のPMO定例に出し、10/19に高梨部長へ説明できる完成度かどうか。修正が必要ならどこか
何を知っているかDay002の企画書からスパイク結果(1.7%)、10/13の決定(案Aへ進む)まで、経緯のすべて
何を知らないかPMO規定「PJ-007」が憲章に何を必須項目として要求しているか、権限範囲をどこまで具体的に書くべきかの相場感
何を気にしているか① 高梨部長への説明で「それで誰が何を決められるのか」と突っ込まれないか ② データ分析チーム・CS部門の合意がまだ取れていないことを、隠さず正直に書いているか ③ 自分(宮田さん)がこの憲章の中でどういう役割を負うことになるのか
読む時間と場面10/16(金)15:00のPMO定例の前、業務の合間に15分ほどで目を通し、赤入れして返す
この読み手が変わると何が変わるか: カタログ上の主な読み手は「ステークホルダー全員」である。今回は宮田さんという1人の味方に絞って先にレビューを依頼された形だが、これは全ステークホルダー向けの文書を書く前段階の「下読み」に当たる。宮田さんのレビューを通ったあと、この文書はほぼ同じ内容のまま、まだ経緯を知らないデータ分析チーム・CS部門・インフラ運用チームにも配布される。そのため、宮田さんしか読まない前提で経緯の説明を省いてはいけない——内容自体は「経緯を知らない人が読んでも成立する」水準を最初から満たしておく必要がある。

4段階で見る — 「3. 成功基準と権限範囲」

企画書とは異なり、憲章では「なぜやるか」ではなく「誰が何を決めてよいか」が最も差の出るセクションになる。同一セクションを4段階で書き分けて比べる。

Bad
成功基準は「都度設定」で実質
なし。体制は「必要に応じて
連携」「適宜相談」で、誰が
何を決める権限か一切不明。
Good
成功基準を600万円等の数値で
固定。320万円以内はPM判断、
超過は高梨部長。ただし宮田
さんの役割・合意状況は不明。
Better
権限範囲を表で提示。体制に
「合意済み/未合意」を明記。
宮田さんの役割(レビュー・
同席)を新設。代替案はまだ。
Best
未合意事項に代替案A/Bを用意。
高梨部長の想定質問にPJ-007
規程で先回り回答。次の行動
まで条件分岐で確定。
Bad
Success metrics "as
appropriate" - no fixed
numbers. Authority undefined;
"consult as needed" x3.
Good
Fixed numeric criteria
(JPY 6.0M etc). PM decides
within JPY 3.2M, Sponsor
above. Miyata's role unclear.
Better
Authority shown as a table.
Team status marked Agreed/
Not agreed. Miyata's role
added. No fallback yet.
Best
Open item gets fallback A/B.
Anticipated question answered
via PJ-007 policy. Next steps
resolved with a condition.
Bad — 妥協して雑に作った状態 / 約13行
3. プロジェクトの目的と成功基準

本プロジェクトは、休眠顧客への対応を強化し、売上向上に貢献する
ことを目的とする。

成功基準については、リターゲティング配信の効果を検証しながら、
適切な指標を都度設定していく方針とする。

4. プロジェクト体制

PMは私が担当する。開発は小島さんにお願いする予定。データ分析
チームやCS部門とも、必要に応じて連携しながら進めていきたい。

予算や進め方に関して問題が生じた場合は、その都度、関係者と
相談しながら対応する。

何が起きているか

  • 「都度設定していく」は、憲章を作る意味そのもの——事前に基準を固定しておくこと——を失わせている。何を達成すれば成功なのか、プロジェクト終了後まで誰にも分からない
  • 「必要に応じて連携」では、データ分析チームやCS部門から正式な合意を得ているのか、これから頼むだけなのかが区別できない
  • 「その都度、関係者と相談しながら対応する」には、誰が最終的に決める権限を持つのかが一切書かれていない。予算超過やスケジュール遅延時に止める権限がPMかスポンサーか分からない
  • 「必要に応じて」「都度」「適宜」という、判断を先送りする言葉が短い文章の中に3回出てくる
  • 高梨部長への説明で「それで、誰が何を決められるんですか」と一言聞かれた瞬間に、答えられない構造になっている
これは能力の問題ではなく時間切れの構造で起きる。権限範囲を具体的な数字としきい値で書く作業は関係者への確認の手間がかかる。締切が近いと「決まっていないことは決まっていないまま」書いてしまいやすい。
Bad
3. Purpose and Success Criteria

This project aims to strengthen our approach to dormant customers
and contribute to revenue growth.

Success metrics will be determined as appropriate as we validate
the effectiveness of the retargeting campaign.

4. Project Structure

I will serve as PM. Development will be handled by Kojima. We will
coordinate with the Data Analytics team and CS as needed.

If issues arise regarding budget or approach, we will consult with
stakeholders as appropriate.

英語にすると粗さが露骨に出る

"as appropriate" が短い文章の中に3回出てくる。英文ではこの表現は「基準を決めていない」の言い換えとして即座に見抜かれ、日本語の「都度」「適宜」よりもむしろ強く「準備不足」のシグナルとして読まれる。

Good — 型は満たしている / 約22行
3. プロジェクトの目的と成功基準

目的: 休眠顧客(82,400人)向けのリターゲティング配信を自動化し、
月間復帰売上を拡大する。

成功基準(稼働開始から3ヶ月以内に達成):
・全休眠会員への展開後、月間復帰売上を600万円以上にする
  (現行340万円比+76%)
・配信停止(オプトアウト)率を1%未満に維持する
・システムの月間運用コストを25万円以内に収める

4. プロジェクト体制と権限範囲

プロジェクトマネージャー: 私(MOpsチーム)
スポンサー: 高梨部長(EC事業本部 販促システム部長)

体制:
・バックエンド開発: 小島(1名、専任、6週間)
・データアナリスト: 0.5人(データ分析チームより、6週間)
・CS部門: 配信増加に伴う問い合わせ対応体制の確認

PMの権限範囲:
・予算320万円の範囲内での支出判断はPMが行う
・上記を超える予算超過、または重大なスケジュール変更は、
  スポンサー(高梨部長)の承認が必要

Badから何が変わったか 動いた軸:③事実と解釈の分離 → ④次の行動

  • ③ 「適切な指標を都度設定」が消え、成功基準が期間(3ヶ月以内)・数値(600万円、1%未満、25万円以内)付きで固定された
  • ④ 権限範囲について「320万円以内はPM」「超過は高梨部長」という線引きが初めて明記された

まだ足りないもの

  • 権限範囲の記述はスポンサーとPMの関係のみで、宮田さん自身がこの中でどんな役割・責任を持つのか一言も出てこない
  • データ分析チーム0.5人・CS部門の「連携」が、すでに相手部門の合意を得た事実なのか、これから調整するものなのか区別されていない。宮田さんが最も気にする「後で他部門から『聞いていない』と言われないか」に直結する論点なのに、他の記述と同じ重さで埋もれている
  • 構成が「目的→成功基準→体制→権限」という一般的な順であり、宮田さんが今日の15分のレビューでまず確認したい「自分は何にサインすることになるのか」「まだ合意が取れていない部分はどこか」が後半まで出てこない
  • 予算超過時の対応はあるが、スケジュール遅延時に誰がどの基準で判断するかの具体的な線引きがない
Goodの限界は「読めば分かる」が「読まないと分からない」こと。 宮田さんは、このまま高梨部長に見せていいものかどうかを、自分でもう一度考え直す作業を強いられている。
Good
3. Purpose and Success Criteria

Purpose: Automate retargeting delivery to 82,400 dormant members
to grow monthly reactivation revenue.

Success Criteria (within 3 months of go-live):
- Monthly reactivation revenue of JPY 6.0M or more after full
  rollout (+76% over the current JPY 3.4M)
- Opt-out rate maintained below 1%
- Monthly operating cost kept within JPY 250K

4. Project Structure and Authority

Project Manager: Me (MOps Team)
Sponsor: Director Takanashi (Head of Promotion Systems, EC Business
Unit)

Team:
- Backend development: Kojima (1, full-time, 6 weeks)
- Data analyst: 0.5 FTE (from Data Analytics team, 6 weeks)
- CS: Confirming support capacity for increased inquiry volume

PM Authority:
- The PM makes spending decisions within the JPY 3.2M budget
- Budget overruns or major schedule changes require Sponsor
  (Director Takanashi) approval

英語版のGoodで注目する点

数字も権限の線引きもあるが、"Confirming support capacity" が合意済みか未了かを区別していない。英文の読み手は "confirming" を進行中の作業と読むため、これが完了しているという誤解を招きやすい。

Better — 読み手に最適化されている / 約24行
3. 成功基準と、まだ合意が取れていない点

成功基準(稼働開始から3ヶ月以内に達成、数値は固定):
・月間復帰売上 600万円以上(現行340万円比+76%)
・オプトアウト率 1%未満
・月間運用コスト 25万円以内

宮田さんに今回ご確認いただきたい点が1つあります。データ分析
チームの0.5人アサインについて、まだ同チームのマネージャーから
正式な合意を得られていません(10/16に確認予定)。合意が取れない
場合、成功基準の達成期限を2週間後ろ倒しする必要が出てきます。

4. 権限範囲とエスカレーション

  項目                       PM(私)        スポンサー(高梨部長)
  予算320万円の範囲内の支出    ○ 判断可        報告のみ
  予算超過・追加投資           ×            ○ 承認必要
  スケジュール2週間以内の変更   ○ 判断可        報告のみ
  スケジュール2週間超の変更    ×            ○ 承認必要
  他部門との調整が難航した場合  △ まず調整      ○ 最終判断

宮田さんの役割: PMOへの提出前レビューと、高梨部長への説明時の
同席をお願いします。決裁自体は高梨部長が行います。

5. 体制(合意状況つき)

・バックエンド開発: 小島(1名、専任、6週間) — 合意済み
・データアナリスト: 0.5人(データ分析チームより) — 未合意
  (10/16に部門マネージャーと確認予定)
・CS部門: 問い合わせ対応体制の確認 — 依頼済み、回答待ち(10/17期限)

★ Goodから何が変わったか — ここが今日の学習の中心

読み手プロファイルの各項目に、変更を1対1で対応させている。

読み手プロファイルの項目Betterで行った変更
何を気にしているか①
「後で他部門から聞いていないと言われないか」
体制表に「合意済み/未合意/依頼済み」を明記した。Goodでは一律に「連携」とだけ書かれ、どれが危ういのか自分で見分けられなかった
何を気にしているか②
「権限があいまいで揉めないか」
権限範囲を表に変え、金額・期間のしきい値ごとにPM/スポンサーどちらが決めるかを一覧化した
何を気にしているか③
「自分はこの中でどう関わるのか」
「宮田さんの役割」を新設し、レビューと同席という具体的な役割を明示した。Goodでは宮田さんの存在自体が本文に出てこなかった
何を判断するために読むか
「このまま高梨部長への説明に使えるか」
「宮田さんに今回ご確認いただきたい点」として、宮田さん自身のTo Do(データ分析チームの0.5人アサインの確認)を冒頭近くに明示した

特に重要な1つの動き

未合意事項(データアナリスト0.5人)を、リスク一覧の1項目としてではなく、本文の中で名指しして扱った。 Goodではこの情報自体は書かれていたが、それが「まだ合意されていない」という事実は書かれていなかった。宮田さんが最も恐れているのは「合意前の情報を、合意済みであるかのように高梨部長に説明してしまうこと」であり、ここを先に開示したことが最大の変化である。

まだBestではない理由:未合意のデータ分析チームのアサインが崩れた場合の代替案(誰が確保するか、どう対応するか)が書かれていない。また、高梨部長が抱くであろう「合意前になぜ憲章を提出するのか」という想定される疑問への回答もまだない。
Better
3. Success Criteria and One Open Item

Success Criteria (within 3 months of go-live, fixed):
- Monthly reactivation revenue >= JPY 6.0M (+76% over current
  JPY 3.4M)
- Opt-out rate < 1%
- Monthly operating cost <= JPY 250K

Open item for Miyata: the Data Analytics team's manager has not yet
formally agreed to the 0.5 FTE assignment (confirming Oct 16). If
agreement isn't reached, the success-criteria deadline would need to
move back two weeks.

4. Authority and Escalation

  Item                          PM (me)        Sponsor (Takanashi)
  Spend within JPY 3.2M budget   Decide          Report only
  Budget overrun / new spend      No             Approval required
  Schedule change <= 2 weeks      Decide          Report only
  Schedule change > 2 weeks       No             Approval required
  Cross-team conflict unresolved  First attempt   Final call

Miyata's role: review this draft before the PMO meeting and attend
the briefing with Takanashi. Takanashi holds final approval.

5. Team (with agreement status)

- Backend: Kojima (1, full-time, 6 weeks) - Agreed
- Data analyst: 0.5 FTE (Data Analytics team) - Not yet agreed
  (confirming Oct 16 with the team manager)
- CS: inquiry-handling readiness - Requested, awaiting reply (due
  Oct 17)

英語版で構成が変わっている点

"Not yet agreed" と明示したことで、Goodにあった曖昧さが消えている。ただし、合意が取れなかった場合の代替案がまだ示されておらず、英語の読み手は "So what happens if it doesn't get agreed?" という次の疑問を持ったまま読み終える。

Best — 読み手が意思決定できる / 約23行
3. 成功基準と権限範囲(要ご確認:1件の未合意事項あり)

成功基準(稼働開始から3ヶ月以内、数値は固定・変更にはスポンサー
承認が必要):
・月間復帰売上 600万円以上(現行340万円比+76%)
・オプトアウト率 1%未満
・月間運用コスト 25万円以内

  項目                       PM(私)        スポンサー(高梨部長)
  予算320万円内の支出          ○判断可         報告のみ
  予算超過・追加投資           ×            ○承認必要
  スケジュール2週間以内の変更   ○判断可         報告のみ
  スケジュール2週間超の変更    ×            ○承認必要
  他部門調整が難航した場合     △まず調整       ○最終判断

未合意事項(正直に): データアナリスト0.5人のアサインについて、
データ分析チームのマネージャーから正式合意を得ていません
(10/16確認予定)。合意が取れない場合の代替案は2つです。
  A) 私が週5時間、簡易分析を自分で巻き取る(精度は下がるが遅延なし)
  B) 開始を2週間後ろ倒しし、次スプリントでの正式アサインを待つ
10/16の回答次第でA/Bいずれかを選び、宮田さんに即日報告します。

想定される質問(高梨部長から): 「合意が取れていないのに、なぜ
今、憲章を提出するのか」
→ PJ-007規程上、投資額200万円超のプロジェクトはキックオフ日の
1週間前までに憲章提出が必要です。未合意事項は代替案とセットで
開示したうえで先に提出するのが、規程上も正しい進め方です。

宮田さんへのお願い: 上記の権限範囲・未合意事項について、10/16
15:00のPMO定例までにご確認いただき、修正点があればご指摘ください。

Betterから何が変わったか 動いた軸:⑤想定反論 → ④次の行動

  • ⑤ 未合意事項を隠さず開示するだけでなく、代替案A/Bを自分から用意した。「合意できていません」で終わらせず、遅延させない方法と遅延を受け入れる方法を両方示している
  • ⑤ 高梨部長が抱くであろう疑問(「合意前になぜ憲章を出すのか」)を先に名指しして、規程の条文で回答した。感情的な言い訳ではなく、PJ-007という制度的根拠で応じている。ここがBetterとBestの実質的な境界
  • ④ 「10/16の回答次第でA/Bを選び、即日報告する」という条件付きの次の行動が確定した。宮田さんは「未合意のまま放置されている」のではなく「今週中に決着する見込みがある」と理解して高梨部長に説明できる
今回はBestまで作るべきか:Best必要。
理由は2つ。① 憲章は一度承認されると、以後のプロジェクトで「誰が何を決めてよいか」の拠り所になる、後戻りコストの高い文書だから ② 宮田さんはこの内容を自分の言葉で高梨部長に説明する立場であり、想定質問にその場で答えられる形になっていないと、宮田さん自身が答えに詰まることになるから。
── 逆に、この憲章が承認された後の「体制・予算の細部」は、合意状況が固まればBetterで十分。毎回すべての章に代替案とトレードオフを書くのは過剰で、まだ揺れている論点にBestの手間を集中させるのが正しい配分。
Best
3. Success Criteria and Authority (1 Open Item Needs Your Review)

Success Criteria (within 3 months of go-live, fixed; changes require
Sponsor approval):
- Monthly reactivation revenue >= JPY 6.0M (+76% over current
  JPY 3.4M)
- Opt-out rate < 1%
- Monthly operating cost <= JPY 250K

  Item                          PM (me)        Sponsor (Takanashi)
  Spend within JPY 3.2M budget   Decide          Report only
  Budget overrun / new spend      No             Approval required
  Schedule change <= 2 weeks      Decide          Report only
  Schedule change > 2 weeks       No             Approval required
  Cross-team conflict unresolved  First attempt   Final call

OPEN ITEM: The Data Analytics team's manager has not yet formally
agreed to the 0.5 FTE assignment (confirming Oct 16). Two fallback
options if agreement isn't reached:
  A) I absorb basic analysis myself, ~5 hrs/week (lower precision,
     no delay)
  B) Push the start date back two weeks and wait for formal
     assignment in the next sprint
I will pick A or B based on the Oct 16 answer and report to Miyata
the same day.

ANTICIPATED QUESTION (from Takanashi): "Why submit the charter
before this is agreed?"
-> Per governance policy PJ-007, projects over JPY 2M must submit a
charter one week before kickoff. Disclosing the open item alongside
a fallback plan, rather than waiting for full agreement, is the
compliant path.

ASK OF MIYATA: Please review the authority table and open item above
before the Oct 16 PMO meeting and flag anything that needs revision.

英語版Bestで意図的に変えた点

見出しに (1 Open Item Needs Your Review) と付けたことで、章題自体が「まだ動いている論点がある」というBLUFになっている。また ANTICIPATED QUESTION という定型ラベルを立てて質問と回答をセットで提示するのは、日本語の「想定される質問」よりも英文としてはさらに直接的な型で、会議で実際に聞かれる前に文書内で処理してしまう効果がある。

日英差分ノート

1. 「権限範囲」を成立させる情報の粒度が違う

日本語では「スポンサーの承認が必要です」という一文で、宮田さんは自分で「それは高梨部長のことだ」と補って理解できる。英語では Requires Sponsor (Takanashi) approval のように、役職名だけでなく個人名までセットで書かないと、複数のスポンサー候補がいる場合に誰を指すか曖昧になる。 日本語ほど「文脈で察して人物を特定する」ことを期待できない。

2. 未合意事項の開示に、代替案が伴わないと評価が変わる

日本語で「まだ合意が取れていません」とだけ書いても、婉曲さの中に「今後どうにかします」という含みが自然に読み取られることがある。英語で同じ内容を "not yet agreed" とだけ書くと、「対応策を考えていない」と解釈されるリスクが高い。 英語Bestで Two fallback options という定型ラベルを立てて対応策とセットにしているのはこのため。

3. 「プロジェクト憲章」という文書の完成形の期待値が違う

英語圏では "Project Charter" はPMBOK等である程度標準化された型を持ち、Sponsor's Signature(署名欄)が本文の必須要素として期待されることが多い。日本語の「プロジェクト憲章」は社内ごとにフォーマットが異なり、承認欄が明示されないことも珍しくない。英語版の全文では末尾に署名欄を明示しているが、これは直訳ではなく英文の型に合わせて追加した要素である。

頻出表現

日本語Englishトーンの強さ・使う場面
権限範囲Authority (matrix) / Decision rights中立。しきい値(金額・期間)と承認者名をセットで書かないと機能しない
未合意事項Open item / Not yet agreed中立。単独では使わず、必ずfallback optionとセットにする
様子見基準/エスカレーション基準Escalation threshold中立。「何が起きたら誰に上げるか」を数値・期限で書く型
スコープ外(やらないこと)Out of scope / Non-goals中立。日本語の「やらないこと」より一段フォーマルな語感
想定される質問Anticipated question(s)中立〜強い。会議で聞かれる前に文書内で処理する定型ラベル
ご確認いただきたいRequesting your review / Please flag中立。「確認してほしい」対象(表・箇条書き)を名指しする
適宜/都度/必要に応じて(多用は避ける)as needed / as appropriate(多用は避ける)弱い。日本語以上に「基準未定」のシグナルとして強く読まれるため、頻用は禁物

差分5軸まとめ

軸 🔴 Bad🟡 Good🟢 Better🔵 Best
① 結論の位置 目的が抽象的な1文のみ。成功基準は「都度設定」で実質的にない 成功基準は数値化されているが4章の後半 冒頭を「まだ合意が取れていない点」から始め、宮田さんの宿題を先に提示 見出し自体に「要ご確認:1件の未合意事項あり」と明記し、論点を冒頭で名指し
② 読み手適合 想定なし。誰が読んでも同じ抽象度 一般的な憲章の型。宮田さん個人の役割には触れず 「宮田さんの役割」を新設し、レビュー・同席という具体的な関与を明示 宮田さんへの依頼を「10/16までに確認」と期限つきで名指し
③ 事実と解釈の分離 「効果を検証しながら」「必要に応じて」など、判断の先送りと事実が未分離 成功基準・体制は事実として明確。ただし合意状況(事実かどうか)は未区別 体制表に「合意済み/未合意/依頼済み」を明記し、事実の確度を区別 未合意事項を独立した項目として扱い、確度と対応策をセットで提示
④ 次の行動 「その都度、関係者と相談」で誰が・いつ・何をするか不明 権限範囲は明記されたが、次の行動そのものは書かれていない 「10/16に確認予定」まで書かれているが、確認できなかった場合の行動がない 「10/16の回答次第でA/Bを選び、即日報告」と条件分岐まで確定
⑤ 想定反論 無視。反論が来ることも想定していない書きぶり リスクとして扱われず、そもそも記述がない 未合意事項は開示したが、対応策や高梨部長からの疑問への回答はまだない 高梨部長の想定質問を名指しし、PJ-007という制度的根拠で先回りして回答
分量(参考) 約13行約22行約24行 ← 最長約23行
分量の行に注目。 GoodからBetterにかけては「体制表への合意状況の追記」でわずかに増え、BetterからBestは「代替案A/B」を足しつつ他の冗長な言い回しを削ったため、ほぼ同じ分量で情報密度だけが上がっている。Bestが最も短いとは限らない——今回は「必要な情報を足す」ことがBestの主な仕事だった回として記録する。

Best版・全文

ここまでは「3. 成功基準と権限範囲」の抜粋だけを比べてきた。以下は Best 水準のプロジェクト憲章としての全文。そのままPMO定例・高梨部長への説明に持ち込める完成形。

日本語版 全文を見る
休眠顧客リターゲティング配信システム 本開発プロジェクト憲章(案)

作成:     EC事業本部 販促システム部 MOpsチーム(私)
日付:     2026年10月14日
版:       v0.1(ドラフト)
レビュー: 宮田(MOpsチームマネージャー)― 10/16 PMO定例まで
承認:     高梨部長(EC事業本部 販促システム部長)― 10/19 説明時


■ ご確認いただきたいこと(宮田さん向け)

本憲章のまま10/19の高梨部長への説明に使えるか、また3章の権限範囲
の表に修正が必要かをご確認ください。未合意事項が1件あります
(3章)。


■ 1. 背景と目的

自社ECの休眠会員(90日以上未購買)82,400人(全会員620,000人の
13.3%)に対し、現行の一律クーポン配信は月間復帰売上340万円に
とどまっている。

2026年6〜8月のPoC、および9/21〜10/9のスパイク(8,200人対象)で、
セグメント別配信の復帰購買率は1.7%(一律配信の様子見基準1.1%を
上回る)を記録した。10/13、高梨部長・宮田さんとの打合せで、全
休眠会員82,400人への本格展開(投資320万円、開発期間6週間)へ
進むことが承認された。

社内規定PJ-007(プロジェクトガバナンス規程)により、投資額200万円
超、または関与部門3部門以上のプロジェクトは、キックオフ1週間前
までに本憲章の承認が必要となる。


■ 2. スコープ

やること:
・全休眠会員82,400人への自動リターゲティング配信システムの開発
・RFMスコアリングと配信の自動化(現行の手動セグメント作成の廃止)

やらないこと(Non-Goal、企画書から継承):
・休眠会員以外(アクティブ会員全体)への配信最適化
・メール以外のチャネル(プッシュ通知・LINE等)への拡張
・レコメンドエンジン自体の高度化(協調フィルタリング等)


■ 3. 成功基準と権限範囲(要ご確認:1件の未合意事項あり)

成功基準(稼働開始から3ヶ月以内、数値は固定・変更にはスポンサー
承認が必要):
・月間復帰売上 600万円以上(現行340万円比+76%)
・オプトアウト率 1%未満
・月間運用コスト 25万円以内

  項目                       PM(私)        スポンサー(高梨部長)
  予算320万円内の支出          ○判断可         報告のみ
  予算超過・追加投資           ×            ○承認必要
  スケジュール2週間以内の変更   ○判断可         報告のみ
  スケジュール2週間超の変更    ×            ○承認必要
  他部門調整が難航した場合     △まず調整       ○最終判断

未合意事項(正直に): データアナリスト0.5人のアサインについて、
データ分析チームのマネージャーから正式合意を得ていません
(10/16確認予定)。合意が取れない場合の代替案は2つです。
  A) 私が週5時間、簡易分析を自分で巻き取る(精度は下がるが遅延なし)
  B) 開始を2週間後ろ倒しし、次スプリントでの正式アサインを待つ
10/16の回答次第でA/Bいずれかを選び、宮田さんに即日報告します。

想定される質問(高梨部長から): 「合意が取れていないのに、なぜ
今、憲章を提出するのか」
→ PJ-007規程上、投資額200万円超のプロジェクトはキックオフ日の
1週間前までに憲章提出が必要です。未合意事項は代替案とセットで
開示したうえで先に提出するのが、規程上も正しい進め方です。


■ 4. 体制(合意状況つき)

・PM: 私(MOpsチーム)
・スポンサー: 高梨部長(EC事業本部 販促システム部長)
・バックエンド開発: 小島(1名、専任、6週間) — 合意済み
・データアナリスト: 0.5人(データ分析チームより) — 未合意
  (10/16に部門マネージャーと確認予定)
・CS部門: 問い合わせ対応体制の確認 — 依頼済み、回答待ち(10/17期限)
・インフラ運用: 配信基盤拡張担当1名 — 合意済み


■ 5. 予算・スケジュール

投資額320万円の内訳:
  バックエンドエンジニア(小島) 1名×6週間      240万円
  データアナリスト 0.5人×6週間(未合意分含む)  45万円
  配信基盤の拡張・保守                          20万円
  CS部門連携(FAQ整備等)                       15万円

スケジュール: 10/20(月)週キックオフ〜11/28(金)完了(6週間)。
全休眠会員への展開は12月上旬を目標。


■ 6. 主要リスク

・データアナリスト0.5人が未合意(前述、対応A/Bあり)
・スパイクは62,400人中8,200人のサンプルであり、残り54,200人でも
  同じ復帰購買率(1.7%)になる保証はない。展開後1ヶ月時点の実測
  値を見て、成功基準の達成見込みを再評価する
・配信対象が10倍規模になることで、CS部門への問い合わせが増加し、
  対応体制が追いつかない可能性がある


■ 7. 承認

  レビュー: 宮田(MOpsチームマネージャー)  日付: 2026/10/___
  承認:     高梨部長(EC事業本部 販促システム部長)日付: 2026/10/___


■ 8. 次の行動

  10/16(金) 宮田さん   本憲章をレビューし、修正点をPMO定例前に指摘
  10/16(金) 私         データ分析チームに正式アサインの可否を確認
  10/17(火) CS部門      問い合わせ対応体制について回答
  10/19(月) 高梨部長    本憲章の最終承認可否を判断
English 全文を見る
Project Charter (Draft): Dormant Customer Retargeting System -
Full Build

Prepared by: MOps Team, Promotion Systems Dept., EC Business Unit (Me)
Date:        14 October 2026
Version:     v0.1 (Draft)
Review:      Miyata (MOps Team Manager) - by the Oct 16 PMO meeting
Approval:    Director Takanashi (Head of Promotion Systems) - at the
             Oct 19 briefing


REQUEST TO MIYATA

Please confirm whether this draft is ready to use as-is for the
Oct 19 briefing with Takanashi, and whether the authority table in
Section 3 needs revision. One open item remains (Section 3).


1. BACKGROUND AND PURPOSE

Of our 620,000 active EC members, 82,400 (13.3%) are dormant (90+
days without purchase). The current uniform coupon program recovers
only JPY 3.40M/month.

Our June-Aug 2026 pilot and the Sep 21 - Oct 9 spike (8,200 members)
achieved a 1.7% reactivation rate, exceeding the pre-agreed 1.1%
go/no-go threshold. On Oct 13, Director Takanashi and Miyata approved
proceeding to full rollout across all 82,400 dormant members
(JPY 3.2M investment, 6-week build).

Per internal policy PJ-007 (Project Governance Policy), any project
exceeding JPY 2M or involving 3+ departments requires this charter to
be approved one week before kickoff.


2. SCOPE

In scope:
- Building an automated retargeting delivery system for all 82,400
  dormant members
- Automating RFM scoring and segment-based delivery (replacing the
  current manual, monthly segment-building process)

Out of scope (inherited from the original proposal):
- Optimizing delivery to active (non-dormant) members
- Channels other than email (push notification, LINE, etc.)
- Upgrading the recommendation logic itself (e.g., collaborative
  filtering)


3. SUCCESS CRITERIA AND AUTHORITY (1 OPEN ITEM NEEDS YOUR REVIEW)

Success Criteria (within 3 months of go-live, fixed; changes require
Sponsor approval):
- Monthly reactivation revenue >= JPY 6.0M (+76% over current
  JPY 3.4M)
- Opt-out rate < 1%
- Monthly operating cost <= JPY 250K

  Item                          PM (me)        Sponsor (Takanashi)
  Spend within JPY 3.2M budget   Decide          Report only
  Budget overrun / new spend      No             Approval required
  Schedule change <= 2 weeks      Decide          Report only
  Schedule change > 2 weeks       No             Approval required
  Cross-team conflict unresolved  First attempt   Final call

OPEN ITEM: The Data Analytics team's manager has not yet formally
agreed to the 0.5 FTE assignment (confirming Oct 16). Two fallback
options if agreement isn't reached:
  A) I absorb basic analysis myself, ~5 hrs/week (lower precision,
     no delay)
  B) Push the start date back two weeks and wait for formal
     assignment in the next sprint
I will pick A or B based on the Oct 16 answer and report to Miyata
the same day.

ANTICIPATED QUESTION (from Takanashi): "Why submit the charter
before this is agreed?"
-> Per PJ-007, projects over JPY 2M must submit a charter one week
before kickoff. Disclosing the open item alongside a fallback plan,
rather than waiting for full agreement, is the compliant path.


4. TEAM (WITH AGREEMENT STATUS)

- PM: Me (MOps Team)
- Sponsor: Director Takanashi (Head of Promotion Systems, EC
  Business Unit)
- Backend: Kojima (1, full-time, 6 weeks) - Agreed
- Data analyst: 0.5 FTE (Data Analytics team) - Not yet agreed
  (confirming Oct 16 with the team manager)
- CS: inquiry-handling readiness - Requested, awaiting reply
  (due Oct 17)
- Infra: 1 platform-extension engineer - Agreed


5. BUDGET AND SCHEDULE

Budget breakdown (total JPY 3.2M):
  Backend engineer (Kojima), 1 x 6 weeks           JPY 2.40M
  Data analyst, 0.5 FTE x 6 weeks (incl. open item) JPY 0.45M
  Platform extension and maintenance                JPY 0.20M
  CS coordination (FAQ prep, etc.)                  JPY 0.15M

Schedule: Kickoff week of Oct 20, complete Nov 28 (6 weeks). Full
rollout to all dormant members targeted for early December.


6. KEY RISKS

- Data analyst assignment not yet agreed (see above; fallback A/B
  in place)
- The spike sampled 8,200 of the 62,400 thin-data members; the same
  1.7% reactivation rate is not guaranteed for the remaining 54,200.
  We will re-assess against the success criteria after one month of
  full rollout data
- A 10x increase in delivery volume may increase CS inquiry volume
  beyond current support capacity


7. APPROVAL

  Reviewed by: Miyata (MOps Team Manager)        Date: 2026/10/___
  Approved by: Director Takanashi (Head, Promotion Systems)
                                                   Date: 2026/10/___


8. NEXT STEPS

  Oct 16  Miyata       Review this charter and flag revisions before
                        the PMO meeting
  Oct 16  Me           Confirm data analyst assignment with the
                        Data Analytics team
  Oct 17  CS           Reply on inquiry-handling readiness
  Oct 19  Takanashi    Decide on final approval of this charter

完成の定義チェックリスト

プロジェクト憲章を提出する前に必ず確認する。「雑・妥協」を防ぐための外部基準。1つでも未チェックがあれば、まだ出さない。
進捗 0 / 9

今日の演習

15分版 — まずこれだけでもやる

Bad例の「4. プロジェクト体制」の段落だけを、宮田さんが一番気にする『権限範囲』の観点で3〜5行に書き直す。

条件はこれだけ:

  • 「誰が」「いくらまでなら」「自分の判断で」決めてよいかを1つ以上具体的に書く
  • 「必要に応じて」「都度」「適宜」を使わない
  • データ分析チームやCS部門との関係が「合意済み」か「まだ依頼段階」かに触れる
Better版を見ずに自分で書いてから見比べる。
60分版

読み手を「初めてこの文書を読むデータ分析チーム・CS部門・インフラ運用チームの担当者たち」(カタログ上の主な読み手=ステークホルダー全員)に変えて、Best版の「3. 成功基準と権限範囲」を書き直す。

彼らは宮田さんと違い、Day002からの経緯(PoC・スパイク・9/17の1on1)をまったく知らない。守る条件:

  • 冒頭で、この文書が何のプロジェクトの憲章かが1〜2文で分かること(経緯を知らない前提)
  • 権限範囲の表は残しつつ、「なぜこの権限分担になっているか」を一言添えること(宮田さん向けでは不要だった説明)
  • 各部門の担当者が「自分に何が求められているか」を、体制の章から自分の名前・役割を探さずに分かる形にすること
  • 分量はBestと同程度(30行以内)
取り組む前のヒント

考える順序

  1. 宮田さん向けの版で省略していた前提(休眠顧客とは何か、なぜこのプロジェクトが始まったか)を、どこまで補うべきか判断する
  2. 複数部門が同時に読むため、「自分に関係あるのはどこか」をすぐ見つけられる構成になっているかを確認する
  3. 未合意事項(データ分析チーム)については、当事者自身が読むことになるため、書き方のトーンをさらに慎重にする(相手を責めているように読めないか)

陥りやすい罠

  • 宮田さん向けの版をほぼそのまま流用してしまう。読み手が「経緯を知っている1人」から「経緯を知らない複数人」に変わっているため、説明すべき前提の量が変わる
  • 未合意事項の書き方が、宮田さん向けでは「私からの正直な開示」だったが、データ分析チーム本人が読む版では「まだ返事をもらっていません」がそのまま「催促」に見えかねない。事実の書き方は同じでも、読み手が変わればトーンの調整が必要になる典型例

チェックすべき観点

書き上げたら、「データ分析チームの担当者がこれを読んで、気分を害さずに自分のタスクを認識できるか」を判定する。できないなら、まだ宮田さん向けの粒度・トーンのまま止まっている。

実務での使いどころ

プロジェクト憲章は、企画が承認された直後、実行フェーズに入る前の「境界線」に位置する文書。前後の文書との関係を押さえると、憲章にどこまで書くべきかの判断がつく。

関係文書この憲章との関係
前企画書(企画#1、Day002)企画書の「様子見基準」(1.1%を上回るか)が、そのまま今回の憲章のプロジェクト成立根拠になった。企画書の「やらないこと」も、憲章の「スコープ」にそのまま引き継がれている
後プロジェクト計画書(PMO#2)憲章の「4. 体制」「5. 予算・スケジュール」が、計画書での詳細なタスク分解・調達計画のベースになる
後WBS / スケジュール線表(PMO#3)「6週間・320万円」という大枠が、ここで週次のタスクと担当まで分解される
後リスク登録簿(PMO#4)憲章「6. 主要リスク」の3項目が、ここで発生確率×影響度をつけて管理される最初のエントリになる
後ステークホルダーマップ / RACI(PMO#7)憲章の体制表は簡易的なものであり、RACIとして正式に分解されるのはここから
現場での実感として一番大きいのは、「未合意事項をいつ書くか」の判断。 全部合意が取れてから憲章を出そうとすると、PMO規定の締切に間に合わなくなることがある。今回のように「未合意だが代替案がある」状態で先に出す判断ができるかどうかが、憲章という文書の実務上の使い勝手を左右する。

自己評価(やった後に記入)