こんにちは！ヒューマンクレストの村上です。

私はヒューマンクレストでユーザー評価サービス「EMOLOG」を運営しています。実はQAとUXは相思相愛。今回はサービス運営で得た知見から「QAエンジニアこそUXを学ぶべき」という話をします。

UXってなんだっけ

UX（ユーザー・エクスペリエンス）ーーーー。「わかっているようでわかっていないビジネス用語ランキング」があれば上位に食い込むワードです。

それもそのはず。UXはデファクトスタンダートとなる定義がないままバズワード的に流行してしまい、今ではなんと27個の定義があります。

それらをすべて紹介していると日が暮れてしまう上に伝えたい本筋でもないので、今回はまず「さわり」だけ紹介しましょう。

一般的に、UXは「製品、サービスを使うことでユーザーが得られる体験のこと」と解釈されています。この体験は、誰が使用するか、使用する文脈（目的や環境）、また経験の蓄積によっても影響を受けます。

UXは「ユーザーの体験」という曖昧な領域を扱っている故に、複数の要素が絡み合っています。たとえば、ジェス・ジェームス・ギャレットはUXの要素について以下のように整理しています。

引用：UXって結局なに？スターバックスから学ぶユーザビリティ・UIとの違い

表層：視覚的なデザイン
骨格：情報の優先順位や配置
構造：全体構造
要件：必要な機能やコンテンツ
戦略：目的や意義

よくUI/UXと併記されがちですが、UIはUXのほんの一要素でしかありません。実際には、ビジネス要件やシステム要件など多くの要素が絡み合っている、それがUXなのです。

UXデザインは必ずしもデザイナーの仕事ではない

ここで押さえておきたいのがUXを作り込んでいく手段である「UXデザイン」は必ずしもUIデザイナーの仕事というわけではないということ。

もちろんデザイン案を形にして共有できる、という意味でデザインスキルはプラスに働きます。しかし、UXデザイン＝UIデザイナーの仕事という考えは間違いです。

UXデザインはUIデザイナーに「やっといて」と丸投げするものではなく「チーム全員で考え、取り組むべき仕事」です。

上に示した氷山の図にある通り、UXにはビジネス、システム、ユーザーニーズなど様々な要素が絡み合っています。そのため、主導するのは経営者、PM、PO、企画、デザイナー、エンジニア、誰でも構わないのです。

チームによっては「UXデザイナー」がいる場合もありますが、まだまだ少数派です。ここで提案したいのが、もしチームにUXの選任担当がいない場合、QAが主導してUXデザインを進めていくのはどうでしょうか。なぜなら、QAとUXは非常に相性がいいからです。

出会った美少女は、幼いころ結婚を約束した相手だった

・・・妄想は頭の中だけにしとけと怒られそうですが、これまでにもUXに近しい話がQAの世界では繰り返し行われてきました。

SQuBOKを勉強された方はピンときていると思うのですが、利用者品質や利用時品質と呼ばれる分野です。

品質特性（利用時の品質モデル）
魅力的品質・当たり前品質（狩野モデル）

最もイメージしやすいのは品質特性でしょう。
「有効性」や「効率性」はユーザビリティに通ずる話です。最近になって「満足性」の中に「快感性」や「快適性」という副特性も追加されました。

「狩野モデル」は魅力的品質・当たり前品質という概念が有名です。「システム的な不具合に対応するだけではユーザーは満足しないよね」ということを簡潔に表しています。

そもそも、なぜQAという仕事があるのかを考えてみると製品・サービスの品質とそれを作り込むためのプロセスの品質を向上していくためです。そうであれば、UXを追求することは、利用時の品質を追求することと同じ方向を向いているといえるのではないでしょうか。

また、QAとUXの関係性は双方向に影響しあうものです。
例えばシステムの不具合やリンク切れ、レスポンスタイムの遅さはユーザー体験に大きく影響します。また、たとえ仕様上の不具合がゼロでもユーザビリティに問題があればユーザーは不具合のように感じたり、不平不満を漏らしながら利用したりすることになります。

このように、QAとUXは相思相愛です。

であれば、QA担当者がUXのことを知っていても損はありません。QA担当者がUXデザインの手法を活用することで、ユーザーにとってのより高い品質を実現することができるのではないでしょうか。

能動的なQAが製品・サービスのUXを高める

QA担当者がUXにも切り込むーーーー。それを実現するためには、テストフェーズからのみでなく企画フェーズから入り込んでいく「能動的なQA」が必要になります。これは、AgileでもWaterfallでも変わりません。

出来上がってきたものに、ユーザビリティテストを行うのみでは不十分です。

例えユーザビリティが良くなっても、そもそもの要件がユーザーニーズとかけ離れているということも考えられます。するとせっかくの改善も「無駄な改善」になってしまいます。

そうならないために、そもそもの要件定義が正しいのか、ユーザーインタビューを行ってユーザーストーリーを描いたり、プロトタイプに対してユーザーテストを行ったりすることで、早い段階からUX≒利用時品質の作り込みを行なっていけるのです。

このことは、コストの面からも非常に重要です。

不具合と一緒で、出来上がってからUX上の問題が見つかっても修正コスト、すなわち手戻り工数が膨大になってしまいます。特にUXは要件定義に関わるので、ひときわ影響範囲が大きいです。これもなるべく早い段階で気付くことができれば、手戻りの影響は最小限で済みます。はしごを登りきってしまってから間違いに気付くより、はしごをかける段階で気づく方がはるかに効率的なのです。

それだけでなく、上流の企画フェーズからQAが参加することは製品・サービスの品質の向上だけでなく、プロセス品質を向上させるためにも有効です。能動的なQAは、一石二鳥であると言えるでしょう。

UXの作り込みのためには、誰かがチームを先導していくことが必要です。ここでQAが先導していくことで、本当の意味でのユーザーの品質が実現できるのではないでしょうか。

今回は概念的な話になりましたが、今後はQuesブログでも具体的なUXデザインの手法を紹介していきたいと思います。