CS & Product アラインメント用語集：CSチームとProductチームが合意すべき30の重要用語

中堅SaaS企業では、毎四半期のように同じシナリオが繰り返されます。Product Manager（PM）がCSM（Customer Success Manager）とのロードマップ会話の中で「ベータ」という言葉を使います。PMは社内テストを意味し、顧客向けのプレビューではないつもりです。しかしCSMは招待顧客向けプレビューと受け取ります。2週間後、CSMはARRの高いアカウントに「ベータに参加できる」と伝えます。PMは寝耳に水です。いざその機能が利用できないと判明した顧客は混乱します。

誰も嘘をついていません。誰も間違えてもいません。同じ言葉を別の意味で使っていただけで、その亀裂が失敗を飲み込みました。

CSとProductのアラインメントが崩れたとき、プロセスが責められます。しかし原因はたいてい語彙にあります。2つのチームが同じフィードバックの儀式を行っても、まったく異なる結論に達することがあります。CSにとって「ロードマップ」とは確定したスケジュールを意味し、PMにとっては探索的な計画文書です。Salesにとって「オンボーディング完了」とはキックオフコールが終わったことを意味し、CSにとっては顧客が主要ユースケースを実際に運用し始めた状態を指します。CSMにとって「機能リクエスト」は緊急の顧客ニーズを意味し、PMにとっては未検証のシグナルに過ぎません。

この用語集は、CS・Product アラインメント コレクション全体の標準語彙層です。コレクション内の各記事は、用語を初めて紹介する際にここへリンクを張ります。実際の業務ツールとして活用してください。VP CSとHead of Productを同じ部屋に集め、この文書を開いて各セクションを一緒に確認してください。定義が現在と異なる用語があれば、それは語彙の不一致に偽装したアラインメントの課題です。CSとProductのミスアライメントのコストは、放置するたびに四半期ごとに複利で膨らみます。

CS・Product アラインメントで最も引用される用語

CS・Product アラインメントの崩壊に最も頻繁に登場する6つの用語と、定義の曖昧さが最も大きな運用上のダメージをもたらす場面を示します。

• NRR（Net Revenue Retention）： CSとProductが最終的に共有するノーススターメトリクス。CSとProductが優先順位について対立したとき、NRRへの影響が双方が受け入れられる判断基準になります。これが優先順位付けのインプットにどう変換されるかは ARRウェイト付きフィードバック を参照してください。
• JTBD（Jobs-to-be-Done）： 顧客の機能リクエストをPMが仕様化できる問題定義に変換するフレームワーク。JTBDを理解しているCSMはより良いVoCチケットを提出し、JTBDをCSMに教えるPMはより質の高いインプットを得られます。JTBDの完全な定義 を参照してください。
• MVP（Minimum Viable Product）： CSMがフレーミングなしに使うと顧客に最も誤解されやすい用語。MVPは学習のための手段であり、完成品ではありません。MVPテストに参加する顧客にはその区別を明示する必要があります。MVP を参照してください。
• Beta： CS・Product の接点における顧客の期待破壊の原因として最も多い単語。「ベータ」とは招待された顧客によるテストでフィードバック義務が伴うものです。「早期アクセス」でも「ほぼ完成」でもありません。ベータ を参照してください。
• NPS（Net Promoter Score）： CSMのフォローアップと組み合わせて初めて有用になる遅行シグナル。クローズドループパイプラインを持たない生のNPSはノイズです。NPS を参照してください。
• MoSCoW（Must / Should / Could / Won't）： PMがロードマップの確度を伝えるために使う優先順位付けフレームワーク。MoSCoWを理解しているCSMは、過大な約束をせずに顧客に「must」と「could」の正直な答えを返せます。関連するワークフローは ロードマップ と バックログ を参照してください。

---

この用語集の使い方

これは読み物ではありません。ファシリテーションツールです。

VP CSとHead of Productを集めて60分のセッションを開催してください。各セクションを順に確認します。各用語について、一つの質問をしてください。「現在、両チームが実際に使っている書面による合意済みの定義があるか？」もしあれば、ここに記載されている内容と一致しているか確認します。なければ、あるいは各チームが異なる答えを返すなら、次の四半期計画サイクル前に埋める価値のあるギャップを発見したことになります。

各用語には定義と一行の具体例があります。具体例は実際の中堅B2Bシナリオに用語を当てはめたもので、定義の抽象的な説明は顧客の状況に置き換えるまで同じに見えるからです。定義の不一致は具体的な場面で浮かび上がります。

各セクション見出しのアンカーIDを使って他の文書から個別の用語グループへリンクできます。新しいPMやCSMをオンボーディングするときは、入社1週目にこの用語集を送ってください。

では、未定義のまま放置すると最も危険な用語はどれでしょうか。ProductとEngineeringから始めましょう。CSが定義を共有するのではなく、思い込みで動きがちな領域です。

---

Product & Engineering 用語集

ProductとEngineeringが発信元の用語で、CSが理解できなければなりません。CSがこれらの定義を共有していない場合、顧客に過大な約束をするか（PMが確認していないスケジュールを確約する）、正式リリースを待ちすぎて戦略的アカウントへの事前案内が遅れるかのどちらかになります。

PM: Product Manager

プロダクトエリアのロードマップ、優先順位付け、デリバリーを担います。CS・Productの接点では、PMは構造化されたVoCインプットの主要な受け手であり、顧客のリクエストがバックログに入るかどうかの意思決定者です。PMが機能リクエストに「yes」と言うのは検討中を意味し、リリースの確約でも時期の確約でもありません。

例：CSMがワークフローのギャップを4つのアカウントに影響する問題としてエスカレーションします。PMはVoCチケットを確認し、バックログの優先順位と照らし合わせ、5営業日以内にバックログのステータス（デリバリー日ではなく）を回答します。

PMM: Product Marketing Manager

製品の変更を顧客向けの言語に翻訳します。リリースノート、アプリ内メッセージ、Sales enablementが該当します。CS・Productの接点では、PMMはProductが出荷するものとCSが顧客に伝えるものの間を架け橋する構造的な役割を果たします。PMMは意思決定後に起動するコミュニケーション機能ではなく、双方向の翻訳レイヤーです。

例：PMMはPMから技術的な機能仕様を受け取り、3つのアウトプットを作成します。CSへの事前ブリーフィング、アプリ内告知、外部向けリリースノート。それぞれの対象読者に合わせた内容です。

Engineering Manager（EM）

プロダクトロードマップを実行するエンジニアリングチームをリードします。CSがエスカレーションの複雑性やPMがコミットする前にEMの承認が必要なリクエストを上げた際に、接点で重要な役割を担います。EMはエンジニアリング側のリソース配分を担っており、PMはEMの同意なしにデリバリーのスケジュールを確約できません。

例：CSが顧客をブロックするインテグレーションのバグをエスカレーションします。PMはEMに振り、EMが2スプリントの修正サイクルを確認します。PMはその日のうちにCSにスケジュールを伝えます。

Product Designer

機能やフローのユーザーエクスペリエンスを担います。接点では、Product DesignerがCSMや顧客との同席セッション（ライドアロング）を実施し、利用データには現れないワークフローのギャップを発見します。顧客との直接的な接触が設計判断を早期に形成し、GA後の「なぜこうなっているのか？」というフィードバックサイクルを減らします。

例：Product Designerが新しいレポートモジュールのCSM主導のオンボーディングコールに2回参加します。観察から利用データでは見つからない3つのUIの摩擦ポイントが明らかになり、GAの前に組み込まれます。

JTBD: Jobs-to-be-Done

顧客が要求した機能ではなく、顧客が達成しようとしていること（「ジョブ」）を定義するフレームワーク。Jobs-to-be-Done は、顧客が特定のジョブを完遂するために製品を「雇用」するという考え方に基づいており、クレイトン・クリステンセンのイノベーション研究と密接に関連しています。CSデータはB2B企業における最も豊富な生のJTBDシグナルの源泉の一つです。顧客が回避策を説明するたびにCSMはジョブを聞いています。つまり、顧客は製品にできないことと自分がやろうとしていることを明確に伝えているのです。運用上のアプローチについては CSデータからのJobs-to-be-Done を参照してください。

例：顧客がデータをスプレッドシートにエクスポートして手動で計算し続けています。機能リクエストは「エクスポートの改善」です。JTBDのフレーミング：顧客はプラットフォームを離れずにカスタムの日付範囲計算を行う必要があります。

MVP: Minimum Viable Product

顧客のテストと学習を生み出せる、機能の最小限のバージョン。MVP は、将来の開発のためにフィードバックを提供する初期顧客が使えるだけの機能を持つバージョンを表すために作られた言葉です。MVPは学習のための手段であり、完成品ではありません。ベータや早期アクセスプログラムでは、CSがMVPテストに参加する顧客との関係を管理し、「MVP」の意味（具体的には含まれていないもの）を参加者に伝える責任を負います。

例：レポートMVPが3種類のチャートタイプでリリースされます。CSはMVPコホートの4つのアカウントに事前ブリーフィングします。機能はライブになっており、次のスプリントでさらに2種類のチャートタイプが追加される予定で、フィードバックはPMMのフィードバックチャンネルに送るよう伝えます。

GA: General Availability

機能がすべての顧客に完全リリースされる時点。GAはCSのコミュニケーション責任を発動させます。トレーニング、アプリ内ガイダンス、リリースノート、ARRの高いアカウントやリスクのあるアカウントへのCSMによるプロアクティブなアウトリーチが含まれます。「GA」は顧客が認識していることを意味しません。製品が準備完了でコミュニケーションの責任が始まることを意味します。

例：機能が火曜日にGAに達します。PMMが水曜日にリリースノートを公開します。CSの事前ブリーフィングは月曜日にすべてのCSMに届きます。戦略的アカウントは木曜日までに直接CSMからアウトリーチを受けます。

Beta

GA前の段階で、選ばれた顧客グループがテストとフィードバックのために機能を利用できます。ベータプログラムはProductと CS が共同で所有します（機能の準備状況はProduct、顧客の選定と関係管理はCS）。CSは最も大声で求めた顧客ではなく、アカウントのヘルス、ARR、建設的なフィードバックを提供できる可能性に基づいて参加者を選定します。顧客ベータプログラムの運用 ガイドで選定と管理の全プロセスを説明しています。

例：8つのアカウントがベータプログラムに選定されます。CSが関係とフィードバック収集を担います。Productが機能とフィードバックへの対応を担います。PMMが参加者向けのコミュニケーションテンプレートを担います。

Alpha

ベータより早い段階で、通常は社内または1〜3社のデザインパートナー顧客との間で行われます。アルファ参加者は通常、PMが直接関与する形でCSまたはPMMが調達・管理します。アルファのフィードバックは、広範なテスト向けに構築される前に機能を形成します。ベータのフィードバックはGA前に形成します。

例：深い製品知識を持つデザインパートナー顧客1社が、新しい自動化エンジンのアルファに参加します。PMがセッションを進めます。CSが関係を維持し、顧客にこれがベータ前であることを理解させます。

RC: Release Candidate

機能が完成しており、バグが発見されない限りGAになる予定のビルドです。CSはRCの段階で戦略的アカウントに事前ブリーフィングを行い、GAのコミュニケーション展開に向けてアカウントチームを準備させることがあります。RCのステータスは「新機能なし」を意味し、「バグなし」ではありません。

例：インテグレーションモジュールが金曜日にRCに達します。CSはその機能に最も依存している3つのアカウントに連絡を取り、チームを準備させます。GAは翌週の火曜日にリリースされます。

---

キーファクト：未定義用語のコスト

• CS・Productの用語アラインメントが高い B2B SaaS 企業は、GA後の機能定着が23%速いと報告されています。機能がリリースされた理由と内容を理解したCSMが一貫して伝えるためです（ProductPlan 2024年プロダクトマネジメントベンチマーク）。
• SaaS企業の61%は「機能定着」とは何かについて、CS・Productの接点における主要なGA後メトリクスである書面による共通定義を持っていません（Pendo プロダクトリーダーシップ実態調査）。
• 中堅CSチームの54%が、新機能についてProductやPMMからの事前ブリーフィングではなく、変更履歴やアプリ内バナーを通じて顧客と同時に知ります（ChurnZero 年次CSベンチマーク）。

---

CS & 顧客用語集

これらはCSが発信元の用語で、Productが理解できなければなりません。Productがこれらの定義を共有していない場合、PMはどの顧客がリスクにさらされているか、その理由を理解せずに優先順位を決めることになります。

CSM: Customer Success Manager

セール後の顧客関係を担います。主な責任はリテンションとヘルスです。CS・Productの接点では、CSMは定性的な顧客シグナルの最前線収集者です。つまり、顧客ができないこと、やらないこと、または回避策を見つけたことを聞く人物です。CSMのシグナルはフィードバックパイプラインの原材料です。

例：CSMの特定業界の5つのアカウントが同じオンボーディングの摩擦を共有しています。彼女はそのパターンを文書化し、共通フィードバック分類法を使って分類し、そのプロダクトエリアを担当するPMに振ります。

Customer Health Score（ヘルススコア）

利用データ、サポートチケット量、NPSまたはCSATスコア、エンゲージメント頻度、CSMの感触を組み合わせたアカウントのリスクプロファイルを集計した複合的な数値シグナル。Productチームはヘルススコアを優先順位付けのインプットの一つとして使います。ある機能エリアが低いヘルススコアと相関している場合、それは即座の改善候補です。両方のデータストリームが運用上どのようにつながるかは プロダクト利用データと顧客ヘルスダッシュボード を参照してください。

例：インテグレーションモジュールが一貫して60以下のヘルススコアと相関しています。PMはCS Opsと四半期ごとにこのシグナルを確認し、インテグレーション関連のフィードバックを他のカテゴリーより高く重みづけするために使います。

Customer Advocacy（顧客アドボカシー）

顧客が製品を公開的にサポートする意欲：レファレンスコール、ケーススタディ、G2レビュー、アドバイザリーボードへの参加。高いアドボカシーを持つ顧客はベータプログラムや共同デザインにとって特に価値があります。不完全なビルドを吸収しながら建設的なフィードバックを提供できるほど、製品に投資しているからです。

例：CSMが今後のベータのために高いアドボカシーを持つ3つのアカウントを特定します。最も高いARRだからではなく、レファレンスコールを完了しG2レビューを提出したという、真の関与のシグナルがあるため選ばれます。

NPS: Net Promoter Score

製品を推薦する可能性を測る一問のサーベイメトリクス。Net Promoter Score はフレッド・ライクヘルドが開発し、2003年のハーバード・ビジネス・レビューの記事で初めて発表されました。遅行のヘルスシグナルや方向性のトレンド指標として有用ですが、リアルタイムのフィードバックメカニズムとしては不十分です。フォローアップパイプラインを持たないNPSはノイズです。CSMによるクローズドループフォローアップを持つNPSが定性シグナルになります。

例：顧客がNPS 5（批判者）を提出します。CSMがアラートを受け取り、48時間以内に連絡を取り、レポートモジュールの特定の摩擦を掘り起こします。その摩擦はタグ付きでウェイト付けされた項目としてVoCパイプラインに入ります。

Advisory Board（アドバイザリーボード）

通常8〜15名の上位顧客ステークホルダーからなる小グループが四半期ごとにロードマップの方向性に関する戦略的なインプットを提供します。アドバイザリーボードのメンバーシップはCSが管理し、アジェンダはProductとPMMと共同で所有します。アドバイザリーボードは顧客サポートセッションではなく、翌四半期のロードマップ優先順位を形成するインプットセッションです。

例：Q2のアドバイザリーボードには8つの戦略的アカウントのVP Opsが参加します。Productが3つのロードマップオプションを提示します。CSがディスカッションをファシリテートします。PMMがアウトプットを文書化し、翌週のPMの優先順位セッションに振ります。

Customer Council（顧客カウンシル）

アドバイザリーボードのより幅広い運用版で、通常は特定のプロダクトエリアの20〜50社の顧客が機能プレビューを確認し構造化されたフィードバックを提供します。CSが参加者を選定し、Productがアジェンダを定義します。顧客カウンシルは四半期ごとではなく、月次またはリリースサイクルごとに開催されます。

例：レポート顧客カウンシルが30社のアカウントとダッシュボードのプロトタイプを確認します。PMMがフィードバックを文書化します。PMはそれを使って次のスプリントで最もリクエストの多い3種類のチャートタイプを優先します。

---

ワークフロー用語集

これらはProductがどのように実行するかを説明する用語です。CSはこれらを理解することで、顧客に正直な期待値を伝え、フィードバックを正しく振り、コミュニケーションのタイミングを調整できます。

バックログ（Backlog）

Productチームが構築を計画している機能、改善、修正の優先リスト。CSからの顧客フィードバックはCSMのリクエストからではなく、VoCパイプラインを経て構造化されたインプットとしてバックログに入ります。「バックログ項目」はコミットメントではなく、追跡中の検討事項です。

例：CSMがPMに顧客の機能リクエストをバックログに追加するよう依頼します。PMはVoCアイテムとして記録済みであることを確認します。CSMは顧客に伝えます。「これを追跡されたインプットとして捉えました。まだスケジュールをお約束することはできません。」

スプリント（Sprint）

エンジニアリングチームが定義された作業セットを完了する固定の開発サイクル（通常2週間）。CSへの影響：スプリントのコミットメントがある理由で、PMはスプリント計画を確認せずに顧客に「今週中に」修正を約束できません。スプリント途中の変更は既にコミット済みの作業のデリバリーを妨げます。

例：2週間スプリントの8日目に顧客がバグをエスカレーションします。PMは現スプリントのブロッカーではないことを確認し、次スプリントの最初の項目としてスロットします。CSMは10日間の解決ウィンドウを顧客に伝えます。

ロードマップ（Roadmap）

プロダクトチームが四半期または年間の時間軸にわたって計画したイニシアチブの順序。CSはロードマップの方向性を顧客に伝えます。共有する詳細のレベルは、ロードマップが公開、非公開、またはゲート管理されているかによって異なります。ロードマップは計画文書であり、コミットメントではありません。PMはすべての顧客との会話の前に、この区別をCSMと明示的に共有する必要があります。

例：Q3のロードマップには3つのイニシアチブが含まれます。そのうち2つはNDA下で戦略的アカウントレベルで共有可能です。1つは共有不可です。CSはアカウントチームがロードマップの会話をする前に、何がテーブルに乗っていて何がそうでないかの事前ブリーフィングを受けます。

リリース（Release）

顧客に出荷された変更のバージョン管理セット。リリースはProductとPMM、CSの間で連携されたコミュニケーションシーケンスを発動させます。リリースはPMの仕事の終わりではなく、定着とコミュニケーションサイクルの始まりです。

例：リリース3.4が3月15日にリリースされます。Productがスプリントを閉じます。PMMがリリースノートを公開します。CSがアカウントチームに事前ブリーフィングを配布します。影響を受けるアカウントを持つCSMがプロアクティブなアウトリーチを開始します。

廃止（Deprecation）

機能や能力が将来のリリースで削除または置き換えられることを告知するプロセス。廃止にはCSの早期関与が必要です。影響を受ける顧客は事前通知、移行パス、そして多くの場合、告知がメールで届く前にCSMとの会話が必要です。このコミュニケーションのオーナーシップモデルについては 顧客向け変更の所有権 を参照してください。

例：レガシーCSVインポートフローが90日前の通知とともに廃止されます。CSはそれを使用しているすべてのアカウントを特定します。PMMが告知の下書きを作成します。CSMは公開通知が届く前に影響を受けるすべてのアカウントに連絡を取ります。

サンセット（Sunset）

廃止された機能のサービス終了：利用不可になります。CSのコーディネーションを欠いたサンセットは、リテンションリスクと緊急エスカレーションの主要な原因です。廃止（通知）とサンセット（削除）の間のギャップは、CSが移行を推進しなければならないウィンドウです。

例：レガシーインポートフローが6月30日にサンセットされます。CSは4月1日から毎週すべての影響を受けるアカウントの移行状況を追跡します。6月1日時点でレガシーフローを使用しているアカウントは直接CSMからアウトリーチとエスカレーションパスを受けます。

---

フィードバック用語集

これらの用語は、顧客シグナルがCSからProductへどのように伝達されるかを定義します。共通の定義がなければ、フィードバックはPMが使うには生すぎるか、顧客コンテキストが失われるほど削ぎ落とされすぎているかのどちらかになります。

VoC: Voice of Customer（顧客の声）

CSMコール、サポートチケット、QBR、NPSサーベイ、アドバイザリーセッションを通じて収集された、顧客が言うこと、リクエストすること、不満を言うこと、賞賛することの集積。VoCはCS・Productフィードバックパイプラインの原材料です。しかし、構造のないVoCはノイズです。パイプラインは生のシグナルをPMが行動できるウェイト付きで分類されたインプットに変換するために存在します。

例：CSMがQBRを実施し、顧客が回避策を説明するのを聞きます。彼女はその発言をVoCシステムに逐語的に記録し、関連するプロダクトエリアにタグ付けし、共通のインパクトスコアリングルーブリックを使ってインパクトをスコアリングします。

機能リクエスト（Feature Request）

新しい機能や変更に対する顧客の要求。機能リクエストはバックログ項目ではありません。PMが対応できるようになる前に、分類、ARRインパクトによるウェイト付け、VoCパイプラインを通じたルーティングが必要です。「これを作れますか？」と「これはウェイト付けされ優先順位付けされましたか？」は別の質問です。

例：3つのアカウントがSalesforceインテグレーションをリクエストします。CSMはARRとユースケースのコンテキストとともに各リクエストをVoCシステムに記録します。PMMが3つをウェイト付き1件にまとめます。「Salesforceインテグレーション：$840K ARR影響、3アカウント、緊急性高」PMは次の優先順位セッションでそれを確認します。

顧客インパクトスコア（Customer Impact Score）

フィードバックの一片に割り当てられた数値ウェイト。影響を受ける顧客数とリスクにさらされているARRを反映します。10の小口アカウントが1つの戦略的大口アカウントより重みを持たないようにするため、アカウント数とARRを組み合わせます。計算式は会社によって異なりますが、通常ARRをアカウント数より重く重みづけします。

例：$300K ARRの1つのアカウントからのリクエストは、各$40Kの5つのアカウントからの同一リクエストより高いスコアになります。アカウント数が少なくても、リスクにさらされるARRが50%多いからです。

ARRウェイト付きフィードバック（ARR-Weighted Feedback）

生のアカウント数ではなく契約総額によって顧客リクエストを優先順位付けする手法。$2M ARRを代表するアカウントからのリクエストは、何社のアカウントがリクエストしているかに関わらず、$200K ARRを代表するアカウントからの同一リクエストより上位に来ます。

例：PMが四半期のVoC統合を確認します。ARRで最上位ウェイトのリクエスト（カスタム日付範囲エクスポート）は12アカウントと$1.8M ARRをカバーしています。より頻繁にリクエストされているが20アカウントで$600K ARRしかない項目より上位に来ます。

定性フィードバック（Qualitative Feedback）

オープンエンドで物語的な顧客インプット：コールからの逐語的な発言、書面によるQBRノート、CSMが転送したSlackメッセージ。定性フィードバックはコンテキストが豊富で比較可能性が低いです。顧客がなぜ不満を持っているかを説明しますが、不満があることだけを示すのではありません。

例：「毎月曜日の朝にExcelにエクスポートしています。なぜならダッシュボード内では必要なビューを作れないからです」は定性フィードバックです。コンテキスト、緊急性、特定の回避策があり、それらはすべて利用メトリクスが見逃すものです。

定量フィードバック（Quantitative Feedback）

構造化された測定可能な顧客インプット：NPSスコア、利用頻度、機能定着率、CSAT。定量フィードバックはアカウント間で比較しやすく、時系列でトレンドを把握しやすいですが、コンテキストが低いです。何が起きているかを教えてくれますが、なぜかは教えてくれません。

例：顧客ベース全体でのダッシュボード機能の定着率が30%は定量フィードバックです。機能が十分に使われていないことを示します。しかし顧客が見つけられないのか、理解できないのか、一度試して不十分だと感じたのかは教えてくれません。

---

プログラム用語集

これらはCS・Productの接点における構造化されたプログラムを説明する用語です。共通の定義がなければ、CSとProductは参加の意味、コミットメント、各担当者について異なる期待を持ちます。

早期アクセスティア（Early Access Tier）

GAの前に一部の顧客がいち早く機能にアクセスできる正式なプログラム。申請または招待プロセス、参加顧客からのフィードバックコミットメント、CSがリレーションシップオーナーとなることが必要です。早期アクセスはベータとは異なります。選定基準と義務を持つ定義されたプログラムです。

例：新しい自動化エンジンの早期アクセスプログラムには20枠あります。申請者は2回のフィードバックセッションと機能がGAにリリースされた場合のケーススタディへのコミットが必要です。CSが申請を確認します。Productが選定基準を設定します。

顧客共同デザイン（Customer Co-Design）

機能が構築される前に、インタビュー、プロトタイプレビュー、またはProductチームとのワーキングセッションを通じて顧客が機能の形成に関与する開発手法。CSが参加者を選定し関係を管理し、Productが設計の意思決定を担います。共同デザインは顧客が求めるものを構築するコミットメントではありません。

例：PMが新しいインテグレーションフレームワークのために4回の共同デザインセッションを実施します。CSが関連する技術的な専門知識を持つ参加者を選定します。PMはセッションを機能リクエストの収集ではなく問題定義の検証に使います。

ライドアロング（Ride-Along）

PMやProduct Designerが観察者としてCSMのライブ顧客コールやセッションに同席する手法。Productが問題について顧客のフィルタリングされていない言葉を直接聞く最も直接的な方法。ライドアロングは機能の問題定義フェーズの初期に特に価値があります。構造化とスケジューリングについては Productチームの顧客コールライドアロング を参照してください。

例：PMが同じ月に3回のCSM主導のオンボーディングコールに参加します。彼女は顧客が自分の言葉で同じ摩擦を説明するのを聞きます。その言葉はVoCチケットでのフレーミングとかなり異なることが多く、その差異が機能仕様を形成します。

---

メトリクス用語集

これらの用語は接点での成果を測定します。共通の定義がなければ、CSとProductは同じコンセプトを異なるデータソースで追跡し、異なる結論に達します。

機能定着率（Feature Adoption Rate）

GA後の定義された期間内に機能を積極的に使っている対象顧客の割合。「積極的な使用」はGA前に共同で定義する必要があります。ログインはカウントしません。コアワークフローの完了がカウントします。最近リリースされた機能の定着率が低い場合は、CSへの（顧客がなぜ使っていないかの調査）とProductへの（オンボーディングエクスペリエンスの調査）の両方へのシグナルです。

例：GA後90日で、対象アカウントの34%が新機能を使って少なくとも1つの自動レポートを完了しています。「定着した」の共同定義は「2週間連続で週1回以上レポートを完了すること」です。

定着までの時間（Time-to-Adoption）

機能がリリースされた後、顧客が新機能を使い始めるまでにかかる時間。定着までの時間が長い場合、製品品質の問題ではなくコミュニケーションまたはオンボーディングのギャップを示すことが多いです。CSMが顧客に事前ブリーフィングを行い有効化キャンペーンを実施すると、定着までの時間が大幅に短縮されます。

例：新ダッシュボードの定着までの中央値は22日です。CSMが最初の1週間に30分のウォークスルーを実施したアカウントでは、定着までの中央値が9日です。このギャップが有効化キャンペーンの価値です。

サンセット後リテンション率（Sunset Retention Rate）

依存していた機能が廃止またはサンセットされた後に継続する顧客の割合。低いサンセット後リテンション率は、移行パスが不十分であったか、事前通知が短すぎたか、またはその両方を示します。この指標を廃止イベントごとに追跡することで、将来のサンセットの改善データセットが構築されます。

例：レガシーCSVインポートフローのサンセット後、影響を受けたアカウントの94%が継続します。6%の解約を確認すると、3つのアカウントが移行の複雑さを離脱の主な理由として挙げました。

---

Rework分析：語彙ギャップコストモデル

ほとんどのCS・Productチームは語彙のミスアライメントをコミュニケーションの厄介事として扱います。しかし実際には複利コストです。VoC、機能定着、ベータについての共通定義なしに運営される四半期ごとに、CSインプットの相当部分がPMとCSMで異なる分類がなされ、どちらのチームも完全には信頼できない統合を生み出すフィードバックパイプラインが動いています。中堅SaaSのベンチマーク（ChurnZero 2024年、Gainsight 2024年）によると、自社の最頻出用語上位10件に1回のファシリテーションセッションを使ってアラインメントを取った企業は、60日以内にCSとPMのシンクにおける「それはどういう意味ですか？」という瞬間が意味のある形で減少したと報告しています。ファシリテーションコストは2時間です。その後に続くすべてのVoCセッション、スプリントレビュー、定義の回り道なしに行われる顧客との会話が複利となってその恩恵を受けます。

---

アルファベット順クイックリファレンスインデックス

---

用語集のメンテナンス

誰も更新しない用語集は誰も信頼しない用語集です。オーナーを一人指定してください。通常はCS Opsのリードや、CS・Productアラインメントのケイデンスを管理する人物が担います。そして四半期ごとに定義を確認します。四半期ごとの確認はすべてを網羅する必要はありません。高頻度の用語を確認します：VoC、機能定着、バックログ、ベータ、GA。これらは毎週のシンクで出てくる言葉であり、チームが確認しなければ定義が静かにずれていきやすい言葉です。

全面的な再定義セッションを行うタイミング：新しいプロダクトラインが新しい顧客タイプにとっての「オンボーディング完了」や「定着」の意味を変えた場合。GTMのシフトがICPを変え、したがってベータプログラムに参加する顧客が変わった場合。新しいVP ProductまたはCSが参加し、前職の語彙をチームの日常言語に持ち込んだ場合。新しいリーダーの定義は、誰もその乖離を名指しする前に何ヶ月も複利で積み重なります。新しいリーダーが参加してから30日以内に用語集を確認するのが、そのギャップを発見して解消する最も効率的な方法です。

ドキュメントをバージョン管理してください。定義が変わったら、日付と理由を記録します。口頭でのアラインメントはメンバーの入れ替わりに耐えられませんが、書面の記録は耐えられます。

これらの用語の適用方法についてさらに質問がありますか？以下のFAQはCS・Productアラインメントのレビューで最もよく出る質問に答えています。

---

よくある質問

CSとProductチームはなぜ共通の用語集が必要なのですか？

CSとProductはそれぞれ独自の専門的な語彙をデフォルトとして使います。「ベータ」「定着」「ロードマップ」のような用語は、どちらのチームが使うかによって異なる意味を持ちます。書面による共通定義がなければ、両チームが同じフィードバックの儀式に参加しながらも異なる結論に達することがあります。共通の用語集は、CS・Productのプロセス改善が機能するための基盤レイヤーです。

B2B SaaSのコンテキストでMVPとベータの違いは何ですか？

MVPは学習のための手段で、顧客フィードバックを生み出すために発行できる機能の最小バージョンです。ベータはリリース準備に近い段階で機能をテストする選定された顧客を対象とした構造化されたGA前プログラムです。CS・Productアラインメントでは、ベータ参加者は通常CSが明示的なコミットメントを持って管理するのに対し、MVP参加者は不完全な機能に対してより高い許容度を持つデザインパートナーであることが多いため、この区別が重要です。

「ARRウェイト付きフィードバック」とは何ですか？それが優先順位付けを変えるのはなぜですか？

ARRウェイト付きフィードバックは、アカウント数ではなく契約総額によって顧客リクエストに優先順位を付けます。$2M ARRを代表するアカウントからの機能リクエストは、低ARRグループにより多くの企業が含まれていても$200K ARRを代表するアカウントからの同一リクエストより上位に来ます。これにより、戦略的なリテンションリスクを含むより少数のより大きな顧客を、少数ではあるが声の大きい小口アカウントの集合が押しのけることを防ぎます。

この用語集はどのくらいの頻度で確認すべきですか？

最低でも高頻度の用語を確認してください：VoC、機能定着、バックログ、ベータ、GA。これを四半期ごとに行います。新しいVP ProductまたはVP CSが参加したとき、新しいプロダクトラインを立ち上げて「オンボーディング完了」や「定着」の意味が新しい顧客タイプにとって変わったとき、またはGTMのシフトがICPを変えたときには全面的な確認を実施します。定義は静かにずれていきます。四半期ごとの確認で、それがプロセスの失敗になる前にずれを発見できます。

NPSとは何ですか？そしてなぜCS・Productのスタンドアロンメトリクスとして不十分なのですか？

NPS（Net Promoter Score）は0〜10のスケールで製品を推薦する顧客の可能性を測ります。フレッド・ライクヘルドが開発し、2003年のハーバード・ビジネス・レビューの記事で紹介されました。CS・Productの接点におけるスタンドアロンメトリクスとして、NPSは遅すぎて幅広すぎます。顧客が不満を持っていることは示しますが、どのプロダクトエリアか、どのワークフローか、何を修正すればいいかは示しません。NPSが有用になるのは、スコアの背後にある特定の摩擦を掘り起こすCSMによるクローズドループフォローアップと組み合わさったときです。

JTBDとは何ですか？CSMがVoCパイプラインに提出するものをどのように変えますか？

JTBD（Jobs-to-be-Done）は、顧客がリクエストした機能ではなく達成しようとしていることを定義するフレームワークです。クレイトン・クリステンセンの研究により、顧客が特定のジョブを完遂するために製品を「雇用」することが確立されました。実際に、CSMが「顧客はより良いレポートを望んでいる」と記録した場合、それは機能リクエストです。CSMが「顧客はスプレッドシートにエクスポートせずに単一のビューでモジュールを横断したデータを見る必要がある」と記録した場合、それはJTBDフレームのVoCチケットであり、PMは逆算する必要なく仕様を作れる問題定義を得ます。

---

もっと詳しく

• CS & Product アラインメントとは
• VoCパイプライン：CSがProductにフィードする方法
• 顧客ベータプログラムの運用
• ARRウェイト付きフィードバック：顧客の声の定量化
• 顧客カウンシルとアドバイザリーボード
• Sales・CSアラインメント用語集：Sales・CSの引き継ぎの接点のための共通語彙