日本のPMのための実践メディア ── AI時代の実務に効く、読む・使う・試すを一つに。
ソウ著者・編集長
Query ownership:PM Compassは評価方法と意思決定プロセスを扱います。ベンダー一覧、製品比較、おすすめ、ランキング、価格、口コミ、software-specific TCOはSaaS Radarの担当です。

Practice Playbooks

評価後の運用まで進める

10カテゴリすべてで、選定評価だけでなくpreflight・運用手順・残す証拠・failure signalまで実務プレイブック化しています。

PM向けツール導入 実務プレイブックを見る →

Saved Workflow

Framework → PoC → Playbookを保存して再開する

カテゴリ単位で3段階の参照と最終stageだけをこの端末に保存します。候補製品名、評価点、PoC結果、Evidence本文は保存しません。

Saved Workflowを開く →

10カテゴリを表示中

Product AnalyticsOwner: PM-CompassVendor handoff: SaaS Radar

Product Analytics

PMのJob: プロダクト仮説をイベント設計・分析・意思決定まで再現可能な運用にする

最重要の判断: PMがセルフサービス分析を継続しても、計測品質と定義の一貫性を保てるか

評価基準(100点)

  1. 計測モデル・Taxonomy適合 — 25点
    主要5〜10イベントとpropertyをtracking planとして定義し、命名・型・変更フローまで再現できる
  2. Identity・データモデル — 20点
    匿名→ログイン、複数device、account/workspace単位の分析を自社ケースで検証できる
  3. PMセルフサービス分析 — 20点
    Activation、Retention、Funnel、Cohortの主要問いをPM自身が再現できる
  4. Data governance・Privacy — 20点
    schema validation、権限、PII制御、変更履歴、データ保持方針を確認できる
  5. 運用・定着コスト — 15点
    instrumentation review、教育、問い合わせ、schema maintenanceのownerと工数を見積もれる
PoCで確認すること
  • 本番に近い5〜10イベントを計測し、欠損・型違い・重複を検出する
  • 匿名ユーザーからログイン後へのidentity mergeを実データで確認する
  • PMが3つの主要プロダクト質問を自力で分析し、再現手順を残す
ガバナンス確認
  • tracking planの承認者と変更フロー
  • PII送信禁止・maskingルール
  • event/propertyの廃止と互換性ルール
導入後の定着シグナル
  • PMが週次意思決定で分析を使う
  • 定義済みeventの再利用率が上がる
  • 分析依頼の待ち時間が減る
更新・撤退を疑うシグナル
  • taxonomy driftが継続する
  • PMが結局SQL/分析担当へ依存する
  • 計測・権限運用コストが便益を上回る

Primary query: PM Product Analytics ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

User ResearchOwner: PM-CompassVendor handoff: SaaS Radar

User Research

PMのJob: リサーチ計画から発言・証拠・示唆・意思決定まで追跡可能にする

最重要の判断: 調査量が増えても、一次証拠と示唆のつながりを失わずチームで再利用できるか

評価基準(100点)

  1. Research workflow適合 — 20点
    計画、対象者、質問、記録、分析、共有まで自社フローで無理なくつながる
  2. Evidence traceability — 25点
    示唆から原発言・動画・note・対象segmentへ戻れる
  3. Synthesis・共同編集 — 20点
    tagging、theme化、重複統合、レビューを複数PM/UXRで再現できる
  4. Consent・Privacy・Retention — 20点
    同意、アクセス権、削除、保持期間、機微情報の扱いを運用できる
  5. 再利用・定着 — 15点
    過去researchの検索・再利用ができ、同じ質問の再調査を減らせる
PoCで確認すること
  • 既存インタビュー3〜5件を取り込み、示唆から原発言まで逆引きする
  • 同じテーマを別担当者が再分析し、結論差分と根拠をレビューする
  • 削除依頼を想定し、対象者単位でデータを特定・削除できるか確認する
ガバナンス確認
  • 同意取得の記録
  • research participant単位の削除手順
  • AI要約に送信するデータ範囲と権限
導入後の定着シグナル
  • 過去researchの引用率が上がる
  • 意思決定文書に一次証拠が紐づく
  • 重複researchが減る
更新・撤退を疑うシグナル
  • 要約だけが残り一次証拠へ戻れない
  • 機微情報の権限管理が運用できない
  • repository入力が定着しない

Primary query: PM User Research ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

RoadmapOwner: PM-CompassVendor handoff: SaaS Radar

Roadmap

PMのJob: 戦略・成果・優先順位・依存関係を、約束日一覧ではなく意思決定として共有する

最重要の判断: 複数チームで更新しても、なぜこの優先順位なのかを根拠付きで説明できるか

評価基準(100点)

  1. Outcome・Strategy接続 — 25点
    objective→outcome→initiative→work itemの関係を自社の粒度で表現できる
  2. 優先順位の根拠追跡 — 20点
    score、顧客証拠、metric、decision logをroadmap itemへ紐づけられる
  3. Stakeholder view — 20点
    経営、営業、開発向けに情報量を変えて同じ正本から共有できる
  4. Dependency・Portfolio governance — 20点
    チーム横断依存、capacity、risk、confidenceを可視化できる
  5. 更新・定着コスト — 15点
    source of truthが二重化せず、週次更新を継続できる
PoCで確認すること
  • 現行roadmapを20〜30 item移し、戦略・outcome・根拠を欠落なく表現する
  • 経営向けと開発向けの2 viewを同じデータから作る
  • 優先順位変更1件をdecision logと証拠まで追跡する
ガバナンス確認
  • roadmap更新権限
  • 公開範囲と機密情報
  • date commitmentとforecastの表現ルール
導入後の定着シグナル
  • roadmap会議で根拠説明時間が短くなる
  • 同じroadmapの複製が減る
  • 変更理由が後から追える
更新・撤退を疑うシグナル
  • 日付とfeature一覧だけに戻る
  • Jira等との二重入力が増える
  • stakeholderごとに別正本が生まれる

Primary query: PM Roadmap ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

Feature FlagOwner: PM-CompassVendor handoff: SaaS Radar

Feature Flag

PMのJob: リリースと公開を分離し、段階展開・停止・実験を安全に運用する

最重要の判断: 本番障害時のkill switchから長期flag cleanupまで、開発とPMが同じルールで運用できるか

評価基準(100点)

  1. Runtime・SDK適合 — 25点
    主要runtimeで評価遅延・fallback・offline時挙動を検証できる
  2. Targeting・Evaluation context — 20点
    user/account/environment等のcontextを意図通りに評価し監査できる
  3. Safety・Kill switch・Audit — 25点
    緊急停止、権限、approval、change history、default値を事故シナリオで確認できる
  4. Experiment measurement — 15点
    flag exposureと実験metricを正しく結び、重複計測を避けられる
  5. Flag lifecycle・Tech debt — 15点
    owner、expiry、cleanup、stale flag検出を運用に組み込める
PoCで確認すること
  • 1機能を段階展開し、targetingとfallbackを複数環境で確認する
  • 障害を想定して権限者が即時停止し、監査ログを確認する
  • 期限切れflagを検出して削除までの運用時間を測る
ガバナンス確認
  • production変更権限
  • 緊急停止の責任者
  • flag owner・expiry・cleanup SLA
導入後の定着シグナル
  • release rollbackのMTTRが下がる
  • 段階展開が標準化する
  • stale flag比率が増えない
更新・撤退を疑うシグナル
  • SDK障害が本体可用性へ影響する
  • 権限が広すぎる
  • flagが増え続けcleanupされない

Primary query: PM Feature Flag ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

AI EvalsOwner: PM-CompassVendor handoff: SaaS Radar

AI Evals

PMのJob: AI機能の品質基準を実例・grader・人間レビュー・回帰テストとして継続運用する

最重要の判断: モデルやpromptが変わっても、品質劣化と新しいfailure modeを継続的に検出できるか

評価基準(100点)

  1. Dataset・Versioning — 20点
    実ユーザー由来case、edge case、期待値、dataset versionを再現可能に管理できる
  2. Grader・Human calibration — 25点
    deterministic/LLM/human graderを組み合わせ、専門家レビューでgrader driftを点検できる
  3. Trace・Failure analysis — 20点
    input/output/tool call/latency/costとfailure taxonomyを同じrunで追える
  4. Regression・CI — 20点
    model/prompt/tool変更時に基準datasetを自動再実行しrelease gateへ接続できる
  5. Cost・Security・Operational fit — 15点
    eval実行コスト、機密データ、retention、rate limitを本番運用前提で見積もれる
PoCで確認すること
  • 実ユーザーcaseとedge caseを含む30〜50件でbaselineを作る
  • LLM graderと人間評価の不一致をサンプリングして理由を分類する
  • promptまたはmodelを1回変更し、CIで回帰差分を検出する
ガバナンス確認
  • golden datasetの変更承認
  • grader prompt/modelのversion管理
  • 機密prompt・responseの保持期間
導入後の定着シグナル
  • release判断にeval差分が使われる
  • 本番failureがdatasetへ戻る
  • 人間レビュー対象を高リスクcaseへ集中できる
更新・撤退を疑うシグナル
  • scoreだけ上がり実ユーザー品質と連動しない
  • grader driftを検知できない
  • evalコストが高く継続実行されない

Primary query: PM AI Evals ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

Feedback ManagementOwner: PM-CompassVendor handoff: SaaS Radar

Feedback Management

PMのJob: 複数チャネルの顧客フィードバックを証拠付きで統合し、優先順位と顧客への返答へつなぐ

最重要の判断: AI要約が増えても、元の顧客発言・segment・product decisionとの対応を失わないか

評価基準(100点)

  1. Ingestion coverage — 20点
    support、sales、interview、survey等の主要チャネルを欠落・遅延なく取り込める
  2. Identity・Deduplication — 15点
    同一顧客・account・同一要望の重複を統合し、segment別に集計できる
  3. Synthesis・Evidence traceability — 25点
    theme/要約から原文、source、顧客、時点へ戻れ、AI分類の誤りを修正できる
  4. Decision・Closed loop — 20点
    feedback→opportunity→decision→status→顧客返答を追跡できる
  5. Privacy・Governance — 20点
    機微情報、retention、権限、AI処理範囲をチャネル横断で統制できる
PoCで確認すること
  • 3チャネルから100件程度を取り込み、重複とtheme分類を確認する
  • 重要theme 5件で要約から原文・顧客・sourceへ逆引きする
  • 1件をdecisionと顧客返答までclosed loopで流す
ガバナンス確認
  • 顧客データのアクセス権
  • AI分類・要約のhuman correction
  • 削除・retentionポリシー
導入後の定着シグナル
  • feedbackからdecisionまでの時間が短くなる
  • 同じ要望の重複集計が減る
  • 顧客へ返答できた比率が上がる
更新・撤退を疑うシグナル
  • AI themeだけ残り原文へ戻れない
  • identity統合が不正確
  • ingestionの欠落で現場が別台帳を使い続ける

Primary query: PM Feedback Management ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

ExperimentationOwner: PM-CompassVendor handoff: SaaS Radar

Experimentation

PMのJob: 仮説・対象・Primary/Guardrail metric・停止条件を事前固定し、実験結果を再現可能な意思決定へ変える

最重要の判断: 施策の差を因果効果として信頼できる形で測り、結果を見てから判定基準を変えずに意思決定できるか

評価基準(100点)

  1. Randomization・Exposure integrity — 25点
    bucketing、exposure logging、Sample Ratio Mismatch、mutual exclusionを検証し、対照群と処置群の割当品質を確認できる
  2. Metric・Guardrail design — 20点
    Primary、Guardrail、data quality/debug metricを事前定義し、同じmetric definitionを継続利用できる
  3. Statistical decision quality — 25点
    sample size、power、confidence interval、有意性、停止条件を実験開始前に説明し、結果画面で追跡できる
  4. Experiment governance・Reproducibility — 15点
    仮説、対象、variant、metric、設定変更、結果、decisionをversion付きで再現できる
  5. PM self-service・Decision workflow — 15点
    PMが設定から結果解釈・decision logまで進め、分析担当への定常依存を減らせる
PoCで確認すること
  • A/Aまたは低リスク実験を実行し、exposure割合とSRM検知を確認する
  • Primary/Guardrail metric、必要sample、実行期間、Go/No-Go条件を開始前に固定する
  • 終了後に別担当者が設定・metric version・結果から同じ結論を再現する
ガバナンス確認
  • experiment ownerと開始/停止承認
  • metric definitionと分析queryのversion管理
  • peeking・再実験・早期停止ルール
導入後の定着シグナル
  • 成功条件とGuardrailを事前登録する実験比率が上がる
  • SRM等の無効実験を意思決定前に止められる
  • decision logから実験証拠へ戻れる
更新・撤退を疑うシグナル
  • exposure mismatchやmetric driftを検知できない
  • 有意差だけを追いGuardrailを無視する運用になる
  • 実験設定・分析が専門担当のボトルネックになる

Primary query: PM Experimentation ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

Session Replay & UX AnalyticsOwner: PM-CompassVendor handoff: SaaS Radar

Session Replay & UX Analytics

PMのJob: 定量指標で見えた摩擦を実セッションの行動証拠へ戻し、再現・仮説・改善判断までつなぐ

最重要の判断: 行動再現性を上げながら、入力値や機微情報を過剰収集せず安全に運用できるか

評価基準(100点)

  1. Replay fidelity・Debug context — 25点
    主要画面・SPA遷移・エラー前後の操作を再現し、時刻・URL・device等のcontextと一緒に確認できる
  2. Event・Metric correlation — 20点
    funnel drop、error、rage/dead click等の定量signalから該当sessionへ遷移し、同じidentity/sessionとして検証できる
  3. Privacy・Masking・Consent — 25点
    入力値、機微DOM、認証情報をmask/excludeし、同意・地域・roleに応じて収集範囲を制御できる
  4. Search・Segmentation・Evidence sharing — 15点
    segment、event、期間、error等で対象sessionを絞り、必要最小限の証拠をチームへ共有できる
  5. Collection performance・Retention — 15点
    収集によるperformance影響、sampling、retention、削除、保存コストを本番条件で見積もれる
PoCで確認すること
  • 既知の摩擦3件を再現し、event/errorから該当sessionへ逆引きする
  • 機微入力・認証情報・非公開DOMを使ってmask/excludeと権限差を確認する
  • 本番相当trafficで収集overhead、sampling、retention、削除手順を確認する
ガバナンス確認
  • capture allow/denyとmaskingルールのowner
  • session閲覧・共有・export権限
  • consent・retention・削除ポリシー
導入後の定着シグナル
  • PMが定量異常をsession証拠で検証する
  • issueや改善仮説にsession evidenceが紐づく
  • CS/開発の再現時間が短くなる
更新・撤退を疑うシグナル
  • replay欠損や再現誤差で証拠として信頼できない
  • masking維持が難しく機微情報リスクが残る
  • 収集performance・保存コストが改善価値を上回る

Primary query: PM Session Replay UX Analytics ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

Product Ops WorkflowOwner: PM-CompassVendor handoff: SaaS Radar

Product Ops Workflow

PMのJob: 要望・バグ・意思決定・実行依頼を一貫したintake→triage→owner→SLA→closed loopで流す

最重要の判断: 情報源が増えても入口・優先順位・責任者・完了条件を標準化し、二重台帳を増やさず運用できるか

評価基準(100点)

  1. Multi-channel intake・Normalization — 20点
    Slack、support、フォーム、社内依頼等の入口から必要fieldを揃え、同じschemaへ正規化できる
  2. Triage・Routing・Deduplication — 25点
    priority、team、owner、duplicateをruleまたはhuman reviewで一貫して決定し、根拠を確認できる
  3. Workflow policy・SLA・Ownership — 20点
    受付→確認→実行→完了のstatus、SLA、responsibility、exceptionをチーム横断で運用できる
  4. Automation・Integration・Audit — 20点
    automationのtrigger/action/overrideを追跡し、主要systemとの二重入力を減らせる
  5. Adoption・Change cost — 15点
    現場が既存チャネルから大きく離れず利用でき、workflow変更を中央管理者だけに依存せず維持できる
PoCで確認すること
  • 3チャネルから20件程度の依頼を取り込み、field正規化とduplicate統合を確認する
  • priority・routing・SLA ruleを適用し、例外1件をhuman overrideしてaudit trailを確認する
  • 1件をrequester通知までclosed loopで流し、手作業と二重入力の回数を測る
ガバナンス確認
  • workflow/routing rule変更権限
  • automation overrideとaudit policy
  • 機密requestの閲覧・通知範囲
導入後の定着シグナル
  • untriaged agingが短くなる
  • 重複・手動reroutingが減る
  • requesterがstatusと完了を追える比率が上がる
更新・撤退を疑うシグナル
  • 別spreadsheetやchannel台帳が残り続ける
  • automation誤配信を監査・修正できない
  • workflow customizationが管理者ボトルネックになる

Primary query: PM Product Ops Workflow ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

AI ObservabilityOwner: PM-CompassVendor handoff: SaaS Radar

AI Observability

PMのJob: 本番AIのtrace・latency・cost・tool call・feedback・safety signalを一つの障害/改善ループへつなぐ

最重要の判断: 本番品質が悪化した時に、どの入力・model/prompt・tool・latency/cost・guardrailが原因か短時間で切り分けられるか

評価基準(100点)

  1. Trace・Context correlation — 25点
    request→model/prompt version→handoff→tool call→responseまで一つのtraceで追い、関連user/session/contextへ戻れる
  2. Quality・Safety production signals — 20点
    user feedback、refusal、guardrail、fallback、failure taxonomy等を本番traceへ関連付けてsegment別に監視できる
  3. Latency・Cost・Reliability monitoring — 20点
    model/tool別latency、token/cost、error、retry、timeoutを可視化し、regressionやrunawayを検知できる
  4. Privacy・Retention・Access — 20点
    prompt/response/tool payloadのredaction、retention、role access、exportを機密度に応じて制御できる
  5. Incident→Eval feedback loop — 15点
    本番failureをissue・eval dataset・回帰caseへ戻し、修正後の再評価まで追跡できる
PoCで確認すること
  • 1つのagent/requestをmodelとtool handoffまでtraceし、意図したcontextが揃うか確認する
  • latency増大、tool failure、guardrail blockを模擬し、alertから原因traceまで辿る
  • 本番failure相当のtraceをredactしてeval caseまたはissueへ戻し、再検証する
ガバナンス確認
  • trace内PII/secretのredaction rule
  • trace閲覧・export・retention権限
  • alert severity・owner・incident escalation policy
導入後の定着シグナル
  • AI incidentのMTTRが下がる
  • 本番failureがeval datasetへ継続的に戻る
  • cost/latency regressionを大規模影響前に検知できる
更新・撤退を疑うシグナル
  • model/tool/versionを跨いでtrace相関できない
  • prompt/responseから機密情報が露出する
  • telemetry noiseが多くactionable alertにならない

Primary query: PM AI Observability ツール 選定 評価基準

このカテゴリのスコアカードpreset・PoC設計を見る →

該当する評価フレームがありません。