クラシルリワードを支えるテスト自動化。人的リソース依存からの脱却を果たし開発効率と品質向上を実現したdelyの取り組みとは

dely株式会社

モバイルアプリテスト

ユーザーインタビュー第24回は、MagicPod代表伊藤とともにdely株式会社様にお話を伺いました。
具体的な活用事例や選定の決め手など、いろいろとお話しいただきました。

dely株式会社

delyは「BE THE SUN」というビジョンを掲げ、社会に対して、ポジティブで大きなインパクトを与えられるような存在であり続けることを目標としています。国内No.1のレシピ動画プラットフォーム「クラシル」、買い物サポートアプリ「クラシルリワード」、ライフスタイルメディア「TRILL」、国内最大級のライバーマネジメント事務所「LIVEwith」を運営しています。

クラシルリワードは「日常のお買い物体験をお得に変える」アプリです。「買い物のためにお店に行く」（移動する）、「チラシを見る」「商品を買う」「レシートを受け取る」といった日常の行動がポイントに変わり、そのポイントを使ってさまざまな特典と交換することができます。

POINT

以前は開発5～6人が30分以上かけて手動テストを実施
非エンジニアの採用を見据えMagicPodを選定
導入から1カ月で定期実行とリリース前の自動チェックを実現
位置情報機能などdelyのユニークなテストケースにも対応

右から
・中澤郁斗さん　クラシルリワード開発責任者
・伊藤望　MagicPod CEO

中澤さん（以下、中澤）：2020年にiOSエンジニアとして入社し、クラシルのiOSアプリ開発をメインで担当していました。それから2年くらいたって「クラシルリワード」の立ち上げに加わることになり、今は開発責任者として携わっています。

クラシルリワードは日常行動をアプリ内で行うことでポイントが貯まり、貯まったポイントを商品券などに交換できるサービスで、iOS・Android・Webの3つのプラットフォームで展開しています。開発組織は全体で40〜50名くらいいまして、そのうちクラシルリワードのメンバーが30名ほどです。

伊藤：クラシルよりも多いんですね。

中澤：そうですね。開発面でも注力しているプロジェクトになっています。

MagicPod導入の経緯

中澤：クラシルリワードでは開発当初からQAチームのような組織が存在しなかったため、開発者たちがスプレッドシートでテスト項目を管理し、手動で機能チェックとリリースを行うサイクルを続けていました。

テストケースをスプレッドシートで管理

中澤：ただ、サービスが大きくなるにつれて機能が増え、テスト項目も増えますので手動テストによる確認作業の難易度と工数が増大していきます。リリースも週2回ほどあり、人的リソースに依存していると確認が疎かになるリスクが高まります。さらにポイントや小売店の情報を扱うサービスの性質上、不具合は発生時に及ぼす影響が甚大です。

伊藤：実際に問題は起きていたのでしょうか？

中澤：ものすごくクリティカルな問題に発展したケースはありませんでしたし、段階的なリリースを行っていたことで不具合が見つかっても速やかに修正対応できていました。ただ、開発チーム内では「事前に防げた問題もあったのでは」という反省もあり、予防的な取り組みの必要性を感じていました。そういった状況を解決するため、自動テストツールの導入を検討するに至りました。

MagicPod導入の決め手

伊藤：クラシルでは自動テストツールは導入されていなかったのでしょうか？

中澤：現在も開発チームによる手動QAを継続しています。一方、クラシルリワードは新規プロジェクトということでさまざまな試みができる機会がありました。そこで、この機会に自動テストの導入を検討することにしました。

具体的な検討候補として、以下の3種類を挙げました。

各プラットフォーム固有のUIテストフレームワーク（iOSのXCTest、AndroidのEspresso）
YAMLベースでテストを実行できるMaestro
GUI上で操作可能なMagicPodのような自動テストツール

プラットフォーム固有のUIテストフレームワークについては、iOS・Androidで個別に実装が必要となり、どのようなテストケースを担保するかなどのコミュニケーションコストも発生します。実装・保守の工数面での懸念から、採用は見送りました。

Maestroも検討しましたがYAMLベースでのテストケース作成は、エンジニアへの依存度が高くなる懸念がありました。当初はエンジニアによる運用を想定していましたが、将来的にQAチームをつくり非エンジニアが関わる場合、YAMLベースでは運用面で課題が予想されますので見送ることにしました。

最終的に、GUIベースで直感的にテストケースを作成できるMagicPodが、エンジニア・非エンジニアを問わず利用できる点で優位性があると判断し、採用を決定しました。

伊藤：ありがとうございます！　選定の前にトライアルを実施されたと思いますが、具体的にどのような点が評価のポイントになりましたか？

中澤：大きく2つのポイントがありました。

1つ目は機能面についてです。クラシルリワードには位置情報の計測や歩数を計測するヘルスケア機能が実装されています。特に位置情報については移動距離に応じてゲージが溜まる仕様があり、MagicPodで緯度経度を設定して疑似的な移動をシミュレートできた点が非常に魅力的でした。

伊藤：以前は実際に移動していたのでしょうか？

中澤：そのとおりです（笑）。リリース当初は開発版をチームメンバーに配布して、物理的に移動してデバッグメニューで移動距離を確認する検証を重ねていました。この工程を自動化できたのはすごく助かりました。

2つ目は、トライアル期間中のカスタマーサポートの質の高さです。開発チームからの技術的な質問や課題に対して、迅速かつ的確な回答が得られました。この点は、導入後の運用面での不安を払拭する要素になりました。

MagicPodの活用状況

中澤：現在はサービスとしてのコア機能を定義し、それらの機能がデグレしないように検知する仕組みを構築しています。具体的には、以下の2つのタイミングでテストを実行しています。

朝7時の定期実行
リリースブランチが切られたタイミング

中澤：以前は開発メンバー5、6人でスプレッドシートを使って30分から1時間ほどかけて必須機能のチェックリストを確認していましたが、その時間が削減できました。また、人の手による作業だったため「これくらい大丈夫だろう」という甘えも出てきてしまい、テストの質にばらつきが出る懸念もありました。これを自動化できたことは大きな改善点だったと考えています。

テストケースは導入当初、iOSとAndroidそれぞれで23ありましたが、現在では25〜26程度に増えています。テストケースの追加は各メンバーの判断に委ねており、新機能開発の際に必要性を感じたタイミングで適宜、追加する形を取っています。今後も追加していきたいと考えていますが、開発を進めながらどの範囲までテストケースを増やしていくべきかについては、現在方針を検討している段階です。

伊藤：運用体制はどのようにされていますか？

中澤：QAチームを新設するかアプリエンジニアに任せるかで悩みましたが、最終的に私が一人で運用する体制を選択しました。その理由として、iOSとAndroid両方の仕様を把握している人間が一括でメンテナンスすることで、OS間の差分を検知しやすいと考えたからです。

また、QA専任メンバーがいない中での複数人運用はコミュニケーションコストが大きく、テストケースが形骸化するリスクもありました。実際の運用では、一度テストケースを作って慣れてしまえばそこまで工数はかからなかったです。

現在はiOSエンジニアとAndroidエンジニアに役割を引き継ぎ、複数人で運用できる体制を整えています。アカウントはiOSとAndroidで5人ずつ発行していて、みんなMagicPodの基本的な使い方は理解できています。例えば機能開発中に障害が発生した場合は担当エンジニアが予防的なテストケースを追加したり、既存のテストケースが失敗した際は該当機能の担当者が確認・判断を行ったりといった体制で運用しています。

伊藤：その先にQAチームをつくる構想があるということですね。

中澤：そうですね。非エンジニアが扱えるようにMagicPodを選んだというのもあるのですが、基本的にはやれるところまで自分たちでやりたいなと思ってはいます。将来的に組織やサービスの規模が大きくなり、QAチームの必要性を強く感じた時点で、改めて体制を見直したいと考えています。

安定運用までの取り組みと課題

伊藤：導入から安定運用できるまでどれくらいかかりましたか？

中澤：1カ月程度ですね。最初はツールの使い方に慣れていない部分もあり「ここを修正したらあちらが壊れる」といった試行錯誤の連続でした。毎朝の定期実行で結果を確認し、問題があれば修正して翌日また確認するという作業を地道に繰り返した結果、どうすれば効率的に動作するかを理解できて安定化につながりました。

伊藤：テスト結果でエラーと判定されたものの、実際には問題がない偽陽性（フレーキー）のようなケースは現状でもありますか？

中澤：はい、特にAPIの仕様に依存する部分で発生しています。例えば時間帯によってAPIからの返り値が異なるケースでは不安定になってしまいます。チームでも議論を重ねまして、そういった外部依存の強い部分についてはいったんテスト対象から除外する方向で進めています。

伊藤：導入後の社内の反応や課題感はいかがでしょうか？

中澤：社内からは概ねポジティブな反応を得ています。特に、コア機能部分のテストケースが自動化できたことで、「安心して開発に取り組める環境が整った」という声が多く聞かれました。また、MagicPodはWebテストにも対応していることから、手動でテスト作業を行っているWebチームにも情報共有を行いました。ただし、現時点では他チームでの導入には至っていません。

課題としては、UIの変更に伴うテストケースのメンテナンスがあります。変更が発生した際に迅速な対応ができないと後になって一括で修正する必要が生じ、大きな工数が発生してしまいます。最近も起きたため、テストケースの継続的なメンテナンスの重要性をチーム全体で再認識している状況です。

伊藤：CIのツールは使用されていますか？

中澤：はい。AndroidはGitHub Actionsで完結している一方、iOSはXcodeクラウドで成果物を生成してMagicPod側に流すという構成を取っています。毎朝、アプリをビルドしてから自動的にテストを実行する流れになっています。

最後に

中澤：まずは無料トライアル期間を活用して、実際の業務での使用感を確認することを強くお勧めします。トライアルで自社サービスに特有の機能がテスト可能かどうかを検証し、実際の運用イメージを具体化することが重要だと思います。

クラシルリワードのように開発サイクルが早いプロダクトでも、適切な運用設計により効果的に活用することが可能でした。ただし導入初期は不安定な部分もあり、テストケースの精度向上には継続的な調整が必要となります。

しかし、それを乗り越えることで開発者の心理的安全性の向上や、効率的なテスト運用体制の構築が実現できます。テスト自動化は一朝一夕には完成しませんが、長期的な視点で見れば開発プロセスの品質向上に大きく貢献する取り組みになると思います。