イオンネクスト DevOpsグループ（開発チーム）｜イオンチーム紹介

約60万人が働くイオングループ。その中には、様々な個性をもった人々が集っています。同じ会社の中でも、チームによってカラーが変わることも。

この記事では「チーム」に焦点をあて、組織、メンバー構成、チームのミッション・ビジョン・バリュー、実際に取り組んでいる技術イシューやプロジェクトなどを紹介していきます。

今回はイオンネクストのDevOpsグループ（開発チーム）です。

【目次】

DevOpsグループの組織

2025年度の新体制により再結成

DevOpsグループはいわゆる“開発者集団”で、「How（どのように作るか）」を担当するチームです。DevOpsグループという体制は、2025年3月からの新体制に伴って再構築されたチームとなっています。実は、イオンのネット専用スーパー「Green Beans」のローンチ前にも、各領域に特化したプロジェクトマネージャーやエンジニアそれぞれが集まるソフトウェア開発チームが存在していました。今回のDevOpsグループは、それをさらに発展させたものになります。

DevOpsグループは「How」に基づく技術的な側面に特化しています。というのも、これまでは、開発者が業務部門の細部にまで関わろうと業務知識のキャッチアップも試みましたが、思った以上に時間がかかり、本来の開発業務に集中できないという課題が生じたからです。

そのため、以前のように業務部門との会議を毎日繰り返して情報をキャッチアップするのではなく、必要な会議を選定しながら開発に時間を割けるように運用しています。

初期の「サービス開発」から「グロース運用」へ

具体的な開発領域としては、大きく2つの軸があります。一つ目は、サービスそのもののスケールです。ユーザー数や注文数といったサービスの利用規模がローンチ時に比べて格段に増えており、それに対応するためのアーキテクチャの見直しや再構築が求められています。単純な延命ではなく、大規模トラフィックにも耐えうる強固なシステム基盤へと進化させていく必要があります。

もう一つは物流拠点の拡大です。現在、イオンネクストのGreen Beansは千葉にある1拠点のみで運営していますが、2026年夏には東京・八王子、2027年には埼玉・久喜に新たな倉庫を開設する予定です。つまり、今後1〜2年で「倉庫1拠点体制」から「3拠点体制」へと移行していくなかで、システム側も「n個の倉庫に対応する」ことが不可欠になります。これまでの倉庫1拠点から複数の拠点になると、在庫や出荷、配送に関するデータ構造や処理の考え方が大きく変わってきます。

全体の処理量が増えるだけでなく、データが物理的にも分散するため、従来のように既存のシステムを小さく改修するだけでは限界が出てきてしまいます。こうした大規模な変化を乗り越えるためには、あらためて開発体制を刷新し、戦略的に開発を推進する専任チームが必要だという判断に至りました。

組織の役割について

内製開発

• PM/PdM：3名

• EM：5名

• エンジニア：10名

• ネットワークエンジニア：12名

イオンネクストの開発体制は、社内の内製チームが約30名、さらに外部のフリーランスや協力会社を含めると約120名規模となっています。今回の新体制で特に重要なのは、「開発者が開発に専念できる環境を整えること」です。周囲のステークホルダーとのコミュニケーションにおいては、技術的な内容をわかりやすく翻訳して共有することが求められます。そこで鍵を握るのが、エンジニアリングマネージャー（EM）の存在で、昨年後半からはEMの採用強化に注力しています。

また、イオンネクストのビジネスモデル自体が「垂直統合型」であるため、それに対応したシステムも非常に多機能・多層的です。具体的には、12の主要コンポーネントと180以上の業務ルールに基づいてシステムが構築されており、これを実質10名ほどのエンジニアで開発・運用しています。

そのため、EMの役割は多岐にわたっていて、「手も動かすエンジニア」でありつつ、「PMの役割」も担うというハイブリッドなポジションになっています。

DevOpsグループ（開発チーム）のミッション・ビジョン・バリュー

2025年度の新体制からOKRを導入

DevOps（開発チーム）はイオンネクスト全体のミッション・ビジョン・バリューに倣うようにしていて、「オーナーシップ」や「ユーザーファースト」といったシンプルな構成になっています。

そして、2025年の新体制からはOKR（Objectives and Key Results）を導入しました。イオンネクスト全体の「デジタル戦略」に紐づいたOKRを各自が設定し、主体的に取り組む流れをつくろうとしています。

トイル率改善に向けて未来を見据えた動き方にシフト

昨年の全体的な課題として大きかったのは、IT部門が「システムを構築する」という本来の目的から外れて、業務部門から起票されるチケットの処理に追われてしまったことです。

イオンネクストではタスク管理にJiraを採用していますが、昨年度はチケットの中身も、目の前のトラブル対応や既存業務の保守といったものが多く、トイル率は79.8％にもなっていました。つまり、未来を創るための活動にほとんど時間を割くことができない状況でした。そこで今年度からは、未来を見据えるための取り組みを復活させることを重要視しています。

今後控える拠点拡大を見据えたシステム像を構想し、それに向けた“攻め”の開発を進めていくのが今年度の大きな方針です。

昨年までも年間目標はありましたが、現場からのチケット対応が優先されがちで、野心的な取り組みは難しい状態でした。そこを変えるためにも、今回はよりビジョンドリブンな目標設計と動き方を重視しています。

OKRを軸にした定例会の実施

具体的な改善策の1つとして、定例会の進行方法を大きく見直しました。以前は、最初に障害発生リスクの数やトラブル状況といった情報共有に多くの時間を費やし、最後に開発の進捗を報告するという流れで、会議の大半がトイルに偏っていました。

しかし2025年からは、まず最初に現在進めている開発がOKRとどのように結びついているのか、達成状況はどうなのかなどを共有するようにしました。今取り組んでいることを再確認しながら、チーム全体の意識をより前向きにし、将来の開発に焦点を当てるカルチャーを醸成しようとしています。

DevOpsグループで取り組むプロジェクト

最優先事項はDBアーキテクチャの再設計

Green Beansは、この1年でトラフィックが約9倍にまで増加しており、現在のデータベースアーキテクチャでは既に限界に近い状態です。このままでは、来年、再来年に予定されている新倉庫の開設に対応できないため、データベースのリアーキテクチャをしっかりと時間をかけて行うことが喫緊の課題となっています。

そのため、CTO直下案件としてこのデータベースの再設計プロジェクトを最優先で進めています。

12のコンポーネントごとに新たなチームを組成

引用：ただモダンに走らない。大企業のレガシー資産と折り合いをつける「“開発”のダイバーシティマネジメント」とは。 ｜AEON TECH HUB

Green Beansを運営するためにシステムを12のコンポーネントに分けていますが、今後は各区分ごとにチームを立ち上げています。「オウンドメディア」でお客さまの自然集客を最大化するようシステムを開発したり、「サプライチェーン」では需要予測に基づいた商品発注を行ったりと、サービスの拡大に伴うパフォーマンス改善や効率化を推進していくことが大事になります。

また「会計」の領域では、「在庫評価」が重要なテーマとなっています。イオンネクストでは、一つひとつの商品に対して原価を計算し、在庫の価値を正確に把握する「単品在庫評価」の仕組みを導入しています。

一般的な小売現場では、店舗に入荷する商品数が膨大であるがゆえに、単品ごとの正確な原価計算は困難です。一方で、イオンネクストではリアルタイムで詳細な在庫評価が可能であり、無駄な発注や過剰在庫の抑制、廃棄ロスの削減などにも寄与していることから、将来的にはグループ全体へ横展開していくことで、イオングループ全体の営業利益の改善にも大きく貢献していきたいと考えています。

関連記事：流通小売業の常識を逆転する「デマンドチェーン」を支える指標とデータ基盤 ｜AEON TECH HUB

AIが変えるプロダクト開発と組織体制

「バイブネイティブ組織」を意識した体制づくり

2025年3月に新体制へと移行したタイミングで、バイブコーディング（人間が一切コードを書かずに、AIがプログラミングする手法）が登場し、生成AIの技術に大きなブレイクスルーが起きました。

加えてアウトカム達成のためにはプロダクトマネジメントやユーザーリサーチなど、専門的なノウハウを持つプロ人材が不可欠でした。それが生成AIとディープリサーチの活用によって、これまで把握しきれなかったビジネスの複雑な背景や要件を把握することが可能になりました。

私たちはAIを千載一遇のチャンスと捉え、その能力を最大限に引き出すことが重要だと考えています。今年はプロダクトマネジメント組織としてチームを運営していますが、AIのさらなる進化によってはその体制自体に変化を起こせるかもしれない。そう感じており、来年度にはAI前提の新たな開発組織のあり方である「バイブネイティブ組織」へと刷新していこうと計画しています。

バイブネイティブについては、以下のブログ記事で詳しく解説しています。

関連記事：バイブネイティブ：AI駆動のバイブオブザーバビリティとバイブコーディングで、誰もが主役の開発革命を

AI駆動開発を本格化

AIにプロンプトを投げて、次々に実装を進めていく開発スタイルを実践するために、6月には「プルリクマラソン1000」という企画を立ち上げました。これは、CTOが1人で1ヶ月間にプルリクエストを1000件出すという試みです。

通常、Web開発チームの1ヶ月の総プルリク数は200〜300件程度なので、その5倍くらいの量を1人でこなすという非常にチャレンジングな取り組みになります。この取り組みを通じて、周りのメンバーも同様にAIを活用し、開発プロセスを劇的に加速させ、今までは不可能であったことを出来るようになりたいと考えています。

技術スタック

クラウド環境はAzure、AWS、GCPに加え、全社共通のプライベートクラウドまで、あらゆるプラットフォームを横断的に活用しています。プログラミング言語については、C#以外にGo、Python、Node.jsといったモダンな言語も多くなっていますが、VScodeなどで動作するAIエージェント型の拡張機能「Cline」は、フロントエンドのコードをAIがその場で生成・提案してくれるたりと、非常に画期的なツールです。

AIのツールはPerplexityやChatGPT、Claude、NotebookLM、Google Agentspaceといったサービスを検証中です。

特に注目すべきは、これまでシステム導入の最大の課題だったセキュリティチェックのプロセスが劇的に改善されたことです。以前は、各システムの手順に沿って詳細なセキュリティレビューを行い、承認を得るまでに非常に多くの時間と労力を要していました。

しかし、現在はディープリサーチ機能を備えたAIにセキュリティチェックを指示するだけで、必要な情報が瞬時に提示されるため、セキュリティレビューを圧倒的なスピードで完了できるようになりました。

DevOpsグループの実績

AI活用でチケットの品質とREADMEの執筆率が向上

AIの活用によって、Jiraで管理するチケット説明文の質が格段に向上したほか、これまでおざなりになりがちだったREADMEの執筆率が劇的に改善しました。特に以前はREADMEの内容があまり充実したものではなかったのが、AIによって高品質なドキュメントが安定して生成されるようになっています。

自社配送のナビ開発におけるAIを用いたモック作成

Green Beansにおけるデリバリー効率化のために、GoogleマップのSDKを使用したカーナビアプリを自社で開発しましたが、まだ改善の余地が多く残っています。

現在、自社配送のドライバーを積極的に採用していますが、長年の経験を持つプロのトラック運転手もいれば、免許取り立ての若手ドライバーもいて、ドライバーの運転技術レベルにばらつきがあります。

安全運転できる道の感覚は個人差が大きく、安全に配慮したルートをドライバーごとに最適化することが求められているわけです。そこで、バイブコーディングを用いて「こういう機能が欲しい」「運転技術に応じてルートを変えられるナビ」という要望をプロンプトとして入力すると、すぐにAndroidアプリのMVPを作ることができました。

それをデリバリーの業務部門に見せたところ、「これこそ求めていたものだ」と非常に好評です。会議のトランスクリプションから、AIが簡単にモックを生成できるため、技術コミュニケーションを大きく進化させるものだと考えています。

関連記事：「無いものは、つくるしかない」イオンが自前のカーナビアプリを作った理由。 ｜AEON TECH HUB

Green Beansアカデミーによる社内AI研修

直近では非エンジニアの業務部門の方々に、AIでできることや活用の仕方を教える社内向けの「Green Beansアカデミー」という研修を定期的に行っています（現在は毎週開催に拡大しました）。業務部門の方が少しでもAIツールの扱いに慣れ、自分でモックを作るレベルに到達すれば「開発の民主化」がより加速していくと考えています。

実際、社内のITヘルプデスク担当メンバーの中にも、ソフトウェア開発経験が全くないなかでバイブコーディングを覚え、勤怠管理用のChrome拡張機能やチケットの状況を管理するダッシュボードなどをを作成した事例も出てきています。

AIを前提としたワークフローを通じて、業務部門のメンバーとITチームがより深く連携し、一体となって開発を進められるようになることを目指しています。

イオンネクストではエンジニアを中心としたデジタル人材の採用を積極的に行っています。話を聞いてみたい、Green Beansの事業が気になる…といった方は、カジュアル面談も実施しておりますので、ぜひお気軽にご連絡ください。