QAエンジニアがプロダクト専任でチームの中に入ると。。。？/登壇資料（杉森太樹）

by Hacobu

Slide 1

Slide 1 text

Confidential QAエンジニアがプロダクト専任でチームの中に入ると。。。？ 2025年11月11日

Slide 2

Slide 2 text

Copyright Hacobu, Inc. 2 自己紹介杉森太樹（すぎもりたいじゅ）株式会社Hacobu テクノロジー本部 QAエンジニア/スクラムマスター - 2017年より第三者検証会社に入社しWeb・モバイルアプリのテスト設計・実行・品質改善に従事し、様々な開発現場で「品質をどう作り込むか」を学ぶ - 2023年にHacobuへ入社、物流DX領域のアプリQAを担当しながらスクラムマスターとしてチーム運営にも携わる顔写真やアイコン

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

Copyright Hacobu, Inc. 6 技術スタック各プロダクトはそれぞれ共通の技術スタックをベースにしつつプロダクト固有の課題に対しては最適な技術を積極的に導入することで開発者体験とプロダクト価値の向上を図っています。開発言語・フレームワーク開発支援ツールインフラ・CI/CD IoT AI セキュリティデータエンジニアリング

Slide 7

Slide 7 text

今日伝えたいこと

Slide 8

Slide 8 text

QAエンジニアがプロダクト専任でチームの中に入ると、、、とってもいいことがあるよ！

Slide 9

Slide 9 text

目次 Copyright Hacobu, Inc. 9 1.現在のQA体制 2.現在の体制の効果 3.課題と今後の展望

Slide 10

Slide 10 text

現在のQA体制

Slide 11

Slide 11 text

プロダクトA 開発チームプロダクトB 開発チームプロダクトC 開発チームプロダクトD 開発チーム＝黒はQAエンジニア以外のメンバー＝オレンジがQAエンジニア基本的にプロダクト専任現在のチーム体制図

Slide 12

Slide 12 text

QAチームプロダクトA 開発チームプロダクトB 開発チームプロダクトC 開発チームプロダクトD 開発チーム独立したQAチームから人をアサインする形ではないです！架空のチーム体制図

Slide 13

Slide 13 text

プロダクトA 開発チームプロダクトB 開発チームプロダクトC 開発チームプロダクトD 開発チーム＝黒はQAエンジニア以外のメンバー＝オレンジがQAエンジニア基本的にプロダクト専任、 QA定例などで情報交換も行います。現在のチーム体制図

Slide 14

Slide 14 text

Slide 15

Slide 15 text

現在の体制の効果

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright Hacobu, Inc. 17 現在の体制の効果開発メンバーとQAエンジニアが同じ方向を見て進むことができるチーム全体で品質を共有・改善する文化が生まれる・PdMや開発メンバーも品質を自分ごととして扱うようになる・不具合検知が早期化（シフトレフト）→ 手戻り削減 →QAが“ブレーキ役”ではなく、“品質のファシリテーター”に日常的に会話プロダクトへの理解同じ目線で共同作業ができる

Slide 18

Slide 18 text

Copyright Hacobu, Inc. 18 現在の体制の効果モチベーションが上がるチームやサービスへの当事者意識が芽生え、自己効力感が高まる →チーム内での発言が反映されやすく、QAエンジニアの存在意義が見える。要件定義や開発方針への影響力感謝されやすいモチベーション向上

Slide 19

Slide 19 text

Copyright Hacobu, Inc. 19 現在の体制の効果二つの効果の循環 QAエンジニアがこの循環に入ると、チーム全体が「品質は全員でつくるもの」という意識になるチームへの影響力向上感謝されやすい高いモチベーションで貢献プロダクトへの理解が深まる同じ方向に進める環境が整う

Slide 20

Slide 20 text

Copyright Hacobu, Inc. 20 QA組織の形の比較プロダクト専任型とQAチーム集中型の比較観点プロダクト専任型（Embedded型） QAチーム集中型（横断型）理解の深さプロダクト・ドメイン知識が深く、業務背景を理解できる複数プロダクトの全体像を把握しやすいスピード感開発と一体で動けるため意思決定が早い調整コストが発生しやすく、着手が遅れやすいチーム連携開発・PdMと距離が近く、壁がない品質会話が日常的に発生プロダクト間の知見共有が容易で横展開しやすいナレッジ共有チーム内で深いノウハウが溜まるが、他チームに届きにくい標準化や仕組み化が進めやすいモチベーション当事者意識・自己効力感が高いチーム間の帰属意識は弱まりやすい品質の一貫性プロダクト単位では高いが、全社ではばらつきやすい全体基準を揃えやすいが、現場最適化しづらいリソースの柔軟性他プロダクト支援が難しいリソースを柔軟にアサイン可能適した状況プロダクトごとに文化が異なる、独立性が高い環境組織的なQA基盤を整えたい、横断プロジェクトが多い環境

Slide 21

Slide 21 text

課題と今後の展望

Slide 22

Slide 22 text

Copyright Hacobu, Inc. 課題と今後の展望 2 2 現在の課題・横断的な活動が難しい・自動化・テスト基盤の整備などが進みにくい・自分が担当しているプロダクト以外の仕様が分からない・プロダクト連携の時に困る・QA工数を他チームと一時的にシェアすることが難しい

Slide 23

Slide 23 text

Slide 24

Slide 24 text

さいごに

Slide 25

Slide 25 text

Copyright Hacobu, Inc. 2 5 さいごに QAエンジニアがプロダクト専任で開発チームの中に入ったら、、、開発メンバーとQAエンジニアが同じ方向を見て進めたりモチベーションが上がったり、とっても良いサイクルができました。とはいえ、これらはあくまでも弊社の事例であり、会社やプロダクトに合ったQAの在り方は他にもたくさんあります。弊社もあゆみを止めず、組織の在り方やQAの在り方などより良い形に進化していけたらと考えています。

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text