第23回Ques_タイミーにおけるQAチームの在り方 / QA Team in Timee

Slide 1

Slide 1 text

タイミーにおけるQAチームの在り方 2024/11/08　第23回Ques 株式会社タイミー岸健

Slide 2

Slide 2 text

自己紹介  岸健（kishiken）  タイミー  エンジニアリング本部 QA Enabling Team   Software Engineer in Test (SET)   ◆経歴  メーカー系SIer → 第三者検証会社   → 消費者向けアプリの一人目QA → タイミー（6月入社）   ◆資格  ・JSTQB Advanced Level 完全上級テスト技術者   ・JSTQB Advanced Level テスト自動化エンジニア   ◆社外活動  ・テスト自動化研究会  

Slide 3

Slide 3 text

タイミーの事業及びサービス紹介

Slide 4

Slide 4 text

タイミーとは 4 ｢働きたい時間｣と｢働いてほしい時間｣をマッチングするスキマバイトサービス従来の「求人サイト」でも「派遣」でもない

Slide 5

Slide 5 text

タイミーの特徴 5

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

タイミーの実績スキマバイト No.1 ※1 ※2 [調査方法]インターネット調査 [調査期間]2024 年 2 月 9 日~11 日 [調査概要]スキマバイトアプリサービスの実態調査 [調査委託先]株式会社マクロミル ※3 2024年9月時点　※4 2024年9月時点利用率・リピート率 ※1 ※2 導入事業者数 136,000企業ワーカー数 900万人 ※4 ※3

Slide 8

Slide 8 text

Vision 一人ひとりの時間を豊かに「人生の時間は有限である」これは代表の小川が尊敬していた祖父の急逝をきっかけに得た教訓です。有限だからこそ時間をより価値あるものにする方法をすぐに見つけられすぐに実行できる世界をつくりたい。この想いから、時間を豊かにする選択肢の一つとして、好きな時間に働ける「タイミー」が着想されました。私たちは「はたらく」に留まらない多様なアプローチで、一人ひとりの時間が豊かになるきっかけを提供していきます。 8

Slide 9

Slide 9 text

Mission 「はたらく」を通じて人生の可能性を広げるインフラをつくる時間にとらわれず、好きな場所で、好きな仕事を。少し前には考えられないような自由な働き方を、タイミーは提供しています。この新しい「はたらく」は、ただ自由であることにその魅力を留めません。「働く」を通じた、多くの人との出会いと経験の積み重ねは、自分自身の新たな価値を発見し、可能性を広げる糧になると私たちは信じています。タイミーは、新しい「はたらく」インフラとして、一人ひとりが自分の可能性を広げていける社会を目指します。 9

Slide 10

Slide 10 text

以上、サービスのご紹介でした  では、改めて……  10

Slide 11

Slide 11 text

タイミーにおけるQAチームの在り方 2024/11/08　第23回Ques 株式会社タイミー岸健

Slide 12

Slide 12 text

今日お話したいこと   ● タイミーのQAチームはなぜQA Enabling チームと名乗っているのか    ● 開発チームとの関わり方    ● いま私たちが取り組んでいる事と、これから取り組みたい事  12

Slide 13

Slide 13 text

組織と開発生産性に関するタイミーでの必読書   13 『チームトポロジー - 価値あるソフトウェアをすばやく届ける適応型組織設計』  Matthew Skelton, Manuel Pais  日本能率協会マネジメントセンター, 2021年  https://pub.jmam.co.jp/book/b593881.html   『LeanとDevOpsの科学[Accelerate] - テクノロジーの戦略的活用が組織変革を加速する』  Nicole Forsgren Ph.D., Jez Humble, Gene Kim  インプレス, 2018年  https://book.impress.co.jp/books/1118101029  

Slide 14

Slide 14 text

イネイブリングチームはチームトポロジーに由来   14 『チームトポロジー - 価値あるソフトウェアをすばやく届ける適応型組織設計』  Matthew Skelton, Manuel Pais  日本能率協会マネジメントセンター, 2021年  https://pub.jmam.co.jp/book/b593881.html   『LeanとDevOpsの科学[Accelerate] - テクノロジーの戦略的活用が組織変革を加速する』  Nicole Forsgren Ph.D., Jez Humble, Gene Kim  インプレス, 2018年  https://book.impress.co.jp/books/1118101029  

Slide 15

Slide 15 text

チームトポロジーとは？   ソフトウェア開発において素早く安定した価値提供フローで  顧客価値の最大化を実現するための適応型の組織設計モデル  ● 技術、人、ビジネスの変化に継続的に対処するために組織も変化することが前提 = 適応型     ● チームの目的と責任を明確にし、チーム間の相互関係の効果の向上を目指す     ● 唯一絶対のトポロジーはなく適応型組織モデルのテンプレートと捉える   15

Slide 16

Slide 16 text

チームトポロジーでの典型的なチーム連携   ストリームアラインドチーム   イネイブリングチーム      ファシリテーション  コンプリケイテッド・サブシステムチーム  X-as-a-Service  X-as-a-Service  プラットフォームチーム   16

Slide 17

Slide 17 text

4つのチーム   17 ストリームアラインドチーム   ビジネスの主な変更フロー=ストリームに沿って配置されるチーム     職能横断型であり、他のチームを待つことなく、要求探索から本番運用までのデリバリー一式を担える。4タイプの中心となるチームで、他のチームタイプはストリームアラインドチームをいかに強化するかを担う。  プラットフォームチーム   インフラや共通的な基盤などを提供するチーム     ストリームアラインドチームが詳細を知らなくても安定的かつ高速にデリバリーを担えるようにサポートすることで負荷を下げる。   イネイブリングチーム   他のチームに対して新しいケイパビリティの獲得（新技術やスキルの導入）を支援するチーム    特定領域のスペシャリストが主な構成メンバーで、組織においてCenter of Practiceとなる。   コンプリケイテッド・  サブシステムチーム   複雑性が高い（高度な専門スキルやドメイン知識が必要など）サブシステムやコンポーネントを提供するチーム  4つのチームタイプに絞り、目的・役割・責任を明確にすることでチーム間の関係性や組織全体の構造を認知しやすくする  17

Slide 18

Slide 18 text

3つのインタラクションモード   18 4つのチームタイプ間のコミュニケーションや連携方法を3つのインタラクションモードとして定義し、チームのタイプやフェーズに応じて使い分ける  コラボレーション  共通の目的に対して他のチームと綿密に協力し合うモード     素早く探索や検証、そこからの学習を進める必要がある、領域の初期フェーズにおいて有効性が高いが、責務境界面を一定に曖昧にすることで短期的生産性は落ちる。  X-as-a-Service  あるチームが他のチームの提供物をサービスとして利用するモード     ブラックボックスとして利用する関係性で、責任境界やオーナーシップも明確で最小限のチーム連携になるが、相手の領域に踏み込まない力学が働くことで、境界面でのイノベーションを起こりにくくする可能性もある。   ファシリテーション  あるチームが他のチームに対して新技術の導入や習得をサポートするモード     組織においてCenter of Practiceを担える経験豊富なメンバーが中心となり、ティーチング・コーチングなどを用いて学習支援や習得の支援となる障害を取り除くアクションを行う。   18

Slide 19

Slide 19 text

チームトポロジーでの典型的なチーム連携   ストリームアラインドチーム   イネイブリングチーム      ファシリテーション  コンプリケイテッド・サブシステムチーム  X-as-a-Service  X-as-a-Service  プラットフォームチーム   19

Slide 20

Slide 20 text

4つのチームにおけるQAチーム   20 ストリームアラインドチーム   ビジネスの主な変更フロー=ストリームに沿って配置されるチーム     職能横断型であり、他のチームを待つことなく、要求探索から本番運用までのデリバリー一式を担える。4タイプの中心となるチームで、他のチームタイプはストリームアラインドチームをいかに強化するかを担う。  プラットフォームチーム   インフラや共通的な基盤などを提供するチーム     ストリームアラインドチームが詳細を知らなくても安定的かつ高速にデリバリーを担えるようにサポートすることで負荷を下げる。   イネイブリングチーム   他のチームに対して新しいケイパビリティの獲得（新技術やスキルの導入）を支援するチーム    特定領域のスペシャリストが主な構成メンバーで、組織においてCenter of Practiceとなる。   コンプリケイテッド・  サブシステムチーム   複雑性が高い（高度な専門スキルやドメイン知識が必要など）サブシステムやコンポーネントを提供するチーム  QAチームは「イネイブリングチーム」と一部「プラットフォームチーム」の役割を持っている  20

Slide 21

Slide 21 text

3つのインタラクションモードにおけるQAチーム   21 イネイブリングチームとしては「ファシリテーション」を、プラットフォームチームとしては「X-as-a-Service」を利用する  コラボレーション  共通の目的に対して他のチームと綿密に協力し合うモード     素早く探索や検証、そこからの学習を進める必要がある、領域の初期フェーズにおいて有効性が高いが、責務境界面を一定に曖昧にすることで短期的生産性は落ちる。  X-as-a-Service  あるチームが他のチームの提供物をサービスとして利用するモード     ブラックボックスとして利用する関係性で、責任境界やオーナーシップも明確で最小限のチーム連携になるが、相手の領域に踏み込まない力学が働くことで境界面でのイノベーションを起こりにくくする可能性もある。  ファシリテーション   あるチームが他のチームに対して新技術の導入や習得をサポートするモード     組織においてCenter of Practiceを担える経験豊富なメンバーが中心となり、ティーチング・コーチングなどを用いて学習支援や習得の支援となる障害を取り除くアクションを行う。   21

Slide 22

Slide 22 text

QAチームの方針   ● ストリームアラインドチーム（開発運用チーム）の自立をQA面から支援する   ○ QAの知識/技術/ツールを開発運用チームが利用できるように専門家は支援する   ● QAチーム内では大きく「QAコーチ」と「SET」の2つの役割に分かれている   ○ QAコーチはイネイブリング性が強く、SETはプラットフォーム性が強い   ■ 役割・インタラクションの仕方は固定ではなくその時のフェーズで変わる   ● 上記を基本方針としてDevOpsにおけるアジャイル（スクラム）以外の開発プロセスにおいては品質リスクを考慮した支援も行う    22

Slide 23

Slide 23 text

具体的なQA活動   イネイブリング性  ● 開発チームに加わり共にQA活動を行う（インプロセスQA）  ● 開発チームの外からQA活動の向上を支援する（QAコーチ）  ● 障害対応フローの整備・不具合分析の推進など    プラットフォーム性  ● 品質分析(観点レビューの実施、変更失敗率/平均修復時間のモニタリングなどの障害分析)   ● システムのテスト容易性の改善  ● テスト手順ドキュメントの整備など    23

Slide 24

Slide 24 text

イネイブリング（QAコーチ）の例   チームで品質についてディスカッション  QAメンバーはアドバイザーとして参加  チームで目指すQAの姿をディスカッション  QAメンバーはコーチとして参加し  トレーニングの計画も担当  24

Slide 25

Slide 25 text

プラットフォーム（SET）の例   現在稼働している自動テストをまとめて、何をテストしているのか・どうやってテストしているのかを整理した。  今後の自動テストの改善のベースライン  25

Slide 26

Slide 26 text

今後の取り組み   ● 全社的な品質文化の醸成  ● 品質関連研修コンテンツの充実  ● 障害対応の振り返りから不具合を分析してフィードバックする  ● システムのテスト容易性を向上させるデバッグ機能の開発  ● システムの安定稼働（SRE）とQAの連携  ● 生成AIを活用したテスト活動のトライアル    26

Slide 27

Slide 27 text

まとめ  ● タイミーのQAチームは「イネイブリングチーム」として開発チームのQA活動を支援することに重点を置いている  ● 開発チームとの関わり方はイネイブリングの他にもプラットフォームとしての関わり方があり、役割やフェーズによって変わる  ● これらを踏まえて、より良い関わり方や支援の方法について模索しながら活動をしている  27

Slide 28

Slide 28 text

ご清聴ありがとうございました！  28