はじめに

N予備校品質保証チーム（以下品証チーム）の望月です。
ドワンゴには2022年1月に中途入社しました。
組織が立ち上がってから1年半という品証チームに参画後の半年間で、プロダクト／プロセス品質向上の観点で取り組んだ改善活動をご紹介します。

※表現に関する補足
この記事では、テストや品質に関連する業務を「QA」と表現しています。

参画当初の品証チームの状態

前項でも触れましたが、品証チームは組織が立ち上がってから1年半という若い組織で、いわゆる立ち上げ期です。
立ち上がり後の1年半はQAプロセスの構築やリグレッションテストの導入など、品証チームの役割を開発チーム内に根付かせる活動を中心に行ってきました。

＜過去の品証チームの活動記録はこちら＞
blog.nnn.dev blog.nnn.dev

一方で、「プロダクト／プロセス」の両面で「これからやりたいこと／改善すべきこと」に着手できていないという課題がありました。

私が入社後、最初に感じたことはメンバー各々が感じている課題感をチーム全体で取り組めていないという点でした。
この部分に自身の知見や経験を活かして貢献できるのではと考え、課題解決に向けてチームを巻き込んで活動を開始しました。
（個人的に活動するのではなく、チーム全体で活動することを重視しました）

改善活動の前に取り組んだこと

まず取り組んだのは、課題の洗い出しと整理です。
各々が感じている課題感を個人の中で留めるのではなく、チーム全体の課題として捉え、チーム全体で解決していくということを目的として洗い出しを行いました。
ただ闇雲に洗い出しをするのではなく、きちんと順序を踏んで進めていくことが大事だと感じたので、どのような手順で整理を進めたかをご紹介します。

STEP1：整理の方針を決める

整理を始める前に方針を決めます。
今回は以下の方針を決めました。

課題の内容	改善活動の期間
プロダクト、プロセスの品質に関するものであれば何でもOK （技術的なことや組織形成に関連するものでも可）	・短期（〜3ヶ月以内）に改善できる課題・中期（〜1年以内）に改善できる課題・長期（1年以上先〜）に改善できる課題

STEP2：課題を洗い出す

STEP1で決めた方針を軸に各々で課題を洗い出します。
課題は合計で34個上がりましたが、その中の一例をご紹介します。

＜洗い出された課題＞

全体的な開発サイクルの中で、後工程でQAすることが多い
テストデータが整備されておらず、QAの度にテストデータを探す／作成する手間が発生している
リグレッションテストのボリュームが膨大で、実施に時間がかかってしまう
リグレッションテストの動作確認項目書が実施者のスキル／知見に依存している
品証の確認を通らずにリリースされているものがある
各クライアントの仕様変更をリアルタイムでキャッチアップできていない

STEP3：課題をカテゴリごとに分類分けする

洗い出した課題をカテゴリ／期間ごとに分類分けします。

＜分類分け＞

シフトレフト
- 全体的な開発サイクルの中で、後工程でQAすることが多い
テストデータ
- テストデータが整備されておらず、QAの度にテストデータを探す／作成する手間が発生している
動作確認項目書（テストケース）
- リグレッションテストのボリュームが膨大で、実施に時間がかかってしまう
- リグレッションテストの動作確認項目書が実施者のスキル／知見に依存している
品証プロセス
- 品証の確認を通らずにリリースされているものがある
- 各クライアントの仕様変更をリアルタイムでキャッチアップできていない

STEP4：課題改善の取り組み内容と実施効果を整理する

実際に課題改善のために取り組む内容や改善後の実施効果を整理します。
実施効果は、達成することによって「何がどう変化するか（改善されるか）」や「改善されることによってどのような効果が生まれるか」を意識しながら整理することがポイントです。
取り組む内容については、可能な限り具体的な取り組みを洗い出します。
具体的な取り組みを洗い出すことで、「チーム内のノウハウで解決できるのか／他チームの協力が必要なのか」がより明確になります。

＜実施効果と取り組み内容＞

No	カテゴリ	課題	実施効果（想定）	取り組み／対応策
1	シフトレフト	全体的な開発サイクルの中で、後工程でQAすることが多い	- リリース工期短縮化 - リリース前の手戻りコスト解消 - プロダクトに寄り添ったQAの実現 - 品証チームのプレゼンス向上	開発サイクルの早い段階でQAを実施
2	テストデータ	テストデータが整備されておらず、QAの度にテストデータを探す／作成する手間が発生している	- テストの効率化 - 品証チーム以外の開発チームメンバーが必要に応じて使用可能（作業効率化） - 教材パターンの認識を開発チーム全体で統一	- 必要なテストデータのパターン洗い出し - テスト環境へのテストデータ準備
3	動作確認項目書	リグレッションテストのボリュームが膨大で、実施に時間がかかってしまう	- 作業効率化、コスト削減 - 実施者のスキルに依存せず、品質のばらつきを解消	- リグレッションテストの自動化導入 - リグレッションテストのメンテナンス
4	動作確認項目書	リグレッションテストの動作確認項目書が実施者のスキル／知見に依存している	- 有識者以外のメンバーが自走できない状態を解消 - 動作確認項目書の品質向上（表記や表現のばらつきを解消）	リグレッションテストのメンテナンス
5	品証プロセス	品証の確認を通らずにリリースされているものがある	- リリース後の安定した品質提供 - リリース後障害の減少 - 開発全体に向けて品質に対する意識向上	各クライアントチームに品証メンバーが参画し、案件以外の改修などの動作確認を実施するプロセスを構築
6	品証プロセス	各クライアントの仕様変更をリアルタイムでキャッチアップできていない	- QAプロセス品質の向上 - 仕様の認識齟齬による手戻り作業防止	各クライアントの開発サイクルにQAプロセスを導入（仕様変更をキャッチアップできる体制構築）

STEP5：総合的な判断で課題の優先度を決める

整理した課題に対して、チーム観点で優先度を決めます。
優先度は「高、中、低」の3つに分類し、基本的には高→中→低の順に対応していきます。
このSTEPで大事なことは、個人観点の優先度とチーム観点の優先度には少なからずギャップが生まれるので、チーム観点をきちんと理解した上で優先度を決めることです。

※優先度「高、中、低」の定義
以下2つの観点で判断し、どちらとも当てはまる場合は「高」／どちらかに当てはまる場合は「中」／どちらにも当てはまらない場合は「低」と定義付けしました。

改善による貢献度の範囲が大きい
改善しないと大きな問題が発生する

STEP6：担当者をアサインし、改善活動を実施する

整理が完了したら、実行に移ります。
次項で実際にここ半年間で品証チームが取り組んでいる／取り組んだ改善活動をご紹介します。

改善活動の取り組み

前項のSTEP4で整理した取り組みを実施します。
半年間では大きく分けて以下3つの取り組みを行いました。

1. 各クライアントチームへの品証メンバー参画
2. テストデータの整備
3. リグレッションテストのメンテナンスと領域拡大

それぞれの取り組みについて「取り組み内容／実施効果」の観点でご紹介します。

1.各クライアントチームへの品証メンバー参画

N予備校の開発チームはクライアント毎（iOSチーム、Androidチーム、PCチーム）に開発チームが独立しています。
品証チームは機能軸の組織のため基本的にはクライアントチームに属さず、横断的に各開発チームと連携を取っていましたが、シフトレフトの観点で2022年4月からiOSチームに品証メンバーとして私が参画しています。
以下、活動の詳細です。

【解決したい課題】
前項STEP4より、

No1：全体的な開発サイクルの中で、後工程でQA活動することが多い
No5：品証の確認を通らずにリリースされているものがある
No6：各クライアントの仕様変更をリアルタイムでキャッチアップできていない

取り組み内容	実施効果
1.開発チームの日例に参加	- 開発⇄品証間の連携強化（お互いに確認したいことを確認しやすくなる環境構築） - 仕様変更をリアルタイムでキャッチアップできる体制が構築できた
2.リグレッションテスト時にまとめて依頼を受けていた改修チケットをリグレッションテストよりも前の工程で品証確認を実施	- リリース対象の改修チケットの品証確認を月1のリグレッションテスト実施時ではなく、改修のタイミングで品証確認することでリグレッションテスト時のテスト負荷を軽減できた - 改修のタイミングで品証確認することで問題の発生やデグレをリリースまでの前工程で解消できた - 各改修チケットのQA観点を開発⇄品証間ですり合わせることによりQAの精度が上がり、品質向上に繋げることができた
3.リグレッションテストのテストケースレビュー工程の導入	- 「品証がどのようなQAを実施しているかわからない」という開発側の課題を解消できた - レビューを通してテストケースの精度が上がり、品質向上に繋げることができた

現在はiOSチームのみに参画していますが、今後はAnrdoidやPCチームにも参画できる体制を構築し、N予備校全体の品質底上げを図っていく予定です。

2.テストデータの整備

N予備校のサービスは教材や授業を利用してユーザーが学習を進めています。
教材と授業にはそれぞれ様々なパターンが存在しますが、パターンの種類を把握できていない／テスト環境に該当のテストデータが存在しないという課題を解決しました。
以下、活動の詳細です。

【解決したい課題】
前項STEP4より、

No2：テストデータが整備されておらず、QAの度にテストデータを探す手間が発生している

取り組み内容	実施効果
1.教材パターンと各教材を整理し、ドキュメントにまとめる	- 教材パターンを全て把握することができた（仕様理解力の向上） - 開発チームから品証チーム宛に教材データに関する問い合わせが稀にあったが、ドキュメントを全体共有することで品証に問い合わせすることなく確認することができる仕組みを構築できた（問い合わせ工数の削減）
2.不足しているテストデータをテスト環境に作成する	- テストデータを利用したい場合にテストデータを準備する工数を削減できた - 本番環境に近いテストデータを利用することで品質向上に繋げることができた

＜N予備校のテストデータについて＞

教材（参考書、問題集、動画、授業など）
アカウント（N/S高生、無料ユーザー、有料ユーザーなど）

上記の通り、テストデータは教材以外にアカウントも含まれます。
アカウントに関しても権限パターンが必要となるため、今後はアカウント整備についても取り組んでいく予定です。

3.リグレッションテストのメンテナンスと領域拡大

品証チームでは現在フロントエンド向けのリグレッションテストを定常的に実施しています。
リグレッションテストは2021年10月頃から運用を開始していますが、継続的に運用を行っていく中でいくつか課題点が出てきたので、今回はその課題を解決していきます。
また、課題解決とは別にN予備校サービスの全体品質底上げの観点で、バックエンド向けのリグレッションテスト導入を進めています。
以下、活動の詳細です。

【解決したい課題】
前項STEP4より、

No3：リグレッションテストのボリュームが膨大で、実施に時間がかかってしまう
No4：リグレッションテストの動作確認項目書が実施者のスキル／知見に依存している

取り組み内容	実施効果
1.既存で運用しているフロントエンド向けのリグレッションテストケースをメンテナンス	- QAスキルや知見に依存することなく誰でもQA遂行を自走できる状態を構築できた - 表記や手順の記載を統一することで認識齟齬（理解誤り）を防止できた - 不足しているテスト項目を充足することでリグレッションテストの精度向上
2.バックエンド向けのリグレッションテストケースを作成	- フロントエンドだけではなく、バックエンド観点のテストを導入することでサービス全体の品質向上を図ることができた - APIテストなど今まで開発側で実施していたテスト工程を品証側で巻き取ることができた（開発側のテスト負荷軽減／開発側と品証側のダブルチェックにより品質担保率向上）

リグレッションテスト効率化の観点で、当初はテスト自動化を検討していましたが、N予備校は多岐に渡る管理ツールを利用する必要があるなどテスト内容が複雑のため、短期／中期的な期間で改善することが難しいと判断し、現時点では優先度を下げています。
自動化導入に関しては、長期的な視点でQAプロセス効率化に取り組んでいく予定です。

今後の展望

過去のブログでも紹介させていただきましたが、品証チームは「開発者品質、ユーザー品質の保証・向上を通じた、社会品質の実現」を目指して活動しています。
（※詳細はこちらをご確認ください）

しかし、未来の教育を作っていくためにはまだまだ品質面で課題があります。
プロダクトとプロセスの両面の品質を磨き上げていくことがN予備校を利用していただくユーザーの満足度向上に繋がってくるので、品証チームとして大きく価値貢献できるように今後も品証チーム全体（個人的にも）で大きくレベルアップを図っていきます。
また、中期的／長期的に継続して実施していくQA活動について、今後も定期的にブログを発信していきます。