連結営業収益9兆円。“途方もない”という言葉が誇張でない規模のイオングループは、アジア最大の小売企業です。301社の連結子会社と27社の持分法適用関連会社（2024年2月時点）から構成される同グループは、日本国内はもちろん中国やASEAN各国においても多くの人々に愛されています。

こうした大規模で長い歴史を持つ企業は、エンジニアから「上意下達の企業文化や硬直的な組織運営なのではないか」「レガシーな技術を採用しているのではないか」と、敬遠されることがあります。しかし、イオン株式会社CTO・イオンスマートテクノロジー株式会社CTOである山﨑賢さんは「歴史の長い巨大企業だからこそ味わえる、エンジニアリングの面白さがイオンにはある」と語ります。山﨑さんは、エンジニアリングを活用してイオングループをどのように変革しようとしているのでしょうか。

JTCはエンジニアリングの力をフルに活かせる環境

――山崎さんは2023年4月よりイオンとイオンスマートテクノロジーのCTOに就任されました。まずはその経緯をお聞きしたいです。

これは半分冗談でいつも言っていることですが、この会社に入った理由のひとつは家が近いからです（笑）。イオン本社の徒歩圏内に住んでいます。真面目に話すと、私は過去にリクルートで開発組織のマネージャーをしており、社員と業務委託を合計すると1,000人くらいを管轄していました。仕事は面白くて充実していましたが、このまま同じ環境で働き続けると大企業病になると思いました。もう一度きちんと現場で働きたくて転職し、2社のスタートアップのCTOを経験しました。その後に再度大きな企業に戻れば、違う視点で物事を捉えられると考えたんです。

「あと1～2年が経ったら大企業に転職しよう」と想定していたタイミングで、イオンから声がかかりました。仮に1～2年後に転職活動をしても、これ以上の規模の企業でCTOを担えるチャンスはないだろうと思い、転職を決めたという流れです。

――山崎さんは昨年末に「巨大企業でDX革新を起こすということ」というブログ記事を書かれていました。この内容を踏まえて伺いたいのですが、エンジニアリングを活用して大企業を変える難しさや面白さはどのような点にあると感じますか？

社内に数多くのステークホルダーがいるので、そうした方々の懐に入るような関係性の構築が必要になることが多いです。こちらが一方的に「こんなシステムを導入すると良いですよ」と押し付けても、相手側の課題とマッチしなかったり、考え方の違いで受け入れられなかったりします。

だからこそ、場合によっては他部署の人と飲みに行くとか、職場を訪問して信頼関係を構築するなどして、「このCTOは上から目線でものを言っているわけではなく、自分たちのことを助けようとしているんだ」と信頼してもらうのが大事です。

エンジニアによっては、こうしたJapanese Traditional Company（以下、JTC）の特徴をあまり快く思わない人もいるでしょう。エンジニアは基本的に「新しい技術に触れることができ、自らのスキルを磨けて、かつエンジニアが尊重されている会社」で働きたいんですよね。

JTCはレガシーな技術を使っていることも多いですし、プロジェクトの主導権がエンジニアではなく他の職種の人々にあることもよくあります。しかし、その環境に対して「JTCは嫌だ」と言ってしまうのは、私は違うと思っています。エンジニアという仕事の本当の価値は「心地良い環境で働くこと」ではなくて「エンジニアリングを通じて効果を発揮して、世の中をより良い方向に変えていくこと」です。

そして、エンジニアリングによる効果は、事業の規模が大きければ大きいほど増幅します。そう考えると、規模の大きな事業を展開しているJTCは、相当にレバレッジが効く環境だと言えますよね。そういった理由で、私はイオンで働くことに大きな魅力を感じています。

ただこうした前提がありつつも、現在のエンジニア採用は超売り手市場ですから、「大変なこともあるけれど、イオンで働いてほしい」と言っているだけでは、人材は他社に流れてしまいます。だからこそ、エンジニアが働く環境を整えて、技術的なチャレンジをするといった取り組みも、着実に続けていきたいと考えています。

現場の課題を拾い上げるには、現場に行くしかない

――Webメディア「what we use」のインタビューでは、各企業が取り組んできた技術的意思決定のなかで印象に残るものや、そこから得た学びを話していただきます。

イオンスマートテクノロジーはイオングループ全体のDX推進を目的として生まれた会社で、2020年に設立されました。私が2023年に入社したタイミングでは、最初の大きなプロジェクトがリリースされた後くらいの時期で、システムの障害も多発していました。そして、システムのトラブルが起きると店舗のスタッフやお客さまが困ることになるので、現場にいる方々とシステム開発者たちとの関係性も良くない状況だったんです。

その状況下で、品質改善プロジェクトを推進しました。問題となっていたシステムは、負荷対策やサーバーの冗長化といった大規模な利用を前提とした思想で作られていなかったため改善が必要でした。そのため、サーバーをスケールアウトすることでシステム全体の処理能力や可用性を高めるといった、Webサービス開発のセオリーに沿ったアーキテクチャへと変えていきました。また、各種アプリケーションやAPIなどに対して「サービスレベル」の考え方を導入しました。

たとえば、私たちが提供しているシステムのなかに「決済」「ポイント」「店舗情報」がひとつになったイオングループの公式アプリ「iAEON」があります。このアプリでは店舗やクーポンの情報、各種の広告バナーなどが表示されており、それぞれが各種のAPIから情報を取得しています。このうち、最も重要なのはポイントが貯まる機能と決済の機能です。この2つは買い物の際にレジで使うので、もしうまく動かなければ店舗のスタッフもお客さまも困ってしまいます。

かつて、このアプリは「すべてのバナーを読み込めなければ、トップページそのものが表示されなくなる」という作りになっていました。しかし、仮に広告の表示に失敗しても、ポイントが貯まる機能と決済の機能は動作するほうが、ユーザーにとっては親切です。

そこで、特定のAPIからの情報取得に失敗しても、サービスレベルの高い機能だけは使えるような構造にしました。それによって、障害はたまに起きているものの、ユーザーが困るようなトラブルにはつながらない設計になっています。店舗のスタッフからも、「最近はシステム障害が起きなくなりましたね」という評価をもらっており、社内の関係性も良くなっています。

――この記事を読まれる方のなかにも「システムの品質に課題があり、店舗のスタッフやユーザーに迷惑をかけてしまっている」という環境で働くエンジニアがいると思います。そういった方々に、御社の事例を踏まえてアドバイスはありますか？

現場からシステム開発部門に寄せられる声というのが、真の課題を捉えていない可能性があると思うんですよね。なぜなら、エンジニアが受けるお叱りというのは、現場の責任者やマネージャーが報告しているケースが多いじゃないですか。でも、責任者やマネージャーも、現場の人々から上がっている意見を集約してレポーティングしているので、重要な情報が抜け落ちている可能性があります。

だからこそ、「管理職の方々をどう納得させるか」ではなく「現場の人々の課題をきちんと拾い上げたうえでエンジニアリングによる課題解決をして、その結果が管理職の人たちに還流される」というアプローチをするほうが、こうした大きな会社を変えやすいと思います。

――どうすれば、現場にいる人たちの声をうまく拾い上げられるでしょうか？

現場に行くしかないでしょうね。私がイオンに入って最初にやったことは、まず実際に現場に赴くことでした。中国にもイオンの子会社があるんですが、これまで日本のエンジニア社員は誰も中国に行っていなかったんですよ。そこで、単身で出張をして現地のスタッフに話を聞きました。また、初期の頃はCTOとは言わずに、店舗のスタッフとして働いたこともありました。そうすると、本当の意味での現場の課題がわかるんですよね。咀嚼されてドキュメントに落とされた情報だけだと、そうしたことが見えてきません。

いかにして社内の信頼を勝ち取るか

――他の事例もお聞かせください。

障害がある程度収束したタイミングで、新しい技術を導入していくプロジェクトを推進しました。やはりエンジニアにとっては、技術的なチャレンジがあったほうが良いじゃないですか。それができる環境は働きがいがありますし、エンジニアのモチベーションが向上すれば結果として会社のためになります。

具体的にお話しすると、イオンでは巨大な基幹系データベースをいくつも持っていますが、それらをTiDBというNewSQLにリプレイスするための技術検証を、PingCAP社と一緒に進めています。また、データ活用に関してもSnowflakeを導入するなど先進的な事例に取り組んでいます。

――山崎さんが技術選定を行ううえで大事にしている軸はありますか？

まずはオープンであることですね。日本固有の技術や特定の企業に依存している技術ではなく、どの国やどの会社でも使える技術であること。そして、新しいこと。働いているエンジニアたちが、その技術に触れることでモチベーションが上がるとか、市場価値が上がる可能性が高いということを重視しています。もちろん、ただ単に新しいだけではダメで、その技術を導入することで事業にとってプラスになることは大前提です。

――大企業において新しい技術を導入する際には、社内のステークホルダーへの説明が大変な印象があります。どのようにして、そうした段取りを進めていますか？

これはアドバイスになるかわかりませんが、社内調整のために時間を使うのではなく、その調整を必要としない環境をいかに構築するかが重要だと思います。私はどのような職場でも、まず「社内での信頼を獲得すること」を最優先にしているんですよね。

エンジニアリングだけではなく複数の手段を使いますし、自分たちの実施したことを広報する活動も積極的に行います。そうした活動を続けていると、「山崎さんのやっていることなら大丈夫だろう」という信頼が社内で生まれて、社内調整そのものを減らせるんですよ。私はそうしたやり方をしましたが、人によって向き不向きがあるので、違うやり方もあると思います。

「イオン×エンジニア」という軸でDevRelを実施

――山崎さんがCTOに就任してから、外部への情報発信が非常に活発になった印象があります。そうした活動についてもお話しください。

確かに、DevRel系の活動にはかなり力を入れています。前提として、イオンという会社はすごいじゃないですか。日本人で、イオングループのサービスを利用したことのない人はほとんどいないと思うんですよ。一方で「イオン×エンジニア」という組み合わせはさほど認知されていないですよね。イオンという社名を見たときに、「技術力の高い会社」と想起する人はほとんどいません。

Googleなどの検索キーワードの市場で、かけ算がブルーオーシャンな領域というのは大きな価値があります。そのキーワードの組み合わせで認知を獲得すれば、その領域のパイオニアになれますからね。だから、「エンジニア」と「イオン」というポピュラーワードのかけ算が現時点で存在していないならば、逆に言えばこれから何でもできるチャンスだと思ったんです。

伸びしろしかないので絶対にDevRelをやろうと決めたのと、社内で働くエンジニアたちにも還元できる要素が大きいと考えたんですよね。要するに「イオンを変えた人たちはこのエンジニアたちだ」と、外部の人々に知ってもらえるじゃないですか。そう考えて、エンジニア採用支援を行うトラックレコード社の力を借りて、DevRelに注力することにしました。

その結果、やはり狙い通りでイオンというキーワードそのものに惹きがあるからこそ、「イオンがエンジニアリングの情報発信を強化している」というだけで、懐疑的な人も含めて大勢が見にきてくれます。うまくいっている要因の8割くらいは先人たちが築いたイオンというブランドの力で、そこに私がエンジニアという変数を注入したら爆発しただけなんです。

――DevRelの施策を続けるなかで、採用にプラスの影響が出ている部分はありますか？

相当にありますよ。これまでエンジニア採用はエージェント経由が多かったのですが、ダイレクトやリファラルが増えていますね。イオンスマートテクノロジーの例で言えば、内定を出したエンジニアのうち、かつては95%くらいがエージェント経由だったのが、現在は50％以上がダイレクトやリファラル経由になっています。

――明確に結果が出ていますね。山崎さんがDevRelの施策を実施するうえで大事にしていることはありますか？

「何でもやる」ですね。イベント登壇やメディア取材など、来た依頼はなるべく断らないようにしています。一つひとつの施策に対して「どれくらいの効果があるのか」と検証するのではなく、その代わりにとにかく数をこなそうということ。これは私自身もそうですし、部下たちが「こういった情報を発信したい」とリクエストを出したものはほぼすべて承認しています。ブランディングは積み重ねが大事です。何か大きなイベントに1回登壇したからうまくいくのではなく、くり返しいろいろな場に露出し続けることで認知されるようになります。

イオングループ全体をテクノロジーで変える

――山崎さんの今後のビジョンを教えてください。

イオンは国内・外合わせると約300社のグループ企業があります。いまイオンスマートテクノロジーが価値を提供できているのは、そのうちのまだまだ限定された領域です。今後は、イオンスマートテクノロジーがイオングループ全体のIT基盤をすべて担えるようにしたいですし、さらに言えばテクノロジーで価値を創出する状態にしていきたいです。

イオンは多種多様な業態の事業を運営しており、人々の生活に密接している会社のひとつです。それだけに、テクノロジーを通じてイオングループ全体を変えることで、人々の暮らしそのものを変えるポテンシャルがあると思っています。

――人々の暮らしそのものを変える。まさに、イオンだからこその仕事の醍醐味ですね。最後に伺いたいのですが、「what we use」で掲載するインタビューやコラムは「技術的・組織的な意思決定」をテーマにしています。エンジニアがこういった事例を学ぶことには、どのような意義があると思われますか？

私はいろいろな事例をよく探して読むんですね。これは、勉強しようと思っているわけではなく、純粋に知的好奇心が旺盛なので、楽しんでいるだけなんです。ただ、特定企業のとても良い事例があったとしても、私はそれをまねることはしません。

その企業の戦略は、業種や事業規模なども違う環境下で、ステークホルダーや巡り合わせとか、いろいろな要素が組み合わさって初めてうまくいくわけじゃないですか。人の成功談を表面的にまねて物事を推進しようとしても、おおよそうまくいきません。だから読者の方々には「なるべく多くの事例を学ぶほうがいいです。でも、自社の戦略を考えるのは、あくまであなた自身ですよ」と伝えたいですかね。

取材・執筆：中薗昴

撮影：山辺恵美子

提供：株式会社Haul

「Snowflake」の記事一覧