１人目のQAエンジニアが入社３ヶ月でやったこと

Transcript

1. １人目のQAエンジニアが 入社３ヶ月でやったこと かわちーばー(@kawabeaver)
2. 本発表のゴール • １人目のQAエンジニアにチャレンジしたい人を応援する ◦ １人目のQAエンジニアを目指す上でどのような業務経験を積めば良いか参考にしていただく ◦ １人目のQAエンジニアは何をすれば良いかわからないという不安を軽減する • １人目のQAエンジニアとしてご活躍中の方を応援する ◦ 他社事例をご自身の活動の参考にしていただく • １人目のQAエンジニアを募集したい企業を応援する ◦ １人目のQAエンジニアに期待したいことのイメージを持っていただく
3. 自己紹介 ソフトウェアテストのことを少し知っているビジネスパーソン • 経歴 ◦ 2012年〜2014年　第三者検証会社 ▪ 主にECサイトのテスト業務を担当 ▪ テスト設計、テスト実施、テスト実施の管理、 Selenium IDEでの自動テスト作成 ◦ 2014年〜2021年　医療系事業会社 ▪ 主に医療系ポータルサイトのテスト業務を担当 ▪ 仕様レビュー、テスト設計、テスト実施、 Selenium（Ruby）での自動テスト作成 ▪ QAチームのチームリーダー（ 1年半） ◦ 2022年〜現在　　SaaS企業 ▪ １人目の社員QAエンジニア（マネージャー） ◦ その他 ▪ テスト設計コンテスト決勝戦出場
4. 話の前提（弊社について） • 開発者自身がテスト業務（テスト設計、テスト実施）を担当する文化 ◦ 「テスト業務を業務委託の方に任せていたが内製化したい」という話ではないので注意 ▪ 私が入社するまでQAエンジニア歴の長いフルタイム勤務の人は不在 • 私が担当するプロダクト（2022年3月時点） ◦ Webアプリケーションとネイティブアプリ（ WebViewがメイン）を開発 ▪ 顧客コミュニティのWebサイト・ネイティブアプリをノーコードで構築できる SaaS ◦ プロダクトマネージャー 2名、開発者14名、SRE4名、デザイナー2名、QA1名 ◦ ２週間スプリントのスクラム開発 ▪ 一部はプロジェクト単位（スクラム外）で進捗管理
5. 今日お話すること 入社３ヶ月でやったこと＋失敗談 • 自分（QAエンジニア）のことを知ってもらう • 状況の分析を行う • 短期的な活動内容を決める • 長期的な活動内容を決める • 採用活動を行う • 失敗したこと
6. 自分のことを知ってもらう
7. 自分（QAエンジニア）のことを知ってもらう • なぜやるか ◦ QAエンジニアと働いたことがない人が殆どなので、 QAエンジニアが何をする人か知らない ▪ QAエンジニアに対する期待値の調整、 QAエンジニアとの接し方を共有する必要がある • 何をするか ◦ 以下のQMファンネルの資料をベースに QAエンジニアは一般的にどんな人かを説明 ▪ https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organiz e-qarelated-roles-and-specialties ◦ 自分はどのようなスキルを持っているかを説明 ◦ 自分にできないこと、協力してほしい領域を説明 ◦ 自分がどんなことを目指しているかを説明
8. 実際に説明したこと ソフトウェア開発におけるQAエンジニアのよくある役割を説明 • テストの専門家 ◦ 主にブラックボックステスト、手動テストの領域でテストの専門家として活動 ◦ テスト計画の立案、テスト設計、テスト実施、テスト実施のマネジメント、仕様レビュー • 自動テストを推進する人 ◦ 自動テスト（E2Eが多い）のコードを書く ◦ 自動テストを各開発チームが運用できるようにする ▪ 自動テストを実行するCI環境、ラッパーなどの共通基盤を整える、トレーニングを実施 ◦ 通常はSET（Software Engineer in Test）などと呼ばれ、QAとは独立した職種の場合が多い • 品質を向上させるためのプロセスを考えたりする人 ◦ テストよりも広い領域（組織、開発プロセス）で品質向上のための取り組みを行う ◦ 品質目標・指標の決定、プロセス改善、振り返りや再発防止策の検討、情報共有、など
9. 実際に説明したこと 私の経歴 • テストの専門家 ◦ 主にブラックボックステスト、手動テストの領域でテスト業務を 9年（DB、サーバーのログは見れる） • 自動テスト ◦ Selenium IDE（1年半）、Seleniumのコードを書く（テスト業務と並行して7年） ◦ E2Eテストを実行できる環境を整えた（JenkinsとWindowsマシンの組み合わせ） • プロセスを考えたりする人 ◦ プロセス改善、振り返りの習慣化、1年半QAチームのリーダー（チーム立ち上げではなくリーダー引き継ぎ） • 苦手なこと（協力をお願いしたい領域） ◦ 開発業務の経験はない（コードを読んで実装内容の雰囲気はわかる。 Gitは使える） ◦ CIやインフラ系の業務経験も殆どない
10. 実際に説明したこと 私が体制を作る上で大事にしたいと考えていること • 組織の文化や状況に応じた体制を作る ◦ CTOの考え方「すべてのエンジニアはクリエイターでありテスターである」 ▪ エンジニア（開発者）に品質向上やテストに積極的に関与させたい ◦ 前職のコピーではなく、弊社にとってベストな体制を作る ▪ 実装はエンジニア、手動テストは QAという分業体制では恐らくスピードが出ない • エンジニアとQAの人数比、土日のみ稼働のエンジニアがいる、など • １プロダクトに多数の改修を入れるので、自動テストが前職よりも重要 • 品質文化の醸成ではなく、品質向上を楽しく ◦ 品質が大事だと思わない人はいない。品質向上を楽しく行えれば自然と品質は向上する ▪ 顧客に喜んでもらえていることを実感する ▪ チームや個人の成長を実感する ▪ 品質向上に貢献するための障害を減らし、品質向上に貢献できる機会を増やす
11. 実際に説明したこと 私が目指すもの「世界で幅広く利用されるサービスを提供できる組織を作る」 • 世界で幅広く利用されるサービス ◦ グローバルスタンダードになるサービス（圧倒的に価値の高いサービス）を目指す ◦ プロダクトのUXだけではなく、CSやセールス含む「サービス」の UXをよくする ▪ 顧客にとっては、機能を利用できない原因がバグでも CSの返答待ちでも同じ損失 • 提供できる組織を作る ◦ 圧倒的に価値の高いサービスに素早く成長させるには効率的・高品質な作業が必要 ◦ そのような作業を「組織が拡大しても」行える体制を作る ▪ 個人の経験に依存せず、技術・プロセス・人の成長で効率的・高品質な作業を目指す • QAチームは本人の強みに応じて組織作りに貢献をする ◦ 組織の体制を作る人、プロセスを作る人、成長する仕組みを作る人 ◦ 技術を活かしてプレイヤーとして貢献する人
12. 状況の分析を行う
13. 状況の分析を行う • なぜやるか ◦ 会社の事情を鑑みずプラクティスを当てはめると会社に合わなくて失敗する可能性がある ◦ リソースが限られているので、費用対効果の高い施策から実施したい（優先度を決めたい） ◦ 課題を明らかにした上で他の人に協力を求めると、納得感を持って協力してもらえる • 何をするか ◦ 前提知識の習得 ▪ 開発チームの文化、ルール、プロセスを知る ▪ ドメイン知識・プロダクトの理解を深める ◦ 定性分析 ▪ 開発チームが感じている課題などをヒアリングする ▪ 開発チームに参加して現場で起きていることを見る ◦ 定量分析　※容易に計測可能だったもの ▪ 不具合チケットを分析する ▪ 自動テストのカバレッジを確認する
14. 実際にやったこと（前提知識の習得） • 開発チームの文化、ルール、プロセスを知る ◦ 会社の説明資料、CEOなどが会社説明をしている記事や動画を見る ◦ CTOの考え方を記載した資料、開発チームの課題図書「 Team Geek」を読む ◦ 開発チームのメンバーと話す、開発チームを観察する ◦ コーディングの方針を読む ◦ 開発プロセスやルールを記載した資料を読む • ドメイン知識・プロダクトの理解を深める ◦ プロダクトのヘルプページを読む ◦ プロダクトを実際に触る ◦ 営業資料などビジネスサイドの資料を読む ◦ Slackのビジネスサイドのチャンネルに参加して情報収集
15. 実際にやったこと（定性分析） • 開発チームが感じている課題などをヒアリングする ◦ CTO、開発者のマネージャー、開発者、スクラムマスター、 SRE、プロダクトマネージャー • 開発チームに参加して現場で起きていることを見る ◦ Slackの開発チームのチャンネルに参加 ◦ スクラムのセレモニーに参加 ◦ PdM、PMM、CS間のミーティングに参加（リファインメントの前工程） ◦ テスト設計結果を確認
16. 実際にやったこと（定量分析） • 不具合チケットを分析する ◦ 本番障害（市場バグ）の月あたりの件数を計測する ◦ 本番障害におけるテスト漏れの原因を分析し、件数を計測する • 自動テストのカバレッジを確認する ◦ 機能一覧を作成し、E2Eテスト（UI）のコードを読み、機能一覧に対するカバレッジを計測 ◦ ユニットテストのコードカバレッジを計測
17. 分析の結果 • 本番障害・UXといった品質向上の優先順位が開発スピード向上よりも高い • 仕様が複雑な機能がいくつかある。その機能はテスト漏れが発生しやすそう • スクラムでの開発にまだ慣れていない • 開発者がテスト業務も担当すべきという文化 • 開発者は自分のテスト設計のやり方に自信が持てていない • Cypressの自動テスト（UI）は多めだがカバーできていない機能もある • テスト漏れの原因の割合は、テスト内容＞認識齟齬＞自動テスト＞その他 ◦ 「自動テスト」はテストの専門家でも思いつきにくい箇所のデグレの事例 • テスト内容の課題の割合は、テスト分析（観点洗い出し）＞＞テスト技法
18. 短期的な活動内容を決める
19. 短期的な活動内容を決める • なぜやるか ◦ 継続的な損失を出す課題があるのに長期的な施策だけ行うと致命的な損失になる可能性あり ▪ すぐできる暫定対応を実施してから長期的な恒久対応を実施する ◦ 短期的に成果を出すことで早期に開発メンバーの信頼を得る ▪ 信頼を得る前に大きな改革を実施しようとしても協力や納得感を得にくく失敗する • 何をやるか ◦ 解決する課題の優先順位を決める ◦ 短期的に実施できる費用対効果の高い施策を検討する ◦ なるべく開発プロセスを大幅に変えない施策を検討する ▪ プロセスを大幅に変えると、新しいプロセスに慣れて成果が出るまでに時間がかかる ◦ 施策の効果測定方法を検討する
20. 実際に行った活動 • 解決する課題の優先順位を決める ◦ 品質向上の優先順位が高い、かつ、テスト漏れの原因の大部分はテスト分析 ▪ テスト分析（観点の洗い出し）の強化を優先する • 短期的に実施できる費用対効果の高い施策を検討する ◦ 開発者の成長やQAエンジニア増員は早期実現が困難。私が関与することが成果を出す近道 ◦ 私が開発者14名分の全チケットのテスト分析・テスト設計をすると開発スピードが落ちる ▪ 私が開発者のテスト設計結果をレビューする体制にする • 開発プロセスを大幅に変えない施策を検討する ◦ 遅くともプルリクエスト作成までにテスト設計結果を箇条書きで簡単に記載してもらった • 効果測定の方法を検討する ◦ プロセス変更が不要となるよう従来からある仕組み（顧客からの問い合わせ件数）を計測
21. 活動の成果（2022年3月時点） • 顧客からの問い合わせ件数を50％以上削減 ◦ 1月の件数と3月の件数を比較 • テスト分析が原因のテスト漏れ件数を80%以上削減 ◦ ただし、プロダクトを触らないとわからないような UI上の問題は検出できていない • 自分のテスト設計レビュー待ちでリリースが遅延した事例なし ◦ 開発スピードをそこまで損なわずに品質向上を達成
22. 長期的な活動内容を決める
23. 長期的な活動内容を決める • なぜやるか ◦ 効率的・高品質な作業を「組織が拡大しても」行える体制を作ることを目指している ▪ テスト内容の品質が私依存となっており、開発者が増えたら自分がボトルネックになる ◦ まだ解決できていない品質上の課題が残っている • 何をやるか ◦ 開発チーム全体のテストスキルの強化 ◦ 残っている品質上の課題に対する優先順位を決定 ◦ 残っている品質上の課題に対する施策の検討
24. 実施を検討している活動内容 • 開発チーム全体のテストスキルの強化 ◦ メンバーのテストスキルの強化（テストプロセスの研修、など） ◦ テスト分析・設計に有用なナレッジを貯める（機能一覧、テスト観点一覧、など） ◦ テストプロセスの改善（各工程で何を実施するかの定義、無駄な工程の改善、など） • 残っている品質上の課題に対する優先順位を決定 ◦ 自動テスト（デグレ）、認識齟齬、プロダクトを触らないとわからない UI上の問題 • 残っている品質上の課題に対する施策の検討 ◦ 自動テストの拡充（ユニットテスト、 APIテスト、UIテスト） ◦ 認識齟齬が生じにくい受け入れ条件の書き方を決める ◦ UI上の問題を検出するための探索的テストの実施、実施のための様々な準備
25. 採用活動を行う
26. 採用活動を行う • なぜやるか ◦ 仲間が多い方ができることが増える ▪ それぞれの人の強み（多様性）を活かすことで、 QAチームとしての可能性が増える • 何をやるか ◦ 人員計画を立てる（どんな人が、いつまでに、何人欲しいか） ◦ 採用媒体の決定 ◦ 採用プロセスの決定 ◦ 募集要項作成 ◦ カジュアル面談の準備 ◦ 面接の準備 ◦ オファー面談の準備 ◦ その他（広報活動など）
27. 実際に行った活動 • 人員計画を立てる（どんな人が、いつまでに、何人欲しいか） ◦ 開発者の人員計画、自分が活動した工数の実績、今後予定する活動から算出する ◦ 社員採用だけでなく業務委託の選択肢も検討 • 採用媒体の決定 ◦ QAエンジニアが採用しやすい媒体は何かを検討 • 採用プロセスの決定 ◦ 一次面接、二次面接以降で何を確認するか、役割を決定 • 募集要項作成 ◦ 今後予定する活動から必須スキル、歓迎スキルを決定
28. 実際に行った活動 • カジュアル面談の準備 ◦ QAエンジニア向けの訴求ポイントは何かを洗い出し ◦ 会社の文化、プロダクト、開発チーム、業務のことを魅力的に説明できるように練習 • 面接の準備 ◦ 会社の文化、評価制度、想定する業務内容に合わせた評価項目を作成 ◦ 各評価項目を判定するための質問を作成 • オファー面談の準備 ◦ 応募者が結果に対して納得感を持ち、弊社が魅力的と感じてもらえるメッセージを準備 • その他（広報活動など） ◦ テックブログの記事を作成予定
29. 失敗したこと
30. 失敗したこと • 最初に受け身になる ◦ 周りの人はQAエンジニアに詳しくなかったので、 QAエンジニアに依頼すべき内容、参加すべき会 議、伝えれば助けになる情報がわかっていなかった ▪ 自分からどのような依頼や情報が欲しいかを発信する、他の人のスケジュールを見にいって 会議を把握するなど、自分か積極的に必要な情報を取りに行く姿勢が大事 • 資料を鵜呑みにする ◦ 開発手順が詳細に記載されていたので、その内容を信用して詳細を想像で補完してしまった。しか し、実際は資料に記載のない手順もあり、後で課題のある手順が見つかった ▪ 実際現場で活動しているメンバーに詳細にヒアリングする姿勢が大事 • 最初にヒアリングする人の範囲を狭くする ◦ 工数削減のためヒアリングする人を限定したため、一部の人が認識する課題を見落とした ▪ 様々な職種、様々な立場の人に対して幅広くヒアリングした方が良い
31. まとめ
32. 私が１人目のQAエンジニアにとって大事だと考える活動 • 最初に自分がどのような人で、何をして欲しいかを積極的に伝える • 最初は積極的に幅広い情報を収集していく • 協力を求める人に対して課題を正しく説明し、共通認識を持ってもらう • 費用対効果を考えて課題の優先順位を決める • 最初は少ないコストで短期的に成果を出す、成果を見える化する • 長期的なビジョンを持ち、成果を出しながら徐々に成長していく ◦ 施策の影響を受ける人が許容できる速度で成長していく • QAチームの仲間を戦略的に増やす
33. 私が活動内容を決める上で参考にさせていただいたもの • QA組織立ち上げ奮闘記〜入社1年でできたこと〜 ◦ https://note.com/morita_masami/n/ncb440f2b5b29 • 20年の歴史があるシステムにどう切り込む？出前館プロジェクトにおけるLINE QA チームの取り組み ◦ https://logmi.jp/tech/articles/324147 • 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話 （3D版） ◦ https://www.slideshare.net/YasuharuNishi/quality-management-funnel-3d-how-to-organize-qar elated-roles-and-specialties