iAEONのアプリ開発チームが取り組む内製化とLeSSのプラティクス導入

iAEONのアプリ開発チームが取り組む内製化とLeSSのプラティクス導入

2024/7/25

Share

この記事に登場している人

翁長 聡史

Satoshi Ounaga

イオンスマートテクノロジー株式会社 iAEON開発ディビジョン iAEON開発ユニット iAEON開発チーム スクラムマスター
新卒で入社の銀行系システム子会社では、ホスト系システム開発を経験後、銀行グループ内会社におけるアジャイル開発推進などを担当。
2022年9月にイオンスマートテクノロジー入社後、ゼロからのアジャイル開発(スクラム)導入・推進をスクラムマスター/アジャイルコーチとして絶賛取り組み中。スクラムがもたらす価値を信じてスクラムに挑み続けている。お気に入り店舗はイオンレイクタウン。
Scrum Alliance 認定スクラムプロフェッショナル-スクラムマスター(CSP-SM)、認定スクラムプロダクトオーナー(CSPO)

    堀内 亮佐

    Ryosuke Horiuchi

    イオンスマートテクノロジー株式会社 iAEON開発ディビジョン iAEON開発ユニット iAEON開発チーム エンジニア
    ex-株式会社リクルート
    大学卒業後2005年からWeb制作業に従事。10年ほど受託開発を経験した後2016年に入社したイオンドットコム株式会社から自社サービス開発に携わる。内製開発組織立ち上げ間もない2022年10月にイオンスマートテクノロジーに入社。これまでのフロントエンドエンジニアとしての経験を活かしUIの実装に軸足を置きつつ、業務改善のための技術的負債解消や開発組織の規模拡大にともなうチームビルディングにも取り組んでいる。

    この記事を読むとわかること

    ・内製チームで小さな成功体験を積み重ねるために取り組んだ案件とは
    ・開発チーム編成における工夫は各チームのスキル・ノウハウ・ドメイン知識の偏りを防ぐこと
    ・チームに起こったポジティブな変化5つとは?

    イオングループの公式アプリ「iAEON」の開発を担うイオンスマートテクノロジー(以下、AST)は、機動力とノウハウ蓄積の観点から2022年10月に内製化へと舵を切りました。しかし、パートナー企業(委託先)作成の複雑かつ膨大なソースコードを読み解いたり、内製開発態勢が整うまでの期間を要求したりと、その道のりは順風満帆ではありませんでした。今回は、立ち上げ当初からチームを率いるフロントエンドエンジニアの堀内亮佐と、内製化およびアジャイル開発の導入を主導したスクラムマスターの翁長聡史に、外部のパートナー企業(委託先)に開発を頼っていた状態から3つの内製スクラムチームができあがるまでの1年半を振り返っていただきました。

    【iAEONとは】
    ポイントの利用・付与のほか、電子マネーやコード決済での支払い、お気に入り店舗のクーポン利用やキャンペーン情報の確認ができるなど、日々の買いものを便利かつお得にしてくれるイオングループの公式アプリ。現在、約1000万のユーザーを抱える。

    【目次】

    スピーディな開発とノウハウ蓄積の必要性から内製化を決断

    ——そもそも、なぜ内製化を決断したのでしょうか。

    翁長iAEONはお客さまに便利かつお得にお買いものを楽しんでいただくためのアプリです。スピーディにサービスを改善し、ユーザー満足度を高めていくことが求められます。しかし、不確実性の高い環境のなかでパートナー企業(委託先)に依存した開発をしようとすると、優先順位の変更や機能追加に時間がかかってしまいます。また、ノウハウが社内に蓄積されないという課題もありました。

    限られたリソースのなかで、お客さまや企画・マーケティング推進部署などビジネス側からのフィードバックを得て、優先順位の見直しを行い、フットワークよく開発を進めていくには、社内で開発をリードしていく必要があると考えました。

    iAEONアプリ開発内製化元年の苦闘

    ——内製チームのスタートはどのような感じだったのでしょうか。

    翁長2022年10月、堀内を含め数名の社員による1チーム体制でキックオフしました。内製化によって機動力の高い開発体制を実現することを目指していましたが、専任のチームメンバーを当初は1名しか配置できなかったことや、メンバーがスクラムに関するスキル・ナレッジ習得が必要な状況であったことから、すぐに結果を出すのは難しい状況だったため、最初の一歩としてスモールスタートを心がけ、徐々に体制を整えていこうという方針でした。

    堀内立ち上げ当初は手探りでしたね。準備に多くの時間をかけました。2022年10月に入社してから実際に手を動かすまでの約2か月間、まずは既存アプリの仕様を理解することから始めました。パートナー企業(委託先)に開発を依頼していた背景もあり、ドキュメント不足のためブラックボックスな部分が多く存在する状態からのスタートでした。要件を見て、アプリのどこをどう改修すればよいかキャッチアップしたうえで、膨大なコードを読み解いたり、開発していた会社からスキルトランスファーを受けたり、社内の有識者を探して仕様について問い合わせたりと大変な作業でした。

    特に、ソースコードを読み解くのは本当に苦労しましたね。以前はエンジニアが不在の時期もあり仕様や設計の面で的確な管理ができておらず、何千行もあるようなプログラムが散見するといった状況。最終的には、シーケンス図を全画面に対してリバースエンジニアリングで作成していく作業をパートナー企業(委託先)とともに行いました。そこまでしなければ把握できないような規模感と複雑さを有した状態になっていたんです。

    翁長こうしたキャッチアップと並行して、内製開発における設計レビューの手法やコーディング規約など開発ルールの整備も進めていきました。

    既存アプリの仕様理解の過程で見えてきた課題

    ——既存アプリの仕様を理解するにあたって、さまざまな課題があったんですね。その後はどのように進められましたか。

    翁長電子マネーWAONカードのWAON POINTをiAEONに登録・合算する仕組みの実装を内製チームの第一号案件として設定し、まずは小さな成功体験を積むことを目指しました。

    5スプリントほどでできるだろうと見込んで堀内を中心に開発を進めていきましたが、嬉しい誤算として事業会社側の検討深掘りを起因とした要件変更・追加が入ったため、2023年2月リリースのフェーズ1と8月リリースのフェーズ2という形でフェーズ分けをすることになったのです。当初は成功体験を積むことを目的に、比較的単純な要件でスクラムを導入しようと考えていたので、スクラムに不慣れななかでのスコープ変更は、チームにとって大きな試練でしたが、要件・要求の変化に対して柔軟に対応するという、アジャイル開発ならではの貴重な体験をすることができました。

    堀内試練といえば、アプリ開発の知見を社内に吸収していかなければならないのと同時に、iAEONの会員数が増えていくなかで、「イオンお客さま感謝デー」となる毎月20・30日などにアクセスが集中しシステムに負荷がかかり、障害が発生することも何度かありました。当時は内製開発をスタートさせて間もないために原因特定に時間を要しておりました。現在では大分スピーディに対応できるようになってきていますが、パートナー会社(委託先)で構築した機能で障害が発生した際には、今でもたまに悩むことがあります。

    ——現在進行形で課題に向き合われているんですね。チームづくりという観点ではいかがですか。

    堀内現在は、パートナー企業(内製)のメンバーの占める割合が大きく、メンバーのバックグラウンドやチームに参画している動機も異なるなかで、どのようにチームビルディングを進めていくか、やりがいを持ってスプリントを回してもらえる状態をいかにつくっていくかというところは現在でも苦戦しています。

    翁長社内の調整も進めつつ、メンバーと密にコミュニケーションを取り、やりたいこととやっていることに齟齬がないか確認しながらモチベーションを維持していくことが大切だと感じています。

    堀内iAEONで採用している技術スタックに付随した課題もあります。ハイブリッド型のアプリ開発を行うためにIonic Frameworkを利用しているのですが、IonicではWebフロントエンドとネイティブアプリの両方のスキルが必要になります。これが足かせになってしまい、エンジニアの採用に苦戦しているという面もあります。リファクタリングやリプレイスも視野に入れつつ、エンジニアにとって魅力的な環境づくりを進めていかなければと感じています。

    例えば、地方在住者の入社も可能になりエンジニアにとって働きやすい制度を整えていたり、技術選定では内製エンジニア自身が主導し、自由度を持った選択ができる環境を目指しています。また、クロスファンクショナルなチームおよびメンバーを目指すために新しい技術領域へのチャレンジを応援する文化が醸成されています。

    3つのスクラムチームにまで成長したiAEONアプリ開発の今

    ——現在のiAEON開発チームの体制について教えてください。

    翁長iAEONの開発チームは当初、1つのスクラムチームでスタートしましたが、内製チームで対応する領域が拡大するにつれ、チームの拡張が必要になってきました。そこで、チームをスケーラブルに成長させていくために、LeSS(Large-Scale Scrum)のプラクティスを導入することにしました。現在は3つのスクラムチームが稼働しています。2023年9月にチーム1とチーム2の2つのチームに分割。さらにチーム1のメンバーを8名にまで増やして、これを2つに分けた形です。

    ASTの社員とパートナー企業(内製)の業務委託メンバーで構成されていますが、まだまだ社員の割合が低いのが課題ですね。また、現在も一部開発を外部のパートナー企業(委託先)に依頼している領域があり、その部分のPM業務はプロダクトオーナーチームが対応しています。24年度内に4チーム体制を実現、100%内製開発を目指しつつ、体制面でも社員比率を高めていきたいと考えています。

    ——チーム編成において、工夫されている点はありますか。

    翁長特定の機能に特化させたチームをつくるのではなく、どのチームでも同じような開発ができるようにしています。もちろん担当する案件によって一時的にチームの得意領域が生まれることもありますが、担当する機能のローテーションをしながらスキルやノウハウ、ドメイン知識の偏りを防ぐようにしています。

    堀内フロントエンドエンジニアとしては、HTML、CSS、JavaScriptだけでなくネイティブアプリやサーバーサイドの知識も必要となり、実際にはチームごとにどうしてもスキルのばらつきがありますが、各チームの有識者が横断的に適宜サポートしています。

    翁長短期的な目線で考えると知識やスキルを持つ人が担当するほうが楽ですが、そこはあえて中長期的な視点を持って、誰もができるように育てていくという考え方を大切にしています。

    iAEON開発チームに起こった5つのポジティブな変化とは?

    ——内製化によって、具体的にどのような変化が生まれているのでしょうか。

    翁長大きく分けて以下の5つがあげられると思います。

    1. アプリ開発が「自分ごと化」
    2. ビジネスとの距離感が近くなった
    3. ユーザー満足度が向上
    4. 「自己組織化」が進んだ
    5. パフォーマンス改善に向けた取り組みを行えるように

    それぞれ詳しく説明していきます。

    1. アプリ開発が「自分ごと化」

    堀内自分たちでコントロールしながらアプリを育てていけるのは、とてもやりがいがあります。お客さまからのフィードバックを得ながら、次の改善にどうつなげていくかチームで話し合いながら進めていくことで、自分ごと化できている実感がありますね。

    2. ビジネスとの距離感が近くなった

    翁長ビジネス側との距離が近くなったのも変化の1つです。スプリントレビューや計画にエンジニアも参加して、ビジネス側の生の声を聞いたり、デモを行ってフィードバックを受けたりといったところを積極的にやってくれています。

    それに対してビジネス側のプロダクトオーナーも理解を示しており、言われたことをただやるのではなく、職種の垣根を超えて課題解決に向けた建設的な議論ができるようになったように思います。ビジネス側の意見によってリリース前に手戻りが生じてしまうことも減りました。私としては「ついにここまでたどり着いたか」という感覚です。

    3. ユーザー満足度が向上

    翁長実際にアプリのレビューを見ても、★4や★5の高評価が増えてきています。ユーザー満足度の向上は嬉しい変化ですね。特に印象深かったのは、初めて内製チームで実装した機能について「ようやく、電子マネーWAONカードがiAEONに登録できるようになった」というコメントです。それまでは、「電子マネーWAONカードがiAEONに登録できない」という低評価コメントが多かったため、当時は大変嬉しかったことを覚えています。

    4. 「自己組織化」が進んだ

    翁長アジャイル開発の観点からいえば、「自己組織化」に向けて着実に進展している途中にあるといえます。もともとスクラムマスターの立場からあれこれ指示をすることは絶対にしないのですが、経験が浅いメンバーに対しては「こういうことも意識してね」と伝える機会があります。ただ、最近はそれが劇的に減っているように思います。

    たとえば、以前は業務要件への対応で計画が埋まってしまうことが多かったのですが、それがいったん落ち着くタイミングで「溜まっている改善系の作業に取り組めるチャンスがきた」という話をしたところ、すでに堀内さんが動いてくださっていたんです。皆前向きに自分ごととして取り組んでいる実感がありますね。

    5. パフォーマンス改善に向けた取り組みを行えるように

    堀内チームのパフォーマンスを上げるための日々の改善にも積極的に取り組んでいます。ビルド時間の短縮やTypeScript環境の整備など、地味な作業の積み重ねではありますが、目に見える成果につながるので、おもしろいです。リリースごとに対応する要件やバグの数は確実に増えています。

    バグの検出数自体は横ばいかもしれません。でも、それはきちんとテストをするようになった証拠でもあります。過去には気が付かなかったバグを見つけられ、その数は横ばいなのです。品質を意識した開発プロセスが根付いてきたのだと思います。

    目指すは自律的・自発的な開発組織

    ——今後、iAEONアプリ開発チームはどのような方向を目指しているのでしょうか。

    翁長今は、プロダクトオーナーと開発チームのあいだにプロダクトオーナープロキシ(代理)という役割の方が入ってプロダクトオーナーからの要件や要求を受けて前さばきをしていますが、将来的にはプロダクトオーナーと開発チームが直接フラットにコミュニケーションを取りながら自発的・自律的に優先順位付けをして、よりスピード感のある開発につなげていけるのが理想だと思っています。

    堀内今はまだ要件駆動で業務を行うケースが多いのですが、内製チームの練度が上がり、コードの理解も進んでいけば、エンジニア主導でグロースハック的にアプリの改善に取り組める可能性もあると思っています。お客さまやビジネス側の声に真摯に耳を傾けながら、エンジニアの観点からもサービス価値を高めていけるようなチームづくりを目指していきます。

    ——そうした自律的・自発的な開発チームを目指していくためには、どのようなエンジニアの方が向いているとお考えですか。

    翁長アスファルトで整備された道路を走るのではなく、ガタガタ道でも前向きに突き進んでいけるタイプの方にとって、iAEONアプリ開発チームはやりがいの多い環境だと思います。ただ、自分のやりたいことだけをやるという考え方は少し違います。ビジネス側とのコラボレーションを図りつつ、エンジニアリングの視点からアイデアを提案できるとよいですね。プロダクトをグロースさせながら、自分自身も成長する。仲間とともに、新しい価値を生み出していく。そんなエンジニアライフを、iAEONアプリの内製開発チームなら実現できるはずです。

    堀内単に言われたタスクをこなすだけでなく、課題を主体的に見つけ、解決策を提案できる課題解決型のマインドセットを持ったエンジニアの方であれば、大いに活躍できるのではないでしょうか。

    実は、かつて私はASTの前身であるイオンドットコムに在籍していた経験があります。イオンドットコムに入社した時も、デジタルシフトを目指して会社が立ち上がった直後のタイミングでした。新しいことに取り組める期待感を持って飛び込みましたが、立ち上げ初期のタイミングだということもあり理想と現実のギャップは大きく、やりたいことができないまま1年半で退職を決意することになりました。

    その後、別の事業会社で5年間経験を積み、そのときどうすればよかったのかという知見を得ました。ASTはまだ設立して間もない会社で、当時のイオンドットコムと同じような課題を抱えています。前回はやり切れなかった想いがあったので、今回は似たような状況のASTで素晴らしい開発チームをつくり、内製化にチャレンジする。そうした自分自身へのリベンジのつもりで取り組んでいます。もしこれからやりきりたいという気持ちをお持ちの方がいれば、ぜひ一緒に取り組んでほしいですね。


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

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

    ※掲載している所属・役職・肩書きおよび各種情報は、記事公開時点のものです。

    Share

    JOIN US

    AEONで働きたい人は、採用サイトもチェック

    カジュアル
    面談

    に申し込む