部門1人目のQAとして入社1年間でやったこと

システム本部デベロッパーエクスペリエンス室のQAエンジニア、伊藤由貴（@yoshikiito）です。

この記事はソフトウェアテストのカレンダー | Advent Calendar 2023 - Qiitaの8日目として書いています。

私は2023年の1月にシステム本部で1人目のQAエンジニアとしてJoinし、この記事を書いている時点でほぼ1年が経とうとしています。

そこで、今回は1年間をふりかえりつつ、取り組んだ内容をまとめました。我々システム本部での品質向上に関する取り組みについて、ぜひ知っていただきたいと思います。

1人目QAとしてJoinした際の状況など

私が所属するシステム本部では、7つの開発部で15のサービスを開発しています。私が入社する以前はQAエンジニアはおらず、各部の開発者がテストや品質向上に関する取り組みを行なっていました。

その時点で「障害が大量発生して大変！」「品質が悪くてプロジェクトが炎上！」といったことはなく、QAエンジニア無しでも開発を進められている状態ではありました。これはこれで良いことだと思います。

とはいえ、テストの作り方や実施度合いなどがチームや担当者によって差があったり、「これで充分だろうか？」といった懸念があったりということで、今後を見据えて品質向上に関する取り組みを行なっていく必要があると考え、QAエンジニアの採用に至った、という経緯です。

横断部門であるデベロッパーエクスペリエンス室にJoin

QAエンジニアとして私がJoinしたのは、個々の開発部ではなく「デベロッパーエクスペリエンス室」という、各開発部に対して横断的に支援をする部署です。

ここではQA以外にも開発者体験の向上につながるさまざまな施策をしており、入社直後に各開発部の方とコミュニケーションをとったり、全体がどうなっているのか状況を把握するには最適な環境でした。

ここで、大きく3つの取り組みを行ないました。

QAエンジニアとしての実務
社内外に向けたQAの認知度向上
今後立ち上げるQA組織の土台づくり

順番にご紹介します。

1. QAエンジニアとしての実務

部門全体に対して、品質向上に関する取り組みを行ないました。

現状把握のためのヒアリング

入社してからまず行ったのは、各開発部の方とのヒアリングです。各開発部でどういった開発の仕方をしているのかや、現状の品質やテストにおいてどんな課題を抱えているかなどを伺いました。

ヒアリングによって色々な情報を得ることももちろんですが、ここでは

QAエンジニアが品質に関する取り組みを巻き取るのではなく、一緒になって品質向上に取り組む存在であること
押し付けやルールの強制をする存在ではないこと

など、自己紹介とともにその位置づけや存在意義などを個別にお話できたことも大きかったと思っています。

ここでのヒアリングの結果を受けて、どの開発部にどういったサポートができそうかなど、今後支援をしていくうえでのアプローチについての検討を行ないました。

個別のチームでのQA支援活動

ヒアリング結果も参考にしつつ、実際にいくつかのチームにおいてQA支援活動を行ないました。

普段横断部門に所属しているため、支援をする際は基本的に「チームの外から」というスタンスになります。これは悪いことではないのですが、入社直後のQAエンジニアが外からのアドバイスに終始してしまっては、信頼関係が構築しづらかったり、改善につながりづらくなったりする懸念があります。

そのため、リソースの都合はあるものの、実際に複数のチームに密に関わることが必要だと判断し、定例参加などを通じて日常的に関わらせてもらっています。

各チームでは、

テスト分析〜設計〜実行
テストケースレビュー
テスト自動化
探索的テスト

などのテスト活動を中心とした関わり方をしたり、一部ではテスト状況を可視化するために開発チームの方々とともにテスト構成を整理したりしました。

テスト構成の整理

ここでのテスト構成とは

いつ
どんなテストを

しているか、を図示したものです。

実際のテスト構成をもとにイメージを作成したものがこちらです。また、この図にある水色の四角＝テストそれぞれに対して、具体的な観点やテストのやり方などを別資料でまとめています。

このような構成の整理を行なうことで、テスト設計やレビューがしやすくなること、障害が発生してしまった際にどこを改善すれば良いのかの検討がしやすくなることなどを期待してまとめました。

現在はこのテスト構成をプロジェクト開始時のテスト計画のインプットにして、以降のテスト内容やとくに見るべきポイントなどを開発チーム内で検討しています。

QAガイド・クライテリアの作成と推進

各開発部へのヒアリングや、複数の開発チームでの支援活動を通じて、全体としての課題感や組織の文化、品質に対する考え方などを把握することができました。

これらを元に、システム本部の各開発部が取り組むべきQA活動や達成すべき状態について記載した「QAガイド」を作成しました。また、各開発チームがどのくらいQAガイド記載の要件を満たしているかをセルフチェックするための「QAクライテリア」も併せて作成しました。

QAクライテリアを半年に1度、チーム単位で回答することによって、自チームのQA活動における課題や過去と比べて改善できている点などを可視化できます。

この「QAガイド」と「QAクライテリア」について、すべての開発部の部会を回って個別の説明も実施しています。全体連絡として「実施してください」だけでは伝わりづらいので、現場の皆さんに直接お伝えする場を持つ、ことを重視しています。

こちらはまだ運用開始したばかりなので、今後継続的に回答を収集することで、QAが各開発チームにどんな支援をするのかの検討や、各開発チームの中での改善活動の検討に役立てていきたいと考えています。

mablを用いたシステムテスト自動化の普及

システムテスト自動化ツールのmablに関しても、普及活動を行ないました。

私が入社する前からmablの導入自体は行われていましたが、活用しているのは1アプリケーションのみ、3000回の月間実行上限に対して実行が100〜200回程度と、かなり余裕がある状態でした。

そこで、本部内におけるハンズオンの実施や、複数チームで利用するための運用ルール設定などを行うことで利用を拡大。2023年11月時点では7アプリケーションで約2700回の実行と、活用が進んでいます。

もちろん、単純にmablでのテスト実行回数が多ければ良いというわけではありません。実施しているテストの内容や、その結果をどう活用しているかなども重要です。しかし、どんなテストをどんな頻度で自動実行すればよいかを、自動テストを導入する前から正確に判断することは難しいと考えています。

そのため、まずは自動テストの運用を体験してもらうことが重要だと考え、mablの普及を進めています。そこから、より適切な内容やタイミングに合わせていければと思います。

2. 社内外に向けたQAの認知度向上

前述のQA活動に加えて、社内外に向けたQAの認知度向上にも取り組みました。

社内に向けたQAの認知度向上施策

これまでQAエンジニアがいなかったこともあり、

QAエンジニアとはどんな存在なのか
どんなことをするのか
QA・品質保証とは何か

などを知ってもらうことが重要だと考えました。

そこで、まずは”ソフトウェアテスト・QA関連勉強会”を立ち上げ、週次〜隔週くらいのペースで勉強会を開催しました。

勉強会の内容はさまざまで、輪読会やChatGPTなどをテストに活用する話のほか、「開発者向け品質保証＆ソフトウェアテストイントロダクション」という座学や、「ライブテスティング会」という名前の、探索的テストの様子を生配信する会などを開催しました。

また、勉強会の開催の他にはナレッジベースの蓄積を積極的に行ないました。テストレベル、テストプロセス、テスト技法、テストツールなど、テストの用語から考え方などさまざまな情報を日々蓄積しています。

ライブテスティング会

直近でリリース予定のプロジェクトを対象に、開発環境で探索的テストをする様子を画面共有で見てもらうイベントです。

「一般的にはこういうところでバグが出ますよね」とか「ここに変な値入れてみたらどうなりますかね」など、探索的テストを実況生中継することで、テストを（一応）専門でやった人がどんな点を気にするのか、どんな見方をしているのかなどを共有することが狙いです。

実際にライブテスティングの題材になってくれた開発チームの方からは「緊張した」「ヒヤヒヤした」といった感想とともに、「自分が普段考えていなかったポイントも知れてよかった」など好評を頂きました。

実は探索的テストをひとに見せながらやっているわたし自身もけっこう緊張するのですが、ただ座学で「テストエンジニアの視点！」などをお伝えするよりは効果的かなと思っています。

内部への発信の成果

これらの取り組みの成果として、ナレッジベースを見てくれた方やライブテスティングを見てくださった方からチャットで相談をいただく機会が増えたことがあります。横断部門に所属しているQAエンジニアとしては、「いつでも気軽に相談できる相手」として存在していることが重要だと考えています。そのためのきっかけづくりも兼ねて勉強会開催やナレッジベースの蓄積を行っているので、相談をしてもらえるようになったことは大きな成果だと思っていますし、相談をうけるたびに毎回嬉しい気持ちになっています。