QA 品質プロセス改善
大規模システム刷新における品質プロセス改善
横断QAで立て直し、体制の解散後も個別チームに残り、
改めて全体の品質統括を任された案件です。
- 対象大規模な業務システムの刷新プロジェクト
- 体制プロジェクト横断のQAチーム
- 経緯横断QAの立ち上げ → 横断体制の解散（個別チームのQAとして継続） → 全体品質の統括
Challenge
相談が来たときの状態
大規模システム刷新プロジェクトにおいて、リリース後の重篤な不具合が立て続けに発生していました。
開発プロセスや品質基準は形式上整備されていたものの、実運用では機能しておらず、品質は担当者個人の判断に依存している状態でした。
Where it was stuck
詰まりの場所
01
基準が文書の上にしかなかった
出す・止めるの判断に使える基準が共有されておらず、担当者ごとの判断で品質が決まっていました。文書としてのプロセスと、現場の動きが別物になっていました。
02
確認が人手に頼り、繰り返せなかった
リリースのたびに同じ確認を人が行い、変更が増えると確認が追いつかない。確認できていない範囲が分からないまま、リリースに進んでいました。
Approach
進め方
この案件は、1回で終わっていません。横断QAでの立て直し、横断体制の解散、全体品質の統括の3段で進みました。
-
立ち上げ
横断QAチームの立ち上げ
プロジェクト横断のQAチームを立ち上げ、現状の品質プロセスを分析。形式的に存在していたプロセスを実態に合わせて再設計し、開発チームと連携しながら改善施策を段階的に導入しました。あわせて回帰テストの自動化を進め、人手に頼っていた確認を繰り返せる形に移しました。
-
横断体制の解散
品質の問題が再び起きた
その後、横断QAの体制が解散し、EightDoorは個別チームのQAリードとして残りました。全体を見る役割が無くなると、品質の問題は再発しました。仕組みを作っても、それを回す体制が無くなると元に戻る、ということが起きました。
-
全体品質の統括
プロジェクト全体の品質マネジメント
個別チームのQAから、プロジェクト全体の品質を統括する役割に改めて任されました。品質ゲートの基準化、テスト自動化の方針、関係するベンダーの管理、確認する対象ドキュメントの限定を進めています。
What we built
作ったもの
Quality gate
品質ゲートの基準
出す・止めるの条件を、担当者の判断ではなく文書の基準にしました。確認できた範囲とできていない範囲を分けて示します。
Automation
テスト自動化の方針
繰り返す確認の範囲を決め、回帰テストを自動化しました。人の確認は、変更の影響が大きい場所に向けます。
Scope
ベンダー管理と対象ドキュメントの限定
関係するベンダーごとに品質の確認の仕方を揃え、確認する資料を絞りました。全部を見ようとしないことが、回る仕組みの条件でした。
Outcome
変化
参画前
- リリース後の重篤な不具合が続発
- 品質の判断が担当者個人に依存
- プロセスは文書の上だけで、実運用では機能せず
- 確認は人手で、繰り返せない
初回参画後
- 重篤な不具合は0件になり、リリースが安定
- 出す・止めるの基準を共有
- 実態に合わせて再設計したプロセス
- 回帰テストを自動化し、繰り返せる確認に
全体品質の統括に移ってからも、品質ゲートの基準と自動化した確認を土台に、安定したリリースを継続しています。
- 初回参画後の重篤な不具合件数
- 連続発生 → 0件
What came next
次につながったこと
横断QAの体制が解散したあとも、個別チームのQAとして関わり続けました。全体を見る役割が無くなったことで品質の問題が再び起き、プロジェクト全体の品質を統括する役割を改めて任されました。
仕組みは、作るだけでは残りません。回す体制と、出す・止めるの基準を文書として持つこと。この案件で学んだことは、ほかの支援でもそのまま使っています。
Contact
大規模開発の品質プロセスを相談する
似た状況でのご相談を受け付けています。
現在の状況を伺いながら、どこから着手できるか一緒に整理します。