一人目のQAになったらやりたいこと

転職活動時に一人目のQAとしてやりたいことをプレゼンした際の資料です。
本資料の記載内容は、現在の著者の考えとは若干異なります。

Transcript

1. 1人目のQAになったら やりたいこと （公開用）
2. 本資料をお読みいただく前の注意点 • 業務委託等も含めて初めて社内にQAエンジニアを受け入れる企業向けの資料で す。 ◦ テスト業務で業務委託を利用済みの企業は対象外 ◦ CTOやVPoEなどが既に理想のQAチームの体制を決めている場合は対象外 • 一般公開できるように、実際提出したものに修正を加えています。 ◦ 企業固有の文言を削除、口頭で補足した説明の追記など • 転職活動時に作成した内容であり、現在の著者の考えと若干異なります。
3. 目次 • なぜやるか • 会社全体の取り組み • 開発プロセスの取り組み • QAチームの組織体制 • 今後の進め方
4. なぜやるか
5. なぜやるか 他社よりも自社のサービスを選んでもらうためには、顧客の期待に応えるサービスの圧 倒的なUXを実現する必要がある ※　会社の目指すものに応じて文章を変える
6. サービスの圧倒的なUXを実現するために必要なこと • サービスの圧倒的なUX実現のために最適化された組織 ◦ プロダクトのUXだけでなく、顧客がプロダクトを利用する上での様々な UXを向上させる • プロダクトの圧倒的なUX実現のために必要な要素を最大化する開発プロセス ◦ 良いアイデア　×　高品質（不具合がない）　 ×　スピード • 上記開発プロセスを支える各領域でプロフェッショナルなメンバー
7. 会社全体の取り組み
8. なぜ会社全体の取り組みが必要か サービスのUXを構成する要素はプロダクトのUXだけではない モール型ECサイトの例 関係する人物 サービスのUXを悪化させる例 マーケティング お中元のGoogle広告をクリックしてもお中元専用のページがない セールス デモサイトがなくECサイト出店時のイメージが湧かない カスタマーサクセス ECサイト出店時のフォローが少なく出店までに時間がかかる プロダクト 使いづらい、不具合がある 社内オペレーター セールの期間設定にミスがあり、サイト表示より早くセールが終了 その他ステークホルダー 宛名にマンション名の記載がないので商品の誤配送が多い
9. なぜ会社全体の取り組みが必要か サービスのUXはエンジニアリングの力でも改善することができる モール型ECサイトの例 関係する人物 サービスのUXを改善させる例 マーケティング コンシューマーに訴求しやすい専用ページを実装（お中元特集など） セールス ECサイト出店者が実際に触れるデモサイトを実装 カスタマーサクセス 業務効率を改善する実装を行い、カスタマーサクセス用の工数を捻出 プロダクト 使いやすい、不具合が少ない 社内オペレーター セールの設定内容を動的にサイト表示して設定と表示の乖離を削減 その他ステークホルダー 入力フォームにマンション名を記載するよう注意書きを記載
10. 会社全体の取り組みで何をやるか • 各オペレーションの品質を見える化 ◦ 各オペレーションのリードタイム、顧客満足度、行動ログなど • 各オペレーションをエンジニアリングの力で改善する体制の構築 ◦ 各オペレーションの課題を定期的にヒアリングする場 ◦ エンジニアリング視点で各オペレーションを観察し改善点を探る ◦ 各オペレーション改善のための実装を定期的に実施（ 10%ルールなど） • 啓蒙や品質文化の醸成ではなく品質向上が楽しくなる組織作り ◦ 品質が大事と思わない人はいない。品質向上が楽しくできれば品質は自然に向上する ▪ 品質が向上した事を見える化 ▪ 品質が向上して人の役に立った事を体験（感謝の声のフィードバックなど） ▪ 自分が品質向上に貢献できる事を体験（適切な小さい目標を少しずつ達成する）
11. 開発プロセスの取り組み
12. プロダクトの圧倒的なUX実現のために必要な要素 • 良いアイデア ◦ 顧客のニーズについて正しい理解 ◦ ニーズに対する適切な解決策 • 高品質（不具合がない） ◦ 欠陥を埋め込まない力 ◦ 欠陥を検出できる力 • スピード ◦ 必要な事だけやる ◦ 手戻りをなくす ◦ ボトルネックをなくす • 各要素共通で必要なものはドメイン知識やシステム理解
13. 各要素共通で必要な取り組み • ドメイン知識やシステムに対する正しい理解 ◦ 取り組みの例 ▪ オンボーディングの充実 ▪ ドキュメント作成 ▪ 勉強会
14. 良いアイデアのために必要な取り組み • 顧客のニーズについて正しい理解 ◦ 取り組みの例 ▪ ユーザーの観察 ▪ ユーザーの声（ユーザーインタビュー、 NPS、サポートへの問い合わせなど） ▪ 行動ログの計測 ▪ カスタマージャーニーマップ、ペルソナ分析、ジョブストーリーなどの作成 • ニーズに対する適切な解決策 ◦ 取り組みの例 ▪ 多様なバックグラウンドの発想を取り入れる工夫（ブレストなど） ▪ 設計レビュー（仕様書のレビュー） • テスト技法等を用いた仕様検討漏れの検出 ▪ 動くプロダクトを直接触ったテスト（ユーザビリティ、ニーズに対する目的達成度） ▪ A/Bテストなど改修の結果ユーザーの行動が期待通りとなっているかをモニタリング
15. 高品質のために必要な取り組み • 欠陥を埋め込まない力 ◦ 取り組みの例 ▪ 設計レビュー（仕様書のレビュー） ▪ 実装前のテスト設計 ▪ アーキテクチャやコードの品質改善 ▪ 認識齟齬を減らす取り組み • 欠陥を検出できる力 ◦ 取り組みの例 ▪ 認識齟齬を減らす取り組み ▪ チームのテストスキル向上 • モブテスト設計やテスト設計レビュー、研修、テストプロセスの改善 ▪ テスト実行リソースの確保 ▪ 自動テスト（ユニットテスト、 APIテスト、E2Eテスト）
16. スピードのために必要な取り組み • 必要な事だけやる ◦ 取り組みの例 ▪ ドキュメントや改修内容は ROIを考える（リッチにし過ぎない） ▪ MVPを意識（最初に作り過ぎない） • 手戻りをなくす ◦ 取り組みの例 ▪ 不具合の早期検知 ▪ ブランチ戦略、その他プロセス • ボトルネックをなくす ◦ 取り組みの例 ▪ 業務効率化（自動化、自動テストなど） ▪ 属人化防止（スキルアップ、ドキュメントなど）、早期のリソースの確保
17. プロフェッショナルなメンバー （QAチームの組織体制）
18. QA系エンジニアの専門領域 一言にQAチームと言っても、QA系エンジニアの専門領域は様々 • テストエンジニア：テストの専門家 ◦ テスト戦略の立案、テスト計画、テスト設計、テスト実施、テストの進捗管理 ◦ レビューはテストに含まれる • SET（Software Engineer in Test）：自動テストやCIなどの専門家 ◦ 自動テストの戦略立案、自動テストの開発、 CIやAWS等の自動テスト実行基盤構築 • QAエンジニア：品質向上のために組織の力を向上させる人 ◦ 指標の計測やプロセス改善、振り返り力向上、シフトレフト、品質戦略立案 参考 https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qarelated-roles-and-specialties
19. QAチームのメンバー：他社の例 QAチームのメンバーの役割、体制は各企業で様々 • テストエンジニア、SET、QAエンジニアを分ける ◦ さらにユーザビリティやセキュリティの専門家を分けることもある • QAエンジニアのみでテストは開発者やBPさんが行う ◦ バグ密度/テスト密度などのKPIやプロセス実施状況の監査 • テストエンジニアのみ ◦ 主に手動のE2Eテストを実行する専門部隊 • 明確に分けない ◦ 原則テストの専門家ではあるが、役割を決めず各人で得意なこともやる
20. QAチームのメンバー：A社の事例 • 主にテストの専門家として活動 • SETもいるが、各開発チームできっちり役割分担はしていない ◦ CI/CD環境（Gitlab-CIやCircle-CIなど）は各開発チームでパイプライン等を構築可能 ◦ E2Eテスト自動化はテストエンジニアや開発者も行っている ◦ SET職の業務内容は通常のソフトウェアエンジニアに必要なスキルセットと比較的類似 • プロセス改善は開発チーム全員で行う ◦ 開発チーム外の人がプロセスを考えるよりも現場の人がプロセスを考えた方が良い ▪ 現場の人は開発チームの事情に詳しいので、現場の人の方が良いアイデアが出る ◦ 各開発チームにプロセスを改善できるメンバーが 1人はいる
21. QAチームのメンバー：結論 • テストの専門家は必要そう • プロセス改善、自動テストについては既存メンバーのスキルセットにもよる 最初はテストの専門家として体制を拡充しつつ、必要に応じて他の専門領域（QAエンジ ニア、SET）を増やすのが良さそう 組織全体の品質保証体制構築などを担うQAエンジニアの役割は、組織が拡大するま では1人目のQAエンジニアで賄うのが良さそう
22. 誰がテストを担当するか テスト担当者 メリット デメリット ・開発者がテストを担当 ・QAチームは開発者が良 いテストを行えるようにレ ビュー等でサポート ・属人化せずボトルネック等が発生し にくい ・ユニットテストも含めた各テストレベ ルのテスト品質が向上 ・テスト容易性が改善しやすい（開発 者がテストしにくさに気づく） ・開発者が品質に対する責任を持つ ・人をスケールしにくい 　・開発もテストもスキルが高い人は市 場に多くない 　・学習コストがかかる 　・すぐに成果を出せない ・開発者もQAチームもテス トを担当 ・上記とおおよそ同じ ・テスト担当をスケールしやすい ・役割分担のルール決めが必要 ・QAチームも開発系の知識が必要？ ・QAチームがテストを担当 ・テスト担当をスケールしやすい ・開発者が開発に専念できる ・開発者が品質に対する責任を持たなく なりがち ・ユニットテストも考慮した自動テスト戦 略を立てにくい
23. 誰がテストを担当するか 会社に応じて提案内容を変える • １プロダクトに開発者が１０名程度の企業 ◦ 開発者とQAチームの両方がテストを担当するタイプを提案 ◦ １プロダクトに大量の修正が入るため自動テストが重要。組織のスケールのしやすさも加味してこ のタイプを提案。 • 開発者１名が１プロダクトのPdM、開発、テストを兼務する企業 ◦ 開発者がテストを担当、 QAチームは開発者をサポートをするタイプを提案 ◦ １名で全て実施するからこそコミュニケーションコストなしでリリース可能な体制なので、その体制の 良さを活かすような体制を目指す
24. 今後の進め方
25. 短期的に成果を出しながら成長するために 改善を継続的に進められるようにするため、最初はわかりやすい成果を出しやすいもの を優先して実施 • 課題が強く認識されている ◦ ボトルネック ◦ 作業品質の課題が大きい • 成功の難易度が低い ◦ 工数があまりかからない ◦ 作業内容が難しくない ◦ 新たな技術の習得が不要、または、少ない 難易度の高い改善は、QAエンジニアとして信頼を得てから、また、組織全体で改善の 成功体験を増やして改善の熱量を高めてから行う
26. 現在考えている進め方 • 企業の課題に合わせて具体的な計画を書く、または、口頭で説明する ◦ 入社１ヶ月で◦◦、入社３ヶ月で◦◦、のようなプランを立てる • 以下は資料や口頭で説明した内容の例です ◦ テストが属人化しているので目指す品質の認識合わせやテストプロセスを標準化する ◦ PdMのリソースをテスト実施から解放（ QAチームが巻き取る） ◦ 自動テストを何となく実装しているので、自動テストの役割を明確化する ◦ スクラムを導入したばかりなので、スクラムに慣れるまでは学習の負荷を増やさないようにする。プ ロセスをあまり変えない施策を実施する ◦ 最初はプレイヤーとして動き、企業に最適な QAチームの体制を模索する（いきなり前職と同じ体制 などにしない）
27. 今後調査したいもの 定性分析の例 • 各人が感じている課題 • 組織の文化 • 着手してからリリースした後までの一連のプロセスを実際に見る • 見つかった不具合の内容 定量分析の例 • 見つかった不具合の件数、種類（よくある計測が目的化しないようにする） • リードタイム