【内製開発Summit 2025】イオンスマートテクノロジーの内製化組織の作り方/In-house-development-summit-AST

イオンスマートテクノロジーは、絶えず変化する市場や顧客ニーズに応えるために2022年から本格的にデュアルトラックアジャイルによる開発を目指し、内製化に取り組んできました。今回は、組織立ち上げ・組織のスケール化・内製化率95%を達成した「道のり」を紹介します。スクラムガイドをベースにして立ち上げ時から再現性の高いアジャイル開発組織を組成すること・エンジニア採用が難しい中でパートナーとの協働で組織をスケールさせる方法・新旧メンバー混成チームでの価値・パフォーマンスの最大化の3点を詳しくお話します。

1. 内製開発Summit 2025 2025.2.27 2年間で内製化率0%→95%を達成した イオンスマートテクノロジーの 内製化組織の作り方 翁長 聡史 堀内 亮佐
2. 会社紹介
3. 会社紹介
4. ミッション・・・
5. 主なプロダクト
6. 本日お話しするプロダクトの紹介
7. 本日お話しするプロダクトの紹介
8. 本日お話しするプロダクトの紹介
9. 本日お話しするプロダクトの紹介
10. エンジニアパート
11. 内製開発ことはじめ 目次 失敗から学ぶ 理想の内製開発の 始め方 AST流内製 チームビルディング 内製開発チームの 現在地とこれから 1 2 3 4
12. 堀内亮佐（42） 自己紹介 ＜職歴＞ 2008年：株式会社ミツエーリンクス 2010年：株式会社博報堂アイ・スタジオ 2016年：イオンドットコム株式会社 2017年：株式会社リクルート 2022年：イオンスマートテクノロジー株式会社(AST) ＜職種＞ フロントエンドエンジニア
13. 1.内製開発ことはじめ
14. 2020年10月：AST誕生 2021年9月：iAEONリリース(外部開発) 2022年10月：堀内入社 2022年11月：内製開発組織スタート AST誕生から内製開発開始まで 1.内製開発ことはじめ iAEONリリースから1年経過後の 内製開発スタート 思っていたより大変だった・・・
15. • 詳細設計書が無い • 画面項目定義書も無い • 外部開発だから社内に有識者い るはず無い • テストも無い • コードのコメント全く入ってな い • かろうじてAPI仕様書はある ないないづくし 1.内製開発ことはじめ
16. • 仕様を理解するためにとにかく コードを読む • しかし読み手を拒む数千行の コード • 連発されるマジックナンバー • typescriptだけど全てはany何も わからない型 • ionicもangularもニッチ故情報 不足 コードリーディングの日々 1.内製開発ことはじめ
17. コードリーディングここがつらかった 1.内製開発ことはじめ つらみ ・何重ものifの入れ子 ・深すぎるネスト ・多すぎる行数
18. そもそも初期開発時に内製化ま でを見据えた中長期的な戦略が 無かったから。 初期開発時はQCDのD（納期） を守ることが至上命題。 Quality（品質）はおきざりに。 どうしてこうなった？ 1.内製開発ことはじめ
19. • 何を使って(技術選定)、どう作 るか(品質定義) • 今後の内製エンジニアの採用に も関わってくる技術選定を社内 で行えなかった • 初期開発のQCDのQuality（品 質）にコード品質を含めること ができなかった エンジニアの不在によって失わ れたもの 1.内製開発ことはじめ PM 企画 開発 デザイン AST 会社A 会社B 開発 請 負 契 約
20. 2.失敗から学ぶ理想の内製開発の始め方
21. なんとか内製開発1号案件をリリース 2.失敗から学ぶ理想の内製開発の始め方
22. コードリーディングから始まり、 改修範囲と影響範囲の把握は手 探りで進め、バグをモグラたた きで潰し、なんとかリリースに こぎつけることができた・・・。 どうすればこのような事態にな らなかったのだろうか？ 内製開発第1号案件を終えて 2.失敗から学ぶ理想の内製開発の始め方
23. • 技術選定 • 品質定義 • 発注先選定 • 受け入れ 開発を外部発注するしないに関 わらず開発開始時にテックリー ドの存在は不可欠 テックリードは不可欠 2.失敗から学ぶ理想の内製開発の始め方
24. とがった技術でいくの？枯れた 技術でいくの？ 選んだ技術によって採用難易度 が変わることも。 プロダクトや組織のスケール化 に大きく関わるため社内でコン トロールしたい。 技術選定 2.失敗から学ぶ理想の内製開発の始め方 • 技術選定 • 品質定義 • 発注先選定 • 受け入れ
25. コーディングルールの定義だけ でなくフォーマッターやlint設定 など。コードの品質を定義する。 テンプレートの実装までしてか ら渡すのがよいかも。 開発時に作成するドキュメント の定義なども。 メンテナビリティを落とさない 仕組みを最初から構築する。 品質定義 2.失敗から学ぶ理想の内製開発の始め方 • 技術選定 • 品質定義 • 発注先選定 • 受け入れ
26. 選定した技術で定義した品質を 満たしてくれる発注先を選定す る。 外部発注せず内製で開発する場 合はエンジニア採用に責任を持 つ。 発注先選定 2.失敗から学ぶ理想の内製開発の始め方 • 技術選定 • 品質定義 • 発注先選定 • 受け入れ
27. 要件だけではなくコード品質も 含めた受け入れを行う。 こまめにPull Request上でレ ビューを行い必要に応じて フィードバックを行う。 受け入れ 2.失敗から学ぶ理想の内製開発の始め方 • 技術選定 • 品質定義 • 発注先選定 • 受け入れ
28. • 技術選定 • 品質定義 • 発注先選定 • 受け入れ 改めて、テックリードの存在は 不可欠！！ テックリードは不可欠 2.失敗から学ぶ理想の内製開発の始め方
29. 初期開発時にテックリードが不 在だったことはもうどうしよう もない。 今後開発組織のスケール化を考 えた際、地獄のコードリーディ ングを経ないと開発に参加でき ない状況ではいけない。 ではどうリカバリーしたか？ 内製開発第1号案件を終えたその後 2.失敗から学ぶ理想の内製開発の始め方
30. 後からドキュメントを作成しテスト環境を構築 2.失敗から学ぶ理想の内製開発の始め方 画面項目定義書 シーケンス図 MagicPodによる 自動テスト環境
31. まとめ 2.失敗から学ぶ理想の内製開発の始め方 後追いでも必要な ドキュメントや環境は作る 初期開発は テックリード必須
32. 3.AST流チームビルディング
33. そもそも内製開発チームとは？ 3.AST流内製チームビルディング コントロールが 難しい
34. そもそも内製開発チームとは？ 3.AST流内製チームビルディング コントロール できる
35. 地方からでも参画いただけたり、 時間の融通が効きやすいメリッ トを活かすために内製開発チー ムは原則リモートワークとして いる。 チームのパフォーマンスを上げ るには心理的安全性の構築が不 可欠。 パートナー採用どうしているか？ 3.AST流内製チームビルディング
36. 相互理解を促進する 3.AST流内製チームビルディング ASTが考える内製とは ドラッカー風エクササイズで互いの価値観を知る
37. 対面でのコミュニケーションはもちろん大事 3.AST流内製チームビルディング ASTが考える内製とは 24年末にチームビルディングイベントを実施
38. 4.内製開発チームの現在地とこれから
39. 2022年11月から始まったな異性 開発体制は順調に拡大中。 外部で開発したアプリのドキュ メントを整備し、仕様を理解し、 品質を担保できるようになり、 安定的にアウトプットが出せる ようになった。 内製開発チームの現在地 4.内製開発チームの現在地とこれから
40. アウトプットではなくアウトカムを最大化したい 4.内製開発チームの現在地とこれから ASTが考える内製とは 月1のリリー スサイクルで アウトプット を最大化する、 リソース効率 に倒しきった 開発を行って いる。
41. アウトプットではなくアウトカムを最大化したい 4.内製開発チームの現在地とこれから ASTが考える内製とは しかしスプリン ト内での開発未 完了により消費 時間に対して提 供できる価値が 少ない状況。最 大化にはまだ改 善が必要な状況。
42. アウトプットではなくアウトカムを最大化したい 4.内製開発チームの現在地とこれから ASTが考える内製とは 全案件のマージ タイミングが遅 くテスト開始が 遅くなることで リリースまでに 不具合が潰しき れずリリースを 見送る案件が生 まれてくる。
43. アウトプットではなくアウトカムを最大化したい 4.内製開発チームの現在地とこれから ASTが考える内製とは ビジネス上の優 先順位が高い案 件を小さく、早 くリリースする ことでアウトカ ムを早期に得る スタイルに変え ていきたい。
44. アウトプットではなくアウトカムを最大化したい 4.内製開発チームの現在地とこれから ASTが考える内製とは 先行案件の学びの上に後続案件を開発、リリースする ことで価値＝アウトカムを最大化したいから。 アウトプットから アウトカムへ
45. リアーキへの挑戦 4.内製開発チームの現在地とこれから ASTが考える内製とは アウトカム最大化のためにフロー効率で価値を届け るには月1リリースのシステムやプロセスの制約がボ トルネックになっている状況。 この課題への打ち手としてアプリのリアーキを決断。
46. ASTではプロダクトの進化と開 発組織の進化を両輪で推進して います！！ ASTプロダクトと開発組織の進化 にぜひご期待ください！ 4.内製開発チームの現在地とこれから
47. 堀内からの発表終わります！ ありがとうございました！ この後は翁長さんからスクラムの 取り組みについてお話します。
48. アジャイル開発(Scrum)パート
49. 自己紹介
50. 自己紹介 翁長 聡史（オウナガ サトシ） 新卒入社の銀行系システム子会社で、 ホスト系システム開発を経験後、銀行・ グループ会社におけるアジャイル開発推進を担当 2022年9月にイオンスマートテクノロジー入社後、 ゼロからのアジャイル開発（スクラム）導入・推進を スクラムマスター／アジャイルコーチとして取り組み中 お気に入り店舗はイオンレイクタウン
51. 自己紹介 聖地福岡にはコロナ禍でこの日を最後に・・ ※観戦史上歴史的大敗ｗ ZoZoマリンスタジアムには、仕事帰りに歩いて行けます！ 趣味：旅行、野球観戦、etc…
52. まず最初に・・・
53. 以下の実現および実現手段として採用 ・多数の不確実性の高い要件に対して、 優先順位・内容の柔軟な見直しを行い、 価値のある要件から開発をしたい ・お客さま・事業会社・推進部署からの iAEONに対するフィードバックや追加 要望を、手軽に取り込みたい なぜ内製化に踏み切ったか & ”Why Agile(Scrum)“ まず最初に・・・
54. スクラムがもたらす価値の実現を 実際にやってみたかった ※支援時は中途半端なスクラムばかり・・ ・特にやりたかったことは、 アジャイル開発（スクラム）の型を しっかり(※)定めてから始めたら ※スクラムの原理原則に則りつつ、 不完全な部分を適切に補完した プロセスに則ること 翁長のやりたかったこと まず最初に・・・ https://scrumguides.org/docs/scrumguide/v2020 /2020-Scrum-Guide-Japanese.pdf
55. まず最初に・・・ 今はこの位置 ・2022/10～2023/08：黎明期・・・スモールスタートによる成功体験の積み上げ ・2023/09～2023/12：成長期・・・内製開発を主体化へスケール化による開発力強化・確立 ・2024/01～2025/02：拡大期・・・更なるスケール化、次のステップに向けた準備期間 ・2025/03～2026/02：？？期 2023/9 2024/1 2025/3 【黎明期】 <取り組み> ・内製チーム組成 ・スクラム導入(トレーニング) ・メンバーの専任化 <主な案件・要件> ・電子マネーWAON対応 ・イオン九州ガッチャ対応 2022/10 【成長期】 <取り組み> ・QAメンバー参画 ・チーム分割（2チーム） ・LeSS導入 ・スクラムフォローアップ ・アジャイル開発者検定受験 <主な案件・要件> ・耐障害性向上 ・レシートレス（Ph1～2） ・アプリ間連携 ・現金チャージ 【拡大期】 <取り組み> ・チーム分割（3チーム） ・スクラムマスター増員 ・統合バックログ導入 ・POフォローアップトレーニング ・MagicPod導入 ・スキルトランスファー <主な案件・要件> ・GAタグ ・バーコード一回スキャン ・Boltz Engine ・iAEON三周年記念 これまでの歩み 【？？期】 <取り組み> ・？？？ ・？？？ <主な案件・要件> ・？？？ ・？？？ ・？？？ etc...
56. 【黎明期】 アジャイル開発(スクラム)導入 ～スモールスタート 【成長期】 2チーム化（LeSS導入）の実現 【拡大期】 最後に・・・ 現在位置とこれから ※時間があればAppendixを… 「統合バックログ」の仕組み化 ／内製化シフトに向けて ～3チームへのスケール化 まず最初に・・・
57. 【黎明期】 アジャイル開発(スクラム)の導入 ～スモールスタート
58. 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート まずはここ ・2022/10～2023/08：黎明期・・・スモールスタートによる成功体験の積み上げ ・2023/09～2023/12：成長期・・・内製開発を主体化へスケール化による開発力強化・確立 ・2024/01～2025/02：拡大期・・・更なるスケール化、次のステップに向けた準備期間 ・2025/03～2026/02：？？期 2023/9 2024/1 2025/3 【黎明期】 <取り組み> ・内製チーム組成 ・スクラム導入(トレーニング) ・メンバーの専任化 <主な案件・要件> ・電子マネーWAON対応 ・イオン九州ガッチャ対応 2022/10 【成長期】 <取り組み> ・QAメンバー参画 ・チーム分割（2チーム） ・LeSS導入 ・スクラムフォローアップ ・アジャイル開発者検定受験 <主な案件・要件> ・耐障害性向上 ・レシートレス（Ph1～2） ・アプリ間連携 ・現金チャージ 【拡大期】 <取り組み> ・チーム分割（3チーム） ・スクラムマスター増員 ・統合バックログ導入 ・POフォローアップトレーニング ・MagicPod導入 ・スキルトランスファー <主な案件・要件> ・GAタグ ・バーコード一回スキャン ・Boltz Engine ・iAEON三周年記念 【？？期】 <取り組み> ・？？？ ・？？？ <主な案件・要件> ・？？？ ・？？？ ・？？？ etc...
59. 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート 着任当初、アジャイル開発(スクラム)に関するモノがASTには 無かった・・・ ・JIRAはあった(位) ・パートナー会社に委託している開発はアジャイルなものも ありましたが・・・ ゼロからのスタート
60. 最初の半年間でやることを決めて、 経営陣（当時の副社長）に伝えた ①大まかにやることをロードマップ化 ・成功体験を得られる要件の開発 ・アジャイル開発プロセス確立 ・バックログ(管理)の整備 ②半年後のイメージを伝える ③何かあったら相談させて頂く やることを決める・伝える 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート 了解！
61. 「しっかりと導入」するために、 中途半端にならない様、纏まった時間と 横断的なカリキュラムで実施 ・開発チームの全メンバーを対象 ・8～10時間程度をかけて実施 ・アジャイル宣言から始めた ⇒スクラムの活動をひととおり イメージできるようにした 初期トレーニングを開催 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート https://agilemanifesto.org/iso/ja/manifesto.html
62. スクラムイベントをひととおり実施 ・ただ「やる」ではなく目的をもって行う ・最初はひととおり「やってみせる」 ・少しずつ「やってもらう」、へ ・初期段階では中途半端になりがちなので プレイベントやポストイベントを設けて、 中途半端にならないようにした スクラムイベントをしっかりと 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート
63. プロダクトバックログリファインメント (PBR)もひと工夫してみました ・PBRをイベントとして実施 ・PBRにもプレイベントを設定 (「PBIの下見の下見」と称してた) ・PBRの活動もプロダクトバックログを 作成して、見える化を図った PBRもしっかりと 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート
64. ステークホルダーが多岐にわたるため、 オンリーワンのPOを配置することが 極めて困難であったことから、 POチーム(バーチャル組織)を組成 主に以下メンバーがPOチーム所属 ・アプリ新機能の企画担当 ・アプリのCS担当 ・アプリの運営・プロモーション担当 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート POをチーム制とした(その１) チーム戦だ！
65. プロダクトオーナー代理(PO-Px)を 開発側のロールとして採用(以下を企図) ビジネスPOと一体的にPO業務を遂行 ・ビジネスPOへのアジャイル開発 (スクラム)に関するスキル補完 ・ビジネスPOへの業務とシステムを 橋渡しするためのスキル補完 POをチーム制とした(その２) 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート 代理の術
66. ・電子マネーWAONカード(青カード)の iAEONアプリへの登録 ・既知の機能から始めて成功体験を得る ↓ ・登録時チェック機能の追加要望が・・ ・他のカード登録機能にも要望が・・ ⇒一番最初に要件の変化～フェーズ分け というアジャイルな体験ができた スモールスタート＆成功体験 (最初の内製スクラム) 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート 開発済み 開発 スコープ 青カードも 登録できて、 お客さま評価 も上々
67. 内製開発専任で入社していたメンバーが 別の業務に配置されていた ※入社タイミングがまちまちだった為 ↓ 経営陣（当時の副社長）に状況を伝えて スクラム導入・推進がままならないこと、 取り組みを加速したい旨を伝えた ⇒出向メンバーは帰任＆開発専任へ 黎明期の課題 (Devの人数が増えない) 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート
68. 同じタイミングでスクラムマスター経験 のあるメンバーがエンジニアとして入社 ⇒Devメンバーが5人体制になり、 スクラムチームとして適正人数に！ ・スキルセットも増えて ・メンバーの役割も多彩になり ・複数の業務要件を実施できるだけでなく ・改善系の要件も実施できるように そして・・・ 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート
69. アジャイル開発(スクラム)を始めるには、 色々な意味で「最初が肝心」 ・いつまでにどのような取り組みを 進めるかを設定したことが良かった ⇒取り組みを気にかけてもらえたこと、 相談できたことはとても有難かった ・スクラムのフレームワークを最初から ひととおり採用したことが良かった ⇒一連の活動が首尾一貫すること、 スクラムのもたらす成果を実感 黎明期をふりかえって 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート 最初が肝心！
70. ゼロから始めるにあたって考慮した方が 良いと感じた点 ・初期段階は妥協せず「やる」「続ける」 ⇒それにより「リズム」が生まれる ・スクラムの不完全な部分を初期段階に おいて如何に補完するか ⇒正解は一つではなく経験則に依る ・導入準備段階からスプリントを回した 方が良い(これは後になって実感した点) 黎明期をふりかえって 【黎明期】アジャイル開発(スクラム)の導入～スモールスタート 導入準備から スプリントを
71. 【成長期】 2チーム化（LeSS導入）の実現
72. 【成長期】2チーム化（LeSS導入）の実現 ・2022/10～2023/08：黎明期・・・スモールスタートによる成功体験の積み上げ ・2023/09～2023/12：成長期・・・内製開発を主体化へスケール化による開発力強化・確立 ・2024/01～2025/02：拡大期・・・更なるスケール化、次のステップに向けた準備期間 ・2025/03～2026/02：？？期 2023/9 2024/1 2025/3 【黎明期】 <取り組み> ・内製チーム組成 ・スクラム導入(トレーニング) ・メンバーの専任化 <主な案件・要件> ・電子マネーWAON対応 ・イオン九州ガッチャ対応 2022/10 【拡大期】 <取り組み> ・チーム分割（3チーム） ・スクラムマスター増員 ・統合バックログ導入 ・POフォローアップトレーニング ・MagicPod導入 ・スキルトランスファー <主な案件・要件> ・GAタグ ・バーコード一回スキャン ・Boltz Engine ・iAEON三周年記念 【？？期】 <取り組み> ・？？？ ・？？？ <主な案件・要件> ・？？？ ・？？？ ・？？？ etc... 【成長期】 <取り組み> ・QAメンバー参画 ・チーム分割（2チーム） ・LeSS導入 ・スクラムフォローアップ ・アジャイル開発者検定受験 <主な案件・要件> ・耐障害性向上 ・レシートレス（Ph1～2） ・アプリ間連携 ・現金チャージ 次はここ
73. 2チーム化(LeSS導入)の実現 【成長期】2チーム化（LeSS導入）の実現 きっかけは鶴の一声 ・「8月中に2チームにしよう」、との CTO(やまけんさん)からのオーダー ・1年位は１チームで整えていきたかった ・とはいえエンタープライズ企業として の意図も分かる 8月中に 2チームに しよっかw
74. 2チーム化(LeSS導入)の実現 【成長期】2チーム化（LeSS導入）の実現 ・プロパー6名のDevチームを分割すると、 3人のチームが2つと分割損が先行しそう ・パートナー会社メンバーに参画頂き、 4or5人のチームを2チーム組成 ・プロパーは均等型の分割を採用 ※チームの文化・特色の継承を目的に ・スクラムマスターは2チームを兼任
75. LeSSのフレームワークを採用 【成長期】2チーム化（LeSS導入）の実現 Scrumチームの分割・スケール化にあたり LeSSのフレームワークに倣ったプロセスへ ・成果物：スクラム⇒LeSSでは不変 (PBLも１つのまま) ・スクラムイベント：LeSSチーム全体 で実施する内容とスクラムチームで実施 する内容に分割・新設 https://less.works/jp
76. 分割の結果・・・ 【成長期】2チーム化（LeSS導入）の実現 ・分割後、4スプリント後には分割前の 2倍程度のベロシティに ・メンバーのスキルを考慮していたので チーム毎に多少の特色は出てきたが、 計画時の振り分けが難航するなどの 分割損の発生は無し ・イベントもLeSSのイベントベースで スキップなく継続
77. スクラムチームをスケール化するにあたり 考慮した方が良いと感じた点 ・プロパー比率(50%以上)が良かった ・ジョインしたパートナーが自走できた ・PO-Pxの増員でより多くの要件を扱えた ・LeSSのフレームワークは最初から 全て採用した方がより良かった ⇒LeSSのPBRの採用に時間を要した ・優秀なPO代理の退職は痛恨の極み・・ 成長期をふりかえって 【成長期】2チーム化（LeSS導入）の実現 https://less.works/jp さっし～
78. 【拡大期】 「統合バックログ」の仕組み化／ 内製化シフトに向けて ～3チームへのスケール化
79. 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 今はこの位置 ・2022/10～2023/08：黎明期・・・スモールスタートによる成功体験の積み上げ ・2023/09～2023/12：成長期・・・内製開発を主体化へスケール化による開発力強化・確立 ・2024/01～2025/02：拡大期・・・更なるスケール化、次のステップに向けた準備期間 ・2025/03～2026/02：？？期 2023/9 2024/1 2025/3 【黎明期】 <取り組み> ・内製チーム組成 ・スクラム導入(トレーニング) ・メンバーの専任化 <主な案件・要件> ・電子マネーWAON対応 ・イオン九州ガッチャ対応 2022/10 【成長期】 <取り組み> ・QAメンバー参画 ・チーム分割（2チーム） ・LeSS導入 ・スクラムフォローアップ ・アジャイル開発者検定受験 <主な案件・要件> ・耐障害性向上 ・レシートレス（Ph1～2） ・アプリ間連携 ・現金チャージ 【拡大期】 <取り組み> ・チーム分割（3チーム） ・スクラムマスター増員 ・統合バックログ導入 ・POフォローアップトレーニング ・MagicPod導入 ・スキルトランスファー <主な案件・要件> ・GAタグ ・バーコード一回スキャン ・Boltz Engine ・iAEON三周年記念 【？？期】 <取り組み> ・？？？ ・？？？ <主な案件・要件> ・？？？ ・？？？ ・？？？ etc...
80. そもそもの課題は黎明期から・・ ・複数のPOやステークホルダーから 直接要件を持ちかけられていた ↓ ・全てが「私の要件が一番！」状態 ・こっそりと「これよろしく」とか 「やることと期限決めてきた」とか ⇒開発は逼迫＆費用も肥大化 「統合バックログ」の仕組み化 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化
81. ・普通にプロダクトの要件を一元的に 受け付けて管理する仕組み ・要件部分と実装部分のバックログが 分かれている部分は、 「デュアルトラックアジャイル」 からのヒント なので・・・考えてみた 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化
82. ・スクラム的には必要な仕組みですが ・当時のビジネスPOの方からは、 「統一的な優先順位付けは困難」 とのことで、この仕組みには難色を ・そうしている間にも、 「私の要件が一番」ビームが乱発射・・ すぐには導入に至らず・・ 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 統一的な 優先順位付け は困難
83. 再び当時の副社長に相談することに・・・ ・統一的な優先順位付けが この仕組みの肝であることを伝える ⇒iAEONの優先順位基準も整理 ・副社長が「優先順位判断、、するよ」 と言ってくださった ・副社長およびCTO・COOの3名による 優先順位付け(着手判断)を行う運用へ 副社長がPO(的な立ち位置)に 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 するよ
84. ・構想から運用開始まで１年以上 ・24年3月から週次での 「統合バックログ確認会」を開催、 スプリント計画的に統合バックログの 確認を実施 ・25年1月よりPOによる優先順位付けや 着手判断を行うという本来の活動へ 運用開始～定着へ 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 この要件の優先 順位を上げます
85. 内製化シフトへの打ち手 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 24年度２Qからのほぼ内製開発に向けた スケーリングを実現 ①更なるスケール化 ⇒3チーム化の実現＆スクラムマスタ増員 ②パートナー会社からのスキトラ ⇒一旦完了も新たな委託により継続 ③内製スクラムQA ⇒MagicPod導入＆テストプロセス標準化
86. そして、、内製開発主体へ 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 22年度第3Qから開始の内製開発を、 24年度第2Qから原則内製開発へ ・24年度第1Qまでに内製化比率を50%へ ・24年度第2Qより開発採択判断を 内製開発のキャパシティ範囲内へ ・完全な内製化への一括シフトとせず、 端境期のキャパオーバーリスク回避を 念頭に、最低限の委託開発を継続
87. 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 ・iAEONアプリが利用できないなどの重大障害発生比率が、 2023年度と比較して2024年度は4分の1程度に減少 ・Google PlayおよびAppStoreのストア評価も、 内製開発の取り組みが進むにつれて、以下のとおり良化へ 障害発生件数＆ストア評価にも変化が・・ 【2023年】 2.0未満 【2024年】 4.0以上
88. 内製化シフトやスケール化に おける課題 【拡大期】「統合バックログ」の仕組み化／内製化シフトに向けて～3チームへのスケール化 ・スキトラ完了後に新たな委託開発の発生 (需要旺盛・納期ロック・キャパオーバー) ⇒内製化比率の低下へ ・プロパーメンバーが増えない ・プロパー比率が少ないスクラムチーム ⇒意図しないピラミッド的構造
89. 【最後に・・・】 現在位置とこれから
90. 【最後に・・・】現在位置とこれから 今はこの位置 2023/9 2024/1 2025/3 【黎明期】 <取り組み> ・内製チーム組成 ・スクラム導入(トレーニング) ・メンバーの専任化 <主な案件・要件> ・電子マネーWAON対応 ・イオン九州ガッチャ対応 2022/10 【成長期】 <取り組み> ・QAメンバー参画 ・チーム分割（2チーム） ・LeSS導入 ・スクラムフォローアップ ・アジャイル開発者検定受験 <主な案件・要件> ・耐障害性向上 ・レシートレス（Ph1～2） ・アプリ間連携 ・現金チャージ 【拡大期】 <取り組み> ・チーム分割（3チーム） ・スクラムマスター増員 ・統合バックログ導入 ・POフォローアップトレーニング ・MagicPod導入 ・スキルトランスファー <主な案件・要件> ・GAタグ ・バーコード一回スキャン ・Boltz Engine ・iAEON三周年記念 ふりかえり（黎明期～成長期～拡大期を経て） 【？？期】 <取り組み> ・？？？ ・？？？ <主な案件・要件> ・？？？ ・？？？ ・？？？ etc... ・2022/10～2023/08：黎明期・・・スモールスタートによる成功体験の積み上げ ・2023/09～2023/12：成長期・・・内製開発を主体化へスケール化による開発力強化・確立 ・2024/01～2025/02：拡大期・・・更なるスケール化、次のステップに向けた準備期間 ・2025/03～：？？期
91. やめたいこと／やりたいこと 【最後に・・・】現在位置とこれから ①一時しのぎの委託開発継続はやめたい ・「委託＞内製(誤認識)」の定着懸念 ・アプリ内の技術的負債増加 ②プロパー比率は増やしたい ・スクラムチームの健全な活動に必要 ・プロパーをトップとした力学を回避 ③フロー効率を目指したい ・チームで的確な開発プロセスを考える ・統一的な優先順位の考え方に従う ※納期ロックを回避したリリース計画へ
92. 次のステージは「成熟期」 【最後に・・・】現在位置とこれから 現状の評価・ふりかえり ・これまでの取組みをメンバーに感謝！！ ・型をしっかり整備してから始めると、 スタートダッシュをしっかりできた ＆再現性を持たせることができた ・「守破離」の「守」に則った活動が 出来ていた ・逆にやりすぎた感もあり、失敗からの 改善体験が少なく、整備された内容に 倣うだけの活動になっていなかったか？
93. 次のステージは「成熟期」 【最後に・・・】現在位置とこれから ・そんな心配も余所に、現時点では 「しっかり整備された型」で活動する ことに対する一定の疑問や提案が起り 始めている ・黎明期～成長期～拡大期を経て、 これまでの取り組みに疑問を持ち始めた チームが踏み込む次のステージ ・成熟期には「守破離」の「破」を実現 してほしいと思う
94. 4チーム化に向けて 【最後に・・・】現在位置とこれから LeSSチームの更なるスケール化を予定 (3チーム⇒4チーム化) ・25年1月末時点では6人×3チーム態勢 ・チーム２の取り組み施策(3月リリース) が完了し、エンジニア(2名)が増員した タイミングで4チーム化を実現予定
95. 自己組織化に向けて 【最後に・・・】現在位置とこれから スクラムマスター主導からDev主導の チーム活動へ ・自律的なチーム開発に向けた後押し ・チームメンバーの責任の下、改善などの 取り組みにおける自由度を増やしていっ てほしい ・とはいえ、今いまはスクラムやLeSSの フレームワークから逸脱しない範囲の 活動を後押しする 色々やって いきましょ
96. 【最後に・・・】現在位置とこれから これまでの歩みとこれからの旅路へ この位置を目指していく旅路へ 自己組織化実現 からの・・・ 今はこの位置 2023/9 2024/1 2025/2 【黎明期】 <取り組み> ・内製チーム組成 ・スクラム導入(トレーニング) ・メンバーの専任化 <主な案件・要件> ・電子マネーWAON対応 ・イオン九州ガッチャ対応 2022/10 【成長期】 <取り組み> ・QAメンバー参画 ・チーム分割（2チーム） ・LeSS導入 ・スクラムフォローアップ ・アジャイル開発者検定受験 <主な案件・要件> ・耐障害性向上 ・レシートレス（Ph1～2） ・アプリ間連携 ・現金チャージ 【拡大期】 <取り組み> ・チーム分割（3チーム） ・スクラムマスター増員 ・統合バックログ導入 ・POフォローアップトレーニング ・MagicPod導入 ・スキルトランスファー <主な案件・要件> ・GAタグ ・バーコード一回スキャン ・Boltz Engine ・iAEON三周年記念 【成熟期】 <取り組み> ・チーム分割（4チームへ） ・LeSS開発プロセス確立 <主な案件・要件> ・ご期待を！！ ・2022/10～2023/08：黎明期・・・スモールスタートによる成功体験の積み上げ ・2023/09～2023/12：成長期・・・内製開発を主体化へスケール化による開発力強化・確立 ・2024/01～2025/02：拡大期・・・更なるスケール化、次のステップに向けた準備期間 ・2025/03～：成熟期・・・LeSSの開発プロセス確立、LeSSチーム・メンバーの自己組織化実現へ
97. テックブログ Meetup SNS オウンドメディア 1 2 3 4 ブログなど イオングループのエンジニ アたちにより、 Zennの Publicationで運用されてい るテックブログ 毎月オンライン or オフライ ンで実施されているAEON主 催のテック系イベント AEON TECH HUB関連の活 動についての情報をポスト していきます AEONグループの社員インタ ビューや登壇レポート、イ ベントのお知らせなどの 様々な記事をお届けします
98. 幅広いポジションでエンジニアを募集中です！！ We are hiring
99. 以上で終わります ご清聴ありがとうございました
100. 【Appendix】 ・フォローアップトレーニング ・スクラムマスター3選
101. 導入後半年のタイミングで、アジャイル フォローアップトレーニングを実施 ・初期トレーニングの学びをどう感じて、 それまでの活動に活かされているか ⇒初期トレーニングの時よりも 賛同・共感が多かった ・チームメンバー全員が「アジャイル ソフトウェア開発技術者検定(Lv1)」合格 ※チームの年度目標にしました フォローアップトレーニング 【Appendix】フォローアップトレーニング https://agilemanifesto.org/iso/ja/principles.html
102. スクラムマスター3選(1/3) 【Appendix】スクラムマスター3選 スクラムチームのスケール化に向けて、 内製スクラムマスター搬出を選択肢に できるよう、スクラムマスター育成に着手 ・チームメンバーから候補者を選定 ・少しずつ取り組んでもらって、 段階的にできることを増やしていった ・構築してきた仕組みを自発的にアレンジ ・最後の仕上げ的にCSM研修を受講
103. スクラムマスター3選(2/3) 【Appendix】スクラムマスター3選 専任スクラムマスタ―のメリデメについて (メリット) ・スクラムマスター業務に専念できること ⇒黎明期は必須 ・別ロールの責務と健全に対峙できること (デメリット) ・別ロールとの距離感が生じやすい(かも)
104. 【Appendix】スクラムマスター3選 スクラムマスタ―の採用について ・０からスクラムを始める場合は、仕組みづくりとアジャイル コーチングができて、現場に入れるスクラムマスター採用が良い ・スクラムをスケール化する場合は、新たなスクラムマスターを 採用してもよいが、現場で育成できるならなお良い ・(おまけ)兼務をするならロール跨ぎではなくチーム跨ぎがおススメ スクラムマスター3選(3/3)