テスト自動化で「開発とテストの同時並行」を実現。レコチョクがQAと開発エンジニアの連携で構築した“ブランチ機能”活用術とは

株式会社レコチョク

モバイルアプリテストブラウザテスト

株式会社レコチョク様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。

株式会社レコチョク

2001年創業のレコチョクは、「音楽市場の最大活性化」をミッションに音楽業界のニーズに応じた先進的なサービスを提供・展開しています。事業は大きく分けて「音楽配信事業」「ソリューション事業」、子会社エッグスによる「インディーズ活動支援事業」があります。音楽配信事業では、2002年に「着うた」サービスを立ち上げ、個人・法人向けダウンロード、ストリーミングのサービスを展開して国内の音楽配信ビジネスを牽引してきました。2025年には原盤での歌唱を前提とした法人向け原盤利用許諾スキーム「レコチョク play」のカラオケ機器メーカーへの提供を開始しています。ソリューション事業では、音楽事業者に特化したECストア開設のプラットフォーム「murket」や法人向け音楽配信事業支援を展開しています。エッグスでは、インディーズアーティストの音楽活動支援を展開しています。

POINT

手動テストのコスト増による開発スピード悪化が導入前の課題
クラウドでは対応できない端末の実機テスト自動化が決め手に
QAと開発エンジニアが連携し、週次改善でテスト通過率90%を維持
ブランチ機能を活用し「開発とテストの同時並行」を実現

左から
・Kiyosakiさん　IT基盤部QA推進グループ
・Kurashigeさん　NX開発推進部プロダクト開発第2グループ
・伊藤望　MagicPod CEO

Kiyosakiさん（以下、Kiyosaki）：私はIT基盤部QA推進グループに所属し、全社横断のシステム開発における品質保証を担当しています。現在、QA推進グループは業務委託を含めて8人が所属するチームになっています。

私は2006年にレコチョクに入社して以来、主にプロジェクトマネージャーを担当していました。その中で「どうしたらリリース後の品質を上げられるだろうか」と考えるようになったのですが、それまでQAとは無関係な仕事をしてきたため、「何から始めればいいのか」と悶々とする日々を過ごしていました。そんな時に既存のQA組織へ異動となり、私もその一員として品質向上に取り組むことになりました。

当初はヒューマンテスターによる手動テストを行っていましたが、E2Eのノーコード・ローコードツールが世に出始め、「自分たちでも導入できるのではないか」と興味を持つようになりました。現在はE2EテストをQAチームに取り入れ、全社的に横展開していく活動が私の主な業務になっています。

Kurashigeさん（以下、Kurashige）：私は2022年に入社し、モバイルアプリエンジニアとして「dヒッツ® powered by レコチョク」などの開発を担当してきました。現在はNX開発推進部という部署でマネージャーをしています。私も「モバイルアプリの品質を上げていくためにはテストをどう運用すればいいのか」と考えていましたので、Kiyosakiと共にエンジニアとQAとで連携し、品質向上のための取り組みを推進しています。

MagicPod導入前の課題

伊藤：Kiyosakiさんは品質に対して、当初どのような課題感を持たれていたのでしょうか？

Kiyosaki：課題だったのはリリースサイクルの中で、「修正後には必ず手動でリグレッションテストを行う」というルールがあり品質保証を行っていましたが、確認すべき機種やOSが増えるたびに、それらの組み合わせでテストパターンが増えていきますので人手が足りず、その都度外注で人員を確保して手動テストを行っていました。

その状況ではリリース終盤のQAフェーズが長くかかってしまうため、逆算してスケジュールを引くと開発期間が短くなってしまいますし、テストを削るとなればそれはそれで調整が大変でした。「リリーススピードに対応していくのにテストの負担が大きすぎる」というところが一番の課題で、日々悩んでいました。自前で自動テストを導入することも検討しましたが、環境構築やそれを保守・運用する人材、メンテナンスのリソースなど困難なことが多く、一度は諦めていました。

Kurashige：結果として、当時は開発エンジニアがユニットテストやビジュアルリグレッションテストの作成・実行、ビルドごとのスモークテストを手動で行うなど、開発側としても多くの工数が割かれていました。

Kiyosaki：QAとしても複数同時にテスト依頼が来た際はとにかくリソースの調整が大変でした。そこで2020年頃にブラウザテストでノーコード・ローコードの自動テストツールを導入しました。

MagicPod選定の理由・経緯

Kiyosaki：弊社ではブラウザよりモバイルアプリのほうがテストの引き合いが多く、モバイルを自動化しないと本当の効率化は実現できないと感じていました。そんな時にたまたまMagicPodのことを知り、我々の求めているものとの親和性が最も高いと感じました。最大の決め手は「実機でテストできる」という点です。実はそれが我々にとっての必須条件でした。

選択肢は「自前で実機環境を構築する」か「SaaSを利用する」かの二択で、自前で構築するのは環境構築や保守の手間を考えると少人数のQAチームでは現実的ではありませんでした。そのためSaaSであることが前提でしたが、実現できるツールがないと思っていたところで見つけたツールがMagicPodだったのです。トライアルで問題ないことを確認し、すぐ導入を決めました。

伊藤：実機でテストできることが重要とのことですが、具体的にはどのようなテストを行っているのでしょうか？

Kiyosaki：クラウドでは対応できない端末でのテストです。特に、弊社の品質基準として新デバイスや最新OS/ファームウェアへ、変更を加えていないアプリの互換性/移植性を担保する必要があるため、これを毎回、手動でテストするのも大変です。その点、MagicPodがあれば手動で行っていたものと同水準の確認がローカルで接続した端末で実施でき、自動化もできるということでとても助かりました。

Kurashige：MagicPodの導入は、ちょうど私が入社して最初のプロダクト開発に入った頃でした。Kiyosakiから「こんなツールがある」と教えてもらい、触ってみて革命的だと思いました。「これはモバイルエンジニアが全員使えるようになるべきだ」と感じ、社内で啓蒙活動を始めました。

開発エンジニアも品質に対しての責任感は持っていますが、開発を進めるうえで何を優先すべきかバランスが難しいところもあります。弊社ではMagicPodがあることでQAチームとの連携が深まり、そのバランスをうまく取ることにつながっていると感じています。

今では新しく入社したメンバーに「うちはこれで自動化しているので、使えるようになってください」とアカウントを発行する自然な流れができています。

Kiyosaki：以前、ブラウザテスト自動化ツールを導入した際はQA主体で進めたため、「QAがやっているもの」という見え方になってしまったという反省がありました。モバイルアプリのテストは開発エンジニアに専用アプリをビルドしてもらう必要があるため、開発エンジニアの協力が不可欠です。そこで、まずは動いているものを見てもらった方が早いと思い、Kurashigeにデモを見てもらったのです。

Kurashigeさん NX開発推進部プロダクト開発第2グループ / Kiyosakiさん IT基盤部QA推進グループ / 伊藤望 MagicPod CEO

MagicPodの活用状況

伊藤：モバイルアプリプランは2022年にご契約いただき、2024年にはブラウザプランもMagicPodに移行していただいていますね。

Kiyosaki：ツールが分かれると学習コストなど管理の手間が大きくなってしまいます。MagicPodのブラウザテストを使ってみたところモバイルとほぼ同じ使い勝手でしたので、統一することにしました。前のツールで使っていたシナリオがMagicPodで対応できたこともあり、移行は非常にスムーズでした。

Kiyosaki：現在は全サービスで日次実行を基本としています。プロダクトが10以上あるので、端末リソースを考慮しながら10分単位で実行時間をずらしています。mainブランチとfeatureブランチを使い分け、mainブランチは深夜にサービスの外形監視に近いイメージで動かし、featureブランチは開発と連動するため日中帯に実行しています。

ブラウザとアプリをまたぐテストなど、実行順序に依存関係がある場合はMagicPodのラベル管理とスケジュール機能を活用し、「ブラウザを15:00、アプリを15:30に実行する」といった形で意図した順番で実行されるように工夫しています。

結果はSlackに通知し、全プロダクトをまとめたチャンネルと、各プロダクト担当者が見る分散チャンネルの2種類に振り分けています。NGが出た際は、まずQAが「サーバー側の問題か」「アプリ側の修正が原因か」などを一時切り分けしてからエスカレーションします。“オオカミ少年”にならないよう、テストの安定性は常に意識しています。

伊藤：開発とQAの連携はどのように行っているのですか？

Kiyosaki：週に一度ミーティングを設け、KPIを追いかけたり、新機能のテストについて話し合ったりしています。例えば「テストが不安定だ」という課題に対し、「ここのロケーターを一意に指定できるように修正してほしい」とエンジニアにお願いすることもあります。

MagicPodを軸にコミュニケーションが格段に増え、開発側から「この修正でシナリオが壊れるんじゃないか？」と気遣ってくれるようになるなど、先々の開発状況を早めに把握でき、QAとしても先回りして準備ができるようになりました。

こうした改善の結果、導入当初は通過率80%を目指していましたが、今では約90%を維持できています。残りの10%はプロダクトの不具合というより、通信環境やサーバレスポンス状態によるフレーキーテストがほとんどです。

Kurashige：開発側も、開発が完了した時点でシナリオも修正されている、という状態を目指してワークフローを構築中です。この「開発とテストのサイクル」はAIなども活用しながら、今もQAと一緒に改善を進めています。私は開発エンジニアがMagicPodを通じて「品質保証とは何か」「どうテスト設計すべきか」を真剣に考えるきっかけになっていることが非常に大きな成果だと感じています。

ブランチ機能で「手動での二重管理」を解消し、CI連携を加速

伊藤：開発フローの中で、featureブランチのテストはCI/CDツールなどと連携されていますか？

Kiyosaki：はい、徐々に連携を進めています。我々のテスト実行トリガーは、このワークフロー図のように大きく2系統あります。

まず、図の左側が各プロジェクトの“開発者起点のフロー”です。コードがdevelopブランチにマージされるタイミングでGitHub Actionsが動き、MagicPodのfeatureブランチのテストを実行します。もしテストが失敗すれば開発者にフィードバックされ、修正サイクルが回ります。

そして図の右側が“QA起点のフロー”です。こちらはQAが管理する別リポジトリから、例えば週1回といった定期実行のトリガーをGitHub Actionsでかけています。これによりMagicPod API経由でfeatureブランチのテストが実行され、QA側でも定期的に品質をチェックできる体制にしています。

Kurashige：これが、先ほど話した「開発とテストの同時並行」を前提とした現在のワークフローです。理論上は開発が完了してコードフリーズに入るタイミングで、テストも完了しているという状態を目指しています。

MagicPodが推奨しているブランチ構成は、我々の開発フローと非常に相性が良いです。我々もMagicPodのmainブランチをCIツールで毎日自動実行する「開発環境向けの基準ブランチ」として位置づけています。

エンジニアが新機能のためにfeatureブランチを作成すれば、本番環境やmainブランチのテストケースに影響を与えることなく、新しいUIのテスト準備を進められます。GitHub Actionsからのコマンドライン実行でもブランチを指定できるので、プロセスに組み込むのがスムーズでした。

伊藤：ブランチ機能がリリースされる前は、どのように管理されていましたか？

Kiyosaki：まさに「手動での二重管理」でした。シナリオ全体を複製して、複製したほうをfeatureブランチとして修正をかけていました。しかし、この手動での複製管理は他の人の作業に影響を与えてしまうリスクが常にあります。そのためブランチ機能によって各自が「独立したワークスペース」で変更を追加・検証できるようになり、チームが安全かつ迅速にコラボレーションできるようになったのが一番のメリットだと感じています。

工数面でもかなり楽になりましたし、CI連携もしやすくなりました。本当に待望の機能でした。以前はmainブランチ1本でしたので、開発中のfeatureブランチでの失敗がヘルススコアに影響してしまっていました。今はブランチが分かれたことでmainブランチの安定性が可視化されやすくなった点も助かっています。

Kiyosakiさん　IT基盤部QA推進グループ / 伊藤望　MagicPod CEO

最後に

Kiyosaki：MagicPodを導入する際、つい「コスト削減」や「人手不足の解消」を目的にしてしまいがちです。私自身、当初は「手動テストのコストを減らしたい」という点にフォーカスしすぎていた部分がありました。しかし、「ツールを導入しただけではその目的は達成できない」ということに身を持って気づかされました。

自動化で最も重要なのは、ROI（投資対効果）を先に計算することだけではなく、「自動テストを安定して繰り返し実行できる体制」をまず築き上げることです。これが何よりものファーストステップだと考えています。

その体制さえできてしまえばテストが安定して動くようになり、コスト削減は“副産物”として後から必ずついてきます。ですから、まずは目的の軸をしっかり見定め、開発エンジニアを巻き込んで開発サイクルにテストを組み込むことから始めることをお勧めします。

そこにうまくハマらないツールは、結局使われなくなってしまいます。せっかく便利なツールを導入しても、使われなくなってしまうのは本当にもったいない話です。

Kurashige：私もほぼ同じ意見です。モノづくりに品質保証は欠かせませんし、目的は「高い品質を維持すること」です。MagicPodはそれにぴったりなツールだと思います。私は現場で開発することが多いので「開発プロセス自体を品質保証のために変えていく」という意識で取り組んでいます。「ただ入れただけ」「ただ自動化しただけ」では、やはり続きません。運用全体を変えていく覚悟があるチームには、非常に効果が高いと思います。ぜひお薦めしたいです。