品質保証部カジュアル面談資料（2025/7/1更新）

SmartHR 品質保証部のカジュアル面談時に利用している資料です。

Transcript

1. 品質保証部 紹介資料 2025/7/1更新
2. ・沿革 ・開発体制 ・ビジョン・ミッション ・体制と活動例 目次
3. 沿革
4. 品質保証部のざっくり沿革 • 2019年4月：1人目のQAメンバーが入社
 • 2020年2月：プロダクトごとにQAメンバーが配属される体制が開始
 • 2021年6月：一部チームにおいてテスト活動移譲の取り組み開始
 • 2022年4月：一部チームにおいてQAE専属解消の周知
 • 2022年4月：品質保証部直下 overallチーム 誕生
 • 2023年7月：QAE専属スタイルからユニット単位で受け持つスタイルに変更
 • 2024年7月：ユニットを役割ごとに再組成
 • 2025年1月：overallチームがレバレッジ推進ユニットとしてユニット化
 • 2025年7月：労務ユニット体制の更新
 現在のスタイルをより進めていくためにも新たなメンバーが必要な状況
5. 開発体制
6. SmartHRの開発体制 • 開発の体制や流れはチームなどによって異なります • 詳しくは次の資料を参照してください ◦ https://hello-world.smarthr.co.jp/
 ▪ プロダクトエンジニア採用サイト

7. ビジョン・ミッション
8. ビジョン（目指す姿） ビジョン（目指す姿）： 良いサービスを早く提供し続ける そのためには、組織全体として次ができている必要があります。
 
 • 早い段階で見つけられる不具合を見つけている • 見つけられなかった不具合においてもリリース後に見つけられている 
 上記を達成するには、開発ライフサイクルの中のすべてのステージにおいてQA観点をもってアクションが 必要です。
 全体的な視点で考えるには、対象となるプロダクト特性や開発チームの状況に応じて判断する必要があ ります。
 それによってステージにかかる、かけるべき工数も変わってきます。
 
 そのためには、どのフェーズをどのようにグラデーションをつけて関わっていくかをチーム単位で考えられ る必要があります。
 

9. ミッション（責務） ミッション（責務）： 継続的に品質保証できる体制をつくる この「体制づくり」は「品質保証部」という部のことでもあり、開発チームや会社全体も含めた話になりま す。
 
 目指す姿に向かって進むためには、私たちが「今おこなっていること」を開発チームで当たり前にし「次の 当たり前」を作っていくことが重要になってきます。
 この「次の当たり前」をQAの専門家である私たちが考え、そして作っていくということを継続的に追求して いく必要があります。
 
 「サービス開発に関わる全ての人がQA活動をおこなうだけでなく、そのQA活動のレベルを継続的に向上さ せていく」 私たちが今おこなっていることを「当たり前」にし、次のステップに持っていくというサイクルをまわすことで「目指す姿」 に近づいていきます。

10. 体制と活動例
11. 品質保証部の体制 品 質 保 証 部 レバレッジ推進 ユニット ・特定プロダクトを対象としない ・プロダクト基盤全般 ・スマートフォンアプリ ・プラットフォーム事業 ・ID管理　など プロダクト 基盤ユニット タレントマネジメント ユニット ・配置シミュレーション ・スキル管理 ・採用管理 ・人事評価　など チーフ （兼） メンバー メンバー メンバー マネージャー チーフ メンバー ＼募集中／ メンバー ＼募集中／ メンバー ＼募集中／ チーフ 労 務 ユニットA ユニットB チーフ メンバー チーフ メンバー メンバー ＼募集中／ 横断チーフ （兼） ・フロントシステムエリア ・人事マスタエリア ・給与計算エリア ・勤怠管理エリア ＼募集中／ チーフ （兼）
12. 労務（ユニットA） • 目指す姿 ◦ 各開発チームと適切な形で連携しながら、良いサービスを早くユーザーに提供するためのプロダクト作りに貢献する • おこなっていくこと ◦ 前提：SmartHR基本機能を擁する労務ドメインの品質保証観点として、広い機能連携の視点を持つ
 ▪広い機能連携：ここでは基本機能が多くの他プロダクトの連携元であることを指している ◦ （１）各開発チームとの関わり方、関わるべきフェーズの適切な判断と課題の解決
 ◦ （２）各開発チームが自律的に品質保証体制をアップデートしていけるような提案とバックアップ
 ◦ （３）上記の活動に必要なスキルの把握と獲得
 • 今おこなっていること ◦ 開発チームに所属せず、管掌プロダクトの品質課題の解決をサポート ◦ 新規プロダクトの開発チームに所属し、品質保証活動を実施 • 今後やっていきたいこと ◦ 現状の可視化 ▪ ユニットメンバーのスキル、今後必要になるであろうスキル ▪ 開発チームやプロダクトの品質 ◦ 可視化した内容をもとに開発チームとの関わり方と内容の幅を広げる
13. 労務（ユニットB） • 目指す姿 ◦ 各開発チームと適切な形で連携しながら、良いサービスを早くユーザーに提供するためのプロダクト作りに貢献する • おこなっていくこと ◦ （１）管掌プロダクトの品質保証活動で得た経験・知見を他の管掌プロダクトが活用できる状態にする ◦ （２）各開発チームとの関わり方、関わるべきフェーズの適切な判断と課題の解決、またそれを効率よく行なえる体制の構築 ◦ （３）上記の活動に必要なスキルの把握と獲得 • 今おこなっていること ◦ 開発チームに専任でQAエンジニアが所属し、品質保証・支援を実施 ◦ 開発チーム外からユニットが管掌しているプロダクトの品質課題の解決をサポート ◦ プロダクト・チームの状況を定量的に評価するための指標の検討と導入 • 今後やっていきたいこと ◦ コード品質に対しても分析・リードができるようにする ◦ 労務プロダクトを横断的に使用する視点に立った品質の向上
14. • 目指す姿 ◦ プロダクト基盤が安定して「良い」を保ち続けられるようにする ▪ 「良い」・・・ 価値検証された基盤が安定して動作し続ける状態 ▪ 「価値検証された基盤」・・・マルチプロダクトにおける負を解消し、プロダクトシナジーを作りだすことで、マルチプ ロダクトとしての価値を高められることが検証された基盤 • おこなっていくこと ◦ プロダクト基盤の開発チームが「良い」を保ち続けられるように、各開発チームにあったプロセスを構築し、再現性を持 たせられるようにしていく • 今おこなっていること ◦ プロダクト基盤のうち、特にリスク・影響が大きいと判断したものを優先して取り組んでいる • 今後やっていきたいこと ◦ 良いサービスを早く提供し続けるために、各開発プロセスにおいて具体的にどのようなQA視点を持つべきか実践を通じ て見極めていく ◦ 各開発プロセスのQA視点のうち、開発チームが担う部分とQAエンジニアが担う部分を判断し、QAエンジニアが担う部 分に注力できる状態にしていく プロダクト基盤
15. • 目指す姿 ◦ タレマネプロダクトが「良いサービスを早く提供し続ける」状態にする ▪ 良いサービス・・・ユーザーへ価値を生む、いつでも意図した通りに使える状態 ▪ 早く提供し続ける・・・良いサービスの水準を保ちつつ、付加価値を生むために割けるリソースが最大化されている 状態 • おこなっていくこと ◦ まずは各タレマネプロダクトが安定したものを出し続けられる状態にする ▪ 品質に対する不安を取り除けるように伴走していき、開発チーム自ら品質を担保できる範囲を広げていく • 今おこなっていること ◦ 開発チームが不安を覚えているフィーチャーや開発アイテムのテスト活動を支援する ◦ 開発チームが安定したものを出し続けるためのプロセスを構築し、移譲する • 今後やっていきたいこと ◦ テストの目的や責務を明確にし、より効率的に守るべきところを守れるようにしていく ◦ 守るべきところで守るために必要な知識・技術を習得していく タレントマネジメント
16. • 今後やっていきたいこと ◦ 職種間のQA認識ギャップを解消し、全社横断的な視座向上による品質担保の取り組みを加速させていく ◦ AIプロダクトに関する品質保証方法、AIを利用した品質保証方法に必要な知識・技術を波及させていく • 目指す姿 ◦ 全体的な視点で「良い」と「早く」をより「レバレッジ」させるために必要なことを継続的に進めていく • おこなっていくこと
 ◦ （１）開発チームに関連性の強い部内の他ユニットに対してのレバレッジ
 ◦ （２）他ユニットが開発チームに関わりを強く持つことでやりづらい全社的な視点でのレバレッジ
 レバレッジ推進ユニット • 今おこなっていること ◦ AIプロダクトの品質保証方法の選定と検証 ◦ ビジネスサイドへのヒアリングとレバレッジ施策の検討
17. 品質保証部のメンバーに 求められるスキル
18. • コアスキルとして求めているもの
 ◦ 「テスト設計力」
 ▪ 開発ライフサイクルのどのフェーズにおいても重要な力です
 ◦ 「QA視点での課題発見力」
 ▪ 課題を見つけてそれに向き合うことが求められます
 • コアスキルと別のQA関連スキルの掛け算
 ◦ コアスキル以外のスキルも必要（QAE・TE・SETスキルのいずれか）
 ▪ 別のスキルもかけることで「深さ」「広さ」でやっていけること
 ◦ テスト設計力も他のスキルがあることで、より「深さ」「広さ」がでてくる
 ▪ 例）SETスキルを活用することで「どこで」「どの自動テストで」「どう守るか」が設計できる
 
 自身の得意なスキル、これから伸ばしたいスキルをもとにバリューを発揮してもらうことを想定しています。
 求められるスキル
19. 今、得られる経験 推しポイント
20. 今のSmartHRの品質保証部で得られる経験 たとえば次のような経験がえられます • 拡大を続けるSmartHRの各プロダクトに対して「良いサービスを早く提供し続ける」かを考えて、実 践することができます
 • 上記の環境で「今あるスキルをより伸ばすこと」「新たなスキルを活用する」機会が多くありま す ◦ 開発ライフサイクル全般に対しての活動の中でなにをやるかを考えて実践できます SmartHRならびに品質保証部はまだまだ成長途中でありいろいろなことを経験できます
21. プロダクト基盤ユニットの推しポイント プロダクト基盤は2024年7月に発足したユニットです • 「基盤」の品質を担保するために多くの裁量を与えられている ◦ どうしていくのか・何をやっていくのかを自分たちで決められる • 「基盤」ごとにドメインが異なるため、さまざまなドメインに関与できる機会がある • 他の職能の領域に深く関わることができる ◦ Case1）PM領域への関わり ▪ 仕様策定や設計への関わり ◦ Case2）PdE領域への関わり ▪ プロダクトコードから仕様の考慮漏れや不具合の発見 ▪ 場合によっては自らプロダクトコードの修正
22. タレントマネジメントユニットの推しポイント • 開発チームとの連携 ◦ 開発チームと一緒に「どうやったら利用者のタレントマネジメントをサクセスできるか？」を模索しな がら正解を作っていける • スループットと安定性への挑戦 ◦ 新機能を小さく速くリリースするため、自身やチームの学習サイクルが速い ◦ 開発プロセスの定義に留まらず、安定性を保ちつつ最高速が出せるプロセスに整えていくことに挑 戦できる ◦ 上記の実現に向けて、テスト以外の領域にも手を広げていける
23. 今のSmartHRの品質保証部のチーフの推しポイント SmartHRにおけるチーフはプレイングマネージャーとして、マネジメントとプレイヤーの両方を担う大事な役割で す。 マネジメントを経験してみたいものの、いきなりマネジメントに全振りをするのはきびしいというのはあるかと思 います。 そういった中、次のようなポイントがチーフの推しポイントとして挙げられます。 • 裁量をもったマネジメント ◦ ユニットに対して方針や評価などを含め裁量が適切に与えられています • 事業視点・組織視点の獲得 ◦ 事業、会社に対する貢献を考える機会が増え新たな視点が得られます ◦ より長いスパンのことを考えることができるようになります • マネジメントへの挑戦支援の充実 ◦ チーフになった方に対するサポートが会社としてあります ◦ 他のチーフも複数おり孤独にならず相談ができます チーフになったからといってマネジメントのほうに向かわないといけないわけではありません。 チーフからプレイヤーへ、チーフからマネージャーへといったキャリアが考えられます。
24. We Are Hiring!
25. We Are Hiring ! SmartHRのQAエンジニアに興味を持っていただけましたら、下記の採用サイトからエントリーい ただけますと幸いです。 カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気 軽に聞きにきていただけたら嬉しいです。 みなさまのご応募お待ちしております！ SmartHR エンジニア採用サイト プロダクトの品質を技術で解決する QAエンジニアをWanted！ by 株式会社SmartHR SmartHRの品質に、一緒に取り組んでくれる方を募集しています！
26. 募集職種 SmartHRの品質に、一緒に取り組んでくれる方を募集しています！ QAエンジニア（チーフ候補） https://open.talentio.com/r/1/c/smarthr/pages/83193 QAエンジニア（労務ユニット横断チーフ候補） https://open.talentio.com/r/1/c/smarthr/pages/110259 QAエンジニア（レバレッジ推進ユニット） https://open.talentio.com/r/1/c/smarthr/pages/103040 QAエンジニア（プロダクト基盤ユニット） https://open.talentio.com/r/1/c/smarthr/pages/103039 QAエンジニア https://open.talentio.com/r/1/c/smarthr/pages/45053