シニアQAエンジニア

必須

• 実務経験：ソフトウェア開発または品質保証の実務経験（8年以上を目安）
• プログラミング能力：テストおよび本番に隣接するコードを読み、レビューできること。加えて、開発者が使うツールやシステムを自ら設計・実装した経験（ノーコードツールの利用経験のみでは要件を満たしません）
• テスト戦略の実績：テストケースの作成・実行にとどまらない、リスクベースのテスト設計・戦略立案の実務経験
• 仕組みを他者に渡した経験：自分が作った型・ツール・プロセスを、自分が関与しなくても他者が使い続ける状態まで持っていった経験
• 組織を越えて変更を通した経験：自分の所属組織の外に対して、基準やプロセスの変更を提案し、意思決定者を動かして実際の変更まで到達させた経験
• クロスファンクショナルな推進経験：開発・PdM・デザインなど職種の異なるメンバーが関わる取り組みを、推進役として進めた経験
• AIリテラシー：LLM／MLモデルの仕組み（学習、バイアス、検証、非決定性）の実務レベルの理解。加えて、AIを組み込んだ仕組みを設計・構築し、運用した経験と、非決定性を前提に品質を判定する方法を設計できること
• コミュニケーション能力：アーキテクチャやプロダクトの議論に影響を与え、品質リスクを技術者以外のステークホルダーに伝えられること
• アジャイル・スクラムなどの開発手法に関する実務経験
• 日本語での円滑なコミュニケーションが可能であること（JLPT N1を超えるレベル）

歓迎

• AI／LLM機能やエージェント型システムの検証経験（評価データセット、LLM-as-judge、敵対的テスト、ドリフト監視）
• テスト設計システム・テスト生成基盤の構築経験
• 品質メトリクスの設計と、それを意思決定に接続した経験
• プロダクト分析の実務経験（計測イベントの設計、ファネル・コホート分析、A/Bテストの設計と解釈など）
• セキュリティーリテラシー（プロンプトインジェクション、データポイズニングなどAI固有の脆弱性を認識し、セキュリティー組織と協働できる程度）
• オブザーバビリティのエンジニアリング（ロギング、トレーシング、メトリクスによる根本原因分析）
• エージェント相互運用の標準（MCP、A2Aなど）への知見
• 難易度の高い業務ドメインの知識（経理、契約、データ品質など）
• ビジネスレベルの英語力があればなお可

求める人物像

• 準備が整うのを待たずに着手し、状況が変われば目標やスコープの変更を自ら提起できる方
• 職位や等級に関わらず論点を出し、品質上の懸念を決定が変わりうる段階で明示的に伝えられる方
• 解き方に入る前に「何が変われば解けたと言えるか」を定義し、与えられた枠組み自体を問い直せる方
• 作ったものを「作った」で終わらせず、使われて効果が出ているところまで見届けられる方

使用ツール

業務内容

• 本ポジションでは、プロダクトを横断して品質基盤作りに関わることで、品質の向上とその維持を目指します。

担当プロダクト・領域例

• Sansan：名刺や企業情報、営業履歴を一元管理して全社で共有できるようにすることで、売上拡大とコスト削減を同時に実現する営業AXサービス
• Eight：価値ある出会いをつなぐ、ビジネスのための名刺アプリ
• Bill One：請求書受領、経費精算、債権管理といった、さまざまな業務領域の課題を解決する、経理AXサービス
• Contract One：契約書をはじめとする取引書類をデータ化し、取引の条件や変遷を可視化することで、機会の損失や信用の低下を防ぎ、企業の利益を守る、契約AXサービス
• Sansan Data Intelligence：企業内外のデータを統合し、ビジネスデータベースとして活用するための顧客マスターマネジメント
• いずれの領域も事業成長に合わせて組織規模が拡大しており、フェーズも技術構成も異なります。担当領域は選考を通じて、希望と経験を踏まえて提案します。

組織のミッション

• 技術本部は、AIを前提とした組織・開発プロセスへの転換を進めています。その一環として、2026年から品質保証の責務を再定義しました。
• 機能検証（実装が仕様どおり動くかの確認）は開発者が開発フローの中で完結させ、品質領域のエンジニアは妥当性確認（正しいものを作れているかの評価）と品質エンジニアリング（品質をプロセス・アーキテクチャ・組織設計に組み込む活動）を担います。
• テストの「実行」は開発者・自動化・AIへ移り、品質領域の重心は、設計・評価・計測の仕組みづくりと、開発者が自らテストを持てるようにする支援へ移ります。
• この転換を支える仕組みは、すでに一部が形になっています。AIを使ったテスト設計支援システム、テスト生成パイプライン、E2E自動テスト基盤、仕様と実装の差分から不具合を検知する仕組みなどを構築し、複数のプロダクトで稼働させています。一方で、再定義した責務を各プロダクトでどう担うかはまだ形になっておらず、仕組みとして確立されていない領域が広く残っています。
• この領域を担当プロダクトの中から形にし、プロダクト横断の仕組みへ広げていく人材を募集します。

具体的な業務

• コードの相当部分がAIによって生成される前提で、テストの「実行」ではなく品質の「成果」に責任を持ちます。担当プロダクトの状況に応じて、以下の重心が変わります。

リスクベースの妥当性確認と品質戦略

• 受け入れ基準の定義、リスクの見積もり、検証範囲の選定と残余リスクの明示
• 開発が保証する範囲と品質領域が保証する範囲の線引きの設計と、関係組織を巻き込んだ確立
• 個人の力量ではなく仕組みとして回る状態への転換と、隣接するチーム・プロダクトへの展開
• 同種の問題が再発しない構造に手を入れる（個別の不具合対応で終わらせない）

テレメトリに基づくプロダクトの価値検証と改善

• 機能要件のレビューで、テレメトリ（利用状況や品質の計測データ）をエビデンスとして要件の前提や優先度の妥当性を問う
• 開発案件に、達成を判定できる成功指標が設定されているか、価値仮説と指標が整合しているかの企画段階での確認
• 出荷後に期待した効果が得られているかの評価と、データを根拠にした改善提案のプロダクトへのフィードバック

開発者の自律的なテスト所有の実現

• テスト設計の型・ガイドラインの整備と引き渡し
• 受け手の前提確認、運用の担い手の確定、自走判定、不要になった仕組みの停止判断
• テスタビリティを設計時の要件として扱える状態づくり

テスト生成・実行の仕組み構築

• AIによるE2Eシナリオの半自動生成と、生成から実行までの反復システム化
• 単体・結合・E2E各レイヤーの重複と抜けの判断、層配分の設計
• ノーコードツール依存からの移行設計と完遂

品質を数値で判定できる状態づくり

• プロダクトのフェーズとニーズに応じた品質指標の選定・定義
• 計測の自動化、ベースラインの設定、品質ゲートの構成
• 投資や優先度の判断に品質観点を持ち込む仕組みづくり

AI・自動化の編成と、出力の品質判定

• リスクベースのテスト選択の構成、AI生成物の合否基準の明文化
• 品質領域・開発・AI・パートナーの役割配分の設計
• 非決定的な出力（AI／LLM機能）の検証（一貫性・頑健性・バイアス・ドリフト）

本ポジションの魅力

• 転換の当事者になれます。責務境界の再定義が進行中であり、型が固まっていない領域が広く残っています。決まったものを運用する仕事ではありません
• 五つのプロダクトを横断するため、広い視野が得られます。フェーズも技術構成も異なる製品群で、共通の型と製品固有の判断の両方を扱います
• 主務と横断の両方に足を置けます。特定プロダクトに閉じた最適化にも、現場を知らない横断論にも陥りにくい構造です
• AI活用が構想ではなく実装として動いています。稼働中のシステムの上に積む仕事です

組織構成

• 主務と兼務の二重所属です。
• 主務：各開発組織に所属し、プロダクトの品質向上、担保を内側から担います。日常のマネジメントと評価は所属開発組織が行います
• 兼務（約10%）：Quality Assurance CoP室（CoP：Community of Practice／実践共同体）に所属し、プロダクト横断のナレッジ・型・計測の仕組み・テスト設計システム・コミュニティーに関与します
• Quality Assurance CoP室は、プロダクトの垣根を越えて品質の共通課題を解決するための横断組織です。各開発組織に品質基準やプロセスを強制する立場ではなく、選択肢・型・計測の仕組みを提供します。技術評価・キャリア評価における専門性観点の補完も担います。

開発環境、使用するツールなど

• 開発言語：TypeScript, JavaScript, Python, C# など
• テスト自動化：Playwright など
• インフラ：Google Workspace, GCP（Google Cloud Platform）, Microsoft 365, Notion, Azure など
• ソースコード管理：GitHub
• AIツール：Claude Code, Codex, GitHub Copilot, Notion AI, Google Gemini, Cursor など