開発組織拡大におけるQA組織の変遷
こんにちは。atama plusの井上です。現在、Quality Promotion（品質推進、以下QP）チームとコンテンツチーム、アセスメントチームで仕事をしています。
今回はQPチームの取り組みの一つである、「開発組織の拡大に伴い、何をどのように検討し、QA組織をみんなで作りあげてきたか」について書いていきます。
QAの役割も会社によって定義は様々かと思いますので、まずはそこから説明します。
QAとは何をする仕事なのか
創業初期のatama plusのQAは、”品質の最後の砦”として品質確認・保証を目的に、開発の最終段階を中心に活動していました。（詳細は後述の「開発組織拡大とQA組織の変遷の概要」セクションをお読みください）
一方で現在のatama plusのQAは、最終段階のみならず、開発前から重要な役割を担います。QAがバグ（不具合）の作りこみを未全に防げれば、エンジニアが不具合を修正する時間や、QAがその修正を確認する時間が削減され、開発効率が高まると考えるためです。
具体的には、「ディスカバリー(課題整理、仮説検証)」と呼ばれる取り組みにQAも参加をします。このフェーズでは、ユーザーの困っていることと、それに対する筋のよさそうな解決方法（機能開発）を、開発前に検証しますが、プロダクト全体の現状仕様に精通し、俯瞰して機能を考えられるQAの視点が重要になってきます。
「〇〇の機能を開発するとしたら、既存の△△の機能と矛盾する部分がでちゃうかもしれないよ」「以前に別機能を開発した時に、こういう不具合が出たけど、今回も似たような開発だから注意ポイントだよ」のようなフィードバックをQAが行うことで、不具合を作りこみにくいプロダクトを開発出来ます。
次のセクションでは、創業期からこれまでのQAチームの変遷について触れたいと思います。
QAの仕事内容について、詳しくは、QPチーム・そのこが書いた記事を読んでもらえると幸いです！
開発組織拡大とQA組織の変遷の概要
atama plusのQAは、大きく分けて3回の転換期がありました。ここでは、それぞれのフェーズの概要や、どういう課題に直面してどのように組織を変遷してきたかについてご紹介します。
○2017年9月：「手探りの状態で品質確認をスタート」
2017年4月にatama plusを創業し、ほどなくしてQA活動が始まりました。
はじめは、「生徒さんをはじめ、atama plusのサービスを使ってもらうユーザーに、バグが含まれているサービスをリリースしてはいけない」という思いから、スプリント後にブラックボックステスト*1でリリーステストを行うところからスタートしました。創業当時、社内にはQA経験者はいなかったため、開発者と相談しながら手探りで品質確認をしていました。
開発体制やQA体制、テストタイミングと期間をまとめると以下のようになります。
開発体制
開発チーム（PO1名、dev 4名程度、UX1名）が1チーム
QA体制
開発チーム外に他業務との兼任のQAが2名
テストタイミングと期間
週に1回のスプリント終了後開始、終了まで数日
1年半ほど経つと、開発チームが2チーム、3チームに増え、専任QAも2、3名という体制になりました。開発スピードが加速しプロダクトの機能も拡充した結果、テストケースが増大し、当時テストに1-2週間ほどを要しました。
また、プロダクトリリースの最終工程で品質確認をしていたため、バグが確認されるとその修正の影響を受け、テスト期間やリリースのタイミングが大きく変動してしまうという課題に直面していました。QAを増やしたり、ケースを効率化したりする程度の改善では、根本的な解決は難しい状態だったため、QAの役割、プロダクトとのかかわり方を見直すことになりました。
*1: スプリントでの成果内容などからテストすべき項目を洗い出し、システムの内部構造を考慮せずに実施するテスト技法
○2019年9月：「品質向上の役割をアドオン変更して、チーム付QA発足」
最終工程のみの品質確認ではテスト期間やリリースタイミングが安定しないという課題を解決するため、もっと前工程からQAが品質確認・向上に携われるよう、QAを開発チーム外ではなく開発チーム内に配置する決断をしました（atama plusでは開発チーム内のQAを“チーム付QA”という役割で呼んでいます）。
チーム内にQAを置くことでQAは「何が作られ、どう動くべきか」といった品質確認にとどまらず、「どう作ればリスクが少なく、何をすればユーザーにとって使いやすいか」という品質向上の役割を担うことも可能になりました。
一方で、リリーステストをおざなりにするわけにはいきません。そこで、「品質確認フォロー」という役割を新設し、リリース時の品質を維持できる状態を作りました。チーム付きQAが早いタイミングで新機能の品質を確認出来ているので、リリーステストで見るべき観点を従来よりも絞ることができ、テストの内容も大幅な効率化が出来るようになりました。
開発体制
開発チーム（PO1名、dev 4名程度、UX1名、QA1名）が3チーム
QA体制
・開発チームにそれぞれQA（開発チーム付QA）を1名ずつ
・品質確認フォローのQAを数名
テストタイミングと期間
開発チーム付QA：デリバリーフェーズからスプリント終了まで随時
品質確認フォロー：リリーススプリント終了後に開始、終了まで2週間
開発の早いタイミングからQAが関わる体制になったことで、リリーステストの期間やリリースのタイミングも安定し、チーム付きQAも所属チーム内における最適な動きが出来るようになってきました。
しかし、開発チームが3チームから8チームと更に増え、QA全体として横断的な対策を打つ必要が出てきました。例えば、テストの自動化について。各チーム付きQAが個別最適な解を求めるよりも、QA全体での対応策を考えたほうがよりスピーディーに解決できる、といった場合です。この時点での体制ではチーム横断的な課題にスピーディーに取り組むのは難しい状況でした。
○2021年6月：「QPチームの発足。個人でのスピード向上からQPチームとしてのスピード向上へ」
1人のチーム付きQAとして取り組むのが難しい課題に対応できるよう、QAの横のつながりを強化したQPチームが発足しました。QPとはQuality Promotionの略です。「QAのみならず全員で品質に取り組める組織を作ろう。QAがその状態を推進していこう」という思いでこのチーム名にしました。
各開発チームに所属しているQAは、QPチームにも所属する形となります。新チームを発足するにあたり、チームの目指すべき軸がぶれないように「いいものを早く安定的にユーザーに届けるチームであり続ける」というミッションを掲げ、全員で認識合わせしました。チームのミッションを言語化、明示することで、現状の延長上に正解を求めるのではなく、ミッション達成のために今やるべきことは？とそれぞれが考えられるようになったと思います。
結果として、最近ではリリーステストの期間を2週間から1週間に短縮することができました。実現にあたっての課題や取り組み内容についてご説明します。
いいものを早く届けるために、リリーステスト（リグレッションテスト*2）期間の短縮に取り組む必要がありましたが、以下のような課題がありました。
*2: プログラムの一部分を変更したことで、ほかの箇所に不具合が出ていないかを確認するためのテストのこと
課題
・リリーステストは品質確認フォロー担当者が実行しているが、ケースの効率化等ではテスト期間の短縮に限界がある。
・リグレッションテストがメインとはいえ、開発の成果物に合わせてケースの修正や追加が発生するため、1週間でテストが完了出来る人員体制を整えると、リリース回によっては大幅に人が余剰になるリスクが増える。（リリーステストの性質上、一部を前倒しでテストするなどの対応も難しい）
・大人数の品質確認フォロー担当者を一気に採用し、教育するのに無理がある。
課題に改めて向き合ってみると、従来の体制の延長線上には解決がないことが分かったため、体制を抜本的に変えることにしました。結果的にはリリーステストを信頼できる外部のパートナーに曜日単位で委託し、2週間から2日に減らすこと成功しました。
それに伴い、社内の品質確認フォロー担当者を「QAアシスタント」へ役割を変更しました。QAアシスタントはリリーステストで外部に委託できない部分のテストを担当したり、チーム付きQAの補佐をしたりすることで、品質をより安定させられるチーム体制とすることができました。
開発体制
開発チーム（PO1名、dev 4名程度、UX1名、QA1名）が10チーム
QA体制 ※QPチームとしてつながりを強化
開発チームにそれぞれQAを1名ずつ
品質確認フォローを外部のパートナーに委託
QAアシスタント業務を6名
テストタイミング
開発チーム付QA：デリバリーフェーズからスプリント終了まで
品質確認フォロー：週に1回のスプリント終了後開始、終了まで2日間
今からどんなチーム体制にしていこうと思っているか
「いいものを早く安定的にユーザーに届けるチームであり続ける」ために、リリーステスト期間の短縮をすることが出来ましたが、まだまだゴールではなく、課題もたくさんあります。
これからは「個人での品質向上からQPチームとしての品質向上へ」というテーマに取り組むことを考えており、早速動き出しています。現状は、以下の課題に取り組むことを考えています。
課題 ※将来的に発生しそうな課題も含む
① チーム付きQA活動が開発チーム内にとどまり、知識の横展開がしにくい。
② 別チームのQAがテストの成果物等をレビューすると、背景含めた理解が不十分で、表面的な判断になってしまう。
③ 新しいQAメンバーへのフォローが十分にしにくい。
④ 開発チームにQAが１人しかいないが故に仕事量の調整が難しく休みがとりづらい。
⑤ 開発チームの増加タイミングに合わせて都合よく採用することが難しい。
上記のような課題を解決すべく、開発チーム付きQAを横断的にフォロー出来る役割を新設し、体制を整えようと対応中です。
まとめ
約4年間、会社の成長に伴いQAも日々改善をしながら、組織を拡大してきました。今後もatama plusのミッションである「教育に、人に、社会に、次の可能性を。」を実現するために、プロダクト同様アジャイルに、課題を見出し、どんどん変化しながら成長していきたいと思っています。
いいプロダクトを作るためにも、いい組織であることは必須条件です。この記事をきっかけにatama plusに興味がわいた！もうちょっと詳しく聞いてみたい！という方がいたら、お気軽にご連絡ください。たくさんの仲間と一緒にいい組織を作り、atama plusのミッションを実現できるいいプロダクトを作りたいと思っております。
QA未経験者でも大歓迎です！なぜなら、atama plusのQAにとって一番大切なのは、プロダクトに対する思い、ユーザーに価値を届けたい (atama plus的に言うと、『Wow students.（生徒が熱狂する学びを。）』)という想いだからです。未経験、経験者ともに入社後の研修が充実しているので、安心して仕事をスタートできます。
採用サイトには、QAの社員インタビューも載っているので、ぜひご覧ください。
こんな方におすすめ
「QAとしての幅を広げ、ユーザーにより良いものを届けたい」
「自社プロダクト開発における、QAの働き方に興味がある」
「アジャイル開発におけるQAの動き方に興味がある」
「プロダクト開発未経験だが、教育業界の仕事やプロダクトづくりに興味がある」
「atama plusという会社や、そこで働く人に興味がある」