
こんにちは。株式会社ニーリーでQAエンジニアをしている池端です。
普段はラーメン食べてばかりでこういう記事を書かないのですが、熱量が高いうちに書き切ろうと思います。
そんなタイミングで、「#ニーリー開発組織の野望」シリーズも第3弾に突入しています。
各メンバーがそれぞれの“野望”を語る中で、今回はQAの番です。
(シリーズ全体の記事は Nealle Developer’s Blog からご覧いただけます!)
その“野望”を語るうえで外せないのが、先日Xでも展開したQA Recruiting Deckのリニューアルです。
ニーリーのQAエンジニア向けのRecruiting Deckを大幅アップデートしました!🎉
体制の変更やミッションの刷新に伴い、”今の”ニーリーQAチームの魅力が詰まった内容になっています。
少しでもご興味のある方は、ぜひご覧ください! https://t.co/UiXxttKfiW
— ばっち (@bacchiQA) 2025年9月18日
少しだけ自慢すると、「野望」という言葉を最初に言い出したのは、僕たちQAなんです。Deckをリニューアルする際に追加した「AMBITION(=野望)」が、その始まりでした。
では、なぜ今リニューアルしたのか?
体制の変更やMISSIONの見直し、AMBITIONの追加もありますが、今回のリニューアルは“今の姿”を正しく伝えつつ、よりリアルに知ってもらうためのものです。
そこでこの記事では、Deckに込めた想いを紐解きながら、ニーリーQAが大切にしている価値観と、その挑戦を紹介していこうと思います。

QAチームのミッションは「品質は高く、しかも速く。」です。 スタートアップの圧倒的な事業スピードの中で、品質とアジリティを両立させる。この”欲張り” とも言える使命の実現に本気で取り組んでいます。
そして、その実現の鍵こそが、私たちのAMBITIONとして掲げる「ドメイン理解を最大の武器に、事業にコミットする」という姿勢です。
ここで言う「ドメイン」とは、プロダクトの仕様に留まらず、サービス、業務、業界、ユーザー行動といった、事業を取り巻くあらゆる領域です。そういったもの全てをひっくるめて誰よりも深く理解すること。それが私たちの考える「武器」です。
「ドメイン知識を武器に、事業にコミットする」とはどういうことか?
これは自分が去年QAとして関わった約半年間にわたる大規模プロジェクトの話をさせてください。
【事例:大手不動産会社との基幹システム連携プロジェクト】
ニーリーでは月極駐車場をオンラインで契約できるサービス「Park Direct」を提供しており、今回のプロジェクトでは、大手不動産会社の基幹システムと「Park Direct」を連携させました。
連携内容を簡単に表現すると以下の通りです。
- 契約情報の連携:Park Directで新規契約されたデータを基幹システムに送信
- 送金情報の連携:初期費用、月々の賃料、解約時の返金等のデータを基幹システムに送信
- 契約後の情報の連携:契約改訂、解約、契約更新などのデータを基幹システムに送信

連携方式はAPI連携を採用。
ユーザー目線ではシームレスに契約できることが最重要ですが、裏側では双方のシステムが正確に同期する必要がありました。
「契約」という一言の裏に潜む、無数の業務ルール
当時自分はこのプロジェクトのQA責任者を務めており、正直、最初は少し甘く見ていました。「自社の開発範囲の品質を担保して、いい感じにデータ連携すればいいんだろう」と。
でも、そんな単純な話じゃないとすぐ気づきました。
本当に向き合うべきは「この連携でお客様の業務は本当にうまく回るのか?」という問いであり、その難しさは、自社の業務ルールが複雑なだけではない点にありました。仕様書に書かれた「契約」という一言の裏には、初期費用や敷金の計算ロジック、月をまたぐ契約日と利用開始日のハンドリングといった自社のルールに加え、それらが連携先であるお客様のシステムでどう扱われるのかという視点が不可欠でした。
「解約」も同様で、「契約月と同月の解約」と「翌月の解約」では敷金の相殺有無の扱いがどう変わるのか。「強制解約」や一度出した「解約の取り消し」といったイレギュラーケースを、自社と相手先のシステムをまたいでどう整合性を取るか…。これら一つ一つが、事業の根幹をなす重要なドメイン知識でした。
プロジェクトから得た知識と最高の経験
このヒリヒリワクワクした経験が教えてくれたのは、QAの価値はテストスキルだけで測れるものではない、ということです。
テストスキルに加え、複雑なドメインをどれだけ深く理解しているか。それこそが、「何を・どこまでテストすべきか」を判断する力を高め、テストそのものを一段上の次元へ引き上げるのだと思っています。
そして何より、本当にヤバい問題はきれいなシナリオ通りでは起きず、複雑なドメイン知識が絡み合う「異常系や実際の運用の中で起きるような複雑なケース」にこそ潜んでいる、ということを身をもって体験することができました。
このプロジェクトで得た学びを忘れないためにも、QAでは普段からこのような働き方をしています。
まず、ニーリーのQAの働き方を象徴するのが、開発プロセスの上流、つまり早い段階から品質活動に積極的に関わっていく「シフトレフト」の考え方です。
もちろん仕様を理解するのも大事なんですが、こだわっているのは「そもそも、なぜこれを作るのか?」という背景やゴールを、チームの誰よりも深く理解すること。その「なぜ」を理解しているかどうかが、後続のテストの質とスピードを変えると思っているからです。
そのために、QAが持つドメイン知識を武器に、PRD(プロダクト要求仕様書)やDesign Doc(設計書)のレビューといった一番最初の段階から主体的に関わっていき、仕様の矛盾や潜在的なリスクを実装(開発)前に指摘し手戻りを最小限に抑える活動をしています。これが、QAのミッションである「品質は高く、しかも速く」 を実現するための、極めて重要なアクションだと思っています。

では、その武器はどうやって手に入れるのか?
机に向かっているだけでは現場のことは分からないので、時にはビジネスサイドの業務にヘルプで入り、実際に自分たちの手でオペレーションを体験しています。そうすることでしか得られない現場のリアルな課題やユーザーのペインを肌で感じるためです。これらの一次情報こそが「業務の解像度」を上げてくれる最高のインプットになっています。
この刺激的な経験から半年ほど。
今の自分は、月極駐車場事業の「Park Direct」と、新しく立ち上がったプロダクトのQAを兼任しています。
これまで1つのサービスに深く関わることが多かった中で、今は異なるプロダクトを行き来するような働き方になりました。
一見するとカオスですが、だからこそ見える景色があります。

それぞれのプロダクトは対象ユーザーや提供価値が少しずつ異なりますが、根底にあるのは「カーユーザーの体験をより便利にする」という共通の目的です。
その目的を共有しながらも、ビジネスモデルや、そこに紐づくビジネスルール、スピード感、求められる品質の“重心”が異なる。そこを理解し、QAとして「今このプロダクトで大切にすべき品質は何か?」を考え抜くことが、マルチプロダクトQAの醍醐味だと思っています。
たとえば、Park Directでは契約や月々の請求/決済など、事業の根幹を支える安定性が求められます。 一方で、新しいプロダクトではユーザー体験の快適さや操作の軽さが重視される。同じ“駐車場”というドメインにいながら、品質の重心が微妙に違う。
どちらも“品質”だが、求められるスピード感やユーザー体験の温度が違う。
その違いを感じ取りながら、プロダクトごとに最適なバランスを試行錯誤する。
その積み重ねこそが、QAのやりがいの一つだと思っています。
新しいプロダクトの詳細については、また別の機会にゆっくり書こうと思います。
そして今、複数のプロダクトが連携し合うことで、新たな価値が生まれようとしています。
それぞれが独立して動くのではなく、データや機能がつながることで、事業全体としての価値が高まっていく。QAとしては、この“連携の境界”をどう捉え、どのように品質を担保するかが大きなチャレンジです。
単に「動作する」だけではなく、プロダクト同士が整合性を保って動いているかを確かめる。そのためには、QAとしてもデータモデルやデータフローなどのシステム構造や業務ルールの前提を理解し、リスクを考える必要があります。
境界をまたぐ分、複数の仕組みを矛盾なくつなげる難しさが常につきまとう。
それでも、チームであれこれ悩む時間が好きです。
このカオスの中で、少しずつ形にしていく感じが、今の自分にはたまらなく面白いです!
と、ここまで強みや面白さを中心に語ってきましたが、私たちはまだまだ完璧ではありませんし、課題もたくさんあります。Deckでも公開している通り、下記のような課題に直面しています。
- 課題1:品質の定義がチーム内で揃っていない
- 課題2:開発スピードと品質保証の“適切な落とし所”が見つからない
- 課題3:プロダクトの複雑化によるテスト設計の難度上昇
- 課題4:ナレッジ・品質資産が属人化しがち
日々挑戦を重ねているからこそ、課題もどんどんアップデートされていきます。
正直に言うと、ここに書いた以外にもまだまだあります。
でも、それも組織が「1→10→100」へと成長していく今のフェーズならではの、最高に刺激的なところだとも思っています。
こうした状況を「面白そうじゃん」と楽しみながら、一緒に新しい仕組みを形にしていける仲間をニーリーは探しています。
仕様書の先にある“事業のリアル”を見に行く。
それこそが、ニーリーQAの挑戦であり、僕たちの仕事の最大の面白さです。
ちょっと長くなっちゃいましたが、自分がこの記事で伝えたかったのは、結局たった一つで、それは 「QAの力で事業を動かすの、めちゃくちゃ面白いぞ!」ってことです!
「ちょっと話でも聞きに行くか」くらいの軽い気持ちで全然構いません!ぜひ声をかけてください。お待ちしてます!
▼カジュアル面談はこちらから!
https://nealle.notion.site/26b8c35b4dfa81218100cf3bcc224ba9
▼今回ご紹介した新しいQA採用デック
コメント