皆さんこんにちは。エンジニアリンググループゼネラルマネージャー兼 QA チームリーダーの窪田です。 1年が経つのは非常に早く、やりたかったことをやれたのかと振り返る年末になりました。本日は私が GM になる前から力を入れてきた活動「全員QA体制への移行*1」についてお話をします。本内容は、12/24 に取締役CTO兼VPoPの山崎がブログで話題に挙げていた「組織的ステップチェンジ」の1つでもあり、組織的なインパクトも大きな活動です。

はじめに

山崎のブログでも言及されていた通り、優秀な QA エンジニア採用は競争が激しい状態にあり各社採用に苦労している状況です。一方でエンジニア採用は順調に推移しており、開発力は日々増強されています。開発スピードの向上に対応出来るようにQA チーム内でも様々な施策を打ってきたため、QA 作業待ちチケットの大量発生などの大きな支障はまだ出ていません。しかし、今後も採用が厳しい状態が続き、現在と同様な方法で QA 作業を進めていくと、開発スピードに対応できなくなるときが訪れ、組織スケールのボトルネックになってしまう可能性があります。また、QA エンジニアが担当サービスのテストに大きな工数を割いているため、品質改善施策に取り組む時間も十分にとれていない状況となっています。テストを中心とした品質確保施策のみではさらなる品質改善は難しいためこちらについても改善が必要です。

現状の開発フロー

現在、QA チームでは、各サービスの開発チームに入り込み、仕様の確認からシステムテストの実施までを担当しています。簡略化したフローで表すと下図のようになります（チームによって採用している開発手法が違うのであくまでも一例です）

現在の開発フローはチーム内で密にコミュニケーションを取りながら並行して作業ができるため作業効率もよく、それぞれのメンバーの得意分野に専念できていると感じており、これもまた1つの安定した形なのかなと思っています。ただし、プロダクトマネージャー（以降 PdM）、エンジニア（以降 Eng）の採用が順調に進んでいるため人数のバランスが将来的に崩れてしまい、システムテスト工程（図のテスト設計〜テスト実施）がリリースのボトルネックになると予想されます。

全員 QA 体制への移行

上記問題点をまずは解消し、将来の組織拡大、さらなる品質改善を達成するために「全員 QA 体制への移行」といったチャレンジをすることになりました。簡単に言ってしまえば QA エンジニアが中心に行ってきたシステムテストを核とした品質保証活動を開発チーム全員でやってしまおうということです。言うは易し。

全員 QA 体制への移行で達成したいことはたくさんありますが、大まかに次のポイントを達成したいと思っています。

テスト活動をチーム全員で出来るようにする
さらなる品質改善施策の実施

1つ目はテスト活動をチーム全員で実施できるようになることで、リリースのボトルネックが将来的に発生するのを防ぎ、全員でプロダクトを触ることにより品質意識を更に醸成することが目標になります。

2つ目は現在、システムテストを中心とした品質保証活動となっているため、次3点の活動によりさらなる品質改善をさせることが目標です。

要件定義や画面設計書などのドキュメント品質向上
リリース後指標の監視によるサービス品質向上
品質指標の随時確認と分析の強化

今回のブログではすでに様々な活動を実施している前者について詳しく説明します。

決起集会（エンジニアリンググループミーティング）

12/26 に VPoE の河合が公開した記事の通り、エンジニアリンググループではグループメンバー全員が参加するミーティングを月に1回実施しています。

www.m3tech.blog

この中で、現在の QA エンジニア採用の現状を踏まえたうえで以下の点について説明をしました。

QA エンジニアの増加に頼らない品質確保プロセスの確立が必要であること
- 半年後、1年後にどのような状態になりたいかの方針・目標も合わせて説明（後述）
テストを中心とした品質保証活動では限界があるため、全体で協力して品質を高める体制が必要であること

説明の後ある程度の反対意見などがあるかなと思っていましたが、予想以上に協力的な声が届きました。改めてエムスリーエンジニアリンググループの互いにリスペクトし合う、助け合う文化に感動を覚えたものです。このような雰囲気もあったため次のステップであるチームへの個別説明もスムーズに進めることができました。

方針・目標設定と周知

Eng に従来 QA エンジニアが実施していたテストを実施してもらうことがとりあえずの基本方針です。実はこの方向性は今年から急に始まったというわけではなく、確認が容易な軽い修正や一部のバッチ処理などはすでに Eng にテストを実施してもらっていました。*2今回はこの活動の範囲を拡大したいというものです。

何をするにも目標を設定することが大事です。まずは目標のための指標を作成しました。次の表のように評価基準は3段階になります。

次に、各チームが現在この評価基準のどのレベルにいるかをマッピングました。その上でチームの性質などを加味してどのタイミングでどのレベルになっていたいかの目標を設定しました。次の表が作成例です。すでに半分以上のテストを実施できているチームは半年後にほぼ全てのテストを実施するように設定しています。また、現在のテスト実施比率が低いチームかつ、高い品質を維持しなければいけないチームについては品質確保の仕組みを整える時間を加味する必要があるため、緩やかな目標を設定しています。

上記目標と方針を各チームに説明をしました。各チームに所属している QA チームメンバーに現実的な進め方について提案をしてもらい、それを揉んだ上で細かいルールなどを決定しました。

ルールの一例を次に示します。今回は表の C チームの例です。

高品質を要求される機能についてはこれまで通り QA エンジニアが中心となってテストを実施する
上記以外の改修でテスト工数が1日未満のものについては Eng がテストを実施する
- Eng は確認したテスト観点をチケットに記載をし、QA エンジニアはそれをレビューする
  - 必要に応じて追加の観点を Eng にテストしてもらう
テスト観点は QA チーム内で蓄積している資料があるため必要に応じて確認をしてもらう

実施の最初の段階ではなるべく簡略なルールにしておき、問題が発生次第修正をしていく方針にしました。このルールを Eng に説明をして、即実施していただきました。

現在までの進捗

C チームでの進捗を一例として紹介します。C チームでは本施策を実施する前から少しずつ Eng によるテストを実施していました。そのため、今回の施策に対しては比較的スムーズに進めることができています。設定したルールに従って動けているため、次のステップ（テスト実施率の向上）に向けての作戦を立てている段階です。上記の活動による成果を簡単にまとめてみました。

月間 130 件の改修のテストを Eng が実施できている
今まで QA エンジニア3人で担当していた仕事を2人で回せる様になった
- 残りの1人は品質改善のための作業着手中

目標としているテスト比率までの道のりはまだまだありますが、着実に良い方向に進んでいる実感があります。成果の中に品質改善の話が少し出ていますが詳しい話については次回以降のブログで紹介しようと思います。

おわりに

当初、この活動により品質が多少落ちてしまわないかという懸念もありましたが、QA エンジニアによるレビューをきちんと行ったり、今まで整備してきた自動テストを活用したりすることにより品質を一定に保てており、懸念は顕在化しておりません。地道な改善活動が実を結んだ結果とも言えます。

うまく行っていることばかりでなく課題もあります。Eng によるテスト実施比率をこれ以上拡大するためには大規模プロジェクトのテストも実施して貰う必要があります。今まで品質計画〜テスト実施を QA エンジニアが実施してきたため、Eng にそのノウハウを伝搬しつつ、適切にレビューやテスト支援を実施して品質を落とさないように移行する必要があります。こちらについてはまだ検討中で、良い成果が出次第また報告させていただきたいと思います。

今後の展望としては、QA エンジニアが品質改善に随時着手ができるようになったり、より高い品質が求められるサービスに QA エンジニアを集中させることができるようになることが目標です。

おまけ

これ、完全達成しちゃうと QA エンジニアのお仕事はどうなるの？という話も出てきます。 QA エンジニアのお仕事はあくまでも品質を確保する、高める事にあり、テストは手段の1つです。上流のレビューに飛び込んでいったり、現在テストなどで確認できていない課題を見つけに行ったり、リリース後の数値をきちんと確認できるように動いたり……とやることはたくさんあります。さらには開発が常に順調に進むとも限らずその時は QA エンジニアの品質知識を活かすチャンスです。エムスリーの QA エンジニアはチームの品質のパートナーとしても何でもやるぞ！というスタンスで活動しているため、今後も様々なチャレンジが待っていると予想しています（直近でもチャレンジはたくさんある……やりたいことがありすぎる……）