Scrum Fest Niigata 2022の登壇資料です。 https://confengine.com/conferences/scrum-fest-niigata-2022/proposal/16401/3qa
3年がかりのQA組織立ち上げ Retty株式会社 常松祐一 2022/5/21
View Slide
自己紹介 顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方を模索しています。常松祐一 (つねまつ ゆういち) ● Engineering Manager ● Software Engineering Coach ● Agile Development SNSアカウント ● tunepolo : ● tune : https://user.retty.me/3946697/
3年前はどんな状態だったの? confidentialconfidential2019年11月15日 第14回Ques「Agile Testの今」
QA組織を立ち上げたいと思ったのだけれど… (2019年秋)
当時の状況と課題感 confidential● スクラムの導入が進み、開発プロセスは改善傾向↑ ● 一方でQAは課題が多い ○ 企画担当が検証項目を考え、手動でチェックする ○ 社内で仕様が把握できていない ○ QAを改善していく専任・専門家がいない ● 自社にあったアジャイルなQA体制・組織を実現したい ↑今思うとふわふわした課題感・・・ confidentialPhoto by Kind and Curious on Unsplash
“スーパーアジャイルコーチ” 藤原さんに相談 confidentialconfidential←当時送ったメール現在もQA面の相談を壁打ちさせていただいておりますhttps://daipresents.com/service/
藤原さんと整理した当時の課題
1. 開発プロセスが上手くまわらない 企画がHowを考える ↓ なんでも作る / 捨てられない ↓ レガシーが積み重なる ↓ 施策開発が遅くなる
2. レガシーが積み重なる システムが古い ↓ 負債が多い ↓ 暫定対応が続く ↓ レガシーが積み重なる
3. 施策開発が遅くなる 仕様が無い ↓ バグが入り込む ↓ テスト項目を増やす ↓ 施策開発が遅くなる
3つの課題があり、スクラム導入で手が打てていたのは1のみ 1. 開発プロセスが うまくまわらない 2. レガシーが積み重なる 3. 施策開発が遅くなる
藤原さんと話して気付かされたこと confidential● QA組織があれば課題は解決するのか? ○ QA組織を作ると、QA組織が門番化しないか? ○ QA組織が無くてもリリース前のテストができているのであればそれはそれで良いこと ● 「価値開発できていない」という真の課題に対して適切な手が打ててなかった confidentialPhoto by Masaaki Komori on Unsplash
QAプロセスの整備 その1 (2019年冬〜2021年春)
confidentialconfidentialPhoto by Leonie Vuilleumier on Unsplash良い点を再認識し、課題に適した手を打つ ● 【課題と思っていたもの】企画担当が検証項目を考えている ○ ✖ 検証項目はQA担当が考えてチェックするべき ○ ○ 企画担当が考えることで仕様の矛盾に目が向く。 ● 【課題と思っていたもの】専門のQA組織・チームが無い ○ ✖ QA組織・チームを立ち上げよう ○ ○ 組織全体でQAをやっていく気概・機運がある。
2. レガシーが積み重なる → レガシーコードの削除を進める confidential● 定期的・積極的に削除していく仕組みを設けた。 confidential
社内Confluenceに検証観点を集めたページを設けた。● 気がつくたびに追記● 吐き出し・書き出しを優先し、後から整理confidential3. 施策開発が遅くなる → サービス理解を蓄積・深める機会を増やす(1)
3. 施策開発が遅くなる → サービス理解を蓄積・深める機会を増やす(2) confidential● 実装着手前に「検証項目の準備・レビューを義務化」 ○ 企画担当・開発者双方が仕様のおかしな点や抜け漏れ、異常系を考えるきっかけができた。 ○ レビューにより検証項目のレベルが底上げされた。 confidential
複雑な箇所について、有識者を集め、時間をかけて整理。※ちなみに左記は「新宿 x イタリアン」のようなお店をリスト表示するページの仕様confidential3. 施策開発が遅くなる → サービス理解の蓄積・深める機会を増やす(3)
課題に適した打ち手のまとめ confidential2. レガシーが積み重なる →レガシーコードの削除を進める 3. 施策開発が遅くなる →サービス理解を蓄積・深める機会を増やす ○ 社内Confluenceに検証観点を集めたページを設けた。 ○ 開発着手前に検証項目の準備・レビューを義務化 ○ 複雑な箇所について、有識者を集め、時間をかけて整理。 confidential
confidentialconfidentialPhoto by Benjamin Davies on Unsplash打ち手の結果はどうなった? ● QA組織は発足せず、QAに携わるメンバーも変わりなかったが、大きな障害は減り、発生数そのものも減少傾向に転じた。 ● 2020年春からはコロナ禍となり、変化が激しい状況となったが、障害対応工数を抑え価値開発に注力できる余力が作れるようになった。
技術プラクティスによるサービス品質改善事例
テスト自動化SaaS mablの導入 confidentialconfidential導入しての学び● 継続的にテストを実施するとバグが見つかる● 自動テストは手動テストの置き換えではない
重めの技術負債の返却 confidential● AWS RDSからAuroraへの移行 & オートスケーリング ● ページキャッシュ機構を独自のものからFastlyに置き換え ● Signal Sciences社のWeb Application Firewall導入 ● DB負荷の高い処理をマイクロサービスに切り出し ・・・など confidential仕様の理解や課題感が企画・開発間で揃うようになり、改善時の効果に目が向くようになって、負債返却のための工数が捻出しやすくなった・・・という側面もある
早い段階での結合とテスト confidential● ビッグバンリリースせず、毎日のリリースで少しずつ機能を入れていく。 confidential
QAに対する温度感の変化 (2021年秋頃)
新たな課題感 confidential● 「発生率」から「発生件数」へ ○ toCメディアはエラー率を見ていることが多かった。 ○ ネット予約やテイクアウト注文などtoBの取り組みが増え、発生率は低くとも、件数そのものが問題となるものが増えた。 ● 「平均修復時間」から「早期発見・予防」へ ○ すぐ直せることも大事だが、早期発見をしたい。 ○ そもそも障害が発生することを想定したプランBが必要なのかもしれない。 confidentialPhoto by Kind and Curious on Unsplash
チーム横串のQA組織が改めて必要 confidentialQA担当が将来起こりうる障害の原因をバシッと言い当てられれば良いが、個人スキルに強く依存する。 企画・開発が基本的な障害・QAに煩わされる時間を減らし、価値提供に向き合う時間を捻出してあげたい。 門番ではなくサポート役 confidentialPhoto by Kind and Curious on Unsplash
QAプロセスの整備 その2 (2022年〜現在)
考えているQA組織の形 confidentialconfidentialQA組織パターン - 構造ごとのメリットデメリットまとめ より機能する形を試行錯誤し見つけてから組織を編成する予定。2022年の末ぐらいを想定。
QA組織立ち上げの前準備 (1) 立ち上げの目的をまとめる confidentialconfidential
QA組織立ち上げの前準備 (2) メンバーが集まり、相談できる場づくり confidential● 「定例会議」ではなく「よもやま会」 ● 「定期報告」ではなく「困っている・気がついたこと」の吐き出し ● 「個人戦」ではなく「チーム戦」 ● 社内の開発状況や、QA勉強会の参加報告もここで行う。 confidential
confidential● mablのテスト追加・メンテナンス・開発者への教育 ● 検証項目のドキュメント更新・記載方法の簡略化検討 ● 仕様ドキュメントの整理 など ※ただしQAに関することを何でもやる・引き取るではなく、他チームに喜ばれることに絞る confidentialQA組織立ち上げの前準備 (3) チームでやれることを増やしていく
この先に興味がある方はぜひMeetyで confidentialconfidential
まとめ
まとめ Photo by Hannah Busing on Unsplash● (自社・自分に無いスキル・知見は頼る) ● 組織・役割ありきでは無く、課題に根ざした手を打つ。 ● サービス・環境の変化で判断は変わりうる。 Rettyでは「組織として価値開発に向き合う時間が捻出できるよう」QA組織の立ち上げ準備を進めています。