KDDIで複数チームのスクラムを6年間やってみた
KDDIではスクラムによる開発がどんどん広がっております。
私自身もパーソナル向けのアプリケーションの開発でKDDIで立ち上げから6年間、複数チームでのスクラムをやってきました。
開発規模としては3チーム構成で全体で30人くらいという複数チームスクラムのプロジェクトの中で主にスクラムマスターとして業務をしてきました。
- サービスインまでのドタバタした時期
- 障害が発生している中でも機能をリリースしていかなくては行けなかったサービスイン後の時期
- 徐々に安定していくと共にお客様の数も増えて開発以外の運用業務も増えていく時期
などに発生した様々な課題やそれに対処した工夫がチームにありました。
スケジュールの言い方や運用や保守などのプロセスの統一などチーム内で工夫したことについて時間が許す範囲でお伝えできたらと思います。
自分自身のふりかえりも兼ねて気がついたことなどまとめて、皆さんの少しでも参考になれたら幸いです。
Outline/Structure of the Talk
- 自己紹介
- プロジェクトの紹介、チームの紹介
- 本日の発表内容の概要
- スクラム導入の経緯
- 課題とその対応、工夫
- 当初のスケジュールを変えること
- チーム、プロセスの改善
- 企画や開発、パートナーといった壁
- 開発、運用、保守のプロセスの混乱
- 複数チームならではのチーム間の衝突
Learning Outcome
- スクラムを新しく始めたい人や今現在実践していて今後も継続していきたい人へのナレッジの共有
- 複数チームスクラム運営にあたるナレッジの共有
Target Audience
スクラムを実践している、スクラムでチームの運営をよりよくしていきたい、これからスクラムを実践したい
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Tsuyoshi Ushio - アメリカの超巨大クラウドの中の人に転生したガチ三流プログラマが米国システム開発の現実をリークする話
90 Mins
Keynote
Beginner
世の中、さまざまな陰謀論やフェイクニュースが世間をにぎわしています。Scrum をはじめとしたソフトウェア開発の考え方、世界的に有名なサービスやツールの多くはアメリカから排出されています。ですので、「ソフトウェアの先端の国はアメリカである。」というイメージを持たれている方も多いかもしれません。
… で、本当のところはどうなのよ?
そこで、元アジャイルコーチの私が自ら、ガチ三流プログラマとして米国に移住して米国の超巨大クラウドのサーバーレスプラットフォームの中の人になってみましたので、アメリカのシステム開発の本当のところを、皆様から多くいただく質問に答える形でシェアしてきたいと思います。
秘密さえ知れば、恐れるに足らず!日本を最高にソフトウェアに強い国にするための一歩を一緒に踏み出してみませんか?
こんな質問に答えてほしい!というリクエストがある方は twitter @sandayuu までお知らせください。 -
keyboard_arrow_down
Ryutaro YOSHIBA (Ryuzee) - プロダクトバックログ Deep Dive
45 Mins
Talk
Intermediate
プロダクトバックログのすべてを完全解説!!
スクラムにおいて、プロダクトバックログは肝となる要素の1つです。プロダクトバックログがなければスプリントは始められないですし、単に要件を切り刻んで並べたようなプロダクトバックログでは変化にも対応できません。
スクラムガイドを見ると、プロダクトバックログの作り方、書き方、維持や管理の仕方については、多くは触れられておらず、多くの人は実践で試行錯誤しながらより良いプロダクトバックログを目指して改善を続けられているのではないかと思います(それはそれで素晴らしい)。
一方でプロダクトバックログを誤解しているのもよく見かけます。すべてをユーザーストーリー形式で書く必要もないですし、全部を同じ具体性にする意味もありません。すべてのプロダクトバックログアイテムをプロダクトオーナーが作らなければいけないわけでもないですし、すべてのプロダクトバックログアイテムを実装しなければいけないわけでもありません。Webアプリケーションでログイン機能がプロダクトバックログの上位に必ず来るわけでもありません。
本セッションでは、プロダクトバックログをうまく使えるようになるための基本から応用まで、Scrum Alliance認定スクラムトレーナー(CST-R)、認定チームコーチ(CTC)の吉羽が体系的に解説します。
-
keyboard_arrow_down
Harada Kiro - The Battle in Scrum
45 Mins
Talk
Advanced
2012年、新たな著作のタイトルが "The Battle" だと知った時、すごくがっかりしたのを覚えています。あれだけ分割しても理解できないと主張していたのに、システムA、システムBにように分断するのかと。
それから10年がたち、パタンランゲージとしてのスクラムも世に出すことができたところで、スクラム・アジャイルにとっての The Battle とは、何だったのか、何なのかを考えてみたくなりました。
Agile Manifesto が発表されてから、アジャイル・スクラムはずっと対立軸の片側として語られてきました。アジャイル開発が一般的に使われるようになり、スクラムが最も利用されるフレームワークとなったとき、The Battle は終わったのでしょうか?それとも、まだ別のシステムが存在するのでしょうか?
ここまでの状況をふりかえりながら、現在のアジャイル・スクラムの場所を確かめてみようとおもいます。
-
keyboard_arrow_down
Mori Yuya - ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」をいかに追求しつづけるか
45 Mins
Talk
Advanced
プロダクトには価値はあり、だからこそ顧客は利用している。しかし同時に副作用も生んでいる。
「最高のプロダクトを作ろう」とはじめたのに、いつのまにか「最高の利益を上げよう」という会社になっていた。顧客の悩みに寄り添っていた私たちが、今では顧客のサイフばかり気にしている。
最高のプロダクトを目指していたのにブルシットプロダクトになっちゃった!
この10年でUXデザインや、ユーザーストーリーマッピング、デザイン思考といった顧客理解の知識や技術が普及してきました。しかし、顧客を助けるふりをして、巧みにつけ込むようにみえるプロダクトはたくさんあります。
パッケージや広告だとプロダクトはめちゃくちゃステキ。ところは実物が届いたらひどいものだった。コレジャナイ感がすごい。
サービス加入は簡単なのに退会は困難を極める。入会はwebフォームから簡単にできるのに、退会するには迷路。くぐり抜けてやっと退会できるかと思ったら、電話をするほかなく、電話はいつかけても混雑中で先に進まない…。
サービス契約前は大量の広告や案内が届くのに、サブスクリプション契約したら一切届かなくなり、契約自体を忘れてしまった。気づいたらお金は払い続けているのに全く利用せずに数年たっていた。
これらはあからさまなものです。しかし、ユーザーの立場でみてみると、プロダクトを利用する中で違和感を覚える場面はあふれています。スマホにアプリをダウンロードし、いくつかの入力を済ませ、いざ利用開始というタイミングで利用規約にサインをさせる…そんな不意打ちです。ユーザーの頭の中ではすでにサービスを利用している気になっているので、複雑な規約に向き合える気持ちにはなれないでしょう。
「顧客が本当に必要だったもの」の継続は難しいはじめは顧客に寄り添って「顧客が本当に必要なもの」を届けられていたのに、長く開発しているうちに寄り添わないことが起きはじめた。「顧客の○○さん」というように一人ひとり名前が付いていた顧客が、1人2人と単なる数字で管理するようになり、顧客の声が遠くなった。昔はクレームが届けば顧客の意見をヒアリングしにいったのに、今では一律定型文を返すようになっていた。いつのまにか黙らせることがうまくなっていた。
プロダクトが顧客に受け入れられるにつれて売上は伸び、企業規模は大きくなる。規模が大きくなるにつれて、資金に余裕ができ、才能が集まりやすくなる。本当なら素晴らしいことがもっと成し遂げられるようになるはず。にもかかわらず、以前と比べて価値を生み出せなくなったように感じる。
素晴らしいプロダクトを生み出すのは難しいことですが、素晴らしさを続けていくことはもっと困難です。業務を効率化したり、企業の大規模化にともなって、「顧客が本当に必要だったもの」を生み出す力は少しずつ阻害されていきます。
あるプロダクトの急成長物語
顧客を助けようとする情熱からプロダクトが始まったとしましょう。顧客とヒアリングしたり、開発を続ける中で、チームは豊かな体験をします。プロダクトがリリースされ、顧客に「これが欲しかったんだ!」と熱烈に歓迎され、顧客が殺到します。プロダクトがヒットしたのです。
すると、増えた顧客から顧客対応や新たな要望がどしどしよせられるようになります。チームはてんてこ舞いです。また手強い競合が参入し、競争が激化します。圧倒的な人手不足から採用に取り組み始めますが、これまでのチームの仕事は属人化し、またそれまでの経験がなければ分からなくなっていました。
ぐちゃぐちゃな仕事を整理して、分割して、分かりやすくします。新しく入ってきた人でも即戦力になれるようにするためです。手分けして仕事に当たれるようになりました。このようにして混乱した状況に秩序をもたらし、急成長の痛みを乗り越えたのです。
「この仕事は何のためにあるのか分からないが、やることになっている」
即戦力でも活躍できるように、手分けができるように整理されてコンパクトになった仕事とはいったいどのようなものでしょう。プロダクトのほんの僅かな部分しか担当していないため、プロダクト全体のことはわかりません。プロダクトオーナーは何をしているのか、営業は顧客から何を言われているのか、広報はどのような狙いを持っているのか、おぼろげにしか見えません。これを細い経験と呼びましょう。
一方で、プロダクトを成長させたプロダクトオーナーやチームは、その貴重な経験を活かせるように、さらに重要な仕事に携わるようになります。これを太い経験と呼びましょう。
経験という側面から考えてみます。組織には、分担された仕事による細切れの経験の大勢の人と、稀少な経験を重ねるごく僅かな太い経験の人という分布の偏りが生じるということです。貴重な太い経験をもつ人は、売れっ子の新人女優のように次々と新たな役に恵まれて、さらに豊かな経験をします。細い経験の人はそうではありません。
さらにプロダクトは急成長したとしましょう。一度手分けされた仕事はさらに分けられ、もはや元々がどのような仕事だったのか分からない人もたくさんでてきます。どんどん細分化が進み、部門は管理しやすいように縦割りが進んでいきます。業務効率化が促されるようになり、サポートでは手早く顧客の問題を解決したことにするため定型文を返すようになる…かもしれません。
「いざ改革」に乗り出すも…
このような状況で、危機を覚えた初期の優秀なチームは、顧客の声が遠くなったことや縦割りが進んでいることを理解しています。そこで部門を横串する「ユーザー中心チーム」や「○○経営組織」が発足し、改革を担うようになります。
さて、もう一度、体験の分布を考えてみましょう。僅かな太い体験と、大量の細い体験の二つがありました。「ユーザー中心チーム」や「○○経営組織」という改革の取組はどのような影響を与えるでしょう。是正するでしょうか、それとも強化してしまうでしょうか。
「顧客が本当に必要なもの」を追求しつづけるユーザーから見て、ただひどいだけでなく、開発したり販売する人たち自身がプロダクトに価値がないと感じており、また買ってもらうことに罪悪感を感じるようなプロダクトやサービスをブルシットプロダクトと呼びましょう。
このセッションでは、ブルシットプロダクトとは何か、どのようにして生まれるのか、なにをすれば解消されるのか、顧客が「顧客が本当に必要だったもの」を実現しつづけるプロダクト組織に向けて、組織システムの成長の観点からお話しします。
目次
ブルシットプロダクトとは何か
・ブルシットプロダクト
・顧客につけ込むダークパターン組織システムは何に自己組織化しようとしているのか
・分業の功罪
・太い経験と細い経験
・負の自己組織化
・官僚主義や大企業病は自己組織化の双子
・ブルシットプロダクトマネジメント
・負をマネジメントする顧客を助けるプロダクト組織へ
・顧客を助ける
・顧客の能力を高める
・無知/無能/無関心から、知ってる/できる/当事者意識へ -
keyboard_arrow_down
Yoh Nakamura - 「いい感じのチーム」になるためにやること
45 Mins
Talk
Intermediate
成長しているプロダクトには"いい感じ"のチームが関わっていることが多くあります
"いい感じ"のチームとなっていくには、それなりの時間が必要であり、その時間の中でどのようなマインドセットでどのような活動をしていくかによってその行く末は変わってきます
もちろんチームの行く末によってプロダクトの成長にも影響が出てくることもあります2020年版のScrumGuideでは、スクラムチームの説明として以下のように記述があります
スクラムチームは、ステークホルダーとのコラボレーション、検証、保守、運用、実験、研究 開発など、プロダクトに関して必要となり得るすべての活動に責任を持つ。スクラムチームは、 自分たちで作業を管理できるように組織によって構成され、その権限が与えられている。持続 可能なペースでスプリントの作業を行うことにより、スクラムチームの集中と一貫性が向上す る。
では、"いい感じ"のチームになるにはどのような活動を行い、どのような関心を持てばいいのでしょうか?
このセッションでは、「 "いい感じのチーム"に近づくヒント」を中心にチーム活動に関するいろいろなトピックについて、元ギルドワークスのアジャイルコーチとして70チーム以上を支援してきた自分なりの経験や考えをお話できればと思います
-
keyboard_arrow_down
Tomonori Sano - スクラムチームとアジャイル開発ガイドライン
20 Mins
Talk
Intermediate
【重要】ラグビーの話は一切しません。
スクラムが組織内で広がる際に、アジャイル開発標準のようなルール作成を検討したことがある、もしくは作成したという組織は多いのではないでしょうか。
個別のチームではスクラムガイド+αで十分だったものが、組織が大きくなるにつれ、標準化や効率化を目的としてルールを制定したくなります。その際に、アジャイル開発標準ガイドラインのようなドキュメントが作成されることになります。
一方で、策定したルールをドキュメント化したものの、読まれない、更新されない、作って終わりのような残念な結果にもなりがちかと思います。
本セッションでは、私が所属するKDDI DIGITAL GATEで作成し2年間運用され続けているルールを、ドキュメントをお見せしながら、何を書いて、何を書かないか、どのようなルールで書いているかをお伝えしたいと思います。
大事な事なので、ラグビーの話は一切しません。
-
keyboard_arrow_down
Hiroyuki Ito - 社内アジャイルコーチの卒論: 9年間の多くのしくじりと、いくばくかの成功を添えて/Messages from Ex-Internal Agile Coach
45 Mins
Talk
Intermediate
English follows Japanese.
私は2013年から、自社サービスを展開する事業会社で、社内アジャイルコーチとして活動してきました。
チームビルディングから、開発生産性向上のための(テスト自動化・DevOpsなどの)技術支援、新規プロダクトの共創、さらには経営層を巻き込んだ組織改革と、活動範囲は多岐に渡りました。そして、多くの失敗と、いくつかの成功とを重ねてきました。
この度、社内アジャイルコーチを辞めるにあたり、改めてこれまでの活動結果およびそれらの自分なりの分析結果とを整理し、社内/外のアジャイルコーチ、および同世代/次代のアジャイル実践者へ提供することが、自分を育ててくれたアジャイルコミュニティへの貢献になるのでは?との考えに至りました。
そこで当セッションでは、特に事業会社の社内アジャイルコーチというコンテキストで、自身が悩み、試し、伝える価値があると判断したものを、特にチーム・技術・組織の3点から整理してお話しします。
I had worked as an internal Agile Coach in several internet service companies since 2013.
I had done a wide variety of activities such as team building, implementing technical foundations for enhancing developer productivity, founding totally new products, and leading organizational changes with the management. There were lots of failures, and some successes.
I convince that sharing ideas and knowledge earned through the experience of those my internal Agile coaching activities will contribute to the Agile community.
In this session, I will talk ideas and knowledge earned through my internal Agile coaching activities from 3 aspects like 1) team, 2) technology, and 3) organization.
-
45 Mins
Talk
Advanced
ぼくが所属している組織では、[email protected]を用いて大規模スクラムを運用しています。
本セッションでは、実践を踏まえた[email protected]の解説と、実際の運用の工夫や導入手順などをお話できればと思います。
[email protected] の取り組みは、2021年4月に2チームからスタートしました。その後2021年8月時点で3チームに拡張されています。
数あるスケーリングスクラムの中からあえてこの手法を選んだのには、将来的な拡張の可能性という理由がありました。
チーム初期の導入段階や、そこからチームが増えて拡張していく様子。MetaScrumなどで上位レイヤーをどのようにして巻き込んで整えていくか、など実際の運用の様子を紹介します。
RSGTが開催される2022年1月の時点では、今よりさらに練度をあげているか、もしくは失敗して撤退しているか。いずれにせよ価値のある情報が提供できると思うので、うまくいっているにせよ、いっていないにせよ赤裸々にお話できればと思っています。 -
keyboard_arrow_down
Miho Nagase - 超ハッピー スーパーハッピー のりのり〜!! とにかく明るいセッション ✌️(^o^)
45 Mins
Workshop
Beginner
え、え、え、ちょっと待ってちょっと待って?
このセッション、明るくなーい!???