Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

エムスリーのQAチームが目指すもの

11/03のDevLove「あなたの知らないQAチーム、QAエンジニアの世界」で発表した内容になります

  • Login to see the comments

エムスリーのQAチームが目指すもの

  1. 1. エムスリーのQAチームが 目指すもの あなたの知らないQAチーム、QAエンジニアの世界 2020/11/03 エムスリー株式会社 城本 由希
  2. 2. 本日お話したいこと 「あなたの知らないQAチーム、QAエンジニアの世界」 ということで、エムスリーのQAチームの雰囲気や普段のしごとを知っ ていただけたらと思います 2
  3. 3. 本日お話したいこと 1. エムスリーのQAチームが何を目指しているか 2. どうやっているのか a. 会社の文化 b. チームの体制/人 c. 開発の仕方/具体例 3. これから伸ばしていきたいところ 3
  4. 4. 自己紹介 ● 名前:城本 由希 @yuki_shiro_823 ● 仕事:エムスリーのQAエンジニア ● 出身:広島(カープファン)    大学時代の専攻は歴史でした ● 趣味:神社仏閣や城や古墳を訪れること    QA関係の勉強会によく出没してます 4
  5. 5. 前提:エムスリーとは何をやっている会社か? ● ミッション ○ インターネットを活用し、健康で楽しく長生きする人を一人で も増やし、不必要な医療コストを一円でも減らすこと 5
  6. 6. 前提:エムスリーとは何をやっている会社か? ● 医師の9割が登録する医療従事者向けサイト「m3.com」を中心 に以下のようなサービスを提供 ○ 製薬企業  :マーケティング支援や新薬開発支援など ○ 病院    :採用支援、電子カルテ、医療機器など ○ 医療従事者 :医療に関する情報の提供、開業・転職支援など ○ 一般消費者 :医療相談、医療系情報の提供など 6
  7. 7. エムスリーのQAチームが何を目指しているか 低コストで高品質の製品を創り、 高速リリースが可能な開発チームを創る 7
  8. 8. 「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? ● 盲目的にバグの削減を目指すのではなく、顧客利益の最大化を目指す ● 開発プロセスに上流から関わり、顧客が真に必要とする製品を提供する ● テストでバグを検出するだけではなく、バグを埋め込まない仕組みを作る ● 個人の作業の最適化を目指すのではなく、開発チーム全体の最適化を目 指す ● QAエンジニアとしての役割を越えて、開発チームの課題解決に全力を尽く す 8
  9. 9. 「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? 盲目的にバグの削減を目指すのではなく、顧客利益の最大化を目指 す ● 過去のNG例 以前はバグの検出数をKPIにしていた →テスト量が多く重箱の隅を突くような指摘が多い ● 是正結果 顧客にとって価値のあるテストを考える 9
  10. 10. 「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? 開発プロセスに上流から関わり、顧客が真に必要とする製品を提供 する ● NG例 最終ゲートキーパーとしてのQAを行い、出来上がったシステム に対する評価しかできない ● OK例 上流から仕様策定への意見を出し、すべての工程で顧客価値を 評価する 10
  11. 11. 「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? テストでバグを検出するだけではなく、バグを埋め込まない仕組みを 作る ● 過去のNG例 以前はバグ検出数をKPIにしていた →バグがないと評価が悪くなる ● 是正結果 バグを埋め込まない仕組みを作った方が品質も業務効率も上が るので、それを目指すべき 例:仕様レビューなどでなるべく事前にバグを取り除く 11
  12. 12. 「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? 個人の作業の最適化を目指すのではなく、開発チーム全体の最適化 を目指す ● 過去のNG例 テストケース作成数、実施数(作業量)をKPIとしていた時期が あったが、不要なテストを誘発してしまった ● 是正結果 本当は少ないテストで品質を保てる方が生産性が高いはず →作業量ではなく、チームのアウトプットの数(ひいては顧客の利 益)にフォーカスすべき 12
  13. 13. 「低コストで高品質の製品を創り、高速リリースが 可能な開発チームを創る」とは? QAエンジニアとしての役割を越えて、開発チームの課題解決に全力 を尽くす ● 過去のNG例 テストだけに注力して他の開発フェーズには手を出さない ● 是正結果 チームの課題解決に向けて積極的に動く 例:必要に応じて、ドキュメント整備や問い合わせ回答をQAエン ジニアが行う 13
  14. 14. どうやっているのか? ~前提:会社の文化~ ● フラットな組織 ○ 現場に裁量 ○ 誰でも施策の起案OK(雇用形態や職種の壁なし) 14
  15. 15. どうやっているのか? ~前提:会社の文化~ ● クライアント(仕事)に対する執着心 ○ 顧客の期待を絶えず上回る ● 社長意識 ○ 一人ひとりが経営者視点に立って主体的に行動 ○ 大きく考え、何でもありで課題を解決 ● 皆をプロフェッショナルとして尊重 ○ 相手を尊重しつつも率直に意見を言う ○ チームで協力して良い成果を出す 15
  16. 16. どうやっているのか ~チームの体制~ 16
  17. 17. どうやっているのか ~チームの体制~ ● QAチームは組織横断チーム ○ QAエンジニアは所属はQAチームで、普段の仕事は各事業チーム と一緒にやっている ● 各事業チームはプロダクトマネージャー、デザイナー、開発者、 QAエンジニア含めて10~20名程度 ○ 開発者とQAエンジニアの比率は10:3程度 17
  18. 18. どうやっているのか ~チームの体制~ ● 各事業チームごとに事業のフェーズが異なるため、求められる品 質の内容が変わる ○ 歴史が長く顧客がついていて、既存影響がないことを厳密に求めら れる事業 ○ 新規に立ち上げて、素早くリリースして市場からのフィードバックを もらいたい事業 ● 開発スタイルは各事業チームの裁量に委ねられる ○ スクラム、カンバン、WBSでの進捗管理 ○ 技術選定 18
  19. 19. 19 技術スタック
  20. 20. どうやっているのか ~QAチームのメンバーとアウトプット~ チームリーダー:窪田純士 ● Docpediaでの品質計画とQA活動 ● エムスリーのテスト自動化の 歴史とこれから 中塚由美子 ● エムスリーのQAメンバーが JaSST Review'20 に登壇しま す!! 20
  21. 21. どうやっているのか ~開発の仕方とQAエンジニアの役割~ 基本的な開発の流れ 21 フェーズ 開発者 QAエンジニア 1 施策の起案 工数見積、企画書レビュー、企画の狙い確認 2 仕様のレビュー 仕様、設計のレビュー 3 実装 実装、ユニットテスト実装 テスト計画/設計/実装 4 コードレビュー コードレビュー 5 システムテスト 非機能テスト テスト実施、テストマネジメント 6 リリース リリース作業 リリース手順、残タスクの確認 7 リリース後の作業 本番環境の動作確認/監視、ふりかえり
  22. 22. どうやっているのか ~一例:開発チームの一員として~ 「施策の起案」フェーズ ● 企画書を見て、ROI算出のためのテスト工数の見積もり ● 起案時点で仕様の考慮漏れなど言えることがあればコメント ○ 影響範囲が分かれば確認 ● 起案の狙いの確認(何のためのシステムか把握してテストしたい ので) 22
  23. 23. どうやっているのか ~一例:開発チームの一員として~ 「仕様のレビュー」フェーズ ● 仕様レビューに参加 ● プロダクトマネージャーや開発者に説明してもらい、不明点を質 問する ○ システム構成図やシーケンス図を描いてもらったり、その場で図を 描いたりする 23
  24. 24. どうやっているのか ~一例:開発チームの一員として~ 「実装」フェーズ ● ここは主に開発者が担当 ○ ユニットテストやAPIテストは開発者が担当 ● QAエンジニアは実装・コードレビューと並行してテスト計画・設計 を実施 ○ 計画中に出てきた不明点は都度開発者に質問 ○ 非機能系試験をどこまで実施するか相談 ○ 計画が出来上がった段階で関係者にレビューしてもらい認識をあわ せる 24
  25. 25. どうやっているのか ~一例:開発チームの一員として~ 「コードレビュー」フェーズ ● ここは主に開発者が担当 ● QAエンジニアは実装・コードレビューと並行してテスト計画・設計 を実施 ○ 特性に合わせてテスト技法を選択 ○ 条件の洗い出し等で不安がある箇所は開発者と打ち合わせて確認 ○ 設計を同じ事業チームのQAエンジニアに任せる場合は導入とレ ビューを実施 25
  26. 26. どうやっているのか ~一例:開発チームの一員として~ 「システムテスト」フェーズ ● 前のフェーズで作成したテスト設計を元に、テストケースを実装、 実施 ○ 自分でやることもテスターさんにやってもらうこともある ○ 非機能系のテストは開発者やセキュリティエンジニアに助けてもらう ことが多い ○ 探索的テストを取り入れることもある 26
  27. 27. どうやっているのか ~一例:開発チームの一員として~ 「リリース」フェーズ ● リリース申請の承認 ○ Gitlabでソースコードが見られるので疑問点があれば確認 ■ リリース対象と関係なさそうなファイルが対象に入ってないか ○ 今回のリリース対象外とするバグがあれば事前に合意を取る 27
  28. 28. どうやっているのか ~一例:開発チームの一員として~ 「リリース後の作業」フェーズ ● 一部の顧客問い合わせについて調査、仕様の回答など対応 ● リリースのふりかえりを実施 ● 本番障害発生時は再発防止策を関係者全員で考える 28
  29. 29. どうやっているのか ~一例:QAチームの一員として~ <課題感> 組織横断チームとはいえ、実際には担当事業のチームメンバと話し ている方が多い →QAエンジニアの間で、事例やグッドプラクティスの共有や、困り事 の相談をする場が少ない 29
  30. 30. どうやっているのか ~一例:QAチームの一員として~ <対応> 1. QAチーム勉強会を隔週で実施 a. お互いのスキルや相談しやすさがアップ b. 勉強会は「業務時間内に業務としてやってよし」とVPoEから許可を もらう (業務委託やアルバイトの方も参加しやすく!) ※VPoEの口癖は「やっちゃいましょう!」 c. 最近は「ソフトウェアテスト技法練習帳」を解いている 30
  31. 31. どうやっているのか ~一例:QAチームの一員として~ <対応> 2. 隔週で座談会実施 a. 課題ややりたいことの共有 b. お悩み相談 「XXで困ってるけどどうしてる?」 3. QAチーム定例、TechTalk(LT大会) a. 全体方針や影響の大きいバグの共有 b. グッドプラクティスの紹介 31
  32. 32. これから伸ばしていきたいところ 各事業チームによって事情が異なるので各チームに最適化されたプ ロセスを目指す ● 優れたテストの実施 ○ システム構成の理解、ドメイン知識、テスト技法やプラクティス等を 利用したテスト設計 ● スピードを落とさずに品質確保する ○ テスト内容(プロダクトごとの手厚さ)や作成するドキュメントなどの 最適化 ○ 自動テストの積極的検討 32
  33. 33. これから伸ばしていきたいところ ● QA(システムテスト以降)実施前の品質を上げる ○ 上流への積極関与:仕様書のレビュー、認識齟齬の防止、各テスト レベルでのテスト ○ チーム全員で品質を作り込む体制 ● 優れたユーザ体験の提供 ○ 上流・企画への積極関与:UI / UX を開発者、プロダクトマネー ジャー、デザイナーとともに良いプロセスで作り上げる 33
  34. 34. どんな人を新たに迎えたいか スキルがあるだけでなく、 より良い品質保証を目指し続ける情熱のある方 ● カルチャーフィット ● エムスリーで案件を自走して対応できる ● 品質保証の何かしらのスペシャリストである ● (将来的に)組織レベルでの品質保証体制の構築・改善ができる 参考:QAエンジニア採用のために、ペルソナを作成してみたお話 34
  35. 35. We're Hiring! QAエンジニア・SET募集中! https://jobs.m3.com/engineer/ 35
  36. 36. ご清聴ありがとうございました 36

×