スタートはみんないっしょ
こんにちは、QAコーワヒーリングです。
テストエンジニアとして10数年いろいろとやらせていただいております。
進捗管理や顧客折衝、テスト設計などテストエンジニアの作業と言いましても色々とありますが、多くの方は テスト実施 をまずは担当されたのではないでしょうか？
わたしも心を無にして一心不乱にテスト項目を消化していくことで日々の達成感を感じていました。
テストは進む
わたしが最初に担当したプロジェクトはウォーターフォールだったこともあり、仕様書をベースにしたテストが主でした。
せかせかとテスト実施を進め予定された項目が完了したら、いわゆる探索的テストのお時間です。
ここからはいかに多くの不具合を見つけ報告できるかが生きがいとなります。
「毎日5件見つけるぞ！」などと思いながら「掲載文に余計な半角が空いてる」などのほんとーに些細なものから、重大な事象を引き起こすものまで項目が完了した後でもぽろぽろと見つかるものです。
仕様通りの動作ではある
さて、テスト項目を実施した時や探索的テストの際に、正常ではない動作が見受けられた際は「不具合だ！報告～♪報告～♪」と意気揚々と不具合レポートを作成してきますが、その際にこの挙動は正常ではないという指標・表現として「仕様書と異なる動作になっている」などその根拠を示すと思います。
わかりやすく「～の操作をしたら画面が固まって操作不能になる」なんて不具合だったら書きやすいですが、「おやっ」と少し違和感があるな程度の事象の場合はこの機能ってどういう仕様だっけと仕様書を確認するでしょう。
その時、その挙動が仕様書通りの挙動だったらどう判断しますか？
その仕様、果たして適切か
仕様通りの動作ならば不具合ではないと報告しても担当の人から「この動作は仕様です」と返ってきておしまいとなっていませんか？
ですが果たしてその 仕様 自体が本当に適切なのかを考えてほしいのです。
仕様書に書いてある通りの動作でも、その機能を実際に使用する人が使いにくいなと感じるならば意味はありません、いずれそれは市場でクレームとなり修正が必要になります。
そうなれば、その機能の妥当性確認の不足、JATQB的に言うなら機能適切性の確認が不足していないかを確認すべきでしょう。
我々テストエンジニアは仕様通りの動作を確認することはもちろんですが、それを実際にユーザーが使用したときにユーザーを満足させられるかを意識することが必要です。
私的には満足させられれば良い品質と言えると思っています。（もちろんその品質を実現および維持するためのコスパなどほかに考慮すべき点はあるのであくまでも個人の信条として）
品質を考える
品質 を考える時、今の私は「狩野モデル」を用いてどのような要素が不足しているのかを考えるようにしています。
Qiitaをご覧になる皆さんには狩野モデルがなんなのかは説明不要でしょう。
もしも聞いたことがないという方がいらっしゃったら「狩野モデル 品質」といった語句で検索してもらえればわかりやすく説明しているWebページがたくさんありますので本記事では説明は省かせていただきます。（私が説明書いたらパクリみたいな内容にしかならなそうですし(;^ω^)）
「使いにくいから改修してください」と報告しても実際に改善してもらうのは難しいでしょう。
「使いにくい」という指摘はあいまいですし、改修するにしても「使いやすくする」とはどのようにすればいいか悩ましいです。
まずは自分の中で言語化するための1つの手段としてこのモデルを使ってみるのはいかがでしょうか？
おわりに
「過去の自分に教えたい、ソフトウェア品質の心得」をテーマにバグ探しに明け暮れていた過去の自分に「このモデルを頭に入れて品質向上目指せ！」と言ってあげたいと思い、本記事を書かせていただきました。
良い品質を目指す中で「じゃあ良い品質とは？」を考えると漠然とはしているが、使いやすくしてほしい・わかりやすくしてほしいといった内容の報告になってしまいがちでした。
そこから一歩踏み出してその機能に足りない要素、それが顕在化するケース、その時使用者が感じる不便さ、それを解消するために必要な要素を考え言語化する時、狩野モデルは有効な手段と言えると思います。