大規模な縦割り組織に LeSSを導入するまでの1年間とその後 / ScrumFestOsaka2021

by Kotoe Ishige

Slide 1

Slide 1 text

株式会社アカツキ石毛琴恵、増田謙太郎大規模な縦割り組織に  LeSSを導入するまでの1年間とその後     

Slide 2

Slide 2 text

石毛琴恵　いっしー@oturu333  株式会社アカツキ   EM / 認定スクラムマスター    2010〜2013 受託開発、SES  2013〜2018 BtoB Web自社サービス  2018〜2019 フリーランスEM（常駐）  2020〜　　アカツキ    ▼趣味  猫吸い、旅行、お酒    ▼最近のこと  外飲みしたい…orz 

Slide 3

Slide 3 text

増田謙太郎  屋号：SCRUMMASUDAR  フリーランスのスクラムマスター    2012〜2019 セキュリティソフトウェアメーカー  2019〜2020 コンタクトECサイトの開発  2021〜　　アカツキ(業務委託)    ▼コミュニティ活動  スクラム道関西、ふりかえりカンファレンス    ▼趣味  ラーメン、コーヒー、朝の散歩 

Slide 4

Slide 4 text

©Akatsuki Inc. 世界をエンターテインする。クリエイターと共振する。 Entertain the world. Resonate with creators. 4 エンターテインメントは、人の心の原動力になる。最高の体験を通じて見える世界が広がり、家族や友人、そしてまだ見ぬ仲間とのつながりを作ってくれる。人生を振り返った時、その体験はかけがえのない時間となる。私たちは自身の内面から湧き出る表現に加え、世界中のクリエイター、アーティスト達と共振し、人々の心を動かすエンターテインメントを創り続けていく。 MISSION

Slide 5

Slide 5 text

©Akatsuki Inc. 5 事業だけではなく”組織のあり方”も変化を追及し、創造性が発揮され続ける組織を目指します。組織の価値観個々を自立した存在として信頼することを出発点に、組織のシステムを構築する。信頼と自立規律と制約を設けることで自由と裁量を明確にし、創造性と主体性を引き出す。規律と創造挑戦と失敗を恐れない一方で計画と学習に情熱を注ぎ、組織単位で進化し続ける。挑戦と学習

Slide 6

Slide 6 text

本題の前にお伝えしたいこと  ● DiscrodのチャットやSNSに、  感想・ご意見などお気軽にコメントをお願いします！  発表中、双方向なコミュニケーションをしていきたいと考えています。  ● 写真撮影、スクリーンショットは、OKです！  SNSにアップしていただいて、OKです！  ● 資料は、のちほど公開します。 

Slide 7

Slide 7 text

目次  1  2  3  4  LeSS導入前の状態  LeSS導入後の変化と取り組み  LeSS導入前の取り組み  そして未来へ 

Slide 8

Slide 8 text

LeSS導入前の状態 

Slide 9

Slide 9 text

体制 

Slide 10

Slide 10 text

プロジェクトの全体構成  新規チームエンジニアリングが必要な変更（機能改修、機能追加）運用チームエンジニアリングが不要な変更（イベント追加、ガチャ更新等） Project  新規チームエンジニアリングが必要な変更（機能改修、機能追加等）

Slide 11

Slide 11 text

新規チームは、セクション縦割り構成  ディレクター  デザイナー  サーバー  エンジニア  （SEN）  クライアント  エンジニア  （CEN）  QA  エンジニアリングマネージャー  （EM）  プロジェクト  マネージャー  （PM）  新規チーム  60人  Project 

Slide 12

Slide 12 text

リリースまでの流れ 

Slide 13

Slide 13 text

計画づくり  ガントチャート

Slide 14

Slide 14 text

実装終了後、検証を行う流れになっている  スプリント1  スプリント2  スプリント3  スプリント4  スプリント5  エピック1  エピック2  エピック3  エピック4  実装  単体テスト  実装  総合テスト  総合テスト  実装  総合テスト  実装  総合テスト  FF(Feature Freeze)   CF(Code Freeze)  単体テスト  単体テスト  既存バグ  実装  総合テスト  単体テスト 

Slide 15

Slide 15 text

セクション ✕ バージョンのイベントを実施する  セクションごと、バージョンごとにイベントを実施。  バージョン朝会やプランニングではガントチャートの確認・調整を行う。  毎日 

Slide 16

Slide 16 text

新規チーム職種、体制  ディレクター  デザイナー  サーバー  エンジニア  クライアント  エンジニア  QA  EM  PM  新規チーム  60人  Project  スクラムマスター（SM）  いない  再掲 

Slide 17

Slide 17 text

バージョンに遅延が発生した場合  再掲 

Slide 18

Slide 18 text

バージョンへのメンバーアサイン 

Slide 19

Slide 19 text

複数バージョンが同時に稼働する  検証開発仕様詳細決定検証開発仕様詳細決定 Ver1.0 検証開発仕様詳細決定 Ver1.1 Ver1.2

Slide 20

Slide 20 text

バージョンごとにメンバーがアサインされる  SEN  CEN  検証開発仕様詳細決定検証開発仕様詳細決定検証開発仕様詳細決定 QA  v1.0  v1.1  v1.2 

Slide 21

Slide 21 text

バージョンごとにメンバーがアサインされる  検証開発仕様詳細決定検証開発仕様詳細決定検証開発仕様詳細決定 v1.0  v1.1  v1.2  v1.0いくぜ！ 

Slide 22

Slide 22 text

バージョンごとにメンバーがアサインされる  検証開発仕様詳細決定検証開発仕様詳細決定検証開発仕様詳細決定 v1.0  v1.1  v1.2  v1.1いくぜ！ 

Slide 23

Slide 23 text

バージョンごとにメンバーがアサインされる  検証開発仕様詳細決定検証開発仕様詳細決定検証開発仕様詳細決定 v1.0  v1.1  v1.2  v1.2…！あれ？ 

Slide 24

Slide 24 text

複数バージョンに関わるメンバーもいる  検証開発仕様詳細決定検証開発仕様詳細決定検証開発仕様詳細決定 v1.0  v1.1  v1.2  v1.2もやるぞ！ 

Slide 25

Slide 25 text

スプリントのイベント  毎日  再掲 

Slide 26

Slide 26 text

当時の状況まとめ 

Slide 27

Slide 27 text

この状況にいたる歴史 

Slide 28

Slide 28 text

過去、チーム固定化やスプリントの導入をした  過去、チーム固定化、スプリントの導入を行っていた ● クロスファンクショナルな2 チーム体制の構築 ● 上記2チームで 2バージョンの並行開発 ● チームごとにイベントを実施

Slide 29

Slide 29 text

この状態にいたる歴史  隣のチームのことが分からなくて  不安  1チームの人数が多く、振り返りで発言しづらい。  イベントを  セクションチームで行おう！  人が足りないセクションがあり、  慢性的にヘルプが発生  バージョンの進捗状況に合わせ、流動的に人員配置しよう！  →そして、リソース効率重視になっていく  技術的負債が増えてきて、非機能開発が工数を圧迫し始めてきた。 

Slide 30

Slide 30 text

わいわいタイム！  Discordのチャットに、今までの内容に対して、  ご意見、ご感想を書いていただけると嬉しいです！   

Slide 31

Slide 31 text

LeSS導入前の取り組み 

Slide 32

Slide 32 text

時系列  時間  石毛参画  1年弱  LeSS 導入  増田  参画  2020/01  2021/01  突然の  リモートワーク 

Slide 33

Slide 33 text

やったこと  1. 現状把握  2. チーム内LT祭り（ティーチング）  3. より深い対話  4. スモールトライ  5. 導入準備  入社後すぐ  1ヶ月後 

Slide 34

Slide 34 text

やったこと  1. 現状把握  2. チーム内LT祭り（ティーチング）  3. より深い対話  4. スモールトライ  5. 導入準備（話しません）  入社後すぐ  1ヶ月後 

Slide 35

Slide 35 text

1. 現状把握 

Slide 36

Slide 36 text

「どういう流れで仕事をしているのか」大枠を理解する。    ● メンバーのことを理解する（1on1）  ○ （自分）自己紹介とやっていきたいこと  ○ （相手）やっていること、困っていること、改善したいと思っていること  ● 仕事の流れを理解する  ○ 組織図や体制の確認  ○ MTGに参加する  ■ ファシリテーター、参加者、内容、頻度  大枠を理解する 

Slide 37

Slide 37 text

1on1は可能な限り、広く行うとより良い  ● 立場の違う人たちから幅広く意見を集約できる  ● チームの全体像が理解しやすい  ○ メンバーの自発性  ○ どの人がどんなことに興味あるのか  ○ セクショナリズムが存在するか、どの程度か 

Slide 38

Slide 38 text

メンバーから出た課題意識  時間効率が悪い  ● 朝会がたくさんあり、朝会だけで時間が多く取られるメンバーがいる  ● 職種の責任範囲が不明瞭でボールが落ちる    PDCAサイクルが回っていない  ● MTGの形骸化（特に、振り返り）  ● セクションを超えた課題解決がしづらい 

Slide 39

Slide 39 text

メンバーから出た課題意識  スケジュールが遅延する、手が空かない  ● スケジュールの終盤になってから遅延が発覚する  ● スケジュール遅延の原因が明確にならず、対策の妥当性や継続性が分からない  ● 改善タスクは「機能開発の手が空いたときにやる」状態で進みづらい    自発性が低い  ● リーダーなど、ハブとなるメンバーに頼りがち 

Slide 40

Slide 40 text

分からないことを深堀りする  ● MTGの背景  ○ MTGの目的や歴史的背景  ● 役割や責務の相互理解  ○ ディレクターとプランナーって何が違うの？  ○ （逆に）EMって何するの？  ● プロセス、フロー  ○ 仕様が定まるタイミング、開発が始まるタイミング…  ○ 意思決定者、プロセス  ○ ブランチワークどうなってるの？   

Slide 41

Slide 41 text

最初は、現状理解に徹することが大事  過去を否定しない。そして、自分の意思を伝える前に  まずは現状と自分以外の人の立場や考えを理解していくこと    真摯な好奇心を大事に。  無邪気に積極的に！    何でも相談できる人を1人見つけると  とっても心強い。 

Slide 42

Slide 42 text

現状を見て思ったこと  ● 複雑な仕組みの中でも相互にフォローし合いながら、継続的に価値提供をし続けている    ● 他責にして文句を言う人が少ない。とても良い人たちで、良いチーム    ● やり方を知らないだけで、彼らが全力で走れる仕組み、流れを整えられれば、大丈夫だろう 

Slide 43

Slide 43 text

チームにとっての理想を考えた  ● 自発的な行動ができるチーム    ● ユーザーへの価値提供に集中できるチーム    ● 人としてチームとして、成長し続ける 

Slide 44

Slide 44 text

まず改善したいと思ったこと  過去の歴史からイベントが形骸化し、PDCAサイクルが回っていない    イベントの目的をそろえて、固定化されたチームごとに実施し、PDCAサイクルを回す  バージョン単位の流動的なチーム & セクションチーム体制による、自発性の持ちづらさ  クロスファンクショナルなチームでの固定化をメインとしつつ、セクションの繋がりも残す体制作り 

Slide 45

Slide 45 text

まず改善したいと思ったこと  ボールが落ちる  責務の見える化  バージョン後半で遅延発覚  問題があったときに早期に変更ができるようにするための、見積もり方法・タイミングの改善 

Slide 46

Slide 46 text

その理想に近いのが、LeSSだった 

Slide 47

Slide 47 text

2. チーム内LT祭り（ティーチング） 

Slide 48

Slide 48 text

LTの立ち位置  As is To be GAP  解決策  LT第1部  LT第1部  LT第2部 

Slide 49

Slide 49 text

LTをしようと思った背景  1. 体制を変えない限りは根本的に改善が難しい。組織規模的にも、早期に手を打ったほうが良いと判断した    2. 目的を理解し、納得して変化しなければいずれ形骸化してしまう    3. 入社して日が浅いため、信頼関係ゼロ。こちらからの考えを伝えつつ、メンバーとの対話の時間を作る 

Slide 50

Slide 50 text

LTの進め方  ● 週次（たまに力尽きてスキップ）    ● LTの目的は、毎回しつこく伝える    ● LT後にハピネスドア　　　でFBをもらい、発表内容の調整や対話 

Slide 51

Slide 51 text

To beで話したこと（LT第1部）  本題に入る前に「今できていること」と「なぜ今できているのに、改善が必要なのか」というお話をした 

Slide 52

Slide 52 text

To beで話したこと（LT第1部）  ● HRT ● 心理的安全 ● 自己組織化 ● 課題解決の方法チーム  ● 不確実性 ● 効率化 ● 見積もり ● 計画づくりプロセス 

Slide 53

Slide 53 text

解決策で話したこと（LT第2部）  ● スクラム、LeSSの概要    ● 大規模スクラム（LeSS）をやっていきたいけど、その目的は第1部で話したことを目指していきたいからだよ    ● 先行して試しているチームからの共有 

Slide 54

Slide 54 text

3. より深い対話 

Slide 55

Slide 55 text

意識したこと  ● 広く浅く共有をしつつ、関心を持ってくれるメンバーとはより深く対話を。いざ変化をおこした後は、彼らが周りのメンバーのサポートをしてくれる    ● 経験主義とはいえ、完全に納得できないことには進めない 

Slide 56

Slide 56 text

意識したこと  群衆の英知もしくは狂気

Slide 57

Slide 57 text

4. スモールトライ 

Slide 58

Slide 58 text

1セクションチームでイベントの改善  ● 1チームで「振り返りが機能していない」という声が大きくなり、振り返り・プランニングの改善をサポートした（予定していたわけではなかった）    ● 半年ちょっとくらい    ● 導入前に、試みと学びを、LT第二部の最後で共有してもらった 

Slide 59

Slide 59 text

チームで実施したこと  ● 相対見積もり ● みんなで見積もり ● プランニングでのアサインプランニング  ● スプリント期間にフォーカスした振り返り ● 想定通りに進まなかった理由の深堀り振り返り 

Slide 60

Slide 60 text

チームで改善できたこと  ● みんなで見積もりをするためには、前提知識を揃える必要がある。  ○ 揃えると、考慮漏れを指摘したり、不要な開発を止めることができた  ○ 着手にあたり不安なことを事前に相談でき、ペアやモブでの実装を提案できた    ● 差し込み作業が作業の予測に影響していると分かり、内容のカテゴライズと計測をしてみた 

Slide 61

Slide 61 text

チーム改善できなかったこと  ● 予実の差分が大きくなりやすいのは、プランニングの時点で仕様が定まってないもの  ○ そもそも見積もりができない  ○ 作業途中で手が止まる 

Slide 62

Slide 62 text

1セクション改善を試みた結論  タスクをReadyにすることは大事。    1セクションでのチームでは、プロセスの課題を解決するのが難しいし、時間がかかる。    クロスファンクショナルチームになって、チャレンジしたい！ 

Slide 63

Slide 63 text

導入前にやったことまとめ  ● 現状を理解する    ● 広く浅く目的や内容を伝える    ● 一部の人と深く対話する    ● 小さく試してみる 

Slide 64

Slide 64 text

わいわいタイム！  Discordのチャットに、今までの内容に対して、  ご意見、ご感想を書いていただけると嬉しいです！   

Slide 65

Slide 65 text

LeSS導入後の変化と取り組み 

Slide 66

Slide 66 text

導入目的を改めて確認！  ● クロスファンクショナルなチームでの固定化を  メインとしつつ、セクションの繋がりも残す体制作り    ● セレモニー目的をそろえて、固定化されたチームごとに  実施し、PDCAサイクルを回す    ● 問題があったときに早期に変更ができるようにするための、見積もり方法・タイミングの改善    ● 責務の見える化 

Slide 67

Slide 67 text

チーム体制 

Slide 68

Slide 68 text

新規チーム体制(2020年まで)  ディレクター  デザイナー  SEN  CEN  QA  EM  PM  新規チーム  Project  再掲 

Slide 69

Slide 69 text

Project  新規チーム体制(2021年1月から)  プロダクトオーナーエピックプロダクトオーナーデザイナー CEN SEN QA スクラムマスター CEN SEN QA スクラムマスター CEN SEN QA スクラムマスター開発チームA 開発チームB 開発チームC プロダクトオーナー(ディレクター)チーム新規チーム  EM  PM 

Slide 70

Slide 70 text

RACI図で役割を明確化  ● 企画からリリースまでの各フェーズにおいて、  プロダクトオーナー、開発者、デザイナー、  スクラムマスター、運用チームなどの各役割について、  RACI図を作成。  プロダクトオーナー開発者デザイナースクラムマスター運用チーム PBIの作成 R/A C C C I スクラムをうまく回す C C C R/A - RACI図の例

Slide 71

Slide 71 text

● サーバーエンジニア、クライアントエンジニア、QAが  1つのチームにいることで、コミュニケーションの量が増えた！  ● 新機能の開発に対して、セクションを越えて開発する動きになり、  開発時に気をつけること、考え方が共有されるようになった！  クライアントエンジニア QA サーバーエンジニア役割を超えて、相談やコミュニケーションが気軽にできるように！  わいわいがやがや

Slide 72

Slide 72 text

ペアプロやモブプロを取り入れ開始！  ● 1つの機能開発に1人の開発者をアサインする方法から、  一部の機能については、  1つの機能開発に複数人の開発者をアサインする方法に変更！  ● 複数人の開発者がいると、ペアプロやモブプロを取り入れるように！  ● 結果、プルリクエストレビュー工程がなくなり、  素早くマージされるようになった！  わいわいがやがや

Slide 73

Slide 73 text

開発プロセス 

Slide 74

Slide 74 text

開発プロセス(2020 年まで)  スプリント1  スプリント2  スプリント3  スプリント4  スプリント5  エピック1  エピック2  エピック3  エピック4  実装  単体テスト  実装  総合テスト  総合テスト  実装  総合テスト  実装  総合テスト  FF  CF  単体テスト  単体テスト  既存バグ  実装  総合テスト  単体テスト  再掲 

Slide 75

Slide 75 text

開発プロセス(2021年1月から)  スプリント1  スプリント2  スプリント3  スプリント4  スプリント5  PBI1  PBI2  PBI3  PBI4  既存バグ  実装  単体テスト  実装  単体テスト  不具合対応  総合テスト  総合テスト  実装  単体テスト  総合テスト  実装  単体テスト  総合テスト  実装  単体テスト  総合テスト  FF  CF  ● シフトレフトで、FFまでに単体テストの完了を目指す。  ● 新機能に加えて、既存バグの対応をバージョン開発開始時に計画する。 

Slide 76

Slide 76 text

● 以前は、ガントチャートで1日単位の作業を  日々確認しているにも関わらず、FFの1週間前に  「やっぱり開発の完了が間に合いません」とエンジニアから遅延を告げられていた。    ● プロダクトバックログアイテムの見積もり結果を使った  バージョンごとのバーンダウンチャートにより、  開発状況の見える化を実施。  FFの1ヶ月前には、FFに間に合わせることが  厳しい機能を、プロダクトオーナーに  認識してもらえるようになった。  プロジェクトの遅延を早く検知できるように！       

Slide 77

Slide 77 text

● 総合テスト期間(FFからCF)に、  “余力があれば”既存バグの修正をしていた。  現実は、新機能の不具合対応で、既存バグの修正に  なかなか手が回っていなかった。    ● 既存障害の修正をプロジェクト開始時に計画するように！  結果、事前に対応する既存障害を  見通せるようになった。  既存のバグ対応を計画できるようになった   

Slide 78

Slide 78 text

スクラムイベント 

Slide 79

Slide 79 text

スクラムイベント(2020年まで)  毎日  動いているバージョンの数だけ、時間をずらして行う  再掲  ● 各セクションごとにイベントを実施 

Slide 80

Slide 80 text

スクラムイベント(2021年1月から)  毎日  ● 固定化した各チームでのみイベントを実施  ● バージョンごとのイベント(朝会)をなくした   

Slide 81

Slide 81 text

朝会の時間が削減！  ● 以前は、バージョンごとに朝会を実施していたため、  ディレクターや複数バージョン掛け持ちのエンジニアは  午前中のほとんどを朝会に費やしていた。  ● 各チームごとにデイリースクラムを実施するのみとなったため、  朝会に費やす時間が30分以内にまで削減された！  ● 結果、本来の仕事（企画作成、開発など）に費やす時間を  増やすことができた！  Ver.1.0の朝会  Ver.1.1の朝会  Ver.1.2の朝会  デイリースクラム  実装  例)午前の時間の使い方  

Slide 82

Slide 82 text

見積もり方法 

Slide 83

Slide 83 text

● ディレクターが要件を決めた時期に、  ロードマップを作成するための絶対見積もりをエンジニアが実施。  ● この結果をもとにディレクターが、  1日単位で、ガントチャートを作成していた。  ● 後から、仕様が変わったり、実装する機能が増えても、  納期が変わらず、プロジェクトを進めるには、不安定な状況だった。    見積もり方法(2020年まで)  機能A  機能C  機能B  実装7日間  実装3日間  実装10日間  例)ガントチャート 

Slide 84

Slide 84 text

見積もり方法(2021年1月から)  見積もりを以下の3つに分類  ● ロードマップを作成するための絶対見積もり  この見積もりの結果を納期としないことを関係者に周知  バッファを考慮したスケジューリングを実施  ● バージョンごとの作業量を求める相対見積もり  プロダクトの進捗見える化するためにバーンダウンチャートに利用  ● スプリントバックログを作るための絶対見積もり  日々のデイリースクラムで開発者が確認するために利用  S  M  L 

Slide 85

Slide 85 text

見積もり方法変更により、事前のスケジュール調整ができるように！  ● ロードマップ作成時、見積もりを考慮して、  開発する機能を選択するようになった。  また、見積もりに幅があることを認識し、  プロジェクトバッファを考慮して計画するようになった。  ● 作業量を表す相対見積もりの結果を用いて、  各バージョンごとの状況を見える化！  バージョン間での優先度を考慮して開発を進めるようになった。 

Slide 86

Slide 86 text

チームを超えた取り組み 

Slide 87

Slide 87 text

● チームを超えて、スクラムについて話すことができる場を  EMが企画して実施。  ● ワイワイと話をすることを大事にしており、  ネクストアクションにつなげることを必須としていない。  ● 実施したテーマ  ○ モブワークなど仕事の進め方  ○ チーム間コミュニケーション  ○ デイリースクラム  etc    YYスクラムの実施  わいわいわいわい

Slide 88

Slide 88 text

わいわいタイム！  Discordのチャットに、今までの内容に対して、  ご意見、ご感想を書いていただけると嬉しいです！   

Slide 89

Slide 89 text

LeSS導入後の課題 

Slide 90

Slide 90 text

導入後の課題  ● 開催されないスプリントレビュー  ● チャートから進捗が判断できない  ● 変化の激しいプロダクトバックログ  ● 「全部開発が終わるのいつになる？」  ✔ ✔ ✔

Slide 91

Slide 91 text

開催されないスプリントレビュー  ● 増田が入場した2月前半のスプリントでは、  スプリントレビューが開催されなかった。  ● その後、スプリントレビューは継続して開催している。  ただ、開発チームによって、  レビューに出せるインクリメントがないことが、しばしばある状態。  今回のスプリントレビューで対象となるとなるプロダクトバックログアイテムはどれですか？開発チーム入場直後の増田出せるものがないので、スプリントレビューは、 ”なし”でお願いします。

Slide 92

Slide 92 text

● 相対見積もりの結果からバーンダウンチャートを作成するも  バーンダウンチャートが落ちるときは、ドカッと下がり、  また平行線の状態になり、先が読みづらい状態。  ● 開発は終わっているが、検証が終わっていない  チャートに実態が反映されておらず、  進捗を判断しづらい状況。  チャートから進捗が判断できない 

Slide 93

Slide 93 text

変化の激しいプロダクトバックログ  ● 運用チームからの依頼や既存バグ対応など差し込みの機能開発が多く、  プロジェクト開始時よりボリュームが膨れがち。  ● プロダクトオーナーと開発者で仕様を固めたと思い、開発をはじめ、  仕様の理解が深まってきてから、改めて見積もると、  開発ボリュームが数倍になることも。  実際のバーンアップチャート

Slide 94

Slide 94 text

「全部開発が終わるのいつになる？」  ● 成果物ベースのコミュニケーションが、  エンジニア個人に依存しており、ばらつきがある状態。  ● その結果、プロダクトオーナーと開発者間でのコミュニケーションが、  不足していることもあり、プロダクトオーナーの関心事が、  「考えた仕様のすべてがいつまでに実装完了できるのか？」  になってしまっている。  ✔ ✔ 機能A 機能B 機能C

Slide 95

Slide 95 text

深ぼってみると… 

Slide 96

Slide 96 text

大きなPBIと１つのPBIに１人のエンジニア  ● 1スプリントで完了できないサイズのPBIが、ほとんど。  ● 大きなサイズなPBIを1人のエンジニアで仕事をしていることが多い。  ● その結果、「スプリントレビューが開催されない」、  「チャートから進捗が判断できない」、「変化の激しい  プロダクトバックログ」、「全部開発が終わるのいつになる？」  といった状況に陥っている。  ● 現在は、PBIを小さくするために、四苦八苦中。 

Slide 97

Slide 97 text

小さなPBIを目指した先の理想 

Slide 98

Slide 98 text

ユーザーへの価値提供を早くする  ● 現在は、数ヶ月後のリリースを達成するために、  開発や検証に取り組んでいる状況です。  ● プロダクトのフィードバックサイクルを回し、  企画からリリースまでのリードタイムを短くしようと奮闘中です。  企画  テスト  実装  現在  未来  リリース  企画  実装  テスト  リリース  実装  テスト  企画  実装  テスト  リリース 

Slide 99

Slide 99 text

運用チームと連携したプロダクト開発  新規チームエンジニアリングが必要な変更（機能改修、機能追加）運用チームエンジニアリングが不要な変更（イベント追加、ガチャ更新等） Project  再掲 

Slide 100

Slide 100 text

わいわいタイム！  Discordのチャットに、今までの内容に対して、  ご意見、ご感想を書いていただけると嬉しいです！   

Slide 101

Slide 101 text

そして未来へ 

Slide 102

Slide 102 text

LeSSを導入した組織のその先へ  自分たちの成し遂げたいこと、あるべき姿を模索しながらの導入初期を終えました。    以前「課題がない」と言う人も多かったチームですが、少しずつメンバーからの課題意識も出てくるようになってきました。🎉    また、おそらく導入前には想像がしづらかった「ユーザーへの価値提供を早くしていこう」という会話も、最近は飛び交うようになりました。🎉   

Slide 103

Slide 103 text

LeSSを導入した組織のその先へ  最終的にはやってみないと分からないし「ともに経験から学び、課題を早く共通認識にして解決していこう」という流れが、少しずつ根付いてきているのかな〜と思います。    モバイルゲーム事業ではまだめずらしいかもしれないアジャイルな組織になっていきたいと思います！ 

Slide 104

Slide 104 text

We are hiring!  アカツキでは、互いに高め合い  最高のゲームをユーザーに届けていけるメンバーを募集しています！  まずはカジュアルにお話しましょう！    ● クライアントエンジニア  ● サーバーエンジニア  ● エンジニアリングマネージャー  ● スクラムマスター  ● More…    ゲーム事業採用サイト  https://game.aktsk.jp/recruit/ 