Kanoモデルで機能要望を分類する｜質問の作り方と判断の注意点
顧客から届いた機能要望を、社内の印象だけで「必須」「あるとうれしい」に分けていませんか。Kanoモデルは、機能の充足と顧客の満足の関係を整理する考え方です。分類の根拠を顧客に確かめることで、開発前に確認すべき期待の違いが見えてきます。
この記事では、質問の準備と回答の読み方を扱います。工数や依存関係も含めた比較は、開発する機能の優先順位を決める方法で紹介しています。
- 機能の充足と顧客の満足を分けて考える
- 同じ条件で、機能がある場合とない場合を確かめる
- 回答の分布と根拠を残して開発判断へ渡す
Kanoモデルは機能の充足と満足を分けて考える
機能を増やしたぶんだけ、満足も同じように増えるとは限りません。欠けると困る機能と、なくても困らないが喜ばれる機能では、改善の意味が違います。
狩野紀昭らの論文「魅力的品質と当り前品質」は、品質を二元的に捉え、魅力的品質・当り前品質・一元的品質などに分類する考え方を示しました。公開抄録で扱われている調査対象はテレビと置時計であり、SaaSの開発効果を測定した研究ではありません。
米国品質協会のモデル解説を踏まえると、主要な違いは次のように整理できます。
| 分類 | 充たされた場合 | 充たされない場合 |
|---|---|---|
| 当り前品質 | 当然と受け止められる | 不満につながる |
| 一元的品質 | 満足につながる | 不満につながる |
| 魅力的品質 | 喜びにつながる | 必ずしも不満にならない |
この表は、機能名から分類を決めるための一覧ではありません。たとえば承認待ちの通知でも、毎日大量の申請を扱う人と、週に一度だけ確認する人では期待が違うかもしれません。どの顧客の、どの作業を対象にするかを先にそろえる必要があります。
また、分類は永続的な属性ではありません。利用状況が変われば期待も変わるため、以前の調査結果を使うときは対象者と確認時点も読み直します。
質問する前に一つの機能と利用場面を決める
顧客が同じ機能を思い浮かべられる説明を用意します。「通知を便利にする」のような表現では、メールの追加を想像する人と、通知を減らすことを想像する人が混ざります。
たとえば、架空の申請管理ツールで「承認待ちが残っている日に、未処理の申請一覧を夕方に一度メールで受け取れる機能」を確かめる場面を考えます。この説明には、通知の条件、内容、タイミング、届く場所が含まれています。
一つの質問に「メール通知と代理承認ができる」と二つの機能を入れないことも大切です。回答が好意的でも、どちらが評価されたのか分からなくなるためです。セットでなければ意味を持たない場合は、その理由を説明し、セット全体への回答として記録します。
質問を配る前には、説明を読んだ人に想像した動作を言い換えてもらうと、解釈のずれを確かめられます。画面案を見せる場合も、目立つ色や文言への好みと機能への期待を混ぜないよう、何を評価してほしいかを伝えます。
機能がある場合とない場合を対にして尋ねる
Kano調査では、一つの機能に対して肯定側と否定側の質問を用います。調査支援を行うDave Verduynの質問方式の説明でも、二つの質問を組み合わせて分類する方法が紹介されています。
先ほどの架空の機能なら、確認する場面は次の対になります。
| 質問側 | 質問文の準備例 |
|---|---|
| 機能がある場合 | 承認待ちの申請一覧を、該当する日の夕方に一度メールで受け取れるとしたら、どう感じますか |
| 機能がない場合 | 承認待ちの申請一覧をメールで受け取れず、画面を開いて確認するとしたら、どう感じますか |
ここでは、ない場合の現在の確認方法も示しています。機能がないことと、業務そのものが不可能なことを取り違えないための準備例です。肯定側だけに「確認漏れを防げる便利な通知」と価値判断を加えると、同じ条件での比較になりません。
上の文例は質問の対象をそろえるための準備例です。正式なKano調査には、回答選択肢と回答の組み合わせを判定する評価表が必要になります。採用する調査方式を確認し、質問・選択肢・評価表を一組として使ってください。自由回答の印象だけで正式な分類結果として報告しないことが大切です。
回答後に理由も聞くと、同じ選択肢を選んだ人の違いを確認できます。「なくても困らない」という回答には、今の確認方法で足りている場合と、通知を必要とする作業をしていない場合が考えられます。理由を省いて集計すると、次に確認すべき相手を見失います。
回答の分布と根拠を開発判断へ渡す
調査結果には、代表する分類だけでなく、回答の分布と対象者の条件を添えます。Verduynの説明も、顧客によって同じ機能の評価が異なる点を挙げています。回答が割れたときは、一つのラベルにまとめる前に違いを読みます。
たとえば、架空の通知機能への回答が、日常的に承認する人と閲覧だけする人で分かれたとします。この場合に残したいのは「魅力的品質」という結論だけではありません。承認作業の頻度、現在の確認方法、通知を不要とした理由も、対象範囲を決める材料になります。
記録には「対象の機能」「調査対象と回答数」「質問文と評価方法」「分類ごとの回答」「判断に使った理由」をそろえます。特定企業の回答者が多い場合は、回答者数と社数も分けて示すと、偏りを確認しやすくなります。少数の回答から顧客全体の割合を断定しません。
分類の役割は、何を顧客に確かめたかを開発判断へ渡すことです。工数、事業上の目標、既存機能との依存関係も並べて、着手・追加確認・見送りを決めます。魅力的品質という理由だけで開発を確約せず、判断理由と再検討する条件を残します。
よくある質問
社内の会議だけでKanoモデルを使ってもよいですか？
質問する候補を整理する用途には使えます。ただし、社内で付けた分類は仮説として扱い、顧客に確認した分類と区別してください。調査対象と質問方法が分からないラベルだけでは、開発の判断根拠として不足します。
回答が割れたら、いちばん多い分類を採用すればよいですか？
代表する分類だけで判断せず、利用場面や役割ごとの違いも確認します。回答数、分布、質問文を残し、どの顧客に向けた判断なのかを説明できるようにしてください。
KanoモデルとRICEスコアは同じものですか？
Kanoモデルは機能の充足と満足の関係を捉える考え方です。RICEは到達人数、影響、確信度、工数を使う比較方法です。Kanoの分類を、そのままRICEの数値へ変換できるものとして扱わないでください。
まとめ
Kanoモデルでは、機能の充足と顧客の満足を分けて考えます。同じ条件で機能がある場合とない場合を確かめ、回答の分布と根拠を残して開発判断へ渡すことが大切です。分類後に工数や事業の目標もそろえて比較する手順は、開発優先順位の決め方で確認できます。
