QAがQAしないでQAするために

QAがQAしないで QAするために 2024/4/11 最後の門番はもう古い！？QA2.0をQA立ち上げ期の2社が語る 株式会社カカクコム 価格.com開発本部基盤システム開発部 QAエンジニア 伊藤由貴（@yoshikiito） 1

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

発表の概要 n 部門1人目のQAとして活動を始めて・・・ l こんなQA組織にしたいと思っている、目指す姿 l QA組織立ち上げのために行ったこと l 困っていること うまくいっていないところも含めて なるべくリアルにお伝えします。 パネルトークや懇親会で議論しましょう! 3

QA組織の目指す姿 4

QA組織の目指す姿 n 開発者主体で、品質保証に関する活動およびその 継続的改善ができる l QAエンジニアはそのための支援を行う QA（エンジニアだけ）が QA（関連の活動を）しないで （開発チーム全体で）QAする 5

開発者主体でのQAを目指す２つの理由 体制 の理由 文化 的な理由 7

開発組織の構成とQAの立ち位置（24年度） 100名弱 開発部1 価格.com 開発本部 開発チーム1-B … 開発部2 開発チーム1-A 開発部3 QAの立ち位置 • 各部・チームに対して広く浅く テスト等の活動を支援 • テストの実務を担うのではなく、 デザイン部１ 開発チーム3-A デザイン部２ 開発チーム3-B 開発チーム3-C テストプロセス整備や技術移転 QA(私) !どうやって・どんなQA活動をしたものか・・・ 8

最後の門番はもう古い！？ n 古いというより、そもそも門番になれない。 l 現状の体制で最後の門番をやろうとすると ボトルネックになることが見えている l 最後の門番ができるだけのQA体制を作るのは困難 9

開発者主体でのQAを目指す２つの理由 体制 の理由 文化 的な理由 10

開発者自身でテストを行ってきた n ユニットテスト以外、結合・システムテストの 設計（相当のこと）〜実行などなど l これまで専任のQAエンジニアが居なかった l テストのアウトソースやテスト会社への依頼もしてこなかった 11

議論したいポイント n 開発者からテスト業務を「はがす」ことの是非 l 工数メリットや、より開発者がスペシャリティを 発揮するという点ではよいと思う l 一方、テスト設計や実行が開発業務によい効果をもたらす 側面もあると考える • 開発者の「テスター・QAが見るでしょ」意識に悩むQAエンジニアも 世の中には一定居る 12

再掲：QA組織の目指す姿 n 開発者主体で、品質保証に関する活動およびその 継続的改善ができる l QAエンジニアはそのための支援を行う QA（エンジニアだけ）が QA（関連の活動を）しないで （開発チーム全体で）QAする 13

目指す姿を実現するために 実際に行っている取り組み 14

行動を促すための活動 １ ２ QA活動の指針＆現状把握の手段を提供 n QAガイド・QAクライテリアの作成と展開 テストのスキルや考え方の伝達 n 勉強会やレビュー等による技術移転 15

QA活動の指針としてのQAガイド n 各開発部におけるQA（品質保証）に関する活動について、共 通してやるべきこと、やったほうがいいこと、目指す状態な どを記したもの n ねらい l 各チームがそれぞれの品質向上のために何をすべきかを把握し、改善 活動につなげる l 品質向上の土台をつくり、チーム間での共通認識をもって改善を行う 16

QAガイドのサンプル 17

現状把握のためのQAクライテリア n 前述のQAガイドをただ渡して 「これに則ってがんばってね！」では何も進まない n どのくらいQAガイドに即した活動が出来ているのか、 取り組みの状況を可視化するための セルフチェックのリストとしてQAクライテリアを用意 18

QAクライテリアのサンプル n 質問項目の例 l 仕様書やテストケース、開発ルールなどを散在させず関係者全員が見 えるところで一元管理している。 l チーム内でコードレビューを行っている。 l チーム内でテストケースやテストコードのレビューを行っている。 l 発生した障害の傾向を分析し、開発プロセスの改善を行っている。 など 19

QAクライテリアのサンプル 緑：だいぶできてる 黄：そこそこできてる 赤：あまりできていない 20

クライテリア結果を元にした改善活動 n 各チームごとの改善活動 l 自チームの過去の結果と現在の結果を比べ 次の対策を検討 n QAとしての改善活動 l 全体の傾向や、同じ部内でのギャップが大きいところ等に注目し、 部門横断で改善すべきポイントや、各部内でナレッジ共有して もらうところなどを探る 21

参考：調査そのものが意識付けになる 皆さんは自社のES調査（伊藤注：従業員満足度調査）で、 下記のような質問項目を定期的に繰り返し問われたとしたら、 どのように思うでしょうか。 • あなたの職場では、オープンにコミュニケーション できていますか？ • あなたの職場では、メンバー同士は信頼しあっていますか？ 言うまでもなく、こうした質問項目を何度も問うこと自体が、 「職場ではオープンにコミュニケーションすべきである」 「メンバー同士は信頼しあうべきである」というメッセージを、 暗に伝えているのです。 22

行動を促すための活動 １ ２ QA活動の指針＆現状把握の手段を提供 n QAガイド・QAクライテリアの作成と展開 テストのスキルや考え方の伝達 n 勉強会やレビュー等による技術移転 23

QAの技術移転や品質文化の浸透、技術向上 引用：品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） ※赤枠は伊藤にて加工 24

• https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties

技術移転のために考える（た）こと n QA・テストエンジニアの考え方・やり方を 開発者向けにして展開 l 取り入れやすく、小さな効果が得られそうなものから l 「正論・べき論」「今やるならこう」をセットで伝える n 開発者が能動的に情報取得できる形を用意 l ナレッジベースの拡充 l 勉強会の定期開催 25

組織の変化 n QAクライテリアの結果が少しずつ改善（赤→黄、黃→緑へ） n QAへの支援依頼や相談が増えた l テストを考える際のよいやり方はないか、など 自分たちがうまくやるには、という相談 26

まだまだ残る課題 n 状況を可視化した次のステップ、改善活動のパワー不足と その結果としての変化のスピード感 n 定性成果（障害数、リリース速度など） ※幸いすぐに目に見える大きな変化を、という無理な要求は無いため 基本的な改善をしっかり進める方向 27

まとめ 28

まとめ：QAがQAしないでQAするために n 立ち上げ期の現状 l 開発者主体でQA活動ができる状態を目指す l 改善の土台となる現状可視化やスキル移転などを実施中 n 取り組みの経過 l いろいろな面で可視化はできつつあるが、 そこから何を読み取ってどう改善に繋げるか、は 推進する役割が必要 ←ここがQAエンジニアの出番 29

以上 ご質問・ご意見などぜひコメントください" 30