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

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

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

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

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

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

6

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• https://www.docswell.com/s/yoshikiito/5RX17N-2024-04-15-101317
• https://www.docswell.com/s/yoshikiito/KLL73D-jasst24kansai-QAEngineer-Job-Crafting

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