開発とテストを分断させない。SHIFTの自社プロダクト開発における“十歩先のQAのあり方”【JaSST’25 Kyushu 登壇レポート】
2025年10月24日、ソフトウェアテストシンポジウム「JaSST’25 Kyushu」が開催されました。JaSSTプレミアムスポンサーを務めるSHIFTからは、CATエヴァンジェリストの石井 優が登壇。
「十歩先のQAのあり方を実現するマネジメントの勘所」と題して、SHIFTのテスト管理ツール「CAT」、テスト設計ツール「TD」の開発において、QAチームが一般的に想定される役割を超えて開発プロセスに関与し、成果を上げている事例を紹介しました。
-
CATエヴァンジェリスト 石井 優
倉庫事業企業のシステム部門にて、基幹システムの開発・保守・導入および大規模基幹システム移行への参画を経験し、2015年にSHIFT入社。CAT開発チーム内でユーザーサポートとして、ユーザーと開発メンバーのブリッジを行いユーザーの課題分析や新機能提案などを日々実施している。
目次
「CAT」「TD」と開発体制の基本構造
従来、QAチームの役割は開発された機能が仕様通りに動くかを確認し、不具合を報告することだとイメージされることもあると思います。
しかしSHIFTの自社プロダクト「CAT」「TD」のQAチームは、その枠にとらわれず、さまざまな役割をもって活動しています。
「CAT」「TD」のサポートを担当する立場の私から見ても、このQAチームの業務範囲はとても広いと考えています。
通常のテスト設計や実行はもちろんのこと、不具合修正の仕様策定、本番環境へのデプロイ作業まで手掛けています。
このQAチームがどのような成果を出しているのか、リーダーの田山に聞きました。
ご紹介する内容をより深く理解いただくために、「CAT」と「TD」、およびプロジェクト体制について簡単に説明します。
まず「TD」とはTest Designerの略称で、テスト設計を支援するツールです。SHIFTのもつ豊富なナレッジを基に、効率的かつ網羅性の高いテストケース作成を可能にします。
次に、テスト管理ツール「CAT」は、テスト実行フェーズを支援するツールです。テストの進捗状況をリアルタイムで可視化し、品質とプロジェクト管理の効率を飛躍的に向上させます。
開発は4つのチーム体制で進められています。日本側の開発チームが主に要件定義や設計を担当し、詳細な実装はベトナムに拠点をおくグループ会社「SHIFT ASIA」が担っています。
そして、今回フォーカスする田山のQAチームは日本にいて、オフショアを含む開発チーム全体と密に連携しながら品質保証活動を進めています。
スプリント全体を使い切る高密度タスク管理
「TD」と「CAT」は、6週間（1スプリント2週間×3スプリント）を1つのリリースサイクルとしています。
一般的な開発プロセスでは、サイクルの序盤（設計フェーズ）でQAチームの手が空いてしまうことが少なくありません。しかし、彼らはその「空き時間」を価値に変える仕組みを構築しています。
新しい機能のテストにすぐ着手できないスプリント1（設計フェーズ）では、チームは前のスプリントの残作業を片付けます。
具体的には、例えばCATのオンプレミス体系であるダウンロード版リリースや不具合の分析報告などがあります。
それらが終了したら、当スプリントで改修した機能のテスト（リリーステスト①）を設計します。
次は、スプリント2（実装・テストフェーズ）です。リリーステスト①で発見された不具合の修正確認と、リリーステスト②の設計を行います。
最後に、スプリント3（修正・最終テストフェーズ）ではリリーステスト②と、製品全体を通した最終的なE2E（End-to-End）テストを実施します。
このサイクルに加え、新規OSへの対応検証やユーザーからの問い合わせ調査、オフショアチームへの修正依頼といった突発的なタスクも発生します。
田山はこれらのタスクをメンバーへ割り振り、チーム全体としてつねに稼働率を最大化しているのです。
このQAチームのもう1つの特徴は、QAメンバーからUI／UXに関する改善提案が積極的にあがってくることです。
彼らは、毎朝行われるQAチームの朝会にて、進捗報告だけでなく、「ここのボタンは直感的でない」「この操作は使いづらい」といった、製品に対する違和感や気づきを積極的に共有しています。
リーダーである田山自らが、フラットに意見をいいあえる雰囲気をつくり出すことで、メンバーは、臆することなく改善提案ができるのです。
開発・QA・オフショアが一体になると、プロダクトは大きく進化する
QAチームでは、テスト以外にもリリース作業や、デプロイマニュアルの作成などに携わっています。
「QAがデプロイまで担当する」と聞くと、驚く方も多いでしょう。
田山は、QAがリリース作業を自ら行うことのメリットについて、「リリース作業を体感することで、インフラに近い挙動、例えば『バッチ処理が毎時0分に起動する』といったシステムの裏側の動きを肌で理解できます」と説明します。
通常、QAのテストはアプリケーションの要件が満たされているかという「要件適合性テスト」に偏りがちです。
しかし、デプロイを通じてインフラの知識を得ることで、サーバー負荷やネットワーク、データベースといった、より広い視点でのテスト観点が養われます。
とはいえ、専門性の高いデプロイ作業をQAチームが単独でこなせるわけではありません。この取り組みが成功している背景には、開発チームとの協力関係がありました。
デプロイに必要なコマンドの作成や技術的な基盤の整備は、専門知識をもつ開発チームが担当します。そして、その手順をドキュメントとして整理し、実行可能な形でQAチームに作業を移譲するのです。
これは「丸投げ」ではありません。それぞれの専門性を尊重し、もっとも効果的な作業分担を模索した結果たどり着いた、パートナーシップの形です。
このチームは、ベトナムのオフショア開発チームとも密接に連携しています。言語や文化の壁を越えてスムーズなコミュニケーションを実現している鍵は、「ブリッジメンバー」の存在です。
ブリッジメンバーが、開発チケット（作業指示書）の内容の翻訳や意図の伝達、スケジュール管理、リソース調整などをきめ細かく担うことで、QAチームは品質保証活動に集中できます。
また、QAチーム自身も、開発メンバーに対して積極的に質問し、仕様への理解を深める努力を怠りません。
適切なメンバー配置と、能動的なコミュニケーションが、チーム全体の生産性を支える生命線となっています。
品質保証が開発を牽引する時代へ。SHIFT QAの挑戦
最後に、同チームが見据える未来は、QAが単なる「不具合を流出させない最後の砦」で終わることではありません。不具合の分析を通じて開発プロセス全体を改善していく存在になることです。
QAチームがテストという専門領域から一歩踏み出し業務範囲を広げることは、QA活動そのものに大きなメリットをもたらします。
開発に携わるメンバーや、ユーザーとも密に連携していきたいと考えています。
周囲のメンバーと連携しプロセスを俯瞰して、品質とデリバリー活動にとってよりよい形を考えていくことで、ユーザーにとって安全・安心かつ、有効なシステムを届けていきます。
（※本記事の内容および対象者の所属は、イベント開催当時のものです）
