こんにちは！みなさん、テストしてますか？ 第2回の前編 では、E2Eテストの基幹部分とも言える 要素探索 の技術の変遷について扱い、 中編 では 実装 の技術の変遷について扱いました。 後編では、どのようにブラウザを介してWebアプリケーションを自動操作するのか、つまり 自動操作技術 について触れたいと思います。また、UIを自動操作して実施するテストという点から、E2Eテストには良くも悪くも様々な目的が期待されてしまっていましたが、これらはWebアプリケーション開発技術の変遷と共に徐々に変わってきました。こうした E2Eテストの目的 についても触れたいと思います。 記事一覧：モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 自動操作技術の変遷 さて、この連載では一貫してPlaywrightを使っています。PlaywrightはいわゆるE2Eテストフレームワークですが、大きく分けると「Webブラウザを自動操作するコンポーネント」と「自動テストを記述するコンポーネント」で成り立っています。 このうち、「自動操作」のほうには様々な変遷がありました。あまりに古いものは自分も良く知らない部分が多いので、おおむね2016年以降の主要なマイルストーンについて記載します。 Selenium 3 と Webdriver CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 開発者体験を重視したツールの流行 Selenium 3 と Webdriver Seleniumは、2025年現在で利用できるものの中では、もっとも歴史の長いブラウザ自動操作ライブラリです。複数のブラウザを統一されたAPIで自動操作できる、というのが強みで、たくさんのテストケースをたくさんのブラウザインスタンス上で実行するためのインフラも用意しています。 クロスブラウザの複雑性をライブラリ側で吸収するというアイディアと、ブラウザとSelenium Serverの中継ぎをするWebDriver部分は仕様を公開して各ブラウザベンダーに実装を任せるという思想そのものは良かったのですが、自動テストインフラの複雑さを招くことにもつながり、インフラの構築やメンテナンス、テスト実行時のトラブルシューティングなどの別の辛さを招いてしまうことも多かったです。 加えて、Selenium WebDriverの（少なくとも当時の）設計思想は「UI上で実際にユーザーが可能なインタラクションを模倣する」というものだったため、テストのためのモック/スタブを作りにくかったり、ネットワークスロットリングなどで特殊な環境を再現した上でのテストが難しいという弱点もありました。 また、仕組み上全てがHTTPベースのコミュニケーションになってしまう点もパフォーマンス上問題になるケースが多く、特にページロードや要素の表示待ちなどが非常に長くなるケースがありました。当時E2Eテストに「不安定」「遅い」という印象を持っていた人たちは、おそらくこれらに苦しめられたいたことでしょう。 一方で、色々と問題はありつつも、自動テストのための大統一APIを作るというビッグピクチャーに向けて今もなお前進し続けているプロジェクトであることは疑いの余地はなく、自動テストエンジニアとして生きるならぜひ動向を追い続けたいプロジェクトの一つです。 ちなみに、HTTPベースの単方向通信しか出来なかったのを改善するために、新しくWebDriver BiDiという仕様が策定されています。こちらについては後述します。 CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 ChromeがHeadlessモードをサポートしたことと、CDP（Chrome DevTools Protocol）をテストに使うことでSeleniumの弱点をカバーできると考えて、CDPをベースにしたハイレベルAPIを実装したのがPuppeteerです。当初はCDPを使っていたのですが、現在は後述するWebDriver BiDiを用いています。 Seleniumがあくまでユーザーに出来る操作のみにフォーカスしていたのに対し（参考： Selenium使いのためのPuppeteer解説｜Qiita ）、PuppeteerはCDPを用いるためネットワーク速度のスロットリングやスタブなど様々な開発者向け機能に対応しており、テストしやすさを改善していました。 一方で、Seleniumユーザーたちの多くがJavaやPythonなどでテストコードを書いていたのに対して、PuppeteerはJavaScriptのみの対応でした。これは普段UIを扱うフロントエンドエンジニアたちには自然だった一方で、JavaScriptの非同期APIに慣れ親しむ前の自動テストエンジニアたちにとってはかなり悩みのタネで、筆者も「自動テストスクリプトが順番通りに動いてくれない……おれはただテストを自動化したいだけなのに……」と毎日悪戦苦闘していたのを覚えています。 ちなみに、パフォーマンスの点について公平のために補足しておくと、Chrome/Chromiumブラウザの自動操作を担うWebDriver実装であるChromeDriverもまたCDPベースで実装されています。ですが、やはりWebDriver自体の通信がHTTP通信であることによるオーバーヘッド自体が大きかったため、速度の面でPuppeteerの方が有利でした。 また、SeleniumとPuppeteerの大きな違いとして、Selenium Gridのような大規模テストインフラを構築する機能の有無がありました。これは大量の実機テスト実行環境を束ねる目的では重要なのですが、CI/CD環境の中でChromiumをインストールしてテストを回すようなケースではそもそも不要なものでもありました。 開発者体験を重視したツールの流行 Cypress さて、Puppeteerの登場で、あくまで筆者の肌感ではあるものの、自動テスト界隈の人気は二分された印象がありました。 テストコードが書けるたくさんのテストエンジニアを中心にたくさんの自動テストを実行したい→Selenium 開発者が日常の開発サイクルの中でガンガンE2Eテストを回していきたい→Puppeteer そうすると、開発者はどうしても 開発者体験 の良さに目が行ってしまいます。例えば、ドキュメントが豊富であるとか、コードが書きやすいとか、デバッグ用のツールキットが充実しているとか、普段の開発エコシステムの中に組み込みやすいとか、そういった具合です。 そんな中で登場したのがCypressです。Cypressははフロントエンドの開発体験をウリにしたツールで、当時の開発者たちが慣れ親しんでいたjQueryのメソッドチェーンを踏襲した書きやすいAPI、フロントエンドエコシステムとの親和性、デバッグ体験の良さなど、良いところがたくさんありました。 一方で、仕組み上複数タブ・ウィンドウの切り替えが出来ないことや、クロスドメインiframeがテストできないことなどは、テスト対象のウェブサイトによっては致命的でした。ちなみに、Cypressのドキュメントは本当に徹底していて、これらのトレードオフまでつまびらかに解説されています。 Cypress docs： https://docs.cypress.io/app/references/trade-offs こうした課題はありつつも、上述した開発者体験の良さ、ならびにこうしたトレードオフまで充分に解説されたドキュメントなどは非常に開発者フレンドリーで、多くの開発者たちに親しまれていました（余談ですが、筆者はあるオンラインカンファレンスでCypressの中の人が「ドキュメントが充実しているのもCypressのいいところで、困ったことがあったらCommand+Kで一発で検索できる」と誇らしげに語っているのを見て、とても良いことだなと感心した覚えがあります）。 Playwright さて、Cypressのメジャーリリースとほぼ同時期に、本連載でも使っている Playwright がα版として産声を挙げました。自動操作の方法としてはPuppeteerが使っているCDPというものになるのですが、この方法は名前の通りChromium系のブラウザ（Chrome、Chromium、Edge）でしか使えないので、FireFoxやSafariはテスト用にビルドしたものを使っています。 個人的には非常にバランスの取れた、良い意味でいいとこ取りのツールだと捉えています。開発者体験の観点からCypressと人気を二分していましたが、その後Cypressと似た機能を取り入れることでより強力なツールになりました。 余談: Selenium4・Webdriver-BiDi 冒頭で紹介したSeleniumですが、何となくオワコンのように見えてしまいがちですが、きちんとメンテナンスされ続けており、2022年には待望の新メジャーバージョンが登場しました。本記事のPuppeteerの項目で「PuppeteerはCDPを直接触れるのでテストが楽」というようなことを書きましたが、Selenium4は待望の cdp エンドポイントが実装され、ブラウザによりますがCDPによる豊富なデバッグ機能にアクセスできるようになりました。 また、Seleniumの根幹となるWebdriver規格も進化しており、新たにWebdriver-BiDiというものが提案されています。BiDiはBiDirectional、つまり双方向の略です。SeleniumがHTTPベースの単方向通信のみのツールだったのを、Webdriver-BiDiはWebsocketベースの双方向通信のものに変えています。これにより、ページの表示待ちなどのパフォーマンスが改善しました。 Puppeteerの話の中で触れたとおり、現在PuppeteerはCDPベースからWebdriver-BiDiベースに変わっています。これがより進んでいくと、クロスブラウザテストのやりやすさはより高くなっていくはずです。 目的/役割の変遷 さて、この「E2Eテストの歴史」は、主にE2E自動テストで使われる技術の変化にスポットを当てることで、「本/記事によって書いてあることが全然違う」という状態を解きほぐすことを目的にしていました。締めくくりとして、これらの技術が何に対して使われるのかの変遷についても理解しておきましょう。 手続き的UIの時代: UIテスト = E2Eテスト JavaScriptによるインタラクティブな表現が可能になった直後のWebアプリケーションは、UIの変化をDOMツリーの操作によって行っていました。例えば、以下のサンプルは簡単なToDoアプリの実装です。ページ全体を読み込み直すことなく、ToDoアイテムの追加/削除のタイミングでデータをバックエンドサーバーに送信しています。 <div id="todoApp"> <input type="text" id="todoInput" placeholder="新しいタスク"> <button onclick="addTodo()">追加</button> <ul id="todos"></ul> </div> <script> function addTodo() { const text = $('#todoInput').val(); if (text) { // バックエンドにPOST送信 $.post('/api/todos', {text: text}, function(todo) { // 成功時にDOMに要素を追加 $('#todos').append(`<li data-id="${todo.id}">${todo.text} <button onclick="deleteTodo(${todo.id})">削除</button></li>`); $('#todoInput').val(''); }); } } function deleteTodo(id) { // バックエンドにDELETE送信 $.ajax({ url: `/api/todos/${id}`, method: 'DELETE', success: function() { // 成功時にDOM要素を削除 $(`li[data-id="${id}"]`).remove(); } }); } </script> DOMツリーを直接編集するということは、状態を再現させるためにはそこまでの手続きを再現させなければいけないということでもありました。再現させるためにはバックエンドも（データベースなども含め）完全なものを準備する必要があるため、必然的にUIテスト=E2Eテストという構図が生まれていました。 宣言的UIの時代: UIテストとE2Eテストの分離 一方、Reactに代表される宣言的UIフレームワークは、「状態を引数として受け取り、UIを返却する」関数としてUIを定義しています。同じToDoアプリをReactで書くと以下のようになります。 function TodoApp() { const [todos, setTodos] = useState([]); const [inputText, setInputText] = useState(''); const addTodo = async () => { if (inputText) { const response = await fetch('/api/todos', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({text: inputText}) }); const newTodo = await response.json(); setTodos([...todos, newTodo]); setInputText(''); } }; const deleteTodo = async (id) => { await fetch(`/api/todos/${id}`, {method: 'DELETE'}); setTodos(todos.filter(todo => todo.id !== id)); }; return ( <div> <input value={inputText} onChange={e => setInputText(e.target.value)} placeholder="新しいタスク" /> <button onClick={addTodo}>追加</button> <ul> {todos.map(todo => ( <li key={todo.id}> {todo.text} <button onClick={() => deleteTodo(todo.id)}>削除</button> </li> ))} </ul> </div> ); } これにより、状態を再現させるための手続きを踏まなくても、特定の状態をテストできるようになります。 また、特徴的なのがUIをいくつかのコンポーネントのまとまりとして構成しており、各コンポーネントを分けてテストすることも可能である点です。子コンポーネントたちも親と同様に状態を受け取る関数として定義されているので、コンポーネントごとに状態を変えられるようになりました。 同時に、WebフロントエンドのビルドはバックエンドのWebアプリケーションフレームワークと別のフレームワークが担当することも増え、フロントエンドUIのみを分離してテストする傾向が増えてきました。その結果、純粋にUIの挙動だけをテストしたい場合はUIコンポーネントテストで済ませ、バックエンドとの統合における不具合の検知やCUJ（クリティカルユーザージャーニー: もっとも重要なユーザー導線）をE2Eテストで守る、という考え方が広まってきました。 まとめ この後編では、自動操作技術の変遷と、E2Eテストの目的の変遷について、流れを追う形でまとめてみました。 第2回はこれで終わりです。続く第3回では、E2Eテストが他のテストレベルとどう違うのか、どのような目的で行われるのか、どのように使い分けるべきなのか、などについて深堀りしていきたいと思います。 【連載】モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 The post 【第2回・後編】E2Eテストの歴史 – 自動操作技術と目的の変遷 first appeared on Sqripts .

QA担当としての業務が、単なるテスト実行の繰り返しに留まっていないでしょうか。 急成長する組織や複雑化するプロダクト開発の現場において、QAの役割は「不具合を見つける」ことから「品質を設計・保証する仕組みを作る」ことへと大きく変化しています。 特にメガベンチャーのような規模では、各チームの部分最適から組織全体の全体最適へと視座を引き上げることが、キャリアアップの決定的な鍵となります。 現場と経営層の板挟みに悩みつつも、属人化を排除し、持続可能な品質体制を築くことは、QAマネージャーとしての真の手腕を証明する絶好の機会です。 そこで今回はQA担当が将来的な市場価値を高めるために知っておくべき役割の再定義から、具体的なキャリアパスの分岐、習得すべきスキル、そしてキャリアアップを具現化するための実践的なステップまでを詳しく解説します。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼強いテストチームの構築方法についてはこちら▼ 最強のテストチームを作る！ チームワークでソフトウェア品質を向上させよう！ QA担当のキャリアアップを考える前に知っておくべきこと QA担当（QAエンジニア）の役割と価値の再定義 QA担当としてのキャリアを一段階引き上げるためには、まず自身の役割を再定義することが重要です。 単に指示されたテストケースを消化し、不具合を見つけるだけのテスト実行者は、品質管理（QC）の範疇に留まっています。 一方で、メガベンチャーなどの複雑な開発環境で求められるQAエンジニアの本質的な価値は、プロダクト全体の品質を設計し、保証する仕組みを構築することにあります。 例えばクロスブラウザテストとは何かを理解した上で、それをどのフェーズでどの程度自動化し、どのブラウザを優先すべきかといった戦略を立てる能力が求められます。 テスト実行という点（ボトムアップ）の活動から、品質保証という面（トップダウン）の活動へと視座を移す必要があります。 不具合を出す前の工程でいかに品質を担保するかという上流工程への関与や、開発チーム全体の品質意識を向上させる働きかけこそが、現代のQA担当が担うべき真の役割です。 この役割の変化を正しく理解し、実行に移すことが、専門性を武器にしたキャリア形成の第一歩となります。 なぜ今、QAのキャリアアップが重要なのか プロダクト開発の高度化とリリースサイクルの短サイクル化が進む現代において、QAの存在感はかつてないほど高まっています。 マイクロサービス化が進むメガベンチャーの現場では、単一のプロダクトをテストするだけでは不十分であり、サービス間の連携や全体の整合性を俯瞰して見る視点が不可欠です。 これに伴い、QA人材の市場価値は今、劇的に二極化しています。 従来のような手動テストのみを繰り返す層と、自動化技術を駆使しつつ組織的な品質戦略を立案できる層との間に、待遇や重要度の大きな開きが生じているのです。 例えば、クロスブラウザテストとはデバイスやOSの多様化への対応そのものであり、これを場当たり的な検証ではなく、持続可能なパイプラインに組み込める人材は非常に貴重です。 開発スピードを落とさずに品質を維持・向上させるという、一見相反する命題を解決できるQAエンジニアは、経営層からも開発現場からも信頼される中核的な存在となります。 市場から求められる要件が高度化している今だからこそ、自身のスキルとキャリアを戦略的にアップデートしていくことが生存戦略として不可欠になっています。 QA担当のキャリアは「狭い」のではなく「分岐が多い」 QAのキャリアパスは、しばしば開発エンジニアに比べて狭いと誤解されがちですが、実際には非常に多様な分岐が存在します。 組織の規模が拡大するメガベンチャーにおいては、特にその傾向が顕著です。 まず品質の全体最適を追求するマネジメント職への道があります。ここでは、各チームのテスト方針を統合し、組織全体の品質基準を策定するリーダーシップが求められます。 次に、特定の技術領域に特化する専門職の道です。テスト自動化のアーキテクチャ設計や、セキュリティ、パフォーマンス、さらにはクロスブラウザテストとは切っても切り離せないフロントエンドの互換性検証など、深い技術的知見を武器にします。 そして、プロダクトの仕様策定段階から品質の観点で介入し、ユーザー体験の向上に寄与する品質推進リードのような横断的な役割も重要性を増しています。 これらの道は決して独立しているわけではなく、自身の志向や組織のフェーズに合わせて柔軟に選択し、時には組み合わせていくことが可能です。 QAという軸を保ちながらも、その周辺領域へと影響範囲を広げていくことで、唯一無二のキャリアを築くことができます。 キャリアアップ＝転職だけではない キャリアアップと聞くと即座に転職を想起しがちですが、現在の組織内での役割拡張も有力な選択肢です。 特に基盤が整いつつあるメガベンチャーにおいては、社内での影響範囲を広げることで、転職以上の経験と実績を得られるケースが多々あります。 例えば現場と経営層の橋渡し役となり、品質向上がいかに事業利益やコスト削減に直結するかを数値で示す活動などが挙げられます。 属人化しているテストプロセスを標準化し、誰でも高い品質でクロスブラウザテストとは何かを意識せずに実行できるような自動化基盤を導入することは、組織全体への大きな貢献となります。 このように「目の前のテストを回す」状態から「組織が自走して品質を高める仕組みを作る」状態へとシフトすることは、社内評価を飛躍的に高めるだけでなく、将来的な市場価値の向上にも直結します。 現場のストレスを仕組みで解決し、持続可能な品質体制を築くプロセスこそが、QAマネージャーとしての真の手腕を問われる場です。 今の環境を自らの設計思想を試すフィールドとして捉え直すことで、社内にいながらにして大きなステップアップを実現できます。   QA担当の代表的なキャリアパスと到達イメージ マネジメント志向のキャリアパス QAマネージャーや品質推進リーダーとしての道は、個別のテスト実行から組織全体の品質戦略へと視座を移すキャリアです。 メガベンチャーのような規模の大きな組織では、単に不具合を見つけるだけでなく、いかに開発スピードを落とさずに品質を担保し続けるかという全体最適の視点が不可欠です。 例えばモダンなWebアプリケーション開発において避けられない課題であるクロスブラウザテストとは、単なる表示確認ではなく、ユーザーの利用環境の多様性に対するリスクヘッジそのものです。 マネジメント職には、どのブラウザまでをサポート範囲とし、どの程度の工数を割くべきかといった投資対効果の判断が求められます。 品質方針の策定やチームビルディング、さらには経営層に対して品質が事業にもたらす価値を論理的に説明する役割を担います。 現場と経営の板挟みに悩みつつも、属人化を排除し、持続可能な品質保証体制を構築することに達成感を見出す人にとって、非常にやりがいの大きなパスとなります。 品質を軸に組織の文化そのものを変革していくことが、このポジションの最終的な到達イメージです。 スペシャリスト志向のキャリアパス 技術的な専門性を極め、エンジニアリングによって品質課題を解決するのがスペシャリストの道です。 テスト自動化エンジニアやSDET（Software Design Engineer in Test）がその代表例です。 ここでは、手動で行っていた検証作業をコードによって効率化し、CI/CDパイプラインの中に組み込む高度なスキルが重視されます。 クロスブラウザテストとは、本来であれば膨大な工数がかかる作業ですが、PlaywrightやCypressといったツールを駆使し、クラウド上のテスト基盤と連携させて自動で検証を回す仕組みを構築するのがスペシャリストの腕の見せどころです。 さらに、パフォーマンス改善やセキュリティ診断、アクセシビリティの担保といった非機能要件のテスト設計においても、深い知見を発揮することが求められます。 特定の技術領域において「この人に聞けば間違いない」という信頼を勝ち取り、技術選定からアーキテクチャ設計までをリードする存在を目指します。 現場の技術的課題を直接的に解決し、開発効率を劇的に向上させることで、プロダクト価値を底上げするプロフェッショナルとしての地位を確立できます。 横断・発展型キャリアパス QAで培った「顧客視点」と「リスク管理能力」を武器に、プロダクトマネージャーやDevOpsエンジニアといった隣接領域へ進出する道も注目されています。 品質保証の知見は、プロダクトの仕様を策定する上流工程で非常に強力な武器となります。 例えば、企画の段階でクロスブラウザテストとはユーザーの利便性を公平に保つための投資であると定義し、ブラウザ間の挙動差を考慮した設計を早期に促すことで、リリース直前の手戻りを防ぐことが可能です。 またQAコンサルタントとして外部から企業の品質改善を支援したり、組織横断で品質基盤を整備する役割を担ったりすることもあります。 品質を「守り」ではなく「攻め」の要素として捉え、プロダクトライフサイクル全体を俯瞰して価値創出の中核を担うことが、このパスの魅力です。 QAの枠を超えて事業成長に直接コミットする経験は、キャリアの選択肢を大きく広げることにつながります。 開発・運用・ビジネスの各側面から品質を捉え直し、組織全体の競争力を高めるリーダーシップを発揮することが期待されます。 フリーランス・外部人材という選択 高い専門性を身につけた先には、特定の企業に属さずにフリーランスや外部顧問として活躍する道も開けます。 急成長中のスタートアップや、品質体制の立て直しを迫られている企業において、即戦力としての知見を提供します。 外部人材に求められるのは、単なるテスト実行の代行ではなく、現場が抱える課題に対する具体的な解決策の提示と実行力です。 クロスブラウザテストとは何か、どのようなツール構成がプロジェクトに最適かといった技術的な助言から、テストプロセスの標準化まで、短期間で目に見える成果を出すことが求められます。 この選択肢には、多様なプロダクトに関わることで知見が加速度的に蓄積されるというメリットがある一方、常に最新の技術動向や海外の事例をキャッチアップし続ける自己研鑽が不可欠です。 自分のスキルが市場でどのように評価されるかを冷静に見極め、特定の領域で突き抜けた価値を提供できる水準に達している必要があります。 自由な働き方と高い報酬を追求すると同時に、自身の名前だけで仕事を勝ち取っていくプロフェッショナルとしての覚悟が問われるキャリアパスと言えます。 キャリアアップのために身につけるべきスキルと経験 技術スキル：QAの市場価値を押し上げる要素 QA担当が市場価値を高めるための技術スキルの核は、単なるテスト実行を超えた「テスト設計力」と「レビュー力」にあります。 不具合が発生しやすい箇所を論理的に分析し、効率的かつ網羅的なテストケースを導き出す力は、属人化を防ぎ組織の品質水準を安定させる基盤となります。 特にマイクロサービス化が進むメガベンチャーの環境では、個別のプロダクトだけでなく、サービス間の複雑な連携を考慮したシナリオ設計が求められます。 また、テスト自動化やCI/CDへの組み込み、品質の可視化といったエンジニアリングスキルも欠かせません。 例えば、Webフロントエンド開発において不可欠なクロスブラウザテストとは、多種多様なブラウザやOS環境での挙動を一貫して検証することですが、これを手動で行うのは非効率の極みです。 最新のツールを駆使して自動化基盤を構築し、開発パイプラインの中で継続的に実行できる仕組みを整えるスキルは、開発スピードと品質を両立させる強力な武器となります。 アジャイルやDevOpsといったモダンな開発プロセスを深く理解し、品質保証を開発サイクルの一部として最適化できる人材は、技術的な専門性を持ったリーダーとして高く評価されます。 非技術スキル：キャリア分岐を生む力 QAマネージャーやリーダーとしてキャリアを飛躍させるのは、技術力以上に非技術的なスキル、いわゆるソフトスキルです。 現場と経営層の板挟みになりやすい立場では、単に不具合を指摘するのではなく、プロダクト全体の価値を最大化するための「課題発見力」と「改善提案力」が重要になります。 ステークホルダーとの合意形成も不可欠な要素であり、開発者やプロダクトマネージャー、経営層と共通の言語で語り、品質目標とビジネスゴールの整合性をとる力が求められます。 例えばリリース速度を優先すべき場面と、品質を最優先すべき場面を冷静に判断し、周囲を納得させる交渉力が必要です。 さらに、チームの育成やナレッジの展開といった横断的な視点も欠かせません。 属人化したスキルを組織全体の知見へと昇華させ、持続可能なチームを作る能力は、マネジメント職としての評価を決定づけます。 クロスブラウザテストとは技術的な課題であると同時に、どの範囲まで検証コストをかけるかという経営判断の側面も持ちます。 こうした多角的な視点を持って意思決定に関与し、組織の文化そのものを品質重視へと導く力が、専門職から経営に近いリーダー層への分岐を可能にします。 経験の積み方がキャリアを左右する キャリアを停滞させないためには、日々の業務の中で「作業」から「設計・判断」へと役割を意識的に広げていく経験の積み方が重要です。 ルーチン化されたテスト実行に終始するのではなく、なぜそのテストが必要なのか、コスト対効果は妥当かといった上流工程の判断に積極的に関与することが求められます。 特に急成長するメガベンチャーでは、複数のプロダクトやチームが並走しているため、プロジェクトを横断した品質改善活動への関与が大きな成長機会となります。 一つのチームでの成功事例を他チームへ水平展開し、組織全体の品質基準を底上げする経験は、全体最適を実現するプロフェッショナルとしての確固たる実績になります。 例えば全社共通のテスト基盤を構築したり、クロスブラウザテストとは何たるかを定義した共通の検証ガイドラインを策定したりする取り組みは、組織全体への影響力が大きく、社内評価と市場価値の両方を高めます。 場当たり的な修正ではなく、仕組みとしての品質向上を主導し、手戻りの少ない開発体制を築いた経験を積み重ねることで、QAとしての存在感を価値創出の中核へと昇華させることができます。 資格・学習はどう位置づけるべきか 学習や資格取得は、単なる知識の習得ではなく「キャリアの証明」や「共通言語の獲得」として戦略的に活用すべきです。 ISTQBやJSTQBといった資格は、テストエンジニアとしての体系的な知見を保有していることを客観的に示す指標となります。 メガベンチャーのような多様なバックグラウンドを持つメンバーが集まる組織では、国際的な標準に基づいた用語や概念を理解していることは、円滑なコミュニケーションを支える重要な土台になります。 しかし資格取得そのものを目的にするのではなく、それをいかに実務の課題解決に結びつけられるかが本質です。 例えば、テスト設計の技法を学ぶことは、網羅性を保ちつつ無駄を省いた効率的なテスト計画を立てる力に直結します。 また、最新の技術トレンドや海外のQA事例をチェックし続ける姿勢も重要です。 クロスブラウザテストとは時代とともに最適な検証手法やツールが変化し続ける領域ですが、常に最新の知見を取り入れることで、自身の設計が「正しい方向を向いている」という確信を持つことができます。 学んだ知識を現場のボトルネック解消に適用し、その成果を具体的な実績として示すことで、キャリアアップのスピードは加速度的に高まります。 QA担当がキャリアアップを実現するための実践ステップ 自身のキャリアタイプを見極める QAとしてのキャリアを次のステージへ進めるためには、まず自身の適性と志向が「マネジメント型」「専門型」「横断型」のいずれに近いかを整理することが不可欠です。 マネジメント型は、チームの統括や品質戦略の立案、予算管理などを通じて組織全体の出力を最大化する道です。 専門型は、SDET（Software Design Engineer in Test）のように、テスト自動化やパフォーマンス改善、セキュリティといった特定の技術領域で深い専門性を発揮します。 そして横断型は、プロダクトマネージャー（PdM）に近い視点を持ち、開発プロセスの改善やビジネス側との橋渡しを担う、近年需要が高まっているポジションです。 例えば、モダンなWebサービス開発において「クロスブラウザテストとは」という問いに対し、マネジメント型であれば「どのブラウザをサポート対象とするのが事業上最適か」という戦略的な判断を下し、専門型であれば「最新の自動化ツールを用いて複数環境での検証をいかに効率化するか」という技術的な解決策を提示します。 横断型であれば「検証工程がボトルネックにならないよう、開発の初期段階でブラウザ間の仕様差異をどう埋めるか」を調整します。 このように、同じ品質課題に対してもキャリアタイプによってアプローチが異なるため、自身の軸を明確にすることが成長の最短距離となります。 現在地の棚卸しと不足要素の明確化 自身の目指す方向性が定まったら、次に行うべきは現状のスキルや経験、そしてこれまで出してきた成果の言語化です。 30代半ばのQAマネージャー層には、単に「テストを回せる」こと以上の市場価値が求められます。 これまでに関わったプロダクトの規模や、マイクロサービス環境下でどのような品質担保の仕組みを構築したのかを、定量的かつ具体的に整理する必要があります。 具体的には、スキルマップを用いて技術スキル、ビジネススキル、リーダーシップスキルの三側面から自己分析を行うのが有効です。 例えば、クロスブラウザテストとはユーザーの多様な利用環境を担保するための重要なプロセスですが、これを手動で行っていた時代から、いかにして自動化へ移行させ、工数を何割削減したのかといった「変化」を語れるようにします。 また、現場と経営層の板挟みでストレスを感じる場面が多いのであれば、それは「ステークホルダー間の調整」という重要な経験を積んでいる証拠でもあります。 不足している要素が「技術的な深掘り」なのか「組織設計の知見」なのかを明確にすることで、次に学ぶべき対象が自ずと見えてきます。 社内でキャリアを伸ばす場合の動き方 現在のメガベンチャー環境でキャリアを伸ばすなら、役割の拡張を自ら提案し、実績を作っていく姿勢が重要です。 個別のチーム内での「部分最適」に留まっている現状を打破し、組織全体の「全体最適」を実現するプロジェクトを主導することが、QAマネージャーとしての評価を確立する鍵となります。 例えば、プロダクトごとにバラバラだった品質基準やテスト方針を統一する、全社共通のテスト基盤を構築するといった動きです。 具体的なアクションとしては、PdMや経営層に対して「品質の見える化」を提案することが挙げられます。 不具合数だけでなく、手戻りによる損失コストやリリース速度の相関をデータで示すことで、QAをコストセンターではなく価値創出の拠点として認識させます。 例えば、クロスブラウザテストとは本来コストがかかるものですが、共通基盤化によって新機能リリースのリードタイムを短縮できることを証明できれば、強力な実績になります。 現場の課題を解決しつつ、経営的なインパクトを与える仕組みを作ることで、社内での影響力は確実に拡大し、より上位の意思決定に関与できるポジションへの道が開けます。 転職・市場活用によるキャリアアップ 社内での役割拡張が難しい場合や、さらなる高みを目指すなら、外部市場を視野に入れたキャリアアップも検討すべきです。 30代のQAマネージャーが市場で高く評価されるのは、単なる管理能力だけでなく、複雑なマイクロサービス環境における品質戦略の構築経験や、QA組織の立ち上げ実績です。 特に急成長中のスタートアップや、レガシーな体制からの脱却を図る企業では、メガベンチャーで培った全体最適の知見は非常に希少価値が高いものとなります。 年代別の考え方として、20代は技術的な幅を広げ、テストエンジニアとしての基礎を固める時期ですが、30代はそれらの知見を組み合わせて「事業にどう貢献するか」という視点が重視されます。 例えば採用面接でクロスブラウザテストとは何かを聞かれた際、単なる定義ではなく「OSやブラウザの多様化に伴うリスクを、ビジネスの優先順位に基づきいかにコントロールしてきたか」を語れることが、30代に求められるレベルです。 自身のこれまでのキャリアを、事業成長に直結する「品質戦略の専門家」として再定義し、市場のニーズと合致させることで、大幅な年収アップや裁量の拡大を伴うキャリアチェンジが可能になります。 QAキャリアを長期的に伸ばす視点 QAとしてのキャリアを長期的に持続させるためには、絶えず変化する技術トレンドと適切に向き合いながら、「品質の専門家」としての確固たる軸を持ち続けることが必要です。 AIによるテスト自動化の進化や、クラウドネイティブなインフラの普及など、QAを取り巻く技術は日々アップデートされています。 これらを単なるツールの変化として捉えるのではなく、品質保証の在り方そのものを変えるパラダイムシフトとして理解し、自身の戦略に組み込む柔軟性が求められます。 例えばクロスブラウザテストとは古くからある課題ですが、近年ではクラウド上で数千種類のデバイスを即座に呼び出し、AIが視覚的な崩れを自動検知するレベルまで進化しています。 こうしたトレンドを追い続ける一方で、時代が変わっても変わらない「本質的な価値」に目を向けることも重要です。 それは、不具合をゼロにすることではなく、ユーザーに届けたい価値を最短で、かつ高い信頼性を持って届けるための「仕組み」を設計することです。 技術を手段として使いこなしつつ、事業成長を品質の側面から支えるという強い軸を持つことで、どのような組織や環境においても替えのきかない存在として、長く活躍し続けることができるはずです。 キャリアアップの一手としてのテスト管理ツール導入 いまの現場で最初に取り組むべき改善ポイント メガベンチャーのような大規模かつ複雑な開発環境において、QAマネージャーが全体最適を目指す際にまず直面するのが、テスト資産の散逸と進捗状況の不透明さです。 多くのチームが並走する現場では、スプレッドシートやドキュメントツールで個別にテストケースが管理され、ナレッジが属人化しているケースが少なくありません。 最初に取り組むべきは、これらのテストケース管理、リアルタイムな進捗管理、そして過去の知見を共有するためのナレッジ基盤をテスト管理ツール（TMT）へ集約することです。 特に、検索需要の高い「クロスブラウザテストとは」という問いに対し、単なるブラウザ別の挙動確認という定義を超えて、複数のOSやブラウザ環境でのテスト結果を一元管理し、不具合の傾向を横断的に分析できる仕組みが重要です。 ツール導入によって、どのチームがどのブラウザで苦戦しているのか、あるいはどのテストケースが冗長なのかが可視化されます。 この可視化こそが、場当たり的な改善から脱却し、データに基づいた品質戦略を立案するための第一歩となります。 情報のサイロ化を防ぎ、誰でも必要な品質データにアクセスできる状態を整えることは、QA組織としての信頼性を高める基盤となります。 ツール導入・活用を主導するQAの価値 テスト管理ツールの導入や活用を主導することは、単なる作業効率の向上に留まらず、QA担当としての市場価値を大きく引き上げる活動です。 メガベンチャーでは、小さなプロセス改善が全社的な開発リードタイムの短縮や品質向上に繋がり、そのインパクトは非常に大きなものとなります。 ツールを導入し、運用フローを定義できる人材は、技術的な理解と組織課題の解決能力を併せ持つ「品質推進リード」として高く評価されます。 経営層やプロダクトマネージャー（PdM）に対して、品質の状況を定量的なレポートとして即座に提示できる能力は、品質を事業成長のドライバーとして位置づけるために不可欠です。 例えば、クロスブラウザテストとは本来工数がかさむ工程ですが、管理ツールの活用によって自動化結果と手動テストの進捗を統合し、リリース判定のスピードを速めた実績は、ビジネス上の明確な成果となります。 現場の板挟みにストレスを感じる立場から、データという客観的な根拠を持って開発方針に影響を与える立場へとシフトできる点が、この取り組みの真の価値です。 キャリアアップ視点でのツール選定・活用の考え方 ツール選定において、単に「操作が便利そう」という視点だけで選ぶのは不十分です。 キャリアアップを見据えたQAリーダーには、そのツールがいかに組織全体の「仕組み化」に寄与するか、そして将来の組織拡大に耐えうる拡張性（スケーラビリティ）を持っているかを軸に考える視点が求められます。 マイクロサービス化が進む環境では、プロダクトごとに個別のツールを導入するのではなく、複数プロダクト横断で品質指標を統一できるツール選定が重要です。 また活用フェーズにおいては、ツールを単なる記録媒体にせず、CI/CDパイプラインや自動化ツールとの連携を前提とした設計を行う必要があります。 例えばクロスブラウザテストとはデバイスの多様化に伴い複雑性が増し続けていますが、自動テストの結果をテスト管理ツールへAPI経由で自動反映させる仕組みを構築できれば、人的ミスを排除した強固な品質保証体制が実現します。 このように技術トレンドを汲み取りながら、属人性を排除した持続可能な品質エコシステムを構想し、実現する経験こそが、シニアなQAマネージャーに求められる専門性です。 QA担当としての次の一歩 テスト管理ツールの導入と運用が軌道に乗った後は、得られたデータを活用して「テスト効率化を成果として語れる状態」を目指すことが次の一歩となります。 単に「テストが終わりました」という報告ではなく、ツール導入前後でテストの再利用率がどれだけ向上したか、あるいは回帰テストの工数を何割削減できたかといった、事業インパクトに直結する数字を語れるようになることが重要です。 こうした成果の言語化は、QAが開発のボトルネックではなく、価値創出の中核であると社内で認識されるための鍵となります。 例えば、複雑なクロスブラウザテストとは、本来であればリリースを遅らせる要因になり得ますが、ツールによる効率化と全体最適によって、安全かつ高速なリリースを支える基盤に変わります。 自分たちの判断や設計が、プロダクト全体のスピードと品質を両立させているという確信を持つことが、QAとしての自信とキャリアの向上に繋がります。 組織の枠を超えて、他チームや外部コミュニティへ品質改善の知見を発信していくことで、QAマネージャーとしての社内外での評価はさらに強固なものとなるでしょう。 まとめ QA担当のキャリアは、決して狭いものではありません。マネジメント、スペシャリスト、あるいはプロダクトマネジメントへの横断など、多様な分岐が存在し、それぞれがプロダクトの価値創出に直結しています。 キャリアアップを実現するために最も重要なのは、日々の「作業」を「品質設計という戦略的な判断」へと昇華させる姿勢です。 例えば煩雑なクロスブラウザテストを仕組み化し、効率と品質を両立させるような取り組みこそが、組織内での評価と市場価値を確実に高める実績となります。 今回の内容を整理すると、以下の3点がキャリアアップの核心と言えます。 役割の再定義： テスト実行者から、全体最適を設計する品質のアーキテクトへ。 スキルの掛け合わせ： 高度なテスト設計力に、ステークホルダーとの合意形成力や仕組み化の視点を加える。 成果の言語化： テスト効率化や品質向上を「事業成長への貢献」として語れる状態にする。 まずは自身の現在地を棚卸しし、一つひとつの改善を仕組みに落とし込むことから始めてみてください。 その積み重ねが、経営層からも開発現場からも信頼される「品質の専門家」としての確固たる地位を築くはずです。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

はじめに こんにちは。 @Sakamoto です。 この記事は、 Merpay & Mercoin Advent Calendar 2025 の4日目の記事です。 2025年9月からメルコインでフロントエンドのインターンを始め、12月初めでちょうど3か月になりました。期間中はメルコインに加え、メルカリNFTの開発にも参加しました。 本記事では、インターン期間中に取り組んだタスクを振り返り、そこで得た学びや気づきをまとめます。 チームについて 今回のインターンではメルコインとメルカリNFTでフロントエンドエンジニアとして参加しました。それぞれ扱うプロダクトの特性が大きく異なるため、求められる視点や進め方にも違いがありました。 メルコイン 暗号資産交換業としてガバナンスやリーガルと関わりが深く、単に機能を実装するだけでなく、背景となる法律や制約を理解したうえで開発を進める必要があります。 メルコインのフロントエンドチームはお客さま対応のための社内ツールのフロントエンド開発、LP（ランディングページ） の作成などを担当しています。 メルカリNFT NFTの売買を可能にするプロダクトを持つチームで、2025年1月に提供を開始し、現在も毎週のように新機能が追加されています。 そのため、よりスピード感のある開発が求められる環境でした。 メルカリNFTのフロントエンドチームは主にメルカリNFTのフロントエンド開発を担当しています。 取り組み概要 メルコイン 社内ツールのフロントエンド改修 メルカリNFT 買取機能の実装・改善 メルカリNFTのくじをメルカリアプリ内から購入できるようにするための対応 リリース後のメモリ監視 その他 Web3領域のドメイン知識の習得 社内の多職種の方とのコミュニケーション エンジニア業務でのAI活用 ここでは太字の6つについてまとめようと思います。 社内ツールのフロントエンドの改修 背景 メルコインで進行しているプロジェクトの一部として、口座の状況、暗号通貨の配信価格など、お客さまからのお問い合わせに必要な情報を確認できる社内ツールの改修を担当し、フロントエンドの仕様整理から実装、QAチームとのテストケースの調整まで、一連の開発プロセスに関わりました。 やったこと 社内ツールの改修にあたって、 表記揺れがないか バリデーションに過不足はないか エラーハンドリングが適切か UIの整合性があるか API連携が正しいか 変更に柔軟に対応できる設計か といったポイントを確認し、後工程での手戻りが起きにくい状態まで仕様書のレビューを行いました。 その上で自分の実装スピードや改修範囲を考慮し、適切なバッファを含めて工数見積もりを行いました。 実装では、各マイクロサービス間の通信にはgRPCが使われているため、Protocol Buffersの定義からモックを作り、UIとの接続を進めると同時にCypressでのE2Eテストも作成・改修に取り組むことができました。 またQAチームとはテストケースや指摘内容を確認しながら、仕様と実装の齟齬をなくすことに努めました。 学び gRPCやProtocol Buffers、Cypressといったこれまで触れる機会の少なかった技術に取り組んだことで、フロントエンド以外の領域にも一部理解が広がりました。 あわせて、仕様書の精度をどう高めるか、どの程度のバッファを見込んで工数を組み立てるか、レビューされやすいコードにするにはどんな書き方がよいかなど、プロダクト開発全体を俯瞰する視点も身についたと感じています。 買取機能の実装・改善 背景 メルカリNFT内のGMV（流通取引総額）を伸ばすための施策として、NFTくじを購入したお客さまが買取依頼を出せる機能の追加をしました。 それに伴い、商品詳細ページに新しいUIや状態管理が必要となり、この部分の改修を担当しました。 また、このタスクがメルカリNFTのコードを触る最初の機能開発だったため、既存コードや周辺仕様のキャッチアップを素早く進める必要もありました。 やったこと 仕様書を確認し、商品詳細ページのどのタイミングで買取ボタンを表示するか、どの状態をどう見せるかといったUIの出し分けを整理しました。 その上で、実装した内容の品質を担保するためにVRT（Visual Regression Test）を活用し、Playwrightを用いたインテグレーションテストも追加・修正しました。 学び Playwrightを使ったインテグレーションテストやVRTの活用など、これまで触れる機会のなかったテスト手法を実際に使いながら理解を深められました。 また、買取前後でUIが複雑に変化する仕様だったこともあり、コンポーネントの責務をどう分けるか、保守性と可読性をどこまで両立できるか、といった設計面の学びも多かったです。 スピードが求められる環境の中でも、既存実装の調査や理解を並行して進めることの重要性を実感しました。 リリース後のメモリ監視 背景 メルカリNFTでは、サービスを安定して提供し続けるために、リリース後のリソース状況の監視や挙動の確認を継続的に行っています。 特にメモリ使用量は、トラフィックの増減や特定機能の利用状況によって変動しやすいため、定期的に観測し、必要に応じて挙動を調査する運用を行っています。 今回の取り組みでは、本番環境のメモリ使用状況をより細かく把握し、どのタイミングでどう増減しているのかを整理しながら、今後の安定した運用につなげるための調査を進めています。 やったこと まずは「いつ・どんな状況でメモリが増えるのか」を把握するために、各Podのメトリクスを確認し、傾向を調査しました。 その上で、なぜそのような増加が起こるのか仮説を立て、順に検証を進めました。 Datadogからログやメトリクスを細かく確認しつつ、他チームにも相談し、Node.jsやNext.jsの内部挙動、キャッシュやSSR周りの可能性など、さまざまな観点から情報を集めることで検証の方向性を調整しています。 学び 日々の調査の中で得られる学びは非常に多いと感じています。 Node.jsやNext.jsが内部でどのようにメモリを使うのか、CPU・GCの仕組み、キャッシュの扱いなど、技術的な理解が大きく深まりました。 同時に、進行中の問題を扱う際のコミュニケーションの取り方や調査内容のまとめ方、仮説の立て方と検証の進め方、進捗が見えにくいタスクをどうやって周囲と共有するかなど、機能開発とは異なるスキルも求められることを実感しています。 Web3領域のドメイン知識の習得 メルコインとメルカリNFTの両方に関わる中で、Web3に関する基礎知識を継続的に身につけることを意識してきました。 暗号資産やNFTの基本概念をはじめ、法規制やコンプライアンス、チェーンの仕組み、トランザクションの流れ、ウォレットの挙動など、業務に必要な知識は社内ドキュメントとして多く整理されています。 日々の開発と並行して、それらの資料を自分から探して読み、背景となるドメイン理解を深めるようにしてきました。 Web3は学ぶ範囲も広く、継続して取り組みたい領域です。 社内の多職種の方とのコミュニケーション もう一つ意識的に取り組んでいたのが、社内の多職種の方とのコミュニケーションです。 プロダクト開発では、さまざまな職種と連携しながら仕様の確定やリリースに向けた調整を進める必要があります。 そのため、日々のやり取りだけでなく、会社の施策として実施されているチービルやメンターランチの機会を活用しつつ、自分からも声をかけて1on1やランチの機会をつくるようにしていました。 チーム全体が話しかけやすい雰囲気を持っていたこともあり、積極的にコミュニケーションを取ることができました。 また、普段どのように技術をキャッチアップしているのか、どんな観点で仕様を見ているのか、なぜ今のキャリアを選んだのかといった話を聞くことで、自分の知らなかった考え方や知識に触れる機会も多くありました。 開発スキルだけでは得られない学びが多く、視野を広げるきっかけになったと感じています。 エンジニア業務でのAI活用 CursorなどのAIツールも積極的に活用し、コード全体の構造を素早く把握したり、関連部分の洗い出しを効率よく進めるようにしていました。 開発・実装では、メンターの方からのアドバイスも参考にしながら、どの情報を渡すと意図が正確に伝わるかといった点を意識するようにしました。 仕様を明確にまとめてコンテキストとしてAIに渡すことで、実装の方向性がぶれにくくなり、提案されるコードの品質も安定するようになりました。 また、AIから返ってくるコードはそのまま使うのではなく、自分の考えとの違いを確認したり、なぜその書き方になるのかを読み解くことで理解を深めるきっかけにもなりました。 結果として、実装を効率化するだけでなく、コードの設計方針を比較しながら学べる良い教材のような存在にもなっていたと思います。 まとめ 3か月を通して、メルコインとメルカリNFTのそれぞれ異なる特徴を持つプロダクトの開発に携わり、多くの学びを得ることができました。 機能実装だけでなく、仕様の詰め方、テストの考え方、多職種とのコミュニケーションなど、エンジニアとして必要なスキルを幅広く経験できた期間だったと感じています。 残りの1か月も、これまでの学びを活かしながら、より深い理解と確かなアウトプットを積み重ねていきたいと思います。 明日の記事は @Fabさんです。引き続きお楽しみください。