QAエンジニアが考える、魅力的品質を上げるために何をしたらいいのか
導入
自社製品の品質を上げたいと思ってネットの情報を探しにいくと、当たり前品質・魅力的品質という考えを目にすることがあると思います。
魅力的品質を上げていきたいと考える人が多いと思うが、自社製品がどのレベルにあるのか？どうしたらそれぞれの品質が上がるのか？の把握は難しいと感じているのではないでしょうか？
この点についていったんの結論が出たので残しておきます。
誰に充てて書くか
機能の仕様や対応方針を決めるPDMやマネージャー、品質に深く関わるQAエンジニア等
結論
先に結論を書くと僕は以下のように理解しています。
- 当たり前品質、魅力的品質どちらもユーザー（顧客）から見た品質である
- 当たり前品質：顧客、ユーザーが認識している問題を解決するもの
- 魅力的品質：顧客、ユーザーが認識できていない or 諦めている問題を解決するもの
- 当たり前品質、魅力的品質どちらに影響するのかは基本的に案件決定時～要件定義時に決まることである
- 魅力的品質を上げるためには顧客理解が重要
- 魅力的品質を上げる方針はより便利に、より広く
こう考えた理由をここから記載していきます。
当たり前品質・魅力的品質とは？
当たり前品質・魅力的品質とは品質を機能の充実状況と顧客満足度の2軸で表現した狩野モデルに登場する5つの品質の中の2つです。（参考）
- 当たり前品質：有って当然で、無いと評価が下がるもの
- 魅力的品質：無くても評価は下がらないが有ると嬉しいもの
考えてみたら当然のことですが、品質とは全てユーザーの目線で定義されるものです。
（製作者がどれだけ良いと思っていても、ユーザーに不評であれば顧客は増えない）
だからこそ、自社製品の品質をどう定義するのかが難しいのですが、顧客目線で考えるとこのような表現もできると考えました。
- 当たり前品質：顧客、ユーザーが認識している問題を解決するもの
- 魅力的品質：顧客、ユーザーが認識できていない or 諦めている問題を解決するもの
この定義に当てはめて考えると、以下のように判断できます。
- 競合他社製品で対応しているところは出来ていて当たり前と思われてもおかしくない → 当たり前品質
- この作業が大変だという認識があるところは出来ていてほしいと思う → 当たり前品質
- 実は大変だが今までのやり方しかないと思っている（解決できる問題だと認識していない） → 魅力的品質
- 大変さは認識しているが、これが当たり前だと思っている → 魅力的品質
これが現時点での当たり前品質・魅力的品質の理解です。
また、”品質”と付いているためテストで担保する印象を持つ人も居ると思いますが、
上記の通り、当たり前品質・魅力的品質どちらも機能・サービスそのものに紐づく考え方なので、テストフェーズではなく対応案件の決定や要件定義等の上流工程でほぼ決まる品質であると理解しています。
→ 案件が決まった時点で当たり前品質を上げる者なのか魅力的品質を上げるものなのか決まる
魅力的品質を上げるために何をすべきか？
当たり前品質・魅力的品質の説明をしたうえで、実際に何をしたら魅力的品質が上がるのか？について述べていきます。
一言に「無くても評価は下がらないが有ると嬉しいもの」と言っても、そんなものは顧客によって違うため、なにが魅力的かを定義するのは不可能では？と思っていました。
また、最初魅力的だったとしても時間が経てば当たり前になってしまう。
現時点での魅力的はどう見つけたらいいのだろう？とも。
結論を述べると、あらゆる顧客にとっての魅力的品質を定義するのは不可能です。
顧客によってどの機能を魅力的に思うかが違うためです。
ですが、一般化することはできました。
- 当たり前品質：顧客、ユーザーが認識している問題を解決するもの
- 魅力的品質：顧客、ユーザーが認識できていない or 諦めている問題を解決するもの
この定義をベースに何が必要かを考えると、顧客がどんな業務をしていて、なにに課題を感じているのか？が最重要であることがわかります。
また、先に述べた通り上流工程で品質が決まるため、必要なのはマーケティング分野の知識や技術です。
僕は品質とマーケティングをすぐに結びつけられずに、当たり前品質・魅力的品質の理解にとても手間取りました。
ただし、顧客の業務や課題を正しく把握できただけでは魅力的品質を上げることはできません。
そもそも、僕が定義した内容だと顧客が課題だと認識していないので、開発案件として挙げることが難しいです。
そこで、思いついたアプローチ方針を残しておこうと思います。
- 今の業務をより便利に
- 今対応できている業務の前後の業務もカバーする
今の業務をより便利に
競合含めすでに対応できているものでも、より効率的に・より低コストに対応できる製品ができれば、それは魅力的品質になりうると考えています。
すでに製品で対応できており、顧客が課題を感じていない可能性が高いためです。
この方針では以下のような指標が考えられます。
- より業務にかかる時間を減らせる
- よりコストを減らせる
- よりコンパクトに設置できる
今対応できている業務の前後の業務もカバーする
顧客が認識していないから考えると、より広い業務をカバーできるように開発するのも、魅力的品質が上がると考えています。
”既存の製品ではここまで”という認識が当たり前になっている可能性が有るためです。
QAとしてどうかかわるか
最後に、QAとして当たり前品質・魅力的品質にどう係わっていけばいいかを述べます。
あくまで、個人の考えなのでこれが正解かどうかは今後も考え続けていきます。
まず、当たり前品質・魅力的品質が上流工程で決まるからといって、QAとして意識してはいけないというルールはありません。
品質を預かるものとして、顧客の業務・課題は常に意識するように心がけてますし、これからも変わりません。
上流工程で決まってから何も対処できないのも嫌なので、要件定義の時点でおかしな点に気づけるように首を突っ込んでいこうと思います。
今はこの考えで案件に関わるようにしています。
また、考えが更新されたら記事を更新します。
記事の理解に至るまでの経緯
ここから下、どう考えてきたかを残しているだけなので新しい情報はありません。
マーケティング観点との関連でもやもやしていたこと
マーケティングについて勉強したことの有る人であれば、商品の価値は顧客（ユーザー）の悩みを解決することであるのような言葉を聞いたことが有ると思う。
そのためにペルソナを設定したりヒアリングしたりして、顧客の本質的な悩みや課題を掘り出すことに力を注いでいる。
この考えが間違っていると思えなかったため、開発の際あたり前品質・魅力的品質を上げるという見方で考えるのがなじまず、ずっともやもやしていた。
みんな魅力的品質を上げたがるが、そもそも顧客が望んでいることを軽視していないか？？と
製品のどの機能が魅力的品質なのか？
マーケティング観点とのうまく繋がらずもんもんとしていながらも、魅力的品質とはなにか？を考えていた。
一言に「無くても評価は下がらないが有ると嬉しいもの」と言っても、そんなものはユーザーによって違うため、なにが魅力的かを定義するのは不可能では？と思っていた。
また、最初魅力的だったとしても時間が経てば当たり前になってしまう。
現時点での魅力的はどう見つけたらいいのだろう？
しばらく悩んでいたが、keyenceの解説本を読んだ時に気づいた。（とにかく情報共有の体制や素材解析の製品のエピソードが参考になった）
ユーザーが認識している問題は他社も当然対応している。
ユーザーが認識できていなかった問題、今まで不便さが当たり前だと思っていた問題、これを解決するものが魅力的品質に当たるもの。
魅力的品質を上げるために結局何をしたらいいのか？
魅力的品質を「顧客、ユーザーが認識できていない or 諦めている問題を解決するもの」としたが、どうすればユーザーが認識できていない問題を見つけることができるのか？
やることは変わらず、とことんユーザーの業務を理解・深堀することだと思う。
これだと行動に移せないのでもう少し方針のようなものを考えてみた。
※ 先のkeyenceを例にとるなら、とにかく必要な情報は全社員に共有されている。
- サービスのメイン機能が解決する業務（既に対応できている業務）の前後の業務を考える
- 「より便利に」を深堀る
Discussion