FACTORYチームのQA活動スタート！QAの作業風景とこれからの挑戦

はじめに

こんにちは。KINTOテクノロジーズで KINTO FACTORY サービスのQAを担当している遠藤です。
2024年5月から「インプロセスQA」として活動を始めました。今回は、QAの視点からFACTORYの開発風景をご紹介します。

このブログを通じて、FACTORYというサービスやKINTO全体の開発に、少しでも興味を持っていただけたら嬉しいです。

---

インプロセスQAとして開発チームに溶け込む - KINTO FACTORYの品質文化

インプロセスQAとは

「インプロセスQA」とは、開発チームの一員として日々の開発プロセスに参加し、その中で品質保証活動を行うQA（品質保証）エンジニアのことを指します。
従来のQAは、リリース直前に独立した立場でテストを行い、不具合を洗い出す「最後の砦」の役割を担ってきました。
一方、インプロセスQAでは、開発初期から仕様検討や設計レビューに関わり、早い段階で課題を発見・改善します。これにより、手戻りを減らし、品質と開発スピードの両立を実現します。

KINTO FACTORYでは、このインプロセスQAを2024年5月から導入しました。
まずは従来の最終QAプロセスを維持しつつ、開発チームの中に入り込み、「一緒に品質を作り込む」文化を育てています。
この取り組みにより、仕様段階から品質の視点を取り入れることができ、ユーザーにより安心して使っていただけるサービス提供を目指しています。

項目	従来QA	インプロセスQA
関わるタイミング	開発後半（リリース前）	開発初期から継続的に
主な役割	最終テスト・不具合検出	仕様検討・設計レビュー・早期改善
メリット	リリース前の品質担保	手戻り削減・品質とスピードの両立
関係性	開発と別組織的	開発チームの一員として活動
課題	後工程での不具合修正コストが高い	文化として根付くまで時間がかかる

FACTORYの開発チームに加わる意味

これまでQAチームは、リリース直前に不具合を洗い出し、障害の防止や納期遵守、安定稼働に大きく貢献してきました。
その経験と知見を活かし、FACTORYチームでは、従来の最終QA工程を続けながら、少しずつ開発の前工程にも関わる取り組みを始めています。

今回はチーム内にQAが一人から参画し、まずは仕様検討や設計の場に顔を出し、早期に課題を共有できる環境づくりを進めています。
まだ加速的に進められる段階ではありませんが、日々のやり取りの中で開発とQAの距離を縮め、自然に協力し合える体制を目指しています。

こうした地道な取り組みが、やがては後工程の手戻り削減や品質向上につながると考えています。
では、この体制の中でどのようなQA作業を行っているのか、次の章で具体的にご紹介します。

---

FACTORYチームのQA作業とは？

基本的には、従来の各サービスで行ってきたQA業務と大きな違いはありません。
主な作業内容は以下の通りです。

• 中・長期的な案件対応
• 短期的な改善対応
• テスト自動化対応

中・長期案件対応

管理ツールの新規開発や、販売商流の新規追加に伴う機能開発では、短期間では終わらない丁寧な準備が欠かせません。
まず関係者と時間をかけて仕様を確認し、その内容をもとにテスト計画を練り上げます。
そして、仕様確認からテスト計画、実施までを数カ月かけて丁寧に進め、品質を確保したうえでリリースにつなげています。こうしたプロセスを踏むことで、リリース後のトラブルを防ぎ、安心して使っていただけるサービスを提供しています。

短期改善対応

画像の見栄えや一時的な表示変更など、軽微な修正や改善は1〜2週間程度で対応します。
着手前にはチケット内容の認識合わせを行い、必要に応じて3日ほどでQAを実施することもあります。
短期間であっても品質を犠牲にせず、ユーザーに素早く価値を届けられるよう心がけています。

テスト自動化対応

Autifyを活用し、2週間ごとのリリースサイクルに合わせて自動テストシナリオの追加・更新・メンテナンスを行っています。
これにより、繰り返し発生するテストを効率化しつつ、リリースごとの品質を安定的に確保しています。
将来的には、PlaywrightとAIを組み合わせ、エンジニアに依存せずQA主導でテストコードをメンテナンスできる仕組みづくりも進めています。

---

長期案件と短期案件の違い

項目	長期案件	短期案件
期間	数カ月	1〜2週間
対象	新サービス / 大規模開発	軽微なUI修正 / 表示改善
QA期間	約1カ月	約3日
主な課題	仕様の複雑さ、関係者調整	認識齟齬によるミス防止

---

QAとして意識していること

私の信念は、「QA作業は開発スケジュールを阻害しない」 ということです。
時間と品質の両立を常に意識して取り組んでいます。

例えば、計画段階でリリース日から逆算して開発スケジュールを立て、QA期間を2週間と想定していたとします。
その後、見積もり依頼を受けた結果、実際には1カ月かかると判明した場合、QA作業を優先するとリリースが遅れます。
リリース遅延は、開発メンバーだけでなく、マーケティングや営業、経営陣、さらには利用を待っているお客様にも影響します。例えば、広告出稿やキャンペーンの開始日を合わせて準備していた場合、それらが無駄になったり、季節やイベントに合わせた需要のピークを逃したりします。さらに、競合他社が先に類似サービスをリリースすることで、市場での優位性やユーザー獲得のチャンスを失う可能性もあります。
このように、リリース時期の後ろ倒しは、関係者全員が予定していた成果を得られなくなるだけでなく、事業成長に直結する重要な機会を逃すリスクを伴います。

そのような場合は、関係者と再度確認を行い、「適切なタイミングで」「必要な範囲のQAを」 行うことを提案します。
大事なのは、QAだけの都合でスケジュールを動かすことではありません。
まずはプロジェクト全体のゴールをはっきりさせて、そのゴールを叶えるために一番いい方法を、プロジェクトとして判断することが大切です。

もちろん、緊急で不具合や障害の改修が必要なときもあります。そんなときは、スケジュールを守りつつ、できるだけ早く対応します。
ただし、スピードを優先するあまり品質を犠牲にすることはありません。短期対応であっても、ユーザーが安心して使えるレベルまでしっかり仕上げてからリリースするのが基本姿勢です。

---

FACTORYチームの一員としてのQA

従来のQAに加え、FACTORYサービスに特化した新たな取り組みも進めています。
ここでは「シフトレフト」の考え方を取り入れています。
シフトレフトとは、テストや品質の確認をできるだけ開発の早い段階（＝左側）で行い、手戻りや修正コストを減らすアプローチのことです。

具体的には、チケット起票段階からQAの観点を盛り込み、開発メンバー側が手の回らない部分の品質もサポートできるよう、まずはできる範囲から早めに着手しています。

理想は、「痒いところに手が届くQA」。
開発だけでは見落としがちなポイントや、通常はQAが対応しない結合テストなど、品質面で不安が残る領域も積極的にカバーしていきます。

---

実際の作業風景

案件対応では、仕様資料をもとにテスト計画や観点をまとめます。
複雑な内容は事前説明を受けることもありますが、基本は資料をベースに進行します。

早期に仕様を理解し、開発メンバー側へ質問しながら進めることで、作業をスムーズに進行できます。
短期対応の場合は、変更点が明確なため、具体的なテストケースを作成し、認識違いがあれば即時修正します。

また、質問だけでなく、雑談レベルの不安も積極的にヒアリングします。
「申し込みできるか不安」「システム連携が正しくできているか」など、細かな不安も解消できるよう努めています。

開発メンバーの方々は、QAの質問や対応依頼など積極的にかつ前向きにとらえて実行してもらえています。
そのため、QA作業もスムーズに進行し、開発メンバー側との連携も良好です。
この環境に甘えることなく、QAとしてできることを常に考え、開発メンバーの皆様と一緒に品質向上に取り組んでいます。

---

これからの活動

Autifyに加え、これまで開発メンバー側主導で使用してきた Playwright を活用した自動化にも取り組みます。
AIを活用してテストコードをエンジニアに頼らずメンテナンスできるようにし、QAが主体的に改善・運用できる体制を整えていきます。

さらに、シフトレフトの推進やテスト範囲の拡大も計画中です。
上流工程での品質作り込み、結合テスト、データフローの確認などにも積極的に取り組み、開発メンバーとQAの連携をより強化していきます。

QAは品質の最後の砦であると同時に、開発メンバーの伴走者でもあります。
チーム内に加わったことで、これまで以上に早い段階から伴走者として関わり、
同じゴールを目指しながら品質を作り込み、必要な対応は即時に行えるよう日々取り組んでいます。

---

さいごに

今回は、FACTORYチームのQA活動についてご紹介しました。
チーム内の一体感や品質へのこだわりが、少しでも伝われば幸いです。

私自身、お客様視点とサービス視点を忘れず、開発メンバーと協力しながら、みなさまに笑顔になっていただける品質を追求していきます。
もし興味を持っていただけた方は、ぜひ 弊社の採用ページ もご覧ください。