フィードバックループ

カノモデル:機能リクエストを顧客の感じ方で分類する

1分で読めます

カノモデルは、何人が要望したかではなく、その機能があるときとないときに顧客がどう反応するかで機能を分類する方法だ。1984年に狩野紀昭が提唱し、すべての機能を五つのグループに分ける。当たり前品質、一元的品質、魅力的品質(感動品質)、無関心品質、逆品質だ。機能リクエストが山積みになっているチームにとって役に立つのは、数十票を集めた要望が満足度をまったく上げないことがある一方で、誰も投票しなかった要望が製品の語られ方を変えることもある理由を、このモデルが説明してくれる点だ。

カテゴリあるときの顧客の反応ないときの顧客の反応よくある要望
当たり前品質何も感じない。あって当然強い不満パスワードのリセット、データのエクスポート
一元的品質多いほど満足が高まる少ないほど満足が下がる速度、ストレージ、上限
魅力的品質感動何も感じない。誰も期待していない気の利いた自動化
無関心品質何も感じない何も感じないほとんど触られない設定
逆品質煩わしさほっとする強制されるツアーや余計な手順

カノモデルのカテゴリにはどんなものがあるか

当たり前品質の機能は、顧客があって当然と考えているものだ。誰も褒めないが、壊れれば全員が気づく。一元的品質の機能は、多ければ多いほど良いという直線的な関係にあり、レポートが速くなることや上限が上がることがその例だ。魅力的品質の機能は予想外なので、なくても何も失わず、あれば本物の熱意を生む。無関心品質の機能はどちらの方向にも何も動かさず、逆品質の機能は取り除くと喜ぶ顧客がいる。

カテゴリとは、ある顧客グループにとって、ある時点での機能の性質のことだ。そのため、同じ機能でもセグメントによって別のグループに入ることがある。

カノ調査はどう実施するか

各機能について二つの質問をする。肯定的質問では、その機能が製品にあったらどう感じるかを尋ねる。否定的質問では、なかったらどう感じるかを尋ねる。どちらも同じ五つの選択肢で答えてもらう。好きだ、当然だ、どちらでもない、仕方ない、嫌いだ。

二つの回答を標準の評価表に当てはめ、回答者ごとに各機能の見え方を分類する。

肯定的 \ 否定的好き当然どちらでもない仕方ない嫌い
好きQAAAO
当然RIIIM
どちらでもないRIIIM
仕方ないRIIIM
嫌いRRRRQ

Mは当たり前品質、Oは一元的品質、Aは魅力的品質、Iは無関心品質、Rは逆品質、Qは矛盾した回答で、疑わしい回答だ。機能ごとに回答者全体の文字を数え、最も多いものをその機能のカテゴリとする。二つのカテゴリが拮抗するときは両方を報告する。40対38という結果は、一方の答えが勝ったのではなく、そのセグメントの意見が割れていることを示すからだ。

どの機能リクエストをカノ調査に入れるか

本気で作ることを検討していて、直感では順位をつけられないものだけだ。調査に適した機能の数は5〜15個で、それぞれに、モックアップなしで顧客が思い浮かべられる一文の説明が要る。候補は、重複をまとめたあとの追跡中のバックログから選ぶ。同じ内容の要望が10件あっても、調査には一つの機能として載せるべきだからだ。まとめる手順は機能リクエストの追跡で扱っている。

バグ修正と、すでに契約で約束している内容は除く。クラッシュを直すべきかどうかは、調査では判断できない。

誰に調査するか

すでに製品を使っている人を、自社にとって大事なセグメントごとに分けて調べる。リスト全体に送ると、いくつもの異なるグループの平均が出やすく、平均は発見を隠してしまう。無料ユーザーと有料ユーザー、新規アカウントと長く使っているアカウント、小さなチームと大きなチームでは、同じ機能が別のカテゴリに入ることがよくある。セグメントごとの結果は分けたままにして、次のリリースがどのセグメントのためのものかを決める。

要望を書いた人を最初の対象にし、そこにアクティブユーザーの無作為標本を加えて、声の大きな少数派だけの調査にならないようにする。依頼文の書き方と送り方は顧客フィードバックの聞き方にある。

カノの結果をどう優先順位に変えるか

作る順番は次のとおりだ。まず当たり前品質の不足を埋め、次に顧客が比較している代替製品に後れを取っている一元的品質の機能、続いてリリースごとに魅力的品質を一つか二つ、無関心品質と逆品質は最後か、作らない。この順序は、各カテゴリが満足度に何をもたらすかから決まる。当たり前品質の不足を埋めれば離れる理由が一つ減り、一元的品質の改善は満足度を着実に上げ、魅力的品質の機能は差別化の源になる。

カノモデルが示すのは機能がどんな種類の価値を持つかであって、コストは示さない。計画に載せる前に、カテゴリと工数の見積もりを組み合わせる。コスト面はRICEスコアリングのような採点方法で扱え、二つは相性が良い。カノで候補を絞り、RICEでその順番を決める。判断全体は機能リクエストの優先順位づけで説明している。

機能は時間とともにカテゴリを移るか

移る。そしてこれが、このモデルについて覚えておくべき最も役に立つ点だ。魅力的品質の機能は、競合が真似をして顧客が慣れるにつれて、一元的品質へ、さらに当たり前品質へと移っていく。二要素認証はかつては嬉しい驚きだったが、今では業務向けソフトウェアに期待されて当然の機能だ。調査結果はある時点のスナップショットなので、賭けているカテゴリについては、1年後か、競合が近い機能を出したときに繰り返す。

魅力的品質の機能を出したら、顧客に伝える。このカテゴリの機能は、知った人だけが感動するので、告知は機能の一部だ。このループを閉じる方法は新機能の発表の書き方で扱っている。

カノモデルの限界は何か

測れるのは行動ではなく、答えとして述べられた気持ちなので、人が欲しいと言うものを過大評価することがある。パターンを見るにはセグメントごとに十分な回答数が必要で、実用上の下限は数十件であることが多い。また、機能を一つずつ評価するので、機能同士がどう影響し合うかについては何も言えない。結果はロードマップの議論の強い根拠として扱い、利用データや売上と並べて見る。順位づけしたリストを計画にする方法はプロダクトロードマップの作り方を参照。

FAQ

カノモデルとは簡単に言うと何か? 機能がある場合とない場合に顧客がどう感じるかで、機能をグループに分ける方法だ。グループは当たり前品質、一元的品質、魅力的品質、無関心品質、逆品質で、それぞれ作る優先度の考え方が異なる。

カノ調査には何人必要か? 決まった人数はないが、個別に読みたいセグメントごとに、はっきりした多数派のカテゴリが見える回答数が要る。実用上の最小値はセグメントあたり数十件が一般的で、回答が少なく結果が割れたときは、未確定として読む。

カノモデルはRICEより優れているか? 答える問いが違う。カノは機能が顧客に与える価値の種類を分類し、RICEはリーチ、インパクト、確信度、工数で作業に順位をつける。カノで候補を絞り、採点方法で順番を決めるチームは多い。

カノ分析はどのくらいの頻度で繰り返すべきか? 安定した製品なら年に一度、競合が似た機能を出したときはもっと早く繰り返す。魅力的品質の機能は時間とともに期待に変わるので、古い結果は、もはや差別化にならない機能を指してしまうことがある。


この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ: 開発者向けドキュメント, changelogツール比較

changeloop
ループを閉じるchangelogを作っているチームです。ユーザーが何かを求め、あなたのチームがそれを届け、求めた人がそれを知る。