品質の民主化 〜QAがいなくてもQAできるチームを目指して〜

Transcript

1. 品質の民主化 ― QAがいなくてもQAできるチームを目指して ― 株式会社タイミー QA Enabling G / @Masami Yajiri 2025/9/25
2. タイミーとは 2 ｢働きたい時間｣と｢働いてほしい時間｣を マッチングするスキマバイトサービス 従来の「求人サイト」でも「派遣」でもない
3. タイミーの特徴 3
4. タイミーの使われ方 働き手と雇い手がいるBtoCプラットフォームを提供しています。外からは見えづらいですが、スポットワークを実現するための雇い手 の手続きや課題は多く、そのプロセスのほとんどをシステム化しています。 4
5. タイミーの実績 スキマ バイト No.1 ※1 調査委託先：マクロミル　調査方法：インターネット調査　調査時期： 2025年1月31日～2025年2月4日 調査対象：直近１年以内にスキマバイトを経験したことのある 18～69歳の男女 1033人 ※2 調査委託先：マクロミル　調査方法：インターネット調査　調査時期： 2025年1月31日～2025年2月4日 調査対象：直近１年以内にスキマバイトを経験したことのある 18～69歳の男女 1033人 ※直近 1年以内に 2回以上働いた経験があるスキマバイトサービスを聴取 ※3 2025年7月時点　※ 4 2025年7月時点 利用率 ・リピート率 ※1 ※2 導入事業者数 200,000企業 ワーカー数 1,190万人 ※4 ※3
6. 目次 1. QAにおける負の力学 2. 力学の解明と解決策 3. 実践事例 4. 品質の民主化を目指して
7. 1 QAにおける負の力学
8. 品質保証の理想と現実 理想 品質は 全員 の責務 VS 現実 QA専門職 への 依存
9. なぜこの力学が生まれるのか？ 職能のサイロ化 「品質保証は専門家（ QA）の仕事」という分断 共依存の心理 エンジニア「QAがいるから安心」vs QA「頼られて嬉しい」 ビルドトラップ 「とにかく機能を作らなきゃ」というプレッシャー 品質のQA依存が生まれる
10. タイミーの組織設計 🔁コンウェイの法則 : 「システムの構造は、それを設計する組織の構造を反映する」 　　ストリームアラインド（価値提供）チームの集合
 　　　　ストリームアラインド（価値提供）チームの集合
 
 
 QA Enabling Team
 
 
 プラットフォームチーム
 ファシリテー ション
 コラボレーション 
 ファシリテー ション
 X-as-a-Service
 X-as-a-Service
 あるチームが他のチームの技術導入・習得を支援 共通の目的に対してチーム間で協力 チームの職能をサービスとして利用 👥逆コンウェイ戦略 : 組織の構造を「顧客への価値提供」に合わせて逆算的に設計・再編 自律的チームによる迅速な価値提供
11. QA Enabling Teamの位置付け 役割 ①QAコーチがCenter of Practiceとして活動 ②知識とスキルのスケーラビリティを促進 ③チームの行動変容による品質向上 インタラクションモード Facilitation あるチームが他のチームの技術導入・習得を支援 Collaboration 共通の目的に対してチーム間で協力 X-as-a-Service チームの職能をサービスとして利用 状況とフェーズに応じて インタラクションモードの「重心」を変化させる
12. 2 力学の解明と解決策
13. 品質活動を阻害する 4つの側面 技能 スキルとツールの不足 • QA知識の属人化・暗黙知化 • テストプロセスの知識・技能的ハードル • 品質メトリクス計測の難しさ 組織 職能のサイロ化 • 開発とQAの分断 • 共依存の心理 • 品質コストの認識不足 文化 誤った価値観 • アジャイルマニュフェストの誤解 • ビルドトラップ（アウトプット偏重） • 視点の固定化（How vs What/Why） 心理 変化への拒否反応 • 既存の役割への安住 • 新しい責任への恐れ • 短期的成果へのプレッシャー
15. 解決策 3つのアプローチで「負の力学」と闘う 🤝 行動変容 心理的安全性の確保 • 段階的責務移譲 • ペア~モブテスティング • 成功体験の設計 • 「やっていき」文化 🚀 Quality as Code 技術と文化の融合 • 品質知識の形式知化 • Shift -Left/Rightの統合 • DevOpsパイプライン • 生きたドキュメント 技能 文化 ⚖ リスクベースアプローチ 組織的な最適化 • 品質コストの可視化 • 品質基準の策定 • FMEAによる優先順位付け • ODCによる欠陥分析 • アウトカム評価 組織 心理
16. Quality as Code 主な取り組み 品質知識のコード化 • ナレッジベースのMarkDown管理 • バージョン管理可能なQAプロセス 1 Shift-Left / Rightの統合 • 早期品質作り込み＋本番モニタリング • 開発全体での品質保証 2 DevOpsパイプライン統合 • CI/CDでの自動品質チェック • 継続的な品質改善 3 実行可能な「生きた」仕様書 • 要求仕様書とUATの接続 • LLMによる自動生成、メンテナンス 4 暗黙知を形式知に
17. リスクベースアプローチ 品質コストの可視化（ 1:10:100の法則） 1 10 100 設計 テスト 本番 ⚖ 主な取り組み リスク（up/down）に基づく優先順位設定 高 中 低 品質指標の計測と可視化 FMEAベース評価 RPN=影響×発生×検知 DORA指標 デプロイ頻度/変更リードタイ ム/変更失敗率/MTTR 多層的カバレッジ基準 ホワイト/ブラックボックス ODC分析 欠陥の傾向分析
18. ビルドトラップを避け、アウトカム志向へ 「どれだけテストしたか？」 テスト実行数、網羅率 「どれだけバグを見つけたか？」 バグ検出率、密度 「活動量」 作業時間、タスク数 「インシデント防止のために何をする？」 予防的活動、リスク評価・回避策 「どれだけ安心できる？安全に使える？」 信頼性、顧客満足 「生産性」 ビジネス価値の提供速度 ❌QAのビルドトラップ ✅アウトカム志向 活動から成果へ
19. 行動変容 主な取り組み 協働による暗黙知の移転 実践を通じた知識・スキルの共有 2 Small Win（小さな成功体験）の積み重ね 段階的な自信の構築 3 段階的な責務移譲 1 共依存から相互補完のパートナーシップへ 「やっていき」文化の醸成 心理的安全性の確保によるチャレンジの促進 4
21. 3 実践事例
22. 大規模プロジェクトでの実践 📝プロジェクト概要 背景 給与計算に関わるタイミー 創業以来最大 のプロジェクト 背景 20名のプロダクトチームに対して 3名のQAで30+ストーリー の品質保証 🚀実践内容 ⚖リスクベース • FMEAベースのPRN評価 • 重要度に応じたテスト強度 • ODC分析によるバグ分類 🚀Quality as Code • 約3,000行の生きたナレッジ • LLMによる思考プロセス再現 • 仕様書駆動開発 🤝行動変容 • 全職能参加型レビュー • 開発者・PxM・CS巻き込み • 品質活動の民主化
23. リスクベースアプローチ
24. “Quality as Code”アプローチ
25. Lean Teamによるテスト品質の補強 成功の鍵 🤝 共通言語: 全員が同じナレッジベースを参照 🎯 具体的な成果物: LLM生成物を「たたき台」に議論できる ⚡ 効率的なレビュー: 各職能の専門性をオールスクラムで発揮 役割の再定義と協業モデル
26. 成果：QCDの目標達成 領域 成果 インパクト Quality クリティカル障害 0件 全体リリース後の重大インシデントゼロ Cost ROI 1000%+ テスト設計時間 16h→30min（97%削減） 追加投資なしで増員を回避 Delivery 遅延 0日 遅延なしで完遂
27. 成果：文化の変革 🚀職能依存から自律的品質保証に • 「QAに聞く」から「自分で判断」へ • リスク評価の内製化 • 品質プロセスの自走 • QAはファシリテーターとして支援 👥全職能参加の品質レビュー文化 • 開発者による自律的なテスト設計 • PdMが品質観点から仕様を検討 • CSが顧客観点で品質を評価 • 品質が「全員の関心事」に 🔁ダブルループ学習の実現 • 「問題」だけでなく「仕組み（力学）」を改善 • ナレッジベースの継続的更新 • プロセスの反復的な最適化 • 組織全体の品質成熟度向上 品質を「 QAの仕事」から「全員の責務」へ
28. 認識したリスクと制約 ⚠振り返り 直面した課題 • 初期の生産性低下 （学習曲線） 必要な前提条件 • 経営層の理解と支援 （根回し大事） • チームの成熟 （全てのチームに適応できるわけではない） 💡これらの制約を認識し、段階的な導入が大切
29. 4 品質の民主化を目指して
30. これからの QAのキャリア 新しいQA ✅品質文化のファシリテーター ✅職能をスケールさせるアーキテクト 従来のQA ☑テスター（問題の発見者） ☑ゲートキーパー（品質の門番） 「共依存」から「相互補完」のパートナーシップへ
31. 実践への第一歩 1 観察 2 設計 3 実践 「負の力学」の観察から始める • チームの状況を客観的に把握する • 品質活動の課題を洗い出す Small Win（小さな成功体験） を積み重ねる • 達成可能な粒度の目標設定 • ポジティブな高速フィードバックループ 3つのアプローチを状況により組み合わせる • アーキテクチャ（ex.QaC） / プロセス（リスクベース） / チーム運営をチームの特性 に合わせて設計 🔑ポイント チームの成熟度に応じた段階的な導入 • スキルとケイパビリティの確認 • 無理のない伴走 • 継続的なサポート • 振り返りと改善
32. 品質の民主化は夢じゃない
33. まとめ 戦略 品質コストの法則（1:10:100）とコンウェイの法則が示すように、 早期の品質の作り込みと組織構造の最適化が不可欠 仮説課題 品質保証のQA依存は「構造」ではなく「力学」の問題であり、 技術・組織・文化・心理の４側面から理解する必要がある 戦術 品質保証をアーキテクチャに融合（ex.QaC）、組織最適化（リスクベースアプローチ）、 行動変容（ex.心理的安全性の確保）の統合により、 DevOpsに統合された持続可能な品質文化 を実現する必要がある 品質は「誰かの仕事」ではなく「全員の責務」
34. Appendix: 参考文献 理論的背景 • コンウェイの法則とチームトポロジー • 品質コストの法則（1:10:100） • FMEA / ODC分析 実践ガイド • Quality as Code実装パターン • リスクベーステストの導入手順 • 心理的安全性の構築手順
35. ご清聴ありがとうございました！ 株式会社タイミー QA Enabling Team / @Masami Yajiri