経歴のスタート地点
田中悠人さんが新卒で入ったのは、業務系の受託開発を主軸にする中堅SIerだった。配属はQA部門。最初の3年はテスト設計書のレビューと手動テスト、4年目以降はSeleniumとAppiumを使ったUI自動化を担当し、社内のテスト自動化推進チームに参画した。
7年目には、自動テストの保守と新規テスト戦略の立案を任される存在になっていた。E2Eテストのフレーキーさをどう抑えるか、回帰テストの実行時間をどこまで削れるか——QAとしての引き出しは確実に増えていた。一方で、彼の書いたテストが本番までどう運ばれていくのか、その先のパイプラインは別チームの管轄で、いつも「外」から眺めるしかなかった。
最初のつまずき
違和感は、ある大型案件のリリース直前に決定的になった。E2Eテストはローカルでは安定して通るのに、CI環境では半分が落ちる。原因を追っていくと、CI側のDockerイメージのバージョン、ヘッドレスブラウザの設定、ネットワークタイムアウトの値、すべてが本番と微妙に違っていた。
田中さんはCI環境の設定ファイルを開いたが、JenkinsのGroovyスクリプトを書いた経験はなかった。GitHub Actionsについても、別チームのエンジニアが面倒を見ていて、yamlを自分で書いたことは一度もなかった。「テストが落ちる原因の半分は、テスト自体ではなく、テストを動かす環境にある」——その当たり前の事実に、彼は7年目にして初めてまともに向き合った。
テスト自動化を極めても、それを「いつ・どこで・どう動かすか」を握れなければ、品質は安定しない。QAエンジニアとして詰める範囲が、テストフレームワークの内側だけでは足りないと痛感した瞬間だった。
転機となった社内提案
翌年、田中さんは社内勉強会で「QAから見た継続的デリバリーの提案」というテーマで30分話す機会を得た。準備のために『LeanとDevOpsの科学』を読み、デプロイ頻度・変更失敗率・リードタイム・MTTRの4指標を社内データで取ってみた。結果は彼の予想以上にひどく、QAボトルネックが定量的に可視化された。
この発表をきっかけに、社長直下のDevOps推進プロジェクトが立ち上がり、QA代表として彼が参画することになった。最初の半年はGitHub Actionsの基礎を独学で詰め、テスト並列実行とジョブの依存設計を整えた。次の半年でDockerコンテナ上でのE2Eテスト実行環境を整備し、ローカルとCIの環境差分をDockerfileに集約した。
2年目には、いくつかのプロジェクトでデプロイ前後の自動回帰テストとSlack通知を組み込み、デプロイ頻度が月1回から週2回まで上がった。「テストを書く人」から「テストとデプロイを一本のパイプラインに編む人」へ、役割は明確に変わっていった。
いま振り返る選書
入口になったのは『GitHub CI/CDガイド』だ。手元のリポジトリで動かしながら学べたので、自動テストのトリガー設計まで一気通貫で実装できた。継続的デリバリーの全体観は『入門 継続的デリバリー』が体系的に整理してくれて、社内提案資料の骨子になった。
コンテナ周りは『Docker/Kubernetes実践』をリファレンスとして使い、ベースイメージの選定とマルチステージビルドの設計をここから学んだ。
大きな転機をくれたのは『LeanとDevOpsの科学』だ。指標で語る、データで語る、というスタンスを彼に植え付けた一冊で、社内の意思決定者に話を通す武器になった。最後に、QA出身の自分の足腰を強くしてくれたのは『テスト駆動開発』で、テストを「品質保証の手段」ではなく「設計の道具」として捉え直すきっかけになった。
これから挑む人へ
田中さんは、QAからDevOpsへの越境を「テスト自動化の延長線」と表現する。新しい技術領域を一から学ぶというより、テストを動かす環境とデプロイを担う環境が地続きであることに気づく旅だった。
QAエンジニアがDevOpsへ踏み出すなら、最初の一歩は自分のテストスイートを動かすCIワークフローを、誰かの手から自分の手に取り戻すことだ。yamlを1本書き切ると、視界が驚くほど開ける。テストを書ける人がパイプラインを書けるようになると、組織の品質はもう一段上のレベルに行くと彼は信じている。
田中さんはまた、QA出身者の強みを軽視するなと若手に伝える。テスト設計で培った「失敗パターンを先に想像する力」は、CI/CDの設計でもそのまま武器になる。デプロイの巻き戻し手順、ロールバック判断、フィーチャーフラグの剥がし方——これらはすべて、QAが普段考えている「もし失敗したら」の延長線上にある。新しい言語よりも、自分の中にすでにある引き出しを掘り直すことから始めればよい。
