※この記事は 2024年06月04日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。
Tebiki株式会社でQAエンジニアをしている中西です。 2023年1月に一人目QAエンジニアとして入社して、1年半が経過しました。 今回は1年半をふりかえり、取り組んだ内容を簡単にまとめました。 これまでのQAエンジニアの活動を知っていただき、現在のプロダクト、チームの状況をお伝えしたいと思います。 一人目QAエンジニアとして奮闘している方、他社のQA活動に興味がある方に何か伝えられれば幸いです。 それでは、振り返っていきます。取り組み内容の詳細を知りたい方は、ぜひカジュアル面談でお話させてください。
知ってもらう
入社して最初に取り組んだことは、社内外にTebikiのQAエンジニアについて認知してもらうことを目的にミッションを策定しました。
このミッションによって、ソフトウェアテストによる品質保証よりも開発プロセス全体でボトルネックになっている、もしくはなり得るプロセスを改善することに注力できるようになりました。 また、採用という点においても、TebikiQAエンジニアの位置づけが明らかになり、「QAエンジニアのミッションに共感してくださる方」という採用軸ができました。
次に、JSTQBのシラバスやASTERセミナー標準テキストなどを引用／参考にし、ソフトウェアテストに関するマニュアルを作成しました。開発エンジニアに体系的なソフトウェアテストに関する知識を身につけてもらい、開発エンジニアとQAエンジニア間で同じ用語を使って会話できるようにするためです。QAエンジニアと開発エンジニア間で知識の隔たりがある状態だと、解釈の違いによる認識齟齬がおき、テストプロセスの改善がうまく進まないと考えて行動しました。 さらに、開発エンジニアがチームに参画する時のオンボーディングコンテンツの一つに組み込み、ソフトウェアテストを学習するための最低限の機会を作りました。しかし、1度読んだだけでは習得できないため、定期的に見返せるように仕組み化できないかモヤモヤしています。
テストプロセスの改善
Tebiki社におけるQAエンジニアの役割とソフトウェアテストの基本について知ってもらうことができたので、テストプロセスの改善に取り組みました。そのうちの2つを紹介します。
基準作り
各エンジニアの主観的な判断によって、不具合修正の優先順位が決まっていたため、優先順位を決めるための基準とそれを判定するためのリスクマトリクスを作成しました。
そして、不具合の影響度とその不具合が発生しているドメインに基づき、リスクレベルを判定し、リスクレベルに応じた行動を定義しました。
リスクレベル 最高 / Critical : 直ちに修正する リスクレベル 最高 / Critical以外 : POと相談し、対応時期を決める
上記のリスクマトリクスを使った行動規定はチーム内にうまく浸透し、以下の開発タスクでも活用することができました。
ローレベルのテストケースの作成と実施基準
QAエンジニアによるテストケースレビューを実施する基準
本番環境で発生した不具合対応状況をユーザーへ告知する方法を決める
振り返ってみると、このような基準作りはQAエンジニアならではの仕事だと思いました。Tebiki社でQAエンジニアとしてのバリューが発揮できたと感じた改善です。
テストガイドの作成
シナリオテスト、探索的テスト、クロスブラウザテストといった、目的に応じたソフトウェアテストの導入を推進しました。しかし、開発エンジニア自身で、このようなテストをどういう時に実施すればよいか判断することができませんでした。
それを解決するために、テストフローと呼ばれるドキュメントを作成しました。（下記画像参照）このテストフローに従うことが定着し、開発エンジニア自身で必要なテストタイプを選択することができるようになりました。
開発チームを超えたプロセス改善
このような活動を経て、以前よりも開発エンジニア自身で適切なテストタイプの選択とテストケース作成ができるようになったたため、次は開発チームを超えたプロセス改善にチャレンジすることにしました。 というのも、カスタマーサポートチームが組織され、ユーザーからの問い合わせ（仕様に関する質問や不具合報告）が徐々に増加する傾向が見られました。それに対処するため、QAエンジニア主導で以下の施策を行いました。
問い合わせ対応フローの策定（標準化）
開発エンジニアがどういう条件で、どのチーム（ロール）にどのような支援を求めて、回答を行うか迷わずにできるようにするために、フローを作成し、フローに沿った運用を定着させました。
問い合わせ対応状況の可視化（可視化）
開発エンジニアが問い合わせ対応した結果を可視化し、問い合わせ対応プロセスの改善に繋げられるようにしました。
CREの立ち上げ（改善）
問い合わせの早期解決と顧客の今抱えている課題を解決するためにCREというロールを作りました。詳細はまた別記事にして、ご紹介します。
振り返ってみて
問い合わせフローの策定（標準化）→ 問い合わせ対応状況の可視化（分析）→ CREの立ち上げ（改善）というように問い合わせ対応プロセスに対して、改善サイクルがうまく回せた活動でした。 また、カスタマーサポートチームと連携を取り、リリースした機能がうまく使われるようにヘルプサイトの改善にもQAエンジニアが貢献できました。開発チームを超えて、カスタマーサポートチームの領域の品質も支援している実感を感じています。このような活動はプロダクト全体の品質、体験を向上していくうえで大事だと考えており、継続していきたいと思ってます。
品質の可視化
そして、現在、開発チーム全員の品質に関する考えをすり合わせたり、品質を可視化し、振り返れるように以下の活動を行っています。先日公開した記事の活動もその一環です。
・品質についてみんなで考える
・品質指針の策定
・品質目標の策定
QAエンジニア主導で考えすぎると、開発エンジニアが改善活動にオーナーシップを持たなくなる恐れがあると考えています。開発エンジニア自身がオーナーシップを持って、このような改善に取り組むために、開発エンジニアとQAエンジニアがどこまで関わるべきかを考えていたりします。
今後について
このように入社から今まで、プロセス構築に注力してきました。一方、ソフトウェアテストをサポートする活動（ペアテスト設計、ペアテスト実施、テスト自動化など）に注力できていません。まだまだ具体的ではないですが、開発エンジニアと近い距離で業務を行い、より実践的なソフトウェアテストの技術伝承をしていきたいと考えています。
私たちは仲間を募集しています！
Tebiki社では、エンジニアを募集しております。様々なチームを巻き込んだ品質改善に興味がある方は、ぜひカジュアルにお話ししましょう！
▼採用HP 現場の未来を動画技術で切り拓く Tebiki株式会社
▼募集中のエンジニア求人一覧 3.エンジニア の求人一覧 — Tebiki株式会社
