QAエンジニアを3年間やって感じたこと

中学校の数学教員からIT業界に転職して、約3年。開発がやりたかった私の最初の仕事は、スマホでアプリを触って確かめるQAでした。「これならプログラミングを知らなくてもできるのでは」と思った時期を経て、今は理由を挙げて「やってよかった」と言えます。開発志望だった自分の考えが、どう変わったかの記録です。

目次
  1. 「絶対に開発がいい」と思っていた
  2. 最初の仕事は、スマホでアプリを触ることだった
  3. 部長が見せようとしてくれていたもの
  4. アプリの裏側には、たくさんの仕組みがあった
  5. プログラミングスクールの勉強は、無駄じゃなかった
  6. 「動けばいいじゃん」が変わった
  7. 個人開発でも、QAをしていた
  8. 開発への憧れは、まだある
  9. コードを書くことの価値は、どう変わるんだろう
  10. これから
  11. QAを3年間やってよかった

中学校で数学を教えていた私が、IT業界に転職して約3年になります。

この3年間、ずっとQAエンジニアとして働いてきました。QAは品質保証(Quality Assurance)のことです。私が担当してきたのは、主に、作られたアプリやシステムが想定どおりに動くかを確かめる仕事でした。

ただ、正直に書くと、最初からQAがやりたかったわけではありません。転職するときは、開発がやりたくて仕方ありませんでした。

今回は、開発志望だった私が、QAを3年間やってみて、どう考えが変わったのかを書いてみます。QAとは何か、という解説ではなく、あくまで私1人の振り返りです。

「絶対に開発がいい」と思っていた

IT業界への転職を決めてから、プログラミングスクールに通いました。エディターを開いて、コードを書いて、動かしてみる。その繰り返しです。

転職するときは、「絶対に開発がいい」という気持ちが強くありました。

スクールで学んだことが、そのまま実務につながるとは限らない。それは分かっていました。それでも、作る側に回りたかったのです。

最初の仕事は、スマホでアプリを触ることだった

配属されたのは、DevOps(開発と運用をつなぎ、作ったものを素早く安定して届けるための考え方)に関わる部署でした。

部長からは、いきなりいろいろな業務を担当するのは大変だから、まずはQAとしてプロジェクトに関わってみないか、と提案されました。担当したのは、テレビCMも流れるようなアプリのプロジェクトです。

最初の仕事は、テストコードを書くことではありませんでした。開発途中のアプリを実際にスマホで操作して、想定どおりに動くか、表示が正しいかを確かめる。それが中心です。

エディターを開くことも、コードを書くことも、ほとんどありません。当時は、正直こう思っていました。

  • プログラミングスクールで勉強した意味が、ないのでは
  • エンジニアとしてのスキルが、身についていないのでは
  • スマホをポチポチ操作するだけなら、プログラミングを知らない人でもできるのでは

これが、当時の正直な気持ちでした。

部長が見せようとしてくれていたもの

部長の提案の意味が分かったのは、しばらく経ってからです。

部長は、最初から1つの機能の開発に集中するより、QAとしてアプリ全体やプロジェクト全体、業界の仕組みを見渡す経験をしたほうがいい、と考えてくれていました。今は、その配慮に納得しています。

開発に入っていたら、最初はボタン1つや、バックエンドのある部分だけを担当していたかもしれません。そうなると、「自分は何を作っているんだろう」と、全体が見えにくくなることもありそうです。もちろん、これは開発をしていない私の想像です。

一方、QAでは、会社側、店舗側、一般のお客さん側、システム管理者側の機能や画面を、ひと通り触ることができました。

QAで触った4つの立場の画面会社側、店舗側、お客さん側、管理者側という4つの立場の画面が、真ん中にある1つのアプリにつながっている。QAでは、この4つの画面をひと通り触った。会社側店舗側お客さん側管理者側1つのアプリ
QAで触った4つの立場の画面(どれも、真ん中の1つのアプリにつながっている)

同じアプリでも、使う人の立場によって、見える画面がまったく違います。お客さんが押したボタンが、店舗側や管理者側の画面にどうつながっているのか。使う人それぞれの立場と、システム全体のつながりを知れたのは、大きかったです。

アプリの裏側には、たくさんの仕組みがあった

QAをしていると、アプリの裏側も少しずつ見えてきます。

1つのアプリの中に、PayPayなどの決済サービス、利用状況を分析するツール、広告に関係するツールなど、たくさんの仕組みが組み込まれていました。データベースが、実際のサービスでどう使われているのかも見えてきました。

AWSにも触れました。実際にやった作業は、たとえばこんなものです。

  • ターミナルでコマンドを実行して、設定を変えたり、キャッシュを削除したりする
  • SQLを実行して、データベースを操作する
  • Amazon S3に置いた画像を差し替えて、CloudFrontのキャッシュを削除し、アプリの画面に出る画像を変える
  • ちょっとしたチラシやポップアップの作業で、HTMLやJavaScriptを触る

S3は画像などのファイルを置いておく場所で、CloudFrontはそれを各地のサーバーに一時保存(キャッシュ)して、速く届ける仕組みです。S3の画像を差し替えても、キャッシュが残っていると古い画像が出続けます。だから、差し替えたあとにキャッシュを消す必要がありました。ちなみに、このブログも同じS3とCloudFrontの組み合わせで動いていて、記事を出すたびに同じことをしています。

Redisに関係する操作もした記憶がありますが、何をしたのか、細かいところまでは覚えていません。

あとからプロジェクトに入ってきた、私より5〜6年ほど経験の長いメンバーには、「それはQAエンジニアの範疇を超えている」と言われたこともあります。

補足

QAエンジニアなら誰でもこういう作業をする、というわけではありません。私の場合は、部署やプロジェクトの環境が、幅広い経験をさせてくれました。

プログラミングスクールの勉強は、無駄じゃなかった

最初は「コードを書かないなら、勉強した意味がない」と思っていました。

でも、振り返ってみると、ターミナル、SQL、AWS、HTML、JavaScriptを扱う場面が、実際にありました。

まったくの未経験で、知識ゼロの状態だったら、こうした作業にもっとストレスを感じていたはずです。コードを書く仕事が中心ではなくても、基礎知識があることに助けられました。

だから今は、プログラミングスクールでの勉強は無駄ではなかったと思えます。3年前の「勉強した意味がないのでは」への、今の答えです。

「動けばいいじゃん」が変わった

以前の私は、自分でもかなり大ざっぱだと感じていました。

  • 動けばいいじゃん
  • 誤字脱字があっても、意味は分かるじゃん
  • 多少違っても、伝わるじゃん

そう考えることが多かったです。

QAを続けるうちに、こういうところに目が向くようになりました。

  • 1ピクセルほどのずれ
  • 表示が、わずかに途切れているところ
  • 仕様と違う文言
  • 意味は同じでも、指定とは違う表現

世の中に公開するものだから、きちんと確かめないといけない。その意識が身につきました。

補足

小さな違いを全部直すべき、という話ではありません。直すかどうかは、品質や影響を考えて決めることです。変わったのは、違いに気づいて、それがどれくらい大事かを考える姿勢のほうでした。

個人開発でも、QAをしていた

QAを始めて1〜2年ほど経ったころ、個人開発に取り組みました。AIが発達してきたこともあって、Vibe Coding(AIに言葉で指示して、コードを書いてもらう作り方)で、いろいろなアプリを作ってみました。

AIがコードを書いてくれるので、自分で書くコードの量は、以前想像していたよりずっと少なくて済みます。

その一方で、こういうことは自分で確かめていました。

  • AIが作ったものが、本当に要件に合っているか
  • 期待どおりに動くか
  • 違う操作のパターンでも、問題がないか
  • 端末や画面サイズが変わっても、ちゃんと表示されるか

気がつけば、個人開発でもQAエンジニアのようなことをしていました。

Vibe Codingで個人開発するときの流れ作りたいものをAIに言葉で伝える。AIがコードを書く。できたものが要件に合っているか、期待どおり動くか、画面サイズが変わっても表示されるかを自分で確かめる。違っていたら、もう1度伝え直す。最後の、自分で確かめるところが、QAの経験そのもの。言葉で伝える作りたいものを、AIにAIがコードを書く自分で書く量は、ぐっと減った自分で確かめる要件・動き・画面サイズやり直しQAの経験
Vibe Codingで個人開発するときの流れ(青磁の枠が、QAの経験が生きているところ)

AIの出力は、いつも正しいとは限りません。だからこそ、何を作るべきかを判断して、できたものを確かめる力の価値を実感しています。3年前に「誰でもできるのでは」と思っていた確認の観点が、ここで役に立っています。

このブログも同じです。記事はClaude Codeに書いてもらっていますが、中身の確認と、出すかどうかの判断は自分でしています。

開発への憧れは、まだある

開発エンジニアになりたい気持ちが、完全になくなったわけではありません。

ただ、現場では、開発担当の人が夜遅くまで残業している姿を見ることもありました。開発の仕事がみんなそうだとは思いません。私が目にした現実の1つです。

一方で、私がQAとして夜10時、11時まで働くことは、ほとんどありませんでした。

今は家族ができて、子どもも生まれました。独身のころのように、夜遅くまでがむしゃらに働くのは難しい。家族との時間と仕事のバランスを考えるようになりました。

かつて憧れていた開発エンジニアになることが、今の自分にとって本当にただ1つの正解なのか。少し悩ましく感じています。

コードを書くことの価値は、どう変わるんだろう

AIがコードを書ける範囲は、どんどん広がっています。そうなると、「コードを書くこと」そのものの価値は、これからどう変わるんだろう、と考えます。

開発エンジニアの価値が下がる、と言いたいわけではありません。設計、要件の理解、検証、運用、使う人にとって何が必要かを考えること。こうした仕事は残るし、形を変えていくはずです。

その変化の中でも、QAで得た幅広い視点や、品質を確かめる力は役に立つのではないか。今のところ、そう考えています。答えが出た話ではなく、今まさに考えている途中です。

これから

ずっとQAだけをやっていればいい、とは思っていません。

  • 開発の勉強は続けたい
  • Webマーケティングも学びたい
  • どんなアプリを作れば人が便利になるのか、どんなものが求められているのかを、考え続けたい

QAで得た経験を、これからの個人開発や新しい挑戦の土台にしていきたいです。

QAを3年間やってよかった

QAのほうが開発より優れている、と言いたいわけではありません。開発志望なら最初にQAをやるべき、という話でもありません。

ただ、希望とは違う仕事でも、経験を積んだあとに意味が見えてくることはある。それが、この3年で感じたことです。

3年前の私は、スマホを操作するだけなら誰でもできると思っていました。今は、QAを3年間やってよかったと、理由を挙げて言えます。

  1. アプリ全体を、いろいろな立場から見渡せた
  2. アプリの裏側の技術に、実際に触れられた
  3. スクールで学んだことが、無駄じゃなかったと分かった
  4. 「動けばいい」から、品質を意識するようになった
  5. AIがコードを書く時代に、確かめる力が役に立っている

最初にQAを提案してくれた部長と、幅広い経験をさせてくれた親切なメンバーには、感謝しています。

この先、開発に進むのか、別の道に進むのか。答えはまだ出ていません。それでも、この3年間が次に何をするにしても土台になる。今は、そう思っています。