カテゴリーの成熟度 - 競合比較

このハンドブックページでは、Category Maturity Scorecardと組み合わせて使う競合比較プロセスを概説します。

競合を見ることがなぜ重要か

私たちの既存の Category Maturity Scorecardプロセス は、ユーザーの視点からのユーザビリティに焦点を当てています。 そのプロセスに欠けているのは、Jobs to be Done (JTBD) を念頭に置いた、機能性と機能において主要な競合に対してアプリケーションとしてどう比較されるかを見ることです。言い換えると、競合比較を加えることで、「解決しようとしている問題はこれ」（JTBD）と「どのように解決されているか」（機能性／機能）と「使うことがどれだけ快適か」（Category Maturity Scorecard）を組み合わせた、より厳密な見方ができます。

そのギャップに対処するため、この競合比較ピースは、カテゴリー成熟度を測定する際に使う既存のCategory Maturity Scorecardプロセスへのアドオンコンポーネントおよびもう一つのデータポイントとして適合するように設計されています。

この新しいプロセスでは、直接的な機能比較を行っていません。代わりに、解決しようとしている問題（JTBDとも呼ばれる）と、それらがGitLabと競合の中でどのように解決されているか（機能とも呼ばれる）に焦点を当てています。最終的に、これは特定のJTBDについて、業界内での「機能完成」がどのようなものかを理解する助けとなります。

既存のCategory Maturity Scorecardプロセスへの組み込み

競合比較はいつでも実施できますが、MinimalまたはViableに到達する前の 早期 に実施することを強く推奨します。競合比較を早期に完了することは、以下に役立ちます。

• JTBD／ワークフローに関連する業界トレンドを特定する
• 自社の機能提供のギャップを特定する
• 比較の発見を計画目的に使用する
• CompetitiveおよびComplete成熟度を評価する前に、特定されたギャップに対処する

早期に競合比較を実施できなくても問題ありません。Category Maturity Scoringの後期段階でこれを実施することにも、依然として大きな価値があります。

Completeにいる場合は、少なくとも年に1回は競合比較を実施するべきです。そうでない場合は、カテゴリーシフトを行う予定があるときに実施します。

従うべきステップ

プロダクトマネージャーは、プロダクトマーケティングマネージャーまたはDeveloper Advocateと協力して、quadチームを率いて競合比較を実施します。理由: プロダクトマネージャーは、JTBD、競合、機能に関する詳細な視点を持っているため、比較作業を率いるのに最適です。以下のステップは、競合比較のプロセスをウォークスルーします。

• ステップ1 - 競合を選択する

  • スペースに多くの競合がある場合は、トップ競合に焦点を当てることをお勧めします。
  • 評価される競合は、JTBDを念頭に置いて直接の競合であることが正当化可能であるべきです。市場シェア、機能の重複などの要素は、比較する競合を決定する際に考慮するべきです。
  • 競合が有料のサブスクリプションを必要とする場合は、公開されているソースを使って可能な限りベストを尽くして比較を実施する必要があります。また、競合についての理解を広げるためにサードパーティのベンダーを活用できるかを確認するため、#competition Slackチャンネルに連絡してください。
  • 競合によっては、Individual Use Softwareプロセス を通じて承認を得る必要があるかもしれません。

• ステップ2 - 法務ガイドラインに従う

  • 競合をレビューしているので、サードパーティサービスを使った競合ベンチマークの使用に関するガイドライン（チームメンバーのみ利用可）と 競合製品の機能の公的議論に関するガイドライン をレビューし、従うことが重要です。
  • 私たちは、評価している競合の利用規約にも注意する必要があります。 評価しようとしている競合の利用規約を理解するのは、しばしば困難です。 自分で解釈しようとするのではなく、競合比較を進める前に #legal Slackチャンネルで質問してください。

• ステップ3 - 焦点を当てるJTBDを決定する

  • JTBDは、評価している（またはすでに評価した）Category Maturity Scorecardテストと直接整合するべきです。JTBDを特定する方法のプロセスは、こちら で概説されています。
  • JTBDのスコープが複数のステージグループにまたがる場合があり、その結果、異なるチーム間でより緊密な協力が必要になります。 そのシナリオに対する最善のアプローチに関する1つの提案は、競合比較のための分業とタイミングの考慮事項を議論しつつ、合意されたJTBDのセットに到達するために非同期ワークショップを開催することです。

• ステップ4 - トップ競合を特定する

  • 評価しているJTBDのコンテキストでこれを保ってください。

• ステップ5 - テンプレート をコピーし、評価しているJTBDを入力する

  • ガイダンスのためにテンプレート内の例をレビューしてください。
  • Issueからデックをリンクし、これらのデックはGitLab外部で閲覧されるべきではないため、完成したデックの「View」設定がGitLab内部のみであることを確認してください。 リマインダーとして、YouTubeに表示される公開ストリームや録画されたミーティングでデックをプレゼンする場合は、画面を共有しないことが重要です。

• ステップ6 - JTBDを解決する機能性／機能を比較する

  • JTBDに関連するエクスペリエンス／機能の違いを示すために、GitLabと競合の両方のスクリーンショットを必ず含めてください。
  • GitLabまたは競合のどちらかが比較されているJTBDを解決する解決策（機能）を提供していないことを発見した場合は、それはおそらくギャップがあることを示しています。

• ステップ7 - 各JTBDをレートする

  • 各スライドは、レーティングの背後にある作業と正当性を示す機会であるべきです。
  • 覚えておいてください: 競合比較は完全にデータ／証拠駆動であるべきです。

• ステップ8 - スコアリングを文書化／更新する

  • 適切なシグナルで このハンドブックページ の既存のカテゴリースコアを追加または修正します

• ステップ9 - 取るべき実行可能なステップを特定する

  • ギャップが特定され、レーティングが完了したので、成熟度を上げるおよび／またはベストインクラスを達成するためのアクションプランを開発する時です
  • （これをどう行うかの提案に関するハンドブックページにWIP - 近日公開）

ベストインクラスのスコアリング

このプロセスが持続可能であるためには、「GitLabはこのカテゴリーでベストインクラスか？」という問いに答える、Category Maturity Scorecardフレームワークに追加する適応可能でシンプルな方法論を提供する必要があります。

レーティングへのアプローチ

Category Maturity ScorecardはJobs to be Done (JTBD)に基づいているので、競合比較で同じターゲットジョブを使用するのが理にかなっています。そのため、私たちは自分たちの判断と市場知識を使って各JTBDを別々に評価し、全体のベストインクラスレーティングを導きます。

Category Maturity Scorecardプロセス全体を通じて、ユーザーがGitLab内で実行する代表的なタスクを理解するために、1つ以上のJTBDを評価します（JTBDは複数のタスクで構成されています）。競合比較については、競合製品内で同じタスクを ヒューリスティック評価 します。各タスクについて、GitLabか競合のどちらが優れたエクスペリエンスおよび／または機能提供を持っているかを客観的に評価します。

ベストインクラスの示し方

JTBDがベストインクラスかを示すために、既存のCategory Maturity Scoreの修正の形でシンプルなレーティングを使います。

• (+) ベストインクラスを示す
• 太字 (+) は、GitLabがすべてのJTBDで競合よりも良いスコアを獲得した、GitLabのスイープを示す
• (-) ベストインクラスではないことを示す
• マーキングがない場合は、競合分析が実施されなかったことを意味する。

例:

• ‘Viable’ - マーキングがないことは、競合分析が実施されなかったことを示す
• ‘Viable (+)’ - (+) はベストインクラスを示す
• ‘Viable (+)’ - (+) はベストインクラスとGitLabのスイープを示し、GitLabがすべてのJTBDで競合よりも良いスコアを獲得した
• ‘Viable (-)’ - (-) はベストインクラスではないことを示す

ヒューリスティックを特定する

これを尋ねるもう一つの方法は: 「これらの比較で競合を見るときに、何を見ているのか？」 短い答えは: JTBDを考慮しつつ、ユーザーにとって何が重要かに焦点を当てる。ヒューリスティックは、両方のアプリケーションを比較できるよう、GitLabと他の競合の両方に適用される必要があります。

ヒューリスティックを 客観的で事実に基づいた ものに保つことも重要です。それは、自分自身の個人的な意見を、使うヒューリスティックから可能な限り除外することを意味します。客観的なヒューリスティック対主観的なヒューリスティックの例をいくつか示します。

時には、比較のために、ヒューリスティックが単にどのように何かが行われているかであることもあります。 つまり、レート可能ではないかもしれません。例えば、データベースへの呼び出しがどのように行われているかを定義する可能性があります。それがJTBDを完了しようとするユーザーにとって差別化要因で重要であれば、ヒューリスティックとして浮上する可能性があります。 このトピックに関する質問がある場合、またはレビューを希望する場合は、UXリサーチャーに相談してください。

ヒューリスティックが客観的か主観的かを判断するのに苦労している場合は、以下を考慮してください。

• ヒューリスティックの定義に ‘better’, ‘faster’, ‘more’ のような単語を使っている場合、それはおそらく主観的なヒューリスティックであり、より客観的になるように調整する必要があります。
• ヒューリスティックが数字、はい/いいえ、または説明を使って比較できる場合、それはおそらく客観的なヒューリスティックです。

ヒント: 事前にヒューリスティックを特定せずに比較に入るのが、時には最善です。 ヒューリスティックは、比較が進行中になると、しばしばあなたに明らかになることがあります。 実際の例:

• 機能を比較するときに、1つのアプリケーションが、同じタスクを完了するために、もう1つのアプリケーションよりもはるかに多くのステップを含んでいたことが明らかになりました。 この例では、比較可能なヒューリスティックは ‘ステップ数’ になりました。

JTBDごとに目指すべき良いヒューリスティックの数は、3つか4つです。‘ベストインクラス’ のストーリーを伝えるのに役立つ、重要な差別化要因と考えるものに焦点を当ててください。

ケーススタディの例

JTBD: サービスにサインアップするとき、効果的に製品を使い始められるよう、できるだけ早くプロセスを進めたい。

潜在的なヒューリスティック:

• 時間
• ステップ数

このための競合分析を実施するためには、特定したヒューリスティックを追跡しながら、GitLabと競合の両方でサインアッププロセスを実行する必要があります。

両方のアプリケーションで各ヒューリスティックを通じて文書化した後、3つの可能な結果があります。

1. GitLabがより多くのヒューリスティックで優れている。（GitLabがこのJTBDのベストインクラス）。
2. 競合がより多くのヒューリスティックで優れている。（GitLabがこのJTBDのベストインクラスではない）。
3. 引き分け。（“ベスト” は引き分けを意味しないので、GitLabがベストインクラスではない。誰かがあなたと同じくらい良ければ、あなたはベストではない）。

これは、どちらのアプリケーションが優れているかについて、各JTBDのレーティングを与えます。カテゴリーレーティングについても、同じタイブレーキングが適用されます。

このようにして、競合分析の全体スコアに到達します。

ページのソースコードを見る - ページの編集 - please contribute.