QAの定着を阻む5つの構造と辞めさせない打ち手

苦労して採用し、時間をかけて育てたテスト担当者が、また辞めてしまった。そんな経験はないでしょうか。

ようやくテスト観点を任せられるようになった頃に退職の申し出があり、抜けた穴を残ったメンバーが埋めることになります。負荷が一部の人に集中し、その人もやがて疲弊して離れていく。採用しても定着せず、品質はそのたびに振り出しに戻ります。

多くの受託開発の現場が、この悪循環を繰り返しています。原因を個人の資質やモチベーションに求めているうちは、何度採用しても同じことが起こります。

なお本記事では、現場の慣習に合わせて、テスト担当者を含めて広く「QA／テスト人材」と呼びます。厳密にはQA（品質保証・プロセス志向の役割）とTester（欠陥を見つける役割）は別物ですが、ここでは受託現場で実際に「テストを担う人」を辞めさせない、という文脈で両者をまとめて扱います。

もう1つ、最初に切り分けておきたいことがあります。「人が採れない」採用難と、「採った人が辞める」定着の問題は、原因も打ち手も別だという点です。採用の難しさそのものについてはQAエンジニアの採用が難しい理由と対処法で扱っており、本記事はあくまで「一度確保した人材をどう辞めさせないか」に絞ります。

本記事では、QAの定着を「根性論」ではなく「仕組み」の問題として捉え直します。採用や育成そのものの話ではなく、少人数・兼任が当たり前の受託現場でPMが打てる手を、判断軸として整理していきます。

育てたQAが辞め続ける「離職の悪循環」という症状

まず押さえたいのは、テスト担当者の離職は単発の出来事ではなく、連鎖する「症状」だという点です。1人辞めたことが次の離職を呼び、負荷が偏り、品質が不安定になっていきます。

辞めるたびに品質が振り出しに戻る

テスト担当者が抜けると、その人が積み上げてきた勘所が丸ごと失われます。「この機能は過去に決済まわりで事故った」「この画面遷移は仕様が複雑で見落としやすい」といった暗黙知は、ドキュメントに残りにくいものです。

後任は同じ失敗を一度経験しないと勘所をつかめません。結果として、チームのテスト品質は人が変わるたびに一段下がり、また時間をかけて戻していくことになります。

たとえば、退職者が「毎回ここは念入りに見る」と口頭で共有していた確認箇所が、引き継ぎ資料には一行も残っていなかった、というのはよくある話です。後任は障害を一度出してから、その箇所の重要性に気づきます。失われるのは工数ではなく、判断の精度そのものです。

抜けた穴を残りが埋め、負荷集中でまた辞める

欠員が出ても案件は止まりません。残ったメンバーが穴を埋め、一人あたりの担当範囲が広がります。

特定の人に負荷が集中すると、その人の残業が増え、疲弊が進みます。やがてその人も限界を迎えて離職し、さらに残りの人へ負荷が移る。離職が次の離職を生むこの連鎖こそが、QAの定着を最も強く阻む構造です。

厄介なのは、この負荷集中が「頼れる人ほど先に潰れる」形で進むことです。仕事のできる担当者に相談や難所が集まり、その人が最初に燃え尽きる。チームの中核から抜けていくため、1人の離職でも失われる戦力は平均以上になります。

採用しても定着せず、人が育たない

穴が空くたびに採用でしのごうとしますが、入っても短期間で辞めていくため、育成に投じた時間が回収できません。教える側の負担だけが増え、チームとしての経験値が積み上がらない状態に陥ります。

さらに見落とされがちなのが、離職が「連鎖のきっかけ」を作る点です。1人が辞めた直後は、残ったメンバーの不満や不安が表面化しやすくなります。「次は自分の番かもしれない」という空気が広がると、それまで踏みとどまっていた人まで転職を意識し始めます。離職は当人を失うだけでなく、周囲の定着意欲まで静かに削っていくのです。

この悪循環を整理すると、次のような連鎖になります。

段階	起きること	次に波及すること
①離職発生	経験者が1人抜ける	暗黙知・テスト観点が失われる
②負荷集中	残りが穴を埋める	一部メンバーの残業・疲弊が進む
③品質低下	勘所のない状態で回す	バグ流出・手戻りが増える
④さらに離職	疲弊者が限界を迎える	①に戻り、連鎖が加速する

この構造は、テスト自動化の分野で語られる「負のサイクル」とよく似ています。林尚平『ソフトウェアテスト自動化の教科書』は、工数削減の圧力がテストを不十分にし、それが市場不具合を生み、対応工数がさらに次のテストを圧迫する連鎖を指摘しています。

人の離職も同じで、一度回り始めた負の連鎖は、どこかの環を断ち切らない限り自動では止まりません。個人を責めるのではなく、連鎖のどこに手を入れるかを考えることが出発点になります。まずは「今、自チームはこの4段階のどこにいるか」を確かめるところから始めてください。

なぜQAの定着が進まないのか｜離職を生む5つの構造

では、なぜテスト担当者は辞めていくのでしょうか。個人の事情はさまざまですが、受託開発の現場に共通する構造的な要因は、大きく5つに整理できます。

テスト担当者の定着が進まない背景には、次の5つの構造が絡み合っています。

#	離職を生む構造	PMが見落としがちなサイン
①	キャリアパス・将来像が見えない	「この先どうなりたい?」に本人が答えられない
②	「開発の下請け」扱いで評価されにくい	評価面談でテストの成果が話題に上がらない
③	繰り返しの手動作業ばかりで成長実感がない	毎回同じ手順書をなぞる時間が大半を占める
④	兼任・少人数で恒常的に高負荷	特定の人だけ毎回リリース前に残業している
⑤	1人体制で相談相手がなく孤立している	テスト設計をレビューする相手が社内にいない

順に見ていきます。

①キャリアパス・将来像が見えない

テスト担当者が「この会社でテストを続けても先が見えない」と感じると、キャリアを描ける場所へ移っていきます。開発者にはリードエンジニアやアーキテクトといった道筋が見えやすい一方、テスト職は将来像が曖昧なまま放置されがちです。

しかし、テストには明確な知識体系があります。JSTQBにはFoundationからAdvancedまでの資格レベルが用意され、テスト設計や管理のスキルが段階的に定義されています。「テストにも深めるべき専門性と到達段階がある」という事実は、将来像を描く材料になります。

②「開発の下請け」扱いで成果が評価されにくい

「言われた通りにテストする人」という位置づけでは、どれだけ事故を防いでも評価につながりません。防いだ障害は目に見えないため、成果が正当に認識されにくいのです。

このとき「たくさんバグを見つけた人が偉い」という単純な物差しに逃げると、かえって逆効果になります。詳しくは打ち手のところで触れますが、バグの件数だけを追うと、水増し起票や、良いコードを担当した人が損をする歪みが生まれます。

③繰り返しの手動作業ばかりで成長実感・裁量がない

毎回同じチェックリストをなぞるだけの日々が続くと、成長している実感を失います。自分の判断で工夫できる余地が少ないほど、やりがいは薄れていきます。

特に、技術力の高い担当者ほどこの構造に敏感です。学びが止まったと感じた瞬間、市場価値を保てる環境へ移ろうとします。皮肉なことに、育てば育つほど辞めやすくなる。これが手動作業に偏ったチームの抱えるジレンマです。

④兼任・少人数で恒常的に高負荷

エンジニアがテストを兼任する体制では、開発の遅れがそのままテスト期間を圧迫します。リリース直前にしわ寄せが集中し、慢性的な高負荷が疲弊を招きます。

しかも兼任者は「開発が本業でテストは片手間」と見られがちで、頑張っても評価が開発側の成果に吸収されがちです。負荷は重いのに手柄は薄い。この非対称が、兼任体制での不満を静かに蓄積させます。

⑤1人体制で相談・レビュー相手がいない

テスト担当が実質1人だと、設計の妥当性を確認し合う相手がいません。判断の孤立は不安を生み、成長の機会も奪います。

レビューがない環境では、自分のテストが十分かどうかを判断する基準そのものを持てません。「これで本当に大丈夫か」という確信のなさを一人で抱え続けることは、想像以上に精神的な消耗を招きます。

これら5つは独立した問題ではなく、互いに絡み合って離職を後押しします。1つだけ直しても効果は限定的で、構造として捉える必要があります。特に④の高負荷と⑤の孤立は同時に起きやすく、放置すると最も早く離職に直結します。

QAが辞めると失うもの｜ノウハウ流出と属人化の連鎖

テスト担当者の離職が痛いのは、単に「人手が1人減る」からではありません。その人の頭の中にしか存在しなかった知識が、まるごと社外へ流出するからです。

失われるのは、次のような資産です。

• 過去のバグの傾向と「事故りやすい箇所」の勘所
• 仕様書に書かれていない暗黙のテスト観点
• 顧客ごとの品質基準や、譲れないポイントの感覚
• 不具合を素早く切り分けるための調査の段取り

これらは手順書には残りにくく、日々の実務の中で身についていくものです。属人化が進んでいるチームほど、1人あたりが抱える知識の量が多く、離職時のダメージも大きくなります。

言い換えれば、優秀で頼れる人ほど、辞めたときの損失が大きくなる構造です。その人に集約された知識は、日々の成果を支えていると同時に、組織にとっての単一障害点でもあります。定着への投資は、この単一障害点を減らしていく保険でもあるのです。

失うものと、その影響を整理すると次のようになります。

失われる資産	復元可否	PMへの影響
過去バグの勘所・事故りやすい箇所	復元困難（経験の蓄積）	見逃し再発、品質の逆戻り
暗黙のテスト観点	部分的に復元可（要棚卸し）	テスト漏れ、後工程での手戻り
顧客ごとの品質基準の感覚	復元困難（関係性込み）	顧客期待とのズレ、信頼低下
調査・切り分けの段取り	復元可（要ドキュメント化）	障害対応の長期化

「見えない負債」を自社の数字で概算する

再採用と再育成には、目に見えないコストがかかります。求人にかかる費用と時間、面接の工数、そして入社後に戦力化するまでの育成期間。これらは数字に表れにくい「見えない負債」として、静かにチームを圧迫していきます。

この負債は、経営者や上長を動かすための「弾」にもなります。捏造した相場ではなく、自社の実数字を当てはめて概算するのがポイントです。次の式のテンプレートに、自社の値を入れて試算してみてください。

` 離職1人あたりの損失（概算） = 採用コスト（求人媒体費・エージェント費・面接工数） + 立ち上がり損失（月額単価 × 戦力化までの月数 × 生産性ロス率） `

たとえば「戦力化まで数ヶ月かかり、その間の生産性は本来の半分」といった自社の実感を、月額単価に掛けて金額に置き換えます。こうして出した損失額を、後述する自動化ツールの費用や外注費と並べれば、施策の予算は「新しい出費」ではなく「損失回避への投資」として説明できます。予算の乏しい現場ほど、この損失回避のロジックが効きます。

そして厄介なのは、属人化とノウハウ流出が悪循環を成す点です。属人化が進むほど離職ダメージが大きくなり、その穴埋めに追われてまた属人化が進む。この連鎖を断つには、知識を個人から仕組みへ移す取り組みが欠かせません。

属人化そのものをどう解いていくかについては、テスト業務の属人化を4つの層で切り分ける方法で構造的な解き方を整理しています。あわせて参考にしてください。

原因に効かせる5つの打ち手でQAを辞めさせない

ここからは具体的な打ち手です。ポイントは、前章までに挙げた5つの離職構造に、一つずつ対応させて手を打つことです。人が辞めない状態は、原因の裏返しを地道に潰していくことで作れます。

5つの構造と打ち手の対応は、次の通りです。

離職構造	効かせる打ち手
①将来像が見えない	役割と専門性を言語化し、キャリアパスを示す
②評価されにくい	予防・設計・上流貢献を多面的に可視化して評価する
③成長実感がない	単調作業を減らし、観点設計や探索的テストに裁量を与える
④高負荷で疲弊	属人化を解いて負荷を分散し、休める体制にする
⑤孤立している	相談・レビューできる関係を内外に確保する

すべてを同時に始める必要はありません。自チームで最も痛い構造から、1つずつ着手してください。各打ち手の末尾には「まず1つやるなら」の初手を添えます。

①役割・専門性を言語化し、キャリアパスを提示する

「あなたの仕事はこういう専門性で、この先こう成長できる」と言語化して伝えることが第一歩です。キャリアパスや等級の設計には、IPAのスキル標準のような公的なIT人材の枠組みが土台になります。役割と到達段階を言葉にすること自体が、本人の将来像を支えます。

失敗しがちなのは、キャリアの話を評価面談の場だけで済ませてしまうことです。査定と将来像がセットになると、本人は身構えて本音を話しません。評価とは切り離した場で、フラットに将来を聞くのが効果的です。

まず1つやるなら：次の1on1で、査定と切り離してキャリアの話を15分だけする。「この先どんなテストができるようになりたいか」を1問聞くだけでも、放置されていないというメッセージになります。

②予防・設計・上流貢献を多面的に評価する

防いだ重大バグや、リリース前に食い止めた事故を「成果」として記録し、評価の対象にします。ただし、バグの検出件数そのものをKPIにしてはいけません。件数を追うと、軽微な指摘の水増し起票を誘発し、品質の良いコードを担当した人が不利になり、そもそも「未然に防ぐ予防」が評価されなくなるからです。

見るべきは件数の絶対値ではなく、次のようなプロセス志向の貢献です。

• 上流での早期発見（設計レビュー段階で仕様の穴を指摘した など）
• テスト観点・テストケースの再利用性（他案件でも使える資産を残したか）
• 予防・レビューへの貢献（他メンバーの設計を見て事故を未然に防いだ など）

さらに、評価制度そのものはPM単独では変えられません。給与や等級は経営・人事のマターです。そこで、制度改定を待たずにPMの権限内でできる「見える化」に落とし込みます。

• 1on1で「今回あなたが防いだ事故」を具体的に言語化して本人に伝える
• 顧客報告や社内共有の場で、担当者の名前を出して貢献を可視化する
• 評価面談の前に、本人の実績メモを上長へ渡しておく

まず1つやるなら：次の顧客・社内報告で、防いだ事故を1件、担当者の名前つきで共有する。制度を変えなくても、貢献を「見えるところに置く」ことは明日からできます。

③単調な作業を減らし、観点設計と探索的テストに振る

毎回同じ手順をなぞる時間を減らし、判断を伴う仕事の比率を上げます。ここで安易に「自動化すれば解決」と考えないことが重要です。

自動化はあくまで、繰り返し作業を機械に代替させる手段であって、導入すれば即座に工数が減る魔法ではありません。林尚平『ソフトウェアテスト自動化の教科書』が「自動テストの多くは失敗する」と警告している通り、ツール導入・スクリプト保守には相応のコストと専門スキルがかかり、目的が曖昧なまま始めると保守しきれずに形骸化します。導入するなら、ROI（先ほどの損失回避の試算と並べる）・保守の担当体制・小さく始めて広げるスモールスタートを前提に据えてください。

そして、成長実感を生む軸は自動化だけではありません。むしろ自動化に依存しない次の軸のほうが、日々の裁量に直結します。

成長の軸	内容	自動化への依存
観点設計	どこを・なぜ見るかを自分で設計する	依存しない
探索的テスト	仕様の隙を狙って能動的に不具合を探す	依存しない
テスト自動化	回帰テスト等の繰り返しを機械に任せる	依存する（コスト要）

自動化は「成長機会の一例」にすぎません。まずは観点設計や探索的テストのように、本人の判断で工夫できる領域を渡すほうが、裁量とやりがいは早く戻ります。

まず1つやるなら：1つの機能について「どこを重点的に見るか」の観点設計を、手順書の作成者ではなく担当者本人に任せる。判断の余地を1つ渡すだけで、単調感は和らぎます。

④属人化を解いて負荷を分散する

特定の人に依存した状態を崩し、休んでも回る体制をつくります。負荷の偏りは疲弊離職の温床です。テストの残業が慢性化する仕組みと具体的な対処は、テストの残業を防ぐ5つの打ち手で詳しく扱っています。

失敗パターンは、ドキュメント整備を「手が空いたらやる」と後回しにすることです。忙しい現場では永遠に手は空きません。棚卸しは通常業務の一部として時間を確保しないと進みません。

あわせて、退職が決まってからではなく、平常時から少しずつ知識を移すことが重要です。退職後の引き継ぎは時間も限られ、口頭説明が中心になりがちで、暗黙知の大半が抜け落ちます。日常のペアテストやレビューを通じて、常に2人以上が同じ勘所を共有している状態を保つほうが、はるかに流出を防げます。

まず1つやるなら：主要機能を1つだけ「2人持ち」にする。メインとサブを決め、サブにも一度テストを通してもらうだけで、単一障害点が1つ減ります。

⑤相談・レビューできる関係を確保する

社内に相手がいなければ、社外の専門家を含めて壁打ちできる関係をつくります。孤立を防ぐだけで、離職リスクは大きく下がります。

まず1つやるなら：テスト設計を、開発者でもよいので誰かに15分レビューしてもらう場を1回設ける。「見てもらえる」状態をつくること自体が、孤立の解消になります。

QAの定着は、たった1つの施策で決まるものではなく、5つの構造に一対一で対応させる地道な設計です。すべてを同時にやる必要はなく、効果の高いものから着手すれば十分です。

外部の専門家を「逃がし弁」兼「レビュー相手」として使う

打ち手の1つとして、外部のテスト専門家を活用する選択肢も検討する価値があります。ここで大切なのは、外注を「人手不足の穴埋め」ではなく「定着を支える仕組み」として位置づける視点です。

外部活用が定着施策として機能するのは、主に次の2つの局面です。

• 繁忙期の高負荷を外に逃がす: リリース前の一時的な負荷集中を外部に振ることで、社内メンバーの疲弊離職を防ぐ「逃がし弁」になります
• 1人QAのレビュー・壁打ち相手にする: 社内に相談相手がいない担当者にとって、外部の専門家は設計を確認し合える相手になり、孤立を解きます

ここで重要なのは、外部活用を「一時的な人員追加」で終わらせないことです。単に手が増えるだけなら、繁忙期が過ぎればまた元の1人体制に戻り、孤立も負荷も再発します。定着施策として使うなら、外部の専門家と関わる過程で、社内にレビューの習慣やテスト観点が残るように設計することが肝心です。

ただし、使い方を誤ると逆効果になります。丸投げして社内に何も残らなければ、かえって属人化を外部に移し替えるだけになりかねません。

外部活用が定着に効く条件と、逆効果になる使い方を対比すると次の通りです。

効く使い方	逆効果な使い方
繁忙期だけ負荷を逃がし、平常時は内製で回す	常時丸投げして社内にノウハウが残らない
テスト設計のレビュー・助言を受ける	作業だけ渡し、判断も外部任せにする
外に出す作業と内に残す知見を切り分ける	何を外注したか社内が把握していない
顧客の品質基準を社内で握り続ける	品質の最終判断まで外部に委ねる

判断の軸はシンプルです。知見は社内に残し、作業の波だけを外に逃がす——この線引きを守れば、外注は属人化を再生産せず定着を後押しします。

内製と外注のどちらをどこまで使うかは、コストだけでなく残す知見の観点でも判断が分かれます。判断の物差しはテストの内製と外注を比較する判断基準で整理しているので、切り分けの参考にしてください。

定着は「仕組み」で作る｜PMが明日から着手すること

ここまで、離職を生む5つの構造と、それに効かせる打ち手を見てきました。最後に、PMが明日から動くための着手ステップを整理します。

繰り返しになりますが、QAの定着は個人の頑張りや相性ではなく、PMが設計できる「仕組み」の問題です。順序立てて手を打てば、悪循環は止められます。

着手のステップは次の3段階です。

1. 「なぜ辞めたか」を構造で振り返る: 過去の離職を個人の事情で片づけず、5つの構造のどれが効いていたかで見直す
2. 効果の高い1つから始める: すべてを一度に変えようとせず、「成果の可視化」か「負荷分散」など、自チームで最も痛い構造から着手する
3. 継続的な体制テーマとして扱う: 定着は一度の施策で終わらず、体制の見直しとして継続的に回していく

まずは、自チームの離職リスクを構造でセルフ診断してみてください。次の項目に思い当たるほど、離職リスクは高まっています。

• テスト担当者に「この先どうなりたいか」を聞いたことがない
• 評価面談でテストの成果が話題に上がらない
• 特定の人だけが毎回リリース前に残業している
• テスト設計をレビューし合える相手が社内にいない
• 担当者が抜けたら復元できない知識が頭の中にある

1つでも当てはまるなら、そこが最初に手を入れるべき環です。体制をゼロから組み直す段階であれば、QAチームをゼロから作る5つのステップも土台づくりの参考になります。

大切なのは、完璧な制度を一度に作ろうとしないことです。5つの構造のうち1つでも手を入れれば、悪循環のどこかの環が緩みます。小さな一手が次の一手を打つ余裕を生み、やがてチームは「人が定着する側」へと少しずつ反転していきます。焦らず、しかし着実に、仕組みを積み上げてください。

よくある質問

テスト担当者が辞める主な原因は何ですか

将来像が見えない、成果が評価されにくい、成長実感がない、高負荷、孤立の5つが絡み合って起きます。個人の資質より構造の問題として捉えるのが出発点です。

テスト人材の定着率を上げるには何から始めるべきですか

一度に全部を変えず、自チームで最も痛い構造を1つ選んで着手します。多くの現場では「負荷分散」か「貢献の可視化」が初手として効きます。

採用難と離職は分けて考えるべきですか

はい、別問題です。人が採れない採用の課題と、採った人が辞める定着の課題は原因も打ち手も異なります。混ぜて考えると、どちらも中途半端になります。

テストを自動化すれば離職は減りますか

自動化は繰り返し作業の代替であり、それ自体が離職を止めるわけではありません。導入・保守にコストと専門スキルがかかるため、観点設計や探索的テストなど自動化に頼らない裁量づくりと併せて進めるのが現実的です。

1人しかいないテスト担当者の孤立はどう防げますか

社内で難しければ、開発者や社外の専門家に設計を15分見てもらう場を定例化します。「見てもらえる」状態をつくるだけでも、判断の孤立と不安は大きく和らぎます。

テスト担当者のキャリアパスはどう示せばよいですか

テスト設計・テスト管理・自動化・品質全体の設計といった専門の広がりを、段階として本人に見せます。JSTQBの資格レベルやIPAのスキル標準を、社内の等級と対応づける形で示すと具体的になります。

辞める兆候を早めに察知するにはどうすればよいですか

定例の1on1を欠かさず、業務量と表情の変化に注目します。残業の増加、口数の減少、改善提案が止まるといったサインは、離職を検討し始めた初期に現れやすい変化です。数字に表れる前の違和感を拾うことが、引き留めの猶予を生みます。

テスト体制の見直しでテスト人材の負荷分散を検討されている方は、体制づくりのご相談をお寄せください。現場の状況に合わせた進め方を一緒に整理します。

次に読むならこの記事

• ITプロジェクトのコミュニケーションロス対策とは
• 炎上プロジェクトとは？失敗の兆候を見抜く方法
• 納期に間に合わない？QAアウトソーシングがリリース前の品質保証を救う理由

テストの手戻りを減らしたい方へ

テスト仕様書のExcelテンプレートを無料で配布しています。自社で整備する場合も、外部に任せる場合も、まずは型を持つところから。

テスト仕様書テンプレートを無料DL テスト代行について相談する