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

品質コミュニティがつなぐ、QAチームと開発者の新たな可能性

kotatsu
July 03, 2023
1.7k

 品質コミュニティがつなぐ、QAチームと開発者の新たな可能性

kotatsu

July 03, 2023
Tweet

Transcript

  1. 2 2 ©2023 Loglass Inc. ログラスについて - 創業4年目のスタートアップ・ベン チャーです -

    「良い景気を作ろう。」をミッション に、経営管理クラウドサービスを 運営しています
  2. 4 4 ©2023 Loglass Inc. @qa_kotatsu 私について - 株式会社ログラスの一人目 QA

    - 元Javaエンジニア - QA歴3年ぐらい - 最近関西に引っ越しました
  3. 7 ©2023 Loglass Inc. ・実践アジャイルテスト輪読会 ・11月~2023年2月で開催 ・アジャイルテスト当たり前へ 時間軸 2022 2023

    6月 QA伝道師を結成 󰨻 スクラム開発Join QA基本概念の紹介 チームでの開発 各種プロセス改善 緊急品質 向上PJ発足 9月 PJ完了 10月 11月 品質コミュニティ構 想/運営開始 1月 状況に合わせて品質コミュニ ティのアジェンダ変更 4月 入社 現在 QA Mission Vision Value策定 所属チーム変更 輪読会開始 12月 二人目QA採用成功 オンボーディング スクラムチームでのエ ピックオーナー ・開発組織の弱点を補う話題を  定例内で取り扱うようにした
  4. 8 QA的な素地が全くなかった 入社直後の開発チームの状況 • 開発チームが3つに分かれていた • QAはプロパーもベンダーも 0人 • 開発組織内にQA知識がほぼ0

    ◦ QAってテストしてくれる人なの? ◦ テストってどうやってやるの? ◦ 前職でテストを行っていた開発者は数人いた ▪ しかし組織内展開などはできていなかった • 品質に対しての問題意識は持っていた
  5. 9 QAの基礎知識・概念の紹介 入社直後にやったこと • テストプロセス、W字モデル • シフトレフト • テスト設計の布教 •

    プロセスQA、プロダクトQA • ソフトウェアテストの 7原則 • アジャイルQA • プロセス整備 ◦ テストプロセス ◦ リリースプロセス ◦ 障害対応フロー ◦ 障害の定義の策定 • 開発チームにJoin ◦ 開発もしていく ◦ テスト設計をモブ作業等
  6. 10 そこで仲間を募った: QA伝道師 色々やりたいが、一人では限界がある • テストに関心があるエンジニアを集め、 QA伝 道師というチームを結成した ◦ テスト方法・Tipsを伝道師に伝えて各

    チームに伝搬してもらう • 各チームの品質担保に注力する人として機 能 • その他に、私の壁打ち相手になって貰った り、ヒアリングさせて貰ったり
  7. 11 2-3か月前に行った仕様変更が原因でした ある時、障害が頻発する事態に陥りました • 緊急事態宣言のような状況となり、機能開発が一時停止した • この問題を解決する為に、問題発生の頻度が高い箇所や主要機能についてのテストを行うことを 決定 ◦ その結果緊急品質向上

    PJが発足 • この事象を後から思い返すと、開発チームの意識が変わったターニングポイントだった • サービス運営において、品質が低下するとどういう事が起こるのか共通認識を持てた ◦ サービス運営において、品質は極めて重要な要素となりうる事 ◦ 最悪の場合、お客様も離れていく事
  8. 12 伝道師というより救急隊員 緊急品質向上PJに伝道師出動 • テストの設計 • テストの実装 • テストの実施 ◦

    これを伝道師と共に進めていった • 伝道師とQAが緊急品質向上PJの進捗確認 をするMTGを定例化 • PJが一段落し、伝道師活動は引き続き継続 して行っていった ◦ しかし私が伝道師をうまくワークさせる ことができずに悩んだ ◦ のちの社内品質コミュニティへ
  9. 15 ©2023 Loglass Inc. 時間軸 2022 6月 QA伝道師を結成 󰨻 スクラム開発Join

    QA基本概念の紹介 チームでの開発 各種プロセス改善 緊急品質 向上PJ発足 9月 PJ完了 10月 入社
  10. 16 ©2023 Loglass Inc. ・実践アジャイルテスト輪読会 ・11月~2023年2月で開催 ・アジャイルテスト当たり前へ 時間軸 2022 2023

    11月 品質コミュニティ構 想/運営開始 1月 状況に合わせて品質コミュニ ティのアジェンダ変更 4月 現在 QA Mission Vision Value策定 所属チーム変更 輪読会開始 12月 二人目QA採用成功 オンボーディング スクラムチームでのエ ピックオーナー ・開発組織の弱点を補う話題を  定例内で取り扱うようにした
  11. 17 所属チームでやっていること 紹介したQA知識の実践 • 所属している開発チームでシフトレフトを実践するべく、プランニングでテスト設計をするようにし た ◦ テスト設計の相談対応 ▪ ときにはモブでテスト設計も行う

    ▪ バグバッシュも導入 ◦ テスト設計のスキルアップのため、ソフトウェアテスト技法練習帳を解いてみる時間を試し に導入 • サブPdMという役割を持ち、機能リリースのためのロードマップ整理・プロジェクト管理のようなこ とを実施 • スクラムマスター的な動きも ◦ スクラムイベントの改善 ◦ プロダクトバックログアイテムをスプリントバックログアイテムへ分割する際の 分割方法について紹介
  12. 20 20 ©2023 Loglass Inc. • 頭の中では広義の品質について 漠然とイメージができていたが、 それらの関係性を説明すること ができないでいた

    • 相互に作用する複雑なリスクの 芽を摘みたい、リスクの芽はそれ ぞれ別の原因がある、それらの 因果関係図をざっくり書き出した ◦ QAとして、3つの品質(プロ ダクト、組織、事業)に取り 組んでいきたいと整理した • この3つの品質のうち、「テスト」に フォーカスをする会を コミュニティとして開催することに した 思想:初期構想
  13. 21 やること、やらないこと 品質コミュニティの会設計 やること • テーマ:広義での品質 • 参加者:PdM, 各チームのエンジニア代表 •

    週に1回、15分 ◦ 事前に話すことを議事録に記載する ◦ 1人2分程度で議事録の内容を発表し 合う ◦ ワイワイスレがあり、誰かが話している 間にSlackで同期コミュニケーション やらないこと • この会で何らかのNext Actionを出す ◦ 「後で話しましょう!」はアリ
  14. 22 22 ©2023 Loglass Inc. • 当初、この3つの品質のうち、「テ スト」にフォーカスをする会を品質 コミュニティとして切り出した想定 だった

    • でもコミュニティとして、事業・組 織的品質についての話題のほう が親和性が高かった ◦ 開発チーム同士のプラク ティスの共有の場 ◦ 共有の場として、なんらか を持ち帰ることができる やってみてわかったこと
  15. 23 広義の品質と、その関係性 思想:品質富士山 • 私が考えた独自概念 • 広義の品質の関係性をエンジニアに説明す るために作った図 ◦ 初期構想の手書きメモからの発展

    • 品質コミュニティは、この富士山の中のトピッ クであれば何でも取り扱う場にした この品質富士山は太陽(顧客の本当に望むサービ ス)に照らされて全貌が明らかになる
  16. 24 品質富士山だけでは目指すべき方向がわからないので、その部分を補完する 思想:QAのミッション・ビジョン・バリュー Mission:開発者と一緒にプロダクトという山を登るシェ ルパとなる not 門番 Vision:急拡大する組織でも良い開発文化を強化 /維持 できるようになる

    良いプロダクトは良い開発チームから Value:顧客志向、アウトカムファースト テストを作ろうと思ったらいくらでも作れるが、顧客のためになら ないことはやらない カバレッジを100%にするとかはナンセンスなのでやらない
  17. 26 品質コミュニティでの成果 やってみた結果 • 開発チームとQAは協力する前提で、最初から開発者を巻き込んでいた ◦ アジャイルQAの知識をインプットして、開発者と QAが協力するのが普通になった ◦ 一人目QAは協力者を最大限増やす事が大事だと思った

    • 品質コミュニティを通じて良い取り組みをシェアすることで、開発チーム同士が良いところを真似し 合うようになった ◦ 今まで業務上で開発チーム単位での接点がなかった ◦ 車輪の再発明の防止 ◦ Scrum of Scrum dailyのプラクティスを結果的に取り入れる事になった • 課題の共有もできるので、解決のきっかけを作る会にもなった • チームが細分化し課題認識・課題発見がしづらくなる中、発生している問題が可視化される場が できて拾いやすくなった ◦ 小さな問題はすぐ検知して解決できる
  18. 28 一年間の取組の成果 やってみた結果 • やはり開発チームに入って同じ時間を過ごし、同じタスクを行っていくと、 理論の提示だけでなく実践もできるし、状況に合わせて調整もできる ◦ 信頼関係も築きやすい ◦ 同じ方向を向いて走るということはコミュニティ形成においても重要

    • 品質は開発チームの責任範囲外で、外部のベンダーに頼って管理するものではない。 それよりも、品質は開発チーム内部に根ざしているべきで、それを実感として理解することが重要 であるという認識に至った ◦ 品質コミュニティでは実感として理解する良い場だった • QAはただテストを行う人、という一面的な認識から脱却した!
  19. 32