Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kishiken
November 08, 2024

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

kishiken

November 08, 2024
Tweet

More Decks by kishiken

Other Decks in Technology

Transcript

  1. 自己紹介
 岸 健(kishiken)
 タイミー
 エンジニアリング本部 QA Enabling Team 
 Software

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

  2. タイミーの実績 スキマ バイト No.1 ※1 ※2 [調査方法]インターネット調査 [調査期間]2024 年 2

    月 9 日~11 日 [調査概要]スキマバイトアプリサービスの実態調査 [調査 委託先]株式会社マクロミル ※3 2024年9月時点 ※4 2024年9月時点 利用率 ・リピート率 ※1 ※2 導入事業者数 136,000企業 ワーカー数 900万人 ※4 ※3
  3. 組織と開発生産性に関するタイミーでの必読書 
 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 

  4. イネイブリングチームはチームトポロジーに由来 
 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 

  5. チームトポロジーでの典型的なチーム連携 
 ストリームアラインドチーム 
 イネイブリン グチーム
 
 
 ファシリテーショ ン


    コンプリケイテッド・サブシ ステムチーム
 X-as-a-Service
 X-as-a-Service
 プラットフォームチーム 
 16
  6. 4つのチーム 
 17 ストリームアラインドチーム 
 ビジネスの主な変更フロー=ストリームに沿って配置されるチーム 
 
 職能横断型であり、他のチームを待つことなく、要求探索から本番運用までのデリバリー一式を担 える。4タイプの中心となるチームで、他のチームタイプはストリームアラインドチームをいかに強化

    するかを担う。
 プラットフォームチーム 
 インフラや共通的な基盤などを提供するチーム 
 
 ストリームアラインドチームが詳細を知らなくても安定的かつ高速にデリバリーを担えるようにサ ポートすることで負荷を下げる。 
 イネイブリングチーム 
 他のチームに対して新しいケイパビリティの獲得(新技術やスキルの導入)を支援する チーム
 
 特定領域のスペシャリストが主な構成メンバーで、組織においてCenter of Practiceとなる。 
 コンプリケイテッド・
 サブシステムチーム 
 複雑性が高い(高度な専門スキルやドメイン知識が必要など)サブシステムやコンポー ネントを提供するチーム
 4つのチームタイプに絞り、目的・役割・責任を明確にすることでチーム間の関係性 や組織全体の構造を認知しやすくする
 17
  7. 3つのインタラクションモード 
 18 4つのチームタイプ間のコミュニケーションや連携方法を3つのインタラクションモード として定義し、チームのタイプやフェーズに応じて使い分ける
 コラボレーション
 共通の目的に対して他のチームと綿密に協力し合うモード 
 
 素早く探索や検証、そこからの学習を進める必要がある、領域の初期フェーズにおいて有効

    性が高いが、責務境界面を一定に曖昧にすることで短期的生産性は落ちる。
 X-as-a-Service
 あるチームが他のチームの提供物をサービスとして利用するモード 
 
 ブラックボックスとして利用する関係性で、責任境界やオーナーシップも明確で最小限のチーム連携 になるが、相手の領域に踏み込まない力学が働くことで、境界面でのイノベーションを起こりにくくす る可能性もある。 
 ファシリテーション
 あるチームが他のチームに対して新技術の導入や習得をサポートするモード 
 
 組織においてCenter of Practiceを担える経験豊富なメンバーが中心となり、ティーチング・コーチン グなどを用いて学習支援や習得の支援となる障害を取り除くアクションを行う。 
 18
  8. チームトポロジーでの典型的なチーム連携 
 ストリームアラインドチーム 
 イネイブリン グチーム
 
 
 ファシリテーショ ン


    コンプリケイテッド・サブシ ステムチーム
 X-as-a-Service
 X-as-a-Service
 プラットフォームチーム 
 19
  9. 4つのチームにおけるQAチーム 
 20 ストリームアラインドチーム 
 ビジネスの主な変更フロー=ストリームに沿って配置されるチーム 
 
 職能横断型であり、他のチームを待つことなく、要求探索から本番運用までのデリバリー一式を担 える。4タイプの中心となるチームで、他のチームタイプはストリームアラインドチームをいかに強化

    するかを担う。
 プラットフォームチーム 
 インフラや共通的な基盤などを提供するチーム 
 
 ストリームアラインドチームが詳細を知らなくても安定的かつ高速にデリバリーを担えるようにサ ポートすることで負荷を下げる。 
 イネイブリングチーム 
 他のチームに対して新しいケイパビリティの獲得(新技術やスキルの導入)を支援す るチーム
 
 特定領域のスペシャリストが主な構成メンバーで、組織においてCenter of Practiceとなる。 
 コンプリケイテッド・
 サブシステムチーム 
 複雑性が高い(高度な専門スキルやドメイン知識が必要など)サブシステムやコンポー ネントを提供するチーム
 QAチームは「イネイブリングチーム」と一部「プラットフォームチーム」の役割を持っ ている
 20
  10. 3つのインタラクションモードにおけるQAチーム 
 21 イネイブリングチームとしては「ファシリテーション」を、プラットフォームチームとして は「X-as-a-Service」を利用する
 コラボレーション
 共通の目的に対して他のチームと綿密に協力し合うモード 
 
 素早く探索や検証、そこからの学習を進める必要がある、領域の初期フェーズにおいて有効

    性が高いが、責務境界面を一定に曖昧にすることで短期的生産性は落ちる。
 X-as-a-Service
 あるチームが他のチームの提供物をサービスとして利用するモード 
 
 ブラックボックスとして利用する関係性で、責任境界やオーナーシップも明確で最小限のチーム連携 になるが、相手の領域に踏み込まない力学が働くことで境界面でのイノベーションを起こりにくくする 可能性もある。
 ファシリテーション 
 あるチームが他のチームに対して新技術の導入や習得をサポートするモード 
 
 組織においてCenter of Practiceを担える経験豊富なメンバーが中心となり、ティーチング・コーチン グなどを用いて学習支援や習得の支援となる障害を取り除くアクションを行う。 
 21
  11. QAチームの方針 
 • ストリームアラインドチーム(開発運用チーム)の自立をQA面から支援する 
 ◦ QAの知識/技術/ツールを開発運用チームが利用できるように専門家は支援する 
 • QAチーム内では大きく「QAコーチ」と「SET」の2つの役割に分かれている

    
 ◦ QAコーチはイネイブリング性が強く、SETはプラットフォーム性が強い 
 ▪ 役割・インタラクションの仕方は固定ではなくその時のフェーズで変わる 
 • 上記を基本方針としてDevOpsにおけるアジャイル(スクラム)以外の開発プロセスにおいては品 質リスクを考慮した支援も行う
 
 22
  12. 具体的なQA活動 
 イネイブリング性
 • 開発チームに加わり共にQA活動を行う(インプロセスQA)
 • 開発チームの外からQA活動の向上を支援する(QAコーチ)
 • 障害対応フローの整備・不具合分析の推進など
 


    プラットフォーム性
 • 品質分析(観点レビューの実施、変更失敗率/平均修復時間のモニタリングなどの障害分析) 
 • システムのテスト容易性の改善
 • テスト手順ドキュメントの整備など
 
 23