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

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

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

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

yuki-shiromoto

May 20, 2021
Tweet

More Decks by yuki-shiromoto

Other Decks in Technology

Transcript

  1. Contents 1. 前提 a. 会社・チームの文化、QAチームの体制 2. シフトレフトの取り組み a. もともと文化としてもっていたもの 3.

    シフトライトの取り組み a. メンバーの声から課題を見つけて対処してみたこと b. チームの取り組みとして用意しているもの 4. その他の取り組み a. チームの垣根を超えて協業や改善が生まれるチャンスを創っているもの 5
  2. 前提:エムスリーとは何をやっている会社か? • ミッション ◦ インターネットを活用し、健康で楽しく長生きする人を一人でも増やし、不必要な医療コスト を一円でも減らすこと • 医師の9割が登録する医療従事者向けサイト「m3.com」を中心に以下のよ うなサービスを提供 ◦

    製薬企業  :マーケティング支援や新薬開発支援など ◦ 病院    :採用支援、電子カルテ、医療機器など ◦ 医療従事者 :医療に関する情報の提供、開業・転職支援など ◦ 一般消費者 :医療相談、医療系情報の提供など 6
  3. 前提:会社の文化 • フラットな組織 ◦ 現場に裁量 ◦ 誰でも施策の起案OK(雇用形態や職種の壁なし) • 行動規範 ◦

    クライアント(仕事)に対する執着心 ▪ 顧客の期待を絶えず上回る ◦ 社長意識 ▪ 一人ひとりが経営者視点に立って主体的に行動 ▪ 大きく考え、何でもありで課題を解決 ◦ 皆をプロフェッショナルとして尊重 ▪ 相手を尊重しつつも率直に意見を言う ▪ チームで協力して良い成果を出す 7
  4. プロジェクトの進め方とQAエンジニアの役割 14 フェーズ QAエンジニア 1 施策の起案 工数見積、企画書レビュー、企画の狙い確認 2 仕様のレビュー 仕様、設計のレビュー

    3 実装 テスト計画/設計/実装 4 コードレビュー 5 システムテスト テスト実施、テストマネジメント 6 リリース リリース手順、残タスクの確認 7 リリース後の作業 本番環境の動作確認/監視、ふりかえり 8 運用 定例などで運用部門の状況確認 シフトレフトの アプローチ
  5. プロジェクトの進め方とQAエンジニアの役割 20 フェーズ QAエンジニア 1 施策の起案 工数見積、企画書レビュー、企画の狙い確認 2 仕様のレビュー 仕様、設計のレビュー

    3 実装 テスト計画/設計/実装 4 コードレビュー 5 システムテスト テスト実施、テストマネジメント 6 リリース リリース手順、残タスクの確認 7 リリース後の作業 本番環境の動作確認/監視、ふりかえり 8 運用 定例などで運用部門の状況確認 シフトライトの アプローチ
  6. 1. ビジネスサイドとの月次ヒヤリハット定例 a. ヒヤリハット事例の共有と、再発防止策の検討を実施 b. システムや運用の改善に繋がる話が出る 2. エンジニアサイドの週次MTG a. ビジネスサイドとも共有しているKPIの達成状況

    3. アンケート作成チームの週次MTG a. アンケート作成業務の状況や困りごと・要望を確認 4. Slackのアンケート作成の質問・相談チャンネルへの参加 a. 提供しているシステムを使ってアンケートを作成している人から質問・相談事項ががってくる デプロイ後のフィードバックを受けるために ビジネスサイド、運用サイドとやっていること 21
  7. 前提:作成依頼後に発生していること 27 チーム アンケート 作成チーム チーム BIR BIR以外の Unit 作成依頼

    作成依頼 • 1日に複数の依頼が来るので優先順の並び替え • 依頼に不備があった時の時の問い合わせ • 作成内容に不明点・疑問があった時の問い合わせ (すぐには返答がこないので次の案件へのスイッチ) • 作成完了後に追加修正依頼を受けた時の対応 etc  →納期に間に合うように仕上げるが、   タスクの流れは良くない
  8. 課題を感じていたこと(1) 課題 • 急ぎの依頼が多い ◦ 調整が発生し納期ギリギリになりがち ◦ 調整作業によるスイッチングコストの発生 • GUIで実現可能なことでも実装の依

    頼がある ◦ 実装コストがかかる ◦ システム側の機能で実現すれば納期も短 縮できる 28 課題からの仮説 • 依頼のプロセスが浸透していない? • システムでできること、実装依頼が 必要なことが分かりにくい?
  9. 課題を感じていたこと(2) 課題 • (仮説)作成の依頼をする側「自分の 担当案件を早くやってほしい」 vs • アンケート作成チーム「たくさんの依 頼をさばいているので急な依頼の対 応は難しい」

    29 課題からの仮説 • お互いの状況を説明した上でルー ルを整備すれば、トータルで対応ス ピードはあがるのでは? (クライアントへの納品スピードを上 げたいのはお互い一致)
  10. 直接アプローチできるところ 31 チーム アンケート 作成チーム チーム BIR BIR以外の Unit アンケート作成チームの一部はQAに属

    しており、直接アプローチが取れる。定 例にも出ておりアプローチしやすい。 同じUnitに属しているので直接アプロー チできる
  11. 直接アプローチできるチームとの取り組み アンケート作成チーム、BIRのビジネスサイドと進めたこと • マニュアルの整備 ◦ アンケート作成チームに依頼を出すまでにやっておくべきこと ◦ 今まで質問が多かったところは、キャプチャを増やしたり、FAQに追加する ◦ 機能として用意されていてGUIでできること、

    アンケート作成チームに依頼が必要なことのリスト化 • ルールの整備 ◦ 依頼を受け取ってから渡せるまでのリードタイムより短い期間を指定する場合は、Unitの トップの許可が必要、とさせてもらった • トレーニングの整備 ◦ アンケート作成時にシステム上で実施する必要があることのトレーニングを作成 33
  12. 課題からアプローチしてみた結果(1) 課題 • 急ぎの依頼が多い ◦ 調整が発生し納期ギリギリになりがち ◦ 調整作業によるスイッチングコストの発生 • システムの機能でできることでも実

    装の依頼がある ◦ 実装コストがかかる ◦ システム側の機能で実現すれば納期も短 縮できる 35 結果 • ルールに則っていない依頼は納期 調整を依頼しやすくなり、スイッチン グコストは減った • 完全になくすことはできないが、事前 に質問が来るなど、減る傾向にある
  13. 課題からアプローチしてみた結果(2) 課題 • (仮説)作成の依頼をする側「自分の 担当案件を早くやってほしい」 vs • アンケート作成チーム「たくさんの依 頼をさばいているので急な依頼の対 応は難しい」

    36 結果 • (再掲)お互いの状況を説明した上で ルールを整備すれば、トータルで対 応スピードはあがるのでは? (クライアントへの納品スピードを上 げたいのはお互い一致) Unitの内外でトレーニングを受けてもら えたり、ルールに沿った運用をしてもら え、協力できた
  14. メンバーからの声、取り組みの結果 メンバーからの声 • 急ぎ依頼への調整をかける頻度が減ってスイッチングコストが減った ◦ メインの業務であるアンケート作成にまとまった時間をとりやすくなった • マニュアル整備によって楽になった ◦ 使い方の質問が来た場合も、以前は質問ごとに使い方を書いていたが、整備後はマニュアルの該

    当箇所のURLを案内すればよくなった ◦ Slackの質問・相談チャンネルを見て、質問が多いものはマニュアルのFAQに追加 取り組みの結果 • メンバーの声から改善のきっかけを拾い、QA主体でアプローチしてみた →他のUnitも含むタスクのフローを効率化しスピードアップできた 37
  15. 効果を検討してリクエストへの対応を実施 • 対応前に効果を見積もってOKなら改善対応の実装に入る ◦ その苦労、面倒が発生する頻度は? ◦ 対応するコストは?(実装だけでなくレビュー、テストのコストも) ◦ 対応したら結果としてどのくらい助かりそう? •

    結果 ◦ より効果の高い改善対応にリソースを割けるようになった →改善対応の実装に入る前に効果の見積もりを必ず行うようになった (改善のリクエストを上げた人が忘れていても、定例などで誰かから「やった?」と声掛けが ある) 41
  16. Shuffle Tea Time • 月一度開催されるオンラインTea Time ◦ Shuffle Tea Time用のSlackチャンネルがある

    ◦ 月一度ランダムでチャンネル参加者が4人1組のチームに振り分けられる ◦ そのチーム内で適宜時間を設定し、30分自由に話す ◦ 出社していた時期はランチに行っていた • ビジネスサイドからエンジニアまで色々な人が参加しており、 協業のヒントや、システムに対するリクエストが聞けたりする ◦ テーマは自由なので趣味の話で盛り上がることもある 47
  17. まとめ・本日お話したこと • DevOpsには色んな面がありますが、ユーザーに価値を届けるのを加速する ために、協業という面で取り組んだことをメインでお話ししました ◦ シフトレフト ▪ 現段階では起案段階から入ったり仕様レビューを行うW字モデル的な入り方 ▪ QAも上流から入り、疑問や改善を投げかけると聞いてくれる文化がある

    ◦ シフトライト ▪ メンバーの声から運用上の課題を見つけ、Unitの内外に協力をもらいデリバリーを加速 する ▪ メンバーから上がったリクエストに対して効果を検討して対応してもらう • 「テスト以外のQA活動ってどんなことをしているのか?」という声をいただくこ とも増えたので、そこへのヒントになれば幸いです 48