21
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

QAエンジニア15年の失敗と学び

Last updated at Posted at 2025-12-22

はじめに

こんにちは!KIYOラーニングでQAエンジニアをしているナカイです。
今回が初めての記事投稿となります。

QAエンジニアとして今年でちょうど15年となりました。この15年間、決して順調な道のりではありませんでした。むしろ、数々の失敗を重ね、その度に苦労しながらも、少しずつ成長してきたというのが正直なところです。

この記事では、私が経験した「失敗」に焦点を当て、そこから得た学びを共有します。
自分と同じような失敗をする人を一人でも減らしたい。そして、失敗してもあきらめなければ挽回するチャンスがあることを伝えたい。それがこの記事を書く目的です。

私のキャリア概要

まず、15年間のキャリアを簡単に整理します。

期間 所属 主な業務・経験
1-3年目 メーカー系SI企業(QA部門) ・BtoB向けパッケージソフトのテスト設計・実施
・テスト業務の基本スキル習得
4-8年目 第三者検証会社
(前半・成長期)
・ECサイト、ソーシャルゲーム、基幹システム、決済端末など多様な案件経験
・テスト計画から報告まで一気通貫の業務
・5名程度のQAチームメンバー管理
・クライアントへのテスト案件の見積・提案・新規受注
9-12年目 第三者検証会社
(後半・マネジメント期)
・複数PJの取りまとめ(10名以上のメンバー管理)
・マネジメントスキルの習得
・新規サービスのQAチームの管理
13-15年目 自社製品QA
(金融系企業→現職)
・教育サービスのテスト業務(現職)
・自動化ツール(MagicPod)のテストケース作成
・AIを活用したテスト業務(挑戦中)

失敗と挽回の物語

1. 新卒時代(1-3年目):QAとの出会い

新卒としてSE職で就職し、品質業務を知り、QA部門を志望しました。しかし、配属後の現実は厳しいものでした。

直面した課題

直面した課題
既存製品の担当経験がなく、仕様理解に苦労
ドキュメントが古く、実態と合わない
テスト設計で苦戦(範囲と粒度の判断が分からない)
「どこまでやればいいのか」が見えない不安

手探りの日々

正直なところ、明確な解決策があったわけではありません。

上司に指導を受けながら、テスト実施を繰り返す。先輩の設計を参考にしながら、自分なりに試行錯誤する。分からないことは質問し、失敗したら次に活かす。そうした積み重ねで、少しずつ仕事を覚えていきました。

月40時間ほどの残業もありましたが、残業代へのモチベーションと若さもあって何とか乗り切り、テスト業務の基本スキルを習得することができました。

転職への決意

3年目となりテスト業務をこなす中で、「もっと幅広い経験を積みたい」「様々な製品のテストを経験したい」という気持ちが強くなっていきました。そして、第三者検証会社という存在を知り、転職を決意しました。

2. 第三者検証会社 前半(4-8年目):成功体験の積み重ね

転職後は、様々な案件を担当し、テスト業務スキルを向上させ、経験値を蓄積していきました。

多様な案件経験

  • WEBサービス
  • ECサイト
  • ソーシャルゲーム
  • 基幹システム

テスト設計・実施だけでなく、「テスト計画から報告まで一気通貫の業務経験」、クライアント企業へのテスト案件への提案・新規受注と業務の幅を広げていきました。この時代はまさに成長期で毎年スキルアップしている実感があり、理想的なキャリアパスを歩んでいました。

芽生えた過信

スキルアップを実感しながら成功体験も積み重ねていたため、「なんでもできる」という自信、いや過信を持つようになっていました。

「多様なプロジェクトを通じた経験値」、「テストスキル、ビジネススキルの向上」、そして「成功体験の積み重ね」が、後の大きな失敗への伏線となっていたのです。

3. 大失敗(7年目):予兆から崩壊まで

案件概要と業務内容

これまでの実績が評価され、決済端末関連のテスト案件を担当することになり、5名程度のテストチームのリーダーを任されました。

業務内容:

  • クレジットカード、電子マネー、ポイントカード、POSレジ連携
  • 決済端末およびデータ連携のテスト業務
  • 特殊なテスト(データ疎通・カードブランドテスト)
  • クライアント側に派遣でテスト業務の取りまとめ担当

自分の問題点

今振り返ると、失敗となる種は既に蒔かれていました。

1. 「なんでもできる」という過信

今回の決済業務の経験はなかったのに、「こなせるだろう」、「今までのように今回もうまくいくだろう」という根拠のない考えがありました。これまでの成功体験から生まれた過度な自信が当時ありました。

2. 自分で業務のタスクを抱え込んでしまう

できる業務も増え、メンバーに業務を依頼するより「自分で担当したほうが早い」という考えが強かった。結果として、メンバーに依頼できる業務も自分でやってしまい、業務タスクを必要以上に抱え込んでしまっていた。

失敗の予兆

後から考えれば、危険信号は明確に出ていました。

予兆 詳細 影響
未経験領域への挑戦 決済端末のテスト業務は初めての担当 難易度が想定以上に高かった
見積もりとの乖離 事前見積りよりもテスト範囲が広い テスト項目が約1.5倍に増加
開発の遅延 開発実装の遅れが発生 テスト期間の圧迫
ドキュメント不足 一部存在せず、仕様が不透明 テスト設計の基盤となる情報が不足

しかし、当時の私は大変な状況とは思いつつも、忙しさもあり適切な対策・対応もできず業務をしていました。

過酷な状態:崩壊

月を追うごとにテスト状況は過酷となっていきました。

現場で起きたこと:

  • 開発が遅れた影響で、QAテスト期間が限られる
  • 一部あいまいな状態でテストを行う
  • 十分なテスト設計・準備が確保できずに実施
  • 不具合→テスト→デグレ発生がいくつも発生
  • 長時間の残業で冷静に判断・対応ができない

業務時間も増え、残業も常態化し、ピーク時には徹夜対応も行うようになっていました。

業務時間の状況:

  • 最大残業時間:80時間以上/月
  • 徹夜の回数:月2回

トラブルの発生

そして、恐れていた事態が起こります。

リリース後に致命的な不具合が発生し、大クレームとなりました。

自分が担当したテスト設計・実施が不十分で、不具合を見逃してしまいました。忙しさのあまり十分に時間を確保できず、不十分なテスト設計・実施をしてしまいました。

結果として人生で1、2番目に怒られる状況となり、強烈な失敗体験となりました。その失敗は今でも鮮明に覚えており、忙しいという状況がありつつも反省すべきことは多かったです。

4. 失敗から得た4つの教訓

この大失敗から、私は以下の4つの重要な教訓を得ました。よくある失敗ではありますが、それを対応しなかったり後回しにすると、トラブルが発生することを痛感しました。

やってはいけないこと なぜダメだったのか
❌ テスト範囲・スケジュールを不明確にする 認識の齟齬が生まれ、後から大きな問題に発展
❌ 認識の齟齬・仕様不明点を放置する あいまいなまま進めると、必ず手戻りが発生
❌ 自分に必要以上にタスクを抱え込む 一人でできる量には限界がある
❌ 早めに相談・エスカレーションしない 問題が大きくなってからでは手遅れ

この失敗経験は、後の挽回への布石となりました。

5. 挽回のチャンス(8年目):再挑戦

転機の訪れ

失敗の後、しばらくして別の案件を担当するようになりました。数か月後、予想外の機会が訪れました。

クライアント側のQA担当者が休職となり、再度同じ案件を担当する機会が訪れたのです。これは、失敗から挽回するチャンスと捉え、担当することになりました。

実際に行った対策

前回の失敗を活かし、やってはいけないことへの対策を徹底しました。

やってはいけないこと 実際にやったこと
❌ テスト範囲・スケジュールを不明確にする ✅ 開発側と日次で状況を共有し、変更があればすぐにアップデート
❌ 認識の齟齬・仕様不明点を放置する ✅ 不明な時点で確認を行い、こちら側から想定挙動を提示して認識を合わせる
❌ 必要以上にタスクを抱え込む ✅ 重要度・優先度を見てタスクをチームメンバーに渡す
❌ エスカレーションをしない ✅ 状況が変わった場合は情報を共有し、相談を行い、トラブルを防ぐ

結果

今回はトラブルなく完遂し、不具合もなくリリースすることができました。

リリース後数か月を経て、QA担当者が復帰し、私は新たな業務を担当することになります。この経験は、失敗してもやり直せる、挽回できるという大きな自信につながりました。

6. マネジメントでの失敗(9-12年目):正論だけでは人は動かない

順調な中の不穏な事態

第三者検証会社の後半(9-12年目)では、マネジメント業務が中心となりました。複数のサービスのテスト取りまとめを担当し、10名以上のQAメンバーを取りまとめながら業務を行っていました。

順調だと思っていたところに、新たな問題が発生します。

ある一人のメンバーを委縮させてしまいました。

10名以上のメンバーを管理する中、限られた時間で業務指示を行っていました。しかし、誤った指導方法により、メンバーに不信感を与え、委縮させてしまいました。

失敗していた指導方法と本来すべき行動

失敗していた指導方法 本来すべき行動
❌ 間違いをストレートに淡々と指摘していた ✅ 相手の立場・状況を考えて言い方を変えて発言する
❌ 限られた時間のため、指摘が中心となり、当事者が「怒られている」感覚にしてしまった ✅ 良い点を認めて、その後で指摘点や改善点を伝える
❌ これまでの経験から自分が正しいと思う対応方法・指示を中心とし、相手の意見を聞く意識が足りていなかった ✅ 相手の考えや意見をしっかり傾聴しながら、業務方法や指示を行う

メンバーからのヒアリングで上記の誤った指導方法が発覚し、当時の上司から指摘を受けました。

上司から言われた一言

「正論をかざして発言しすぎると、納得してもらうことも納得できなくしてしまい、人がついてこなくなるよ」

この言葉は、今でも強烈に残っており、マネジメントにおける自分の足りない点を痛感しました。

学びと改善

この失敗を反省して、本来すべき行動を意識しながらQAメンバーとの信頼関係を再構築していきました。

実践効果:

  • 信頼関係が深まる
  • 早期相談が増え、予防効果が生まれる

以降はQAチーム内のトラブルはなくなり、正論だけでは人は動かない。信頼関係が全ての土台という重要な教訓を得ました。

まとめ

QAエンジニアとして15年間のキャリアを振り返ると、成功だけでなく失敗も数多く経験しました。しかし、その失敗から得た教訓は、今の自分を形作っていると感じています。

15年間の失敗経験から得た学び

  1. 過信は禁物:「なんでもできる」という自信は、適切な判断を鈍らせる
  2. 早めの相談・エスカレーション:問題が小さいうちに対処する
  3. タスクの適切な分配:一人で抱え込まない
  4. 認識の齟齬をなくす:あいまいなまま進めない
  5. 正論だけでは人は動かない:信頼関係が全ての土台
  6. 失敗しても挽回できる:失敗から学び、次に活かす

失敗は決して終わりではなく、次への学びのチャンスです。

この記事が、QA業務に携わる皆さんの参考になれば幸いです。


KIYOラーニング株式会社について

当社のビジョンは『世界一「学びやすく、分かりやすく、続けやすい」学習手段を提供する』ことです。革新的な教育サービスを作り成長させていく事で、オンライン教育分野でナンバーワンの存在となり、世界に展開していくことを目指しています。

プロダクト

  • スタディング:「学びやすく・わかりやすく・続けやすい」オンライン資格対策講座
  • スタディングキャリア:資格取得者の仕事探しやキャリア形成を支援する転職サービス
  • AirCourse:受け放題の動画研修がついたeラーニングシステム(LMS)

KIYOラーニング株式会社では一緒に働く仲間を募集しています

21
15
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
21
15

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?