なぜ「PdM Playbook」を地域に翻訳するのか
PdM Playbook という、プロダクトマネージャーの動き方を6つの Skill にまとめたリポジトリを公開している。
これは僕自身が Web プロダクトの現場で 2025〜2026 年に使ってきた動き方を、再現可能な手順に落としたもの。AI と一緒に動くことが前提になっていて、ユーザーの声から、実装プロンプトまで、プロダクトマネージャーの手元で一直線に抜ける設計になっている。
このメディアで僕がやっているのは、Web プロダクトのつくり方を地域課題に持ち込むこと。だから PdM Playbook を、そのまま地域プロジェクトに翻訳する価値がある、と思っている。
これはそのシリーズの入り口にあたる記事。
PdM Playbook の6つの Skill
| # | Skill | やること |
|---|---|---|
| 1 | ユーザーの声 → 問題定義 | 生の声を、解くべき問題に変換する |
| 2 | AIディスカッション → Design Doc | AI と議論しながら設計の骨子を作る |
| 3 | Design Doc → 仕様書 | 設計を、作れる粒度に分解する |
| 4 | 仕様書 → 指示プロンプト | AI に作らせるための指示を組む |
| 5 | 優先順位マトリクス | やることと、やらないことを切り分ける |
| 6 | スコープ管理 | 走り出してからの範囲を守る |
順番に並べると、「声を拾ってから、ものができるまで」を、一人と AI で抜ける構造になっている。
翻訳する理由は、地域の「自走」のため
僕の地域での関わり方は、ずっと カスタマーサクセス的なスタンス で動いている。
火種をつくる。仕組み化する。地域の人が自走できる状態をつくる。そして、深く関わりすぎない。これは性格の問題ではなくて、地域プロジェクトの構造的に、外から来た人間が居座り続けると地域は弱くなる、という経験から来ている。
このスタンスで見ると、PdM Playbook を地域に翻訳する意味が変わってくる。
これは「プロダクトマネージャーである僕が、地域プロジェクトを動かすための道具」ではない。地域の人が、プロダクトマネージャーの動き方を自分の手で回せるようになるための道具として翻訳したい。
- 火種は、地域の住民にも、町議にも、商店主にもある
- でも「火種を、解くべき問題に変換する」「問題を、作れる粒度の仕様にする」「仕様を、AI や委託先に渡す」までの動き方は、いまの地域には埋め込まれていない
- ここに PdM Playbook の6つの Skill が入ると、外部のプロダクトマネージャーがいなくても、地域内で動き出す
PdM Playbook を地域に翻訳するというのは、外部の専門家依存を、地域内の動ける人に置き換える作業だ。これが CS スタンスとの接続点になる。
Skill 1：住民の声を、解くべき問題に変換する
6つの Skill の中で、地域に最も足りないと感じているのは、Skill 1 だ。
地域には、声が溢れている。「街灯が暗い」「子どもが遊ぶ場所がない」「商店街がさびれた」「移住者が定着しない」。役場にも、町議にも、商工会にも、毎日のように声が届いている。
でも、届いた声が、解くべき問題に変換されない。
「街灯が暗い」は、街灯の話なのか、夜間の安全の話なのか、町の動線の話なのか。「移住者が定着しない」は、住居の話なのか、仕事の話なのか、関係性の話なのか。声の表層と、解くべき問題の構造は、別物だ。この変換ができる人が、地域に決定的に足りない。
これは マチつく で僕が「コミュマネ＝CS担当」というペルソナを置いた時の問題意識と、ほぼ同じ。マチつくの企画起点は喜茂別の町議の街灯エピソードだったけれど、あの場面で必要だったのは、街灯を交換する人ではなくて、街灯エピソードを問題定義に翻訳する人だった。
Web プロダクトの世界では、これはプロダクトマネージャーの中核スキルとして長く議論されてきた。User Interview の手法も、Jobs to be Done のフレームも、Problem Statement の書き方も、相当の蓄積がある。地域には、この蓄積がまだ届いていない。
だから、シリーズの最初は Skill 1 を地域文脈に翻訳するところから始めたい。
このシリーズで書くこと
入り口記事のあとに、各 Skill を地域文脈に翻訳した記事を、使った順番で書いていく予定。
- Skill 1：住民の声を、地域課題の定義に変換する — マチつく／コミュマネの実務として（次回）
- Skill 2〜6：実際に地域プロジェクトで使ったタイミングで、ケースとセットで書く
「フレームの一覧化」を先にやらないのは、カタログ化したフレームは使われないという経験則から。使ってから書く順番のほうが、読者にとっても自分にとっても効く。
2026 年のローカルに、PdM Playbook が効く理由
最後に、なぜいまこのフレームなのか。
AI の進化で、個人が動かせるプロジェクトの上限が、明確に上がった。声を集めて、構造化して、Design Doc を書いて、仕様に落として、AI に実装させる、までを一人で抜けられる。
地域プロジェクトは、これまで「人手が足りない」「予算がない」「専門家がいない」で止まっていた。PdM Playbook の6つの Skill を、AI を相棒にして地域内で回せるようになると、この壁が一段下がる。
そして、これが回るようになれば、僕みたいな外部のプロダクトマネージャーが深く関わり続ける必要が、いまより減る。地域が自走するために、プロダクトマネージャーの動き方を地域に置いて帰る。それが 2026 年のローカルで、このフレームを翻訳する意味だ。
この記事について
このシリーズは、PdM Playbook（hico-mrmgn / 2026）を地域文脈に翻訳する試みとして書いている。元のリポジトリは Web プロダクトのプロダクトマネージャー向けに書いたものだが、各 Skill には地域でも通用する構造があると考えている。