Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
品質保証本部カジュアル面談資料(2026/6/18更新)
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
SmartHR 品質保証本部
October 18, 2023
Technology
42k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
品質保証本部カジュアル面談資料(2026/6/18更新)
SmartHR 品質保証本部のカジュアル面談時に利用している資料です。
SmartHR 品質保証本部
October 18, 2023
More Decks by SmartHR 品質保証本部
See All by SmartHR 品質保証本部
横断組織出⾝のQAEが インプロセスQAEで つまずいたこと‧活かせたこと
qa
0
1
開発チームとQAエンジニアの新しい協業モデル -年末調整開発チームで実践する【QAリード施策】-
qa
0
2k
スケールアップ企業でQA組織が機能し続けるための組織設計と仕組み〜ボトムアップとトップダウンを両輪としたアプローチ〜
qa
0
650
品質保証の取り組みを広げる仕組みづくり〜スキルの移譲と自律を支える実践知〜
qa
0
87
自動テストのコストと向き合ってみた
qa
1
370
LLMを搭載したプロダクトの品質保証の模索と学び
qa
1
2.5k
年末調整プロダクトの内部品質改善活動について
qa
0
67
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
qa
1
140
SmartHRの品質保証部の 今とこれから
qa
1
390
Other Decks in Technology
See All in Technology
新しいUbuntu/GNOMEが使いたいからXからWaylandへ移行頑張ってるの巻 2026-06-20
nobutomurata
0
150
AIのReact習熟度を測る
uhyo
2
650
フィジカル版Github Onshapeの紹介
shiba_8ro
0
290
あなたの知らないPDFのアクセシビリティ
lycorptech_jp
PRO
0
220
就職⽀援サービスにおけるキャリアアドバイザーのシフトスケジューリング
recruitengineers
PRO
1
150
マルチアカウント環境での コーディングエージェントを使った障害調査が大変なので AIエージェントにReadOnly権限を付与してみた / ReadOnly AI Agents for Multi-Account AWS Incident Response
yamaguchitk333
2
110
When Platform Engineering Meets GenAI
sucitw
0
130
スタートアップにAmazon EKSは早すぎる? マルチプロダクト戦略を加速する Platform Engineeringの実践 / Is Amazon EKS Too Soon for Startups? Practical Platform Engineering to Accelerate a Multi-Product Strategy
elmodev09
0
320
データサイエンスを価値につなげるプロジェクト設計 〜 DS一年目が現場で得た気づき 〜
ysd113
1
280
不要なレビューをAIにまかせて AIコーディングの環境改善を加速した
shoota
1
220
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
3k
SteampipeとExcel Power QueryでAWS構成定義書の作成を自動化する
jhashimoto
0
150
Featured
See All Featured
The Curious Case for Waylosing
cassininazir
1
390
Why Mistakes Are the Best Teachers: Turning Failure into a Pathway for Growth
auna
0
160
JAMstack: Web Apps at Ludicrous Speed - All Things Open 2022
reverentgeek
1
480
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
250
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
123
22k
From π to Pie charts
rasagy
0
210
Marketing to machines
jonoalderson
1
5.5k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.3k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.9k
Prompt Engineering for Job Search
mfonobong
0
350
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
2.9k
Transcript
品質保証本部 紹介資料 2026/6/18更新
・沿革 ・開発体制 ・ビジョン・ミッション ・体制と活動例 目次
沿革
品質保証本部のざっくり沿革 • 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月:労務ユニット体制の更新 • 2025年10月:品質保証部が品質保証本部に「本部」化 • 2025年10月:労務プロダクト品質保証部として「部」化 現在のスタイルをより進めていくためにも新たなメンバーが必要な状況
開発体制
SmartHRの開発体制 • 開発の体制や流れはチームなどによって異なります • 詳しくは次の資料を参照してください ◦ https://hello-world.smarthr.co.jp/ ▪ プロダクトエンジニア採用サイト
ビジョン・ミッション
ビジョン(目指す姿) ビジョン(目指す姿): 良いサービスを早く提供し続ける そのためには、組織全体として次ができている必要があります。 • 早い段階で見つけられる不具合を見つけている • 見つけられなかった不具合においてもリリース後に見つけられている 上記を達成するには、開発ライフサイクルの中のすべてのステージにおいてQA観点をもってアクションが 必要です。
全体的な視点で考えるには、対象となるプロダクト特性や開発チームの状況に応じて判断する必要があ ります。 それによってステージにかかる、かけるべき工数も変わってきます。 そのためには、どのフェーズをどのようにグラデーションをつけて関わっていくかをチーム単位で考えられ る必要があります。
ミッション(責務) ミッション(責務): 継続的に品質保証できる体制をつくる この「体制づくり」は「品質保証本部」という組織のことでもあり、開発チームや会社全体も含めた話になり ます。 目指す姿に向かって進むためには、私たちが「今おこなっていること」を開発チームで当たり前にし「次の 当たり前」を作っていくことが重要になってきます。 この「次の当たり前」をQAの専門家である私たちが考え、そして作っていくということを継続的に追求して いく必要があります。 「サービス開発に関わる全ての人がQA活動をおこなうだけでなく、そのQA活動のレベルを継続的に向上さ
せていく」 私たちが今おこなっていることを「当たり前」にし、次のステップに持っていくというサイクルをまわすことで「目指す姿」 に近づいていきます。
体制と活動例
品質保証本部の体制 レバレッジ推進 ユニット ・特定プロダクトを対象としない ・プロダクト基盤全般 ・スマートフォンアプリ ・プラットフォーム事業 ・ID管理 など プロダクト 基盤ユニット
タレントマネジメント ユニット ・配置シミュレーション ・スキル管理 ・採用管理 ・人事評価 など チーフ (兼) メンバー メンバー メンバー チーフ 人給基幹プロダクト品質保証部 フロントシステム 勤怠管理・給与計算 マネージャー (兼) ・フロントシステムエリア ・人事マスタエリア ・給与計算エリア ・勤怠管理エリア \募集中/ チーフ (兼) 人事マスタ \募集中/ \募集中/ \募集中/ \募集中/ 品 質 保 証 本 部 Director
人給基幹プロダクト品質保証部の体制 フロントシステム 勤怠管理・給与計算 チーフ メンバー チーフ メンバー ・フロントシステムエリア ・給与計算エリア ・勤怠管理エリア
\募集中/ 人 給 基 幹 プ ロ ダ クト 品 質 保 証 部 マネージャー (兼) 人事マスタ ・人事マスタエリア チーフ メンバー \募集中/
フロントシステムユニット • 目指す姿 ◦ 各開発チームと適切な形で連携しながら、良いサービスを早くユーザーに提供するためのプロダクト作りに貢献する • おこなっていくこと ◦ フロントシステムエリアの品質状況の可視化と、そのための指標づくり ▪
開発チーム単位ではなくエリアの品質を可視化するための指標を取り、状況を言語化できる状態にする ▪ プロダクトの品質に貢献しつつ、上記の指標から今より根拠のある中長期の品質戦略を立てられるようにする ◦ 上記を推進できる開発チームへの関わり方、体制を整える • 今おこなっていること ◦ インプロセスのさらに次の段階として、開発チームとの関わり方を広げる活動 ▪ 複数の開発チームを2つのブロックに分け、各ブロックを複数のQAEが担当する体制にすることで、属人化を解消しな がら、エリアとしての品質保証がおこなえる体制へ ◦ エリア共通で使用する不具合情報の整備、各開発チームへの導入 • 今後やっていきたいこと ◦ 根本的なリソース不足を解消するために、さらに採用活動にも力を入れていく
人事マスタユニット • 目指す姿 ◦ 信頼できる人事マスタを、変化に追従しながら、顧客が安心して使い続けられる状態で提供し続ける • おこなっていくこと ◦ 定量(エリア全体に向けて) —
品質をデータで見える化し、傾向を掴み、エリアの意思決定に活かす ◦ 定性(チーム・プロダクトに向けて) — 開発プロセスに沿って各チームに関わり、上流から品質を作り込む ◦ 学びを次に活かす — 起きたことから学び、予防と復旧を改善し続ける ◦ 上記の活動に必要なスキルの把握と獲得 • 今おこなっていること ◦ 人事マスタエリアの全featureを対象としたリスク分析・テスト戦略の導入と、QAEが開発上流から関与できる体制の構築 ◦ 品質ダッシュボードによる不具合・インシデント情報の可視化と、データに基づくエリア全体の意思決定プロセスの整備 • 今後やっていきたいこと ◦ 信頼性の4要素(正確性・耐性・復旧力・検知力)を軸にした指標設計・計測体制の構築と、職種を超えた連携体制の確立 ◦ インシデントの学びを活かした再発防止サイクルの整備と、AI活用・チーム特性に応じた持続可能な品質保証モデルの確立
勤怠管理・給与計算ユニット • 目指す姿 ◦ 各開発チームと適切な形で連携しながら、良いサービスを早くユーザーに提供するためのプロダクト作りに貢献する • おこなっていくこと ◦ (1)勤怠管理エリア、給与計算エリアの品質保証活動をリードし、高品質な機能を継続してリリースできる環境を作る ◦
(2)品質保証活動で繰り返し発生しうる問題を定義し、型化により問題に対する解決の再現性が高い状態を作る • 今おこなっていること ◦ 勤怠管理エリア、給与計算エリアそれぞれにインプロセスで関与し、品質保証活動を実施 ◦ 仕様策定・レビュー、テスト全般(計画作成、探索的テストの実施など)、不具合分析、開発プロセスの改善 ◦ 品質を高めるための施策の立案と実施のリード • 今後やっていきたいこと ◦ 勤怠管理エリア、給与計算エリアのプロダクトを横断的に使用する視点に立った品質の向上
• 目指す姿 ◦ プロダクト基盤が安定して「良い」を保ち続けられるようにする ▪ 「良い」・・・ 価値検証された基盤が安定して動作し続ける状態 ▪ 「価値検証された基盤」・・・マルチプロダクトにおける負を解消し、プロダクトシナジーを作りだすことで、マルチプ ロダクトとしての価値を高められることが検証された基盤
• おこなっていくこと ◦ プロダクト基盤の開発チームが「良い」を保ち続けられるように、各開発チームにあったプロセスを構築し、再現性を持 たせられるようにしていく • 今おこなっていること ◦ プロダクト基盤のうち、特にリスク・影響が大きいと判断したものを優先して取り組んでいる • 今後やっていきたいこと ◦ 良いサービスを早く提供し続けるために、各開発プロセスにおいて具体的にどのようなQA視点を持つべきか実践を通じ て見極めていく ◦ 各開発プロセスのQA視点のうち、開発チームが担う部分とQAエンジニアが担う部分を判断し、QAエンジニアが担う部 分に注力できる状態にしていく プロダクト基盤ユニット
• 目指す姿 ◦ タレマネプロダクトの本質的な価値に寄り添う • おこなっていくこと ◦ プロダクトの特性や状況に合わせた本質的な価値を見極め、その価値を守り、より最大化できるよう最適な手法を考え実 行していく ◦
「最速で成長していく」ために仮説検証のサイクルの速度を上げ、一度のサイクルでより多くより正確な検証結果を得られ るようにしていく • 今おこなっていること ◦ 品質状況を測るための足がかりを作り、潜在的な品質課題の早期発見や品質改善の取り組みの効果を可視化できるよ うにする ◦ 急拡大中のチームやプロダクトに合わせ、品質保証活動を最適化する • 今後やっていきたいこと ◦ 可視化された品質状況から品質改善活動の緊急度を定量的に示し、タレマネ事業の中長期計画へ適切にフィード バックできるようにする タレントマネジメントユニット
• 今後やっていきたいこと ◦ 職種間のQA認識ギャップを解消し、全社横断的な視座向上による品質担保の取り組みを加速させていく ◦ AIプロダクトに関する品質保証方法、AIを利用した品質保証方法に必要な知識・技術を波及させていく • 目指す姿 ◦ 全体的な視点で「良い」と「早く」をより「レバレッジ」させるために必要なことを継続的に進めていく
• おこなっていくこと ◦ (1)開発チームに関連性の強い部内の他ユニットに対してのレバレッジ ◦ (2)他ユニットが開発チームに関わりを強く持つことでやりづらい全社的な視点でのレバレッジ レバレッジ推進ユニット • 今おこなっていること ◦ 他部署との協業を通じた品質向上施策の実践 ◦ LLMアプリの品質保証手法の体系化の取り組み ◦ 品質保証・テスト領域へのAI技術活用の模索
品質保証本部のメンバーに 求められるスキル
• コアスキルとして求めているもの ◦ 「テスト設計力」 ▪ 開発ライフサイクルのどのフェーズにおいても重要な力です ◦ 「QA視点での課題発見力」 ▪ 課題を見つけてそれに向き合うことが求められます
• コアスキルと別のQA関連スキルの掛け算 ◦ コアスキル以外のスキルも必要(QAE・TE・SETスキルのいずれか) ▪ 別のスキルもかけることで「深さ」「広さ」でやっていけること ◦ テスト設計力も他のスキルがあることで、より「深さ」「広さ」がでてくる ▪ 例)SETスキルを活用することで「どこで」「どの自動テストで」「どう守るか」が設計できる 自身の得意なスキル、これから伸ばしたいスキルをもとにバリューを発揮してもらうことを想定しています。 求められるスキル
今、得られる経験 推しポイント
今のSmartHRの品質保証本部で得られる経験 たとえば次のような経験がえられます • 拡大を続けるSmartHRの各プロダクトに対して「良いサービスを早く提供し続ける」かを考えて、 実践することができます • 上記の環境で「今あるスキルをより伸ばすこと」「新たなスキルを活用する」機会が多くあります ◦ 開発ライフサイクル全般に対しての活動の中でなにをやるかを考えて実践できます •
実践の場でスキルを活用する、伸ばす以外に「タレマネ施策」を通してのサポートもあります SmartHRならびに品質保証本部はまだまだ成長途中でありいろいろなことを経験できます
プロダクト基盤ユニットの推しポイント • 「基盤」の品質を担保するために多くの裁量を与えられている ◦ どうしていくのか・何をやっていくのかを自分たちで決められる • 「基盤」ごとにドメインが異なるため、さまざまなドメインに関与できる機会がある • 他の職能の領域に深く関わることができる ◦
Case1)PM領域への関わり ▪ 仕様策定や設計への関わり ◦ Case2)PdE領域への関わり ▪ プロダクトコードから仕様の考慮漏れや不具合の発見 ▪ 場合によっては自らプロダクトコードの修正
タレントマネジメントユニットの推しポイント • 開発チームとの連携 ◦ 開発チームと一緒に「どうやったら利用者のタレントマネジメントをサクセスできるか?」を模索しな がら正解を作っていける • スループットと安定性への挑戦 ◦ 新機能を小さく速くリリースするため、自身やチームの学習サイクルが速い
◦ 開発プロセスの定義に留まらず、安定性を保ちつつ最高速が出すことに挑戦できる ◦ 上記の実現に向けて、テスト以外の領域にも手を広げていける
レバレッジ推進ユニットの推しポイント • 「0.n → 1」を形にする挑戦 ◦ QA視点がまだ届いていない領域に踏み込み、 他職種と協業しながら小さな取り組みを具体的な成果へ育てていくことができます。 • 部署の垣根を越えた、全社的な品質改善への貢献
◦ 開発チームに留まらず、セールスなど多様な関係者を巻き込みながら、 会社全体の品質向上を推進できます。 ◦ この過程で、様々な立場からの「品質」に触れ、豊富な改善経験を積むことが可能です。 • AIなど最先端領域への挑戦 ◦ AIの品質保証のような新しい分野や、プロダクト品質向上のための技術検証に近い領域 にも挑戦し、まだ答えのない課題に取り組むことができます。 参考資料:未来へレバレッジをかけるためのレバレッジ推進ユニットの役割と今 https://tech.smarthr.jp/entry/2025/11/19/140235
今のSmartHRの品質保証本部のチーフの推しポイント SmartHRにおけるチーフはプレイングマネージャーとして、マネジメントとプレイヤーの両方を担う大事な役割で す。 マネジメントを経験してみたいものの、いきなりマネジメントに全振りをするのはきびしいというのはあるかと思 います。 そういった中、次のようなポイントがチーフの推しポイントとして挙げられます。 • 裁量をもったマネジメント ◦ ユニットに対して方針や評価などを含め裁量が適切に与えられています
• 事業視点・組織視点の獲得 ◦ 事業、会社に対する貢献を考える機会が増え新たな視点が得られます ◦ より長いスパンのことを考えることができるようになります • マネジメントへの挑戦支援の充実 ◦ チーフになった方に対するサポートが会社としてあります ◦ 他のチーフも複数おり孤独にならず相談ができます チーフになったからといってマネジメントのほうに向かわないといけないわけではありません。 チーフからプレイヤーへ、チーフからマネージャーへといったキャリアが考えられます。
We Are Hiring!
We Are Hiring ! SmartHRのQAエンジニアに興味を持っていただけましたら、下記の採用サイトからエントリーい ただけますと幸いです。 カジュアル面談も実施しておりますので、選考に進む前に気になることがありましたらぜひ、気 軽に聞きにきていただけたら嬉しいです。 みなさまのご応募お待ちしております! SmartHR
エンジニア採用サイト プロダクトの品質を技術で解決する QAエンジニアをWanted! by 株式会社SmartHR SmartHRの品質に、一緒に取り組んでくれる方を募集しています!
募集職種 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