チーム専属QAからE2E自動化横断支援へ。QAキャリアを前進させた1年間

こんにちは！　株式会社MIXIでQAをしているayanoです。
この1年間、私は「チーム専属QA」から「横断的なE2Eテスト自動化の支援者」という新しい役割に挑戦してきました。

この記事では、そんな私がどんなきっかけでキャリアを変え、どんな1年を過ごしてきたのかをまとめます。
「チームの中で頑張るQA」から、「チームを支えるQA」へ──その変化の過程を、ひとつのキャリアケースとして読んでいただけたらと思います。

チーム専属QAとしての私

異業種・異職種からQAエンジニアに転職して5年半の期間、私は計4つの開発チームで「チーム専属QA」として働いてきました。
最初は、テスト実行を通じてソフトウェアテストの基礎を学ぶところからのスタート。
次第にテスト設計やレビューにも関わるようになり、その過程で「テストをする」ことが品質保証のすべてではないと教わります。

やがて、QAエンジニアとは“みんなをよくする人”である、という定義に出会います。
それは、私が漠然と感じていた理想像が言語化された表現でした。

「チームをよくするために、自分にできることを増やしたい」
そう思いながら、レビューやふりかえりの技術を磨き、プロセス改善のアイデアを考え、ノーコードツールでの自動テストに挑戦するなど、日々の業務の中で“自分なりの成長”を積み重ねていました。

チーム専属QA時代の課題と限界

チーム専属QAとして複数チームを経験し他チームと交流する中で、次第に“技術の属人化”という壁を感じ始めました。
スキルの高い人がいるチームは自然とテスト技術が発展していく一方で、そうでないチームは停滞したまま。
そして、そのスキルを持つ人が異動や退職で抜けてしまうと、チーム全体の技術力が少しずつ下がっていく──。
そんなサイクルを、いくつかのチームで見てきました。

「せっかく誰かが積み上げた知見や工夫が、チームの外に出ないまま消えてしまうのは、あまりにももったいない」、そう感じたのが、今思えば最初の“横断的に動きたい”という原体験でした。

特に印象的だったのが、「テスト自動化」に携わり始めてから初めてチーム異動をした時のことです。
初学者である私が手探りで自動化を進めてきた以前のチームと違い、異動後のチームでは自動化のスキル感や進め方がまったく違うことに衝撃を受けました。
さらに他チームの状況を聞いてみると、全社的には「進んでいるチーム」と「まだこれからのチーム」が極端に分かれている気がします。

このままでは、せっかくの知見がチームに閉じてしまい、いつか消えてしまう。
私は、社内向けに自動化の知見を共有する取り組みを始めましたが、“チーム専属の立場”では、できることにどうしても限界があるという現実に直面します。

「もっと横断的活動に注力できたら、全体を良くできるのに」そんな思いが、少しずつ強くなっていきました。

横断活動への移行を決断

「チームの中で頑張る」だけでなく、「チームを支える側」に回りたい。そして、テスト自動化の専門性をもっと深めたい──
そう真剣に考え始めたのは、チーム専属QA歴5年の頃でした。

前述した“QAエンジニア＝みんなをよくする人”という定義は、西康晴さんによるQMファンネルで提唱されました。

私が思い描く姿は、QMファンネルで言うところのロール（実業務への近さ）を「インプロセス」から「コーチ」に変え、スペシャリティ（専門性）をQA・TE（プロセス改善・テスティング）からPE（プロセスエンジニアリング＝自動化領域）へと広げた先にある。
その方向性に、自分のキャリアの可能性を感じていました。

また、ちょうどその頃、個人的にワークライフバランスの見直しが必要な時期に差し掛かっていました。
「限られた時間の中で、自分の価値をどう最大化できるか」
──そう考えたとき、“自分の得意を広げて組織をよくする”という挑戦は、自然な選択だと思えたのです。

組織としても以前から「テスト自動化への取り組みにバラつきがありそうだが、そもそも実態を把握できていない」「横断的に活動するQAエンジニアの不足」という課題がありました。私が思い描くQAの新しい形である「E2Eテスト自動化の横断支援」は、その課題を解決する方向性を意識した結果でもありました。
私が「横断支援をやってみたい」と相談したとき、マネージャーは即座に「いいね」と背中を押してくれました。
理想を共有できる上司がいたことは、この挑戦の大きな追い風になりました。

これらの経緯を経て、「QAによる横断支援」という新しい役割を社内で初めて試すことになりました。

横断支援で取り組んだこと

こうして始まった「横断支援」という新しい役割。
誰もやったことのないポジションだったので、まずは「何をしたいのか」や「どう進めれば実現できそうか」を言語化しながら、少しずつ活動の形を作っていきました。

まずは「活動の地図」を描く

最初の2か月は、あえて急いで動かず、現状把握と方針づくりに時間を使いました。
マネージャーとの活動方針のすり合わせの結果、初期は「MagicPodというツールの普及・利用サポート」に焦点を当てて自らの役割を説明することにしました。ツールを入り口にすることで相談へのハードルを下げ、「横断支援」が受け入れられやすい環境を作るためです。

「MagicPodというツールの普及・利用サポート」だけを考えてもアイデアが豊富にあったので、Miroのオンラインホワイトボードを使用してやるべきこと・やりたいことの可視化を行いました。

そして、アクションへの変換としてタスクの粒度まで落とし込む。この方法で、「大きな方針」と「実際に着手するタスクの内容や優先度」がブレないまま進めることができました。

オープンに、見える形で動く

活動を始めたときに意識したのは、「何をやっているのか」「なぜやっているのか」をオープンにすることでした。

タスクはすべてNotion上で管理し、組織のミッションやビジョンとリレーションさせながら、進捗は自動でSlackに通知されるようにしました。
外から見ても活動の全体像がわかる仕組みを整えたのです。

「その場しのぎ」で終わらせないための仕組みづくり

横断支援の目的は、単に「問題を解決すること」ではありません。
“解決し続けられる状態”を作ることです。

そのために取り組んだのが、

• テスト自動化ポータルの構築（社内のナレッジ集約）
• ダッシュボード・テンプレートなど、再利用できるツールの整備
• チーム支援の中で得た学びの体系化（ドキュメント公開）

これらを通して、特定チームで終わるノウハウを「全社で使える仕組み」に変えていきました。

事業を超えて汎用的に利用できる「MagicPodの分析ダッシュボード^[1]」や、「MagicPodのケース一覧と実行結果一覧を分析可能なデータベース形式で取得するGAS」、そしてツールを限定せずに使える「テスト自動化アーキテクチャ（TAA）テンプレート」などは、いずれも最初から全社利用を前提に設計しました。
これらは実際に、複数事業で活用されています。

「教える」ではなく「伴走する」

支援のゴールは“私が手を動かすことによって問題を解決する”ことではなく、“チーム自らが問題を解決し、理想の状態を維持できる状態を保てる力を得る”ということ。
「今だけの支援」で終わらせず、支援が終わった後も自走できる文化を育てるために、私は以下の4つを大切にしてきました。

1. 机上ではなく現場から始める

まずは現場のQAに話を聞き、リアルな課題からスタートする。
現場の温度感なしに仕組みを作っても、長続きしません。
実際に支援を行った事例は全て、QAからの直接の相談がきっかけでした。

2. 実務は有限、相談はいつでも

実務支援はあくまで短期間。実務支援では必ずゴールを決めて、設定した期限内にスキルトランスファーが完了するようにしました。
代わりに、支援が終わった後も“相談できる隣人”であり続けることを意識しました。
「いつでも相談してください」と周知するだけでなく、チーム単位で定例のザッソウ（雑談・相談）MTGを設けることで、「相談できる仕組み」を維持しました。

3. 技術ではなく文化を根付かせる

数ヶ月以上の支援を行ったすべてのチームに、「ふりかえり」の開催を提案・主導しました。
プロセス改善としてのふりかえりの工夫やファシリテーションの経験を活かし、チーム自身が成果と課題を言語化できる場を作ることで、継続的な改善文化を根付かせていきました。

4. 答え・指示ではなく、選択肢の提示・問いかけを

「これが正解です」と理想論を押し付けるのではなく、一般論や他のチームの事例を紹介しつつ、最終的にどの道を選ぶかは、必ずチーム自身に決めてもらいました。
これは私自身がテスト自動化についても支援活動についても未熟であるが故でもありますが、「コーチ」というロールを強く意識したものでもあります。

ふりかえりの場でも、議論の中で「提案された〇〇をやりましょう」と流すのではなく、「この課題を解決するために、どんなゴールを設定すると良さそう？」「〇〇をやるにあたって、詳細を決められる？まずはこの部分は具体的にどんな風に取り組む？」と深掘りできるように問いかける。
その問いを通じて、チームが自分たちの答えを見つけていけるようにしました。

成果と成長

横断活動を通じて、支援先のチームに変化をもたらすと同時に、私自身も大きく成長できたと感じています。

チームに起きた変化

E2E自動テストを新規導入したとあるチームでは、リグレッションテストの手動実行工数を74%削減^[2]できました。導入済み自動テストの改善支援をしたチームでも、成功率の向上など、定量的な効果が見え始めています。

しかし何よりも嬉しかったのは、支援先チームのテスト自動化に対する意識が前向きなものに変化したということです。
支援によってチームの中に「自分たちで前に進められている！」という感覚が芽生える瞬間を、私は何度も目の当たりにしました。
特に印象的だったのは、ふりかえりを開催したときのこと。
メンバー同士が互いの成長に気づいたり、QAだけでなくエンジニアやPMまでもがテスト自動化の価値と課題を共有するようになり、どんどん“自動化が自分ごとになる”瞬間を目にすることができました。

“解決し続けられる状態”を作れたかどうかは、これからも長い目で見ていく必要があると思いますが、解決し続ける文化のための種を蒔くことはできたのではないかなと思います。

自分自身の成長

テスト自動化の知見が、教える視点で深まった

この活動を始めるにあたり、ツールやテストレベルを超えてテスト自動化全般を学びましたが、やはり「自分のために学ぶ」のではなく「広く共有するために学ぶ」ので今までとは理解の深さが違います。

そして複数のチームと向き合うことで、現場ごとに異なる課題や文化に触れ、「抽象的な原則をどう現場に落とし込むか」を考える機会が格段に増えました。
その経験が、テスト自動化を“技術”ではなく“仕組みづくり”として捉える視点を育ててくれました。

自分に合うロールの発見

この1年で、自分にとって品質保証に対する“しっくりくる関わり方”がはっきりしてきました。
それは、チームの一員として課題に取り組む「インプロセスQA」よりも、チームの外側から成長を支える「コーチング的な関わり方」のほうが、自分には向いているという実感です。

以前の私は「チームの中に入り、手を動かして改善していく」ことにやりがいを感じていました。
けれど、横断支援を通じて複数のチームをサポートするうちに、“自分が動くことで課題を解決する”よりも、“相手が動けるようになる環境を作る”ことのほうが、より自分の強みを発揮できると気づきました。
これは、キャリア転換を決断したときに抱いていた“きっとこの方向が自分に合うはず”という予感が、確信に変わった瞬間でもありました。

今後はテスト自動化の専門性を深めるだけでなく、より体系的にコーチングを学びながら、“チームの力を引き出すQA”を目指していきたいと考えています。

成長を支えたのは生成AIとの協働

そしてもう一つ、この1年を語るうえで欠かせないのが生成AIとの協働です。

横断支援は手を動かすよりも思考に充てる時間が長く、判断に迷う場面も多い仕事です。
そんなとき、AIが“いつでも壁打ちできる相棒”でいてくれたことは大きな支えでした。
文章のレビューやアイデア出しはもちろん、ノンプログラマでありながらGASやPythonで社内向けツールを自作したりと、AIの力を借りてできることの幅が一気に広がりました。

また、私はプログラミングが苦手で、コードで書く自動テストの経験がほとんどありません。書籍などからの知識はありますが、実体験がないため何となくでしか理解できていないのです。
それでも、E2Eテスト（シナリオテスト）だけでなく、ユニットテストや統合テストといった他のレベルの自動化についても理解を深め、「テスト自動化全体」を支援できるようになりたい──
そのためには、まず自分自身が“コードでテストを書いて運用する”経験を持つ必要があります。

今は生成AIのサポートを受けながら、少しずつテストコードを書き、動かす練習をしています。
「コードが書けないから私にはできない」をツール自作で乗り越えられた経験があるからこそ、AIと一緒に学んで専門性を広げることへのハードルが格段に下がったのです。

今もまだ学びの途中ですが、AIがあることで「わからない」を怖がらずに進めるようになりました。
これからの成長を考えたとき、生成AIは間違いなく、私にとって欠かせないパートナーです。

学び・気づき：キャリアの広げ方

この1年間の横断支援を通じて、私はたくさんのことを学びました。
技術的なスキル以上に、“QAのキャリアの考え方そのもの” が大きく変わったように思います。

QAのキャリアは「深める」だけではなく「広げられる」

QAは「スキルを深めること」こそが成長だと思われがちです。
テスト設計を学び、レビュー力を磨き、より高い専門性を身につけていく──
その延長線上だけにキャリアがあると信じている人も少なくありません。

けれど、横断支援に携わる中で、もう一つの方向があると確信できました。
それは、“スキルを横に広げる”という選択です。

今、QAには驚くほど広い専門性が求められています。それと同時に、少ない予算の中スピードも求められるので、与えられた業務をこなすだけでは、どの分野も浅く終わってしまう。
自分で枠を越え、学びに出ていかない限り、TE・QA・PEといったスペシャリティは本当の意味で身につかないのではないか──そう感じています。

少なくとも、私自身はそうでした。
経験を土台にPEの領域へ自ら踏み出すことで、初めて“広げる学び”の面白さを知りました。
もし環境がそれを許すなら、「今あるスキルを活かしながら横に広げる」という選択を、ぜひ一度検討してみてほしいと思います。

QAと一口に言っても、役割の広げ方次第で景色は変わる

同じQAでも、どんな関わり方をするかで見える景色はまったく違います。

ロールを変えることは、スキルチェンジではなく視点のシフト。
QMファンネルでは、下にあるロールほどより多くのスキルを必要とする構造になっています。ここで言うスキルは、技術的なハードスキルだけでなく、コミュニケーションや可視化、ファシリテーションといったソフトスキルも含まれるでしょう。
下にあるロールにチャレンジすることで、飛躍的な成長を実感することができました。

キャリアの広げ方は、自分の「好き」と「得意」の交差点にある

この1年を通して感じたのは、キャリアの答えは外に用意されているものではなく、自分の中にあるということです。

「チームの中で手を動かすこと」が好きな人もいれば、「チームの成長を支えること」にやりがいを感じる人もいる。
どちらが正しいということはなく、それぞれの“好き”と“得意”が交わるところに、自分らしいキャリアの形があるのだと思います。

QAという仕事は、まだまだ進化できる。
その可能性を信じて、一人ひとりが自分のスタイルで品質を支えていけたら──
それこそが、私がこの1年を通して学んだ最大の気づきです。

まとめとこれからの展望

この1年間、チーム専属QAから横断支援QAとして活動してきて、自分のキャリアの形を見つめ直す時間をたくさん持てました。

これから挑戦したいこと

これからは、より高度な自動化と、組織全体の品質文化づくりに挑戦していきたいと考えています。
E2Eテストだけでなく、ユニットテスト・統合テストなどの幅広い自動化レベルを理解し、「テスト自動化全体を設計・支援できるQA」を目指したい。

そしてもうひとつは、人と技術・人と人を繋ぎ、「品質を支える文化」を広げ育てること。
テスト自動化やプロセス改善といった仕組みは、最終的には“人の意識”に支えられています。
仕組みや経験がチームの枠を超えて共有されるようになった時、組織はもっと強く、もっと柔軟になると思うのです。

挑戦を見守る文化でありますように

横断支援という新しい挑戦を通じて感じたのは、挑戦そのものを認め、見守る空気がある組織は強いということです。

もしあなたの周りにも、「新しいやり方を試したい」と手を挙げる人がいたら、どうか拒まず、まずは見守って、応援してあげてほしい。懐疑的な気持ちが浮かんできたら、そのネガティブな気持ちを一度捨てて直接対話をしてほしい。
その一歩が、チームや組織全体の品質文化を豊かにしていくはずです。

私自身も、これからまた新しい挑戦をしていく中で、同じように見守ってもらえるような存在でありたいと思います。

おわりに

QAという仕事は、誰かが作ったロールモデルに沿うだけでなく、自分自身の「好き」と「得意」を起点に、新しいキャリアを描いていけると信じています。

この記事が、同じようにキャリアに悩んでいる誰かにとって、「こういう形もありかも」と思える小さなきっかけになったら嬉しいです。

脚注

1. MagicPodの分析ダッシュボードについては、MagicPodヘルススコアの全社統合分析用ダッシュボードを作成してみた という記事で詳細を公開しています。
   この記事の公開後、ダッシュボードにクラウド端末の利用台数推移情報を追加し活用が広がっています。

2. 削減した工数は、自動テスト導入により新たに発生する「テスト結果分析」「自動テストのメンテナンス」に充てています。さらなる手動テスト工数の削減と、新たに発生した2つのタスクの自動化・効率化が現在の課題です