魅力的品質と品質特性
この記事はソフトウェアテストあどべんとかれんだー2014の12/16の記事になります。
今日は今年の心に残っているエピソードの1つを紹介し、それについて考えたことを紹介したいと思います。
あるとき、TEF道のお世話役の安達さんと品質特性の使い方の話をしていたときに、「製品やサービスに必要な品質を考えるときに、いきなり品質特性を使うとグッとくる製品はできないよ」ということを言っていました。
これを聞いて自分はハッとしました。Σ(゚Д゚;)
テスト設計コンテストに参加したときは網羅を意識して最初から品質特性を用いていました。また実際の業務でも品質特性に基づいて初めから品質の定義をすることが多かったと思います。でも確かに最初から品質特性を使うとヌケ・モレは防げますが、製品・サービスのコアになるべき機能が全くトガらずに、ありきたりなものになる可能性がありそうです。
この問題を解決するため(*1)に、狩野モデルを使ってこの製品・サービスのコアになるトガった機能とそれ以外の機能に分けて考えてみます。
- 魅力的品質 :製品・サービスのコアになるトガった機能
- 当り前品質 :上記以外の機能
順序的には、トガった機能にあたる製品やサービスの魅力的品質をまずしっかりと考え抜き、その後、当り前品質を考えるときにモレ・ヌケがないように品質特性を使うといいのですね (*・Д・)ナルホドネ-
ところで本当に魅力的品質かどうかはどうやったら分かるのでしょうか?
机上で品質特性の一覧とにらめっこしていても答えはでないと思います。 COOKPADの高井さんの発表(*2)から引用しますと、「要求事後性:ソフトウェアが要求を満たしているかは、ソフトウェアを使わないと判断できない」ということです。もちろん特定のドメインのソフトウェアに おいては簡単に使ってもらうことが難しい可能性もありますが、Webサイトやスマホアプリなどのソフトウェアは使ってみることでフィードバックを得ることができます。
リーン・スタートアップでいうところのMVP(Minimum Viable Product)で作り込む機能も、魅力的品質(と思っているモノ)に属する機能とその魅力的品質が成立するための必要最低限の当たり前品質の機能が対象になると思います。そしてMVPのリリースとフィードバックを繰り返していくことで、ユーザーにとっての本当に魅力的品質かどうかを判断していくのですね。
特に目新しくはないと思いますが、自分にとっては品質特性の使いどころを改めて整理する良い機会になりました。
次回はきょん君お願いします♪
*1 @snskが提案している品質特性自体に重みをつけて品質モデルを定義するという方法でも解決できそうです。詳しい説明はAndroidアプリテスト技法(秀和システム)を参照のこと。
*2 JaSST’14東北発表資料 https://speakerdeck.com/takai/cookpad-and-test-automation
2014/12/18 追記
安達さんからコメントありましたので、そのまま転記しておきます。
私のコメントの真意は「いきなり品質特性を使うとそれに一律はめ込んで満足する=特徴的な要素が尖らずに平坦にしてしまう人が多いんだよね」です。十分に使いこなすスキルを持っている方は大丈夫ですが、そうでない方が使うと特徴のない平坦な結果wwを出しがちなのでこのコメントになっています。それを防止する一つの手段として、①品質特性を使わずに特徴的な特性を明確にする(尖らせる)→②そのあと何か忘れているモノがないかを確認する意味も含めて品質特性を使う、というやり方を紹介しました。