プロダクトづくりに向き合う、atama plusのQAという選択肢

（この投稿は2024年7月に加筆修正しています）
はじめまして！
atama plusというAI×教育のスタートアップで、QA(Quality Assurance：品質保証)を担当している、そのこです。

この記事では、atama plusのQAの仕事について、皆様にご紹介できればと思います。

というのも、QAの仕事が、なかなか理解されづらいのです。
Q＆Aに間違われることや、製品の検品係だと思われることもしばしば…。
また、一言にQAといっても、会社によって仕事内容には幅があります。

この記事を読んで
「atama plusのQAはこんな仕事をするんだ、イメージが湧いた！」
「QAの仕事って、なんだか面白そうだな」
と感じていただけたら嬉しいです。

QAって世の中的にはまだあまり知られてない仕事なのかも

　　友人に「QAとして働いているんだ！」というと、しばしば「どんな仕事なの？」と聞かれます。ソフトウエア開発においては重要な役割ではあるものの、QAの世間一般での認知度はまだまだ高くないのかもしれません。

　認知度はそれほど高くないですが、実は近年非常に注目されている職種の一つです。「品質の高い製品を提供し続ける」ことはソフトウェアを開発している企業にとっては非常に重要なポイントとなるためです。（QAの仕事を外注で請け負う専門性の高い会社で急成長しているところもたくさんあるくらいです。）

「QA」は「Quality Assurance」、日本語にすると「品質保証」です。例えば、atama plusのようにアプリを作っている場合、世の中に出す前のタイミングで、想定通りの動きをするか、挙動の確認をするのも仕事の1つです。
　
　アプリの挙動確認を、QAでは ”テスト実行” と呼んだりしますが、それは業務のごく一部。atama plusのQAはそれ以外にもやってることがたくさんあり、品質確認担当というより「プロダクト開発者の一員」と捉えていただくと分かりやすいかと思います。

　一言にQAと言っても、会社によってプロダクトに対する関わり方や役割が結構違います。「これから説明すること」＝「全ての会社におけるQAの仕事範囲」というわけではないので、あくまでのatama plusにおけるQAの話としてお読みいただけると嬉しいです。

atama plusってどういう会社？

　本題であるQAの話に入る前に、「atama plusってどういう会社なの？」と気になる方もいると思うので、先に少し説明します。

　atama plusは、「教育に、人に、社会に、次の可能性を。」というミッションを掲げ、一人ひとりの学習を最適化するAI教材「atama＋」を全国の塾・予備校に提供したり、「atama＋塾」を全国にフランチャイズ展開したり、直営の「atama＋オンライン塾」を運営したりしている会社です。

　詳しく知りたい人は、是非「3分でわかるatama plus」の資料を読んでみてください！
https://speakerdeck.com/atamaplus/about-atama-plus
 創業8年目、累計調達額は113億円になりました。

開発体制ってどうなってるの？

atama plusでは、「アジャイル開発」という手法でプロダクトを開発しています。「機能リリース→ユーザーからのフィードバック→改善」のサイクルを短期間で回すことで、ユーザーにとってより良いプロダクトをつくりつづけるのが、アジャイル開発の特徴です。
　
　atama plusにはPdM、エンジニア、デザイナー、QAで構成される5人前後の小さな開発チームが複数あり、チーム間で協力し合いながらプロダクトを開発しています。各チームが開発したそれぞれの機能を統合して、リリース前に最終確認を行います。
　
　atama plusのQAは「チーム内での開発」と「リリース前の最終確認」「リリース後の品質管理」の大きく分けて3つの役割を担いますが、この記事では「チーム内での開発」について詳しく書きます。

開発チームにおけるQAの仕事は大きく分けて3つ

　さて、ここからが本題！
　開発における、atama plusのQAの仕事は、大きく分けて3つあります。

①品質の高いプロダクトを作るためのフィードバック
②確認観点の洗い出しと確認手順の設計・実行
③品質改善活動を主導する


　開発チームでは、「ディスカバリー(課題整理、仮説検証)」と「デリバリー(開発)」を、複数の課題に対して同時並行で行います。1週間を一つの区切り(1スプリント)として管理して、出来るだけ早く新機能をリリース出来るようにしています。

　上の3つに関して、それぞれ詳しく説明します。

品質の高いプロダクトを作るためのフィードバック　

「品質保証」と言うと、”品質の最後の砦”の存在と思われがちです。
　しかしQAの仕事は、エンジニアの開発前から始まっています。QAがバグ（不具合）の作りこみを未全に防げれば、エンジニアが不具合を修正する時間や、QAが修正を確認する時間が節約できるためです。

　atama plusでは、「ディスカバリー(課題整理、仮説検証)」というフェーズで、ユーザーの困っていることと、それに対する筋のよさそうな解決方法（機能開発）を、開発前に検証します。
　
この時に、プロダクト全体の現状仕様に精通し、俯瞰して機能を考えられるQAの視点が重要になってきます。「〇〇の機能を開発するとしたら、既存の△△の機能と矛盾する部分がでちゃうかもしれないよ」「以前に別機能を開発した時に、こういう不具合が出たけど、今回も似たような開発だから注意ポイントだよ」のようなフィードバックをすると、そもそも不具合を作りこみにくい開発が出来ます。

その際に、「その機能によって、ユーザーに価値が届けられるかどうか」という視点を大切にしています。

　　チームにより良いフィードバックをし続けるために、誰よりもプロダクトに興味を持って、自分から理解しに行く姿勢が必要になります。そのため、他チームが開発した機能を頭で理解するだけでなく、リリース前にまず触ってみて、ユーザーの使用感を想像することを大切にしています。

さらに、実際のユーザーからの問い合わせ内容や困りごとをチェックし、新機能の現場での使われ方や、より使われやすいプロダクトに改善するための情報収集を積極的に行っています。そうすることで、新機能を考える時に、その機能に閉じない、プロダクト全体を俯瞰したフィードバックが出来るようになります。

確認観点の洗い出しと確認手順の設計、実行

　次に開発段階でのQAの役割を説明します。
開発は、ユーザーにとって有益だと思える機能の方向性が定まると動き出します。QAは、エンジニアがコードを書いている間、じっと待ってる訳ではありません。開発と並行して、どういうチェックをすれば品質の良いものに出来るか、注力するべきポイントを整理します。仕様通りに動くかどうかの確認に留まらない確認ポイントを洗い出せるかが、QAの腕の見せ所です。

例えば、「Aボタンを押すとA画面に行く」のは当たり前ですが、もう少しユーザーの立場に立って考えます。
「Aボタンを押すべきタイミングで気づきやすい流れになってるかな?」
「もし、間違ってBボタンを押してしまった時、それに気づいてAボタンを押しなおせるかな？」
「そういえば、似たような機能を作った時、Aボタンを連打して反応が悪くなるケースがあったけど今回は大丈夫かな？」
といった具合に、ユーザーが実際に使う状況をベースに考えます。大事なのは「その機能によってユーザーに価値が届けられるかどうか」それを念頭に確認観点を考えます。

確認観点を考える際、不具合レポートが役に立ちます。
不具合レポートは、リリース後に実際に現場から報告があった内容を、事象ごとにまとめたものです。
QAは、所属チームに関わらず、プロダクトに関わる全ての不具合レポートを確認し、修正の必要性や優先度を判断する業務を日々行っています。
これにより、「想定していないユーザーの使い方」や「不具合が起こりやすいパターン」の把握が出来るので、ユーザーが実際に使う状況を想像したり、注意すべきポイントが見つけられるのです。

また、新機能開発時のような、全ての観点を網羅的に確認することが難しいときは、エンジニアやデザイナーと一緒に、注力して確認するポイントや、過去の経験から念入りに確認しておいた方が安心できるポイントをピックアップしています。

確認手順の設計や実行は手動で行うこともありますが、ここ数年はテストの自動化にも力を入れています。テスト自動化とは人間の手で操作をして動作確認をする代わりに、テストの実行内容や期待値についてコード上に明記し、自動で動作検証を行うことを意味します。テスト自動化が進むとプロダクトが複雑化してもリグレッションテスト（Aという機能を開発した時に予期せず他の機能が影響をうけて不具合を発生していないかどうかを確認する）が容易に出来るため、プロダクト全体の品質維持がしやすくなるというメリットがあります。

品質改善活動を主導する

　atama plusでは、1週間の区切り(スプリント)で開発を進め、スプリントが終わるたびに「レトロスペクティブ」という振り返りを行っています。振り返りでは「〇〇という行動は良かった！」のような話や、「どうしたらあの不具合を未然に防げたんだろう？」のような話も挙がり、後者のようなトピックではQAが率先して動きます。

　例えば「詳細設計の時に〇〇まで深堀りすべきだったから、次回からはそうしよう！」といった具体的な改善を実行することもありますし、「今度、みんなで品質に関する〇〇という本を読んで、目線を合わせよう」といった提案をすることもあります。大事なのは「QAだけが品質について考える」のではなく、「チーム全体で品質を考えられる」ようにすること。それを念頭において活動していますし、そのための仕組みづくりもQAの大事な役割です。

まとめ

QAの開発チームにおける仕事内容について書いてみましたが、イメージは湧きましたでしょうか？私自身はatama plusでQAをはじめて5年以上経ちましたが、atama plusのプロダクトの改善によって「勉強が楽しいと思える生徒が増えた！」「また成績が上がった！」というフィードバックは、未だに震えるほど嬉しいです。QAとして、atama plusのプロダクト開発が出来ている状況に毎日ワクワクしています。

　QAの業務を行う上では専門知識(テスト手法、テスト自動化スキルなど)ももちろん大事ですが、atama plusのQAにとって一番大切なのはプロダクトに対する想い、ユーザーに価値を届けたい (atama plus的に言うと、『Wow students.（生徒が熱狂する学びを。）』)という想いです。

　atama plusでは、入社後の新人研修の後、QA職種としての研修がしっかり1ヶ月間用意されています。研修終了後も、勉強会や知識共有の場が設けられているので、QAとしてのスキルを身に着けやすい環境が整っており、
QA経験が豊富なメンバーからのフォローを受けることも出来ます。
atama plusにはとても興味があるしQAの仕事も面白そうだけど、未経験だし心配だなぁという方でも、活躍の機会が十分にあります！実際にatama plusのQAは入社時点でのQA未経験者が多くいますが、みんな活躍していますよ。

atama plusでは組織の拡大に伴い、QAの仲間を大募集中です！
少しでも興味がわいた！もうちょっと詳しく聞いてみたい！という方がいらしたら是非お気軽にご連絡ください。

▼QAの募集要綱：
https://herp.careers/v1/atamaplus/NB-T_67l5Qn4

・こんな方におすすめ
　「QAとしての幅を広げ、ユーザーにより良いものを届けたい」
　「自社プロダクト開発における、QAの働き方に興味がある」
　「アジャイル開発におけるQAの動き方に興味がある」
　「プロダクト開発未経験だが、教育業界の仕事やプロダクトづくりに興味がある」
　「atama plusという会社や、そこで働く人に興味がある」