開発部全体をより良くするための組織横断QAチャレンジ

1.6K Views

July 05, 24

スライド概要

【令和トラベル×ウェルスナビ×カカクコム】 プロダクトと共に進化し続けるQA組織のつくりかた
https://techplay.jp/event/946649

発表資料

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

開発部全体をより良くするための 組織横断QAチャレンジ 2024/7/5 【令和トラベル ウェルスナビ カカクコム】 プロダクトと共に進化し続けるQA組織のつくりかた 株式会社カカクコム 価格.com開発本部基盤システム開発部 QAスペシャリスト 伊藤由貴(@yoshikiito) 1

2.

目次 1. はじめに 2. QA組織の現状 3. スタート時からの取り組み 4. 学びと今後 2

3.

自己紹介:伊藤由貴(いとうよしき) n 仕事の経歴 l 2012 ~ 2022 株式会社ベリサーブにて 主にシステムテスト自動化の推進 l 2023 ~ 株式会社カカクコムにて 部門一人目のQAエンジニアとして 複数開発チームへの横断QA活動実施中 n 社外の活動 l JSTQB AL テスト自動化エンジニアシラバス翻訳 l テストツールまるわかりガイド改訂 l TechTeamJournal ライター l Sqripts スクリプター n X:@yoshikiito 3

4.

今回の概要 n 1人目のQAとして入社して以降、 QA組織立ち上げの過程で考えたことや取り組みについて l 今回は「もっとうまくやれたはず」「もっと良い判断があったかも」 といった苦労・反省の切り口でご紹介 4

5.

目次 1. はじめに 2. QA組織の現状 3. スタート時からの取り組み 4. 学びと今後 5

7.

サイトの特徴・性質 n 開設からの歴史が長い l 20年以上続いている n ビジネス面で安定している l 売上が右肩上がりで「*年で*倍に!」というフェーズではない n PV・利用者数の規模が大きい l 開発組織も複数の部からなる規模 7

8.

開発組織の構成 100名弱 開発部1 価格.com 開発本部 開発チーム1-B … 開発部2 開発チーム1-A 開発部3 デザイン部1 開発チーム3-A デザイン部2 開発チーム3-B QA(私) 開発チーム3-C QA 8

9.

QA組織として目指す姿と施策 n 目指す姿 l 開発者主体で品質保証に関する活動および その継続的改善ができる • QAエンジニアはそのための支援を行う n 施策 l 現状可視化・分析・改善 • 開発チームでの取り組み可視化や障害分析の基盤構築など l 共通化・効率化 • テスト観点蓄積、自動化など l 品質技術習得 • 勉強会、ナレッジベース作成など 9

10.

目次 1. はじめに 2. QA組織の現状 3. スタート時からの取り組み 4. 学びと今後 10

11.

1人目QAとしてJoinした時点 n 状況 l 7つの開発部、15のサービス がスコープ l それまでQAエンジニアはおらず、 テスト会社への依頼や業務委託のテスト担当者もなし l QA活動はテストが中心で、開発者が自分たちで行っている • 逼迫した品質課題や炎上などは無い状態 n 目指すこと l 各開発部・開発チームでの、QAという切り口での全体最適化 11

12.

作りたいと考えた組織のイメージ QA部 本部 QA マネージャ 開発部1 開発部1 担当QA 開発部2 開発部2 担当QA 開発部3 開発部3 担当QA … … 開発部N SET 開発部N 担当QA SET 12

13.

組織づくりにおける問題と対策 n 問題:社内的にも、市場的にも、好き放題採用はできない l 他部門との兼ね合いも加味した人員計画 l スキル・経験のあるQAエンジニア採用の難易度高 n 対策:1名、増えて2,3名体制を前提にQA業務を進める l 採用活動は行いつつも、まずは1人でできることを スモールスタートで行う 13

14.

特定プロダクトのQAと横断QAの違い ※個人の感覚です。実は違いは無い!などぜひ議論したいポイントです 特定プロダクトのQA 横断QA スタンス • 自分たちが実業務を行う • 内側で活躍 • 個々の開発チーム内で 実業務をやってもらう • 外から支援 主な業務 • PRJごとのレビューやテスト • プロセスや仕組みの整備 • 開発者への品質技術移転 14

15.

横断QAとしてのアプローチ n 横断QAが “QA文化” や様々な取り組みを 開発組織に浸透させる場合・・・ l トップダウン型:プロセスや標準などを決めて、現場におろす l ボトムアップ型:個々のチームでの改善を横展開していく • 特定プロダクトのQA的な動きから始める いいとこどりを目指して 「両方やる」を選択 15

16.

両立をめざした結果 n トップダウン型アプローチでの施策 l 各チームでのQA活動状況の可視化と定期チェック l 障害情報の蓄積と分析の基盤づくり(価格.com) n ボトムアップ型アプローチでの施策 l 一部チームにJoinし、テストのレビュー等参加 l テストプロセスの整備や導入 16

17.

ボトムアップ型アプローチ横断QAの問題 n 開発チームにとって価値を感じづらいQAに・・・ l テスト等の実業務を行うにはドメイン知識が不足しているが、 「半分Join」状態ではキャッチアップがままならない l QAの活用方法が曖昧で、遠慮されやすい • 「忙しそうなので、関係ありそうなMTGのとき呼びます!」→呼ばれなくなる • ずっと居るわけではないQAを開発業務のプロセスには組み込めない n なぜそうなったか l 逼迫した品質課題が(実感として)無かった l 今までQA無しで回っていた 17

18.

目次 1. はじめに 2. QA組織の現状 3. スタート時からの取り組み 4. 学びと今後 18

19.

横断QAのよいアプローチ、学びと仮説 n 異なるプロダクトに共通する標準・仕組みを トップダウンで考え、普及する難しさ l ナレッジを汎化をしていった結果、メッセージが薄まる • 例)「ちゃんと単体テストを書きましょう」 n 横断QAはボトムアップ寄りのほうがうまくいくのではないか l 対象を絞ったうえで結果を出して横展開、のほうが推進力に勝る 19

20.

今後 n 2人目のQAの方の立ち上がりとともに、 ボトムアップ型のアプローチでの活動を強化 l チームにQA居たほうがいいよね!の実感を持ってもらう n 価格.comにおけるQAの(私が思う)存在意義 l サイトの急成長を支える・・・という場面はないかもしれないが、 リニューアルや改善施策を安心して行える状況に貢献したい l ビジネスの柱の一つである価格.comでQA活動の知見をためることには 意味がある • 他サイトや、今後新規サイト立ち上げ時に人や仕組みが活きるはず 20

21.

参考 QAがQAしないでQAするために JaSSTʼ24 Kansai QAエンジニアの仕事をつくる 21

22.

以上、ありがとうございました 22