SmartHR 品質保証部プロダクト基盤ユニットの紹介ーより良いものを目指して、品質の土台を築くー

こんにちは！QAエンジニアのyugeです。突然ですが、みなさんは継続しているものは何かありますか？わたしは、言語学習サービスDuolingoの英語版。連続学習日数が900日を超えました。お試し期間中に退会するのを忘れてしまったのが事の始まりなのですが、気づけば大台目前。継続は力なり！と願ってやみません。

品質保証部の連載企画も早いもので第6弾。ユニット紹介記事としては最後！わたしが所属するプロダクト基盤ユニットの活動内容について紹介します！

プロダクト基盤ユニットとは

品質保証部のユニット名の一覧。プロダクト基盤ユニットがフォーカスされている。 — 品質保証部の体制図

プロダクト基盤ユニットは、2024年7月に新設されたユニットです。労務領域の中で作られていたプロダクトチームが再編成されたことと、品質保証部の体制変更に伴い、新たに構成されることとなりました。

そもそも「プロダクト基盤」とは、労務領域とタレントマネジメント領域、そしてプラットフォーム領域の複数のプロダクトが必要とする共通の基盤のこと。その基盤を開発しているのが「プロダクト基盤チーム」です。プロダクト基盤チームの発足についての記事にもある通り、プロダクト基盤はマルチプロダクト戦略に向けてとても大きな役割を担っています。

品質保証部のプロダクト基盤ユニットが管掌するプロダクトや開発チームは、ドメイン領域も多岐にわたります。その中でもプロダクトの特性、チームの状況、開発のフェーズなどを踏まえ、課金基盤チームと権限基盤チームに注力することを選択しました。

これまでの品質保証部のユニット紹介記事でもあったように、労務領域の開発チームを横断したり、特定のチームに複数人で専任として携わったりと、チームへの関わり方は1つではありません。プロダクト基盤ユニットのQAメンバーは、集中して関わるべきチームを定めて継続的な品質保証活動をしていくための土台作りを進めています。それぞれ影響の大きなプロダクトであるため、コンテキスト理解にかかる遅延を排除し、どのようにアプローチするかを発見していく段階であると判断したためです。

次では、ユニットメンバーがどのような活動をしているのか、一部ご紹介します。

プロダクト基盤ユニットの活動

品質保証活動・テスト活動の土台作り

マルチプロダクト戦略が進む中で、「どこに力を入れ、何をやるのか」といった取るべき戦略を選択できる状態にすることが、ますます大きな意味を持つようになりました。そのために、各プロダクトチームが独立して品質保証活動、テスト活動できるようにすることは、目下、わたしたちが注力していることのひとつです。テスト戦略や方針をどう立てるか、なぜ必要なのかについてチームに共有したり、テスト分析の仕方や考え方、テスト設計技法について勉強会を開催するなど、チームと伴走しながらテスト活動の土台作りを進めています。

テスト実行では、プロダクトエンジニア(以下、PdE)と一緒にモブ探索的テストを実施する「モブ探」を開催しました。「テストの目的」「何が確認できればいいか」をチームで考えるところから始め、開発に携わるPdEと一緒にモブテストをする、といったものです。冒頭で立てた目的に応じて、どんな操作をすればいいのか、どんな結果を期待するのか話し合いながら進めていきます。このテストで目指すのは、「テストの目的が達成できること」です。そして、この活動のねらいは、テストの目的を統一し実践すること、テスト手法に対する理解を深めること、自分以外のメンバーが持つ観点や不安箇所を共有するといった「経験を積むこと」にあります。モブ探で出た操作観点が次の開発時に考慮され、不具合を未然に防いだり、テストの進め方を見直すきっかけにもつながりました。

これらの活動は、一日にして成らず。試行錯誤をしながら、経験を重ねられるような取り組みを引き続き考えていきます。

仕様策定や設計の段階から品質を担保する

各基盤チームが開発する機能は、その特性上、SmartHRを実際にご利用いただく方々だけでなく、SmartHRの機能を開発するプロダクトチームもユーザーとなります。影響範囲が非常に広くなるため、入念な検討と設計が必要不可欠です。

そのため、より早い段階からQAエンジニアの視点を取り入れ、要件定義やユーザーストーリーに基づいて検討漏れがないかを確認したり、将来を見据え、さまざまなパターンを考慮した設計になるように提案をしています。また、必要に応じて実現に向けた仕様策定を担うこともあります。

チームの状況や機能の特性に応じて取るべきアプローチも変わるため、まだまだ手探りな部分もあるのが現状です。どのような進め方や方法がよいのか、取り組みを通して最適な形を見つけていければと思います。

プロダクトコードの理解を深め、品質向上につなげる

テスト活動や、品質にまつわる知識の展開をしつつ開発中に作成されるPull Requestをすべて読む、「PR1,000本ノック（仮）」も実践しています。実際に1,000本見ることをゴールとしているわけではなく、「全部読むぞ！」という心意気の表れです。この活動では、PRレビューと、プロダクトコードを理解するための大きく2つの取り組みを進めています。

PRレビュー

PRレビューでは主に2点を確認しています。

処理実装に問題がないか
必要なテストパターンが揃っているか

レビュー段階で早期に不具合を見つけ修正することと、適切な単体テストが書かれていることで手動テストにかかるコストを削減したり、単体レベルで見つけられる不具合を見逃さないようにすることが目的です。

プロダクトコードの理解

プロダクトコードを理解するため、PRを読むことを起点として週に1回PdEに質問したり、実際にコードを動かしながら不明点を解消する場を設けています。これはプロダクトコードの構造、ロジックを理解することで、不具合が潜みやすい箇所や重点的に見るべき場所を判断する力を養うためのものです。また、プロダクトコードを理解していることで、不具合の原因箇所を特定でき、迅速な修正につなげられると考えています。

品質向上と開発効率の最適化につなげることと、プログラミングに関する知識・スキルを向上させることがこの取り組みのねらいです。取り組みをはじめた当初はコードを読むのに必死でしたが、現在では「わからない」と感じる点や確認の内容が変わりつつあり、少しずつですが確実に力になっていることを感じます。

プロダクト基盤ユニットの難しさとやりがい

わたしたちのユニットには「基盤の品質を作っていく」ことが求められています。

くり返しになりますが、プロダクト基盤ユニットはまだ生まれて半年の新しい組織です。どのように開発チームと関わり、どのような活動を進めていくのか、プロダクト基盤ユニットとして何を目指していくのかを決めるのはわたしたちで、今まさにその真っ只中にいます。

プロダクトマネージャー(以下、PdM)領域への関わりとして仕様策定や設計を進めたり、PdE領域への関わりとしてプロダクトコードを自ら修正するといった場面を作ったりと、他の職能領域に深く関わる機会も少なくありません。プロダクト基盤は異なるドメインをもった機能群で、多種多様なドメイン領域に関わる機会も多く存在します。

複数のドメインを理解することも、PdMやPdEの領域に入り込んで活動することも簡単ではありませんが、新しい発見と挑戦の毎日で、それがプロダクト基盤ユニットの良さであり、やりがいです。

より良いものを届けるため、プロダクトとともに、わたしたちも一緒に成長していければと思います。