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

ScrumFestOsaka2021での発表資料です。

Transcript

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

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

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

4. ©Akatsuki Inc. 世界をエンターテインする。 クリエイターと共振する。 Entertain the world. Resonate with creators. 4 エンターテインメントは、人の心の原動力になる。 最高の体験を通じて見える世界が広がり、 家族や友人、そしてまだ見ぬ仲間とのつながりを作ってくれる。 人生を振り返った時、その体験はかけがえのない時間となる。 私たちは自身の内面から湧き出る表現に加え、 世界中のクリエイター、アーティスト達と共振し、 人々の心を動かすエンターテインメントを創り続けていく。 MISSION
5. ©Akatsuki Inc. 5 事業だけではなく”組織のあり方”も変化を追及し、 創造性が発揮され続ける組織を目指します。 組織の価値観 個々を自立した存在として信頼すること を出発点に、組織のシステムを構築す る。 信頼と自立 規律と制約を設けることで自由と裁量を 明確にし、創造性と主体性を引き出す。 規律と創造 挑戦と失敗を恐れない一方で計画と学 習に情熱を注ぎ、組織単位で進化し続 ける。 挑戦と学習
6. 本題の前にお伝えしたいこと
 • DiscrodのチャットやSNSに、
 感想・ご意見などお気軽にコメントをお願いします！
 発表中、双方向なコミュニケーションをしていきたいと考えてい ます。
 • 写真撮影、スクリーンショットは、OKです！
 SNSにアップしていただいて、OKです！
 • 資料は、のちほど公開します。

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

8. LeSS導入前の状態

9. 体制

10. プロジェクトの全体構成
 新規チーム エンジニアリングが必要な変更 （機能改修、機能追加） 運用チーム エンジニアリングが不要な変更 （イベント追加、ガチャ更新等） Project
 新規チーム エンジニアリングが必要な変更 （機能改修、機能追加等）
11. 新規チームは、セクション縦割り構成
 ディレクター
 デザイナー
 サーバー
 エンジニア
 （SEN）
 クライアント
 エンジニア
 （CEN）
 QA
 エンジニアリングマ ネージャー
 （EM）
 プロジェクト
 マネージャー
 （PM）
 新規チーム
 60人
 Project

12. リリースまでの流れ

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

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

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

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

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

19. 複数バージョンが同時に稼働する
 検証 開発 仕様詳細 決定 検証 開発 仕様詳細 決定 Ver1.0 検証 開発 仕様詳細 決定 Ver1.1 Ver1.2
20. バージョンごとにメンバーがアサインされる
 SEN
 CEN
 検証 開発 仕様詳細 決定 検証 開発 仕様詳細 決定 検証 開発 仕様詳細 決定 QA
 v1.0
 v1.1
 v1.2

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

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

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

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

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

26. 当時の状況まとめ

27. この状況にいたる歴史

28. 過去、チーム固定化やスプリントの導入をした
 過去、チーム固定化、スプリント の導入を行っていた • クロスファンクショナルな2 チーム体制の構築 • 上記2チームで 2バージョンの並行開発 • チームごとにイベントを実施
29. この状態にいたる歴史
 隣のチームのことが分からなくて
 不安
 1チームの人数が多く、振り返りで発言 しづらい。
 イベントを
 セクションチームで行おう！
 人が足りないセクションがあり、
 慢性的にヘルプが発生
 バージョンの進捗状況に合わせ、流 動的に人員配置しよう！
 →そして、リソース効率重視になって いく
 技術的負債が増えてきて、非機能開発 が工数を圧迫し始めてきた。

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

31. LeSS導入前の取り組み

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

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

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

35. 1. 現状把握

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

54. 3. より深い対話

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

56. 意識したこと
 群衆の英知もしくは狂気
57. 4. スモールトライ

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

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

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

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

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

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

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

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

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

67. チーム体制

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

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

70. RACI図で役割を明確化
 • 企画からリリースまでの各フェーズにおいて、
 プロダクトオーナー、開発者、デザイナー、
 スクラムマスター、運用チームなどの各役割について、
 RACI図を作成。
 プロダクト オーナー 開発者 デザイナー スクラム マスター 運用チーム PBIの作成 R/A C C C I スクラムを うまく回す C C C R/A - RACI図の例
71. • サーバーエンジニア、クライアントエンジニア、QAが
 1つのチームにいることで、コミュニケーションの量が増えた！
 • 新機能の開発に対して、セクションを越えて開発する動きになり、
 開発時に気をつけること、考え方が共有されるようになった！
 クライアントエンジニア QA サーバー エンジニア 役割を超えて、相談やコミュニケーションが気軽にできるように！
 わい わい がや がや
72. ペアプロやモブプロを取り入れ開始！
 • 1つの機能開発に1人の開発者をアサインする方法から、
 一部の機能については、
 1つの機能開発に複数人の開発者をアサインする方法に変更！
 • 複数人の開発者がいると、ペアプロやモブプロを取り入れるように！
 • 結果、プルリクエストレビュー工程がなくなり、
 素早くマージされるようになった！
 わい わい がや がや
73. 開発プロセス

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

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

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

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

78. スクラムイベント

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

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

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

82. 見積もり方法

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

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

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

86. チームを超えた取り組み

87. • チームを超えて、スクラムについて話すことができる場を
 EMが企画して実施。
 • ワイワイと話をすることを大事にしており、
 ネクストアクションにつなげることを必須としていない。
 • 実施したテーマ
 ◦ モブワークなど仕事の進め方
 ◦ チーム間コミュニケーション
 ◦ デイリースクラム
 etc
 
 YYスクラムの実施
 わい わい わい わい
88. わいわいタイム！
 Discordのチャットに、今までの内容に対して、
 ご意見、ご感想を書いていただけると嬉しいです！
 

89. LeSS導入後の課題

90. 導入後の課題
 • 開催されないスプリントレビュー
 • チャートから進捗が判断できない
 • 変化の激しいプロダクトバックログ
 • 「全部開発が終わるのいつになる？」
 ✔ ✔ ✔
91. 開催されないスプリントレビュー
 • 増田が入場した2月前半のスプリントでは、
 スプリントレビューが開催されなかった。
 • その後、スプリントレビューは継続して開催している。
 ただ、開発チームによって、
 レビューに出せるインクリメントがないことが、しばしばある状態。
 今回のスプリントレビューで対象となるとなる プロダクトバックログアイテムはどれですか？ 開発チーム 入場直後の増田 出せるものがないので、 スプリントレビューは、 ”なし”でお願いします。
92. • 相対見積もりの結果からバーンダウンチャートを作成するも
 バーンダウンチャートが落ちるときは、ドカッと下がり、
 また平行線の状態になり、先が読みづらい状態。
 • 開発は終わっているが、検証が終わっていない
 チャートに実態が反映されておらず、
 進捗を判断しづらい状況。
 チャートから進捗が判断できない

93. 変化の激しいプロダクトバックログ
 • 運用チームからの依頼や既存バグ対応など差し込みの機能開発が多く、
 プロジェクト開始時よりボリュームが膨れがち。
 • プロダクトオーナーと開発者で仕様を固めたと思い、開発をはじめ、
 仕様の理解が深まってきてから、改めて見積もると、
 開発ボリュームが数倍になることも。
 実際のバーンアップチャート
94. 「全部開発が終わるのいつになる？」
 • 成果物ベースのコミュニケーションが、
 エンジニア個人に依存しており、ばらつきがある状態。
 • その結果、プロダクトオーナーと開発者間でのコミュニケーションが、
 不足していることもあり、プロダクトオーナーの関心事が、
 「考えた仕様のすべてがいつまでに実装完了できるのか？」
 になってしまっている。
 ✔ ✔ 機能A 機能B 機能C
95. 深ぼってみると…

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

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

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

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

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

101. そして未来へ

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

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

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