カノモデルとは？品質の5分類と活用方法を解説

カノモデルは、品質や機能の充足と、顧客の満足・不満の関係を整理する考え方です。「機能を増やせば、その分だけ満足が高まる」とは限らない点に注目します。狩野紀昭らの品質研究に基づき、機能の優先順位を考える際にも使われています。（狩野紀昭らの原著）（カノモデルを使ったサービス設計の研究）

改善の要望を集めても、すべてには対応できないことがあります。その際、顧客にとって当然の条件と、あれば喜ばれる条件を分けると、議論を整理できます。作り手の印象だけで分類を決めないことが大切です。

本記事では5分類と質問方法を説明し、予約サービスの架空例を使って、回答を改善判断につなげる手順を紹介します。

カノモデルの品質の5分類

同じ充足・不充足でも、満足と不満への関係は品質の種類によって異なります。

実務で使われる5分類は、当たり前品質、一元的品質、魅力的品質、無関心品質、逆品質です。サービス設計の研究でも、これらの分類を使って顧客の反応を整理しています。

分類	充足した場合	充足しない場合
当たり前品質	当然だと受け止められます。	不満につながります。
一元的品質	満足が高まります。	不満につながります。
魅力的品質	満足につながります。	なくても不満にはつながりにくい品質です。
無関心品質	満足への影響が小さい品質です。	不満への影響も小さい品質です。
逆品質	かえって好まれない品質です。	ない方が好まれます。

この分類は、企業が提供する機能の永続的な属性ではありません。ある顧客にとって便利な通知が、別の顧客には過剰な連絡になる場合があります。誰に聞くかを決めず、機能名だけで分類することは避けましょう。

対になる質問で顧客の反応を聞く

一つの機能について、ある場合とない場合を対にして尋ねます。

カノモデルの質問では、同じ機能について「提供されるとどう感じるか」と「提供されないとどう感じるか」を尋ねます。両方の回答を組み合わせ、分類します。片方の好意だけで魅力的品質と判断する方法ではありません。

機能のある・なしを同じ場面で尋ねる

架空の予約サービスで確認通知を調べる場合、「通知機能は必要ですか」だけでは、何の通知かが曖昧です。「予約直後に、日時と料金が記載された確認メールが届く」と、場面と内容をそろえて説明します。ない場合の質問も、同じ場面・同じ機能について尋ねます。

回答選択肢は、うれしい、当然だと思う、何とも思わない、仕方ないと思う、困るという5つの反応に対応します。ここでの日本語は、研究で用いられた選択肢を平易にした説明用の表現です。

本調査の前に、少人数に質問文の意味を説明してもらうと、解釈の違いを見つけられます。「機能がない」と「利用できない」を別々の場面だと理解していないかも確認してください。

予約サービスの質問・分類例

質問の対象と回答の組み合わせを示すと、分類の理由を確認できます。

週末の講座を予約する顧客を想定します。以下は、その顧客が答えたと仮定した説明用の架空例です。実際の顧客の割合や、予約サービス全体の評価を示すものではありません。

調べる機能	ある場合の回答	ない場合の回答	この組み合わせの分類
予約内容の確認	当然だと思います。	困ります。	当たり前品質と分類します。
予約直後の確認メール	うれしく感じます。	困ります。	一元的品質と分類します。
持ち物の提案	うれしく感じます。	何とも思いません。	魅力的品質と分類します。
背景色の選択	何とも思いません。	何とも思いません。	無関心品質と分類します。
予約ごとの会員登録必須化	困ります。	うれしく感じます。	逆品質と分類します。

このサンプルでは、確認できないと困る条件と、付加的な案内の違いが課題として浮かび上がります。同時に、企業に都合のよい登録手順が顧客には負担になる可能性も検討できます。

回答を評価表へ照合する手順

上の5行は代表例です。ほかの組み合わせも分類するには、2022年研究のTable 1（PDF 8ページ）を、次の順で参照します。この評価表は、一人の回答を分類するためのものです。

一つの機能について、「ある場合」と「ない場合」の回答を一組にします。
評価表の行（Functional Answers）で「ある場合」の回答を、列（Dysfunctional Answers）で「ない場合」の回答を探します。本記事の選択肢は、表の順に「うれしい」「当然」「何とも思わない」「仕方ない」「困る」に対応します。
行と列が交わる記号を読みます。Aは魅力的、Oは一元的、Mは当たり前、Iは無関心、Rは逆品質、Qは疑問回答です。
回答者ごとの記号を記録してから、機能別・顧客層別に件数を集計します。Qは5分類へ無理に入れず、質問の誤解や回答の理由を確認します。

例えば、「ある場合は当然」「ない場合は困る」の交点はMです。両方に「うれしい」と答えた場合はQになります。質問文と選択肢の意味を途中で変えると照合できなくなるため、本調査で使う表と表現は先に統一してください。

回答の分布をどう読むか

最多の分類だけでなく、顧客層ごとの分布と回答理由を確認します。

品質の評価が商品や消費者の属性で変わることは、品質研究でも検討されています。（消費者の品質要求に関する研究）全体では無関心品質が多くても、ある利用者群では当たり前品質が多い場合があります。全体の一つの分類だけで削除を決めない方が安全です。

集計では、調査対象、回答者数、機能ごとの有効回答数を残します。新規の利用者と長期の利用者を比べる際は、各群の人数も示してください。回答者の少ない群の差を、顧客全体の違いとして言い切らないことが重要です。

回答理由を補足すると、数字だけでは見えない事情を確認できます。通知が好まれないなら、機能そのものより頻度が問題かもしれません。顧客インタビューを組み合わせれば、その違いを確かめる材料になります。

改善の優先順位に使う方法

品質の分類に、問題の深刻さ・実装費用・対象人数を加えて判断します。

まず、利用に支障がある当たり前品質を確認します。予約内容を確認できないといった問題は、付加機能より先に解消する候補になります。ただし、安全や契約上の要件は、調査で人気が低くても守る必要があります。

次に、一元的品質や魅力的品質について、どの顧客に何を変えたいかを決めます。満足度を上げたいのか、問い合わせを減らしたいのかを分け、実装と運用の費用を見積もります。分類結果は、購入率や利益の上昇を直接示すものではありません。

予約サービスの架空例で、確認画面の不備によって日時の取り違えが起きているとします。この場合は、当たり前品質と分類されたことに加え、予約を正しく利用できないという支障を理由に、確認画面の修正を先に検討します。魅力的品質と評価された持ち物の提案は、予約内容を確かめられる状態を整えた後の候補です。実装費用が大きい場合は、まず誤りを防ぐ案内を用意できるかも確認します。

試験では一つの改善を選び、予約完了、問い合わせ、利用後の評価を確認します。顧客満足度調査の設計と合わせて、導入前の期待と利用後の反応を分けて測ることを推奨します。

カノモデルの限界と注意点

分類は判断材料であり、実装順を自動的に決める計算機ではありません。

機能の説明が曖昧なら、顧客は別々の内容を想像して答えます。実際には使えない機能の評価や、複数の機能を一つにした質問も、解釈が難しくなります。一つの質問対で調べる対象を絞りましょう。

最適な調査人数や、集計後に機能を分類する判断基準は、対象顧客・目的・判断方法によって異なります。一つの分類が多いという理由だけで、売上への影響や効果の大きさを確定できません。対になる回答を評価する表とは区別して考えます。

また、期待される品質は競合や利用経験で変わる可能性があります。一定の期間がたったときや、サービス内容を大きく変えたときには、同じ顧客条件で再確認することを検討します。

まとめ

カノモデルは、顧客の反応を対になる質問で確かめ、改善の理由を整理するために使います。

✓5分類は、品質の充足と満足・不満の関係を表します。
✓対になる質問で、機能がある場合とない場合の反応を確認します。
✓顧客層と回答分布を見て、全体の最多分類だけで判断しません。
✓優先順位には、費用・対象人数・問題の深刻さも加えます。

まず、改善候補を一つ選び、ある場合とない場合の質問を作ってみてください。顧客が同じ機能を想像して答えられるかを確かめると、社内の「きっと喜ばれるはず」という議論を検証可能な形に変えられます。