国内外で伸び続ける「パラレル」。プロダクト品質を支えるQAチーム立上げの裏側初公開【後編】

2022年2月9日 11:50

こんにちは。QAエンジニアのmiisanです。

前編に引き続き、パラレルのQA体制立上げについてをご紹介します。
QA立上げにあたる課題に対して、何を打ち手としてQAチームが進化したのか？これからQAチームを立ち上げようとされている方や立ち上げた後の進め方に悩まれている方の参考になればと思っています。

取組内容の紹介

現状の理解

最初にパラレルのプロダクト開発の流れを俯瞰的に見ながら、良い点・改善できそうな点・不思議に思ったことを共有しつつ、振り返りをしながら現状を整理していきました。

振り返っていく中で課題が明確に見えていったので、その上で何から着手した方が良いかまとめ、タスク優先度を決めました。継続的な改善を組織として行っていくため、QAチームでは2週間に1回のペースで振り返り実施を続けていきました。

見えてきた課題として、下記のようなことがわかりました。以下の内容に優先順位をつけ、順々に改善していきました。

まずはQA内で改善できそうなことから進めていき、次第に「QAだけではやっていけないぞ？」と発展し、課題に合わせて他ユニットを必要に応じて巻き込みながら、双方の課題感をすり合わせしつつ柔軟に進めていきました。

課題の着手

整理された課題に対し、順番にフローやルールを導入していき、課題を解決していきました。

パラレルではドキュメント文化を大切にしており、過去のつまずきや問題点が分かりやすく整理されていたことから全体を通し、課題と優先度（ = お困り度）が明確になっていたため、どの課題とアクションが紐づいているのか分かりやすく、新しい基準やルールを導入していく過程で合意形成を取ることが非常にしやすかったと感じます。

新しい文化やフロー、ルールを導入するとき、場合によってはハレーションが起きるリスクもあります。ですが、チームで課題の洗い出しをしてから基準やルールの策定に進むことでそういったことを減らすこともできます。パラレルは、全員がプロダクト開発に集中する組織になっており、プロダクトをより良くしていく最短ルートを常に求めているので、チームでそこに納得したことで特にハレーションが起きなかったのだと思います。

あとは、同時に全てのことを解決しようとはしませんでした。優先度の高い、もしくはメンバーが重要だと考えた施策から着手し、改善策が浸透した後に次の取組みに進むといった感じで改善していきました。

QAについて知る

冒頭でも伝えた通り、パラレルではQAをPMと当時インターンだったメンバー（※現在はパラレルに入社しQA担当）で実施しており、私が関わり始めた当時、QA専門家が不在という状態でした。

なので、プロダクト開発におけるQAの関わり方や考え方などについても、少しずつインプットする機会を設けました。QA組織内製化のため、メンバーが中心となり、メンバーがQAの専門家として、主体的に判断し行動できるようになるためのサポートに徹しました。

プロダクト全体での取組み

最後に、プロダクト全体に影響し、開発チーム全体での協力が必要な取り組みを少しずつ提案していきました。

例えばQAフェーズよりもっと早くに不具合が見つかった方が、結果的にリリースを早めます。プロダクトチームとして早く良いものを届けるために、QAがテストにはいる前に、PMやデザイナーが機能やデザインチェックをするフローに取り組んでもらうことで、全体の品質向上につとめました。

トライアンドエラーで進みましたが、プロダクトを良くしたいという共通の思いから、新しい取り組みを実際に取り入れることができたのは、すごくいいチームだと思います。

変化

取り組みを実施した結果、チームやメンバーに変化がありました。

リリースサイクルの標準化

突発的にリリース／リバートを繰り返していた状況から、2週間を1タームとしたリリースを目指す形に変わり、プロダクト開発に重要な「継続的かつ効率的な価値の提供」に少し近づきました。

もちろん初めからうまくサイクルが回ったわけではありません。

アプリのサブミット日を最初に決めたがゆえに、結局QAがタイトになってしまったり、開発側がいつまでにQA依頼すべきか分からなくなったり新たな課題も発生しました。

ですが、新しく発生した課題は振り返り、改善していけばいい。
この習慣が根付いているので、今のパラレルでは新しい取り組みを続けていくことができます。リリースサイクル標準化に着手できたこと以上に、この習慣ができたことは大きな変化だと感じます。

リグレッションテストの効率化

パラレルのQAはリリースバージョンごとにチケットベースの単体QA（ = 機能QA）の実施後に、全体QAと呼ばれるリグレッションテストを実施しています。

ですが、バージョンアップに合わせてテストケースをうまく棚卸できていない点があったので、一度時間を作り、リグレッションテストの棚卸しと整理を行うことで、実施工数を半分にすることができました。

しかし、機能は常に増えていくため、今後もリグレッションテストの項目精査を続けていく必要があります。このサイクルをどのように回していくかについては検討しなければいけない新たな課題だと考えています。

コミュニケーション機会の増加

QAチームでの振り返りが習慣化された結果、開発組織全体に対する新たな改善点も見え、他ユニットとさらに協働するようになりました。
これにより、開発全体にQAが最適化されていくようになり、QAがよりプロダクト開発において重要な一部として取り込まれるようになってきていると思います。

不具合が気になる

最後にもっとも良い変化は、これまでは気になっていなかった障害などが気になり始めたという変化です。

多くのサービスで、優先度の低い問題や技術的課題を抱えた状態でプロダクトをリリースしているものです。同様にパラレルでも蓄積された課題があります。
ですが、問題を整理し始めたことで、これまで問題が問題として露呈していなかったところがあらわになったり、逆に綺麗に整っているところが増えてきたために、未整備の箇所が気になる状況になりました。

例えば以前から発生していたクラッシュの問題があったとしても、ほかの問題が減ってきたことで、問題として露呈するようになります。問題が減っていけばいくほど、残された課題に注視され、その結果、より高い品質やSLOを意識した開発を実現しようと考えるようになります。

いくつかの変化をあげてきましたが、小さな変化の連続でパラレルの品質保証は少しずつ変わりつつあります。

変化に寛容であり、より良いプロダクトを早くお客様に届けたいという気持ちを持って推進してきたからこそ、プロダクト開発における品質保証体制の一歩を踏み出せたと感じます。

番外編

現在パラレルのQAは、インターンから新卒でパラレル入社したメンバーが専任で担っています。これまでの立ち上げの取組を通して、彼女は誰よりもプロダクトに触れ、機能を知っている人となり、そして自ら学び、プロダクトの品質保証について責任を持ち成長しています。

”仕様通りに動いてはいるが、ユーザー目線で考えると違和感がある”などの意見をフィードバックしたり、現状の課題に意見を述べたり、これまで以上のバリューの発揮をしています。

QA経験のない人でも、プロダクトをよりよくしていきたいという思いがあれば、QAについて一緒に考えたり、知る機会があるので、もしもパラレルのプロダクトに興味を持った方はお気軽にお声がけください！

＝＝＝
パラレルはQA含め全職種積極採用しています！ご興味ある方はぜひご連絡ください。
■パラレル採用ページ
■お問合せ先：hr@parallelcorp.com　

この記事が気に入ったらサポートをしてみませんか？