アカツキ_Cedec2021_「モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後」
•
0 likes•248 views
CEDEC2021のアカツキによるセッション「モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後」資料
Recommended
More Related Content
What's hot
Similar to アカツキ_Cedec2021_「モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後」
Similar to アカツキ_Cedec2021_「モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後」 (9)
More from aktsk_corporate
More from aktsk_corporate (11)
アカツキ_Cedec2021_「モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後」
- 2. 石毛 琴恵 いっしー@oturu333 株式会社アカツキ EM / 認定スクラムマスター 2010〜2013 受託開発、SES 2013〜2018 BtoB Web自社サービス 2018〜2019 フリーランスEM（常駐） 2020〜 アカツキ ▼登壇、活動 スクラムフェス大阪2021、furoshiki.fm ▼趣味 猫吸い、旅行、お酒
- 3. 増田 謙太郎 屋号：SCRUMMASUDAR フリーランスのスクラムマスター 2012〜2019 セキュリティソフトウェアメーカー 2019〜2020 コンタクトECサイトの開発 2021〜 アカツキ(業務委託) ▼コミュニティ活動 スクラム道関西、ふりかえりカンファレンス ▼趣味 ラーメン、コーヒー、朝の散歩
- 4. ©Akatsuki Inc. 世界をエンターテインする。 クリエイターと共振する。 Entertain the world. Resonate with creators. 4 エンターテインメントは、人の心の原動力になる。 最高の体験を通じて見える世界が広がり、 家族や友人、そしてまだ見ぬ仲間とのつながりを作ってくれる。 人生を振り返った時、その体験はかけがえのない時間となる。 私たちは自身の内面から湧き出る表現に加え、 世界中のクリエイター、アーティスト達と共振し、 人々の心を動かすエンターテインメントを創り続けていく。 MISSION
- 8. LeSS導入前の状態
- 13. 導入前の状態
- 18. 導入前の実装・検証の流れ エピック1 エピック2 エピック3 エピック4 実装 単体テスト 実装 総合テスト 総合テスト 実装 総合テスト 実装 総合テスト FF(Feature Freeze) CF(Code Freeze) 単体テスト 単体テスト 既存バグ 実装 総合テスト 単体テスト
- 19. すごく良いチーム！ ● リリースするために自分がすべきことを考えて動いている ● セクショナリズムな対立がない ● チームを大事にする文化が強い
- 20. 課題意識 自発的な改善を求めたい ● リーダーなど、ハブとなるメンバーに頼りがち ● PDCAサイクルが回っていない スケジュール管理が大変だが、遅延する ● マネジメントコストが高い ● スケジュールの終盤になってから遅延が発覚する
- 21. 改善したいと思ったこと 自発的に改善を重ねられるチームになる ● 個やチームが成長に向かえる状態を作る ● PDCAサイクルを回し、積み重ねる状態を作る プロジェクトマネージメントの問題を解決する ● 遅延を減らす & 遅延を早く検知する ● マネジメントコスト下げる
- 22. トークタイム
- 23. LeSSやろう！
- 24. スクラムとは スクラムは ● 3つの作成物 ● 3つのロール ● 5つのイベント など最低限のルールの セットで 構成されています。 引用：『SCRUM BOOT CAMP THE BOOK【増補改訂版】』
- 26. やったことと変化
- 32. ● コミュニケーションの量が増え、 気軽な相談がしやすくなった ● セクションを越えて、開発時に 気をつけること、考え方が共有 されるようになった！ ● 課題が上がるようになってきた クライアントエンジニア QA サーバー エンジニア チーム内のコミュニケーションが活性化 わい わい がや がや
- 33. ペア・モブプロやワークが活性化 ● ペアプロやモブプロが増えた ● QAメンバーのペア・モブワークも 始まった ● 試してみた結果、属人的なタスク を減らしていきたいという声の増 加 ● 協働作業でレビューを含めている ので、完了スピードUP
- 36. 目的
- 42. お互いを知る = 自己開示とフィードバック 自己開示とフィードバックのサ イクルを回していくことで、相 互理解が深まる ● 雑談 ● 価値観ポーカー ● ドラッガー風エクササイズ ● 自己紹介・他己紹介ワーク 引用：https://qiita.com/hirokidaichi/items/5d8c4294083d85654a04
- 44. 心理的安全のない組織で起こること このように 見られたくない 行動 発生する問題 無知 質問をしない 作業の非効率（大きな手戻 り、作業遅延） 無能 失敗を隠す、認めない 何度も同じ失敗が起きる ネガティブ 意見を言わない 解決しない 邪魔 アイデアを提案しない 改善しない
- 47. より心理的安全の高いチームになるために 個に求められるマインド ● 仕事を実行の機会ではなく学習 の機会と捉える ● 自分が間違うということを認め る ● 好奇心を形にし、積極的に質問 する 引用：https://rework.withgoogle.com/jp/guides/understanding-team- effectiveness/steps/foster-psychological-safety/
- 52. 開発プロセス
- 53. 導入前の実装・検証の流れ エピック1 エピック2 エピック3 エピック4 実装 単体テスト 実装 総合テスト 総合テスト 実装 総合テスト 実装 総合テスト FF(Feature Freeze) CF(Code Freeze) 単体テスト 単体テスト 既存バグ 実装 総合テスト 単体テスト
- 54. 開発プロセス(2021年1月から) スプリント1 スプリント2 スプリント3 スプリント4 スプリント5 PBI1 PBI2 PBI3 PBI4 既存バグ 実装 単体テスト 実装 単体テスト 不具合対応 総合テスト 総合テスト 実装 単体テスト 総合テスト 実装 単体テスト 総合テスト 実装 単体テスト 総合テスト FF CF
- 55. ● 大きな粒度のエピックから小さい粒度であるプロダクトバ ックログアイテム(PBI)での完成を目指す。 ● シフトレフトで、FFまでに単体テストの完了を目指す。 ● 新機能に加えて、既存バグの対応を バージョン開発開始時に計画する。 プロセス変更の意図
- 57. 計画時の見積もり
- 58. ● ディレクターが要件を決めた時期に、ロードマップを 作成するための人日見積もりをエンジニアが実施。 ● 上記結果をもとにディレクターが、 1日単位で、ガントチャートを作成していた。 ● 後から、仕様が変わったり、実装する機能が増えても、 納期が変わらず、プロジェクトを進めるには、不安定な状況。 見積もり方法(2020年まで) 機能A 機能C 機能B 実装7日間 実装3日間 実装10日間 例)ガントチャート
- 59. 見積もりを以下の3つに分類 1. ロードマップを作成するための人日見積もり ○ 見積もり結果を納期としないことを関係者に周知 ○ バッファを考慮したスケジューリングを実施 2. バージョンごとの作業量を求める相対見積もり ○ 進捗見える化のためバーンダウンチャートに利用 3. スプリントバックログを作るための人日見積もり ○ 日々のデイリースクラムで開発者が確認するために利用 見積もり方法(2021年1月から) S M L
- 61. 目的
- 63. 改善したいと思ったこと 自発的に改善を重ねられるチームになる ● 個、チームが成長に向かえる状態を作る ● PDCAサイクルを回し、積み重ねる状態を作る プロジェクトマネージメントの問題を解決する ● 遅延を減らす & 遅延を早く検知する ● マネジメントコスト下げる 再掲
- 66. 既存バグの対応がFFからCFの期間に限定されている ● 既存バグの修正見通しが立ちづらく、 新機能のバグ対応が優先されるため、 修正バージョンが以降のバージョンに送られ続ける 発生していた不思議な現象③ v1.0 v1.1 v1.2 入らないから 次へ！ 今回も入らないから 次へ！
- 67. スケジュールが遅延するとは？ ● プロジェクトにおいて、「スケジュールの遅延が 発生している」とは、どのような状況だろうか？ ○ やるべきことが後から見つかってくる ○ バグなど手戻りが多く発生している ○ 差し込み作業で、メンバーがプロジェクトに入れない etc ● 要するに、 「自分たちが立てた計画通りに、進んでいないこと」
- 68. そもそも計画を立てることの難しさ ● スケジュールの見積もりは、 初期に立てるほど、 ズレが大きくなりやすい。 ● くわえて、見積もる人と 作る人が異なると、さらに 見積もりがずれるため、 計画の難易度が上がる。 引用：『アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～』P.27
- 71. ● ユーザー操作におけるテンポの良さ ● 初心者でもわかりやすい操作になっている ● ユーザーの目を引く演出になっている etc いくら綿密な計画を立てたとしても、 後から発見することが多く、 改善することが重要なのが、ゲーム開発 ゲームにおいて作ってみないとわからないこと
- 72. ● プロダクトは完成し、一定の品質が担保されていることで 世にリリースすることができる ● 多くの仕事に手を付けたとしても、 完成しない限り、リリースすることができない ● 仕掛品の数を少なくすることで、 小さくとも機能として完成した状態を目指す 仕事を始めるんじゃない！終わらせるんだ！
- 75. 改善したいと思ったこと 自発的に改善を重ねられるチームになる ● 個、チームが成長に向かえる状態を作る ● PDCAサイクルを回し、積み重ねる状態を作る プロジェクトマネージメントの問題を解決する ● 遅延を減らす & 遅延を早く検知する ● マネジメントコスト下げる 再掲
- 76. マネジメントコストが高い状況
- 77. 最後にひっくり返ると、特にコストが高い ● 正確な計画を立てることは、そもそも難しい ● すべての仕事を最初に洗い出すことも難しい ● プロジェクト終盤に、ちゃぶ台返しが発生すると、 再計画時のコストが、非常に高くなる 最後にひっくり返らないように、 プロジェクト初期から プロダクトを確認し続けることが重要
- 78. 機能の中で優先順位を決める 機能の中で優先順位を決め、集中するべき点を定める ● リリースに必須な機能 ● リリースに必須ではないが、できれば欲しい機能 ● リリース時には不要、またはプロダクトとして不要な機能 全部やりきるのではなく、 どうすればリリースできるのかを焦点をあてる 特に、やらないことを決めることができると、 プロジェクト終盤でひっくり返りづらくなる。
- 79. 変化を受け入れ、コストの低い状態を目指す ● マネジメントコストが0になることはない ● マネジメントコストが低い状態を保つことが重要 ● プロダクト開発を通して得られた経験こそ重要な事実 計画通りに進むことを目指すのではなく、 プロダクト開発を通して得られた経験を 計画に組み込み続ける
- 80. 導入に向けて行ったこと
- 83. ① 観察 1on1 アジェンダ ● （自分）自己紹介とやっていきたいこと ● （相手）やっていること、困っているこ と、改善したいと思っていること 立場の異なるメンバーから幅広く チームの雰囲気もつかめる 否定せず、相手の立場や考えを理解する 『他者と働く』
- 84. ② 新規チーム全体へのLT As is To be GAP 解決策 LT第1部 LT第1部 LT第2部
- 85. ② 新規チーム全体へのLT 第2部 チームについて ● HRT ● 心理的安全 ● 自己組織化 プロセスについて ● 不確実性 ● 効率 ● 計画づくり、見積もり
- 87. ③ 1チームで小さく試して共有してもらう スプリントプランニング ● みんなで見積もり ● 相対見積もり スプリントレトロスペクティブ ● スプリント期間にフォーカスした振 り返り ● 想定通りに進まなかった理由の深堀 り
- 88. なぜこのやり方にしたのか ● 仕事の進め方が複雑になっていて、 まず体制を変えないと、チームが 変化していくのは難しいと考えた ● 目的を理解し、納得して変化しな ければいずれ形骸化してしまう ● 自分の考えを伝えつつ、メンバー との対話の時間を作りたい
- 89. トークタイム
- 90. 新たな課題
- 91. チャレンジを経て、チームの課題が変わった これまでの話題の中心 直近のリリースまでを どのように進めるか これから目指したいこと ユーザー価値、価値提供をベースに ● なぜこれを届けたいのか ● 届けた結果どうだったのか ● 価値をより早く届けよう
- 93. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C ① ②
- 94. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C リリース ① ②
- 95. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C リリース リリース ① ②
- 96. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C リソース効率 できる人ができることをやる。リソースをムダなく利用する フロー効率 それぞれ助け合いながらタスクを割り振りする。リリースまでのリードタイムが短い ① ②
- 97. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C リソース効率 できる人ができることをやる。リソースをムダなく利用する フロー効率 それぞれ助け合いながらタスクを割り振りする。リリースまでのリードタイムが短い ① ②
- 98. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C リソース効率 できる人ができることをやる。リソースをムダなく利用する フロー効率 それぞれ助け合いながらタスクを割り振りする。リリースまでのリードタイムが短い ① ②
- 99. 価値をより早く届けよう A A A A A B B B B B C C C C C A A A A A 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A B B B B B C C C C C 月 火 水 木 金 A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C すべてが着手されて進んでいるように見えて安心感がある。 でも実は、1タスクごとの進捗は見えづらく、 リリースが遅く、マネジメントコストも高い。 優先度の高いものから着手・リリースしていく。 やっていること、進捗が見やすく マネジメントコストが低い。 ① ②
- 100. 価値をより早く届けよう ゲームは、リリースして初めてユーザーに価値提供ができて、 売上にもつながる。なので、リリースを早くしていきたい。 内部で決めたスケジュールどおりに作業が進むかは、実はそれ ほど大事なことではないこともある。 A A A A A A A A A A A A A A A B B B B B C C C C C B B B B B C C C C C B B B B B C C C C C リリース リリース ②
- 101. 具体的に取り組んでいきたいこと
- 103. 並行バージョン開発をやめる