正解がないから面白い。MAU600万の巨大アプリ「iAEON」を育てる、ビジネスと開発の橋渡し役“PO-Px”のリアル

2026年1月に累計2,000万ダウンロード、月間アクティブユーザー数（MAU）600万人を突破し、国内有数規模へと成長したイオングループの公式アプリ「iAEON」。多岐にわたる事業会社やステークホルダーからの複雑な要望をさばき、スピーディに価値を届けるため、同社はアジャイル開発の原則である「プロダクトオーナー（PO）は1人」というセオリーを大胆にアレンジした独自の「POチーム体制」を採用している。

本記事では、ビジネス要件とシステム開発の狭間に立ち、両者を繋ぐ翻訳家であるPO-Px（プロダクトオーナー代理）の奈良、共にプロダクトを育てるビジネスPOの岸本・河野、そしてチームを支えるスクラムマスターの翁長による座談会を実施。公式な役割ではないからこそ生じた試行錯誤と、専門性の違うメンバーがいかにして率直に意見を言い合える共創チームを作り上げたのか、そのリアルな姿を紐解く。

スクラムの原則を破る独自の「POチーム体制」と「PO-Px」の誕生

通常のアジャイル開発（スクラム）において、「プロダクトオーナー（PO）」はプロダクトの価値を最大化するための全責任を負う役割であり、原則として“1人で担うもの”とされている。しかし、MAU600万人以上が利用する巨大アプリ「iAEON」の開発現場では、このセオリー通りの体制を組むことが極めて困難だった。

その最大の理由は、イオングループ特有のスケールの大きさにある。決済やポイント、各事業会社のサービスを統合するプラットフォームであるiAEONには、各所から要望が山のように日々寄せられる。POが1人であらゆる領域の意思決定から開発チームへの要件落とし込みまでを網羅することは物理的に不可能だったのだ。

そこで生み出されたのが、ビジネス側の要望をまとめる「PO（iAEON企画・運営部門）」と、システム開発側でその実現に責任を持ち推進する「PO-Px（プロダクトオーナー代理）」がバーチャルチームを組み、業務を分担・協業するイオン独自の「POチーム体制」である。

各所からの多種多様な要望は、まずビジネスPOが集約する。その後、要件の優先順位が上がってきた段階で、ビジネス側と開発側で「検討着手」の合意を形成。合意後はPO-Pxが配置されて要件の具体化に着手し、定期的なリファインメント（仕様調整の会議）の場において、開発（Dev）メンバーと共に要件の具体化・詳細化を推進していく仕組みとなっている。

翁長新たに参画したメンバーが最初に直面する壁は、ステークホルダーの圧倒的な多さです。複雑に絡み合う要望をいかに整理し、開発へ連携していくか。この高度な調整業務こそが、PO-Pxというポジションの最大の腕の見せ所であり、醍醐味であると考えています。

公式には存在しない役割「PO-Px」が抱いた手探りの葛藤

スクラム開発における公式のPOとも、従来のウォーターフォール開発におけるPM（プロジェクトマネージャー）とも異なる「PO-Px」。明確な役割定義が存在しない独自のポジションゆえに、立ち上げ当初の現場では、最適な立ち回りを模索する日々が続いていた。

奈良公式に存在しない役割であるため、当初は自身の立ち位置が定まらず、手探り状態でプロジェクトを推進することに最も苦労しました。開発チームに対してPMのようにトップダウンで指示を出すわけではないため、スクラムの中でどのように協働していくかについては、現在も継続して試行錯誤を重ねています。

その難しさを象徴するのが、巨大企業ならではの開発手法の多様性である。外部ベンダーとの協業によるウォーターフォール型の開発から、内製スクラムチームが主体となって推進するコア機能開発や迅速な価値検証を伴う機能改修まで、ひとつのアプリ内に全く性質の異なるプロジェクトが同居している。

「異なる開発手法や価値基準が混在する環境下でのプロジェクトマネジメントは極めて難易度が高い」と奈良は語る。しかし、そのような状況においても、ビジネスPOとして伴走する岸本は、PO-Pxの柔軟な対応を高く評価している。

岸本例えば、イオン株主さま向けの『イオンオーナーズクラブ（ミニアプリ）』の構築案件は非常に複雑なシステム連携が必要であり、ビジネス側だけでは判断がつかないため、ほぼ全面的に奈良さんに頼る形となりました。外部ベンダーが関わる領域では発注元のPMとして強固にコントロールし、内製スクラムチームに対しては伴走するPO-Pxとして立ち回る。案件の性質に応じて、その役割を柔軟に使い分けていただけるのは非常に頼もしいです。

この大規模案件において、奈良は過去の教訓を活かした重要なプロセス変更を行っていた。

奈良外部ベンダーが開発した機能をそのまま本番環境に組み込んだ結果、リリース後に「なぜこういう仕様になっているのか」と混乱を招くケースもありました。そのため、ベンダーからの納品物を内製メンバーに確認してもらうことをスクラムのプロセスで実現することで、二つの開発手法のハイブリッドな運用を確立させました。

試行錯誤を繰り返す中で、要件の「前さばき」の役割も次第に確立されていった。ビジネスPOから要件を受領する際、単なる「手段（やりたいこと）」ではなく、その背景にある「目的（どうしたいのか）」の明確な定義を求めるプロセスである。

岸本以前は、開発の要件定義において『なぜその機能が必要なのか（Why）』という目的が曖昧なまま着手してしまうリスクが少なからずありました。現在では、PO-Pxが事前に背景を精査・定義した上で進行できるようになったため、開発のブレが大幅に低減されたと感じています。

専門性の壁を埋める「翻訳家」として、ビジネスPOと二人三脚で歩む

小売の現場に精通するビジネス担当者と、システムを構築するITエンジニア。両者の間には、不可避な「専門性の壁」が存在する。このギャップを埋め、ビジネス要件をシステム要件へと正確に翻訳・変換する役割も、PO-Pxの真骨頂である。

店舗部門の出身であり、ITの専門知識を持たない河野。新機能の要件定義において、UIの視覚的なイメージは構築できても、それを具体的なシステム仕様として開発チームへ伝達するノウハウを持ち合わせていなかった。河野はPO-Pxとの協業について次のように語る。

河野自分のようにITの専門知識を持たないビジネスPO側が描いた要望を、PO-Px側が技術的な要件へと翻訳し、詳細な仕様設計を担っていただけるため、まさに“二人三脚”でプロジェクトを推進できています。

たとえば、災害発生時に急遽実施する「緊急支援募金」の開発を立ち上げた際、システム構造上は登録された募金名称をそのまま使い回す仕様になっており、個別の募金名（被災地名など）を都度変更することは開発負荷が非常に大きいという制約があった。しかし、金額入力欄の名称が同一のままでは「本当に意図した支援先に届いているか」とユーザーに不安を与えてしまう懸念があったため、表示名称の変更ができないかとPO-Pxに相談した。

開発負荷と顧客体験の狭間で悩むなか、PO-Pxは「金額入力の枠外にヘッダーバナーを追加し、そこに個別テーマを表示させる」という代替案を提示した。

河野開発側の技術的な制約を回避しつつ、お客さまに安心感を提供する最適なUI/UXを最小限の工数で実現できたのは、技術と顧客体験のバランスを共に追求してくれるPO-Pxがいたからこそです。ビジネス側の意向のみで独断的に仕様を決定するリスクを回避でき、常に多角的な視点でプロダクトを評価できるのは、非常に健全な状態だと感じています。

機能実装のフェーズにおいて、システム要件とビジネス要件の最適なバランスを調整する上でも、PO-Pxの存在は欠かせない。開発チームからシステム構造の最適化を目的とした代替案が提示された際、システムの制約とUI/UXの観点で優先すべき顧客体験のバランスをどう図るか。PO-Pxが双方のメリットとデメリットを客観的に比較し、建設的な議論をリードしている。

岸本「ここから先は自分の業務範囲外」と明確に線を引くのではなく、柔軟な連携によってPOのスキルを補完していただいています。開発期間の短縮や費用を抑えるための代替案を逆提案してくださる場面も多く、PO-Pxはプロジェクトにおいて不可欠な存在です。

また、PO-Pxはビジネス側と開発側の間に立ち、開発現場を不要な混乱から「守る」役割も担っている。ストーリーポイントを用いて計画的にタスクを消化するスクラムチームにとって、ビジネス側からの突発的な仕様変更やタスクの差し込みは、プロジェクトの進行に多大な負荷をかける。そのため、チームの適正な開発上限を見極め、それを超える要望が開発候補として上がった際には、PO-PxがビジネスPOと速やかに優先順位の調整を行う。これにより、開発チームが今取り組むべきスプリントに専念できる環境が維持されている。

河野当初は「なぜエンジニアと直接コミュニケーションが取れないのか。少し確認したいだけなのに」と、体制に窮屈さを感じることもありました。しかし、単に分断されているのではなく、公式な場で密に会話しつつ、日々の突発的な差し込みからは守るというメリハリのある構造なのだと、プロジェクトを進める中で深く理解できました。

共創プロセスが育む、プロダクトへの深い思い入れ

外部ベンダーへの開発委託が中心であったかつての環境では、構造上「システムを構築すること」自体が目的化しやすい側面もあった。しかし、開発の内製化が進み、POチームが主体的に機能し始めたことで、開発のカルチャーは根本的な変化を遂げている。

象徴的なのが、iAEONアプリのトップ画面（ホーム画面）の改修と新機能追加に伴うキックオフ会議での光景だ。

岸本ビジネスPO、PO-Px、デザイナーが同席するスモールチームで企画会議を実施した際のことです。PO-Pxがその場にいることで、「このUIを実現するには裏側のシステムも改修する必要がある」「実装にはこれくらいのスケジュールが見込まれる」といった技術的な観点を含めた具体的な議論が即座に展開されます。少人数のチームで活発に意見を交わし、ゼロから仕様を構築していく。このような共創のプロセスがあるからこそ、完成したプロダクトに対する深い思い入れが醸成されていくのだと思います。

プロダクトへの強いコミットメントの裏には、巨大アプリならではの重圧が存在する。その象徴とも言えるのが、ポイント付与と決済を一つのバーコードで完結させる「iAEONバーコード1回スキャン」機能の開発プロジェクトである。

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

イオンスマートテクノロジー、イオンフィナンシャルサービス、イオンアイビスの3組織が連携し、システムアーキテクチャの根幹に関わる大規模な改修が実施されたこのプロジェクト。開発の終盤に行われたパイロットテストでは、検証環境では見つからなかった課題が浮き彫りになった。開店前の朝8時から実機テストを開始したもののエラーが発生。問題解決が開店時間を超えた10時過ぎ（一般の顧客がいる時間帯）まで及ぶなど、現場は常に高い緊張感に包まれていた。

微小な不具合が大規模な顧客体験に直結するため、プロジェクトの進行は常に多大なプレッシャーと隣り合わせであるが、だからこその“やりがい”も感じられる。

奈良結果が出るまでの過程は困難の連続でしたが、関係各所と即座に連携してシステムを安定させ、実際にお客さまにご利用いただいている光景を目にした際は、「無事に動いた」という深い安心感と、この体制だからこそ成し遂げられたという大きな達成感に包まれました。

翁長若手メンバーからも、「自らが手がけた機能が実際に社会で動いていることに大きなやりがいを感じる」という声が聞かれます。影響範囲が広大であるためミスは許されないという緊張感はありますが、そのプレッシャーすらも原動力として楽しめる環境だと思います。

企画からPdMまで――「PO-Px」から拡張するキャリアの可能性

ビジネス領域とシステム（開発）の壁を越え、双方の知見を尊重しながら巨大なプロダクトのグロースを担うPO-Px。この独自の役割が持つキャリアの可能性や役割の魅力について語ってもらった。その締めくくりとして、3名それぞれにどんな人に来て欲しいかを聞いた。

翁長ビジネスPOとPO-Pxは、実務を通じて互いの領域への理解を深めています。ビジネス起点の企画から、開発ディレクション、PM、PdMなど、今後のキャリアの選択肢を大きく広げることができるポジションです。自身の専門性をさらに拡張したいという意欲的な方に、ぜひ参画していただきたいですね。

岸本要件定義の初期フェーズからプロジェクトに深く関与できる、非常にポテンシャルの高い環境です。決められた仕様を単に実装するのではなく、ビジネス要件をゼロからどのようにシステムで実現するかを主体的に考え抜ける方を歓迎します。

iAEONアプリを導入する各店舗の目的（KPI）は売上高の向上であり、アプリ開発や機能改善はあくまでそのための「手段」に過ぎない。しかし、開発に従事していると店舗の日常から離れるため、開発自体が目的化しがちである。どれほど美しいアプリであっても店舗で使いづらければ本末転倒となるなか、手段と目的が入れ替わりそうになった際、迷わず原点に立ち返るマインドが重要だ。

河野システム構築の技術にとどまらず、iAEONアプリを毎日使ってくださる『お客さまの存在』を置き去りにせず、店舗での体験を私たちと共に真摯に考え抜ける。そんな熱意を共有できる方と一緒に働きたいと思っています。

奈良高度な技術力もさることながら、この『iAEON』という巨大なプロダクトを自分ごととして捉え、より良いものへと進化させていきたいという強い熱意を持った方をお待ちしています。

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

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