2回のバーコード読み取りを1回に。複数の会社をまたいだ「iAEONバーコード1回スキャン」開発プロジェクトが教えてくれたこと

「会員コードを読み取ってください」「AEON Payのバーコードを読み取ってください」――。イオン店舗のレジで買い物をする際、かつては2つのバーコードを順に提示する必要があった。わずかな手間とはいえ、混雑時には後ろのお客さまを気にしながらスマートフォンの画面を切り替える煩わしさもあった。

2024年11月、この二度手間が解消された。イオングループの公式スマートフォンアプリ「iAEON」がアップデートされ、ポイント付与・クーポン利用から決済までを1回のバーコード表示で完了できるようになったのだ。

一見シンプルな機能改善の裏には、複数の組織が関わる大規模な開発プロジェクトが存在していた。プロジェクトを率いたのは、イオンスマートテクノロジー（以下、AST）ビジネスプロジェクトユニット ビジネスプロジェクトチームの奈良だ。彼がこの開発を通じて直面した予期せぬ課題と、そこから得た学びとは。

【目次】

イオンタワーでの副社長の一言から始まったプロジェクト

iAEONの会員バーコードとAEON Payのバーコードを別々に読み取る必要があった支払い手続きを、1回のスキャンで完了できるようにする「iAEONバーコード1回スキャンプロジェクト」。このプロジェクトは、2023年秋のある日、幕張新都心のイオン本社ビル・イオンタワー11階での会話から始まった。

当時のAST副社長であった金子は、「バーコードを1回スキャンするだけで支払いまで完結できないか」と提案した。その言葉を受け、今回のプロジェクトで開発チーム側のプロジェクトオーナーを務めた奈良が動き出した。「金子は当初からこの課題を強く意識していたと思います」と奈良は振り返る。金子からの投げかけは、すぐに具体的なプロジェクトとしてスタート。2023年末には開発に着手していた。

たしかに、アプリ内で2回のバーコード読み取りが必要な仕様は、ユーザーにとって大きな負担となる。結果として、iAEONアプリの普及を妨げる要因のひとつにもなっていた。しかしながら、バーコードが2本に分かれていた背景には、それなりの理由もあった。

会員バーコードとAEON Payのバーコードでは、役割が異なります。会員バーコードはクーポンやオーナーズカードなどの会員サービスを利用するためのもの。一方、AEON Payのバーコードは支払いに特化しています。たとえば、クーポンは使いたいけれど支払いは現金でしたいお客さまもいらっしゃいます。バーコードが分かれていたのは、そういった多様なニーズに応えるためでした。（奈良）

このような明確な理由があり分かれていた2本のバーコード。それを統合するためには、複数の組織が保有するシステム間での緻密な連携が必要だった。

3つの組織による大規模開発 - 疎結合を意識したシステム設計

このプロジェクトには、イオングループの金融事業を担うイオンフィナンシャルサービス（以下、AFS）、イオンアイビスIT事業部（当時：現在はASTに統合）、そしてASTが参画。それぞれが異なる役割を担い、ひとつのゴールを目指した。

AFSは決済ゲートウェイ、イオンアイビスはPOSシステム、そしてASTはその間をつなぐイオン会員基盤とフロントエンド開発を担当しました。開発は完全リモート体制で進めました。（奈良）

一見すると単純なバーコード統合の裏には、システム全体のアーキテクチャに関わる重要な判断があった。iAEONの会員情報をどのシステムで保持し、どう連携させるか。その選択が、今後のシステム拡張性にも大きく影響するためだ。

具体的には、大きく分けて3つの選択肢があった。会員情報の処理をPOS側に寄せる案、決済ゲートウェイ側に寄せる案、そしてiAEON会員基盤を中心とする案だ。最終的には、iAEON会員基盤を中心とする案が採用された。

POSや決済ゲートウェイにも会員情報はありますが、大元はiAEON会員基盤のデータです。ほかのシステムに寄せると、データの更新や連携が複雑になってしまいます。できるだけシンプルな設計を目指しました。（奈良）

さらに、システム間の連携においては、疎結合を意識した設計が採用された。「各組織の領域をできるだけ独立させ、インターフェイスだけをしっかり決める。そうすることで、将来の変更や拡張に柔軟に対応できます」と奈良は説明する。

特にAPIの開発では、慎重な判断が必要だった。当初は、既存のシステムをできる限り活用しようという方針だったが、結果的にほとんどのAPIは新規開発することとなった。ただし、処理フローについては既存の仕組みを参考にしている。奈良は「まったく新しいものを作るのではなく、実績のある処理の流れを活かしながら、新しいAPIを構築していきました」と振り返る。

「どちらのバーコードを主役にするか」問題は、顧客目線で議論

開発チームが直面した次の課題は、どちらのバーコードを主体とするかという選択だった。当初、開発チームは「どちらでも可能」という案を提案した。つまり、会員バーコードでもAEON Payのバーコードでも、どちらを読み取っても支払いまで完了できる仕様だ。

「技術的には可能でしたし、ユーザーに選択肢を提供できる良案だと考えました」と奈良は話す。しかし、この提案は社内会議であっさりと却下された。理由は「お客さまが混乱する」という一点だった。

そして、度重なる議論の結果、会員バーコードを主体とする方式が採用された。AEON Payのバーコードを主体とした場合、クーポン適用後にレジに表示される金額と実際の支払い金額が異なる可能性があったことなどが主な理由だ。

この選択には、もうひとつの重要な考えが込められていた。「AEON Payを使うお客さま、使わないお客さま、オーナーズカードだけを使うお客さまなど、さまざまな利用パターンがあります。すべてのお客さまにとって自然な流れとなるのは、会員バーコードを起点とする方式だという判断です」と奈良は説明する。

一見、技術的な選択に見えるこの判断の根底には、すべてのお客さまの使い勝手を最優先する、イオンの顧客第一の考え方が反映されていたのだ。

実店舗でのパイロットテストで想定外の事態と遭遇

開発終盤、プロジェクトは重要な局面を迎える。実店舗でのパイロットテストだ。最初のテスト会場となったとあるダイエー店舗での出来事を、奈良は生々しく記憶している。

朝8時から始めたテストで、いきなりエラーが発生しました。本来なら開店前の9時までに終わらせる予定でした。しかし、問題が解決したのは10時過ぎ。すでに一般のお客さまがご来店されている時間帯でした。（奈良）

開発環境では問題なく動作していたシステムが、本番環境ではエラーを起こし、正常に機能しなかった。裏では開発メンバーが待機していたため、すぐに原因究明に取り掛かることができたが、それでも解決までに予想以上の時間を要した。混雑する昼時が近づくなか、テストに来ていた本社スタッフが店舗スタッフと間違えられ、お客さまから商品の場所を聞かれることもあったという。

印象的だったのは、ダイエーの柔軟な対応だった。「一般のお客さまがいるなかでのテストを許可していただき、本当に助かりました」と奈良は感謝を込めて語る。

後日行われた別店舗でのテストでは、新たな課題が浮上した。それは、当初の設計では想定していなかった買い物の新しい形態との連携だった。具体的には、「レジゴー」と呼ばれる、顧客自身がスマートフォンで商品のバーコードをスキャンして専用レジで会計するセルフショッピングサービスである。

このレジゴーは、iAEONアプリから起動できる「ミニアプリ」として提供されていた。ミニアプリとは、アプリ本体とは別に動作する軽量なWebアプリケーションで、必要に応じて機能を追加できる仕組みだ。開発チームにとって意外だったのは、レジゴーミニアプリを使用した場合、会員情報が自動的に転送されるため、会員バーコードの読み取りが不要になる。「このケースを想定していなかったことが大きな反省点だった」と奈良は振り返る。レジゴーミニアプリには稼働時間の制限があるため、店舗オープン後に一般の顧客として買い物をする形でテストを行い、動作確認を進めたという。

実際に、レジゴー利用時にのみ発生する不具合が見つかり、緊急で改修して本番リリースに間に合わせました。開発を始めた2023年秋の時点では、レジゴーミニアプリはまだ存在していなかったため、事前に十分な検討ができていませんでした。（奈良）

一連のテストから得られたのは、単なる技術的な問題発見以上のものだった。

検証環境では、どれだけテストを重ねても見つからない問題があります。POSシステムだけを見ても、実店舗にはさまざまな種類があり、全パターンの検証は困難です。また、レジゴーミニアプリの事例が示すように、私たちのアプリはほかのシステムと密接に連携しており、その関係性は日々進化しています。ミニアプリのような新しい機能が次々と追加されるなか、影響範囲を完全に把握することはますます難しくなっている。だからこそ、実店舗での入念なテストと、想定外の事態に柔軟に対応できる体制づくりが重要です。（奈良）

より快適な買い物体験を目指して進化を続けるiAEONアプリ

現在、このiAEONバーコード1回スキャン機能の利用率は、iAEONでの支払い全体の半数以上に達している。導入初期はわずか10%程度だったが、徐々に上昇を続けているという。

しかし、プロジェクトはまだ完全な完了点には達していない。実は、バーコード自体はまだ2種類存在しており、将来的な完全統合も視野に入れている。

今後のアプリ開発における課題も多い。たとえば、iAEONは機能を増やすごとに、アプリ自体が重くなっていくため、新規でダウンロードする際の容量が課題になっている。

その解決策として注目されているのが「ミニプログラム」だ。現在iAEONでは、レジゴーのような追加機能を「ミニアプリ」としてWebベースで提供している。一方、「ミニプログラム」は必要な機能だけを必要なタイミングでアプリにダウンロードする、より軽量な仕組みだ。中国のWeChat（微信）などで普及している技術だが、以前はプラットフォーム側が禁止していた。最近、規制が緩和され、採用を検討できるようになってきている。

アプリ開発は、技術の進化とユーザーニーズの多様化という2つの大きな流れのなかにある。バーコード1回スキャンは、ユーザーの使いやすさを追求したひとつの成果といえる。しかし、これはまだ通過点に過ぎない。より快適な買い物体験を実現するため、ASTの挑戦はこれからも続いていく。

複雑化するシステム開発への示唆 - プロジェクトから得た教訓とは

このプロジェクトを通じて得られた最大の学びは、影響範囲の見極めの重要性だと奈良は語る。

アプリの機能が増え、外部連携が増えていくなかで、ひとつの変更がどこにどう影響するのか、その見極めがますます重要になっています。特に最近は、ミニアプリやミニプログラムなど、アプリ本体から切り離された機能が増えていく傾向にあります。そのぶん、影響範囲の特定は複雑になっていきます。（奈良）

それに伴い、実店舗でのテストや関係者とのコミュニケーションの重要性も高まっていく。

今回の反省として、レジゴーチームとの連携が不十分だったことがあげられます。最初から開発チームに入ってもらい、早い段階からコミュニケーションを取れていれば、今回起きた問題は防げたかもしれません。（奈良）

一見シンプルな機能改善の裏には、数多くの組織と人々の協力、そして緻密な技術的検討があった。そして、その過程で得られた学びは、今後ますます複雑化していくアプリ開発の現場で、確実に活かされていくことだろう。

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

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

【関連記事】

iAEONアプリに興味がある方へはこちらの記事もおすすめです。

1000万ユーザーへのプッシュ配信を3倍高速化 - iAEONアプリの大規模配信基盤改善の舞台裏

イオンの“レシートレス機能”開発秘話。現実世界の複雑なオペレーションをどう実装したのか。