こんにちは！QAエンジニアのchokichiです。
実はSmartHRに入社して12月で5年を迎えました。それを記念して（？）初めてのTech Blogを品質保証部の連載企画の一環で書いてみたので、読んでいただけたら嬉しいです！
私は現在、品質保証部のプロダクト基盤ユニットに所属し、課金基盤の開発チームの中に入って品質保証文化の醸成をしています。
この記事では、複数あるプロダクトのうち「なぜ課金基盤チームに入るという選択をしたのか」と「実際にチームに入って半年間でどんな活動をしたのか」について書きました。
課金基盤チームになぜ入ったのか
そもそも課金基盤ってなんなの？という方は、プラン選択を柔軟に！課金基盤チームの挑戦の記事で詳しく紹介されているので、気になった人は読んでみてください。
さて、色々なプロダクトやプロジェクトがある中で、なぜ課金基盤にQAエンジニアとして入ったのか。
プロダクト作りに関わっている方ならピンと来るかもしれないですが、超簡単にいうと「お客様のお金に直結しているから」です。
じゃあお金に関わることならなんでもかんでも人を投入するのかというと、もちろんその限りではないです。人員には限りがあるので、ユニットとして「どのプロダクトやプロジェクトに集中して関わるべきか」という判断をしたうえで関わり方を決定します。
関わり方は大きく分けて2つあります。開発チームの中で品質保証文化を醸成していくのか、外から品質保証の支援をするのかです。課金基盤チームでは「中で品質保証文化を醸成していく」という選択を採りました。
ではなぜ課金基盤が「集中して関わるべき対象」となったのか。これについては「もし障害が発生した場合にどんなリスクが発生するのか」というのを考える必要があります。
課金基盤では主に以下のようなリスクが発生する可能性があると考えました。
- お客様の金銭的な損害が発生するリスク
- お客様が利用できるはずの基本機能やオプション機能が利用できないリスク
- 課金基盤で利用している外部システムを含む、運用面でトラブルが発生するリスク
機能が利用できないリスクについては返金などの対応が必要になる可能性がありますし、運用面でトラブルが発生すると請求業務が実行できない可能性があります。最悪の場合、どのリスクもサービスの解約に繋がりかねないものです。
これらのリスクの顕在化を未然に防ぐ必要があるため、課金基盤チームを「集中して関わるべき対象」としたわけです。
本題：この半年間（2024年下期）でどんな活動したの？
ここでは実際に半年間でどんな活動をしたのかについて、主に次の2つを紹介します。
- テストフローの構築
- 雇用形態別課金プロジェクトの仕様検討とDB/API設計
テストフローの構築
先述の課金基盤チームの記事にも記載されていますが、課金基盤チームはまだ生まれて間もないチームです。チームのメンバーのほとんどが別のプロダクトを開発していたところから異動してきました。そのため、開発体制を整えるところから活動する必要がありました。
私がチームに入ってまず行なったのは、現状どういった流れで開発〜デプロイが進行しているのかの確認です。現状を知らないことには改善すべき課題が明確にならず、誤った方法を取り入れてしまったり、チームで納得感のある活動が出来なくなってしまうためです。 その結果、テストの設計や実施といったフローの部分が各自のやり方でバラバラに実行されていることが分かりました。
このままでは再現性のあるテストフローにならず、メンバーの異動があるたびにカオス度が増していき、振り返りを行おうにも当時どんなテストフローだったか分からないから改善できないといった課題が出てきてしまいます。
なので、チームに入って最初にやったQAエンジニアとしての活動は、テストフローの構築でした。
具体的には以下についてルールを定め、チームで合意を得たうえで運用を開始しました。
- 誰がいつテスト設計をするのか
- 実装者が受け入れ条件と影響範囲を加味したテスト設計をする
- 誰がいつテスト設計物をレビューするのか
- 2人目のコードレビュアーがテスト設計物をレビューする
- 別途QAエンジニアもコード及びテスト設計物をレビューする
- 誰がいつテストを実施するのか
- テスト設計物をレビューしたプロダクトエンジニアがテストを実施する
- テストを実施した結果はどうやって証跡を残すのか
- テスト設計されたもののテストを実施した旨をPull Requestにコメントで残す
- 別途それ以外のテストを実施した場合は、それもPull Requestにコメントで残す
これと併せて、JIRAで管理しているタスクのチケットに以下のサブタスクを追加し、運用に乗せました。
- テスト設計
- テスト設計レビュー（プロダクトエンジニア）
- テスト設計レビュー（QAエンジニア）
- 手動テスト実施
テストフローの構築をした結果、実際に新しいメンバーが参入してきてもスムーズに受け入れられる状態になり、振り返りの時に「テストフローのこの部分について改善したい」という話題が出てもメンバー間で認識が合った状態で改善策を考えられる状態にできました。
また、サブタスクで作業状況の可視化ができるようになったため、「どんな状況なのか分からない…休日を跨いで記憶が…」といったことも無くすことができました。
雇用形態別課金プロジェクトの仕様検討とDB/API設計
雇用形態別課金プロジェクトについても先述の課金基盤チームの記事に記載がありますが、平たくいうと「これまでの課金基盤では実現できないDBの新しいテーブルとAPIが必要で、それらを用いた新しい運用フローが必要になる。実現できたらお客様の要望を叶えられてハッピー！」といったものです。（平たすぎますね）
ではなぜQAエンジニアが仕様検討やDB/APIの設計に関わっていったのか。
そもそも課金基盤というのはとても複雑な作りをしています。なぜ複雑なのかというと、大きく分けて2つの要因があると思います。
- SmartHRが世に出た当時から使われ続けているプロダクト（逆にいうと、使われ続けても大きな問題が発生していない安定性のあるプロダクト）であり、外部システムとSmartHRの基本機能を繋ぐためのAPIを提供するのが役割であること
- 請求に至るまでのロジックと運用フローが非常に複雑であること
これらの複雑さに立ち向かうためには、現行の仕組みを理解したうえで「どのようにすれば雇用形態別課金を実現できるのか」を深く考える必要があります。
そして深く考えるためには、外部仕様だけでは整合性の取れた正しいロジックとなっているかどうかの判断ミスやパターンの漏れが発生しかねないので、内部仕様まで踏み込む必要があります。
ではどうやったら内部仕様まで踏み込めるのか。その解として私が選択したのが、仕様検討やDB/API設計に自身が関わることでした。
関わるといっても、出来上がった仕様書やDB/APIの設計書を読むだけということではありません。自ら必要な仕様について提案・議論したり、雇用形態別課金を実現するために必要なテーブルやカラム、APIについて提案・レビュー・議論を行なってきました。
資料を読むだけなのと、自らが考えて提案できる形にするのでは、明確に理解の深さに差があると考えたからです。
その結果、複数プロダクトのコードを跨いでお客様に見せたいものをどのように実現させていくのかという解像度が上がり、既存を踏襲してよい部分と新しいものに置き換えるべき部分のイメージがつくようになり、運用フローまで見据えた議論へ参加できるようになりました。
これらができるようになることで、複雑かつ様々なパターンを考慮した内部仕様から必要な品質保証についてのアプローチを考える材料として、今後も活かしていこうとしています。
実際に品質保証についてのアプローチとして活用できているものもあるので、いくつか紹介しておきます。
- プロダクトエンジニアが実装したプロダクトコードをレビューし、パターンの考慮が漏れている分岐などがないか、テスト項目に不足がないか、必要な自動テストが実装されているかの確認ができるようになった
- 実現したいこと（＝改修が必要な箇所）とJIRAのチケットを紐づけることで、どこまで実現できたのか、チケットに不足が無いかを俯瞰して確認できるようになった
- 他部署も交えた運用フローについての議論で、カラム名が飛び交う中でも内容が理解できるようになり、パターンを考慮した実現方法について提案できるようになった
まとめ
他にも活動としてプロダクトエンジニアとプロダクトマネージャに対してデシジョンテーブルの活用について勉強会を開催したり、他プロダクトへどのような影響が出るのかを調査してまとめたりなど、改めて半年を振り返ってみると色々やってきたなーと感じます。
特にDB/API設計は未経験での挑戦だったので、こういった挑戦ができる環境と、プロダクトエンジニアと対等に意見交換できる環境が社内で当たり前のように存在しているというのがありがたいなーと思っています。
雇用形態別課金のリリースに向けてまだ道のりは長いですが、この半年間の活動を通じて得たものを活かしつつ、どのように品質保証していけばよいかを考えて実践していきます。
We are Hiring!
SmartHRでは一緒にSmartHRを作り上げていく仲間を募集中です！少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
