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

スクラムチームが一体になるために行ったQAプロセス変革の道のり / QA process transformation

とうま
May 10, 2024
790

スクラムチームが一体になるために行ったQAプロセス変革の道のり / QA process transformation

とうま

May 10, 2024
Tweet

Transcript

  1. Chapter 1 まとめ QA • ウォーターフォール的なプロセス • 情報伝達や⼿戻りのコストが⾼い • レビュアーの役割を⾒直してテスト設計

    を⾏うように • 採⽤活動を再開するも苦戦 kintone開発全体 • 活気がなく暗い雰囲気 • 職能横断のコラボレーションが弱い? • チームの健全性に責任を持つ役割の⼈が 不在 QAがスクラムチームへ 対策については次章 26
  2. QAマニフェストの策定 QAマニフェストとはkintone QAみんなが⼤切にしている価値観を明⽂化したもの。策定したマニフェストを紹介。 品質⽂化を浸透させる ‧QAだけでは品質は保てない。 よって、チーム全員に協⼒して もらえるようにする ‧繰り返し⾏う操作は⾃動化を⾏う ‧⼈海戦術ではなく、効果的な テストを⾏う

    ‧開発プロセスの最後にまとめて QAがテストするだけでない ‧適切な段階でテストする 常に最適な⽅法を考える 最後の砦とならない kintone QAマニフェスト QAマニフェストを拠り所にすることで、 ⽬指すべき⽅向性を⾒失わないようにする 40
  3. 全体振り返りの改善 そこで⼼理的安全性やコラボレーションを促進させるために様々な取り組みを起こった。 Norm Kerthの最優先司令 “どんな道をたどったにせよ、当時の知識‧技術‧能⼒‧利⽤可能 なリソース‧状況の中で、みんなができる限り最⾼の仕事をした はずです。それを⼼から信じます。” 冒頭で全員に賛同してもらい、建設的に議論が進 むようにしている。 ⽇々の⼩さい成果や良かったと思える出来事を

    「やったーエリア」(※)に挙げて共有する (1分程度) ※とあるチームで挙がったTry、何か成功した ら「やったー!」と⾔おう ⼩さな成果を祝福する 代表者制 元々は関係者全員を集めているような状態だった。 チームや職能の代表者に参加してもらうことにし て、⼈数を絞った。 振り返りツール 元々はkintoneを使って振り返りを⾏っていたが miroに変更。 (kintoneを使う=Excelを使って振り返りをやるイメージに近いかも) 52
  4. その他の改善活動 全体振り返りが盛り上がらないのは1つの事象にすぎず、チームや組織全体のシステムを改善しなければ根本解決 には⾄らない。全体振り返りには限らない改善活動についての⼀例を紹介。 「kintoneをより良くする会」をスクラムマ スターを中⼼に企画。 kintone 開発全体 各スクラムチーム より良くする会とは、kintone開発に関わる⼈全員を 対象に、わいわいする会。

    チームを超えた親睦を深めることで、やっていき感を⾼ めることが⽬的。 コンテンツ︓トークセッション、相互理解、OST、親睦 会、etc • チームビルディング • 理想やゴールについての議論 • プロセス改善 • ファシリテーション • スクラム勉強会 などなど Chapter3にて具体例を紹介。 54
  5. Chapter 2 まとめ • スクラムチームに⼊る上での課題 • 課題解決のために拠り所が必要 • QAマニフェストを策定し、課題解決へ •

    スクラムチーム毎の柔軟な対応が可能に • 活気がなく暗い雰囲気 • ⼼理的安全性とコラボレーションの問題 • 全体振り返りやkintone開発全体の改善 • 結果、全体振り返りが活発に 様々なレイヤーで職能間でコラボレーションが促進 56 QA kintone開発全体
  6. 垣根の越境活動 DevとQAの垣根を越境するために、現在も様々な活動を⾏っている。そんな中、⾃分が所属す るスクラムチームが取り組んだ活動の⼀部を紹介。 マインドセットに関する 改善活動 プロセスに関する 改善活動 • チームビルディング •

    インセプションデッキ • ゴールへの意識を向ける • 理想と現実のギャップを知る • デイリースクラムの活⽤ • ⾃動テストの⾒直し • QAムキムキ化計画 • チーム毎の本番リリース また、マインドセットと構造(プロセス)についてはセットで考えることが重要だと考えている ので、それぞれに関する取り組みについて紹介。 60
  7. チームビルディング 半年に1回程度の頻度でチームビルディングを開催。他のスクラムチームでも似たような 頻度で開催している。スクラムマスターが中⼼に企画することが多い。 開催実績 主な⽬的 • 2023/01/19 @オンライン • 2023/08/17

    @⼤阪 • 2024/02/05 @福岡 • メンバー間の相互理解 • コミュニケーションの促進 • 理想や課題についての議論 • 親睦を深める 開催場所が毎回異なるのは、各メンバーの拠点が異なるというのもあるが、、、 ”⾮⽇常感”の中で同じ時間を共有するという体験も重要 64
  8. アジェンダ例 1⽇⽬ 14:00 – 16:00 偏愛マップ 16:00 – 17:30 ⻑期の振り返り

    18:00 - 懇親会 2⽇⽬ 09:00 – 10:00 買い出し 10:00 – 11:30 わがままカード 13:00 – 14:00 マシュマロ・チャレンジ 2023/08/17 @⼤阪 1⽇⽬ 14:00 – 14:10 チェックイン 14:10 – 15:10 ウソ・ホントゲーム 15:25 – 17:45 OST 18:00 – 20:00 懇親会 2⽇⽬ – 10:00 ザツダン 10:00 – 11:30 開発計画読み合わせ 13:00 – 15:00 システミックモデリングとシステム 思考による現状分析 2022/02/05 @福岡 65
  9. 「理想と現実を語る会」のアジェンダ どのようにこの会を進めたかを紹介。 STEP4 STEP3 STEP2 STEP1 アジャイルマニフェストの 原則の冒頭にある⼀節。 “顧客満⾜を最優先し、価 値のあるソフトウェアを早

    く継続的に提供します。” これを実現するのに理想的 なチームとは、どのような チームだろうか。 理想のチームと⽐較し、 我々のチームはどのよ うになっているだろう か。 理想と現状のギャップ を埋めるためにできる 施策には何があるだろ うか。 出した施策を深堀って、 具体的なアクションに つなげる。 理想の深堀り 現状の深堀り アクション出し アクションの深堀り 68
  10. 余談)GROWモデルをイメージして構成 理想の深堀り 現状の深堀り アクション出し アクションの深堀り GROWモデル Goal Reality Options Will

    ‧‧‧ ‧‧‧ ‧‧‧ ‧‧‧ ⽬標設定 現状把握 選択肢の検討 実⾏へのコミットメント 理想と現実を語る会 GROWモデルとは、コーチングの1つの⼿法。 Goalから考えることで⽅向性を⾒失わずに内省を深めることが可能な⼿法(個⼈的な解釈) 69
  11. 効果 それぞれの活動の効果について。 チームビルディング 理想と現実を語る会 みんなが考えている理想が知れた。そして、 ⽅向性はみんな同じだという気付きがあった。 さらに、具体的な課題に対してアクションも 実⾏できた。(他部署との連携がうまくいっ ていなかったので他部署とのコネクションの 機会を設けた)

    定量的に効果を⽰すことは難しいが、定性⾯ で⾔えば、⼀体感を⽣み出す効果はあったよ うに感じられる。 例えば、チーム内の雑談で当時の思い出話を すると、同じ仲間なんだなという実感がわい たりして、チームの⼀体感には⼀役買ってい るように思える。 70
  12. プロセスに関する改善活動 プロセスに関する改善活動を2つ紹介。 デイリースクラムの活⽤ ⾃動テストの改善 今までのE2Eの⾃動回帰試験では、全ての改修 に対して実装していくという⽅針で⾃動化を ⾏ってきた。 その結果、E2Eのテストケースが膨れ上がり 様々な弊害が起こっている。 そんな⾃動回帰試験に関する⽅針⾒直しと、

    QAムキムキ化について紹介。 デイリースクラムで、ただの進捗管理の場に なってしまうような傾向にあった。 しかしスクラムガイドにある通り、進捗を検 査し、必要に応じて適応させることが重要。 検査と適応を促すために⾏った、スプリント ゴールの確認と時間割の作成について紹介。 72
  13. デイリースクラムの活⽤ デイリースクラムでは、スプリントゴールと時間割の確認を⾏うことで検査と適応を促進 させた。 スプリントゴール の確認 • そもそもスプリントゴールがなかったため決めるところから始めた • ちなみにゴール設定が難しい際は「スプリントテーマ」という形に •

    スプリントゴールの進捗確認はファイブフィンガーで確認 • 各個⼈の意思を表明してもらうことで具体的な懸念が挙がるように 時間割 • DevとQAの各タスクを着⼿するタイミングを可視化。 • タスクの依存関係が可視化されたり、チーム全体として最適な順番 を考えられるようになったり透明性の向上や効率化にも役⽴った。 73
  14. 74

  15. ⾃動テストの改善 E2Eが肥⼤化するなどの問題があり、⾃動回帰試験の再整備をDevとQAで⾏っている。E2EはQAがテスト 設計しDevに実装してもらうという流れだったが、⼀緒に考えることで新たな知⾒を得られた。 1. 「登録」ボタンを押し、登録画⾯に遷移する 2. 登録画⾯でフィールドに値を設定する 3. 「保存」ボタンを押下する 4.

    詳細画⾯で値を確認する →2.で設定した値が表⽰されていること 確認したいのは3、4で、1、2はどのような⼿ 段でも構わない。 ※しかし、QAは⾃然⾔語以外の表現しかでき ないため、愚直な⼿順で記載している。 Devは愚直に1〜4をブラウザを介した実装を⾏っていたが、もしかすると1〜2については 別の軽量な⽅法で実装できたかもしれない。 QAが提⽰したテストケース QAの考え このような気づきは、⼀緒に活動を重ねなければ⾒えなかった改善点。 職種横断で共通の⽬的へ向けた活動が重要 75
  16. QAムキムキ化 • 1時間/週 • QA2名 + Dev(任意参加)によるモブ作業 • QAが⾃律してE2Eのテスト実装を可能に ちなみに、⾜並みを揃えた訳では無いが、他のスクラムチームも同様のム

    キムキ化計画が進⾏中... QAムキムキ化計画 QAが⾃動テストを実装できれば前述の⾃然⾔語以外で表現できるし、Devの負荷が⾼い場合にはQA が助けることもしやすくなる。QAも実装可能にしようというのがこのQAムキムキ化計画である! 76 ムキムキになればDevとのコラボレーションが促進されるはず!
  17. Chapter 3 まとめ 同じチームにしただけでは⼀体とはなれない。⼀体となるための様々な取り組みが重要。 マインドセットに関する改善活動 プロセスに関する改善活動 • チームビルディング • 理想と現実を語る会

    • デイリースクラムの活⽤ • スプリントゴールの確認 • 時間割の設定 • ⾃動テストの改善 • ⽅針⾒直し • QAムキムキ化計画 当然ではあるが、これだけやっておしまいではない より良いチームになるべく取り組み続けるのが重要 77