自治体ヒアリングは、ユーザーインタビュー記録だ
このシリーズの 1 本目 PdM Playbook を、地域に翻訳する で、Web プロダクトの動き方を地域に翻訳する全体像を書いた。
その続編として、今回は Skill 2「顧客の声を構造化する」 を地域に翻訳する。
題材は、ここ数ヶ月で僕が同席した 4 件の自治体ヒアリングだ。それぞれ規模も予算もテーマも違う。けれど、PdM の語彙で並べ直すと、これは間違いなく "ユーザーインタビュー記録の集合" として読める。
これを構造化することで、
- 4 自治体それぞれが何に困っているのか
- 共通する未解決のコアは何か
- どの自治体から何の "打ち手" を試すべきか
が見えてくる。
顧客の声を構造化する 4 ステップ
PdM Playbook で僕が使っているのは、こういう順序だ。
- 症状を分離する — "困っている" の主語を、人 / 制度 / 予算 / 時間 のどれに置くか
- 原因仮説を立てる — その症状の "ボトルネック候補" を 3 つ書き出す
- 制約を明示する — 予算上限・期日・人員 ―― これを "プロダクトの非機能要件" として読む
- 解像度の差を測る — 複数の声を並べたとき、どこで差が出るか
順番に、4 自治体のヒアリングをこのフレームに通してみる。
Step 1: 症状を分離する
ヒアリングで出てきた "困りごと" を、主語別に分けると、こうなる。
| 自治体 | 主語 | 出てきた症状 |
|---|---|---|
| A 自治体 | 人 | 協力隊 2 名で定着率 50% |
| A 自治体 | 制度 | 移住施策未整備、パンフレットなし |
| A 自治体 | 予算 | 広告費に偏り、制度設計費が不足 |
| B 自治体 | 制度 | 協力隊のミッションが 2 系統 |
| B 自治体 | 予算 | 総額 200 万 (募集 170 / 研修 30) |
| C 自治体 | 制度 | 食 × ジオパークのお試しツアー設計 |
| C 自治体 | 予算 | ツアー 60 万 + サポート 200 万 |
| C 自治体 | 時間 | 夏の実施までに入札完了 |
| D 自治体 | (未整理) | ヒアリング段階の浅さ |
これを見て気づくのは、同じ「移住推進」というラベルの下に、まったく違う症状が並んでいることだ。
A は「人と制度」の話、B は「制度と予算」の話、C は「制度・予算・時間」が同時に走る話、D はまだ症状が出ていない段階。
Web プロダクトの世界で、ユーザーインタビューの最初にやるべきは「ペルソナの分解」だとよく言われる。同じ "ユーザー" のラベルでも、状況がここまで違えば、打ち手は全部違うはずだ。
Step 2: 原因仮説を立てる
それぞれの症状について、ボトルネック候補を 3 つ書き出してみる。
A 自治体: 協力隊定着率 50%
- 採用導線の精度（誰に届いているか）
- 受入オンボーディングの不在（着任後の最初の数ヶ月）
- ミッションの曖昧さ（業務未確定）
→ どれもありえる。これは 前の記事 で 4 層に分解した話とつながる。
B 自治体: 協力隊募集 200 万円・ミッション 2 系統
- 募集と研修の予算配分（170 : 30）が合っているか
- ミッション 2 系統の負荷バランス（事業承継 vs 観光協会配属）
- 募集媒体の選定
→ 予算配分の話に見えて、本質はミッション設計の話。
C 自治体: 食 × ジオパーク ツアー
- ツアー設計（コンパクト型の意味）
- 60 万円の使い道の優先順位
- ツアー後 30 日のフォロー設計
→ "コンパクト型" の解像度を上げないと、設計が散る。
D 自治体: (まだ症状が出ていない)
- そもそも何を解こうとしているか、関係者間で共通言語ができていない可能性
- ヒアリングの場 自体の設計が浅い可能性
- 担当者の情報が断片的な可能性
→ ここはまだ "顧客の声" が抽出されていない段階。インタビューのやり方から見直す対象。
Step 3: 制約を明示する
ヒアリングで出てくる "制約" は、Web プロダクトで言う非機能要件にあたる。これを抽出しておかないと、後で打ち手が制約に引っかかって動かなくなる。
| 自治体 | 予算 | 期日 | 人員 | その他 |
|---|---|---|---|---|
| A | 特別交付税 500 万 + 補正予算 | 10 月までにコーディネーター募集開始 | 担当 1 名 | 既存協力隊 2 名 |
| B | 総額 200 万 (170/30) | 2024 年 4 月〜2025 年 3 月 | 募集枠複数 | 広告費の天井 |
| C | 60 + 200 万 (税込) | 5 月中旬入札完了 / 夏実施 | 最大 10 名対応 | 食 + ジオパークの 2 軸 |
| D | (未確定) | (未確定) | (未確定) | (情報量不足) |
ここで重要なのは、「制約は声に出して言われない」 ことが多いという点だ。担当者が「予算 60 万」と言ったとき、その背後には議会の予算承認サイクル、自治体内部の決裁フロー、過去の支出実績との比較、複数年度の繰越可能性などがある。
PdM が解像度を上げるべきは、表に出る数字の裏にある "制約の連鎖" だ。
Step 4: 解像度の差を測る
4 自治体を並べたとき、どこで解像度に差が出るか。整理するとこうなる。
解像度マトリクス (◎=高い / ○=ある / △=浅い / ×=未抽出)
症状 原因仮説 制約 打ち手
A 自治体 ◎ ○ ◎ ○
B 自治体 ○ △ ◎ △
C 自治体 ○ △ ◎ △
D 自治体 △ × × ×
これを見ると、
- A 自治体は症状と制約まで見えていて、原因仮説と打ち手の解像度を上げる段階
- B / C 自治体は症状と制約は見えているが、原因仮説が浅く、打ち手の手前で止まっている
- D 自治体はまだヒアリングそのものをやり直す段階
…という見え方になる。
これは、Web プロダクトでユーザーインタビューを 10 件こなした後にやる "横断比較" と同じ作業だ。1 件ずつでは見えない "共通する未解決のコア" が、横断比較で初めて立ち上がる。
4 自治体に共通する "未解決のコア"
横断してみて、共通している声があった。
「採用 / 募集の入口は強化されているが、その後の設計が薄い」
- A: 採用したいが、定着しない
- B: 募集したいが、ミッション設計が後手
- C: ツアーで人を呼びたいが、ツアー後の伴走設計がない
- D: そもそも何を解くかの合意がない（= "募集" の手前）
つまり、自治体側の課題感は 「人を呼ぶ」段階で止まっていることが多くて、「呼んだ後、その人がどうなるか」を設計に組み込むという発想自体が、まだ標準ではない。
これは Web プロダクトで言うと、Acquisition は語彙があるが、Activation / Retention の語彙が薄い状態だ。
構造化の出口 ―― 次のアクション
このフレームを通すことで、次にすべきことが見える。
- A 自治体: 4 層分解の結果に沿って、受入・ミッション・暮らしの 3 層に予算を流す提案を作る
- B 自治体: 募集 / 研修の予算配分を、ミッション 2 系統別に再設計
- C 自治体: ツアー設計を MVP 一枚絵に落とす（次の記事 コンパクト型お試しツアーの MVP 設計 ）
- D 自治体: ヒアリングの場 自体の設計をやり直す（事前準備 → 当日 → 振り返り）
「自治体ヒアリングをユーザーインタビューとして読む」というだけで、ここまで次の一手が出てくる。
このフレームを使うときの注意
最後に、自治体ヒアリングをユーザーインタビューとして扱うときの注意点を 3 つ書いておく。
1. 「困りごと」と「要望」を分ける
担当者が「〜が欲しい」と言ったとき、それは要望であって、必ずしも困りごとではない。要望の背後にある困りごとを取り出すのが、PdM の仕事だ。
2. 制約は数字の裏まで聞く
「予算 60 万」だけでは設計に使えない。「その 60 万はどの費目から出ているのか」「来年度も使えるのか」「予算名目は何か」までヒアリングする。
3. 自治体ごとに比較しない、横断で比較する
A と B を直接比較しても、規模も予算も違うから意味は薄い。代わりに、A / B / C / D を並べたときに 「共通する未解決のコア」 を取り出すことに使う。
開いている問い
PdM Playbook を地域に翻訳するシリーズは、これで Skill 2 まで来た。
次は Skill 3「仮説を一枚絵に落とす」 を、C 自治体のお試しツアー設計に当てはめて書く予定にしている。ヒアリングで構造化した内容が、いよいよ "プロトタイプ" に変わる段階だ。