【内製開発Summit 2025】2年間で内製化率0%→95%を達成したイオンスマートテクノロジーの内製化組織の作り方

内製開発組織立ち上げの背景と初期の課題

翁長　イオンスマートテクノロジー株式会社（以下、AST）は2020年10月に設立された比較的若い会社で、「イオングループの全てのビジネスをテクノロジーの力で進化させる」というミッションを掲げています。主なプロダクトとしては、本日お話しするスーパーアプリ iAEONをはじめ、超大規模データ基盤や4000万人超の顧客基盤、さらには従業員体験のDXなど、幅広い領域を手がけています。

iAEONは「暮らしにつながるイオンのトータルアプリ」として、これまで物理カードで貯めていたWAONポイントをアプリで貯められる機能や、バーコード決済のイオンペイ、電子マネーのモバイルWAON、お得に使えるクーポン、店舗情報など、イオンに関わるさまざまなサービスを一つにまとめたアプリです。



堀内　このiAEONアプリは、2021年9月に外部開発によってリリースされました。その約1年後の2022年11月から、内製開発組織をスタートしました。

私たちが内製化に踏み切った理由は大きく2つあります。1つ目は、多数の不確実性の高い要件に対して、優先順位や内容を柔軟に見直しながら、価値のある要件から実現していきたいという思いでした。2つ目は、お客様や事業会社からiAEONに関するフィードバックをタイムリーに取り込みたいということです。これらを実現するプロセスとして、アジャイル開発手法の1つであるスクラムを採用することにしました。

しかし、内製開発をスタートした時点で直面した現実は厳しいものでした。まず、ドキュメントがなにもない。画面項目定義書もなく、かろうじてAPI仕様書があるだけという状況だったのです。さらにテストコードも整備されておらず、コードのコメントもほとんど入っていない、まさにないないづくしからのスタートでした。

仕様を理解するためには、とにかくコードを読むしかありませんでした。しかし、そのコードの品質が読み手を拒むような状態。深いネストの繰り返し、何重ものifの入れ子、1ファイル16,000行を超えるコード、400を超える循環的複雑度......。

なぜこのような状況になったのか。根本的な原因は、初期開発時に内製化までを見据えた中長期的な戦略がなかったことにあります。初期開発ではQCD（品質・コスト・納期）のうち、納期を守ることが至上命題とされ、コードの品質は置き去りにされていました。

また、開発体制においても問題がありました。社内には進行を管理する人間と要件を出す企画のメンバーだけで、開発やデザインは請負契約で外部に発注していたのです。社内にエンジニアがいないことで、どのような技術を使って、どのように作るかという部分で、社内の意思を反映させることができませんでした。

失敗から学ぶ内製開発の理想的な始め方

堀内　私たちは内製開発の第一号案件を通じて、理想的な内製開発の始め方について多くの学びを得ました。その経験から見えてきたいくつかの重要なポイントをご紹介します。

最も重要な教訓は、テックリードの存在は不可欠ということです。開発を外部発注するにしても、内製で行うにしても、開発開始時からテックリードが必要だと強く感じました。テックリードが担うべき責務は大きく4つあると考えています。

まず1つ目は技術選定です。尖った最新技術を採用するのか、あるいは枯れた安定技術を選ぶのか。この選択は、その後のプロダクトや組織のスケール化に大きく関わってきます。例えば、市場からエンジニアを採用しようとしたときに、あまりにニッチすぎる技術だと「そもそもその技術をやっている人がいない」という状況に陥り、組織のスケール化が難しくなります。そのため、技術選定は社内でしっかりとコントロールしたいポイントです。

2つ目は品質定義です。後から決めた品質定義を既存のコードに遡って適用するのは非常に難しいものです。そのため、最初からメンテナビリティを落とさない仕組みを構築することが重要です。コーディングルールの定義だけでなく、フォーマッターやlint設定など、コードの品質を定義する仕組みを整え、開発時に作成するドキュメントの定義も明確にしておくべきでした。

3つ目は発注先選定です。先に述べた技術選定と品質定義を満たせる発注先を探すことも、テックリードの重要な役割です。また、外部発注せずに内製で開発する場合は、適切なエンジニアの採用にも責任を持つ立場となります。

4つ目は受け入れです。完成したアプリで受け入れテストをするのではなく、開発段階からコードレビューを実施し、ソースコードの品質を保つことも重要な役割となります。必要に応じてプルリクエスト上でこまめにレビューとフィードバックを行うことが大切です。



これらの教訓から、内製開発を始める前にはテックリードの存在が不可欠だということを、これから内製開発に挑む会社の方々にはぜひお伝えしたいポイントです。

私たちはすでに内製開発をスタートしていましたので、初期開発時にテックリードが不在だった状況を何とか改善する必要がありました。特に、開発組織のスケール化を考えたとき、地獄のコードリーディングを経ないと開発に参加できないような状況は何としても避けたかったのです。

そこで取ったのが、後からドキュメントを作成し、テスト環境を構築するというアプローチです。本来は最初からあるべき画面項目定義書やシーケンス図といったドキュメントを、リバースエンジニアリングで作成しました。かなりのパワープレイでしたが、後に続く人のためにドキュメントを整備しました。

成果を最大化するためのAST流チームビルディング

私たちが考える内製開発とは、アウトカムを最大化するためにビジネス状況に応じて柔軟に開発の優先順位をコントロールしたり、開発で得た経験の蓄積によりリリース速度や品質を改善し続ける能力を社内に持つことです。

スクラムでを採用することによりスプリント毎に開発計画を見直せたり、スプリントを重ねるごとにチームの経験値が蓄積されていきます。しかし、外部委託では、こうした優先度調整が難しかったり、知見や成長が社内に残りません。社内でコントロールできないその部分を、社内でしっかり管理しようというのがASTの考える内製開発の本質です。

内製開発の目的は前述の通りなので、100%社員だけで開発を行うことが内製開発ではありません。目的達成の手段として私たちは、プロパー（社員）とパートナーの混成チームで内製開発を進めるというスタンスを取っています。

そこで重要になるのが、どのようにして優秀なパートナーに参画してもらうかという点です。ASTの開発チームでは、リモートワークを基本とした働き方を採用しています。これは、首都圏以外にお住まいの方にも参画いただけたり、小さなお子さんがいる方も安心して働いたりできる環境を整えるためです。こうした柔軟な働き方を提供することで、地理的な制約に縛られず、優秀な人材に参画してもらえる環境を作っています。

プロパーとパートナーの混成チームのパフォーマンスを向上させるためには、心理的安全性の構築が不可欠だと考えています。メンバー間の相互理解を促進するために、ドラッカー風エクササイズという自己開示の取り組みを実施し、相互理解を促進しました。



また、基本的にはオンラインでの開発が中心ですが、オフラインでのコミュニケーションも大切にしています。2024年末には、チームビルディングイベントを開催し、全員でホワイトボードを囲んでVSM（Value Stream Mapping）を書き出すなどの活動を行いました。

アジャイル開発（スクラム）の導入

翁長　私たちの内製開発の軌跡は、アジャイル開発、特にスクラムの導入と深く結びついています。この旅を「黎明期」「成長期」「拡大期」という3つのフェーズに分けてお話しします。

黎明期：スクラム導入〜スモールスタート

2022年10月から2023年8月までの黎明期は、スモールスタートによる成功体験の積み上げに注力しました。スタート時点では、社内にはJIRAがあるくらいで、アジャイル開発に関するものはほとんど存在しなかったのです。まさにゼロからのスタートでした。

私は最初の半年間でやることを決め、当時の副社長に以下のような内容を伝えました。

1.大まかにやることをロードマップ化
2.半年後のイメージを伝える
3.何かあったら相談させていただく



次に、開発チームの全メンバーを対象に8～10時間程度の初期トレーニングを実施しました。アジャイル宣言から始め、スクラムの活動をひと通りイメージできるようにしたのです。

スクラムイベントもひと通り実施しました。ただ「やる」だけでなく、 なぜそのイベントが必要なのか、目的を持って行うことを心がけました。最初は私が「やってみせる」ことから始め、徐々に「やってもらう」方向へシフトしていきました。特に初期段階ではイベントが中途半端になりがちなので、プレイベントやポストイベントを設けて、必要な活動がしっかりと行われるよう工夫しました。

例えば、PBR（プロダクトバックログリファインメント）。これはスクラムフレームワークにおいて必須のイベントではありませんが、私たちはこれを重要なイベントと位置づけ、しっかりと実施しています。さらに効果を高めるために、PBRの前にプレイベントを設けました。エンジニア同士が事前に話し合う場を「下見の下見」と称して開催し、本番のPBRがスムーズに進行できるように。また、PBRの活動自体もプロダクトバックログアイテムとして起票することで見える化を図り、初期段階から体系的に取り組みました。



PO（プロダクトオーナー）の設定にも工夫が必要でした。iAEONはイオングループの多くの事業会社がステークホルダーとなるため、1人のPOを配置することが極めて困難でした。そこで、アプリ新機能の企画担当、CSの担当、運営・プロモーション担当などで構成されるPOチームを組成しました。さらに開発側のロールとして、プロダクトオーナー代理（PO-Px）を設け、ビジネスPOへのアジャイル開発に関するスキル補完や、業務とシステムを橋渡しする役割を担わせました。

スモールスタートとして最初に取り組んだのは、電子マネーWAONのiAEONアプリへの登録機能でした。すでに開発済みの類似機能があったため、それを参考にすることで成功体験を得ることが目的でした。しかし予想外にも、登録チェック機能の追加や既存機能への展開要望など、追加要望が次々と出てくる「よくある現象」が発生し、結果的にフェーズ分けが必要なほどの規模に拡大しました。それでも初めての案件でアジャイル開発の特徴である柔軟な対応を実際に体験できたことは非常に有意義でした。開発自体は大変でしたが、要件はきちんとリリースでき、お客様からの評価も良好でした。



黎明期の主な課題は、開発メンバーの人数が増えないことでした。内製開発専任で入社したメンバーが別の業務に配置されていたのです。この状況を当時の副社長に報告し、スクラム導入が進まない現状と、しっかり進めていくべきという考えを進言しました。その結果、メンバーが戻り、開発チームが5人体制となり、スクラムチームとして適正な規模になりました。

黎明期を振り返ると、最初が肝心だと強く実感しています。当初からいつまでにどのような取り組みを進めるかを明確にしたことで、経営陣にも取り組みを気にかけていただけましたし、相談したときには迅速に対応していただきました。また、スクラムの各要素をひと通り採用したことで、活動が首尾一貫し、スクラムがもたらす成果を実感することができました。

ゼロから始める際に考慮すべき点として初期段階では妥協せずに活動を続けることが重要だと感じました。継続することで徐々にリズムが生まれてきます。またスクラムフレームワークの不完全な部分を初期段階でどう補完するかもポイントです。スクラムのフレームワークはあえて不完全にされているものの、そのままにしておくと中途半端になりがちです。ただし、補完の方法に唯一の正解はなく、経験則に基づいた判断も必要です。

最後に実感したのは、準備段階からスプリントを回し始めたほうが良かったということです。まとまった準備期間を設けるだけではなく、準備期間も2週間スプリントとして準備活動の計画・実行・振り返りまでできていれば、より効果的だったと思います。

成長期：2チーム化とLeSS導入

2023年9月から12月の成長期は、CTOのリクエストからの2チーム化を実現しました。パートナー会社のメンバーにも参画いただき、4～5人の2チームを組成。プロパーは均等に分配し、スクラムマスターは私が2チームを兼任しました。



2チーム化に伴い、LeSS（Large-Scale Scrum）を採用。分割後4スプリントで分割前の2倍のベロシティを達成しました。分割によるロスも最小限に抑えられました。

成長期を振り返ると、スケール化にあたって考慮すべき重要な点がいくつか見えてきました。まず、プロパー比率が50%以上を維持できたことは非常に有効でした。これにより、新たに参加したメンバーに対しても組織の文化や特色、スキルなどを効果的に共有することができました。次にパートナーの方々が自走できる体制を整えられたことも大きな成果です。

また、PO-Pxの役割をもつメンバーを増員したことでより多くの要件に対応できるようになりました。これもスケール化において重要な考慮点だったと実感しています。

反省点としては、PBRに関して、LeSSでは3種類の形式があり複雑だったため、理想的な形に落ち着くまでに時間を要したことです。このプロセスはLeSS導入時点でフレームワークに沿って開始すべきだったと考えています。

拡大期：統合バックログの仕組み化と3チームへのスケール化

2024年1月からの拡大期には、「統合バックログ」の仕組み化に取り組みました。この仕組みを導入した背景には、黎明期から存在していた課題があります。当時、複数のPOやステークホルダーから開発チームに直接要件が持ち込まれていました。「私の要件が最優先」という主張が錯綜し、最悪の場合は「やることと期限を決めてきたから、よろしく」という一方的な依頼もありました。

そこで導入したのが、プロダクトの要件を一元的に受け入れて管理する仕組みです。しかし、要件が多岐にわたるため、統一的な優先順位付けは難しいという問題がありました。そこで再び経営陣に相談。POに代わってはじめは副社長が優先順位付けを担当し、最終的にはCTOやCOOを含めた3名で優先順位付けと着手判断を行う運用が始まりました（現在はPOが担当しています）。

構想から運用開始まで1年以上を要しましたが、週次で統合バックログの確認を行う場が設けられたことで鮮度の高い優先順位の見直しや新たな要望の取り込みが可能になりました。

内製化を進めるためには、チーム拡大が必要不可欠と考え 3チーム体制の実現に取り組みました。3チーム体制では1人のスクラムマスターでは対応が難しくなるため スクラムマスターの増員も実施しています。

また、単に組織を拡大するだけでなく パートナー会社からのスキルトランスファーも進めました。ただし、このスキトラは一旦完了したものの、新たな委託の発生により継続中の状態が続いています。

内製化をより効率的に進めるため、内製スクラムQAの取り組みとして MagicPodの導入やアジャイル・スクラムに適合した テストプロセスの標準化にも力を入れています。



2022年度第3四半期に0%だった内製開発比率は、2024年第1四半期までに 50%まで引き上げることができました。その後は大きな方針転換として 開発採択判断自体を内製開発のキャパシティ範囲内に限定する決断をし、現在では95%の内製化率を達成しています。ただし、絶対に実施しなければならない要件は当然発生するため、そのリスクを回避する観点から、最低限の委託開発は継続しています。

一方で、内製化シフトとスケールにはいくつかの課題が残されています。先ほど言及しましたが、スキルトランスファー完了後に新たな委託開発を行わざるを得なかったことが、結果的に内製化比率の低下を招いてしまいました。また、プロパー比率が増加しないことにより、意図せずピラミッド型の組織構造が形成されてしまっているという問題も存在しています。

内製開発チームの現在地とこれから

堀内/翁長　これまでの取り組みの成果は、具体的な数字にも表れています。重大障害発生比率が2023年度と比較して約1/4程度に減少し、アプリストアの評価も2023年の2.0未満から現時点では4.0以上へと大幅に向上しました。

内製開発チームは現在、2週間に1回のスプリントを2つ回して、月1回のリリースサイクルで開発を進めています。リソースを最大限活用し、リリース日にまとめて価値を届けるリソース効率重視の開発を行っていますが、課題も見えてきました。

スプリント後半のテスト期間で開発時間が制限され、テスト開始が遅いためバグ対応が追いつかないケースがあります。月1リリースに合わせて案件が集中するため、テスト中のバグが後半に急増し、対応しきれないという問題も発生しています。

今後は、リソース効率からフロー効率への転換を目指し、優先順位の高い案件を小さく早くリリースして価値を早く届ける方針に変えていきたいと考えています。この課題を解決するため、アプリのリアーキテクチャにも取り組み始めました。

また「やめたいこと」と「やりたいこと」を明確にし、一時しのぎの委託開発をやめ、プロパー比率の向上を進めていきます。成熟期では「守破離」の「破」を実現し、チームが型を自分たちの状況に合わせて進化させる段階へと移行したいです。

組織面では4チーム化の準備を進め、スクラムマスター主導からDev主導のチーム活動へシフトし、自己組織化を促進していきます。なお、ASTでは共に挑戦する仲間を募集しています。ぜひご応募ください。

アーカイブ動画はこちら

https://findy-tools.io/events/2e84e82bf936b31a931f