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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

LeSS導入前の状態 

View Slide

体制 

View Slide

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

View Slide

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

View Slide

リリースまでの流れ 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

検証
開発
仕様詳細
決定
検証
開発
仕様詳細
決定
検証
開発
仕様詳細
決定
v1.0 
v1.1 
v1.2 
v1.0いくぜ！ 

View Slide

検証
開発
仕様詳細
決定
検証
開発
仕様詳細
決定
検証
開発
仕様詳細
決定
v1.0 
v1.1 
v1.2 
v1.1いくぜ！ 

View Slide

検証
開発
仕様詳細
決定
検証
開発
仕様詳細
決定
検証
開発
仕様詳細
決定
v1.0 
v1.1 
v1.2 
v1.2…！あれ？ 

View Slide

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

View Slide

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

View Slide

当時の状況まとめ 

View Slide

この状況にいたる歴史 

View Slide

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

View Slide

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

View Slide

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

View Slide

LeSS導入前の取り組み 

View Slide

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

View Slide

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

View Slide

やったこと 
1. 現状把握 
5. 導入準備（話しません） 
入社後すぐ 
1ヶ月後 

View Slide

1. 現状把握 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide


View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

 

View Slide

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

View Slide

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

View Slide

チーム体制 

View Slide

新規チーム体制(2020年まで) 
SEN 
CEN 
QA 
EM 
PM 
新規チーム 
Project 
再掲 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

開発プロセス 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

スクラムイベント 

View Slide

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

View Slide

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

View Slide

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

View Slide

見積もり方法 

View Slide

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

View Slide

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

View Slide

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

View Slide

チームを超えた取り組み 

View Slide

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

View Slide

 

View Slide

LeSS導入後の課題 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

深ぼってみると… 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

 

View Slide

そして未来へ 

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

Kotoe Ishige

More Decks by Kotoe Ishige

Featured

Transcript