DevOps組織でQAが加速のために取り組んでみたこと

2021/05/20 Ques第16回の資料になります。

Transcript

1. DevOps組織でQAが加速のために
 取り組んでみたこと 2021/05/20　第16回Ques
 エムスリー株式会社　城本　由希
 1
2. 自己紹介 • 城本　由希　@yuki_shiro_823 • メインは担当しているWebリサーチのチームでWebやアプリのQAを実施。QAエン ジニアのスキル向上を目指してQAチーム内の勉強会を開いている • 広島出身のカープファン • 歴史が好きで神社仏閣や城跡をよく訪れていました。 2
3. 3 • DevOpsには色んな面がありますが、ユーザーに価値を届けるのを加速す るために、協業という面で取り組んだことをメインでお話しします • 「テスト以外のQA活動ってどんなことをしているのか？」という声をいただく ことも増えたので、そこへのヒントになれば幸いです 今日お話すること
4. 今日のお話でターゲットにしているところ 4 引用元：https://danashby.co.uk/2016/10/19/continuous-testing-in-devops/
5. Contents 1. 前提 a. 会社・チームの文化、QAチームの体制 2. シフトレフトの取り組み a. もともと文化としてもっていたもの 3. シフトライトの取り組み a. メンバーの声から課題を見つけて対処してみたこと b. チームの取り組みとして用意しているもの 4. その他の取り組み a. チームの垣根を超えて協業や改善が生まれるチャンスを創っているもの 5
6. 前提：エムスリーとは何をやっている会社か？ • ミッション ◦ インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コスト を一円でも減らすこと • 医師の9割が登録する医療従事者向けサイト「m3.com」を中心に以下のよ うなサービスを提供 ◦ 製薬企業　　：マーケティング支援や新薬開発支援など ◦ 病院　　　　：採用支援、電子カルテ、医療機器など ◦ 医療従事者　：医療に関する情報の提供、開業・転職支援など ◦ 一般消費者　：医療相談、医療系情報の提供など 6
7. 前提：会社の文化 • フラットな組織 ◦ 現場に裁量 ◦ 誰でも施策の起案OK（雇用形態や職種の壁なし） • 行動規範 ◦ クライアント（仕事）に対する執着心 ▪ 顧客の期待を絶えず上回る ◦ 社長意識 ▪ 一人ひとりが経営者視点に立って主体的に行動 ▪ 大きく考え、何でもありで課題を解決 ◦ 皆をプロフェッショナルとして尊重 ▪ 相手を尊重しつつも率直に意見を言う ▪ チームで協力して良い成果を出す 7
8. 前提：エムスリーQAチームのミッション 低コストで高品質の製品を創り、 高速リリースが可能な開発チームを創る 8 参考：エムスリーQAチームが目指すもの https://www.slideshare.net/shiromotoyuki/qa-239060402
9. 前提：QAチームの体制 • QAチームは組織横断チーム ◦ QAエンジニアは所属はQAチームで、普段の仕事は各事業チームと一緒にやっている • 各事業チームはプロダクトマネージャー、デザイナー、開発者、QAエンジニ ア含めて10～20名程度 9 所属 担当チーム
10. 前提：BIRとは BIR（ビジネスインテリジェンス＆リサーチ） 医療従事者の会員向けアンケート(国内最大の医師パネル)をベースに、製薬 会社へのマーケティング支援を提供する事業を行っています。 10
11. BIR 前提：所属Unitの構成 11 ビジネスサイド (各リサーチの種類ごとにチームがある) エンジニアサイド 開発 エンジニア QA エンジニア PM チーム チーム チーム チーム アンケート 作成チーム 自分はここ
12. ライフサイクルの上流での取り組み シフトレフトの 取り組み 12 もともと 文化として持っていたもの
13. シフトレフトとは 13 参考：https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol13.pdf ベリナビ2018年3月号　辰巳敬三 「ソフトウェアテストのニューノーマル　～テストの新たな常態・常識～」　 • 開発ライフサイクルの上流からテスト活動を開始すること（ウォーターフォー ルモデルだとW字モデル） • DevOpsの文脈だと、開発完了後に行われるテストを、もっと早い開発の途 中段階でかつ自動的に行うこと
14. プロジェクトの進め方とQAエンジニアの役割 14 フェーズ QAエンジニア 1 施策の起案 工数見積、企画書レビュー、企画の狙い確認 2 仕様のレビュー 仕様、設計のレビュー 3 実装 テスト計画／設計／実装 4 コードレビュー 5 システムテスト テスト実施、テストマネジメント 6 リリース リリース手順、残タスクの確認 7 リリース後の作業 本番環境の動作確認／監視、ふりかえり 8 運用 定例などで運用部門の状況確認 シフトレフトの アプローチ
15. 実際にやっていること(1) 「施策の起案」フェーズ • 企画書を見て、ROI算出のためのテスト工数の見積もり • 起案時点で仕様の考慮漏れなど言えることがあればコメント • 影響範囲が分かれば確認 • 起案の狙いの確認 （何のためのシステムか把握してテストしたいので） 15
16. 実際にやっていること(2) 「仕様のレビュー」フェーズ • 仕様レビューに参加 • プロダクトマネージャーや開発者に説明してもらい不明点を質問する • システム構成図やシーケンス図を描いてもらったり、その場で図を描いたり する 16
17. シフトレフトのまとめ • 現段階では起案段階から入ったり仕様レビューを行うW字モデル的な入り 方 ◦ DevOps文脈での「開発がひととおり完了した後に行われるテストを、もっと早い開発の途中 段階でかつ自動的に行う」シフトレフトはまだ課題 • QAも上流から入り、疑問や改善を投げかけると聞いてくれる文化がある ◦ 加速のための相談・提案はやりやすい 疑問や改善を投げかけると聞いてくれる文化がある、という土壌の上で、 チャレンジしてみたことをシフトライトの面からご紹介します 17
18. リリース済みのサービスの 運用フローに対する取り組み （主に社内のユーザへの対応） シフトライトの 取り組み 18 メンバーの声から 課題を見つけて対処してみたこと
19. シフトライトとは 19 • デプロイ後、本運用に入ってからも本番環境でテストを行うこと • 本スライドでは、要素技術としてやっていることと、ちょっと広めに捉えてデプ ロイ後にQAエンジニアがトライしてみたアプローチについて紹介する 参考：https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol13.pdf ベリナビ2018年3月号　辰巳敬三 「ソフトウェアテストのニューノーマル　～テストの新たな常態・常識～」　
20. プロジェクトの進め方とQAエンジニアの役割 20 フェーズ QAエンジニア 1 施策の起案 工数見積、企画書レビュー、企画の狙い確認 2 仕様のレビュー 仕様、設計のレビュー 3 実装 テスト計画／設計／実装 4 コードレビュー 5 システムテスト テスト実施、テストマネジメント 6 リリース リリース手順、残タスクの確認 7 リリース後の作業 本番環境の動作確認／監視、ふりかえり 8 運用 定例などで運用部門の状況確認 シフトライトの アプローチ
21. 1. ビジネスサイドとの月次ヒヤリハット定例 a. ヒヤリハット事例の共有と、再発防止策の検討を実施 b. システムや運用の改善に繋がる話が出る 2. エンジニアサイドの週次MTG a. ビジネスサイドとも共有しているKPIの達成状況 3. アンケート作成チームの週次MTG a. アンケート作成業務の状況や困りごと・要望を確認 4. Slackのアンケート作成の質問・相談チャンネルへの参加 a. 提供しているシステムを使ってアンケートを作成している人から質問・相談事項ががってくる デプロイ後のフィードバックを受けるために ビジネスサイド、運用サイドとやっていること 21
22. フィードバックから 運用上の課題を改善した事例 22
23. 前提：タスクの流れ 23 複雑な仕様のアンケートは、アンケー トを実装＆確認する専門チームがい る
24. 前提：アンケートシステム • リサーチに用いるアンケートシステムは内製している 参考：Reactを使って本気でアンケートシステムをつくった • 柔軟にアンケートを作成できるアンケートシステム ◦ 設問や選択肢などアンケートに必要なパーツはGUIで選択できる →エンジニアでなくてもアンケートの作成が可能 ◦ 複雑な制御が必要な場合は、JavaScriptを組み込むなどエンジニアが手を加えることで可 能にしている 24
25. 前提：アンケートシステム（画面例） 25 GitHubでデ モが公開され てます
26. 前提：アンケート作成関連の流れ詳細化 26 チーム アンケート 作成チーム チーム BIR BIR以外の Unit 複雑な仕様のアンケートは、 BIR内外の複数のチームから作 成の依頼が来る 作成依頼 作成依頼
27. 前提：作成依頼後に発生していること 27 チーム アンケート 作成チーム チーム BIR BIR以外の Unit 作成依頼 作成依頼 • 1日に複数の依頼が来るので優先順の並び替え • 依頼に不備があった時の時の問い合わせ • 作成内容に不明点・疑問があった時の問い合わせ (すぐには返答がこないので次の案件へのスイッチ) • 作成完了後に追加修正依頼を受けた時の対応　etc 　→納期に間に合うように仕上げるが、 　　タスクの流れは良くない
28. 課題を感じていたこと(1) 課題 • 急ぎの依頼が多い ◦ 調整が発生し納期ギリギリになりがち ◦ 調整作業によるスイッチングコストの発生 • GUIで実現可能なことでも実装の依 頼がある ◦ 実装コストがかかる ◦ システム側の機能で実現すれば納期も短 縮できる 28 課題からの仮説 • 依頼のプロセスが浸透していない？ • システムでできること、実装依頼が 必要なことが分かりにくい？
29. 課題を感じていたこと(2) 課題 • （仮説）作成の依頼をする側「自分の 担当案件を早くやってほしい」 vs • アンケート作成チーム「たくさんの依 頼をさばいているので急な依頼の対 応は難しい」 29 課題からの仮説 • お互いの状況を説明した上でルー ルを整備すれば、トータルで対応ス ピードはあがるのでは？ (クライアントへの納品スピードを上 げたいのはお互い一致)
30. 課題に着手する前に気をつけたいこと • 自分が直接アプローチ可能なところや、直接リクエストが聞こえてくるところ に局所対応しがち ◦ 交渉が不要なので楽ではあるが、全体の流れを見たときに返ってコストがかかるようになっ てないか？ ◦ 直接声がきこえてくるメンバーの不満だけに対応しようとしてないか？ ※自分の場合は、接する頻度は次の通り アンケート作成チーム＞BIRのビジネスサイド＞BIR外のビジネスサイド • チームやUnitをまたいで、全体のフローとしてどこを改善したらよいかを考え る 30
31. 直接アプローチできるところ 31 チーム アンケート 作成チーム チーム BIR BIR以外の Unit アンケート作成チームの一部はQAに属 しており、直接アプローチが取れる。定 例にも出ておりアプローチしやすい。 同じUnitに属しているので直接アプロー チできる
32. Unitをまたぐアプローチになるところ 32 チーム アンケート 作成チーム チーム BIR BIR以外の Unit 別Unitになるため、一度Unitのトップ同 士で話しを通してもらったほうがアプロー チしやすい
33. 直接アプローチできるチームとの取り組み アンケート作成チーム、BIRのビジネスサイドと進めたこと • マニュアルの整備 ◦ アンケート作成チームに依頼を出すまでにやっておくべきこと ◦ 今まで質問が多かったところは、キャプチャを増やしたり、FAQに追加する ◦ 機能として用意されていてGUIでできること、 アンケート作成チームに依頼が必要なことのリスト化 • ルールの整備 ◦ 依頼を受け取ってから渡せるまでのリードタイムより短い期間を指定する場合は、Unitの トップの許可が必要、とさせてもらった • トレーニングの整備 ◦ アンケート作成時にシステム上で実施する必要があることのトレーニングを作成 33
34. Unitをまたぐチームとの取り組み Unitのトップ同士で話を通してもらってから実施したこと • BIR外のアンケート関係者にトレーニングを受講してもらう ◦ 受講に依頼の時に「アンケート作成チームへの問い合わせのやり取りを減らせれば、納品 のスピードを上げられる」と相手へのメリットも伝える →トレーニング作成時点でのアンケート業務に関わるメンバーに受講してもらう ◦ トレーニングを録画して新規参画メンバーにも受けてもらえるようにする • ルールの周知 ◦ 整備したルールは、一度メールでUnitのトップから周知してもらった ◦ その後はSlackのチャンネルで定期botで忘れないよう周知している 34
35. 課題からアプローチしてみた結果(1) 課題 • 急ぎの依頼が多い ◦ 調整が発生し納期ギリギリになりがち ◦ 調整作業によるスイッチングコストの発生 • システムの機能でできることでも実 装の依頼がある ◦ 実装コストがかかる ◦ システム側の機能で実現すれば納期も短 縮できる 35 結果 • ルールに則っていない依頼は納期 調整を依頼しやすくなり、スイッチン グコストは減った • 完全になくすことはできないが、事前 に質問が来るなど、減る傾向にある
36. 課題からアプローチしてみた結果(2) 課題 • （仮説）作成の依頼をする側「自分の 担当案件を早くやってほしい」 vs • アンケート作成チーム「たくさんの依 頼をさばいているので急な依頼の対 応は難しい」 36 結果 • (再掲)お互いの状況を説明した上で ルールを整備すれば、トータルで対 応スピードはあがるのでは？ (クライアントへの納品スピードを上 げたいのはお互い一致) Unitの内外でトレーニングを受けてもら えたり、ルールに沿った運用をしてもら え、協力できた
37. メンバーからの声、取り組みの結果 メンバーからの声 • 急ぎ依頼への調整をかける頻度が減ってスイッチングコストが減った ◦ メインの業務であるアンケート作成にまとまった時間をとりやすくなった • マニュアル整備によって楽になった ◦ 使い方の質問が来た場合も、以前は質問ごとに使い方を書いていたが、整備後はマニュアルの該 当箇所のURLを案内すればよくなった ◦ Slackの質問・相談チャンネルを見て、質問が多いものはマニュアルのFAQに追加 取り組みの結果 • メンバーの声から改善のきっかけを拾い、QA主体でアプローチしてみた →他のUnitも含むタスクのフローを効率化しスピードアップできた 37
38. 課題からのアプローチと効果のまとめ 課題 • 急ぎの依頼が多い、システムの機能でできることでも実装の依頼がある • 依頼1件ごとに見ると依頼元と作成チームで対立構造が起きている アプローチ • マニュアル、ルールの整備や周知、トレーニングの提供 前年比で1件あたりの工数を約15%削減することができた デリバリーの加速に貢献できた！ 38
39. フィードバックから システム上の課題を改善した事例 39
40. アンケート作成チームからのシステム改善要望 • 一番システムを触っているチームなので、不便な点に気づきやすい ◦ システム改修も対応できるメンバーがいる • 対応前に気をつけたいこと 「苦労したことや、面倒だったことに引っ張られがち」 ◦ 苦労や面倒を解消するのは重要だが、それが発生する頻度はどの程度か？ ◦ 頻度を考えると実はシステムで対応するより、手動で対応するほうがコスパがいいので は？ 40
41. 効果を検討してリクエストへの対応を実施 • 対応前に効果を見積もってOKなら改善対応の実装に入る ◦ その苦労、面倒が発生する頻度は？ ◦ 対応するコストは？（実装だけでなくレビュー、テストのコストも） ◦ 対応したら結果としてどのくらい助かりそう？ • 結果 ◦ より効果の高い改善対応にリソースを割けるようになった →改善対応の実装に入る前に効果の見積もりを必ず行うようになった （改善のリクエストを上げた人が忘れていても、定例などで誰かから「やった？」と声掛けが ある） 41
42. シフトライトの 取り組み 42 チームの取り組みとして用意して いるもの リリース済みのサービスを 使って検証する取り組み
43. カナリア・リリース 『新旧2つのバージョンを同時に稼働させ、徐々に新バージョンを運用すること で新バージョンに問題がないことを確認しながら移行するデプロイの手法です。 手法の名称は「炭鉱のカナリア」に由来しています。』 43 参考：https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol13.pdf ベリナビ2018年3月号　辰巳敬三 「ソフトウェアテストのニューノーマル　～テストの新たな常態・常識～」　
44. ABテスト 『デザインが異なる2つのWebページを用意し、ユーザーの利用状況（クリック 率、導線など）の測定結果に基づいてWebページのデザインや動線の良さを評 価し最適化を図る手法です』 44 参考：https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol13.pdf ベリナビ2018年3月号　 「ソフトウェアテストのニューノーマル　～テストの新たな常態・常識～」　
45. その他の 取り組み 45 チームの垣根を超えて 協業や改善が生まれるチャンスを 創っているもの
46. 昔からあるシステムを学び直す会 • きっかけ ◦ 昔から存在していてほとんど手が入らないシステムは、QAも把握してない機能があった ◦ その機能に関するヒヤリハットがあったことから、昔からあるシステムをメインターゲットに、 画面を触りながら挙動を学び直す会を月一度開催することになった ◦ 当初、エンジニア側で行う予定だったが、ビジネスサイドにも声をかけて実施 • 成果 ◦ 当初の目的通り、把握してなかった機能について知れた ◦ プラスし、学び直す会を録画して新規参画メンバ用の教育資料としてストック 46
47. Shuffle Tea Time • 月一度開催されるオンラインTea Time ◦ Shuffle Tea Time用のSlackチャンネルがある ◦ 月一度ランダムでチャンネル参加者が4人1組のチームに振り分けられる ◦ そのチーム内で適宜時間を設定し、30分自由に話す ◦ 出社していた時期はランチに行っていた • ビジネスサイドからエンジニアまで色々な人が参加しており、 協業のヒントや、システムに対するリクエストが聞けたりする ◦ テーマは自由なので趣味の話で盛り上がることもある 47
48. まとめ・本日お話したこと • DevOpsには色んな面がありますが、ユーザーに価値を届けるのを加速する ために、協業という面で取り組んだことをメインでお話ししました ◦ シフトレフト ▪ 現段階では起案段階から入ったり仕様レビューを行うW字モデル的な入り方 ▪ QAも上流から入り、疑問や改善を投げかけると聞いてくれる文化がある ◦ シフトライト ▪ メンバーの声から運用上の課題を見つけ、Unitの内外に協力をもらいデリバリーを加速 する ▪ メンバーから上がったリクエストに対して効果を検討して対応してもらう • 「テスト以外のQA活動ってどんなことをしているのか？」という声をいただくこ とも増えたので、そこへのヒントになれば幸いです 48
49. We're Hiring! エンジニア募集中です！　詳しくはこちらで！ 49