3年がかりのQA組織立ち上げ / 3 years of work to set up a QA organization

by Yuichi Tsunematsu

Slide 1

Slide 1 text

3年がかりのQA組織立ち上げ  Retty株式会社  常松祐一  2022/5/21 

Slide 2

Slide 2 text

自己紹介  顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースする開発体制のあり方を模索しています。常松祐一 (つねまつゆういち)   ● Engineering Manager   ● Software Engineering Coach   ● Agile Development    SNSアカウント  ● tunepolo :   ● tune :   https://user.retty.me/3946697/

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

3年前はどんな状態だったの?  confidential confidential 2019年11月15日第14回Ques 「Agile Testの今」

Slide 5

Slide 5 text

QA組織を立ち上げたいと思ったのだけれど…  (2019年秋) 

Slide 6

Slide 6 text

当時の状況と課題感  confidential ● スクラムの導入が進み、開発プロセスは改善傾向↑  ● 一方でQAは課題が多い  ○ 企画担当が検証項目を考え、手動でチェックする  ○ 社内で仕様が把握できていない  ○ QAを改善していく専任・専門家がいない  ● 自社にあったアジャイルなQA体制・組織を実現したい  ↑今思うとふわふわした課題感・・・  confidential Photo by Kind and Curious on Unsplash

Slide 7

Slide 7 text

“スーパーアジャイルコーチ” 藤原さんに相談  confidential confidential ←当時送ったメール現在もQA面の相談を壁打ちさせていただいております 󰢜 https://daipresents.com/service/

Slide 8

Slide 8 text

藤原さんと整理した当時の課題 

Slide 9

Slide 9 text

1. 開発プロセスが上手くまわらない  企画がHowを考える  ↓  なんでも作る / 捨てられない  ↓  レガシーが積み重なる  ↓  施策開発が遅くなる

Slide 10

Slide 10 text

2. レガシーが積み重なる  システムが古い  ↓  負債が多い  ↓  暫定対応が続く  ↓  レガシーが積み重なる

Slide 11

Slide 11 text

3. 施策開発が遅くなる  仕様が無い  ↓  バグが入り込む  ↓  テスト項目を増やす  ↓  施策開発が遅くなる

Slide 12

Slide 12 text

3つの課題があり、スクラム導入で手が打てていたのは1のみ  1. 開発プロセスが  うまくまわらない  2. レガシーが積み重なる  3. 施策開発が遅くなる 

Slide 13

Slide 13 text

藤原さんと話して気付かされたこと  confidential ● QA組織があれば課題は解決するのか?  ○ QA組織を作ると、QA組織が門番化しないか?  ○ QA組織が無くてもリリース前のテストができているのであればそれはそれで良いこと  ● 「価値開発できていない」という真の課題に対して適切な手が打ててなかった  confidential Photo by Masaaki Komori on Unsplash

Slide 14

Slide 14 text

QAプロセスの整備その1  (2019年冬〜2021年春) 

Slide 15

Slide 15 text

confidential confidential Photo by Leonie Vuilleumier on Unsplash 良い点を再認識し、課題に適した手を打つ  ● 【課題と思っていたもの】企画担当が検証項目を考えている  ○ ✖ 検証項目はQA担当が考えてチェックするべき  ○ ○ 企画担当が考えることで仕様の矛盾に目が向く。    ● 【課題と思っていたもの】専門のQA組織・チームが無い  ○ ✖ QA組織・チームを立ち上げよう  ○ ○ 組織全体でQAをやっていく気概・機運がある。 

Slide 16

Slide 16 text

2. レガシーが積み重なる  → レガシーコードの削除を進める  confidential ● 定期的・積極的に削除していく仕組みを設けた。  confidential

Slide 17

Slide 17 text

社内Confluenceに検証観点を集めたページを設けた。 ● 気がつくたびに追記 ● 吐き出し・書き出しを優先し、後から整理 confidential 3. 施策開発が遅くなる  → サービス理解を蓄積・深める機会を増やす(1) 

Slide 18

Slide 18 text

3. 施策開発が遅くなる  → サービス理解を蓄積・深める機会を増やす(2)  confidential ● 実装着手前に「検証項目の準備・レビューを義務化」  ○ 企画担当・開発者双方が仕様のおかしな点や抜け漏れ、異常系を考えるきっかけができた。  ○ レビューにより検証項目のレベルが底上げされた。  confidential

Slide 19

Slide 19 text

複雑な箇所について、有識者を集め、時間をかけて整理。 ※ちなみに左記は「新宿 x イタリアン」のようなお店をリスト表示するページの仕様 confidential 3. 施策開発が遅くなる  → サービス理解の蓄積・深める機会を増やす(3) 

Slide 20

Slide 20 text

課題に適した打ち手のまとめ  confidential 2. レガシーが積み重なる  →レガシーコードの削除を進める    3. 施策開発が遅くなる  →サービス理解を蓄積・深める機会を増やす  ○ 社内Confluenceに検証観点を集めたページを設けた。  ○ 開発着手前に検証項目の準備・レビューを義務化  ○ 複雑な箇所について、有識者を集め、時間をかけて整理。  confidential

Slide 21

Slide 21 text

confidential confidential Photo by Benjamin Davies on Unsplash 打ち手の結果はどうなった?  ● QA組織は発足せず、QAに携わるメンバーも変わりなかったが、大きな障害は減り、発生数そのものも減少傾向に転じた。  ● 2020年春からはコロナ禍となり、変化が激しい状況となったが、障害対応工数を抑え価値開発に注力できる余力が作れるようになった。 

Slide 22

Slide 22 text

技術プラクティスによるサービス品質改善事例 

Slide 23

Slide 23 text

テスト自動化SaaS mablの導入  confidential confidential 導入しての学び ● 継続的にテストを実施するとバグが見つかる ● 自動テストは手動テストの置き換えではない

Slide 24

Slide 24 text

重めの技術負債の返却  confidential ● AWS RDSからAuroraへの移行 & オートスケーリング  ● ページキャッシュ機構を独自のものからFastlyに置き換え  ● Signal Sciences社のWeb Application Firewall導入  ● DB負荷の高い処理をマイクロサービスに切り出し  ・・・など  confidential 仕様の理解や課題感が企画・開発間で揃うようになり、改善時の効果に目が向くようになって、負債返却のための工数が捻出しやすくなった・・・という側面もある

Slide 25

Slide 25 text

早い段階での結合とテスト  confidential ● ビッグバンリリースせず、毎日のリリースで少しずつ機能を入れていく。  confidential

Slide 26

Slide 26 text

QAに対する温度感の変化  (2021年秋頃) 

Slide 27

Slide 27 text

新たな課題感  confidential ● 「発生率」から「発生件数」へ  ○ toCメディアはエラー率を見ていることが多かった。  ○ ネット予約やテイクアウト注文などtoBの取り組みが増え、発生率は低くとも、件数そのものが問題となるものが増えた。  ● 「平均修復時間」から「早期発見・予防」へ  ○ すぐ直せることも大事だが、早期発見をしたい。  ○ そもそも障害が発生することを想定したプランBが必要なのかもしれない。  confidential Photo by Kind and Curious on Unsplash

Slide 28

Slide 28 text

チーム横串のQA組織が改めて必要  confidential QA担当が将来起こりうる障害の原因をバシッと言い当てられれば良いが、個人スキルに強く依存する。  企画・開発が基本的な障害・QAに煩わされる時間を減らし、価値提供に向き合う時間を捻出してあげたい。    門番ではなくサポート役  confidential Photo by Kind and Curious on Unsplash

Slide 29

Slide 29 text

QAプロセスの整備その2  (2022年〜現在) 

Slide 30

Slide 30 text

考えているQA組織の形  confidential confidential QA組織パターン - 構造ごとのメリットデメリットまとめより機能する形を試行錯誤し見つけてから組織を編成する予定。 2022年の末ぐらいを想定。

Slide 31

Slide 31 text

QA組織立ち上げの前準備 (1)  立ち上げの目的をまとめる  confidential confidential

Slide 32

Slide 32 text

QA組織立ち上げの前準備 (2)  メンバーが集まり、相談できる場づくり  confidential ● 「定例会議」ではなく「よもやま会」  ● 「定期報告」ではなく「困っている・気がついたこと」の吐き出し  ● 「個人戦」ではなく「チーム戦」  ● 社内の開発状況や、QA勉強会の参加報告もここで行う。  confidential

Slide 33

Slide 33 text

confidential ● mablのテスト追加・メンテナンス・開発者への教育  ● 検証項目のドキュメント更新・記載方法の簡略化検討  ● 仕様ドキュメントの整理など  ※ただしQAに関することを何でもやる・引き取るではなく、他チームに喜ばれることに絞る  confidential QA組織立ち上げの前準備 (3)  チームでやれることを増やしていく 

Slide 34

Slide 34 text

この先に興味がある方はぜひMeetyで  confidential confidential

Slide 35

Slide 35 text

まとめ 

Slide 36

Slide 36 text

まとめ  Photo by Hannah Busing on Unsplash ● (自社・自分に無いスキル・知見は頼る)  ● 組織・役割ありきでは無く、課題に根ざした手を打つ。  ● サービス・環境の変化で判断は変わりうる。    Rettyでは「組織として価値開発に向き合う時間が捻出できるよう」 QA組織の立ち上げ準備を進めています。 