hey Product Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

JaSST’21 Tokyo 「急成長プロダクトで私が体験した、QAチーム立ち上げの裏バナシ」後編

(このお話はJaSST’21 Tokyoにて発表させていただいた「急成長プロダクトで私が体験した、QAチーム立ち上げの裏バナシ」の内容を加筆したものです)

初めまして、STORES 決済 QAチームの金子です。 今回はSTORES 決済のQAチーム立ち上げ→今に至るまでの裏側を前編後編に分けてお話していきます。 後編は「組織急成長の中での課題と新たなテーマ自動化」です。

組織急成長の中での課題

QAチームの拡大と同じように開発チームもどんどん拡大していきました。 その中で、コミュニケーション上の課題も出てきてしまいました。

役割と責任を明文化していない

QAチームが立ち上がって最初の頃になるのですが、テストについて開発チームにヒアリングしたところテストはあまり好きではないと言われてしまったことがあります。 ここから更にコミュニケーションを繰り返したり今までの経緯を調べてみたりして課題を深ぼってみたところ、そもそもQAで守るべき品質の定義ができていなかったため、どこまで開発側で品質担保し、どこからQA側で担保するかが決まっておらず、責任の押し付けあいが発生してしまっていたことが根本的な原因だということがわかりました。

チェックリストで明文化を

ではどうやって解決したのか、結論から言うと役割と責任を明文化しました。 具体的には、プロジェクトが始まったらQAチーム内で工程やスケジュール、テストデータなどを列挙したチェックリストを作成し、それを開発チームに連携する事で共通認識を作り漏れがないようにしました。 それまでのテストの開始基準は開発で動作確認が終わったら始める、というようなふんわりしたものだったのですが、誰がみてもわかるような詳細なものにしました。

f:id:n1010n7zk:20210929110340p:plain

チーム間の責任分担を具体的に定義したことによって、互いにやるべきことも明確になり、開発チームのモチベーションも上がりました。QAチームにテストが回ってくる際の、本来なら開発時に潰しておくべき不具合がかなり減少した感覚がありました。また、副次的な効果として共通認識を持つことによってチーム間のコミュニケーションが円滑になりました。

少し話は脱線するのですが、今までのやり方をいきなり変えるのは結構難しいことです。しかし、このケースについてはすんなりいきました。 立ち上げ時期の課題でお話しした通り、QAの重要性や目的を啓蒙することで組織としての理解が進んでいたため、その辺りが効いていたものと思っています。

新たなテーマ「テスト自動化」

立ち上げ時期の課題や組織拡大での課題を通し、チームの中で改善・チーム間のコミュニケーションの改善を行ってきました。ですので次は今QAチームが取り組んでいる新たなテーマについてお話しします。

ずばり「テストの自動化」です。

現在QAチームでは、ようやくテスト自動化に着手し始めているところです。 とはいえ始めたばかりですので、残念ながら成果やナレッジをお伝えできる状態ではありません。 ですので今回は、自動化を始める目的の整理のところをお話します。

自動化の目的を整理する

テスト自動化を行うにあたって注意するべき点は、手段が目的になってしまいがちな部分です。 私たちも昔からやりたいと考えていたのですが、目的をどこにおくか定まらずなかなかできていませんでした。

自動化をすることで事業的な効果がなければ導入しても意味はないですし、ただ導入したい人の自己満足になってしまう危険性もあると思っていたからです。 自動化はテスト対象の向き不向きもあるります。そのため、ケースの作成やメンテナンスを考えると、単純な工数削減にはならないのではないかと考えています。

しかし今の弊社のような拡大する組織においては、教育コストの削減と言ったところで効果が出るのではと期待しており、現在はそれを目的にしています。 プロダクトの拡大に伴ってプロジェクトが増えることはあっても減ることはなく、それに対応するためにQAメンバーも同じく増えていきます。そうしてくると採用すればどうにかなる問題ではなくなっていきます。人が多くなれば教育コストもかかってきますし、その分ヒューマンエラーのリスクも増えてしまう。 このままいくと流石にマニュアルでやるのは限界が来るため、自動化が必要だと考えたわけです。

なぜ「今」自動化するのか

ではどうして「今」なのか。 これは誰か一人がやろうと言いただしたわけではなく、自然とその流れができていきました。 改善を続ける事でQAチームに余裕が生まれ、テストの実行だけではなく本来すべきことを考えるようになり、結果メンバーから自動化をやるべきだという声が上がるようになりました。それと同時に、コミュニケーション量が増え、課題を共通認識できるようになった開発チーム側からも自動化をするならこういうことができるという提案があり、自然と自動化が進められる状態になっていきました。

私たちのサービス 「STORES 決済」は単純なWebアプリケーションとは違い、アプリもあればハードウェアとの連携もあり自動化するには少し複雑です。果たして自動化することによる費用対効果が本当にあるのだろうか、という疑問と何度も向き合いながら丁寧に目的を詰めていきました。

今回のまとめ

  • チーム間の責任範囲を明確化することによって開発チーム全体のパフォーマンスが向上した
  • テスト自動化の取り組みでは手段と目的を間違えないことが大事

2回に分けてお送りしましたSTORES 決済のQAチーム立ち上げ→今に至るまでの裏側、いかがだったでしょうか。 hey社QAチームはQuality for funをモットーにチーム一丸となって品質保証・向上を行なってます。

カジュアル面談などもやっているので、もし興味がある方がいれば、ぜひこちらSTORES 決済のQAが、社内にある意味──QA 金子なづき・開発者 内立良介対談|heyに立ち寄ってみてください!