【QA】狩野モデルから考える品質保証

[ミクシィグループ QAエンジニア Advent Calendar 2021](https://qiita.com/advent-calendar/2021/mixi_qa) 18日目の記事になります。
（既に1ヶ月過ぎてますがご容赦を…）


# はじめに
皆さんは**狩野モデル**を知っているでしょうか？
有名な言葉なので、知っている人も多いかと思います。
こちらは主に狩野モデルについて知らないQA初心者向けの記事となります。
改めて狩野モデルについて復習したいQA中級者以上の人も是非読んでいただけたらと思います！

# 狩野モデルとは
1980年代に東京理科大学名誉教授の狩野紀昭（かのう のりあき）さんが提唱したモデルです。
海外では『Kano Model』と呼ばれています。

今から40年ほど前に提唱されたモデルにも関わらず、
現在でも品質保証・マーケティングの分野では重要な指標となっており、
海外でも通じる概念となっているのがすごいですね。

# 狩野モデルの定義
狩野モデルには5つの品質要素があります。

### 当たり前品質
充足されていても当たり前と受け取られるが、不充足であれば不満を引き起こす品質要素のこと。
<font color="Red">ユーザーが「あって当たり前」と思う品質レベル</font>を指します。

```
例）
テレビ：電源が付く・音声が聞こえる・チャンネルが変更できる
車：エンジンがかかる・ブレーキが利く
```

- - -

### 一元的品質
充足されていれば満足を引き起こし、不充足であれば不満を引き起こす品質要素のこと。
<font color="Red">あると嬉しいが、ないとユーザーの不満につながる品質レベル</font>を指します。
製品のスペックなどがここに該当します。

```
例）
テレビ：薄型モデルかどうか・解像度が高いかどうか
車：燃費が良いかどうか
```
- - -

### 魅力的品質
充足されていれば満足を引き起こすが、不充足であっても仕方ないと受け取られる品質要素のこと。
<font color="Red">なくても不満はないが、あるとユーザーが満足する品質レベル</font>を指します。

```
例）
テレビ：3D視聴ができる・ディスプレイが透過する
車：車内Wi-Fiが利用できる
```
- - -

### 無関心品質
充足されていても不充足であっても満足度には影響を与えない品質要素のこと。
<font color="Red">あってもなくてもどちらでもいい品質レベル</font>を指します。

```
これに関しては例を挙げづらいですが、普段ユーザーがほとんど使用しない機能などが該当します。
テレビだと説明書などが該当する……？
```
- - -

### 逆評価品質
充足されていれば不満を引き起こし、不充足であれば満足を引き起こす品質要素のこと。
<font color="Red">あると逆にユーザーにとってよくない品質レベル</font>を指します。

```
例）
テレビ：dボタンのメニューが常に開いた状態になっている
車：カーナビ音声案内の頻度が高すぎる
```

# 狩野モデルからQAに落とし込む
では問題です。
①～⑤の中で、どの品質要素を最優先でQAすべきでしょうか？

①当たり前品質
②一元的品質
③魅力的品質
④無関心品質
⑤逆評価品質

・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・
・

**答えは「①当たり前品質」です。**
何故①が正解かというと、
当たり前品質の基準を満たしていないものは
製品としての機能要件を満たせていないからです。

当たり前品質で挙がる要素はテストケースにおいても
必ず項目に含まれる要素になります。
つまり、基本機能周りのテストケースを作る際に悩んだら、
プロダクトにおいての当たり前品質が何なのかを確認すれば良いということです！

## 当たり前品質以外の優先度は？

### 一元的品質・魅力的品質
「②一元的品質」「③魅力的品質」は高くなることでどちらもユーザー満足度が上がります。

「②一元的品質」については、競合他社製品と比べられる要素になるので、
市場のトレンドや製品自体の知識を持ち合わせたうえで、品質レベルを上げていく必要があります。
「③魅力的品質」は市場に大きなインパクトを残せるため、効果が高いです。

例を挙げて考えると分かりやすいかもしれません。
**<font color="blue">②一元的品質：テレビの画質が良くなる・音質が良くなる
③魅力的品質：ブラウン管テレビから薄型液晶テレビになる**</font>

③の方がよりユーザー満足度が上がります。
会社やプロダクト自体の評価も上がるため、魅力的品質を意識したQAを行えると良いです。

### 無関心品質
「④無関心品質」については、QA不要とまでは言いませんが、
コストをかけてQAを行ったとしてもユーザー満足度に繋がりにくいため、優先度は低くなります。

### 逆評価品質
「⑤逆評価品質」は、ないがしろにしてはいけない要素です。
これが含まれた状態でリリースしてしまうと、ユーザー離れを起こしかねないからです。
そして厄介なことに、テストケースで拾いにくい部分でもあります。

QAとしてできることは以下でしょうか。

- 仕様段階で逆評価品質に繋がってしまう要素がないかを確認・指摘する
- プロダクト理解を深め、メインユーザーと同じ目線でQAする
- ABテストを実施し、数値から調査を行う
    - これはどちらかというとマーケティング要素の方が強いかも

## 優先度まとめ
あくまで個人的な基準ですが、以下のように考えています。

**当たり前品質 ＞ 魅力的品質・逆評価品質 ≧ 一元的品質 ＞ 無関心品質**
※ここでは影響度の大きい順で優先度をつけています
※現状より良くすること（魅力的品質）と現状より悪くしないこと（逆評価品質）を同率に考えています

プロダクトによっては
「より良くする方（魅力的品質・一元化品質）に重点を置く」
「不満に繋がる品質要素（当たり前品質・一元化品質・逆評価品質）のみを一旦カバーする」
「一元的品質の向上を積み重ねて、地道にユーザーにアプローチしていく」
など方針があるかと思いますので、各品質の優先度はケースバイケースかなと思います。

# 当たり前品質の基準は変わっていく
時代によって「当たり前」は変化していきます。
例えば今の時代にスマホではなくガラケーを使えと言われても、多くのユーザーは満足しないと思います。
20年前は「ガラケーが当たり前」でしたが、今の時代においては「スマホが当たり前」だからです。

年月の経過だけではなく、モノやコトの流行で変わる場合もあります。
コロナ禍になってからは、店頭に消毒液があったり、席の間隔を空けたり、といったことが「当たり前」になりました。
今、感染対策を一切していないお店に行こうと思う人はかなり少数だと思います。
こういったものが絡み合って、当たり前品質の基準は日々変わっています。

- - -

さて、QAの話に戻します。
「2年前にプロジェクトAで実装した機能をプロジェクトBでも実装したい」という依頼があったとします。

QAはプロジェクトAのテストケースを流用して、プロジェクトBのテストケースを作ります。
「2年前と同じ内容のテストをしておけば大丈夫」という言葉に危機感を覚えませんか？

機能は全く一緒だったとしても、2年前と今では当たり前品質の基準が変わっています。
『当たり前品質で挙がる要素はテストケースにおいても必ず項目に含まれる要素になる』と前述しましたが、
上記を踏まえると、テストケースの内容が大きく変わる可能性があります。

過去のテストケースを流用する際は、
現状の当たり前品質に即したものになっているかを改めて確認しましょう！

# 自分が思っている魅力的品質は本当に魅力的品質なのか
市場のトレンドや製品自体の知識が欠乏していると、
どの機能がどの品質要素に属しているのか見誤ってしまうことがあります。

- 魅力的品質だと思っていたが、ユーザーにとっては当たり前品質だった
- 魅力的品質だと思っていたが、ユーザーにとっては一元的品質だった
- 魅力的品質だと思っていたが、ユーザーにとっては無関心品質だった
- 魅力的品質だと思っていたが、ユーザーにとっては逆評価品質だった

どのパターンもユーザーにマイナスなイメージを与えかねないので結構怖いです。
開発者目線で物を作っていると、ユーザーの実態から乖離しやすくなるので
常にユーザー目線での意識を忘れないようにしましょう。
関係者で仕様レビュー・プロダクトのデモレビューなどを繰り返したり、
ユーザーインタビューなどで利用者の声を聴いてみるのも良いかもしれません。

# まとめ
- 狩野モデルには5つの品質要素がある
    - 当たり前品質・一元的品質・魅力的品質・無関心品質・逆評価品質
- 当たり前品質の基準を満たしているかどうかを最優先にQAする
    - それ以外の品質要素の優先度はケースバイケース
- 当たり前品質は時代・流行などで変化していく
- どの機能がどの品質要素に属しているか見誤らないようにユーザー目線を意識する

皆さんの担当しているプロダクト内における、各品質要素は何でしょうか？
狩野モデルを参考にして、是非考えてみてください！