Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

kawabeaver
February 12, 2022

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

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

kawabeaver

February 12, 2022
Tweet

More Decks by kawabeaver

Other Decks in Programming

Transcript

  1. なぜ会社全体の取り組みが必要か サービスのUXを構成する要素はプロダクトのUXだけではない モール型ECサイトの例 関係する人物 サービスのUXを悪化させる例 マーケティング お中元のGoogle広告をクリックしてもお中元専用のページがない セールス デモサイトがなくECサイト出店時のイメージが湧かない カスタマーサクセス

    ECサイト出店時のフォローが少なく出店までに時間がかかる プロダクト 使いづらい、不具合がある 社内オペレーター セールの期間設定にミスがあり、サイト表示より早くセールが終了 その他ステークホルダー 宛名にマンション名の記載がないので商品の誤配送が多い
  2. なぜ会社全体の取り組みが必要か サービスのUXはエンジニアリングの力でも改善することができる モール型ECサイトの例 関係する人物 サービスのUXを改善させる例 マーケティング コンシューマーに訴求しやすい専用ページを実装(お中元特集など) セールス ECサイト出店者が実際に触れるデモサイトを実装 カスタマーサクセス

    業務効率を改善する実装を行い、カスタマーサクセス用の工数を捻出 プロダクト 使いやすい、不具合が少ない 社内オペレーター セールの設定内容を動的にサイト表示して設定と表示の乖離を削減 その他ステークホルダー 入力フォームにマンション名を記載するよう注意書きを記載
  3. 会社全体の取り組みで何をやるか • 各オペレーションの品質を見える化 ◦ 各オペレーションのリードタイム、顧客満足度、行動ログなど • 各オペレーションをエンジニアリングの力で改善する体制の構築 ◦ 各オペレーションの課題を定期的にヒアリングする場 ◦

    エンジニアリング視点で各オペレーションを観察し改善点を探る ◦ 各オペレーション改善のための実装を定期的に実施( 10%ルールなど) • 啓蒙や品質文化の醸成ではなく品質向上が楽しくなる組織作り ◦ 品質が大事と思わない人はいない。品質向上が楽しくできれば品質は自然に向上する ▪ 品質が向上した事を見える化 ▪ 品質が向上して人の役に立った事を体験(感謝の声のフィードバックなど) ▪ 自分が品質向上に貢献できる事を体験(適切な小さい目標を少しずつ達成する)
  4. プロダクトの圧倒的なUX実現のために必要な要素 • 良いアイデア ◦ 顧客のニーズについて正しい理解 ◦ ニーズに対する適切な解決策 • 高品質(不具合がない) ◦

    欠陥を埋め込まない力 ◦ 欠陥を検出できる力 • スピード ◦ 必要な事だけやる ◦ 手戻りをなくす ◦ ボトルネックをなくす • 各要素共通で必要なものはドメイン知識やシステム理解
  5. 良いアイデアのために必要な取り組み • 顧客のニーズについて正しい理解 ◦ 取り組みの例 ▪ ユーザーの観察 ▪ ユーザーの声(ユーザーインタビュー、 NPS、サポートへの問い合わせなど)

    ▪ 行動ログの計測 ▪ カスタマージャーニーマップ、ペルソナ分析、ジョブストーリーなどの作成 • ニーズに対する適切な解決策 ◦ 取り組みの例 ▪ 多様なバックグラウンドの発想を取り入れる工夫(ブレストなど) ▪ 設計レビュー(仕様書のレビュー) • テスト技法等を用いた仕様検討漏れの検出 ▪ 動くプロダクトを直接触ったテスト(ユーザビリティ、ニーズに対する目的達成度) ▪ A/Bテストなど改修の結果ユーザーの行動が期待通りとなっているかをモニタリング
  6. 高品質のために必要な取り組み • 欠陥を埋め込まない力 ◦ 取り組みの例 ▪ 設計レビュー(仕様書のレビュー) ▪ 実装前のテスト設計 ▪

    アーキテクチャやコードの品質改善 ▪ 認識齟齬を減らす取り組み • 欠陥を検出できる力 ◦ 取り組みの例 ▪ 認識齟齬を減らす取り組み ▪ チームのテストスキル向上 • モブテスト設計やテスト設計レビュー、研修、テストプロセスの改善 ▪ テスト実行リソースの確保 ▪ 自動テスト(ユニットテスト、 APIテスト、E2Eテスト)
  7. スピードのために必要な取り組み • 必要な事だけやる ◦ 取り組みの例 ▪ ドキュメントや改修内容は ROIを考える(リッチにし過ぎない) ▪ MVPを意識(最初に作り過ぎない)

    • 手戻りをなくす ◦ 取り組みの例 ▪ 不具合の早期検知 ▪ ブランチ戦略、その他プロセス • ボトルネックをなくす ◦ 取り組みの例 ▪ 業務効率化(自動化、自動テストなど) ▪ 属人化防止(スキルアップ、ドキュメントなど)、早期のリソースの確保
  8. 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
  9. QAチームのメンバー:A社の事例 • 主にテストの専門家として活動 • SETもいるが、各開発チームできっちり役割分担はしていない ◦ CI/CD環境(Gitlab-CIやCircle-CIなど)は各開発チームでパイプライン等を構築可能 ◦ E2Eテスト自動化はテストエンジニアや開発者も行っている ◦

    SET職の業務内容は通常のソフトウェアエンジニアに必要なスキルセットと比較的類似 • プロセス改善は開発チーム全員で行う ◦ 開発チーム外の人がプロセスを考えるよりも現場の人がプロセスを考えた方が良い ▪ 現場の人は開発チームの事情に詳しいので、現場の人の方が良いアイデアが出る ◦ 各開発チームにプロセスを改善できるメンバーが 1人はいる
  10. 誰がテストを担当するか テスト担当者 メリット デメリット ・開発者がテストを担当 ・QAチームは開発者が良 いテストを行えるようにレ ビュー等でサポート ・属人化せずボトルネック等が発生し にくい

    ・ユニットテストも含めた各テストレベ ルのテスト品質が向上 ・テスト容易性が改善しやすい(開発 者がテストしにくさに気づく) ・開発者が品質に対する責任を持つ ・人をスケールしにくい  ・開発もテストもスキルが高い人は市 場に多くない  ・学習コストがかかる  ・すぐに成果を出せない ・開発者もQAチームもテス トを担当 ・上記とおおよそ同じ ・テスト担当をスケールしやすい ・役割分担のルール決めが必要 ・QAチームも開発系の知識が必要? ・QAチームがテストを担当 ・テスト担当をスケールしやすい ・開発者が開発に専念できる ・開発者が品質に対する責任を持たなく なりがち ・ユニットテストも考慮した自動テスト戦 略を立てにくい
  11. 誰がテストを担当するか 会社に応じて提案内容を変える • 1プロダクトに開発者が10名程度の企業 ◦ 開発者とQAチームの両方がテストを担当するタイプを提案 ◦ 1プロダクトに大量の修正が入るため自動テストが重要。組織のスケールのしやすさも加味してこ のタイプを提案。 •

    開発者1名が1プロダクトのPdM、開発、テストを兼務する企業 ◦ 開発者がテストを担当、 QAチームは開発者をサポートをするタイプを提案 ◦ 1名で全て実施するからこそコミュニケーションコストなしでリリース可能な体制なので、その体制の 良さを活かすような体制を目指す
  12. 短期的に成果を出しながら成長するために 改善を継続的に進められるようにするため、最初はわかりやすい成果を出しやすいもの を優先して実施 • 課題が強く認識されている ◦ ボトルネック ◦ 作業品質の課題が大きい •

    成功の難易度が低い ◦ 工数があまりかからない ◦ 作業内容が難しくない ◦ 新たな技術の習得が不要、または、少ない 難易度の高い改善は、QAエンジニアとして信頼を得てから、また、組織全体で改善の 成功体験を増やして改善の熱量を高めてから行う
  13. 現在考えている進め方 • 企業の課題に合わせて具体的な計画を書く、または、口頭で説明する ◦ 入社1ヶ月で◦◦、入社3ヶ月で◦◦、のようなプランを立てる • 以下は資料や口頭で説明した内容の例です ◦ テストが属人化しているので目指す品質の認識合わせやテストプロセスを標準化する ◦

    PdMのリソースをテスト実施から解放( QAチームが巻き取る) ◦ 自動テストを何となく実装しているので、自動テストの役割を明確化する ◦ スクラムを導入したばかりなので、スクラムに慣れるまでは学習の負荷を増やさないようにする。プ ロセスをあまり変えない施策を実施する ◦ 最初はプレイヤーとして動き、企業に最適な QAチームの体制を模索する(いきなり前職と同じ体制 などにしない)