株式会社カウシェのDev005_QAエンジニア / 正社員の求人

募集背景

カウシェは2026年7月に累計700万ダウンロードを突破し、ピボット後約3年でGMV35倍・売上総利益411倍・DAU81倍という急成長を遂げてきました。

この成長を支えているのが、開発の速度です。1日5〜9回のデプロイ、月間12回の施策リリース。1人あたりのデイリーPR数は約1年で1.1本から4.6本へと4倍を超え、全PRの83%をAIレビューのみでマージできる体制を実現しています。

一方で、この速度に品質保証を追従させるには、テストのあり方そのものを変える必要があります。現在のQAは業務委託メンバーによる体制で、日々のリリースは問題なく回っています。ただ、これから先——リリース頻度がさらに上がり、EC・ゲーミフィケーション・ソーシャルが絡み合うプロダクトの複雑性が増していく中で必要になるのは、テストを実行する体制ではなく、エンジニアリングによって品質を担保する仕組みです。

そこで今回募集するのが、SET（Software Engineer in Test）です。テスト設計から自動化基盤の構築、CI/CDへの組み込みまでを、自らコードを書きながら進めていただきます。

現在はQA責任者の亀井が中心となり、AIを活用したテスト自動化のトライアンドエラーを進めている段階です。テスト戦略も自動化基盤も、まだ「型」ができあがってはいません。裏を返せば、カウシェの品質保証をどう設計するかを、これから一緒に決めていけるということです。

なお、QAとしての実務経験は必須ではありません。バックエンドを中心とした開発経験があり、品質やテストに関心があれば、QAの知識は入社後に身につけていただけると考えています。

プロダクトの特徴

カウシェは発見型ソーシャルECアプリです。

発見型ECとは、従来の「ほしいものを検索して買う」検索型ECとは真逆で、「なんとなく眺めているなかで、ほしいものを発見して買う」という体験を提供するECを指します。
セール商品との偶然の出会いや、レビュー・クエストなどの参加型機能を通じて、買い物が「単なる購入」を超えて感情を動かす体験になる場をつくっています。

2026年7月に累計700万ダウンロードを突破し、ユーザーは全国にまんべんなく広がっております。特徴的なのは、これまでECをほとんど使ったことがない40〜50代の女性に多く利用いただいている点です。

「カウシェファーム」という作物育成ゲームや、「みんなの投稿」という投稿機能など、日常的に楽しめる要素が豊富にあることが強みとなっており、1日平均38分・月20日以上という高い頻度で利用していただいているユーザーが多く、これまでのECユーザーとはまったく異なる行動が生まれています。

プロダクトの目指す世界

カウシェは「日常に楽しさを」をミッションに、「新しい生活圏のカタチ」をつくります。

検索と最適化に寄りがちなECでのお買い物体験に、発見や偶然、ほどよいにぎわいといった人間らしい豊かさを取り戻すことが狙いです。ふらっと立ち寄れば気になるものが見つかり、知人の姿に安心し、つい滞在したくなる。駅前や商店街のように、人が自然と集まり生活のリズムに溶け込む拠点を、ソーシャルとエンタメとコマースの掛け算で形にします。情報収集も遊びも買い物も同じ動線の中でゆるやかにつながり、作業となってしまっていたお買い物はいつしか楽しみへと変わります。

2023年の事業転換以降、約3年でGMV35倍、売上総利益411倍、DAU81倍を達成。

変化を力に変えてきた私たちは、人数に依存しない運営モデルで常識を更新し続けます。目指す姿は、1億人に1億通りの楽しみが巡る生活インフラです。社員100人で企業価値1兆円に挑み、10年後に小売の主役となるべき生活圏を自分たちの手で切り拓きます。

SETというポジションについて

SET（Software Engineer in Test）は、テストを実行する役割ではなく、テストの仕組みをエンジニアリングでつくる役割です。

私たちはSETを「開発者を顧客とするエンジニア」と定義しています。エンドユーザーに向けてプロダクトの品質を見るのではなく、開発者が速く安全にリリースできる状態をつくることが、このポジションの成果です。これはGoogleがEngineering Productivityで示してきた考え方に近く、テストの目的を品質そのものではなく、開発の速度に置く立場です。

ただしカウシェは社員100名を目指す組織であり、大規模組織の型をそのまま持ち込むつもりはありません。この規模・この速度で何が機能するかは、あなたと一緒に決めていきます。

なお、テストコードは開発者自身が書きます。SETがすべてのテストを書く体制は取りません。SETの役割は、開発者がテストを書きやすい基盤・パターン・仕組みを用意することです。

一方で、入社直後から仕組みづくりだけに専念していただくわけではありません。

カウシェファーム・EC・広告が絡み合うプロダクトの挙動は、仕様書を読むだけでは掴めません。自分で触ってテストしてみて初めて「ここは壊れやすい」「この確認は自動化する価値がない」といった判断がつきます。立ち上がり期には既存メンバーと一緒に手を動かしてテストを実施していただき、そこで得た気づきを、何を自動化し何を捨てるかの設計に還元していただきます。手を動かすこと自体が目的ではなく、仕組みを設計するための一次情報を取りに行く、という位置づけです。

日本ではまだ職種名として一般的ではありませんが、実態としては「バックエンドエンジニアとして開発をしながら、テストコードや自動化基盤に踏み込んできた」という経験に近いものです。ご自身のスキルシートに「SET」と書いたことがなくても、テストコードを書き、設計に踏み込んできた経験があれば、十分に活きるポジションです。

カウシェが求めているのは、QAの手法に詳しい方よりも、ソフトウェアの構造を理解した上で、品質を仕組みとして担保できる方です。

業務内容

EC・ゲーミフィケーション・ソーシャルが絡み合う複雑なプロダクトにおいて、要件定義からリリースまでのプロセスに一貫して関わり、エンジニアリングによる品質向上を担っていただきます。

① テスト自動化基盤の設計・構築
リグレッションテストをはじめとするテストの自動化基盤を、自らコードを書いて構築します。CI/CDパイプラインへの組み込みまで含め、高速なリリースサイクルを支える土台をつくります。

② テスト設計と品質戦略の策定
プロダクト価値を高めるための「あるべき品質」を定義し、保証の仕組みを設計します。どこを自動化し、どこを手動で担保するか。その線引きから設計していただきます。

③ AI NativeなQAプロセスの確立
コードの大部分をAIが生成する開発組織において、従来のQAプロセスはそのまま適用できません。AIを活用したテスト項目の作成・仕様把握の効率化を実践しながら、AIが生成したコードをどう担保するかを含めて、プロセスを組み直します。

④ シフトレフトの推進
仕様検討・設計の段階からプロジェクトに加わり、QAの観点で仕様の矛盾や考慮漏れを指摘します。不具合を作り込む前に防ぐことで、手戻りのコストを削減します。

⑤ 開発チームへの品質観点の浸透
テストを一人で抱えるのではなく、開発チーム全体が品質を担保できる状態を目指します。テストコードの書き方や設計の考え方を、日々の開発の中で共有していきます。「SETがテストを書く」のではなく「開発者がテストを書ける」状態をつくることが成果です。

このポジションで向き合う難題

EC×ゲーム×ソーシャルが絡み合う複雑な状態遷移

カウシェでは、購買・ゲーム・SNS投稿・AIレコメンドが一つのアプリの中で影響し合います。カウシェファームの作物育成ロジック、ソーシャル連携、セール連動——複雑な状態遷移を伴う機能の品質保証は、一般的なECアプリとは次元の異なる難しさがあります。

1日最大9回のデプロイに追従するテスト設計

高速なリリースサイクルの中で「テストが開発の足を引っ張らない」仕組みを設計する必要があります。何を自動化し、どこに時間をかけ、どこを割り切るか。優先順位の判断そのものが問われます。

AIが生成したコードの品質をどう担保するか

全エンジニアがAIを活用してコードを書く環境では、従来のQAの前提が通用しません。AIが生成するコードの特性を理解した上で、レビューとテストの役割分担を再設計する視点が求められます。

「型」がない状態からつくる

テスト戦略も、自動化の範囲も、これから決めていく段階です。整備されたプロセスに乗るのではなく、何を基準にするかから考えていただくことになります。

仕事の魅力

品質保証の設計を、ゼロから担える

すでに整った仕組みを引き継ぐのではありません。テスト戦略・自動化基盤・プロセスを、自分の判断で形にできます。「自分が設計した仕組みの上でプロダクトが動いている」という手触りを持てる環境です。

バックエンドの経験を、専門性として広げられる

開発経験を土台に、テスト自動化・品質設計という専門性を積み上げられます。AI時代において「品質をエンジニアリングで担保できる人」の希少性は上がり続けており、キャリアの差別化に直結します。

AI Native開発の最前線でQAを設計できる

デイリーPR数4倍超、全PRの83%をAIレビューのみでマージ——この環境で品質をどう担保するかは、業界にまだ答えがありません。実践しながら自分で定義できる、希少な機会です。

少数精鋭で、仕組みによって解く

カウシェは「100人で企業価値1兆円」を掲げ、人数に依存しない運営モデルを追求しています。人を増やしてテストを回すのではなく、仕組みと自動化で解くことに、組織全体が本気です。

開発環境・技術スタック

モダンな技術選定と、Google Cloudのフルマネージドサービスを徹底活用しています

• 言語：Go (100%)
• インフラ：Google Cloud (Cloud Run, Cloud Spanner, Pub/Sub, etc)
• 通信：gRPC, Protocol Buffers
• CI/CD：GitHub Actions, Cloud Build
• 構成管理：Terraform
• モニタリング：Cloud Monitoring, Cloud Logging, Cloud Trace
• 分析基盤：BigQuery, Looker Studio
• QA自動化ツール：Maestro（CI/CDへの組み込みはこれから）
• AI/LLMツール：Claude, Codex, Cursor, Gemini, GitHub Copilot, etc（全員分予算あり）
• その他：GitHub, Slack, Notion, Figma
• 開発スタイル：アジャイル開発（1日5〜9回のデプロイ、月間12回の施策リリース）

一緒に働く「人」と「技術文化」

直属上司：QA責任者 亀井 亮介

山形大学工学部にて情報工学を専攻し、卒業後はエンジニアとして活動。主にバックエンドエンジニア、プロジェクトマネージャーとして開発に従事した後、QAエンジニアへ。マネーフォワードでは本部のQA部長として、各ロールと協力しながらDevOpsチームの品質改善を主導。ISTQB Expert Levelシラバスの日本語翻訳を担当し、ISTQB Advanced Level（Test Management）を保有。現在はカウシェでQAを担当し、AIを活用したテスト自動化・QAプロセスの再設計を進めている。

担当役員：執行役員CTO 池松 恭平

東京工業大学大学院にて計算工学を修了後、2014年にDeNA入社。バックエンドエンジニア、エンジニアリングマネージャーとして、EC、SNS、ヘルスケアなどのプロダクト開発に従事。2020年から複業として参画していたカウシェに翌年5月に入社。バックエンドエンジニア、エンジニアリングマネージャー、プロダクトマネージャーを経て2023年10月より現職。

現在のQA体制と、SETの位置づけ

現在は、業務委託のQAエンジニア3名がプロダクト領域（カウシェファーム・EC・広告・オペレーション）に分かれてテストを担い、QA責任者の亀井が全体を設計しています。

既存メンバーが担っているのは「ユーザーの立場からプロダクトの品質を見る」役割です。今回募集するSETは、その手前——「開発者が速く安全にリリースできる基盤をつくる」役割を担っていただきます。両者は競合せず、補完します。

あなたは、エンジニアリングによって品質を担保する仕組みづくりの、最初の1人です。

技術文化

• メガベンチャーやTechスタートアップでテックリード・EM・CTOを経験した30代シニアメンバーが多数在籍。GoとGoogle Cloudを主軸に、高速かつ安定した開発体制を実現しています。
• 「品質を上げるからこそ速く作れる」
  • スピードと品質はトレードオフではありません。テスト、CI/CD基盤、継続的なリファクタリングを重視し、「急がば回れ」を実直に実行するスタイルです。
  • Firestore → Cloud Spannerへの移行の例
• AI Native開発の実践
  • 1人あたりのデイリーPR数が1年で1.1本→4.6本へ増加。全PRの83%をAIレビューのみでマージできる体制を実現しており、開発生産性の向上を数値で追い続けています。
  • 全PRの83%をAIレビューだけでマージできるようにした
• 事業と顧客に近い距離で開発する文化
  • PdMやデザイナーと混成で動き、事業数値やKPIの状況・対応方針を深くSyncして開発を行っています。定量数値と定性（使用感・お問い合わせ・SNS投稿・レビュー）を重視し、リリース後には定性・定量の変化を確認して次の施策に繋げていきます。

キャリアパス

まずはテスト自動化基盤の構築と品質設計に集中いただき、その後はカウシェの品質保証全体をリードする立場を想定しています。開発とQAの両方を理解した上で仕組みを設計できる人材は市場に多くありません。SREなど隣接領域へ関心を広げていくことも可能です。

入社後3ヶ月の期待値（オンボーディング）

入社直後から「放置」することはありません。明確なマイルストーンと共に、チーム全体で立ち上がりをサポートします。

• 1ヶ月目：プロダクトと開発フローのキャッチアップ：カウシェのプロダクト仕様（カウシェファーム・みんなの投稿・AIレコメンド等）と、既存のQAプロセス・テスト範囲・自動化状況を把握します。既存のQAメンバーと一緒に実際のテストを実施し、プロダクトの挙動と壊れやすい箇所を体感で掴んでいただきます。小規模な施策のQAを完遂できる状態が目標です。
• 2ヶ月目：テスト自動化への着手：特定領域のテスト自動化を、設計から実装まで自らリードします。あわせて、現状の品質課題を自分の言葉で語れる状態を目指します。
• 3ヶ月目：品質戦略の提案：カウシェのテスト戦略・自動化の優先順位について提案を行い、技術的な意思決定に関与いただくことを期待しています。

選考フローと技術課題について

お互いのミスマッチを無くすため、技術力とカルチャーの両面を丁寧に確認させていただきます。

• カジュアル面談（まずは気軽にお話ししましょう）
• 一次面接（技術・カルチャー：QA責任者・CTO / 60〜90分）
• 課題選考（技術：QA責任者＋現場エンジニア / MAX90分）
  • 課題を共有させていただき、ご自宅で取り組んでいただき、その後、ディスカッションを行う形式です。
• 最終面接（対面：CEO・COO / MAX90分）
  • 最終面接と課題選考の間に、リファレンスチェックを実施することがあります。

カウシェをもっと知る

• 採用ページ：https://enjoy-working.kauche.com/
• Company Deck：https://speakerdeck.com/kauche/zhu-shi-hui-she-kausie-company-deck
• 社員インタビュー：https://note.com/kauche
• TechBlog：https://zenn.dev/p/kauche

• テストを「実行する」のではなく、「仕組みで担保する」ことに面白さを感じる方
• 設計の意図を理解し、「なぜこうなっているのか」を掘り下げられる方
• 品質保証・テストの領域に専門性を広げていきたいと考えている方
• 「測れないものは改善できない」と考え、仕組みの効果を数字で語れる方
• AIを積極的に使い倒し、自分の仕事のやり方を更新し続けられる方
• 型がない状態から、基準そのものをつくることを楽しめる方
• 自分がやりきることよりも、周囲ができる状態をつくることに達成感を覚える方
• カウシェのミッション「日常に楽しさを」と、バリュー（変化を愛す・追い風をおこせ・成果でつなげ・好きを大事に）に共感いただける方

• バックエンドを中心としたソフトウェア開発の実務経験
  • 経験年数は問いません。ご自身が書いたコードについて「なぜこの構造にしたのか」「どこが壊れやすいのか」を自分の言葉で説明できることを重視します（特定の設計思想に関する知識の有無は問いません）
• テストコードを書き、テストしやすさを理由にプロダクションコードの設計に手を入れた経験
  • カバレッジの高さではなく、「テスト容易性のために設計を変えた」経験を見ます。ユニット・結合・E2Eのいずれでも構いません
• 「何をテストしないか」を判断し、その理由を説明できること
  • リスクと工数を踏まえて優先順位をつけ、削る判断を開発者やPdMに説明した経験
• 開発者・PdM・デザイナーと仕様レベルで議論できること
  • 仕様の曖昧さや考慮漏れを指摘し、選択肢を示して合意形成した経験

※QAとしての実務経験、およびテスト関連資格は必須ではありません。

※すべて満たす必要はありません。ひとつでも当てはまる方はぜひご応募ください。

【テスト自動化・基盤】

• E2E / UIテスト自動化ツールの導入・運用経験（Maestro, Appium, Playwright, Autify 等）
• CI/CDパイプラインの構築・運用経験（GitHub Actions 等）
• テストコードのないコードベースに、後からテストを入れていった経験
• テスト環境・テストデータの整備、Flakyテストの解消に取り組んだ経験

【品質設計・プロセス】

• QA領域の実務経験（テスト設計・テスト計画・品質戦略の策定など）
• JSTQB / ISTQB などで体系的なテスト知識を学んだ経験（資格の有無は問いません）
• インシデントの振り返りから、再発防止を仕組みとして実装した経験
• 開発生産性・品質の指標設計や計測の経験（Four Keys 等）

【プロダクト・技術領域】

• Go、Google Cloud での開発経験
• モバイルアプリ（iOS / Android）の開発またはテストの経験
• フロントエンドの開発経験
• AIを活用したテスト生成・QAプロセス改善の経験
• SRE領域（負荷試験・セキュリティ・可用性）への関心や経験