QAエンジニア（※QA : Quality Assurance（品質保証））は、ソフトウェアの品質確保のプロフェッショナルとして、お客様にプロダクトが提供される前に、システムが意図通りに動作するか、必要な品質基準を満たしているかを確認する重要な役割を担っています。

今回は、2022年7月にTOKIUMに入社し、現在はQAチームでリーダーを務める富田さんに、自社プロダクトのQAとして働く面白さやTOKIUM QAチームならではの魅力についてお話を伺いました。

「第三者検証」ではなく「自社プロダクト」のQAとして働くという選択肢：TOKIUM QAの特徴と魅力

はじめに自己紹介をお願いします。

現在はTOKIUMでQAのリーダーとして、テスト設計やQAチーム全体のプロセス改善などに取り組んでいます。

開発に携わっていない第三者の視点から品質保証を行う第三者検証からQAとしてのキャリアをスタートし、計10年間、ソフトウェアテストや品質保証の分野で経験を重ねてきました。

QAの仕事を始めた当初は手動テストを行う一人のテスターとして活動をしていましたが、徐々にテストの自動化やチームのマネジメントに関わるようになりました。

TOKIUMに入社したきっかけを教えてください。

前職が第三者検証ということもあり、自社プロダクトの品質保証に携わることへの憧れがありました。

第三者検証では様々なプロジェクトにスポットで入り、短期間でテストを実行しますが、自社プロダクトでは一つのチームに所属し、継続的に同じプロダクトの品質向上に携わることができます。

品質保証という仕事に携わる者として、テストを実行して終わりではなく、長期的に責任を持ってプロダクトに関わり続けられる点に大きな魅力を感じていました。

また、TOKIUMのQAチームがPdMチームと連携して、要件定義から品質保証まで幅広く活躍できる人材を求めていることや、テスト自動化にも携われることを聞いて、様々な挑戦ができる環境だと思い、入社を決断しました。

第三者検証のQAと自社プロダクトQAの両方を経験したうえで感じるそれぞれの面白さについて教えてください。

第三者検証の面白さは、多種多様なサービス・プロダクトに携わることができ、経験値を積みやすいところだと思います。またプロジェクトベースで関わる方が変わるので、プロダクトだけでなく、様々な方々と関われる面白さもあります。

一方で、自社プロダクトは要件定義の企画段階など上流工程からQAとして関われるという特徴があり、テスト単体ではなく、プロダクト作り全体を見渡した視点も磨かれるので、モノづくりが好きな人はやりがいを感じるのではないでしょうか。

他の自社プロダクトのQAとの違いとして、組織体制に特徴があると伺いました。具体的に教えてください。

前提として、QAチームが属するTOKIUMのプロダクトチームは、実際にソフトウェアの開発を行う「開発部」とプロダクトの企画や仕様の設計を担う「プロダクト部」に分けられるのですが、TOKIUMのQAはプロダクト部に属しています。そのプロダクト部の中に、PdMチームとQAチームがあるという位置づけです。

これは、普段上流で活躍しているPdMとQAが同じ部署にいることで、QA自身もお客様への価値提供をより意識できるようにすることを意図しています。

もちろんQAチームが開発部に属する体制をとる場合には、不具合対応やテスト実行の際の連携が向上するという利点もありますが、そうしてしまうと、PdMとの関わりが少なくなるのでユーザ視点・UI/UXの視点が薄くなりかねないです。

プロジェクトの最前線：UI刷新プロジェクトでのQAの役割

直近でUI刷新プロジェクトにQAリーダーとして参加したと伺いました。このプロジェクトの概要と立ち上げの背景を教えてください。

UI刷新は、TOKIUMインボイスの請求書画面を一から見直し、デザインと使いやすさを抜本的に向上させるためのプロジェクトでした。請求書画面は、お客様の業務効率に大きく関わる部分のため、そのUI刷新は非常に重要なプロジェクトと位置付けられていました。

プロジェクトは、お客様からこれまでにいただいていたご要望、追加のヒアリングをもとに、PdMが中心となって現状のUIのどこが問題なのかを整理したところから始まりました。

QAチームはどの段階で、どのように関わりましたか？

このプロジェクトは、要件定義と並行して、デザイン作成を行ったり、一部開発に着手したりとアジャイルに進んでいきました。その後、テストの段階に進むという流れでした。

QAチームは、デザイン作成の段階から徐々に入っていきました。テスト自体はまだ先でしたが、この段階ではデザインの意見出しやテストスケジュールの調整を行っていました。

一般にQAはテスト設計フェーズからの参画が多く、このように初期段階から関わるケースは比較的珍しいですが、TOKIUMがこのような早い段階での参画を実施している背景には、2つの意図があります。

1つは、ユーザーの様々な利用シーンを想定したQAならではの視点でデザインに対して意見を出すことで、より良いUXを実現するためです。もう1つは、プロジェクトの早い段階からキャッチアップすることで、テストのリソース管理をより効果的に行い、テストの迅速かつスムーズに完了させるためです。

このプロジェクトにおいて、QAチームが特に注力した点や工夫した点はどのようなことでしょうか？

大規模な開発であったため、重大な不具合の検知漏れを防ぐことを最優先事項として取り組みました。そのために、特にテスト完了後の不具合分析に力を入れました。

不具合分析をすることで、不具合の発生パターンからリスク領域を特定できるので、この結果をさらなる追加テストの検討に活用し、不具合リスクの高い問題を未然に防ぐことができます。また、開発チームに不具合分析を共有することで、開発チームとしても不具合発生の根本原因の特定に取り組むことができ、不具合発生の根本原因を特定し、再発防止が可能になるため、開発の改善にもつながります。

アジャイル開発ではスピードが重視され、こうした丁寧な分析プロセスを省略しがちですが、今回のUI刷新プロジェクトでは、長期的な品質維持の観点から徹底して分析を行いました。

この分析の結果、お客様に安心してご利用いただける状態でリリースすることができました。

このプロジェクトを通じて、QAチームとしてどのような進化を遂げましたか？

このプロジェクトは、QAチーム総動員での大規模な取り組みとなりました。その中で、テスト時は多くのメンバーを巻き込んで、複眼的思考でテストしていくことの重要性に気づけたことが大きな成果です。

1人のテスターの確認では見えてこない視点も、複数人でテストすることにより、多様な利用シーンを想定した検証が可能になり、より幅広い観点からUI/UXの改善点を洗い出すことができました。

また、QAチームのみならず、開発部や、お客様を最前線でご支援するカスタマーサクセス部、カスタマーオンボーディング部の方などにもテストにご協力いただきました。多様な視点から意見をいただき、より良い品質でリリースをすることができました。

TOKIUM QA改革：QAチームの進化

テスト設計の方法の改革に取り組んでいると伺いました。どのような改革を行ったのか教えてください。

これまでは組み合わせ系のテストや互換性確認、ユーザビリティチェックなどの実施可否を感覚値で判断するにとどまっていました。

しかし現在は、各テスト項目に対してより具体的な実施方法を定義し、効率的に品質を検証をするための方法論である「テスト技法」を積極的に活用しています。

加えて、マトリックスやグラフを活用することで、必要なテスト範囲を可視化し、一目で把握できるようになりました。これらにより、テストの網羅性を客観的に担保し、より一般化された手法での品質保証が可能となりました。これは、テスト担当者の経験や勘に依存せず、誰が実施しても一定水準の品質を確保できることを意味します。

テスト設計方法を見直した背景には、どのような課題意識があったのでしょうか？

テスト設計の改革の背後には、2つの重要な課題認識がありました。

1つ目は、テストケースの網羅性の見える化です。従来の手法では、テスト観点の漏れを特定することが困難で、どの領域に対して重点的にリソースを投入すべきかの判断が適切にできていませんでした。

2つ目は、QAの専門性の活用についてです。以前はテスト技法の活用が十分でなく、QAならではの知見や専門的な観点を、より効果的にテストプロセスに反映させる余地がありました。

これらの課題を解決するため、テスト設計プロセスの改革に着手しました。

QAチームとしての今後のビジョンについて教えてください。

　長期的な目標として、どのようなテストケースに対しても最適なテスト技法を選択・活用できる体制の構築を目指しています。そのためには、各テストシナリオに適した技法の選定基準を整理し、チーム全体への普及を図る必要があります。

具体的な取り組みとして、「境界値分析」、「オールペア法」や「状況遷移テスト」といった技法ごとのサンプルケースの作成とナレッジの共有をしていこうと考えております。

また、テスト技法のトレーニングについて、これまでは個々の手法の習得に重点を置いていましたが、今後は「どのような状況でその技法を活用すべきか」という実践的な判断基準の共有にも注力していこうと思っています。

私自身、テスト技法に関して完璧な知見を持っているとは考えていませんが、これまでの経験で培ったノウハウをチーム全体に共有していき、組織としての対応力を高めていきたいと考えています。

QAという名のモノづくり：TOKIUM QAのやりがい

QAエンジニアとしてやりがいを感じる瞬間はどのような時ですか？

　QA独自の視点でプロダクトの安全性や品質向上に貢献できた時に、特に大きなやりがいを感じます。例えば、テスト設計においてQAならではの観点を提供できた時や、重要な不具合を発見した際に開発部から感謝の言葉をいただいた時は、特に強い手応えを感じます。

開発チームが主にコードベースでシステムを理解しているのに対し、QAチームは製品の画面を最も長く操作する立場として、実際の画面操作を通じて製品を理解しています。

この異なる視点があるからこそ、ユーザー体験に直結する問題点や機能変更による影響範囲を見出すことができ、それがQAとしての大きなやりがいにつながっています。

今後、QAエンジニアとしてどのようなキャリアを築いていきたいですか？

QAのキャリアパスには、テストの管理を行う「QAマネジメント」、品質戦略を提案する「QAコンサルタント」、技術力を強みとする「QAスペシャリスト」という3つの方向性がありますが、私は「QAスペシャリスト」としての道を目指していきたいと考えています。一人のプレーヤーとしてテスト設計技法を極めていくことに、大きな魅力を感じているからです。

テスト設計には、ものづくりに通じる面白さがあります。最適なテストケースを一から作り上げていく過程では、テスト技法という理論的な基盤と、個人のセンスや創造性が同じくらい重要になります。この2つの要素を組み合わせることで、それぞれのプロジェクトに最適なテスト設計を実現できます。

また、プロジェクトごとにテストの対象や機能が異なるため、そこで求められるテストの内容も多種多様です。この変化に富んだ環境でテスト設計の専門性を高めていけることに、大きなやりがいを感じています。

TOKIUMのQAに興味を持たれている方へメッセージをお願いします。

TOKIUMの特筆すべき特徴として、組織全体のQAに対する高い関心度が挙げられます。開発部、PdMチーム、そして他部署の方々が、常にQAの視点を取り入れることが品質向上につながるということを理解して、「QAの人はどう考えるか」という観点で相談してくださいます。

また、現在のTOKIUMのQAチームは、様々な挑戦ができる環境が整っています。先述したプロセス改善をはじめ、多くの新しい取り組みを進めている最中です。現状が最善だとは考えておらず、もっとよい仕組みづくりができると思っています。

QAエンジニアにとって、他チームからの理解があり、かつ挑戦を後押ししてくれる環境で働けることは決して当たり前ではありません。意欲的な方々にとって、非常に魅力的な環境だと思います。

一緒に改善・改修を推進してくださる方を心待ちにしています。