Content last updated 2026-04-09

顧客 Issue 優先順位付けフレームワーク

なぜこのフレームワークが存在するのか

GitLab のプロダクトチームは、サポートチケット、セールス会話、CSM とのやり取り、直接の顧客 Issue など、複数のチャンネルを通じて顧客フィードバックを受け取ります。一貫性のある優先順位付けシステムがないと、重要な顧客ニーズがノイズの中で失われ、チームは顧客の成功にとって何が最も重要かについて足並みを揃えるのに苦労します。

このフレームワークは、GitLab チームメンバーが顧客への影響をプロダクトチームに伝えるための共通言語を提供し、セールスを阻むもの、更新を危うくするもの、約束された成果を表す Issue が適切な注意を受けられるようにします。

フィードバックを提供する場所

Issue に関する顧客フィードバックを提供する推奨方法は、以下に記載 されているプロセスに従って 内部コメント を使用することです。内部コメントは顧客のプライバシーを保護し、機密のビジネス情報が公に表示されることを防ぎます。

パブリックコメントが必要 な場合 (顧客がコメントを見ることを期待しているサポートワークフローなど) は、代わりに Feedback テンプレート を使用します。

クイックスタート

顧客 Issue を優先順位付けするには、適切なラベルとコンテキストを付けた 内部メモ コメントを Issue に追加します。内部メモは GitLab チームメンバーのみに公開され、顧客のセンチメントが不必要に露呈しないようにします。

利用可能なラベル:

  • Ultimate: ~Ultimate::Blocker または ~Ultimate::Retention または ~Ultimate::Fast Follow
  • Premium: ~Premium::Blocker または ~Premium::Retention または ~Premium::Fast Follow
  • DAP: ~DAP::Blocker または ~DAP::Retention または ~DAP::Fast Follow
  • Ultimate: ~Ultimate::Blocker または ~DAP::Retention または ~DAP::Fast Follow

例:

Blocker の例:

~DAP::Blocker

SAML グループ同期機能なしでは商談 [internal link](https://gitlab.my.salesforce.com/0061234567890) をクローズできません。顧客はデプロイメントのために IdP グループに基づく自動プロビジョニングを必要とします。彼らのセキュリティ要件を満たす回避策はありません。

Retention の例:

~Ultimate::Retention

顧客 ([internal link](https://gitlab.my.salesforce.com/0061234567891)) はこれを 2025 年 7 月に更新する際の更新ブロッカーとしてフラグしました。大規模なモノリポでのパフォーマンス低下が、彼らのエンジニアリング部門全体での採用を妨げています。彼らは積極的に代替案を評価中です。

顧客はパイプライン開始までに 15 分以上の待機時間を示す具体的なメトリクスを提供しました。

Fast Follow の例:

~Premium::Fast Follow

更新会話中に顧客 (SFDC: https://gitlab.my.salesforce.com/0061234567892) に対して、Q3-2025 末までに強化された監査ログフィルタリングを提供することを約束しました。顧客はこの約束に基づいて更新を受け入れました。

この機能により、手動のログエクスポートなしでコンプライアンス要件を満たすことができます。現在の回避策は許容範囲ですが、運用上のオーバーヘッドを生み出しています。

仕組み

優先順位付けラベル

顧客対応チーム (Sales、Customer Success、Support、Solutions Architecture) は、顧客に直接影響する Issue に対し 内部メモコメント内で 製品固有のスコープ付きラベルを追加します:

  • ProductName::Blocker - この機能なしでは顧客に SKU を販売できない
  • ProductName::Retention - すでに購入されたこの SKU を、この機能なしでは顧客に維持できない
  • ProductName::Fast Follow - はい、この顧客を販売または維持できますが、この機能の確約された提供を期待しています

コメントにラベルを追加する

ラベルを追加できる人:

  • ソリューションアーキテクト
  • カスタマーサクセスマネージャー
  • サポートエンジニア
  • アカウントエグゼクティブ
  • プロダクトチームメンバー

ラベルを追加するタイミング:

  • ギャップが特定される技術評価中
  • 顧客がワークフローに影響する Issue を報告するとき
  • 特定の機能が拡張をブロックしている更新会話中
  • 将来の提供に関する約束がなされたとき

ラベルの追加方法:

  1. 内部メモ コメント (パブリックコメントではない) を作成する
  2. 適切なスコープ付きラベルをコメントに含める
  3. Salesforce (または他の外部システム) の顧客レコードへのリンクを貼る
  4. 顧客名や収益数値を含めずにビジネスインパクトを記述する

コメントに必要なコンテキスト:

  • 優先順位付けラベル (例: DAP::Blocker)
  • 顧客アカウントへのリンク (Salesforce の商談またはアカウント)
  • ビジネスインパクトの説明
  • 該当する場合、影響を受ける顧客セグメント／ティア

重要なプライバシー要件:

  • 常に内部メモを使用する - パブリックコメントに顧客の詳細を投稿しない
  • Issue コメントに 顧客名を絶対に含めない
  • Issue コメントに 純 ARR、契約額、収益数値を絶対に含めない
  • すべての機密情報は、リンクされた外部システム (Salesforce など) に保持する
  • 顧客を一般的に参照する (例: “Customer”、“Strategic customer”、“Enterprise prospect”)

各ラベルの意味

Blocker

この機能なしでは顧客に SKU を販売できない。

重要な質問: この機能は取引をクローズするためのハード要件か？

例:

  • 顧客が利用できない特定のコンプライアンス認証を要求している
  • 必要なエンタープライズシステムとの統合が存在しない
  • セキュリティコントロールが顧客のデプロイメントモデルに必須である
  • 必要な API 機能がないことで顧客の重要な自動化ワークフローが妨げられている

Retention

すでに購入されたこの SKU を、この機能なしでは顧客に維持できない。

重要な質問: この機能なしで顧客はチャーンまたはダウングレードするか？

例:

  • 顧客が更新ブロッカーとして明示的に Issue を提起した
  • 競合とのギャップが代替案の積極的な評価を引き起こしている
  • 機能の欠如が購入済みシート全体での採用を妨げている
  • パフォーマンスまたは信頼性の問題がビジネスを混乱させている

Fast Follow

はい、この顧客を販売または維持できますが、この機能の確約された提供を期待しています。

重要な質問: この機能を提供することで、顧客のクローズまたは維持を約束しましたか？

例:

  • 想定されるタイムラインで販売プロセス中に機能の約束がなされた
  • 更新会話で提供期待のあるロードマップ項目が議論された
  • 将来の提供に同意した上で、顧客から要求された機能強化
  • 回避策が存在するが、顧客が適切な解決策を期待している機能ギャップ

プロダクトチームの責任

プロダクトチームはこれらのラベルを計画プロセスへのインプットとして使用し、厳密な順序付けの仕組みとしてではありません。ラベルは顧客の緊急性とビジネスインパクトを示し、チームはこれを技術的依存関係、戦略的優先順位、全体的な製品の方向性とバランスを取ります。

トリアージの期待事項

トリアージボットがコメント内に顧客優先順位付けラベルがある Issue を監視します。優先順位付けラベル付きの Issue が 5 営業日後もマイルストーンや計画ラベルなしで残っている場合、関連するチームメンバーがリマインダーを受け取り、Issue が計画中に適切に考慮されることを確実にします。

この自動化は、特定の結果を強制することなく、顧客フラグ付き Issue がタイムリーにレビューされることを保証します — プロダクトチームは最終的な優先順位付け決定について完全な自律性を保持します。

ガイドラインとベストプラクティス

常に内部メモを使用する。 顧客優先順位付けコメントは、顧客のプライバシーと機密のビジネス情報を保護するため、内部メモでなければなりません。

顧客情報を保護する。 Issue コメントに顧客名、収益数値、契約額を絶対に含めないでください。すべての機密の詳細は Salesforce などのリンクされた外部システムに保持する必要があります。

Blocker は取引のブロッカーを意味する。 このラベルは、機能なしでは販売が本当に進められない状況のみに使用します。顧客が購入できる回避策が存在する場合、それはブロッカーではありません。

Retention はチャーンリスクを意味する。 このラベルは、顧客が更新会話中に機能をリクエストしたときではなく、SKU を継続できないと明示的に示した場合に使用します。

Fast Follow は私たちが約束をしたことを意味する。 このラベルは、GitLab チームメンバーが顧客と提供期待を設定した場合のみ使用します。約束のない一般的な機能リクエストにはこのラベルを付けるべきではありません。

内部メモにビジネスコンテキストを明確に記録する。 プロダクトチームは情報に基づく意思決定をするために顧客への影響を理解する必要があります。アカウントリンク、顧客ティア／セグメント、なされた約束の具体的な詳細を含めてください — ただし、名前と収益は外部システムに保持してください。

1 コメント 1 ラベル。 Issue が複数の製品に影響する場合、主要な製品領域を選び、必要に応じて各製品ごとに別のコメントを追加します。顧客への影響が不確かな場合は、ラベルを追加する前にプロダクトチームと話し合ってください。

コンテキストが変化したら更新する。 回避策が特定されたり、機能なしで取引がクローズされたり、顧客の優先順位が変わったりした場合、更新されたコンテキストや明確化を含む新しい内部メモコメントを追加してください。

フィードバックと進化

このフレームワークはチームの使用とプロダクトフィードバックに基づいて進化していきます。質問や提案は次の方法で送信してください:

関連: Product Development Flow、Working with Product

リソース

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License