機能の優先順位付けのための Kano サーベイ

Kano モデル

Kano モデルは、認知された製品機能とユーザー満足度を結びつける理論です。1980 年代に日本の狩野紀昭教授によって開発されました。

Kano モデルは、製品機能の開発がユーザー満足度にどのように影響するかに基づいて、5 つのカテゴリーに分類します:

• 当たり前品質（Must-be）: 初期採用に不可欠な機能ですが、どれだけ投資しても高い満足度にはつながりません。
• 一元的品質（Performance）: （別名 One-dimensional）これらの望ましい機能への追加投資に応じて満足度が高まります。
• 魅力的品質（Attractive）: あったらいい機能ですが、うまく実装すれば満足度が急上昇します。
• 無関心品質（Indifferent）: これらの機能への投資はユーザー満足度を増加させたり減少させたりしません。
• 逆品質（Reverse）: これらの機能は持っているよりも持っていないほうが実は良いです。

機能がどのカテゴリーに属するかがわかれば、開発で最も重要なものに優先順位を付けることができます。理論上、当たり前品質カテゴリーの機能を最初に優先し、次に一元的品質、そして魅力的品質を優先するべきです。各カテゴリーに属する機能の数によっては、製品チームと協力して優先順位を決定する必要があるかもしれません。

なぜ使うのか？

Kano モデルを使うことで、新製品の機能を優先順位付けする際により情報に基づいた決定を下し、これらの機能がユーザーに共感を呼ぶかどうかとその理由をよりよく理解するのに役立ちます。

どう使うのか？

Kano モデルは、特に機能の優先順位付けに情報を提供するときに、顧客データとともに最もよく活用されます。このデータを収集するには、Kano 分析モデルの一部として開発された標準化された質問票を使ってリサーチスタディを実施することをお勧めします。

リサーチの観点からは Kano スタディのサーベイを設計するのはどちらかというとシンプルですが、プロダクトマネージャーには多くの準備が必要です – 特に機能と製品領域の現状を説明することです。次のセクションでは、GitLab で Kano スタディを設計する詳細について議論します。

Kano サーベイの例

下のプロジェクトでは、新しい GitLab 機能のセットを優先順位付けする方法を理解するために Kano サーベイが開発されました。

例プロジェクト: CI 機能優先順位付けのためのサーベイ

プロジェクト要約: チームは、ユーザーに利益をもたらすと考える 12 の新機能の構築を検討していました。新機能を構築するのはコストがかかり時間もかかるので、チームは各機能についてユーザーがどう感じるか、優先順位とともに理解したいと思いました。目標は、チームが最初に構築すべき 12 のうちのどれかをより明確に理解することでした。

12 の機能についてのフィードバックを得るために、チームは各機能について短い要約や説明を開発し、繰り返し改善する必要がありました。次のセッションでは、機能説明を作成しサーベイに転送するプロセスの詳細を提供します。

準備

スタディの成功にはよく定式化された機能説明が不可欠です。参加者は、聞かれている機能とその機能の価値を正確に理解できなければ、率直なフィードバックを提供できません。明確に理解されるのに十分な詳細を提供することを保証するために、機能が綿密な改善プロセスを経た後にのみサーベイを作り始めることが理にかなっています。

カテゴリーの説明

私たちは通常、既存の機能のコンテキストで新機能を開発します。そのため、最初に提示される機能を含む現在のエクスペリエンスを参加者に説明する必要があります。

カテゴリー説明の例:

GitLab における継続的インテグレーションパイプラインは、プロジェクトの Git リポジトリ内のバージョン管理ファイルとして定義されます。このファイルは「gitlab-ci.yml」と呼ばれ、ユーザーはこのファイルを編集してリポジトリにプッシュすることで CI パイプラインを構成します。パイプラインはジョブとステージで構成されます。ジョブはパイプラインが何をすべきかを定義します。ステージは 1 つまたは複数のジョブで構成され、ジョブが実行される順序を定義します。ステージ内のすべてのジョブは並列に実行され、それらすべてが成功すれば、パイプラインは次のステージに進みます。前提条件、例外などのさまざまな種類の条件をパイプラインに指定できます。プロジェクトをローカルでクローンするか、オンラインテキストエディタを使って、パイプライン YAML ファイルを編集できます。

機能説明

機能説明を作成する際は、これらのガイドラインに従ってください:

1. MVC ではなく機能を記述する
   • 調査結果は、合理的に長い期間にわたって関連性があるべきです。言い換えれば、1 つまたは 2 つのマイルストーンで開発できないようなものでしょう。
2. 機能説明の認識におけるバイアスを避けるため、シンプルで中立的な言葉を使う
   • sections や categories のような GitLab の専門用語は使わない
   • easy-to-use、better、faster、more efficient のようなセールスやマーケティングの言葉は使わない
   • 悪い例: Run Dynamic Application Security Testing (DAST) in the cloud as part of your CI jobs on cloud based runners. This will make deploying and testing applications in a sandbox significantly more efficient.
   • 良い例: Run Dynamic Application Security Testing (DAST) in the cloud as part of your CI jobs on cloud based runners, to deploy and test applications in a sandbox for potential vulnerabilities.
3. 機能をシステムのコンテキストに設定する
   • 一貫した用語を使い、機能説明が全体のカテゴリー説明に適合することを確認します。
4. 各説明を 1 段落のテキストにすることを目指す
   • 通常の段落 1 つ未満では十分でない可能性があります。一方、テキストが長すぎると、参加者はコンテンツを流し読みしがちで、機能を完全に把握できなくなります。
5. 新機能のみを含める
   • 既に開発された機能を含めることはベンチマークを設定するかもしれませんが、ほとんど実行可能ではないため、このコンテキストでは役に立ちません。
6. 説明を画像や GIF で豊かにする
   • 視覚的補助があると、参加者が機能説明で説明されているコンセプトを理解するのに役立ちます。

一般に、機能説明は次の基本構造に従うべきです:

• 機能: ユーザーが UI で何を見ることができるか
• 動作: 何をするか
• 価値: なぜそれを導入したいのか

機能説明の例:

オンラインパイプラインエディタの隣に表示される CI ジョブコードスニペットのリスト。このリストからジョブ YAML をコピーし、パイプラインコードに貼り付けることで、これらのコードスニペットをパイプラインの構成要素として使用します。したがって、新しいパイプラインの作成プロセスにおけるステップが少なくなります。

• 機能説明のその他の例については、このCI features list Google Docを参照してください。

ヒントとコツ

サーベイ

標準化された質問票

Kano モデルの標準化された質問票は、関心のある各機能について尋ねる 2 つの質問で構成されています:

標準化された質問票を使う利点は、基本的にすべてのリサーチデザインが既に完了しており、以前のスタディから再利用できることです。また、この手法に一貫したアプローチを取ることで、プロセスにエラーを導入するリスクを減らせます。

リサーチプランの例については、過去のKano スタディプラン（Google Docs）を参照してください。

質問票の構造

Qualtrics を使って質問票を作成します。関連する質問（機能的および非機能的質問）と一緒に各機能説明は別のブロックに提示されるべきです。これにより、参加者は各機能について別の機能とは独立して回答できます。また、提示順序が参加者のフィードバックに影響を与えないように、各ブロックの順序をランダム化することをお勧めします。

#1027 で使用したサーベイの例

データ収集と分析

提供された質問票を使って、データを収集し、分析し、定量と定性の両方のアプローチを使って結果を報告できるようになります。

定性アプローチ

このアプローチは、優先順位付けの背後にあるなぜをより理解するのに役立ちます。最初に定性データを収集して分析することは、説明が紛らわしいか不明確かどうかなど、機能説明の問題を発見するのに役立ち、より大規模な参加者セットに送る前に説明を修正できます。定量アプローチを行った後、サーベイサンプルからの数人のユーザーと話して、評価を提供した理由についての追加のフィードバックを得ることもできます。

参加者のタスクが質問票を経て自分の回答の背後にある推論を説明することである、5〜10 のモデレーター付きセッション、または 20〜30 のモデレーターなしセッションを実施することをお勧めします。

例 Dovetail プロジェクトでは、より大規模なサーベイで応答を集める前と後にモデレーター付きインタビューが実施されました。

定量アプローチ

ターゲットオーディエンスの 50〜80 人のユーザーから応答を収集し、The Complete Guide to Kano Modelで説明されている離散分析を使って分析することをお勧めします。このアプローチは、優先順位付けの決定を裏付けることができる「数値」を提供しますが、優先順位付けの背後にある理解は依然として欠けます。

分析にはこのスプレッドシートテンプレート（GitLab 内部リンク）を使用します。

定量アプローチからの出力をまとめたサンプルレポート（GitLab 内部リンク）。

定量と定性のアプローチを取ることで、データの背後にあるより完全なストーリーが得られます。優先順位付けに加えて、参加者がなぜそのようにスコアを付けたかを説明することもできます。これら 2 つのアプローチを組み合わせて、Kano モデルスタディを最大限に活用してください。

追加リソース

• 記事: The Complete Guide to Kano Model
• 記事: Kano Model — Ways to use it and NOT use it
• ビデオ: Building a Winning UX Strategy Using the Kano Model

GitLab で実施された Kano リサーチの例

• モニタリング機能の優先順位付け
• CI 機能の優先順位付け
• セキュリティインサイト機能の優先順位付け
• GitLab Plus 機能の優先順位付け

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