yamoryのQAエンジニアポジション立ち上げと、私たちが目指す品質のカタチ

西條広晃
2026.6.23

こんにちは、「yamory」 のQAエンジニア（以下、QAE）の西條/Joです。

yamory事業部は2025年の10月にQAEポジションを新しく立ち上げました。今回は、その背景やどんな考えで動いているのか、これからどこを目指していくのかについて書きました。

★入社インタビュー記事もぜひご覧ください

ITシステムの脆弱性を自動検知し、管理・対策までを一気通貫で実現する国産クラウドサービスです。フロントエンドはTypeScript/Angular、バックエンドはKotlin/Spring Boot、インフラはAWSを中心に構成し、CI/CDにGitHub Actions、監視にDatadogを活用しています。

yamory事業部では、1スプリント1週間のスクラムを採用し、体制や優先順位をチーム自身が決める自律的な開発文化を大切にしてきました。元々メンバーの品質意識は高く、設計・実装・振り返りのサイクルが根付いています。

一方で、2025年前半までは専門のQAEが所属しておらず、プロダクトの急成長に伴って「チーム間の情報共有コスト」「QA基盤の整備」「限られたリソースでの案件規模拡大への対応」といった、成長途上ならではの課題も顕在化していました。

そこで、この強い開発文化を活かしつつ、組織的に品質への取り組みを強化するために新設されたのが「QAE」ポジションです。

新設されたQAEに期待される役割は、単なるテスト活動に留まりません。開発プロセス全体の品質向上や、チームの品質文化のさらなる醸成、AI活用の推進など多岐にわたります。

私たちは、QAEを「『yamory』のお客様に最高の価値を届ける人」と定義し、自律的なチームとともにプロダクトの価値最大化を目指しています。

QAEが直接的に売上を作るのは難しいと思います。しかし、例えばインシデントの発生や市場への不具合流出を未然に防ぐことで、問い合わせ対応やお知らせの発報、コード修正／再テスト／再リリースといった事後対応コストを大幅に削減することはできます。

品質の善し悪しという側面において、お客様の離脱防止に寄与することで、結果的に事業成長への貢献につながると考えます。

yamory QAEはこの点を共通認識として持ち、行動軸の一つにしています。

手動・自動テスト、プロセス改善など、何であれ、これらはすべて「お客様に最高の価値を届けるための手段」に過ぎません。

私たちは、「QAEがひたすらテストだけをやっている」とった状況はベストではないと思っています。お客様に最高の価値を届けるためにやれることは全力でやっていこうと決めています。

だからこそ、すべての行動の根本に「これはお客様にとって価値があるのか」という問いを置き続けることが私たちのこだわりです。テストが目的化した瞬間に、この問いは失われてしまいます。

「yamory」のプロダクトに関わる全ての人たちがプロダクト品質の作り込みに関心を持って、実際に品質向上に取り組んでいる状態を作ることが私たちの目指すところです。これはQAEの力だけでは達成できないので、プロダクト作りに関わるメンバーとの協働・共創が不可欠だと考えています。

QAEは「最後の砦」「番人」のようなイメージを持たれがちですが、yamory QAEが目指しているのは「番人」ではなく「伴走者」です。一定のフィードバック能力は持ちつつも、開発メンバーが思い切ってアクセルを踏めるように支え、お客様に高品質な機能をチーム一丸となっていち早く届けることに貢献したいと考えています。

関わる全員にリスペクトを持ち、丁寧に接することは、チームの心理的安全性を底上げし、品質向上活動の土台になると考えています。QAEは細かな質問や指摘をする場面も多いからこそ、伝え方には特に気をつけるようにしています。雰囲気が悪いチームでは、気になるリスクがあっても声に出しづらくなってしまうように思います。

仕様だけでなく、お客様がどう使っているか、どこでつまずきやすいかといった解像度でプロダクトを理解することが、テスト設計やフィードバックの質に直結すると考えています。　

特にQAEの立ち上げフェーズでは最初のメンバーに知識が集中しがちです。テストプロセスやナレッジをドキュメントとして整備し、チームが拡大しても誰でも同じレベルで品質向上活動に取り組める状態を目指しています。

Tech BlogやNoteでの発信、社外イベントへの参加や登壇を通じて知見を共有していきます（この記事もその一環です！）。発信は活動の言語化にもなり、他社のQAEとの知見交換を通じて自分たちの活動にも還元できると考えています。

yamory QAEの活動領域は、品質課題の解決、テスト基盤整備、プロセス・文化醸成、品質の可視化、AI活用推進、チーム連携、情報発信など多岐にわたります。

プロダクトのフェーズに応じて最適な方法を選びながら、これらの活動を推進しています。

詳細については別途記事を書く予定ですが、簡単に事例を共有します。

要求定義や分析といった上流工程は「曖昧な言葉」が多く、認識の齟齬から手戻りが発生しやすい領域です。そこでプロジェクトリスク分析とテスト計画のプロセスを整備し、上流工程の情報を構造化してドキュメント化するためにAIを活用する取り組みを進めています。

AIで構造化することで、不足している情報や曖昧な箇所を浮き彫りにし、プロセスの土台を固めています。チーム全体の手戻りコストを下げ、開発スピードの向上につなげることが狙いです。

リリース後に起きうる失敗は、リリース前に潜在リスクとして見えていることが少なくありません。そこで「すでに失敗した」と仮定して失敗原因を事前に洗い出すプレモーテムを、AIと人の2段階で実施する取り組みを進めています。

まずAIプレモーテムで、開発・QA・PdM・Biz・セキュリティの5つの視点から、技術・プロセス・組織・データ境界・システム波及・不可逆性など多角的な観点を体系的に洗い出してインプットを作ります。続く人間プレモーテムでは、そのインプットを土台に多様なメンバーで議論し、影響度×発生確率のリスクマトリクスで優先度を判定して、対応すべきリスクと対策をリスク管理表に落とし込みます。

「失敗の原因を挙げること」自体が場の目的になるため、社歴やヒエラルキーに関係なく懸念を声に出しやすく、リリース前にリスクを早期発見し、軽減させることが狙いです。

E2Eテストの効率と安定性を向上させるため、AIを活用しつつ既存のE2EテストをPlaywrightに移行するプロジェクトを完遂しました。

このプロジェクトでは、AIが生成したコードをそのまま採用することはせず「そのテストケースで何を守りたいのか」に着目した人間によるレビューを必ず実施しながら進めました。

また、カバレッジを広げることにとらわれ過ぎずに、ユーザーストーリーなどをベースに作成したテストケースを安定して回し続けることを目指しています。

私たちが目指しているのは、チームが安心してお客様に価値を届け続けられる状態を作ることです。

現在も品質に関するフィードバックを早期に行えるよう要件定義の段階からプロジェクトに参加していますが、仕様や設計に対するフィードバックの質と範囲をさらに広げ、手戻りの少ない開発とお客様への価値向上をより高いレベルで両立させていきたいと考えています。

また、手段に固執せず、プロダクトや組織のフェーズに合わせて「今、何をやるべきか」を問い続け、最も効果的な打ち手でお客様に最高の価値を届けられる体制を作っていきます。

yamory QAE立ち上げの段階から関われていることに、大きなやりがいと責任を感じています。

「テストだけをする人」ではなく、「お客様に最高の価値を届ける人」として、チーム全体で品質を作り込んでいくために必要なことは全力で取り組んでいきます。

今後もyamory QAEの取り組みを発信していきますので、ぜひ見守っていただけると嬉しいです。

最後までお読みいただきありがとうございました。