はじめに
LITALICOでQAをしている@s_nrmです。
QA業務を行っていると、新機能リリースの際に「利用時品質」を十分に考慮できているか、という観点で考える機会が増えてきました。
一般的に、品質担保のフェーズでは新機能のテストを行い、挙動に問題がないかを確認します。しかし、画面が仕様通りに動くかどうかを確かめる以前に、「そもそもその設計自体に問題はないか」（ボタンの位置は適切か、誤操作を誘発しやすくないか、作業効率は向上しているかなど）、仕様そのものをテストする工程が必要ではないかと感じています。
そこで、仕様に対してチェックを行う「利用時品質の確認用ドキュメント（現在は「QA仕様書」と呼んでいます）」を作成し、検証を行う試みを始めています。
現状の確認
LITALICOでは多種多様なサービスを展開しており、QAエンジニアもそれぞれのサービスチームに所属して活動しています。まずは各サービスにおいて「利用時品質」に対するチェックが現状どのように行われているかを確認してみました。
各チームのQA仕様書の作成タイミングや使用タイミング、また記載している内容も各チームごとにバラバラで、同じQA仕様書という名前ではありますが内容はチームごとに全く異なる状態となっていることが分かりました。
一つ目のフォーマット作成
そこで各チームリーダーで話し合いを行い、QA仕様書に記載したい内容というものを纏めました
これを基に最初の雛形を作成したものが以下になります
意見が出たものを取り入れて、機能単位でQA仕様書を作成するものとして試用し始めたのですが。実際に使ってみると使いずらいと思う点がたくさん出てきました。
- パッと見で見にくい
- 項目数が多すぎて作成コストが掛かる
- 利用時品質っぽい項目と、機能観点のような項目が交差していて、どこが重要な内容なのか、どのように活用すればいいのかイメージが湧かない
- 各項目に記載する内容のイメージが湧かない。内容が似通っているものがあり、どこに何を入力するべきなのか分からない
- 利用時品質が満たせているかテストする際に、どの項目に記載されている内容をチェックすれば良いのか分からない
特に項目が多すぎて作成コストが掛かる点が大変でした。
頑張って書いても生かせない項目があったり、必要ないと思うものがあるなと実際に使ってみると感じられました。
フォーマットの改善
以上を踏まえて次に作成したのが以下のフォーマットになります。
記載すべき項目を一気に減らしました。
機能に対するユーザーストーリーを記載する欄があり、そのユーザーストーリーに対する
- DONEの定義（どのような機能が備わっていればこのユーザーストーリーは満たせているといえるのか）
- リスク（このユーザーストーリーが満たせていない場合、使用上どのような問題が発生する可能性があるか）
- ユーザーストーリーの発生確率
- ユーザーストーリーの影響度
- 発生確率と影響度からリスク評価を算出
を出すというものです。
項目数も一気に減り、この仕様書内で何を確認したいのかがスッキリするようになりました。
現在はこのフォーマットで実際の機能に対する利用時品質の分析を行い、利用時品質の観点から新機能の使いやすさなどをテストできるようにしていくために実践に取り入れているところになります。
さいごに
QAの役割を「仕様通りの確認」に留めず、利用時品質という「ユーザー体験」にまで踏み込んで考えることを、これからも大切にしていきたいと考えています。
より良いプロダクト作りを目指して、知見をアップデートしながら挑戦を続けていこうと思います。
最後までお読みいただきありがとうございました。