Slide 1

Slide 1 text

2025/02/25 Findy Job LT タイミーにおけるQAチームの取り組み 株式会社タイミー 片野 晃一

Slide 2

Slide 2 text

自己紹介 片野 晃一 所属 エンジニアリング本部 プラットフォームエンジニアリング部 QA Enabling G Software Engineer in Test (SET) 経歴 Webシステム、メール配信プラットフォームの開発を経て 2024年7月から現職 好きなもの ラーメン、甘いもの、キーボード 2

Slide 3

Slide 3 text

3 QAチームの変遷 時期 概要 トピック 2023年8月〜 QAチームの立ち上げ準備 ・1人目のメンバーが入社 ・コンセプト・活動方針の策定 参考: チームトポロジーに対応するQAアプローチのご紹介 2024年1月〜 SAチームを支援する取り組みを開始 ・1人目のQAコーチが入社 ・SAチームに常駐しQAコーチとしての関わり方を模索 参考: 駆け出しQAコーチがチートポ型組織でQAしないで価値を届けたい話 2024年6月〜 チーム規模の拡大 ・1人目のSETが入社 ・開発プロセスの分析と課題探索 ・障害対応プロセスの改善 ・残りのメンバーも入社し6名体制に 2024年11月〜 活動範囲の拡大 ・より組織的・横断的な取り組みに着手(後述) 3 2024年7月 ここで入社

Slide 4

Slide 4 text

目次 ● タイミーについて ● QAチームの体制と方針 ● 取り組んでいること ● 今後の展望

Slide 5

Slide 5 text

タイミーについて

Slide 6

Slide 6 text

6

Slide 7

Slide 7 text

7

Slide 8

Slide 8 text

タイミーの使われ方 働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手 の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。 8

Slide 9

Slide 9 text

開発組織の全体像 複数のストリームアラインドチームとそれらを横断的に支援するチームで構成されている ストリームアラインドチーム群 9

Slide 10

Slide 10 text

タイミーの標準的なストリームアラインドチーム ある価値提供する継続的な流れ(バリューストリーム)を対象として、 価値を届けることに集中するチーム(ストリームアラインドチーム)を作る 10

Slide 11

Slide 11 text

イネーブリングおよびプラットフォームチーム 各領域の専門家としてSAチームの能力獲得を支援したり、共通的な基盤を提供する イネーブリング/プラットフォームチーム群 11

Slide 12

Slide 12 text

QAチームの体制と方針

Slide 13

Slide 13 text

QAチームの体制 ● イネーブリングおよびプラットフォームチームの両方の性格を持つ ● 品質の専門家としてSAチームの能力獲得支援と共通的な基盤の提供を行う ● QAチーム内では大きく「QAコーチ」と「SET」の二つの役割に分かれている Dev Enable イネーブリング/プラットフォームチーム群 QA Agile Practice Cloud Infra Backend Frontend QA Enabling G ・マネージャー ・QAコーチ (2名) ・SET (3名) 13

Slide 14

Slide 14 text

14 QAチームの変遷 14 時期 概要 トピック 2023年8月〜 QAチームの立ち上げ準備 ・1人目のメンバーが入社 ・コンセプト・活動方針の策定 参考: チームトポロジーに対応するQAアプローチのご紹介 2024年1月〜 SAチームを支援する取り組みを開始 ・1人目のQAコーチが入社 ・SAチームに常駐しQAコーチとしての関わり方を模索 参考: 駆け出しQAコーチがチートポ型組織でQAしないで価値を届けたい話 2024年6月〜 チーム規模の拡大 ・1人目のSETが入社 ・開発プロセスの分析と課題探索 ・障害対応プロセスの改善 ・残りのメンバーも入社し6名体制に 2024年11月〜 活動範囲の拡大 ・より組織的・横断的な取り組みに着手(後述)

Slide 15

Slide 15 text

● Capability: プロダクト組織が自律的に品質保証活動を行う ● Agility: 変化に適応し高速に価値提供する ● Reliability: 高いサービス信頼性を実現する 15 目指すこと QAチームは組織が開発生産性と品質を両立するためのケイパビリティや知識・経験を Center of Practice として提供する 価値あるプロダクトを素早く届ける

Slide 16

Slide 16 text

16 活動方針 16 SAチームの自立をQA面から支援する ● QAの知識/技術/ツールをSAチームが利用できるように支援する 目的や状況に応じて適切に役割・インタラクションの仕方を選択する ● 基本的な役割としてQAコーチとSETに分かれており、前者はイネーブリング性、後者はプラットフォーム性 の活動を担うことが多い ● ただし、役割や振る舞い方は固定せず、目的や状況に応じて適切な方法を選択する 開発プロセスに合わせた支援を行う ● 先述の方針を基本としてDevOpsにおけるアジャイル(スクラム)以外の開発プロセスにおいては品質リス クを考慮した支援も行う

Slide 17

Slide 17 text

取り組んでいること

Slide 18

Slide 18 text

QAコーチの活動事例 - QAの技術移転 実例マッピングのワークショップ (相談ベースの対応、ファシリテーション) 18 SAチームとの共同作業やファシリテーションを通じてQAの考え方やスキルを伝える 状況によってはQAコーチがテスト活動の主体になることもある QA基礎知識・テスト技法のワークショップ (SAチームに所属、ファシリテーション) テスト計画・分析・設計・実施 (SAチームに所属、コラボレーション)

Slide 19

Slide 19 text

SETの活動事例 - 検証環境の整備 19 テスト環境・テストデータに起因する課題を解決するため、本番環境に近い検証環境を整備中(現在進行形) プロジェクト企画(一部抜粋)

Slide 20

Slide 20 text

SETの活動事例 - 検証環境の整備 ● 異なる専門性を持つメンバーを巻き込んで方針を検討 ● 目的、ユースケース、具体策をマッピングして実現したときの価値を評価 ● アーキテクチャ設計をベースに実装コスト、リスクを評価 20 具体案選定のためのマッピング アーキテクチャ検討

Slide 21

Slide 21 text

課題を集める 課題を集めるための一次情報を収集する機会を大事にしている ● メトリクスの観察 ● 「目安箱」の設置 ● SAチームからの相談・レビュー依頼 ● QAアセスメント(定性・定量アンケート) ● ヒアリング ● ワークショップの実施 ● ペアプロ・モブプロへの参加 ● 障害対応・ポストモーテムへの参加 ● 社内輪読会・勉強会への参加 ● 雑談 ● など... 21 目安箱: SAチームからの相談や改善提案を受け付ける

Slide 22

Slide 22 text

今後の展望

Slide 23

Slide 23 text

業務のテーマ ● システムの信頼性向上 ○ CUJを基盤とした品質基準の策定 ○ 品質分析フレームワークの導入(ODC分析、FMEA等) ○ 障害対応プロセスの継続的な改善 ● 開発組織の生産性向上 ○ 検証環境の整備 ○ テストデータの拡充 ○ 生成AIの活用・トライアル ● QAチームの施策遂行能力強化 ○ SAチームとの関わり方の整理 ○ 他職種とのコラボレーションや越境の推進 23

Slide 24

Slide 24 text

● QAチームの変遷 ○ 開発組織の戦略に沿ってチームのコンセプトを定めた ○ 活動を通じてチームの在り方や方向性を模索してきた(今も継続中) ○ チームとしてより大きな課題に取り組めるようになってきた ● 環境の変化 ○ 事業成長に伴う変化 ○ プロダクトや組織の規模拡大 ○ AIの進化 ○ など... 振り返ってみる 24

Slide 25

Slide 25 text

課題の集め方 ● 質の高い課題を集めるために何をするか ● SAチームとの関わり方の模索 取り組むべきことは何か? 25 解くべき課題の決め方 ● どの課題をどのような順序で解くのか ● QAチームとしての判断軸を持つ インタラクションモードの整理 メトリクスの観察 QAチームのアプローチやポートフォリオの見直し

Slide 26

Slide 26 text

そもそも何を目指すのか? 26 目指すのは開発生産性と品質の両立 ● どんな品質を守るために、いつ、どこで、誰が、何を、どこまでやるべきなのか ● CUJを軸とした品質基準の策定 なぜ品質基準を策定するのか? ・システムが品質目標を達成しているかどうかを可視化し、監視するため ・品質基準を下回った場合をトリガーに組織的な品質改善アクションを促すため ・テストや自動化の優先度が明確になり、開発者・QAメンバー双方の負荷を軽減するため 期待する効果 ・CUJをもとに、顧客体験と直結した品質基準を共有 ・変更時の重要テスト項目が明確化し、リリース時の信頼性向上 ・品質やユーザビリティに関する共通言語を組織として確立 Critical User Journey (CUJ) を基盤とした品質基準の策定

Slide 27

Slide 27 text

CUJ を基盤とした品質基準の策定 27 リスク分析フレームワークの作成 User Journey の洗い出し User Journey の分析

Slide 28

Slide 28 text

WE ARE HIRING! 興味があればお気軽にご連絡ください! https://product-recruit.timee.co.jp/