KDDIアジャイル開発センター株式会社では、
auでんきの「auでんきアプリ」の開発、運用をLarge-Scale Scrum（LeSS）フレームワークで開始し、7年目に突入しました。
4チームでスクラムオブスクラムズを構成しています。

おかげさまで月間100万人以上のお客様に利用いただけるアプリへ成長しましたが、
以下のような多くの要望があります。

• より多くの魅力的な機能を短いスパンでリリースしたい
• プロダクト運営にかかわる対応をスピーディに行いたい
• 日々アップデートされるセキュリティ対策を施したい
• エンジニアは新しい技術をプロダクトで試したい

 etc….

これにより、POが全ての内容を理解して優先順位を決めることが難しくなり、
並行作業が多くリリーススピードの停滞が見えるようになりました。

また、プロダクトの期間が長いため人も入れ替わり、今の変化したやり方が当たり前になり、変えようとする気持ちも薄れつつあります。

スクラムを採用する意味を改めて考え直し、
より素早く市場へ投入できるようにカイゼン活動を行なっております。

スクラム導入の基本である
「スクラムを組織に導入する時は小さくても完璧なスクラムチームをまずは綺麗に回すべき」を2022年に心機一転から既存のLeSSチームの中で導入しております。

そんな私たちの既存プロダクトを運営しながらのカイゼンしていった内容と結果を皆様に共有いたします。

auでんきの「でんきアプリ」は、Large-Scale Scrum（LeSS）フレームワークで7年目に突入しました。
4チームでスクラムオブスクラムズを構成しています。

おかげさまで月間100万人以上のお客様に利用いただけるアプリへ成長しましたが、
以下のような多くの要望があります。

• より多くの魅力的な機能を短いスパンでリリースしたい
• プロダクト運営にかかわる対応をスピーディに行いたい
• 日々アップデートされるセキュリティ対策を施したい
• エンジニアは新しい技術をプロダクトで試したい

 etc….

これにより、POが全ての内容を理解して優先順位を決めることが難しくなり、
並行作業が多くリリーススピードの停滞が見えるようになりました。

また、プロダクトの期間が長いため人も入れ替わり、今の変化したやり方が当たり前になり、変えようとする気持ちも薄れつつあります。

スクラムを採用する意味を改めて考え直し、
より素早く市場へ投入できるようにカイゼン活動を行なっております。

スクラム導入の基本である
「スクラムを組織に導入する時は小さくても完璧なスクラムチームをまずは綺麗に回すべき」を既存のLeSSチームの中で実施しています。

既存プロダクトを運営しながらの大胆なカイゼン内容と結果を皆様に共有いたします。

30人超所属するスクラムチームの開発で7年目に突入しました。

守・破・離の「離」に到達し、独自の文化を形成しつつ運営しております。
参画当初の方々は、それぞれの道を歩み始めており現状チームにはあまり残っていません。

「離」から生まれた独自のプロセスで、現状プロダクト開発を行っております。
プロダクトを止めない開発を行いつつ、大規模なチームのカイゼンは試行錯誤の連続でした。

今一度「守」から、「守・破・離」を振り返り、より高みに到達できるチーム、プロダクトをより大きく育てるべく日夜試行錯誤中。

長期間継続＆大規模チームの状況、新たな取り組みの１つの事例になれば幸いです。

KDDIではスクラムによる開発がどんどん広がっております。

私自身もパーソナル向けのアプリケーションの開発でKDDIで立ち上げから６年間、複数チームでのスクラムをやってきました。

開発規模としては３チーム構成で全体で３０人くらいという複数チームスクラムのプロジェクトの中で主にスクラムマスターとして業務をしてきました。

• サービスインまでのドタバタした時期
• 障害が発生している中でも機能をリリースしていかなくては行けなかったサービスイン後の時期
• 徐々に安定していくと共にお客様の数も増えて開発以外の運用業務も増えていく時期

などに発生した様々な課題やそれに対処した工夫がチームにありました。

スケジュールの言い方や運用や保守などのプロセスの統一などチーム内で工夫したことについて時間が許す範囲でお伝えできたらと思います。

自分自身のふりかえりも兼ねて気がついたことなどまとめて、皆さんの少しでも参考になれたら幸いです。

どういう巡り合わせかスクラム初心者からKDDIのとあるプロジェクトの立ち上げに関わり、気がついたら無我夢中で６年間たっていました。

開発規模としては３チーム構成で全体で３０人くらいという複数チームスクラムのプロジェクトの中で主にスクラムマスターとして業務をしてきました。

• サービスインまでのドタバタした中での過酷な開発をしていた時期
• 障害続きの中でも機能をリリースしていかなくては行けなかったサービスイン後の時期
• 徐々に安定していくと共にお客様の数も増えて開発以外の運用業務も増えていく時期

などそのその時期に応じて様々な変化がチームにありました。

それらの変化の中で体制やバックログの種類、優先順位の考え方など様々な内容をチームとして工夫し適応してきました。

自分自身のふりかえりも兼ねて気がついたことなどまとめて、皆さんの少しでも参考になれたら幸いです。