QAエンジニア

ポジション概要

Regaraは、ライフサイエンス業界向けの臨床・薬事インテリジェンスプラットフォームです。医療機器、製薬、バイオテクノロジー企業が、製品を市場に出すために必要なもの — 薬事戦略、臨床試験プロトコル、試験報告書、申請資料 — を複数の市場にわたって計画・準備するために当社を活用しています。

AIそのものがプロダクトです。当社は、リアルタイムのデータを調査し、それに基づいて推論し、完全な技術文書をエンドツーエンドで作成する自律エージェントのプラットフォームを運用しています。そのため品質は本質的に難しい課題です。出力は固定ではなく生成されるものであり、同じ入力でも2回で異なるテキストが生成されることがあり、最終成果物は顧客が規制当局に提出する文書です。

一般的なQA業務との違い。ここでの欠陥は、ずれたボタンではありません。誤った数値、根拠のない主張、あるいは引用元が引用内容を裏付けていない引用です。生成された文書は、流暢で、体裁が整っていて、それでも誤っていることがあります — 画面上には何の兆候も現れません。顧客より先にそれを見つけることが、この仕事です。

これは品質に専念するポジションです。テストサイクルの合間にプロダクト機能を開発するための採用ではありません。当社で最も難しい品質課題に、全神経を注げる人が必要だからこその採用です。探索的テストや自ら作成するテストケースから、欠陥の追跡、本番環境での修正確認まで、担当するテスト領域をエンドツーエンドで担っていただきます。

実際に取り組む業務

01 · 探索的テストと機能テスト

顧客と同じようにプロダクトを使い、そのうえで弱点を探し出します。

• ディスパッチフロー、結果ビュー、管理ツール全体で機能テストとUI/UXテストを実施する。
• 境界を探る — 空の状態、過大な入力、中断された実行、権限、ブラウザやビューポートの違い。
• 画面単体ではなく、顧客が実際に使うワークフローをテストする。
• リリースごとに再テストし、デグレードを検出する。

02 · テスト設計と回帰テストのカバレッジ

得た知見を、個々のリリースを超えて使い続けられる再現可能な仕組みに変えます。

• 主要なユーザーワークフローを網羅するテストケースとチェックリストを作成・維持する。
• リリース前にチームが実行する回帰テストスイートを担い、プロダクトの変化に合わせて最新に保つ。
• プロダクト全体に対するカバレッジを可視化し、どこにギャップがあるかを率直に示す。
• テストしやすさではなくリスクで優先順位を付ける。重要度の低い領域を手厚くカバーし、重要な領域を何もカバーしていないスイートは、カバレッジがあるように見える分、スイートがないよりも悪い。

03 · 生成された出力の検証

この仕事で最も面白い半分であり、確立された手法がない部分です。

• 生成された成果物の内部整合性を確認する — 数値、相互参照、セクションの網羅性、書式。
• エージェントが生成した識別子や参照を、正式な情報源と照合する。
• 根拠のない主張、誤った帰属、そして引用している記述を内容が裏付けていない引用を指摘する。引用の完全性は、このプロダクトにとって最も重要な品質特性です。
• ゴールデンサンプルに照らして出力を評価し、その結果を評価スイートにフィードバックする。
• 出力が非決定的な場合にも機能するテスト手法を設計する — 「期待どおりの文字列が出力されたか」が適切な問いではない場面で。

04 · 欠陥の報告とトリアージ

バグレポートは成果物です。読んだ人が追加の質問をせずに対応できるように書いてください。

• 最小限で確実な再現手順を切り分ける — 「たまに壊れる」ではなく。
• 再現手順、期待結果と実際の結果、環境、そして根拠を示せる重大度を添えて報告する。
• 欠陥を、それが損なう要件やワークフローまでさかのぼって特定する。
• コードのバグとモデル品質の問題を見分ける。担当者も修正方法も異なり、振り分けを誤ると全員の1週間が無駄になります。
• 修正が検証されるまで、一つひとつを追跡する。

05 · リリース検証と品質シグナル

リリースが安全かどうかを判断し、しかもその判断が正しい人が必要です。

• リリース検証を実施し、ビルドがリリース可能かどうかについて明確で根拠のある見解を示す。
• 品質シグナルを継続的に追跡する — 欠陥の傾向、流出率、そしてプロダクトのどこで問題が繰り返し発生しているか。
• 誰も聞きたくない内容も含め、品質の状況をエンジニアリングに書面で報告する。
• リリースの状況が悪化しているときは早めに警告を発する。遅すぎる警告は、ないのとほとんど変わりません。

06 · テスト自動化

手作業で行っている確認を、自動で実行されるチェックへ移行します — 効果が本当に見込める部分で。

• バックエンドのカバレッジをpytestで、フロントエンドのカバレッジをVitestとReact Testing Libraryで拡充する。
• 最も利用頻度の高いワークフローについて、ブラウザレベルのエンドツーエンドテストを作成する。
• テストスイートをGitHub Actionsに組み込み、マージ後ではなくプルリクエストの段階で失敗が表面化するようにする。
• 自動化は慎重に判断する。誰も信頼しない不安定なスイートは、置き換えた手動テストよりもコストがかかります。

技術スタック

• バックエンド — Python 3.12, FastAPI, SQLAlchemy 2.0, Pydantic v2, Postgres / SQLite, pytest
• フロントエンド — React 19, TypeScript (strict), Vite, TanStack Router + Query, Tailwind, shadcn/ui, Vitest + RTL
• AI — 最先端LLM API（Claude）、MCPツールサーバー、RAG、評価ハーネスおよびゴールデン出力による採点
• インフラ — AWS（ECS/EC2, ECR, SQS, S3）, Docker, GitHub Actions

すべてを知っている必要はありません。テストの大半はコードベースではなくアプリケーションに対して行います — ただし、バグの原因を追うときに読むのも、自動テストスイートを拡張するときに書くのも、これらの技術です。

応募資格

必須要件

• QA、ソフトウェア品質、またはテストエンジニアリングの職務で約2〜5年、実際のユーザーがいる実際のプロダクトをテストした経験。
• コンピュータサイエンス、コンピュータ工学または関連分野の学位 — または同等の実務経験。
• 少なくとも1つの言語でコードを読み書きできること。PythonまたはTypeScriptが当社のスタックに最も近いですが、Java、C++など他の言語でも問題ありません。
• 読み込めないページだけでなく、わずかに誤った値にも気づける注意力。
• 明確な技術文書を書く力。私たちはあなたのコードよりもバグレポートを多く読みます。
• 一次情報 — 仕様書、規格、APIコントラクト — を読み、実装がその記述どおりかを正確に確認できること。
• 曖昧な状況でも筋道立てて対応できること。漠然とした報告をそのままエスカレーションせず、最小限の再現手順に絞り込めること。
• 少なくとも1つのテストフレームワーク（pytest、Vitest、Playwright、Seleniumなど）の実務経験。
• Gitとプルリクエストのワークフローに慣れていること。
• リリースを止める覚悟があること。このポジションでは、関係者が待っている中でもビルドの準備ができていないと伝えなければならないことがあります。それを伝えることこそが仕事です。
• ラスベガスでフルタイムの出社勤務が可能であり、米国での就労資格を有すること。

歓迎要件

• AIやLLMが生成した出力のテスト経験、または評価ハーネスの構築・運用経験。
• 規制産業（医療機器、製薬、臨床研究）での経験、または21 CFR Part 11、GxP、コンピュータ化システムバリデーションの知識。
• 画面経由だけでなくデータを直接検証できる程度のAPIテストとSQLのスキル。
• CI/CDの経験、特にGitHub Actions。
• アクセシビリティテスト、またはパフォーマンス・負荷テストの経験。
• テストプロセスが存在しなかった組織でプロセスを立ち上げた経験。
• スタートアップでの経験、およびプロセスが整う前の段階でも柔軟に動けること。

私たちの開発スタイル

• 見栄えの良い1つの例だけで出荷することはありません。プロンプト、検索、ツールの変更はすべて、顧客に届く前に回帰テストスイートと採点済みの出力セットで評価されます。私たちは数値に基づいて改善を重ねます。
• 本番までのサイクルが速い。入社1週目からステージング環境でテストを行い、あなたが報告したバグはすぐに修正されるため、修正の確認も自分で行えます。
• テスト領域をエンドツーエンドで担います。探索的テストや自ら作成するテストケースから、自動化と欠陥追跡、本番環境での修正確認まで。誰かが実行用のスクリプトを渡し、考える部分を取り上げるようなことはありません。
• 少人数のチームで直接協働。創業メンバーのエンジニアリングチームと並んで働き、あなたが作成するすべてのプルリクエストにコードレビューが入ります。
• 最先端で開発しています。新しいモデルのリリース、コンテキストやキャッシュの機能、エージェントツールを登場と同時に追い、より優れていればそれに合わせて作り直します。ここで学ぶことは常に最新です。

期待される成果

• 欠陥は顧客ではなくステージングで見つかり、流出率は低下傾向にある。
• 捏造された、誤って帰属された、あるいは根拠のない引用は、顧客の目に触れる前に社内で検出される。
• スイートが重要な部分をカバーし、不安定でないため、回帰テストのグリーンが本当に意味を持つ。
• バグレポートが追加の質問なしで対応される。
• カバレッジのギャップはインシデントで発覚するのではなく、事前に把握・明示されている。
• モデル品質の問題とコードの欠陥が、最初から適切な担当者に届く。
• リリースの判断には根拠があり、エンジニアリングがあなたの見解を信頼している。

このポジションが存在する理由

従来のQAは、照合できる正解があることを前提としています。ここではシステムが毎回新しいものを書き、典型的な失敗は、完璧に読めるのに自らの引用が裏付けていない主張を含む文書です。これはアサーションを追加すれば解決する問題ではありません — 規制当局と同じ目で出力を読める人が必要です。それがこのポジションです。