フレームワーク活用ガイドひとことで言うと#
顧客の要求を当たり前品質・一元的品質・魅力的品質の3つに分類し、「あって当然のもの」と「あると嬉しいもの」を区別して開発の優先順位を決めるフレームワーク。すべての要件が同じ重みではないという前提に立つ。
押さえておきたい用語#
- 当たり前品質（Must-be Quality）
- あっても満足度は上がらないが、なければ強い不満を生む要素。例: ホテルの清潔さ、ソフトウェアの安定動作。
- 一元的品質（One-dimensional Quality）
- 充足度に比例して満足度が上がる要素。例: バッテリーの持ち時間、料理の味。多ければ多いほど嬉しい。
- 魅力的品質（Attractive Quality）
- なくても不満は生まれないが、あると大きな満足・感動を生む要素。例: ホテルの無料アップグレード、予想外の便利機能。
- 無関心品質（Indifferent Quality）
- あってもなくても満足度に影響しない要素を指す。開発リソースを投下すべきでない。
狩野モデル優先順位付け法の全体像#
こんな悩みに効く#
- 機能の要望リストが長すぎて、何から作るべきか判断できない
- 「顧客が求めている」と言われるが、どの機能が本当に満足度に寄与するかわからない
- 競合と差別化するための投資先を見極めたい
基本の使い方#
優先順位をつけたい機能や要件を一覧にする。
- バックログ、顧客要望、競合分析から候補を集める
- 10〜20件 が分析しやすい。多すぎる場合は事前にスクリーニング
- 各機能は「○○機能がある/ない」の形で表現する
各機能について2つの質問をセットで聞く。
- 充足質問: 「この機能があったら、どう感じますか？」
- 不充足質問: 「この機能がなかったら、どう感じますか？」
回答選択肢（各質問共通）:
- とても嬉しい
- 当然である
- 何とも思わない
- 仕方ない
- とても不満
サンプル数は 30〜100人 が目安。
充足質問と不充足質問の回答の組み合わせで、各機能のカテゴリを判定する。
| 不充足で「嬉しい」 | 不充足で「当然」 | 不充足で「何とも」 | 不充足で「仕方ない」 | 不充足で「不満」 | |
|---|---|---|---|---|---|
| 充足で「嬉しい」 | ? | 魅力的 | 魅力的 | 魅力的 | 一元的 |
| 充足で「当然」 | 逆 | 無関心 | 無関心 | 無関心 | 当たり前 |
| 充足で「何とも」 | 逆 | 無関心 | 無関心 | 無関心 | 当たり前 |
| 充足で「仕方ない」 | 逆 | 逆 | 逆 | 無関心 | 当たり前 |
| 充足で「不満」 | 逆 | 逆 | 逆 | 逆 | ? |
回答者の過半数がどのカテゴリに該当するかで、その機能のカテゴリが決まる。
開発の優先順位を以下の順序で決定する。
- 当たり前品質: 最優先。欠けると致命的な不満→解約に直結
- 一元的品質: 次に優先。競合との差別化・満足度の向上に寄与
- 魅力的品質: 余裕があれば投資。ファンを作る要素
- 無関心品質: 見送り。リソースを投下しても効果なし
具体例#
状況: 従業員30名のSaaS企業。タスク管理ツールの次期バージョンで開発候補が 15機能 あるが、エンジニア3名で3ヶ月に実装できるのは5〜6機能。ユーザー120名に狩野式アンケートを実施。
分類結果
| カテゴリ | 機能 | 件数 |
|---|---|---|
| 当たり前 | 通知機能の安定化、モバイル対応、データバックアップ | 3件 |
| 一元的 | 検索機能の強化、カレンダー連携、繰り返しタスク | 3件 |
| 魅力的 | AIによるタスク自動分類、Slack連携、ダッシュボード | 3件 |
| 無関心 | テーマカスタマイズ、ゲーミフィケーション、SNS共有 | 3件 |
| 逆・矛盾 | — | 3件 |
開発計画
- v2.0（今四半期）: 当たり前3件 + 一元的2件 = 5機能
- v2.1（来四半期）: 一元的1件 + 魅力的2件
通知機能の安定化は「地味だが最優先」と判明。ユーザーインタビューでは「AIタスク分類が欲しい」の声が多かったが、狩野分類では魅力的品質であり、当たり前品質の未達を先に解決すべきという判断になった。
状況: 全国50店舗のビジネスホテルチェーン。宿泊客の満足度が 3.6/5.0 で競合（3.9/5.0）を下回る。改善候補12項目について宿泊客500名にアンケート実施。
分類結果
| カテゴリ | 項目 | 投資額（全店舗） |
|---|---|---|
| 当たり前 | Wi-Fi速度の改善、客室の清潔さ、チェックイン待ち時間短縮 | 3,000万円 |
| 一元的 | 朝食メニューの充実、ベッドの質向上、コンセント増設 | 5,000万円 |
| 魅力的 | スマートキー導入、客室のAlexaスピーカー設置 | 8,000万円 |
| 無関心 | ロビーの装花、館内BGMの変更 | 500万円 |
1年後の結果
まず当たり前品質3項目に 3,000万円 を投下。次に一元的品質からコンセント増設（800万円）を実施。
- 満足度: 3.6 → 3.9
- リピート率: 42% → 51%
- 口コミ評価: 「Wi-Fiが遅い」の不満コメントが 85%減少
Wi-Fi速度改善のような「地味な改善」が満足度を最も効率的に引き上げた。魅力的品質のスマートキー導入は翌年度に先送りし、限られた予算で最大の効果を得られた。
状況: 登録ユーザー5万人のオンライン学習プラットフォーム。ユーザーから寄せられた機能要望が 28件 。開発チーム5名で半年のロードマップを策定する。ユーザー200名に狩野アンケートを実施。
主要な発見
| 機能 | ユーザー要望の声の大きさ | 狩野分類 | 判断 |
|---|---|---|---|
| 動画のダウンロード保存 | 要望1位（最多） | 当たり前 | 最優先 |
| 学習進捗ダッシュボード | 要望3位 | 一元的 | 第2優先 |
| AI学習プラン生成 | 要望2位 | 魅力的 | 第3優先 |
| 動画の再生速度変更 | 要望8位 | 当たり前 | 最優先 |
声の大きさと狩野分類が一致しないケースが見つかった。「AI学習プラン生成」は要望2位だったが魅力的品質（なくても不満はない）。一方「動画の再生速度変更」は要望順位が低かったが当たり前品質（ないと不満が強い）。
要望の声の大きさだけで判断していたら、当たり前品質が後回しになり、解約率が上がっていた可能性がある。狩野分類によって「声の大きさ ≠ 優先順位」という重要な気づきが得られた。
やりがちな失敗パターン#
- 「顧客の声が多い機能」を最優先にする — 声の大きさと満足度への寄与は比例しない。狩野分類で当たり前品質かどうかを確認する
- 当たり前品質を軽視する — 地味な機能（安定性、速度、基本操作）こそ当たり前品質であり、欠けると致命的。華やかな魅力的品質より先に確保する
- アンケートの設計が曖昧 — 充足質問と不充足質問をペアで聞かないと分類できない。一般的なアンケート（5段階満足度調査）とは異なる
- 分類を固定的に考える — 時間の経過とともに、魅力的品質が当たり前品質に変わる（例: スマホの指紋認証は登場時は魅力的、現在は当たり前）。定期的に再調査する
まとめ#
狩野モデルは顧客の要求を当たり前品質・一元的品質・魅力的品質に分類し、「あって当然のもの」を最優先、「あると感動するもの」はその次という優先順位を明確にするフレームワーク。充足質問と不充足質問のペアで調査し、評価テーブルで機械的に分類する。声の大きさや開発者の直感ではなく、顧客の満足度構造に基づいた優先順位付けが可能になる。