1人目のQAエンジニアとして、成長と品質を両立するために、知っておきたいこと

こんにちは！J-CAT株式会社でQAエンジニアをしている奥田です。

私たちは、「テクノロジーとクリエイティビティで、魅力あふれる日本の姿を世界へ」をミッションに掲げている観光テックカンパニーです。弊社では、特別な感動体験に出会える予約サイト「Otonami」と、日本の魅力を世界へ届けるインバウンド向け予約サービス 「Wabunka」を運営しています。

1人目QAが知っておきたいこと

今回は、急成長中の観光スタートアップにおいて、1人目のQAエンジニアがとしてアサインされてから、約半年が経ちましたので、プロダクトの成長と品質を守るための活動で得た学びをまとめました。

QAの技法や知見を述べるには、まだまだ未熟であり、試行錯誤を繰り返している段階ではありますが、自分と同じように1人目のQA担当にアサインされたエンジニアが最初の一歩目で「知っておきたいこと」くらいはお伝えできればと思います。

まずはQAとは何かを掴む

自分は元々フロントエンドの開発をしており、QAに関する経験もなく、「QAとはなんぞや？」という状態でした。
なので、まずはQAという概念の輪郭を掴むところからのスタートになりました。
QAとは、Quality Assuranceの略で、QAエンジニアとは言葉の通り、

ソフトウェアの「品質を保証するエンジニア」となります。

はあ、そうですかという感じですね。
一口に品質と言っても、ソフトウェアの品質というのは、多岐に渡ります。

品質特性（システム及びソフトウェア製品の品質要求及び評価（SQuaRE）−システム及びソフトウェア品質モデル参照）
個人的には、QAエンジニアという仕事に惹かれたきっかけになった図です。
というのも、この図はQAエンジニアがどこからどこまでを見るのかという指標になったからでした。
また、これほど多岐にわたる視点を持ってプロダクトを見れるポジションということが単純に楽しそうと思いました。

あと、これだけ多くの観点を1人の責任者が全てを担保するのはほぼ不可能だと直感的に理解でき、ある意味諦めがついたのも良かったです。 QAエンジニアが「品質」の全てを1人で抱え込まなくても良いし、さまざまなステークホルダーと連携して、仕事を進めることが正解なんだと理解できました。

「品質保証」はQAエンジニア1人でやらなくてもいい。

これは、「スクラム開発　QAエンジニア　役割」とかでネットで調べると出てくることですが、自分にとっても、知っておいてよかった心構えでした。

昨今プロダクト開発でよく採用されるスクラム開発では、スプリントごとに、設計~開発~リリースが高速で行われます。そのサイクルの中で、「品質」を担保し続けるのは、とても困難なことです。
QAに対する知見はもちろん、システムやプロダクトに対する深い理解が必要となるからです。実際には、開発エンジニアだけでなく、PdM、経営陣、デザイナー、カスタマーサポートなどプロダクトに関わる全てのステークホルダーが連携し、それぞれの得意な分野の知見を持ち寄りながらさまざまな「QA活動」を日々地道に行わなければいけません。
「QA活動」の旗振り役が、QAエンジニアだと私は捉えています。

「品質視点」をスクラムに持ち込む

自分自身、QAにアサインされた当初、心配だったのが、「ちゃんと価値を発揮できるのだろうか」ということでした。開発エンジニアのようにコードをゴリゴリ書いて、日々新しいものを創出している存在ではないので、一見「何をしているの？」と思われかねない、、

そんな自分が最初に誰でもQAエンジニアとして価値を発揮できると考えているのが、

「品質視点」をスクラムに持ち込むということです。

ソフトウェアの開発現場において、よく陥るのが、「品質を疎かにしてスピード上げる」という状態です。
結論から言うと、スピードと品質はトレードオフではありません。

しかし、そのような状態に陥ってしまう力が働くのは、ソフトウェア開発に携わる人間なら分かるのではないでしょうか。（詳しくはtwadaさんの「質とスピード」という講演動画でよくわかります。）

組織にもよりますが、全ての開発チケットのステータスを網羅的に追えているのは、PdMかスクラムマスターくらいしかいません。ただ、彼らの視点は「機能開発（どうやって作るか）」や「開発の進捗」といった「スピード」の視点に寄りがちです。

そこで、QAエンジニアの出番です。
QAエンジニアこそが、開発の「質とスピード」を守ることができる大事な存在です。

品質視点を持つことで結果的には、開発のスピードを上げることにつながります。
開発の早い段階で仕様の考慮もれやUIUXの欠陥に気づいて、開発後の手戻りを防ぐことができると開発効率に大きく貢献できます。保守性の高いコードを書くことで、後々のメンテナンスコストが下がり、改修にかかる時間も少なくなります。

どのようにして「品質視点」をスクラムに持ち込むのか

スクラム開発におけるQAエンジニアは、基本的に全てのスクラムイベントに参加し、開発前から開発後のリリースまでに関わります。

<開発前>
開発初期段階で品質視点のリファインメント
スクラム開発の初期段階では、スプリント内で着手するチケットに対する、UIUX、性能などの要求を汲み取り、仕様に落とし込みます。
例えば、入力フォームのエラーメッセージのパターンの考慮もれなどは、ユーザー体験に影響が出るので、パターンの洗い出して、チケットに加えます。

最近では、開発チーム内でチケットごとにどこまでをテストするのか、どのテストレイヤーでカバーするのか、などをチーム全体で擦り合わせる「QAリファイメント」も始めました。

これらの活動による思わぬ効果もありました。
開発者にも品質視点が共有され、開発者自身で開発中のバグ混入を防止してくれるようになってきたのです。
とある日のレトロスペクティブで、
「QAで引っかかりそうなところをあらかじめ開発中に見ることができた」と言って頂けてとても品質視点が浸透し始めてるなと手応えを感じました。

<開発中>
バグ頻出ポイントやチケット間の依存を予測して、開発エンジニアへの注意喚起やナレッジ蓄積

これも、先ほどの「全ての開発チケットのステータスを全て追っている」強みを活かし、「画面遷移時の状態保持でバグがよく出る」とか「過去に開発したチケットの対応を新規ページにも適応しなければならない」とか、開発エンジニアだけでは気づきにくい点を共有することができます。
また、チケット間の依存がある場合は、「開発中のこのチケットは、こっちを先にリリースしたいから連携してね〜」など、エンジニア間の連携を促したり、コミュケーションのハブにもなれます。

また、ユーザー向けのメールの送信ロジックと本文をリスト化し、メール関連の機能開発時にどのメール種別に対応が必要かどうかを検討しやすくするなど、チームの仕様整理やナレッジづくりにも貢献できます。

<開発後>
受け入れテストを実行し、バグの修正〜リリースまでを管理

QAエンジニアの作業として、一番大きな時間を占めるのが、テストです。
基本的には、開発者が行っている単体テストや結合テスト、E2Eなど自動テストではカバーできない範囲の手動テストをおこないます。
リリース前のUATとして、シナリオテストや探索テストなどをしています。開発後に実際にできたものを触り、バグやUIUXの問題点がないかをチェックします。
UATで行うテストケースは、開発エンジニアが開発中に設計して、NotionのDBにて蓄積しています。

最後まで、作ったものにドンと胸を張ってリリースができるよう、チーム内での調整をして、見届けます。

以上が「品質視点」をスクラムに持ち込むために行なっている活動です。
まだまだ改善の途中で、週ごとのレトロスペクティブなどでチームメンバーとスプリントごとに課題を見つけながら、「今週はチケットに品質のチェック項目を追加してテンプレート化してみましょう」とか「バグの報告はlinearのチケットに集約した方が、開発に回しやすい」など、試行錯誤しています。

組織の壁を乗り越える存在になる

これはQAエンジニアとして、自分自身も力を入れていきたい部分になります。
先にも述べた通り、ソフトウェアの品質というのは多岐に渡ります。
だからこそ、得意な人に任せることが大切です。

例えば、ユーザーについて一番理解しているのがCSであり、デザイナーは「使用性（UI・UX）」のプロであり、「コードの保守性」はプログラマーが得意とする領域です。

QAエンジニアの立ち回りとしては、彼らとコミュニケーションをとりながら、
「ここまではやる」というプロダクトとして担保すべき品質を見定めていきます。

他にも、日時リリース報告を専用slackチャンネルで報告する取り組みも、チームメンバーと話す中で必要だと判断して新たに始めました。こちらはCSや編集チームなど他部門のメンバーからのフィードバックをもらう窓口として機能しています。
リリースした機能が、成果をあげているかどうかの検証・フィードバックの吸収体制の強化も今後も力を入れていきたいところです。

QAエンジニアはおもしろい

ここまで、1人目のQAエンジニアとして、知っておきたいことをテーマに、ブログを書いてきましたが、最後にお伝えしたいのは「QAエンジニアはおもしろい」ということです。

開発チームの中で、より幅広い視点でプロダクトを見ることになるので、スクラムマスターやPdMに頼られる補佐役にもなれるし、自らがプロダクトに大きな影響を与えるキーマンにもなれるのがQAエンジニアだと思います。

QAエンジニアの立ち回り
自分自身これまで、フロントエンジニアとして、ソフトウェア開発に関わってきましたが、いつも課題に感じていたことがあります。

• 動くものを作ったは良いけど、後からバグがいっぱい出る ＝「品質視点の欠如」
• 上流と下流の連携不足で開発が円滑に進まない ＝「組織の壁」

QAエンジニアは、このようなプロダクト開発の課題解消のために縦横無尽に駆け回り、チーム開発にインパクトを出せるのが最大の魅力です。

今後の展望

Otonamiチームにおいては、サービスの成長とともに、システムの規模も組織も大きくなってくるフェーズかと思います。今自分が「1人目」のQAエンジニアとして進めている活動を、組織的にQA行えるような体制を作っていきたいと考えています。

特にやっていきたいのは以下の三つです。

• 「J-CATの品質基準を作る」

  J-CATのサービスは世界観も独自で、高級なイメージのあるブランドであるので、それに見合った品質の基準を作って開発組織内で浸透させていきたい。

• 「自動テストの強化」
  手動テストは無くならない、とはいえ自動テストは強力です。リグレッションテストや負荷テストなど、安心してプロダクトをリリースできる仕組み強化していきたいです。

• 「位置決定の上流まで関われるQA」
  ユーザー視点でこんな機能があるべき、品質的に優先的にこの課題に対処すべきなど、QAだからこそ気づけることもあると思います。そんな時に組織の中でステークホルダーとの調整ができ、実現まで持っていけるQAエンジニアが究極形態だと個人的には思っています。

最後に

私が、QAにアサインされたのもJ-CATの事業と組織が成長し、拡大期を迎えようとしているという事業のフェーズによるものが大きいと思います。

テックリードの前田ともよく話すのですが、目指すべきQAの姿は組織やプロダクトによって異なるし、ひいては同じプロダクトでもフェーズや機能によって変わってくるよねと。今のJ-CATにとってどんな品質が求められるかは、自分たちで探っていくものであると。

「プロダクトにとって何が必要か」を考える姿勢はJ-CATのプロダクトチームが理想とする「プロダクトエンジニア」の概念とも共通しています。
こちらに興味のある方は、前田の過去の記事をご覧ください。
https://zenn.dev/jcat/articles/12cf711dba1c79

またJ-CATのプロダクト開発に興味を持ってもらえた方はぜひこちらも、覗いてください。
https://www.wantedly.com/companies/company_5019094/post_articles/907188

QAエンジニアに関わらず、プロダクトの成長のために何が必要かを考えながら、仲間と一緒に、日々働けたら良いなと思っています。