70人規模プロジェクトで崩れたQAチームを立て直した方法
目次
第1章｜巨大プロジェクトの傾き始め
この案件は、総勢70名規模の大規模テストプロジェクトでした。期間はおよそ4か月、約10チームが並行して稼働し、それぞれが「テスト計画」「テスト設計」「テスト実装」「テスト実行」のいずれかを担っていました。各チームの進め方はチームリーダーに一任されていましたが、テストケースのテンプレートやテストメニューのマニュアルは事前に整備されており、全くのゼロから始める状況ではありませんでした。
体制は、全体を統括するテストプロジェクトリーダーが1名、その配下に各チームリーダーが1名ずつ配置され、さらにその下に作業員が所属します。各領域に特化したチーム構成で、毎日の会議ではリーダー陣が集まり、テスト順序の依存関係や進捗の調整を行っていました。
この話はプロジェクト開始から参画していたチームリーダー（前任者）から私（後任者）に引き継いで、どうプロジェクトを立て直したのか？と言うお話です。
この題材になるQAチームは70人の中でも、約半数で構成するプロジェクトの要になるチームです。このチームの成否でプロジェクトの結果は大きく変わります。
案件全体の概要
1.案件の要となるQAチーム
30名規模のQAチームでした。このチームは、プロジェクト全体の中でも基本的な項目チェックを大量にこなす役割を担い、量は膨大ですが難易度は比較的低めです。ただし、チームリーダーの判断力や進捗コントロール次第で成果が大きく変わるため、特に信頼できる人材が配置されるポジションでした。ポイントは、多人数をどう効率的に動かすかに尽きます。
2.スケジュールと作業の特徴
スケジュールはタイトながらも、やり方によっては余裕を作ることも可能でした。仕様変更は少ない一方で、チェック項目が膨大で、日ごとの作業配分が非常に重要です。見積もりを誤ればすぐに調整が必要となり、気づくのが遅れると取り返しがつかなくなります。調整の鍵となるのは、リーダー同士の横のつながり、全体調整を依頼できる関係性、人材の適性見極め、進捗を阻害する要因の早期把握などでした。
崩れ始めたサイン
1. 方針不一致による調整力の低下
進捗遅延の兆候として、プロジェクトリーダーとチームリーダーとの間で方針や優先順位が合わない場面が増えていきました。課題をプロジェクト内で共有せず、一部の人が抱え込みすぎることで負荷が偏り、状況を全員で改善できなくなっていきました。全体リソースが限られてくるのと、作業難易度が低いので、プロジェクト内の他のチームとの調整連携が重要になります。
2. 不具合報告と進捗の板挟み
このプロジェクトでは、毎日検出された不具合件数を開発側へ報告する必要があり、報告品質も重視されていました。しかし、この要になるQAチーム内では、もともとのプロダクトの品質が低く、不具合検出量が多く、不具合報告は時間コストが高く、得意なメンバーは希少であったため、**「進捗」と「正確で質の高い不具合報告」**のバランスが常に課題となり、現場は日々その調整に追われていました。テスト進捗と不具合報告のバランスが崩れると、進捗数値に明確な変化が現れます。
3. 手戻りの増加のロジック
進捗のノルマに焦った作業員の中には、一部のテスト判定で、仕様書確認不足や経験差から誤判定が発生し、手戻りが増加しました。こうした状況では、危険度の高い作業を誰がするかの見極めと、事前の対策が非常に重要になります。
問題が顕在化した瞬間
1.バグの多発
前任者のQAチームでは、バグが頻発し、進捗への影響が一気に顕在化しました。この段階では、チーム間の連携不足が影響し、対応スピードが落ちていました。不具合報告の経験値の高い人がいないと、この状況から抜け出すのは難しいかもしれません。
2.情報共有によるコミュニケーションコストの増加
各チームの作業員にとっては不具合の分類は複雑で、他チームとのやり取りにも時間がかかるため、情報共有が遅れたり、他のチームから報告された不具合を検証し報告する事態がしばしば発生します。大規模案件ならではのコミュニケーションコストの高さが課題でした。
3.チーム全体の機能低下
状況が悪化すると、言い争いになったりと、会議や調整の時間が増え、作業自体が止まる場面も出てきます。そうなると、チームリーダー間の情報共有がリーダーの判断で無くなったりします。そして、互いのチーム状況が把握できず、「助けて」と言いづらい空気が生まれ、調整難易度がさらに上がりました。この時点で、プロジェクト全体の機能は大きく低下していました。
このように、背景には「調整力の低下」「タスクと品質のバランス崩れ」「情報共有の遅れ」という複合的な課題が絡み合っていました。私が現場に配属されたのは、まさにこのような状況が顕在化したタイミングだったのです。
第2章｜リーダー交代と初動対応
1. 突然の交代通達
ある日、プロジェクトの方針転換として「QAチームのリーダーを交代する」という通達が私（後任者）にありました。
背景には、プロジェクトリーダーとチームリーダー間の方針の違いやコミュニケーション不全があり、双方が高い能力を持ちながらも歩調を合わせられない状況が続いていたようです。こうしたことは大規模案件では珍しくなく、特に忙しさや時間的制約が強い環境では起こりがちです。
そのタイミングで、比較的うまくチームを回せていた私に声がかかりました。正直に言えば、引き継ぎ期間はほぼゼロ。前任者からの詳細な状況共有はなく、急遽「この状態から軌道修正してほしい」という依頼を受けた形です。
その時、全期間4か月中、1か月が過ぎ、そのチームの全体の猶予は2か月でした。進捗としては3週間位ビハインドがあった記憶です。
2. 初動の判断
引き継ぎ直後の現場は、指示が全員に行き届いておらず、能力が適材適所で発揮されていない状態でした。中には役割を与えられず、取り残されてしまったメンバーもいました。
この状況を打開するため、まず私はチームの要となりそうなメンバーを集め、情報収集のための短時間ミーティングを実施しました。
この時の狙いは、進捗を立て直す前に「チームの現状を正確に把握すること」です。
3. 状況打開のためのスキルセット
情報収集を進める中で、チーム再構築に必要な役割が見えてきました。
- 進捗を確実に出せる人
- 進捗状況を判断し指示を出せる人
- 作業員からの質問を受け付けられる人
- 不具合を処理できる人
- 他チームとの横の連携に強い人
- プロジェクトリーダーと円滑に連携できる人
この役割を誰が担えるのかを洗い出すことで、チーム状況の改善策につなげられる準備を行いました。
4. 小さな成功の兆し
最初の情報収集会議では、メンバーそれぞれの特徴や得意分野を把握することができました。さらに、私自身が元々ある程度人材の適性を知っていたこともあり、初動の段階で「誰をどの役割に置くべきか」の見立てを立てられました。
この「現状把握と適材適所の仮配置」が、その後の改善策をスムーズに進めるための最初の成功要因となりました。
第3章｜改善策の設計と実行
1. 課題の核心：役割の分離不足
現状を分析した結果、前任の運営方法には大きな課題がありました。
作業者の質問受付、作業者への指示、不具合報告の処理、他チームやプロジェクトリーダーとの連携——これらをチームリーダー1人がすべて担っていたのです。
特に「作業者からの質問対応」と「不具合報告の処理」は、どちらも随時状況が変化し、頻繁な対応が必要になるため、他の役割と兼任するには相性が最悪です。これらを分離しないまま運営することは、コスト負荷を高め、進捗全体に悪影響を与えます。
2. 改善方針：負荷の集中を解消する
私の得意分野は、組織内でも希少だった「不具合報告の処理」でした。
作業者としての経験が豊富だったため、他のメンバーがどこに時間を取られるかを把握していました。そこで、まずは不具合報告の負荷を減らすことを最優先にしました。
3. 不具合報告の効率化
- 報告文のテンプレート化
作業者には、文章の上手い・下手は関係なく、とにかく報告しやすい形を用意しました。重要なのは文章の質よりも、報告が完了するまでの時間短縮です。 - 通過率の高い文章作成
過去に大規模プロジェクト全体の不具合文精査を担当した経験から、この組織で通りやすい文章やプロジェクトリーダーの判断基準を熟知していました。そのため、作業者が提出した報告文は私が集中的に整え、承認されやすい形に仕上げてから提出しました。
これにより、不具合報告の遅延は大幅に減少しました。
4. 質問対応の戦略的切り分け
質問対応については、視点を変えると「質問対応を担当する人＝進捗を直接出しにくい人」という特徴が見えてきます。そこで、
- 教えるのが得意だが進捗は出しづらいメンバーを質問受付専任にする
- 進捗を出せるメンバーが、進捗を出せないメンバーの質問対応に時間を取られないようにする
この役割分担で、進捗を出せる人材は作業に集中でき、質問対応の質も落とさず維持できる体制を作りました。もう一つ重要なのは大規模プロジェクトなので、1人あたりの進捗ノルマを事前に出すのですが、個人成績にはこだわらず、チーム全体の成績に集中します。これだけでは作業者同士の不平不満が生まれ、上手く行かなくなるので、進捗を出せる人には事前にこのくらいの数値を確保して欲しいという平均ノルマを大きく上回る目標を課し、特別な部隊だという特別感を出し、問題が発生したときには優先的に相談に乗り解決することで、多少の無理が通るように調整しました。
5. 適材適所の判断基準
多数の人材を見てきた経験から、次のような特徴が判別しやすいと分かっていました。
- 仕様を把握できる人材と進捗を出せる人材は別物
- 教えられる人材と進捗を出せる人材も別物
- 進捗を出せる人は寡黙な傾向があり、コミュニケーション頻度は低い
- 教えるのが得意だが進捗が出ない人は、逆にコミュニケーションが活発
この特徴をもとに人材配置を最適化しました。
6. 実行後の変化
改善策を実行して最初の1週間は軌道修正が難しく、数値的にもすぐには効果が現れませんでした。しかし2週間目に入ると、明らかに数値が改善し始めました。
当初の初期進捗目標にはまだ届かないものの、チーム全体が伸びる兆しを確信できる状態になりました。
また、傾向として「教わっていた新人が伸びる時期」に差し掛かっていたこともあり、このまま進めれば改善は確実だと感じました。
第4章｜改善の成果とチームの変化
1. 最も難しかった調整
改善の中で一番難しかったのは、プロジェクトリーダーとの調整でした。幸いなことに、私とプロジェクトリーダーの相性は良く、丸投げタイプだったため、私自身の理論を基に戦略を展開できました。
余計な横やりもなく、自由度の高い環境で動けたことは、大きな追い風になりました。
2. 安定感のある成果
私が参画してから3週間後、目標進捗にはまだ届いていない段階でしたが、プロジェクト内では「安心して任せられる」という空気が生まれていました。
役割分担が明確になったことで作業のバッティングもなく、問題が起きても大きなトラブルには発展しませんでした。
3. チームの成長
改善を進める中で、チーム内にはより多くの仕事を覚えるメンバーが増え、全体的に余裕が出てきました。
単純作業で要求が大きく変化しない業務だったため、一度安定すると進行のコントロールは比較的容易でした。
4. 全体の手応え
改善策が定着し、成果が安定してくると、日々の作業に追われるだけだったチームが、自分たちで状況を見て動ける集団に変わっていきました。
大きな波もなく、着実に進められる体制を作れたことは、このプロジェクトにおける大きな成果の一つでした。
第5章｜学びと再現性のあるノウハウ
1. 評価と実力のギャップから得た気づき
前任者は社内で「天才」「プロフェッサー」のように評価される存在でした。一方、私は当初から周囲の評価は明らかに低い立場でした。
しかし実際に現場を見て印象的だったのは、どれだけ優れたスキルを持つ人でも、プロジェクト内の関係性によってはパフォーマンスを発揮できないということです。
2. 不具合マネジメントスキルの重要性
特に、不具合報告を的確に処理できる人材——いわゆる不具合マネジメントスキルを持つ人は、この会社において非常に貴重でした。
このスキルは進捗や品質の両方に直結するため、大規模プロジェクトの安定には欠かせないと強く感じました。
3. 成果と信頼のバランス
一部の成果だけを見て「この人には任せない」「信頼できない」と判断してしまうと、組織の効率は大きく下がります。
むしろ、得意分野を活かして役割を割り当てる方が、お互いに評価を得やすく、ストレスなく進められることを学びました。
4. ボトルネックの定義と対策
今回の悪状況では、「ボトルネック＝消費コスト（作業時間）が高い工程」と定義したことが正しかったと振り返ります。
特に、多数の人が苦手とする作業はボトルネックになりやすい傾向があります。この特性を見極め、優先的に対策することが重要です。
5. 役割分割の再現性
作業と役割の区切り方は今回の改善で最も効果的だった部分の一つです。
「責任がある作業をリーダーがやる」という発想は見直すべきであり、得意な人が得意なことをやる体制の方が、短期間での成果にもつながります。今回の軌道の急激な修正をしなければいけないという状況では、この役割分割の方法は、他の現場でも高い再現性を持つと確信しています。
また責任という定義も間違えない方が良いと思います。問題が発生したから、リーダーが外されるというのは会社としても嬉しくないですし、貴重な人材が減るだけなので、良いことはないです。つまり、責任とはチームの結果を果たすことと定義する必要があると思います。そう考えると、やはり、得意な人がやると再現性は高く安定します。
第6章｜まとめと読者へのメッセージ
このプロジェクトでの経験は、「どれだけ混乱している現場でも、構造を整えれば立て直しは可能」ということを改めて教えてくれました。
私が行ったのは特別なことではなく、
- 情報の流れを整理する
- 役割を分離して負荷を減らす
- 適材適所で人を配置する
という、シンプルな取り組みです。
しかし、その効果は想像以上で、短期間でもチームは安定し、メンバーが自発的に動く集団へと変わりました。
もし今、読者の方が混乱した現場や停滞したチームに関わっているなら、まずは情報と役割の整理から始めてみてください。
小さな改善の積み重ねが、やがて大きな成果につながります。
ピンチの現場は決して「負け戦」ではありません。
状況を変えるきっかけは、現場をよく見て、一つひとつの課題に向き合う小さな一歩から始まります。
