初めてのプロダクトを担当したときのお話
はじめに
これはウイングアーク Agile and DevOps Stories のAdvent Calendar 2019、第九弾（2019年12月12日）の投稿です！
今回は4年半ほど前に新たなプロダクトのQA担当者として関わることになってから現在に至るまでに、どのように開発チームとの関係を構築していったかを振り返ってみようと思います。
新たなプロダクトのチーム状態
担当した新たなプロダクトは私が関わることになった時点で、すでに9年以上もバージョンアップをしながらリリースされ続けていた製品でした。
なぜ私がこのプロダクト関わることになったかというと、私がこのプロダクトの担当となる1つ前のバージョンにおける開発チームとQAチームの関係に疑問を感じたためです。
どのようなことに疑問を感じたかというと
- QAチームは上流工程では開発チームと一切関わらず、設計レビューや仕様書レビューなどに参加しない。
- QAチームは受入テストで実施する内容は開発チームには公開せず、抜き打ちテストのような内容に対してクリア条件を設けて、それをクリアするまで受入テストを何度も行い、クリアするまでQA検証フェーズに入らない。
- QA検証フェーズ中に深刻度の高い不具合が見つかるたびに、開発チームで既定のリグレッションテスト（手動テスト）を実施しなければならない。
- テスト自動化がほとんど行われていない。
これらによって、開発チーム、QAチームとも作業の手戻りが多発し、そのたびに手動でリグレッションテストを何度も何度も実施する状況に陥り、どちらのチームも疲弊していきました。
これを第三者として見ていた私としては、もっと別のやり方があるのでは？と感じたことが、このプロダクトに関わることになった理由です。
最優先事項
新たなプロダクトに携わるにあたって、初めて一緒に作業をする方々も多かったので、私に対して「名前は聞いたことあるけど君は何をやってくれるの？」「どのようなやり方をするの？」と思われていたと思います。
前のバージョンで開発チームとQAチームの関係が健全ではなく、必要以上に開発チームに負荷を与えていると感じていました。
そのため、「プロジェクトの最初から最後まで開発チームとQAチームが協力し合いながら製品リリースを達成する関係構築」を最優先事項としました。
具体的にどのようなことを行ったかというと
- 開発チームの進捗会議に参加し、QAチームでも手伝えそうな作業の話題があがった場合は積極的に手伝い、開発進捗の押し上げに貢献する。
- 設計レビュー、仕様レビューにQAチームが参加し、上流工程でフィードバックを行うことで、可能な限り作業の手戻りを減らす。
- QAチーム主導で開発チームと協力しながらテスト自動化を推し進め、定期的にリグレッションが発生していないことを確認する仕組みを構築する。手動でテストを行わなければならない範囲を減らし、手戻りが発生した場合の工数を低減させる。
- 受入テスト内容とクリア条件を公開し、達成するためにどのような状況となれば良いかを開発チームにフィードバックすることで、受入テストを見据えて開発チームが主体的に動けるようにする。
これらを行っていくことで少しずつ前のバージョンとはQAチームの振る舞いが違うことを開発チームに認識してもらえるようになり、大きな問題が発生することなく製品リリースを迎えることができました。
さらに前のバージョンと比較して、QAチームの人数が半分以下でこれらを達成することができました。これはテスト自動化と上流工程から製品開発にQAチームが携わることで、手戻りを減らし、これまで手動で行っていたテストを自動化できたことが大きかったと感じています。
さらなる改善
初めて担当したバージョンを無事リリースし、この時点で開発チームとはプロジェクト開始当初では感じられなかった信頼関係が構築できたと感じることができました。
その後も新たなバージョンの製品開発が何度もありましたが、そのたびに新たなプロセスやテスト自動化を開発チームと協力しながら構築していくことにチャレンジしていきました。
- 製品開発初期に2カ月毎の開発進捗目標と、製品品質を開発チームと合意し、開発進捗の遅れや製品品質が想定外の状態となっていないかを定期的に確認するプロセスを設ける。
- Excelクライアントをリコーディングすることになったが、自動テストが無かったので、自動テストを構築。各機能の振る舞いの仕様を資料にまとめて、リコーディングによるデグレードが発生していないことを確認するための自動テスト資産を作成する。
- Webクライアントも全く新しい画面を実装することになり、こちらも自動テストの構築を行うことになったが、自動テストを行うために要素にIDを埋め込んで実装してもらうように開発チームに依頼。
- ここまでの自動テストはE2Eテストが対象だったが、コンポーネントレベルや結合レベルのテスト自動化の仕組みを開発チーム主導で構築。
- 上流工程で開発チームとQAチームでどのようなテストを行っていけばいいか、それを行うにはどのような手段があるかを議論する場を設けるようになった。
これら以外にも開発チームに様々な提案や依頼をしてきました。もちろんすべてがすんなり受け入れてもらえたわけではありません。ただ、その度に意見やその理由についてなどをディスカッションすることでお互いに納得感を得ながら進めることができています。個人的にはこの「納得感を得ながら進めていくことが重要」だと感じています。やらされている感があるとモチベーションが湧きませんし、成果物の精度にも影響がありますからね。
開発チームとQAチームのアジャイルな関係
現在の開発チームとQAチームとの関係はいつでも協力し合える関係を構築できていると感じてます。これは開発チームとQAチームメンバーの新たなことへの挑戦に対する理解と行動力の賜物です！感謝感謝！
お客様へ価値ある製品をリリースするという共通の目的に対して、開発チーム、QAチームがそれぞれの立場から貢献できていると思います。
仕様書が無いからテストできない。計画時に無かったことだからやらない。それはこっちの作業ではなく、そちらの作業でしょ。などの会話はなく、様々な変化に対してどのように協力し合いながら対応していくかという会話ができています。
これはアジャイルソフトウェア開発宣言に沿っているなと感じています。
開発チームとこのような関係を構築できると、予期せぬ事象が発生しても柔軟に対応できるようになりますし、何より製品開発が楽しくなります！
QAチームはテストばかりをやっていた時期もありましたが、テスト以外でも製品開発の作業にチャレンジすることで、より製品開発に貢献できていると感じることができています。
もちろん楽しいことばかりではありませんが、開発チームとQAチームが1つのチームとして動けていることに価値があります。
今後
開発チームとQAチームの連携はかなり進んできました。
今後は営業チームやサポートチームとの連携をより密にしていくことで、これまでとは異なる視点で、より良い製品とするためのフィードバックを取り込んでいくことが目標です。
ScrumやXPのようなアジャイル開発手法を導入できていませんが、少しずつ自分たちが良いと思えることに部門を超えて協力してチャレンジしていくことも1つのアジャイルの形かなと思っています。
