今、アーキテクトとして品質保証にどう関わるか

今、アーキテクトとして品質保証にどう関わるか NEALLE 2026.2.16 QA engineer at a Startup vol.25
野呂編株式会社ニーリー野呂有我

目次 1｜自己紹介 2｜プロダクト紹介 4｜ARCHチームのミッション 5｜自動テスト基盤構築の意思決定 8｜今取り組んでいること 2 11｜まとめ
7｜自動テスト基盤の構築

3 1｜自己紹介氏名所属経歴野呂有我／ Yuga NORO
  株式会社ニーリー  プラットフォーム本部アーキテクチャチーム   ・大学院時代に友人と楽譜販売サービスを立ち上げ  ・その後、SIer企業に参画  ・副業としてニーリーでいくつかの開発に携わる  ・フリーランスを経て、ニーリーへ  ・ニーリーではアーキテクチャグループのGMとして  　技術側の意思決定などを行っている 

4 2｜プロダクト紹介

Park Direct for Business 法⼈向け⽉極駐⾞場の探し‧契約‧⽀払い‧管理サービス 3｜プロダクト紹介

アーキテクチャチームとは？ • アーキテクチャチームのメインミッションは「デリバリーの高速化」 • 「デリバリーの高速化」には色々な要素が含まれている ◦ 開発生産性の向上のような指標から、成長・DXのような文化的な側面まで • そのうちの一つに「変更障害率の低下」も含まれている •
また「テストピラミッド」は、ユニットテストなど開発側の要素も多く含まれている • → QAチームからでは手が出しにくい領域もあり、弊社ではアーキチームがSETを内包している 4｜ARCHチームのミッション

自動e2eテストの導入 • e2e自動テストの導入は3年以上前に遡る • 当時、２週間に1度のリリースの度にリグレッションテストを行っていた ◦ その時点で、全体のリグレッションを行うのに1日〜2日かかっていた • フロー効率の改善のため、リリース頻度を高めたいがこのリグレッションテストがボトルネックになりつつあった
• → e2eリグレッションテスト自動化の機運が高まる！ • そして、その時は基盤作成ではなく、ノーコードSaaSを選択した 5｜自動テスト基盤構築の意思決定

自動テスト基盤の開発のモチベーション • ノーコードSaaSは、素早く少人数でe2eテストを導入したいというニーズに合致！ • F氏の尽力によりe2eリグレッションテストは自動化された！ • しかし、時を経て以下のような課題感が出てきた ◦ メールを介するフローや複雑な操作が必要な箇所が沢山あり、それを制御するために中にJavaScriptを書く必要があった
▪ ノーコードツールのe2eテストに挿入されたJavaScriptはレビューする方法もコードをバージョン管理する方法もない ◦ テストを実行するたびにコストがかかった ▪ 課金対象がテストの実行回数だった ▪ 最初は問題なかったが、リリース頻度が増えると高額になっていった • この頃にはもう、リリースが1日に数回あるというのも珍しくなくなっていた 6｜自動テスト基盤構築の意思決定

自動テスト基盤の構築 • → JavaScriptの量と、コストの高さが分水嶺を超えたため、基盤作成を決意 ◦ 今後のマルチプロダクト化を支えるスケーラブルなテンプレートとしても期待があった • 自動テストをコードで管理する方法として、PlaywrightとGithubを選択 • テスト基盤として以下を用意
◦ テストシナリオ（Playwrightコード） ◦ テストをGithub Actionsで実行するワークフロー ▪ STG環境では定期実行と手動実行 ▪ DEV/Feature環境では手動での実行に対応 • すると…コストは1/10以下に！実行時間も80%短縮！ • 複雑なJavaScriptが記載しやすくなったことで、カバレッジも向上、フレーキーテストが減少 • また、アーキテクチャチームがそれをメンテすることで、プロダクト側の実装の問題に気づいたり、修正したりできるようになった 7｜自動テスト基盤構築

自動テストの自動生成 • 通常e2eテストはテストピラミッドの頂点に位置し、一般には多くなりすぎない方が良いとされている ◦ メンテナンスコストが爆発する！ • しかし、フレームワークのバージョンアップや、共通ソースコードの変更など、通常のリグレッションテストよりも網羅的にe2eテストをしたくなることは、割とある ◦
これまでは、その際は足りない部分を人手で補っていて、１週間程度かかることも珍しくなかった • とはいえ、そのためだけにe2eテストを増やすと、作成コストもメンテナンスコストもペイしない…事が多い • が、LLMの登場で事情が変わってきている 8｜今取り組んでいること

自動テストの自動生成 • これまで人間が手で実行していたリグレッションテストのシナリオを基に、 LLMにPlaywrightのコードを自動で生成させる ◦ 怪しいところだけ人間が見る ◦ → 通ることが確認できたら、エビデンスだけ残してメンテせずに破棄する •
この方法で、詳細なリグレッションテストの工数を簡略化 • まだ完全にワークしているわけではないが、そこそこの精度で生成できるようになってきた • → これまでそこに裂かれていたQAチームの労力や、開発者の労力をより本質的な業務へ • また、新しいプロダクトのe2eテストも、自動生成によって高速に準備できるようになってきている ◦ 今後のマルチプロダクト化を支えるスケーラブルなテンプレートとしての期待（再掲）に応えられている？かも 9｜今取り組んでいること

自動テストの自動修復 10｜今取り組んでいること • 自動生成の応用で、失敗したe2eテストをLLMが分類 → 修正 → 回帰テスト ◦ フリーキーなものやテスト側の問題と思われるもの（セレクタの変更など）は、
ある程度自動で修正PRが作られるように ◦ 回帰テストで失敗したものはPRを作成しないようにしているので、通ったものだけが上がってくる • これにより、SET自身の工数も削減し、より本質的な業務に集中できる環境が整ってきた

まとめ 11｜まとめ • ニーリーではアーキテクチャチームとして、SETの領域に取り組んでいる • 規模の拡大に伴ってノーコードSaaSから自前の基盤へ移行した • 移行により、コストの大幅な削減と作成の効率化ができるようになった • また、LLMを使ってテストを大量に自動生成したり、テストを自動で修復できるようになった
• 開発者とQAが協力してSET領域に取り組むと、相乗効果で色々いいことがある！

ニーリーでは、QA / ARCH はもちろん、他のポジションも積極採用中です！ https://jobs.nealle.com/ We are hiring!!!

Thank you 15

今、アーキテクトとして品質保証にどう関わるか

今、アーキテクトとして品質保証にどう関わるか

Nealle

More Decks by Nealle

Other Decks in Programming

Featured

Transcript