「ポチッと終わる」は幻想だった。大規模アプリiAEON×MagicPod、7割自動化の裏にある“もぐら叩き”のリアル 

2025年12月15日時点で累計2,000万ダウンロードを突破したイオングループのトータルアプリ「iAEON」。スマホ決済「AEON Pay」やクーポン、キャンペーン情報、電子レシートなど、多岐にわたる機能を一つにまとめ、全国の店舗で利用されるこの大規模アプリは、数千に及ぶ検証項目と多種多様な端末・OS環境を抱えている。アジャイル開発体制において、スピーディにユーザーへ価値を届けながらも、決して品質を落とさない。それがイオンスマートテクノロジー（AST）の開発チームに課せられた重要なミッションだ。

本記事では、品質保証の要となるリグレッションテスト（プログラムの変更により既存機能に影響が出ていないかを確認する回帰テスト）に、AIテスト自動化プラットフォーム「MagicPod」を導入した取り組みを紹介する。

「ポチッと押したら終わる」という理想と、現場が抱えていた不安。そして運用開始後に直面した「不安以上の大変さ」に見舞われながらも、自動テストを通じて品質を「自分たちの手」に取り戻そうと奮闘するチームの軌跡を、スクラムマスターの矢追かおる氏と、パートナーとして参画するQAエンジニアの木川氏の視点から紐解いていく。

【目次】

「翌朝には終わっている」はずだった――
“ポチッと押したら終わる”世界を夢見て

システムの機能を追加・改修した際、既存の機能が壊れていないかを確認する「リグレッションテスト」は、プロダクトをリリースする前に必ず毎回行わなければならない、決して逃れられない工程だ。「iAEON」のように多機能かつ利用者の多い大規模アプリにおいては、そのテスト項目は数千にも及び、手動で行うには膨大なコストと時間がかかる。

この負荷を軽減するため、iAEON開発チームはテスト自動化プラットフォーム「MagicPod」の導入プロジェクトを立ち上げた。当時のチーム上層部からは、「ポチッとボタンを押せば、明日の朝にはテストがすべて自動で終わっている」という、手軽で効率的な世界観が期待されていた。

しかし、現場で実際に手を動かすQAエンジニアの木川氏は、過去の経験から自動テストの立ち上げがいかに困難な道のりになるかを熟知していた。自動テストは「作る」ことよりも、それを継続的に「運用」していくことのほうがはるかに難易度が高いからだ。

そう簡単にはいかないだろうな、という一抹の不安は最初から抱えていました。そして実際に運用を始めてみると、iAEONというアプリの規模の大きさも相まって、当初の不安をさらに超える大変さが待っていたのです。（木川）

「ポチッと終わる」はずだった自動テストは、想像を超える泥臭い道のりの始まりに過ぎなかった。

外部ベンダー依存からの脱却――
品質を自分たちの手へ

そもそも、なぜiAEON開発チームはテストの自動化、そして品質保証の内製化に踏み切ったのだろうか。その背景には、当時のチームが抱えていた「品質へのスタンス」に対する強い危機感があった。

というのも、iAEONの検証工程は外部ベンダーに委託するフローが定着していた。開発が完了すれば外部のパートナー企業にテストを一任し、結果だけをもらってリリース判定会で承認をもらうというプロセスが組み込まれていたのだ。

第三者の視点で客観的にテストしてもらえる点や、開発要件を知らないからこそ「いちユーザーと同じ目線」でアプリに触れてもらえるといったメリットは確かにあった。しかし、内製化を進めるアジャイル開発という文脈において、この体制は必ずしもフィットしない部分があったのである。

アジャイルで開発を進めているのに、検証の段階で開発チームの手から離れてしまう体制には、強い違和感を覚えます。プロダクトを開発するということは、全工程に責任を持ち、自分たちの手でプロダクトを育てていくということです。内製開発を推進していくなかで、「検証を外部に頼っているから品質が担保できない」となってしまっては意味がありません。（矢追）

課題の本質は、外部委託にかかる金銭的なコストだけではない。「品質への責任」と「プロダクトの深い理解」が内製チームに蓄積されないという構造的な問題こそが、最大の障壁だった。自分たちで検証し、自信を持って世に出す文化を作る。その第一歩として、テスト自動化ツールの導入は必要不可欠な選択だったのだ。

AppiumからMagicPodへ――
誰もが使えるツールを求めて

実は、MagicPod導入以前にも、「Appium」を用いてテストの自動化自体は行われていた。しかし、その取り組みはアジャイル開発のスピードに追いついていなかった。

Appiumはコーディングを前提とするツールであるため、「専門知識がなくてもチーム全体で使えるツール」を求めていたiAEONチームの要件にはそぐわなかったのだ。

結果として「特定のエンジニアしかテストを実行・修正できない」という属人化の壁にぶつかっており、保守や修正にも多大な工数と費用がかかっていた。自動化の仕組みそのものの運用を別のベンダーに依頼せざるを得ないという状況に陥っていたのである。

旧ツールは人に依存してしまうものだったので、誰でも簡単に使えるツールではありませんでした。さっき矢追さんが言った通り、やはりチーム全体で使えないと意味がありません。特定のエンジニアだけでなく、開発者（Dev）や品質保証担当（QA）、もっと言うとプロダクトオーナー（PO）といったメンバーみんなで使えるツールにしたいよね、というところからツールの選定が始まりました。（木川）

プログラミングの知識不要で直感的にテスト環境を作成できるノーコードツールであり、かつモバイルアプリの自動化に強い。さらに、プロビジョン社での運用実績もあったことから、MagicPodへの全面移行が決断された。

数千項目から“7割自動化”成功の裏側――
複雑なアプリ構造との意外な好相性

新たなツールを導入するにあたり、まずは数千にも及ぶiAEONのテスト項目のうち、どこをMagicPodに任せ、どこを人間が手動で確認するのかという「適合性の調査」が行われた。

スマートフォンのカメラを使ったバーコードの読み取りや、実際のクレジットカードを利用した決済処理など、どうしても物理的な操作を伴う機能については「ここは無理」と割り切り、自動化の対象から意図的に除外した。一方で「ここはいける」と判断したツール上で実現可能なテストはすべて自動化する方針で設計を分けた結果、数千ある項目のうち約7割の自動化に成功した。

大体どのプロダクトでも、自動化率が7割に達していればかなり良い方だと言えます。ツール上では実装できるはずなのに、アプリの作りとの相性が悪くて自動化できないケースも多いのですが、iAEONに関してはそういった相性の悪さが少なく、基本要素がしっかり取得できました。（木川）

この結果は、開発側の矢追氏にとってもポジティブな発見だった。iAEONは機能が多岐にわたり、画面の階層も深いため、一見すると自動化のハードルが高いように思われていたからだ。

iAEONって、メニューも多いし階層も深いので、複雑なイメージがあったんです。でもMagicPodできちんと要素が取れたということは、変に複雑な作り込みをしているわけではなく、アプリの構造自体はしっかりとしているということ。階層が深いだけで、ベースの作りは自動化ツールと相性が良かったというのは、新しい発見でしたね。（矢追）

こうして、実装フェーズ自体は約2ヶ月という短期間で一気に進められた。しかし、自動テストにおける本当の試練は、ここから始まることになる。

実装2ヶ月、“本当の挑戦”はここから――
原因不明の“稼働停止”に立ち向かう

プロジェクトは順調な滑り出しを見せたかに思えたが、テスト自動化における本当の試練は「作る」ことではなく、継続して「安定稼働させる」ことにあった。

運用開始から約半年が経過した頃、突如として“終わりなきもぐら叩き”とも言える大きな壁が立ちはだかる。

Android版のテストが突然動かなくなるという事象が発生しました。普通に実装した時は動いていて、それまで何の問題もなかったものが、何かの拍子で一斉にエラーになってしまいました。（木川）

アプリ側のバージョンアップによる影響なのか、それとも自動化ツール側の仕様変更によるものなのか。原因が特定できないまま、一時はテストを作り直す事態となった。ここからが自動テスト運用における“本当の挑戦”だったという。

その時にわかったのが、画面要素の「取得方法」の重要性でした。iAEONはネイティブとWebViewのハイブリッドで作られているのですが、MagicPod上で要素を「WebView要素」として取得しておけば、今回のような予期せぬ稼働停止が防げるかもしれないと気づいたのです。そこで、ほぼすべてのテストをWebView要素として取得し直して作り変えました。結果として、それ以降は大きな改修は発生していません。（木川）

原因究明の中で得られたこの大きな教訓。トラブルに直面した際、チームにはそれを前向きに捉える心理的安全性の高い土壌があった。

原因がわからないトラブルはどうなるかと不安になるものですが、チームの上層部からも「それも一つの学びだったね」と言っていただいて。失敗を責めるのではなく、この経験を次への教訓として活かしていく。そんな前向きな姿勢がチーム全体に共有されていたからこそ、乗り越えられたのだと思います。（木川）

完全には解消しなかった──
多様な端末環境と外部システム連携の壁

自動テストを安定稼働させる上で、もう一つ避けては通れない難題があった。それが、モバイルアプリ特有の「外部システムとの連携」と「多様な端末環境」への対応である。

iAEONには、クレジットカードを紐づける機能など、外部システムと連携する機能が数多く搭載されている。

外部の会社がシステムメンテナンスを行っていると、我々のアプリからも接続ができなくなります。私たちが制御できない外部要因であっても、自動テストはその時点でエラーとして止まってしまう。自動テスト自体の修正は不要でも、相手側の復旧を待ってから何度も実行し直さなければならないのは、運用上非常に大変な部分です。（木川）

テストが途中で止まってしまうと、「アプリに不具合があったのか」「外部システムの問題なのか」の切り分けが難しくなる。これはiAEONに限らず、現代の複雑なシステム連携を前提とするアジャイル開発において、多くの企業が直面している共通課題でもある。

特に決済（Pay周り）はポイントなども扱うため、万が一不具合が起きればユーザーからの厳しい声に直結する、絶対に失敗が許されないアプリの“肝”である。

ところが、連携先の対向システムには本番と同等のテストが行える「ステージング環境」が用意されていないケースがあった。これに対して矢追氏は、「対向側にテスト環境がないと知ったときは、正直愕然としましたね」と当時の衝撃を語る。

外部環境の要因で頻繁にテストが止まってしまうと、「あぁ、またいつものエラーだよ」と誰も気に留めなくなり、本当にアプリ側の不具合だった場合に見逃してしまいます。自動テストをそんな“オオカミ少年”にせず、本当に価値あるものとして運用し続けるためには、本番と同等に検証ができる「ステージング環境」の存在が不可欠です。システム連携を行うステークホルダー全体で、テスト環境の重要性をもっと共有し、整備していく必要があると痛感させられました。（矢追）

さらに、フルリモート体制で開発を行う同チームにとって、「検証用端末の不足」も物理的な壁となっていた。最新機種だけでなく、一部のユーザーが利用する古いOSや特殊な端末もカバーしなければならない。

その端末のユーザーが数パーセントであっても、何千人という利用者がいる以上、検証しないわけにはいきません。とはいえ、手動でテストをしていると「私、何やってるんだろう」と思ってしまう瞬間があるのも事実です。そうした部分こそ、MagicPodに任せたい領域ですね。（矢追）

MagicPod導入当初はiOSがシミュレーター起動に対応していなかったり、カード登録の検証がクラウド上でうまくできなかったりと、ここでも次々に技術的な壁が立ちはだかりました。それでも開発チームが親身に協力してくれたおかげで、少しずつ対応が進み、導入から約2年を経て、ようやくクラウドでの一斉検証の道が開けてきたところです。（木川）

再びの“脱・属人化”への挑戦が始まる――
草の根運動で変わるチームの意識

MagicPodの導入目的の一つは、プログラミングの知識がなくても使える「脱・属人化」だった。しかし、運用を続ける中で、皮肉にも“新たな属人化”というジレンマが生まれていた。

ツール自体のUI操作は誰でもできます。しかし、実際にエラーなく動く効果的なテストケースを構築するためには、複雑な条件分岐や画面遷移を考慮する必要があり、結果的に「iAEONの深い仕様理解」が必要不可欠になるという現実に直面しました。（木川）

テストを構築するために、あらゆる機能の仕様を誰よりも深く把握していく木川氏。気づけば、チーム内で「仕様についてわからないことがあれば、まずは木川さんに聞け」という状態になっており、特定の個人への依存度が高まり、「脱・木川さん」がチームの新たな課題となっている。

導入当初、開発メンバーの中には、新しい自動化ツールを「以前の外部パートナーの代わりに入ってきたもの（手数が一つ増えただけ）」程度に捉えている雰囲気もあったという。そこで矢追氏と木川氏は、「QAという品質保証はチーム全員でやるものだ」という文化を浸透させるための地道な活動を始めた。

毎回のスプリントレビューで、木川さんが設定してくれたMagicPodの内容をチーム全員に共有し続ける「草の根運動」を続けました。品質保証はチームでやるんだよという文化の浸透には苦労しましたが、その活動があったからこそ、協力してくれるメンバーもどんどん増えてきたのだと思います。（矢追）

その地道な啓発活動は、今、確実に実を結び始めている。

最近では、一部の開発エンジニアが空き時間に自発的にAIを活用して「MagicPodをより効率的に動かす方法はないか」と探求し始めてくれています。与えられたツールとしてではなく、「自分たちの開発ツールの一つ」として受け入れ、品質に向き合おうとしてくれる。この変化は本当に嬉しい成果ですね。（矢追）

目指すは「ポチッと押して帰ろう」――
心理的安全性の高いチームで本質的な品質向上へ

様々な試練を乗り越え、約7割のテスト自動化を軌道に乗せつつあるiAEON開発チーム。しかし、彼らにとってテストの自動化は決してゴールではない。定常的な作業をツールに任せることで生まれた“余白”こそが、人間が本来注力すべき領域への扉を開くからだ。

動作が正しく動くかどうかの確認は、ツールに任せることができます。だからこそこれからのQAは、さらに上流の要件定義の段階から入り込み、「ユーザーにとって使いづらくないか（ユーザビリティ）」や「本当にこの仕様で良いのか」といった、人間でしか判断できない本質的な品質の作り込みにより多くの時間を割いていきたいと考えています。（木川）

開発から検証まで、ユーザーの手に届くその瞬間まで全員で品質に責任を持つ。それこそが、内製アジャイルチームが目指す真の姿だ。

目指すべきは、1日開発したらその日の夜に自動テストをかけ、翌朝には「ここまでの機能は品質が担保されている」という安心感を持って次の開発に進める姿です。心理的安全性の高いチームを目指して、「押したら帰ろう」が実現できる世界を作っていきたいですね。（矢追）

「ポチッと終わる」という夢物語から始まったプロジェクトは、数々の壁を乗り越える日々を経て、チームの意識を根本から変える強力な起爆剤となった。イオングループの巨大な商流を支えるiAEONの品質は今、確かな熱量を持ったエンジニアたちの「自分たちの手」によって、日々磨かれ続けている。

イオングループでは一緒に変革に挑んでくれる方を募集中です。

どんなことをしているのか気になる方は、お気軽にご連絡ください。カジュアル面談も実施しておりますので、まずはざっくばらんにお話しましょう！