QAエンジニアから見る前職と現職での品質の差異

この記事は、LITALICO Engneers Advent Calender 2023 シリーズ１の10日目の記事です。前日は、@katzumi さんの「登壇を支える技術」でした。

今年7月にLITALICOにQAエンジニアとして入社し、気付けば6か月目に突入してしまいました。
この半年弱で気づいたことや感じたことを、前職との比較をベースに振り返っていこうと思います。

前提

前職では第三者検証として、店舗内でスタッフさんが使用するアプリのテストに2年ほど携わっていました。
今は福祉・介護サービスの事業所が請求業務時に使用できるソフトウェアのQA活動を行っております。

ドメインもプロダクトの目的もユーザーも違いますし、私自身の役割も変化しているので、比べるには少し難しい部分もありました。
そこでまずは前職と現職の違いを表にしてみます。

プロダクトの違い

	前職	現職
ドメイン	リテール	福祉・介護サービス
プロダクト内容	接客用iOSアプリ 販売管理システム	請求用ソフトウェア
ユーザー	開発元の自社店舗スタッフ	顧客である事業所の職員さん
役割	第三者検証	自社プロダクトのQA

役割について

第三者検証とQAの違いについては、お世話になっている先輩 @yamahiro2022 さんが昨年投稿された記事「第三者検証からQAに転職してみて」をぜひ読んでいただきたいです！（宣伝）

ちなみに追加で私が個人的に感じている違いとしては以下です。

• 第三者検証
  • もちろん品質保証活動には最善を尽くすが、サービス提供者の立場として、責任の所在や組織としての印象なども若干意識して行動の範囲や方針を決めていた感覚
• 自社のプロダクト
  • 責任は全部自社（つまり自分）に返ってくるので、役割や立場的な制限に縛られることなく自由に品質を追求できる感覚

今回の比較について

前提はこのくらいにし、この記事では主にドメインとユーザという2つの観点から、テストないしQA活動の差異をまとめていきたいと思います。

セキュリティ面に関するお話は今回は含めておりません。

ドメインの違いによる差異

• リテール
  • 運用の想像がしやすい
    • いち消費者として関わった経験があれば、顧客の行動や気持ちが想像しやすい
    • 接客業の経験があれば、運用時に求める要素が想像しやすい
  • 必要な知識
    • 法令遵守などは基本ビジネス側でカバーされているので、プロダクトでどうにかする部分はあまりない（インボイスや個人情報についてくらい）
    • 海外展開などある場合は、法律・文化などによる特色の違いへの理解
  • 柔軟性
    • ビジネス側の判断により、イレギュラー対応が発生する可能性がある
      →逆に言うと、システムに不具合があった場合もオペレーションでカバーしやすい
    • セールなどのイベントのため頻繁な取得データの切り替えに対応できる必要がある

• 福祉・介護サービス
  • 運用の想像が難しい
    • 日常生活で実際に利用もしくは運用した経験がない人も多い
  • 必要な知識
    • サービスに関する専門的な知識(サービス種類はかなり多い)
    • 請求業務に関する法的要件
    • 自治体ごとに定められた要件
  • 柔軟性
    • 根本的な請求の流れは基本的に変わらないが、自治体毎に異なるルールや方式を採用しているサービスもあるためそれぞれ対応する必要がある
    • 法改正による大幅な変化とそれに伴う過渡期への対応が必要
    • 請求業務は法令に従って行うため、イレギュラー対応の可能性は低い
      →オペレーションで解決できるものではないため、システムの正確さがより求められる

ユーザーの違いによる差異

• 自社店舗のスタッフ
  • UI/UX
    • ユーザーが顧客へのメリットを最大化させられるかが大事
      →顧客へのサービス向上目的ではないユーザー体験や利便性の優先度は少し下がる
    • 顧客に関わらない部分での誤字などは、ユーザーに語弊なく伝わることが担保されているのであれば一先ず問題なし
  • 運用中に不具合発生の場合
    • オペレーション時に気付ける
    • 自社で即時対応ができる
    • ある程度のイレギュラー対応が可能
      例）顧客への損失が出ないよう自社で代わりに送料を負担する

• 福祉・介護サービス
  • UI/UX
    • 請求が法に従って正しく、規定の期間内に実施できることが最優先
    • 請求書類等ではない部分の誤字であっても、プロダクトの信頼性に関わるため大事な品質観点である
  • 運用中に不具合発生の場合
    • 利用中にユーザーが気づいてから、対応できるまでに時間がかかる
    • 請求業務を終え、自治体から結果が返ってきて発覚する場合もある
      →請求可能な期間が決まっているため、即時対応で解決できない

テスト・QA活動の変化

前職と現職で関わっていたプロダクトには前述の差異があり、それぞれのプロダクトの品質に関わりながら下記の違いを感じました。

• ユーザーが店舗スタッフ
  • ユーザーの先にいるお客様を想像してアプリの品質を定義しようとしていた
  • テスト設計・実施する際のシナリオや不具合によるリスクも、ユーザーというよりはお客様にどんな影響があるか（と、あとは企業への損失が出ないか）を逐一考えていた
  • その一方で接客業経験者としては、ユーザーである店舗スタッフの方がこれで少しは便利になるだろうという機能の追加に携わる時はとても嬉しかったことも覚えている

• ユーザーが事業所
  • まずは正確性が最も重要ではあるので、福祉・介護サービスの知識をつけ、変更や更新による影響範囲を考えられるように日々チームで勉強会をするなどしている
  • その上で、忙しい中で少しでも簡単に事務業務を済ませてもらえるようにするにはどうあれば良いのか想像しようとしている
  • 事業所・職員の方々をメインに想像して品質を考えている
    →このプロダクトを使ってどう感じるかユーザーの意見を重視

ただ、事業所が利用者への支援により多くのリソースを回せるように請求業務をお助けする、が目的のプロダクトなので「ユーザーとユーザーの先にいる誰かのための品質」という意味では似ているなと振り返りながら思いました。

終わりに

この記事を書きながらやや目的がほわほわしていたのですが、二つを比べたかったというよりは、QAとしてどんなアプリやシステムの品質にも適応できるようになりたいという気持ちを書きたかったのだと気付きました。
（LITALICOには様々なサービスがあるのでそれぞれに適応できるQAでいたいです。）

今携わっている福祉・介護の事業所で使用されるソフトウェアは、リテール店舗での運用とは違い、個人的には今まで運用の現場に携わったことがないため経験値から品質を定義することがより難しく感じています。

そのため以前よりもテスト技法やメソッドなどの必要性を感じており、勉強や情報収集の時間を多く取るようになりました。

LITALICOのQAチームでは任意参加の勉強会もメンバーの発案で実施されており、ソフトウェアテストの知識や演習・開発工程の知識・Web技術の知識・ロジカルシンキング…　などなど業務時間内でナレッジ共有し合える機会が多いのでその点とても助かっております。

今回は入社半年目の振り返りになりましたが、今後は法改正など大きなイベントもありますし、その時その時で品質に関して気付いたことを言語化していきたいと思います！