この記事は、GLOBIS アドベントカレンダーシリーズの10日目の記事となります。
はじめに
はじめまして、株式会社グロービスでQAエンジニアをしている池邊と申します。
先日、グロービスでは「GLOBIS 学び放題（日本語版）」と「GLOBIS Unlimited（英語版）」を統合し、1つのIDで利用可能にする「OnePlan（ワンプラン）」という新プランをリリースしました。異なる歴史と技術スタックを持つ2つのサービスを統合し、お客様の利便性を飛躍的に高める、全社を挙げた一大プロジェクトです。
私はこのプロジェクトにおいて、QA（品質保証）の全体リードを担当しました。開発、ビジネス、基盤など、複数の開発チームが関わるこのプロジェクトは、QAチームにとっても過去最大級の挑戦でした。
正直なところ、プロジェクト開始当初、私たちは大きな不安を抱えていました。
「どこかで致命的な事故が起きるのではないか」
「テスト工程に入ってから仕様の矛盾が噴出し、スケジュールが崩壊するのではないか」
「チーム間の隙間で、誰も気づかないバグが本番に紛れ込むのではないか」
8ヶ月という長期プロジェクトの中で、私たちはこうした不安と向き合い続けました。多くの「泥臭い失敗」や冷や汗をかく場面を経て、ある種の「勝ちパターン」に辿り着きました。
結果として、私たちは リリース後インシデントゼロ、エラーに関する問い合わせゼロ でこのプロジェクトを完遂できました。
本記事では、この経験から得た 「不確実性を構造的に減らすための3つの戦略」 を、成功談としてだけでなく、そこに至るまでの反省も含めて正直にお伝えします。もし今、同じような不安を抱えている方がいれば、少しでも参考になれば嬉しいです。
プロジェクトの規模と難易度
まず、今回のプロジェクトがどのような難易度だったかを簡単に共有します。
期間
構想含め約8ヶ月（2024年2月〜10月）
体制
- 開発チーム：5〜7名規模のスクラムチームが6チーム、事業推進チーム3チーム、オペレーションチーム1チーム
- 開発メンバー約30名、QAメンバー14名の大規模体制
難易度
長年運用された2つのサービスのDB統合、言語切り替えロジックの実装、古いアプリバージョンへの対応など、影響範囲が予測しづらい技術的課題
制約
主力サービスであり、既存ユーザーへのデグレは許されない
単なる機能追加ではなく、「既存仕様の複雑な絡み合い」と「ステークホルダーの多さ」が、このプロジェクトを高難易度にしていました。
3つの戦略：「QAプロジェクト」ではなく「メインプロジェクト」の成功戦略
私たちが辿り着いた3つの戦略は、 「QAプロジェクトを成功させるための戦略」ではありません 。
これらは 「QAの力でメインプロジェクト（OnePlan統合）を成功させるための戦略」 です。
従来の「開発が終わってからQAがテストする」という直列型から、QAがメインプロジェクトに統合され、プロジェクト全体の成功確率を高める役割を担う構造への転換でした。
具体的には、以下の3つの戦略を 時間軸と役割の両面で組み合わせる ことで、不確実性を段階的に減らしていきました。
【上流・先行】戦略1：不確実性コーンの早期圧縮
プロジェクトの「先行偵察・地ならし」として機能。開発前に仕様の矛盾を潰し、QAフェーズが始まる時点で「純度の高い状態」を作る。
【中流・反復】戦略2：リスクバーンダウン
プロジェクトの「計器（センサー）」として機能。開発の進捗に合わせて「今どこにリスクがあるか」を可視化し、段階的にリスクを焼却する。
【全工程・横断】戦略3：バウンダリースパナー
プロジェクトの「神経系（接着剤）」として機能。チーム間の「情報の断絶」を繋ぎ、組織の綻びから生まれるポテンヒット（誰も拾わないバグ）を未然に防ぐ。
この3つは独立した施策ではなく、 相互に補強し合う統合戦略 です。それでは、各戦略について詳しく見ていきましょう。
【図解1：3つの戦略の全体像と時間軸の関係】
戦略1：複雑性を飼いならす「不確実性コーン」の早期圧縮
私たちが抱えていた課題
大規模プロジェクトの序盤は、常に不確実性に満ちています。
- この仕様で本当に大丈夫なのか？
- 開発が進んでから矛盾が発覚したら、どれだけの手戻りが発生するのか？
- 実装完了後にQAが始まった時点で、すでに取り返しのつかない問題が埋め込まれているのではないか？
通常、QAが本格稼働するのは「実装完了後」になりがちです。しかし、この段階で仕様の矛盾が発覚すると、手戻りコストは甚大になり、スケジュールは簡単に崩壊します。
私たちは、この「後半に爆発する不確実性」を事前に圧縮する必要がありました。
私たちが実践したこと
プロジェクトマネジメントの分野には、 「不確実性コーン」 という概念があります。プロジェクト初期は不確実性が非常に高く、時間が経つにつれて徐々に減少していく様子を円錐（コーン）に見立てたモデルです。
私たちはこのコーンを「開発着手前」に強制的に圧縮するため、 「理解と合意のシフトレフト」 という戦略を取りました。
1. 開発と並走する「助走期間」の設計
今回のプロジェクトでは、開発プロジェクトの立ち上げと同時に、QAチームも 「助走期間（2月〜6月）」 を開始しました。これは単に「早く始める」だけではありません。開発側の要件や仕様の解像度が徐々に上がっていくプロセスに、QAも完全に同期して並走しました。
具体的な活動内容
開発チームのスクラムイベントへの全面参加
デイリースクラム、リファインメント、レビューなど、すべてのスクラムイベントにQAメンバーが参加。仕様が固まっていく過程をリアルタイムで理解しました。
QA内プロダクト分析会の実施
30分×6回の分析会を開催。プロジェクトの目的や背景、複雑な仕様変更（言語切り替えロジックなど）について、QA内で認識を統一しました。
機能単位のまとめドキュメント作成
57件のドキュメントを作成。仕様の矛盾や考慮漏れに気づいた際は、その場でフィードバックを行い、手戻りの芽を摘んでいきました。
コスト面にも配慮しました。まだ仕様が固まっていない初期段階から全員を投入するのではなく、 最初はリードQAなど少数のメンバーで並走し、解像度が上がってきた後半から他のメンバーが本格参入する という体制をとりました。QAコストを最適化しながら、深いコンテキスト理解を実現できました。
2. 「プロダクト目線」への意識転換
助走期間中、特に意識したのは 「視座の切り替え」 です。
プロジェクト定例ではどうしても「納期・スコープ・リソース」といった 「プロジェクト目線」 の話題が中心になります。一方、QAには 「プロダクト目線（ユーザー体験やシステム整合性）」 が不可欠です。
私たちはQAメンバー内で、要件や仕様の確認にとどまらず、以下のような本質的な議論を行う時間を設けました。
- なぜこの機能が必要なのか？（ビジネス・市場背景）
- ユーザーにとってこの体験はどうあるべきか？
単に仕様書通りかを確認するだけでなく、背景にある「意図」を理解することで、テスト設計の精度を根本から高められました。
なぜこの戦略が効いたのか
この「助走期間」が生み出した最大の効果は、 QAフェーズ開始時点での「確信」 です。
通常、QA期間が始まると「本当にこの理解で合っているのか？」という不安から、テスト設計の途中で何度も開発チームに確認が必要になり、手戻りが発生します。
しかし今回は、助走期間で仕様の成り立ちから理解していたため、 「この理解は間違っていない」という確信を持ってテストを設計 でき、テスト設計のイテレーション速度が大幅に向上しました。
開発チームにとっても、QAが仕様の背景を理解しているため、「なぜこのテストケースが必要なのか」という議論がスムーズになり、相互の信頼関係が強まりました。
正直な失敗談：用語統一の遅れ
一方で、大きな反省点もあります。 「用語の定義」への感度が不足していたこと です。
例えば、プロジェクト中盤まで、「言語」という言葉が曖昧に使われていました。ある人は「コンテンツ（動画）の言語」を指し、ある人は「UIの表示言語」を指して話していたため、議論がかみ合わない場面が多発しました。
QAからの「この『言語』はどちらを指しますか？」という指摘をきっかけに、PO（プロダクトオーナー）が詳細な用語集を作成してくれました。これが後にチーム全員の認識を統一する 「神資料」 となりました。
この経験から得た教訓は、「言葉の定義揺れは、プロジェクトの手戻りに直結する」です。
次回は、 プロジェクト初日に用語集のデータベースだけでも作っておき、揺れに気づいた瞬間に即座に解消できる状態 にしておくべきだと痛感しました。用語の揺れは「後でまとめて整理」では遅すぎるのです。
戦略2：品質の予実管理「リスクバーンダウン」モデル
私たちが抱えていた課題
大規模プロジェクトで最も怖いのは、 「ビッグバンリリース（一括リリース）」 です。
すべての機能を開発し終えてから、最後にまとめてテストを行う。この手法だと、リリース直前になって致命的なバグや仕様矛盾が噴出し、収拾がつかなくなります。
私たちが恐れていたのは、こうした状況でした。
- リリース直前にクリティカルなバグが大量に見つかったらどうするのか？
- 「なんとなく不安」という状態のまま、リリース判定をすることになるのではないか？
- 最終的に「えいやっ」でリリースボタンを押すことになるのではないか？
私たちが実践したこと
私たちはこの恐怖を回避するため、 「リスクバーンダウン」 という考え方を採用しました。検証フェーズを意図的に分割し、段階的にリスクを「燃やし尽くす（Burndown）」アプローチです。
1. 3段階の検証フェーズで「安心」を積み上げる
具体的には、QA期間を以下の3つのフェーズに分割しました。
Phase 1：地ならし（7月）
目的: バックエンド（Feature Flag制御）の先行リリースに向けた、既存機能への影響確認
狙い: 「設計・基盤レベルのリスク」をこの段階で焼却する。後戻りできない致命的な問題を早期発見する
規模: 優先度高のリグレッションテストを中心に、約400件のテストケースを実施
成果: この3段階のテスト計画を策定する中で、「第一弾テストが完了した時点で、バックエンド（BE）だけなら安全に先行リリースできるのではないか？」という議論が生まれ、分割リリースの意思決定につながりました。最終リリースのビッグバンリスクを事前に大幅に低減できました
Phase 2：主戦場（8月）
目的: 今回の肝である「言語切り替え機能」や新機能の徹底検証
狙い: 「機能レベルのリスク」を焼却する。クリティカルなバグをこの期間に出し切る
規模: 優先度高のテストケース約1,200件、クリティカルユーザージャーニー（CUJ）1,500件以上を検証
成果: 新機能に関する主要なバグをこの期間に修正完了させました
Phase 3：最終防衛線（9月）
目的: 残存バグの修正確認と、UX（ユーザー体験）の微調整
狙い: Phase 1の反省（検証漏れ）を活かした再検証。「残存リスクとUXの違和感」を焼却する
規模: Phase 1で漏れていた領域を中心に、追加で約300件のテストケースを実施
成果: リリース判定の時点で、「未知の爆弾」がない状態を作ることができました。最終的な残存バグは優先度低の2件のみに抑え込みました
【図解2：リスクバーンダウンのイメージ
最終的に私たちは 「QA完了レポート」 を作成し、メイン開発チームやステークホルダーと合意形成を行いました。「なんとなく不安」ではなく、 全員が納得する「根拠ある自信」 を持ってGoサインを出すための重要なプロセスでした。
2. QAが向き合うのは「バグ」ではなく「リスク」
大規模プロジェクトでは、個々のバグそのものよりも、 「どのリスクが、どの程度残っているか」 の方が重要になります。
私たちは定例の場で、常に「今どんなリスクが残っているか」「どのリスクから先に潰すべきか」を議題に据え続けました。
特に意識したのは、 「分からないことをそのままにしない」 ことです。仕様や影響範囲に不明点があれば、その場で担当者に確認し、問題ないと分かれば「その確認自体がリスクを減らした動き」として称賛するようにしました。
こうした積み重ねによって、QAメンバーも「バグを探す人」ではなく、 リスクと向き合い、リスクを減らす動きを設計・推進する役割 という意識を強く持つようになりました。
なぜこの戦略が効いたのか
この「リスクバーンダウン」モデルが生み出した効果は、 リリース判定時の「心理的安全性」 です。
従来のビッグバンリリースでは、リリース直前まで「本当に大丈夫か？」という不安が消えません。しかし、段階的にリスクを可視化し、焼却していくプロセスによって、私たちは 「ここまでやったのだから大丈夫」という確信 を持てました。
3段階に分けたことで、Phase 1での反省をPhase 3に活かすという 学習サイクル も機能しました。
正直な失敗談：「ポテンヒット」のリアルと本番バグ
こう書くと綺麗に計画通り進んだように見えますが、現場は冷や汗の連続でした。
特に苦労したのが、チーム間の隙間に落ちる 「ポテンヒット（担当不明領域）」 です。テスト計画を進める中で、「各チームのQA担当領域の狭間で、誰もテストしておらず、現状の仕様さえ不明確な箇所」が次々と見つかりました。
Phase 1では、考慮漏れによる本番バグを2件発生させてしまいました。
1つ目は、 コンテンツ登録機能の不具合 でした。社内のコンテンツチームがコンテンツを新規登録できなくなってしまうという、オペレーションに影響する問題です。
2つ目は、 非会員向けLPの表示不具合 でした。非会員向けのランディングページのUIが一部正しく表示されないという、潜在顧客への印象に関わる問題です。
幸いユーザー影響は軽微でしたが、社内の他チームに迷惑をかけてしまう苦い経験となりました。
「計画にないボールが落ちてきたとき、誰が拾うか」。この問いに対し、各チームの担当QAの間に落ちたボールであることを明確にし、リードとなる私やメイン開発チームの担当QAが率先して拾いに行くことで、混乱を最短で抑え込むという動き方を取りました。
この失敗が、次の戦略3の重要性を私たちに痛感させることになりました。
戦略3：組織の隙間を埋める「バウンダリースパナー」としてのQA
私たちが抱えていた課題
大規模プロジェクトでは、「コンウェイの法則」の通り、組織構造の断絶がそのままシステム整合性の欠如として現れます。
私たちが恐れていたのは、こうした状況でした。
- 開発チームAとチームBの間で、仕様の認識がズレているのではないか？
- 「それは私の担当範囲ではありません」と誰も拾わない領域で、致命的なバグが発生するのではないか？
- 各チームが最善を尽くしても、チーム間の連携部分で事故が起きるのではないか？
Phase 1で実際に本番バグを発生させてしまった経験から、私たちはこの「組織の隙間」をどう埋めるかが最重要課題であると認識しました。
私たちが実践したこと
私たちは、QAの役割を 「バウンダリースパナー（境界連結者）」 と再定義しました。
これは経営学の用語で、組織間の境界を越境し、知識や情報を繋ぐ役割を指します。アジャイル開発の文脈では 「グルーワーク（Glue Work：接着剤）」 とも呼ばれる動きです。
【図解3：バウンダリースパナーの役割図】
QAチームが陥りがちなのは、「開発チームが作ったものをテストする」という受動的なスタンスです。しかし、このスタンスでは組織の「隙間」で発生するリスク（ポテンヒット）を防げません。
私たちは、QAが「テストする人」ではなく、 「チーム間のリスクを見逃さないハブ」 として機能することを意識しました。
1. 開発チームへの深い入り込み
具体的には、以下のような動きを取りました。
開発デイリースクラムへの参加
メイン開発チームのデイリースクラムにQAメンバーも参加し、「今日行われる仕様変更」をリアルタイムでキャッチアップ。「QAが知らないところで仕様が変わっていた」という事態を防ぎました。
「ワンプランQA連絡会」の設置
各領域（受講者向け開発、法人向け開発、アプリ開発など）のQA担当者が集まる定例会を設置。助走期間中は週次でしたが、開発が本格化してからは 日次で開催 。「あっちのチームで何が起きているか分からない」というサイロ化を徹底的に排除しました。依存関係のある仕様変更やリスクを、毎日同期し続けました。
2. 「リスク」に対して声を上げるマインドセット
どんなに緻密に計画しても、組織の隙間には必ず「担当不明の領域」が発生します。
このとき、「それは私の担当範囲ではありません」と沈黙してしまえば、それはそのままバグになります。
私たちは、 「リスクは気づいたからには潰さなければいけない。QAがその声を上げる人になろう」 というマインドセットをチーム全体で共有しました。
担当不明の領域が見つかったとき、QAが勝手にボールを拾うのではありません。 「ここが落ちています。誰がやりますか？ 解決に向けて動きましょう」 と声を上げ、チーム同士をつなぎ、解決に向けて動かす。
この 「リスクに対する感度の高さと、声を上げる勇気」 を持つことが、大規模プロジェクトの品質を支える推進力になると確信しています。
なぜこの戦略が効いたのか
この「バウンダリースパナー」としての動きが生み出した効果は、 「ポテンヒットの早期発見」 です。
従来であれば、結合テストや本番リリース後に初めて発覚していた「チーム間の認識ズレ」を、開発期間中にリアルタイムで検知し、修正できました。
QAが各チームのハブとして機能することで、 「QAに聞けば全体像が分かる」 という状態が生まれ、開発チーム間のコミュニケーションコストも削減されました。
正直な反省：完璧ではなかった
ただし、この戦略も完璧ではありませんでした。
助走期間の終盤、全体像が見えてきた段階で「あれ、この機能のテスト設計、どこもやってなくない？」という領域（例：マイナーな導線のリダイレクトなど）が発覚し、急遽QA内でボールを拾い合うバタバタが発生しました。
Phase 1のテスト（リグレッション）で仕様漏れが発覚した後、その修正に対するテスト設計を「どのチームのQAがやるか」で一瞬お見合いが発生しました。結果としてQAが主導して巻き取りましたが、役割分担の曖昧さが露呈した瞬間でした。
こうした経験から、 「誰が拾うか」のルールを事前に明確にしておく ことの重要性を学びました。
まとめ：QAは「守り」ではなく「攻め」の要である
8ヶ月間のプロジェクトを通じて、私たちが得た最大の学びは、 「QAはプロジェクトを成功に導くための『攻め』の役割を果たせる」 です。
「不確実性コーンの早期圧縮」も、「リスクバーンダウン」も、「バウンダリースパナー」も、すべては 「品質を守るため」だけでなく、「プロジェクトを前に進めるため」の戦略 でした。
- 仕様理解を早期に行うことで、手戻りを防ぎ開発速度を上げる
- リスクを可視化することで、自信を持ってリリース判断を下せるようにする
- 組織の隙間を埋めることで、チーム間の連携を加速させる
正直なところ、私たちも最初からこうした「攻めのQA」ができていたわけではありません。時間をかけて、失敗を重ねながら、少しずつこの形に辿り着きました。
今思うと、その 最初の一歩は「QAを要件定義段階から巻き込んでもらうこと。その意義や価値を開発チームに示すこと」 だったのかもしれません。
もし今、「進捗は見えているが、品質が見えない」という不安を抱えている方がいれば、この3つの戦略が何かのヒントになれば嬉しいです。
QAは単なる「バグを見つける人」ではありません。不確実性と戦い、組織を繋ぎ、プロジェクトの成功確率を上げるための、強力なパートナーになれると信じています。
宣伝
グロービスでは、エンジニア・QAを積極採用中です！個人的には、これまで転職で経験した会社の中で一番「ちゃんと課題解決の話ができる組織」「評価基準が明確な組織」だなと感じています。手前味噌ですが。
ご興味ある方は下記からご連絡お待ちしています！
Discussion