横断組織出⾝のQAEが インプロセスQAEで つまずいたこと‧活かせたこと

Transcript

1. 横断組織出⾝のQAEが インプロセスQAEで つまずいたこと‧活かせたこと 2026.05.19 QA Test Talk Vol.6 ⼭下 太基 © SmartHR, Inc.
2. © SmartHR, Inc. 今⽇伝えたいこと つまずいたこと これまで経験した横断組織での動き⽅のままインプロセスで動 いたことによる失敗 活かせたこと 横断組織での経験で、インプロセスでも活かせたこと 1. ⾃⼰紹介 2. SmartHRの事 a. 開発体制 b. QA体制 3. ⽤語の定義 4. つまずいたこと 5. 活かせたこと 6. おわりに
3. ⾃⼰紹介 ⼭下 太基 / Taiki Yamashita 基本プロフィール • 所属：株式会社SmartHR • ⼊社：2025.08.01 © SmartHR, Inc. 経歴 • 2022.04.01 - 新卒から横断 SET‧QAEとして活動 • 2025.08.01 - SmartHR⼊社。特定プロダクトに⼊りつつ横断 としても活動
4. 業務効率化とデータ活⽤で、 様々な⼈の働き⽅を変えていくことを実現 SmartHRのプロダクト提供範囲 従業員データベースを中⼼に「⼈事‧労務」「タレントマネジメント」など、バックオフィスのあらゆる業務がシームレスに連携。 各業務を通じて従業員に関するあらゆる情報が次々に蓄積されることで、データベースの精度が向上し、好循環が⽣まれる仕組みです。 15 | 68 参 照:https://speakerdeck.com/smarthr_pr/smarthr-company-introduction1?slide=15 4
5. 5 SmartHRの開発体制 参考: https://hello-world.smarthr.co.jp/
6. QA組織体制 品質保証本部 組織図 品 質 保 証 本 部 ⼈給基幹プロダクト品質保証部 フロントシステム ⼈事マスタ 勤怠管理‧給与計算 他ユニット 他ユニット 他ユニット 僕の所属 © SmartHR, Inc. 僕の動きとしては 横断とインプロセスを4:6くらい で動いています 参考 ：https://speakerdeck.com/qa/qa-intro-202 310
7. ⽤語の定義 本登壇における2つの役割の定義と例 横断QAE 複数の開発チームやプロダクトを横断して品 質保証に関わる やってる事の例: ⼈給基幹プロダクト品質保証部内の他QAEと 連携しつつ、⼈給基幹全体の不具合分析やAI 活⽤等の特定チームに閉じない施策を進めて いく インプロセスQAE 1つの開発チームに深く⼊り込み、専任で品質 保証に関わる やってる事の例: 深く関わるチームを決め、そこにはスクラム イベントやテスト戦略策定にも積極的に関わ る。 © SmartHR, Inc.
8. つまずき
9. 1. コミュニケーション⾯ 開発チームの事情を考慮せず施策展開してしまった 会社の課題から品質保証本部で広めたい施策があった 「会社としてこういう課題があるのでチーム内でこの施策を進めたいです」 と提案 3 チームの現状と施策がミスマッチし、チームから想定以上にツッコミが 1 2 © SmartHR, Inc. それ何のため にやるんでし たっけ？ 管理コスト増 えません？ 今のチームの 運⽤に合わな い気がします
10. © SmartHR, Inc. チームの理解を得るアプローチへ改善 Before - 会社として必要な理由だけを説明する - 品質保証本部の理想状態で提案する - 合意者を絞って進める After - 「チームにとってのメリット」と紐づけ て説明する - まず導⼊で試す（理想状態にこだわらず ハードルを下げる） - 実際に動く⼈たちと認識を合わせる
11. 2. 品質保証活動のタイミングが後⼿に 背景 ⼊社後参加した開発チームでは、その期の開発ロードマップが既に決まっていた。 そこには品質保証活動が極端に少なかった 結果 品質保証活動において 「やるべきこと」ではなく「隙間でできる事をやる」 となってしまった 早期から噛んでいかないとリリーススケジュールに品質保証活動を織り込めない。と痛感 © SmartHR, Inc.
12. © SmartHR, Inc. 取れるアクションで成果を出した結果 初期から品質保証活動も踏まえてスケジュールを作る状態へ → チームの振り返りより “品質⾯をかなり削ったり 後回しにしてしまった” “QAを戦略として 組み込めていなかった” 1. 信頼の構築 ねじ込んだ品質保証活動 を実施した結果、想定よ り多く不具合が出た 2. 意識の変容 「やっておいてよかった」
13. 3. ドメイン知識の重要性 横断時代の視点のまま 「テスト観点が網羅されているか」を中⼼に 確認していた インプロセスの視点 ユーザー業務‧仕様の背景‧既存挙動‧法令 を踏まえて、リスクを⾒⽴てる必要があった © SmartHR, Inc.
14. 活かせたこと
15. © SmartHR, Inc. 横断での経験が活かせたこと 1 越境して巻き込む⼒ 開発プロセス上接点が無かっ たサポートの⽅へコミュニ ケーションを取り、リスク分 析会に招待した。 開発メンバーだけでは思いつ かなかったリスクを洗い出す ことができ、結果として開発 プロセスの改善に踏み込めた 2 組織の情報を拾う⼒ チーム内だけでなく、他チー ム‧過去事例‧社内情報から リスクを⾒⽴てられた。 これにより、あらかじめ対策 を⽴てることが出来た 3 ⼀歩引いて⾒る⼒ チームに深く⼊りながらも、 局所最適に陥らず判断できた 横断時に培った「会社全体の 意向」「開発組織全体の状 態」を踏まえる視点が活きた
16. まとめ
17. まとめ 懇談会にてぜひお話ししましょう！ © SmartHR, Inc. • 横断のやり⽅をそのまま持ち込む • グループ⻑と合意 → 現場展開 • 既に決まっているスケジュールに品質保証活 動を「ねじ込む」 今 • 開発チームに合う状態にしてから持ち込む • 「施策を持っていく」のではなく「相談す る」イメージ • スケジュール策定の時点からQAEが参加し、 品質保証活動も踏まえてスケジュールを作る ⼊社直後
18. おわり