転職のテンサゲから始まった自動化入門 ～自動化できないQAの民から脱却～

転職って、テンションが上がる時もあれば、めちゃくちゃ下がる時もある。

私はその日、普通にテンションが下がっていた。

理由は単純で、選考に落ちたからである。

しかも、なんとなく感じていた。

「あ、自動化とかCI/CDとか、その辺が弱かったかもしれない」

でも私は、いわゆる“レガシー金融QA”側の人間だった。

勘定系。基幹系。移行。総合テスト。  
WinMerge。SQL。ドライバー。Excel。  
巨大システム。慎重リリース。夜間バッチ。

そんな世界に長くいた。

だから正直、自動化というものに対して、

「なんか強そう」
「コード強者の世界」
「自分には縁がない」

みたいなイメージを持っていた。

面接で、

「何か知っている自動化ツールはありますか？」

と聞かれて、

「ありません」

と答えた時、ちょっとだけ思った。

“あ、自分って自動化できないQAの民なのかもしれない”

でも、不思議なもので。

落ち込むと、私は逆に「理解したくなる」。

だからその日、頭痛のする頭で、自動化について聞き始めた。

---

最初は本当に呪文だった。

Playwright？  
E2E？  
CI/CD？  
hooks？  
isolation？  
冪等性？

何？？？？？

でも、「つまり何をしたいの？」で考え始めた瞬間、少しずつ繋がっていった。

---

Playwrightは、ブラウザ操作を自動化するものらしい。

つまり、

ログインして、  
ボタン押して、  
購入して、  
履歴確認して……

みたいな、一連の操作を自動でやる。

「あれ？これ総合テストの思想では？」

と思った。

E2Eは、ユーザー操作を最後まで通す考え方。

つまり、

開始  
↓  
処理  
↓  
API  
↓  
DB  
↓  
画面表示

まで含めて見る。

「あ、これ“業務成立性”を見るってことか」

となった。

さらに面白かったのが isolation。

最初、「ダンスの技？」と思った。

でも意味を聞いたら、

“テスト同士を独立させる”

という話だった。

つまり、

前のテストの残高変更に引っ張られず、  
毎回フレッシュな状態で回帰テストを回せる。

これ、めちゃくちゃ合理的では？

コードを変更した時に、

同じ条件のテストを何パターンも自動実行できる。  
壊れた場所がすぐ分かる。

しかもそれをCI/CDで継続実行する。

「なるほど、だからSaaS文化って自動化が重要なのか」

ここで、世界が繋がった。

---

私は今まで、

「自動化ができない」

のではなく、

“自動化文化の少ない場所にいた”

だけだったのかもしれない。

勘定系や基幹系は、そもそも文化が違う。

巨大で、慎重で、止められない。

だから、

SQL確認、  
差分比較、  
件数確認、  
人的レビュー、

みたいな世界になる。

でも、デジタルバンクやSaaSは違う。

継続リリース。  
API。  
小刻みな変更。  
Web文化。

毎回人力で回帰していたら、死ぬ。

だから、

PlaywrightでE2Eを作る。  
CI/CDで継続実行する。  
変更影響を高速検知する。

その上で、QAは単純確認ではなく、

“リスク分析”や“品質向上”

にリソースを使う。

ここでようやく、自動化が「怖いもの」ではなくなった。

---

もちろん、私はまだ完全に理解したわけじゃない。

DockerもGitも、まだよく分からない。  
環境構築も、多分これから詰まる。

でも、それでも。

E2EもPlaywrightも怖くない。  
CI/CDも、少しだけ読めるようになった。

私は、自動化できないQAの民ではなかった。

――ただし、これは序章に過ぎない。  
戦いはこれからだ！