今回は開発現場やネット記事などで私が感じる「狩野モデル（Kano Model）」のモヤモヤを言語化してみたいと思います。
はじめに：それ、本当に「品質」の話ですか？
「この機能、ユーザーにとって魅力的品質だよね」 「これはあって当たり前の機能だから当たり前品質だ」
開発の現場やプロダクト会議で、こんな言葉を耳にしたことがある人は多いのではないでしょうか。
また、ネット記事で魅力的品質や当たり前品質の具体例として「〇〇機能」と記載されているのを目にしたことがあるかもしれません。
一見すると、それぞれの品質にフォーカスした内容のようにも見えます。しかし私はそこに、なんとも言い難いモヤモヤを感じてしまうことがあります。
> それって、本当に「品質」の話をしているのかな？
> 単に「機能の話」を、それっぽく分類してるだけでは？
本記事では、このモヤモヤの正体を明らかにしつつ、「品質」と「機能」の違い、そして現場で狩野モデルを使う際のポイントについて、私なりの視点で整理してみたいと思います。 これはあくまで個人の見解であり、会社や製品の公式見解ではないことをご承知おきください。
品質と機能：なぜ混ざるのか？ なぜ違和感を持つのか？
まず前提として、品質と機能は別物です。 かの有名なG.M.ワインバーグ氏の「品質とは誰かにとっての価値である」という言葉を起点に考えてみます。
ここでの「誰か」は ユーザー であり、「価値」は 体験を通じ得られたこと・感じたこと と言えるでしょう。さらに、ここでいう「体験」は 製品に備わる機能の操作 と言えると思います。
このことから、機能と品質をそれぞれまとめると以下のように表現できるのではないでしょうか。
- 機能
- 製品に何が備わっているか（仕様や構造）
- 品質
- ユーザーがそれをどう知覚するか（主観的な評価）
例えば「このサイトは分かりやすい」というコメントがあったとします。 これは「UI 設計が優れている」という機能的な話ではなく、「（コメントしたユーザーは）快適に欲しい情報を得られた」という主観的な知覚=品質の話です。
この2つが混ざる理由は、言葉の抽象度や視点のレイヤーが一致していないまま会話が進んでしまうからです。 その結果、「魅力的品質」「当たり前品質」という言葉が分かりやすくキャッチーであることも加わって言葉だけが独り歩きし、言いようのない引っ掛かりを生むことになります。
では、その魅力的品質や当たり前品質などを定義した狩野モデルとはどんなものでしょうか。
狩野モデルを再確認する：分類は“知覚の変化”を表している
狩野モデルとは、プロダクトの品質要素(※後述)に対する物理的な充足状況 と ユーザーの満足感 の2つの側面から品質要素を5つに分類するフレームワークです。分類した結果、「ユーザーのニーズが分かる」「開発で取り組むべきものの優先順位がたてられる」などの効果があります。 フレームワークとしての手順は本記事では触れていきません。気になる方は調べてみてください。
| 分類 | 定義 |
|---|---|
| 魅力的品質(魅力的品質要素) | それが充足されれば満足を与えるが、不充足であってもしかたがないと受けとられる品質要素 |
| 一元的品質(一元的品質要素) | それが充足されれば満足、不充足であれば不満を引き起こす品質要素 |
| 当たり前品質(当たり前品質要素) | それが充足されれば当たり前と受けとられるが、不充足であれば不満を引き起こす品質要素 |
| 無関心品質(無関心品質要素) | 充足でも不充足でも、満足も与えず不満も引き起こさない品質要素 |
| 逆品質(逆品質要素) | 充足されているのに不満を引き起こしたり、不充足であるのに満足を与えたりする品質要素 |
出典：狩野紀昭他著「魅力的品質と当り前品質」『品質 1984年14巻2号』、日本品質管理学会、1984年、pp.147-156、https://doi.org/10.20684/quality.14.2_147
これらの概要は狩野モデルについてネットで調べるとよく目にするものです。 ここで重要なのは、この「定義」として説明されているものは “機能そのものの分類”ではなく、あくまで ユーザーがその品質要素をどう“知覚”するか（満足か不満足か）の分類 であるということです。
また、前項まで語られてきた「魅力的品質」や「当たり前品質」は品質要素の分類の一部に過ぎません。ここで語られる品質要素とは、読んで字のごとく品質を構成する要素です。前述の「魅力的品質と当たり前品質」の論文内では以下が挙げられていました。
- テレビの例
- 寿命、消費電力、アフターサービス、リモコン、映り具合、操作性など
- 置き時計の例
- 時間の進み・遅れ、電池交換のしやすさ、時計の大きさ、インテリア性など
品質要素についてネットで調べると「性能」「操作性」「信頼性」など、比較的抽象度の高い言葉で紹介されていますが、狩野モデルにおいて用いられる品質要素は、上記の例のように開発しているプロダクトに即した、より抽象度の低い内容でなければなりません。
QAエンジニアの提案：抽象度を揃えるための観点
ここまでの話からモヤモヤの正体は、「品質」と「機能」が異なる抽象度の話であるにもかかわらず、同列に語られることにあると分かりました。
このことから品質を話すうえで重要なのは、抽象度を揃えるよう意識することであるといえるでしょう。
では、抽象度を揃えるためにはどうすればいいか。いくつかの観点から考えてみました。
開発フロー（ディスカバリーフェーズ）の観点から捉える
ここでは開発フローの最上流であるディスカバリーフェーズにフォーカスします。
ディスカバリーフェーズでは「ユーザーが欲しているもの」を仮説を立て、調査し、検証しながらユーザーストーリーを作り、機能の輪郭を作り上げていきます。 冒頭に記載したワインバーグ氏の言葉の考察と照らし合わせ「ユーザーが体験を通じ得られたこと・感じたこと」を品質とすると、このユーザーストーリーの集まりこそ フィーチャー(機能) を構成する品質であると言えそうです。つまり、ユーザーにとっての価値（品質）が固まっていくことで機能の構想が作られていくフェーズであると言えるでしょう。
ユーザーの抱える課題やニーズ調査の動き自体を品質と結びつけるシーンはなかなかないかもしれませんが、ここで作られているものは正に狩野モデルの品質分類（魅力的品質や当たり前品質など）に準ずるものだと思います。
「品質」と「機能」の抽象度がズレるのは、上図のようにユーザーストーリーがフィーチャーを構成する細かな機能につながることによって、「細かな機能」側に焦点が引っ張られるからかもしれません。この関係性を意識することでズレは生じ難くなるのではないでしょうか。
プロジェクト管理の観点から捉える
上記ではディスカバリーフェーズに注目し、品質がどの抽象度に当たるかを記載しました。 ここではプロジェクト管理の観点から抽象度を合わせてみようと思います。
プロダクト開発に携わる多くの人が知っているであろうプロジェクト管理ツール JIRA にそのヒントはありました。
JIRAのデフォルトの課題タイプに エピック / ストーリー / タスク というものがあります。
「エピック」は大規模な成果物（新機能など）を定義する際に使用されます。
- エピック例
- レシピを簡単に検索する機能
「ストーリー」は「エピック(機能)」に対し、「誰にどのような価値を届けるか」を記載する最小単位で切り分けられたものです。ユーザーに届ける価値を定義する場なので、ここで語られる内容はエピックを構成する品質であると言っても良さそうです。 以下の例では分かりやすく「”だれ” が “何をする” か 。 なぜならば、”（その体験で）〇〇という価値を得られる” からだ 」というフォーマットで記載しています。
- ストーリー例
- "仕事で忙しい人" が "手間を掛けずレシピを検索" できるようにしたい。なぜならば "検索条件を0から考える面倒さをなくしたい" からだ
- "子育て中の人" が "栄養バランスが良いレシピを検索" できるようにしたい。なぜならば "子どもの健康に必要な栄養知識を得たい" からだ
- "料理初心者" が "簡単に作れるレシピを検索" できるようにしたい。なぜならば "料理に不慣れでも家族に美味しい手料理を食べさせたい" からだ
「タスク」はユーザーに届ける価値(ストーリー/品質)を更に分解した具体的な開発アイテムです。全てのタスクチケットが対象ではないですが、この粒度になるとストーリー（=品質）を構成する品質要素と言えるのではないでしょうか。
- タスク例
- カテゴリを選択するだけで該当のレシピが表示できるようにする
- 栄養バランススコアがn以上 のチェックボックスをつけ、該当のレシピが表示できるようにする
- 調理ステップ(手順)がn以下 を指定できるようにし、該当のレシピが表示できるようにする
上記の例ではそれぞれ「カテゴリ選択」「栄養バランススコアのチェックボックス」「調理ステップの指定」が品質要素と言えそうです。
まとめると、
- 「ストーリー」が複数集まってエピック（機能）が構成される
= 「ストーリー」 はエピック（機能）に対する品質の一部である - 全てではないが、「タスク」で作り込む内容はエピック（機能）に対する品質要素といえそうである
こう考えると抽象度も揃いやすくなるのではないでしょうか。
問いを持つようにする
「品質」と「機能」の関係性が異なる抽象度の話であるならば、抽象度を意識した問いを自分の中に一つ持っておくことが大切になります。 完全に自分を棚に上げて記載しますが、品質の話をする際は下記のような問いを意識してみるといいかもしれません。
「これはユーザーがどう感じるかという話か？ それとも機能の設計上の話か？」
まとめ
狩野モデルはあくまで「ユーザーの知覚」に基づく分類であり、個々の機能をそのままラベル付けするためのものではありません。そのため、抽象度の合わないまま「この機能は魅力的品質だ」と語ると、品質と機能の区別が曖昧になり、認識の齟齬が生じて表面的な理解に留まってしまうかもしれません。
品質を正しく語るためには、議論する内容の抽象度や文脈を意識し、粒度を合わせていくことが大切です。 魅力的品質や当たり前品質という言葉を“なんとなく便利なラベル”として使うのではなく、それがどの抽象度で、誰の視点から語られているかを意識することで、より精度の高い議論ができるのではないでしょうか。
本記事では狩野モデルの具体的な活用方法について詳しく触れていませんが、正しい理解の上で活用すれば、前述の狩野モデルの論文内に記載された置き時計の実証実験（商品企画時に導入し、従来の売上の3.5倍を達成）のように、大きなビジネスインパクトにつなげることができるかもしれません。
おわりに
本記事を書いていて「また違う視点から整理もできるのでは」「言葉が足りずうまく言語化できない」と感じた点も多々ありますが、ひとまず現時点で考えていたことは整理できたと思います。
冒頭でお伝えした通り、本記事の内容はあくまで個人の見解であり、一つの考え方です。必ずしも「これが正解である」と主張するものではありません。
同じようなモヤモヤを感じたことがある方に、少しでもこの整理が届けば幸いです。
We are Hiring!
本記事を読んで、SmartHRの品質保証部に興味を持っていただけましたら、カジュアル面談をぜひご検討ください。
私たちと一緒に新たなSmartHRの品質保証部を築いていきましょう！
品質保証部の募集職種一覧
YOUTRUSTのカジュアル面談のURL
