業法改正のニュースが流れた日
ある日、保険業界の業法改正のニュースが流れた。
それまで保険業界の B2B SaaS の現場で議論されていた要件 ―― 顧客本位の業務運営、業務品質評価制度への対応、AI を使った契約手続きの監査、全件チェックの体制構築 ―― が、ニュースが流れた瞬間から 「やった方がいい」から「やらないと立ち行かない」に位置づけが変わった。
業界全体のプレイヤーが、同じ方向に同時に動き始めた。
僕はその数週間後、移住推進の仕事のなかで、別の "外部圧" に出くわした。総務省の特別交付税の要綱が変わって、自治体側の予算配分の前提が動いていた。これも、全国の自治体が同じタイミングで動かざるを得ない外部圧だ。
別々の領域で同じ現象を見て、僕は気づいた。
保険業界の「業法改正」、地域であった「補助金 / 交付税の要綱改定」。どちらも "制度起点で要件が動く" 現象だ。
このメディアでは、Web プロダクトのつくり方を地域に持ち込む話をずっと書いている。今回はその逆 ―― 地域の現場で見えている現象を、B2B SaaS の枠組みと並べて構造化する 試みになる。
"制度起点プロダクト" という分類
ふつう、プロダクトの動因はこう分類される。
- 顧客起点 : 顧客の困りごとから機能を作る
- 競合起点 : 競合がやっているから追随する
- 技術起点 : 新しい技術が出たから取り入れる
この 3 つはどれも、プロダクト側に主導権がある。
これに対して、制度起点 は違う。動因は外部の制度変更にある。プロダクト側は「制度がこう変わったから、要件をこう動かさないといけない」と、ほぼ受動的に応じる。
| 分類 | 動因 | 反応速度の競争 |
|---|---|---|
| 顧客起点 | 顧客の声 | 顧客の声を拾う速さ |
| 競合起点 | 他社の動き | 真似する速さ |
| 技術起点 | 新技術 | 取り込む速さ |
| 制度起点 | 制度改定 | 制度を読む速さ |
制度起点だと、業界全プレイヤーが同じスタートラインに立つ。差がつくのは 「制度を読む速さ」「制度を要件に翻訳する速さ」 だけだ。
保険業法 vs 自治体交付税 ―― 同じ構造を 2 軸で並べる
保険業法改正と、自治体の交付税要綱改定を、同じ表で並べてみる。
| 軸 | 保険業法改正 | 自治体交付税要綱改定 |
|---|---|---|
| 起点 | 金融庁の改正通知 | 総務省の要綱改定 |
| 影響範囲 | 業界の全プレイヤー（保険会社・代理店・SaaS） | 全国の自治体 |
| 求められる速度 | 改正施行日まで | 補正予算編成サイクル |
| 反応の遅延が招くこと | 業務停止 / 業界からの脱落 | 予算が降りない / 事業が動かない |
| 派生する新要件 | 全件チェック / 監査ログ / AI ガイドライン | 移住コーディネーター / 制度設計費 / 受入伴走 |
| 反応した側に開ける商機 | 業界全体の業務改善需要 | 全国の自治体への一括支援需要 |
並べると、構造が完全に同型なのがわかる。
これは偶然ではない。制度起点で要件が動く市場は、業界・地域問わず、同じ動き方をする。
制度起点の場合に PdM がやるべき 3 つのこと
僕がいま現場で意識しているのは、3 つだ。
1. 制度を、施行前に読む
業法改正にしても要綱改定にしても、ニュースになるのは "施行決定" のタイミングだ。けれど、行政の世界には ドラフト段階 / パブリックコメント段階 / 施行決定段階 の 3 段階がある。
ニュースになる前に、ドラフト段階で要件を起こせるかどうかで、競合に対して 3〜6 ヶ月のリードタイムが取れる。
これは、
- 業界団体の議事録を読む
- 行政の審議会の資料を読む
- 関係省庁の発表をウォッチする
…という、地味だが効く仕事だ。PdM の手元に持っておくべき "情報源リスト" は、顧客の声のチャネルだけではない。
2. 顧客より早く動く
制度が変わると、顧客はだいたい "困ってから" 動く。困る前に「これに困りますよね」と提案できると、PdM は顧客より半歩前に立てる。
「困ってから動く」型の競合と並べたとき、半歩前にいる PdM のプロダクトは、
- 提案の主導権を握れる
- 業界の語彙を作る側に回れる
- 顧客の業務設計に組み込まれやすい
…という違いが出る。これは、顧客起点プロダクトでは起きにくい競合優位だ。
3. 機能を、業界共通言語に揃える
制度起点で動く要件は、業界の全プレイヤーが対応する。だから、要件を 自社固有の機能名で語るのではなく、業界の共通言語で語る ことが効く。
たとえば、保険業界で「全件チェック」と言ったら、業界の人は一発で何のことかわかる。これを自社プロダクトで「○○管理機能」と独自命名すると、業界の語彙と接続できず、提案の押しが弱くなる。
地域で言えば、自治体相手に「移住コーディネーター業務支援」と言うと文脈が伝わるが、独自に「○○マネジメントサービス」と命名すると伝わらない。
業界の語彙に揃えること は、要件設計の話に見えて、実は GTM（市場参入戦略）の話でもある。
制度起点プロダクトの "弱点"
ここまで書いたが、制度起点プロダクトには弱点もある。
弱点 1: 制度依存
制度が変わったから要件が動く、ということは、制度が変わらない時期は、要件の動因が乏しいということでもある。
これに対しては、
- 顧客起点の動因も並行で持つ（業務改善 / コスト削減 / UX）
- 次の制度改定の方向を、業界より早く読む
- 制度起点で動かないプレイヤーへの提案を温める
…で備える。
弱点 2: 業界全体が同じ方向に走る
業界の全プレイヤーが同じ要件に同時に動くと、差別化は 「速さ」と「深さ」 にしか出ない。
これは、サウナのような市場（全員が似たような店を作る）と似ている。差は、空間設計の深さや、運営の作法の細部に出る。プロダクトも同じで、要件は同じでも、実装の質と業務統合の深さで差がつく。
弱点 3: 制度起点だけで動くと、顧客の声に耳が遠くなる
これが一番怖い。
制度を読む仕事は楽しい。要件が明確に降りてくるから、迷いが少ない。けれど、制度起点だけで動いていると、顧客の声を拾うチャネルが弱る。結果として、制度では拾われない "現場の本当の困りごと" を取りこぼす。
PdM の手元では、制度起点と顧客起点を 常に並列で動かす ことが必要になる。
自治体側で起きていることは、ほぼ同じだ
最後に、自治体側の話に戻る。
自治体の動きを観察していると、
- 交付税要綱の改定が、自治体側の予算配分を動かす
- 動かされた予算が、地域おこし協力隊や移住コーディネーターの募集枠を生む
- けれど、要件が降りてきた段階で「何をする募集なのか」が決まっていない
…という、まさに制度起点の B2B SaaS と同じパターンが現れる。
ここで地域側で必要なのは、
- 要綱改定を、施行前に読む（行政の発表をウォッチ）
- 自治体より早く「これに使えますね」と提案する
- 要件を、自治体の語彙（特別交付税 / 補正予算 / コーディネーター）に揃える
…という、B2B SaaS と同じ動き方になる。
Skill 2 の記事 で書いた "自治体ヒアリングはユーザーインタビューだ" と並べて、ここで言えるのは、自治体側のプロジェクトは、典型的な "制度起点プロダクト" だ ということだ。
開いている問い
「制度起点」という分類が成立するなら、これに特化した PdM の動き方があってもいいはずだ。
僕の仮説は、こうなる。
制度起点の PdM は、"顧客の声を拾う" 比率を 5 割以下に下げて、"制度を読む" "業界の語彙を作る" "施行前に動く" の比率を 5 割以上にした方が、勝率が上がる
これは、Web プロダクトで言われる「顧客の声を最優先に」とは、明確に違う動き方だ。
地域でも、保険でも、教育でも、医療でも、制度の影響が強い領域では、こちらの動き方が必要になる。
これを framework として書き切るのが、次の宿題だと思っている。