LayerX エンジニアブログ

LayerX の エンジニアブログです。

コンパウンドスタートアップにおけるQAチームの課題とのびしろ #LayerXテックアドカレ #のびしろウィーク

こんにちは!このブログを書くにあたり、LLMに「のびしろ」のいい感じの挿絵画像をリクエストしたら縦長のお城の絵が生成されました。バクラク事業部QAチームの nao です。

この記事は LayerXテックアドカレ2023 の43日目の記事です。昨日は @shun_tak さんが データ領域におけるイネーブリング活動と課題について について書いてくれました。そちらもあわせてご覧いただければと思います!

「のびしろウィーク」ということで、QAチームの活動で目指したい方向性や課題、そして伸びしろについて書きます。

のびしろウィークとは

「のびしろウィーク」とは、LayerXの各チームメンバーが自分たちのチームの伸びしろについて対外的に発信する期間です。

過去の対外的な発信では、社内でうまくいった事例などについては各種発信していました。しかし、弊社も多くの企業と同じように不確実な市場で事業に向き合っているため、うまくいったこともあれば、これからより良くしたい部分、いわば「のびしろ」もとてもたくさんあります。

そこで、今回はQAチームの伸びしろについてご紹介します!

私達の伸びしろを読んでみて、「その課題、一緒に取り組んでみたい!」とすこしでも思っていただけたら、ぜひ気軽にご連絡ください!

QAチームのミッションや普段の活動

私達QAチームのミッションは、爆速で開発されるバクラクプロダクトの品質をより高く、顧客価値につなげ、高速にリリースすることです。その実現手段として、書籍「Agile Testing」で謳われるようなWhole Teamでの品質・テスト活動の実現を進めています。

具体的には、バクラク事業部には「経費精算」「請求書受取」「ビジネスカード」「申請」「電子帳簿保存」「請求書発行」というプロダクトが存在し、それらの開発チームの一員として各QAエンジニアはテストや品質に関する活動をリードする役割を担っています。

QAチームの活動については、以前の記事「世の中に新たなQAの形をつくる」半年に1つのペースで新規プロダクトが生まれるLayerXのQAのあり方」が参考になりますので、よろしければそちらもご覧いただければと思います。

Whole Teamでの品質・テスト活動の実現に向けて

先にも述べた通り、各QAエンジニアは各開発チームにてテストや品質に関する活動をリードする役割を担っています。そのため、現状は、開発チーム全員で開発物を一斉にテストする会や、複数の仕様や開発物の共有会を、QAエンジニアがファシリテートしています。しかし、それらだけでなく、開発サイクルの後半でテスト期間を設け、QAエンジニアが開発物をテストするなど、まだQAエンジニアがリリース前のテスト担当のような状態になっています。

加えて、プロダクトが大きくなっているチームやこれからリリースするプロダクトのチームなど、チームによって大きく状況が異なり狙う品質が異なるものの、従来からおこなってきた一定のQA活動の型で進めてしまっている部分があります。現在、QA戦略の再設計などを進めているものの、まだ道半ばで、チーム内での品質に関する議論や狙う品質に合わせたQA活動の型作りなどがまだ十分にはできていません。

そして、プロダクトの品質はあらゆるステークホルダー間で話されるべきだと思いますし、会社全体で興味を持つべきテーマだと思います。そういった文化を実現するために、QAエンジニアとして全社的に働きかける動きをおこなうべきですが、上記の課題などがあり、まだできておらず歯痒い思いをしています。

プロダクト連携に対するテストの解を持ちきれない

弊社は「コンパウンドスタートアップ」という戦略をとり、創業時から複数プロダクトを意図的に提供しています(コンパウンドスタートアップに関しては、詳しくは弊社の福島が書いた「コンパウンドスタートアップというLayerXの挑戦」をご参照ください)。私達QAチームが担当しているバクラクシリーズもその一部であり、「プロダクト間の連携の良さそのものがプロダクトである」と考え、プロダクトをまたいだ滑らかな体験になるよう設計されています。

開発チームもある程度データを中心に構成し、開発がおこなわれるものの、チームをまたいだ機能を、誰がどのようにテストするかを本質的に解くための戦略の解をまだ持てていない課題があります。現状、チームをまたいだテストが必要になった段階で、必要なコミュニケーションを取り解決していますが非効率かつ漏れに気づきにくいため、今後はプロダクト間のテスト設計やコミュニケーションの型などで、課題の解決をしていきたいと考えています。

プロダクトのUXや機能仕様へのフィードバックがおこなえていない

QAエンジニアはリリース前のテストや自動テストの実装などでかなりの時間をかけてプロダクトに触れています。ですので、プロダクトのUXや機能仕様に関するフィードバックをもっと率先しておこなうべきであると考えています。ただ闇雲にフィードバックするのではなく、事実に基づいて、お客様の体験向上に焦点を当ててフィードバックすべきだと考えています。そのためには、QAエンジニアが「お客様の業務の深い理解」、「他社プロダクトの理解」、「UXデザインやIA(情報設計)の知識」を深めていく必要があると考えていますが、まだまだ理想には遠くおよばない状態です。 それに向けて、まずは他社プロダクトの理解をすることで、探索的テストの中でプロダクトの改善点にも目を向けた検証をしている程度ですが、その先でQAエンジニアからもUX改善の提案が日常的におこなわれている状態を目指して、これからも凡事徹底して頑張っていきます。

まとめ

QAチームは立ち上がって1年以上経過していますが、まだまだプロセスや戦略、活動範囲などには課題や伸びしろが多く、これからも改善していきたいことだらけです。

今回のブログであつかった3点の他にも課題や伸びしろは沢山ありますし、それらを解決しながら成長できると信じて、1つずつモダンなQAならどうあるべきか?を日々問い続けていこうと思います。もし今回の課題に一緒に取り組んでみたい!一緒に成長するような経験をしたい!と少しでも感じていただけたら、ぜひお気があるにご連絡いただければと思います!

すこしでもピンときたらぜひお話ししましょう

とにかくいいQA活動を実現したいので、すこしでもピンときたらぜひお話ししましょう!カジュアル面談への参加をお待ちしています。

私のカジュアル面談はこちらです👇 jobs.layerx.co.jp