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〜 アカツキ
▼登壇、活動
スクラムフェス大阪2021、furoshiki.fm
▼趣味
猫吸い、旅行、お酒
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
1
2
3
4
LeSS導入前の状態
導入に向けて行ったこと
やったことと変化
これから目指していきたいこと
目次
Slide 7
Slide 7 text
LeSS導入前の状態
Slide 8
Slide 8 text
プロジェクトの全体構成
新規チーム
エンジニアリングが必要な変更
（機能改修、機能追加）
運用チーム
エンジニアリングが不要な変更
（イベント追加、ガチャ更新等）
Project
Slide 9
Slide 9 text
プロジェクトの全体構成
新規チーム
エンジニアリングが必要な変更
（機能改修、機能追加）
運用チーム
エンジニアリングが不要な変更
（イベント追加、ガチャ更新等）
Project
新規チーム
エンジニアリングが必要な変更
（機能改修、機能追加等）
こちらのチームでの
お話をします
Slide 10
Slide 10 text
新規チームは、セクション縦割り構成
ディレクター
デザイナー
サーバー
エンジニア
（SEN）
クライアント
エンジニア
（CEN）
QA
エンジニアリングマ
ネージャー
（EM）
プロジェクト
マネージャー
（PM）
新規チーム
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
導入前の状態
バージョンのスケジュール、スコープ
各機能のWHY、WHAT
Slide 15
Slide 15 text
導入前の状態
複数バージョン同
時に
開発や検証
Slide 16
Slide 16 text
導入前の状態
ディレクターの進捗管理の補佐
コミュニケーションハブ
Slide 17
Slide 17 text
導入前の実装・検証の流れ
エピック1
エピック2
エピック3
エピック4
実装
単体テスト
実装
総合テスト
総合テスト
実装
総合テスト
実装
総合テスト
FF(Feature Freeze)
CF(Code Freeze)
単体テスト
単体テスト
既存バグ
実装
総合テスト
単体テスト
Slide 18
Slide 18 text
すごく良いチーム！
● リリースするために自分がすべきことを考えて動いている
● セクショナリズムな対立がない
● チームを大事にする文化が強い
Slide 19
Slide 19 text
課題意識
自発的な改善を求めたい
● リーダーなど、ハブとなるメンバーに頼りがち
● PDCAサイクルが回っていない
スケジュール管理が大変だが、遅延する
● マネジメントコストが高い
● スケジュールの終盤になってから遅延が発覚する
Slide 20
Slide 20 text
改善したいと思ったこと
自発的に改善を重ねられるチームになる
● 個やチームが成長に向かえる状態を作る
● PDCAサイクルを回し、積み重ねる状態を作る
プロジェクトマネージメントの問題を解決する
● 遅延を減らす & 遅延を早く検知する
● マネジメントコスト下げる
Slide 21
Slide 21 text
LeSSやろう！
Slide 22
Slide 22 text
スクラムとは
スクラムは
● 3つの作成物
● 3つのロール
● 5つのイベント
など最低限のルールの
セットで
構成されています。
引用：『SCRUM BOOT CAMP THE BOOK【増補改訂版】』P.28
Slide 23
Slide 23 text
LeSSとは
スクラムをシンプルに拡張したフレームワークと言われる。
● 全体で1つのプロダクトバックログ
● 複数の開発チーム
Slide 24
Slide 24 text
やったことと変化
Slide 25
Slide 25 text
自発的に改善を重ねられるチームになる
Slide 26
Slide 26 text
以前
流動的なメンバーアサイン
現在
クロスファンクショナルなチームでの固定化
体制の変更
Slide 27
Slide 27 text
チームごとにスクラムイベントを実施
毎日
Slide 28
Slide 28 text
No content
Slide 29
Slide 29 text
No content
Slide 30
Slide 30 text
● コミュニケーションの量が増え、気
軽な相談がしやすくなった
● セクションを越えて、開発時に気
をつけること、考え方が共有され
るようになった！
● 課題が上がるようになってきた
クライアントエンジニア
QA
サーバー
エンジニア
チーム内のコミュニケーションが活性化
わい
わい
がや
がや
Slide 31
Slide 31 text
ペア・モブプロやワークが活性化
● ペアプロやモブプロが増えた
● QAメンバーのペア・モブワークも始
まった
● 試してみた結果、属人的なタスクを減
らしていきたいという声の増加
● 協働作業でレビューを含めているの
で、完了スピードUP
Slide 32
Slide 32 text
（+α）チーム内コミュニケーション
デイリースクラム前の短い雑談
テーマを定めた雑談
自己開示や他者理解
やり方はチームの中で考えて実施
チームランチやディナー
各チーム自由に。
ゲームしたり、おしゃべりしたり。
Slide 33
Slide 33 text
（+α）チームを超えたコミュニケーション
①
②
①新規チーム全体
・仕事の進め方への課題をディ
スカッションする自由参加の場
（YYスクラム）
・シャッフルランチ
②セクションごと
セクションリーダーを中心に
・情報共有、課題発見
・育成、学習
Slide 34
Slide 34 text
目的
Slide 35
Slide 35 text
自発的な改善をしやすく、
改善を積み重ねやすくするための土台づくり
Slide 36
Slide 36 text
議論や高め合いのできるチームになりたい
自発的な改善ができるとは
課題を、衝突を恐れずメンバーに
公開することができ、
議論ができ、
意思決定ができ、
実行できる人やチームになること。
気軽に話せる
相談ができる
議論ができる
難易度
Slide 37
Slide 37 text
議論や高め合いのできるチームになりたい
その状態になるためには土台が必
要。
実際にたどり議論ができるようにな
るかはメンバー次第だが、
土台作りでサポートできる。
気軽に話せる
相談ができる
議論ができる
難易度
Slide 38
Slide 38 text
お互いのことを知ることが大事
自分のこと 他人のこと
Slide 39
Slide 39 text
お互いのことを知ることが大事
自分のこと 他人のこと
業務外
業務
Slide 40
Slide 40 text
お互いを知る = 自己開示とフィードバック
自己開示とフィードバックのサイク
ルを回していくことで、相互理解が
深まる
● 雑談
● 価値観ポーカー
● ドラッガー風エクササイズ
● 自己紹介・他己紹介ワーク
引用：https://qiita.com/hirokidaichi/items/5d8c4294083d85654a04
Slide 41
Slide 41 text
主体性を持ちやすい状態とは
対人関係においてリスクある行動を取っ
たときの結果に対する個人の認知の仕
方、つまり、「無知、無能、ネガティブ、邪
魔だと思われる可能性のある行動をして
も、このチームなら大丈夫だ」と信じられる
かどうか
引用
：https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/identify-dyn
amics-of-effective-teams/
Slide 42
Slide 42 text
心理的安全のない組織で起こること
このように
見られたくない
行動 発生する問題
無知 質問をしない 作業の非効率（大きな手戻
り、作業遅延）
無能 失敗を隠す、認めない 何度も同じ失敗が起きる
ネガティブ 意見を言わない 解決しない
邪魔 アイデアを提案しない 改善しない
Slide 43
Slide 43 text
居場所があるから安心して力が発揮できる
「個として、チームとして成長していく
こと」に目を向けてもらうために
大前提必要な土台を整える必要があ
る。
引用：https://dime.jp/genre/912205/
Slide 44
Slide 44 text
議論や高め合いのできるチームになりたい
その状態になるためには土台が必
要。
実際に議論ができるようになるか
はメンバー次第だが、
土台作りでサポートできる。
気軽に話せる
相談ができる
議論ができる
難易度
Slide 45
Slide 45 text
より心理的安全の高いチームになるために
個に求められるマインド
● 仕事を実行の機会ではなく学習の
機会と捉える
● 自分が間違うということを認める
● 好奇心を形にし、積極的に質問す
る
引用
：https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/fo
ster-psychological-safety/
Slide 46
Slide 46 text
より良く仕事を進める方法をチームで思考する
ぬるま湯
言われたことを
やる
高ストレス
成長し続ける
心理的安全の高い状態
+
自分たちで考え、改善する必
要がある（責任）
の掛け合わせで、チームは
ラーニングゾーンにいることが
できる。
引用：『エンジニアリング組織論への招待』P.108
Slide 47
Slide 47 text
チームの学びの蓄積
チームでの学びはチーム内での経験によって積まれる。チームが
変わるとセットされる。
固定化されたチーム
流動的なチーム
時間
知識
時間
知識
Slide 48
Slide 48 text
まとめ
● クロスファンクショナルチームでチームの固定化
● PDCAサイクルの導入
を行いました。
心理的安全のあるチームになり
チームで適切な責任を持ってもらい
チームで学びを積み上げながら
チームで改善できるような状態を作るため
Slide 49
Slide 49 text
プロジェクトマネージメントの問題を解決
する
Slide 50
Slide 50 text
開発プロセス
Slide 51
Slide 51 text
開発プロセス(2020 年まで)
スプリント1
スプリント2
スプリント3
スプリント4
スプリント5
エピック1
エピック2
エピック3
エピック4
実装
単体テスト
実装
総合テスト
総合テスト
実装
総合テスト
実装
総合テスト
FF
CF
単体テスト
単体テスト
既存バグ
実装
総合テスト
単体テスト
再掲
Slide 52
Slide 52 text
開発プロセス(2021年1月から)
スプリント1
スプリント2
スプリント3
スプリント4
スプリント5
PBI1
PBI2
PBI3
PBI4
既存バグ
実装
単体テスト
実装
単体テスト
不具合対応
総合テスト
総合テスト
実装
単体テスト
総合テスト
実装
単体テスト
総合テスト
実装
単体テスト
総合テスト
FF
CF
Slide 53
Slide 53 text
● 大きな粒度のエピックから小さい粒度であるプロダクトバックロ
グアイテム(PBI)での完成を目指す。
● シフトレフトで、FFまでに単体テストの完了を目指す。
● 新機能に加えて、既存バグの対応を
バージョン開発開始時に計画する。
プロセス変更の意図
Slide 54
Slide 54 text
● プロダクトバックログアイテムの見積もり結果を使った
バージョンごとのバーンダウンチャートにより、
開発状況の見える化を実施。
● FFの1ヶ月前には、間に合わせることが厳しい機能を、
プロダクトオーナーに認識してもらえるようになった。
プロジェクトの遅延を早く検知できるように！
Slide 55
Slide 55 text
計画時の見積もり
Slide 56
Slide 56 text
● ディレクターが要件を決めた時期に、ロードマップを
作成するための人日見積もりをエンジニアが実施。
● 上記結果をもとにディレクターが、
1日単位で、ガントチャートを作成していた。
● 後から、仕様が変わったり、実装する機能が増えても、
納期が変わらず、プロジェクトを進めるには、不安定な状況。
見積もり方法(2020年まで)
機能A
機能C
機能B
実装7日間
実装3日間
実装10日間
例)ガントチャート
Slide 57
Slide 57 text
見積もりを以下の3つに分類
1. ロードマップを作成するための人日見積もり
○ 見積もり結果を納期としないことを関係者に周知
○ バッファを考慮したスケジューリングを実施
2. バージョンごとの作業量を求める相対見積もり
○ 進捗見える化のためバーンダウンチャートに利用
3. スプリントバックログを作るための人日見積もり
○ 日々のデイリースクラムで開発者が確認するために利用
見積もり方法(2021年1月から)
S
M
L
Slide 58
Slide 58 text
見積もり方法変更で事前のスケジュール調整ができるように！
● ロードマップ作成時、見積もりを考慮して、
開発する機能を選択するようになった！
見積もりに幅があることを認識し、
プロジェクトバッファを考慮して計画するように！
● 作業量を表す相対見積もりの結果を用いて、
各バージョンごとの状況を見える化！
バージョン間での優先度を考慮して
開発を進めるようになった！
Slide 59
Slide 59 text
目的
Slide 60
Slide 60 text
スケジュールの遅延に対する認識を変え、
変化を受け入れることで、
マネージメントコストを減らす
Slide 61
Slide 61 text
改善したいと思ったこと
自発的に改善を重ねられるチームになる
● 個、チームが成長に向かえる状態を作る
● PDCAサイクルを回し、積み重ねる状態を作る
プロジェクトマネージメントの問題を解決する
● 遅延を減らす & 遅延を早く検知する
● マネジメントコスト下げる
再掲
Slide 62
Slide 62 text
ディレクターが1日単位のガントチャートで
管理しているにも関わらず、
FFの1週間前に「間に合いません！」と
エンジニアから告げられる
発生していた不思議な現象①
Slide 63
Slide 63 text
FFより早く開発完了すると、
検証開始まで一定時間放置される新機能
● 毎回スケジュール終盤は忙しいにも関わらず、
スケジュールの中盤、手持ち無沙汰になるエンジニア
● 忘れた頃にバグチケットが起票されるので、
思い出すことから始める必要があるエンジニア
発生していた不思議な現象②
Slide 64
Slide 64 text
既存バグの対応がFFからCFの期間に限定されている
● 既存バグの修正見通しが立ちづらく、
新機能のバグ対応が優先されるため、
修正バージョンが以降のバージョンに送られ続ける
発生していた不思議な現象③
v1.0
v1.1
v1.2
入らないから
次へ！
今回も入らないから
次へ！
Slide 65
Slide 65 text
スケジュールが遅延するとは？
● プロジェクトにおいて、「スケジュールの遅延が
発生している」とは、どのような状況だろうか？
○ やるべきこと後から見つかってくる
○ バグなど手戻りが多く発生している
○ 差し込み作業で、メンバーがプロジェクトに入れない
etc
● 要するに、
「自分たちが立てた計画通りに、進んでいないこと」
Slide 66
Slide 66 text
そもそも計画を立てることの難しさ
● スケジュールの見積もりは、
初期に立てるほど、
ズレが大きくなりやすい。
● くわえて、見積もる人と
作る人が異なると、さらに見積
もりがずれるため、
計画の難易度が上がる。
引用：『アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～』 P.27
Slide 67
Slide 67 text
ゲームは、計画通りにできる領域？
引用：https://slide.meguro.ryuzee.com/slides/90#
Slide 68
Slide 68 text
全体を把握することの難しさ
引用：https://twitter.com/haradakiro/status/1415213883443220482
Slide 69
Slide 69 text
● ユーザー操作におけるテンポの良さ
● 初心者でもわかりやすい操作になっている
● ユーザーの目を引く演出になっている
etc
いくら綿密な計画を立てたとしても、
後から発見することが多く、
改善することが重要なのが、ゲーム開発
ゲームにおいて作ってみないとわからないこと
Slide 70
Slide 70 text
● プロダクトは完成し、一定の品質が担保されていることで世にリ
リースすることができる
● 多くの仕事に手を付けたとしても、
完成しない限り、リリースすることができない
● 仕掛品の数を少なくすることで、
小さくとも機能として完成した状態を目指す
仕事を始めるんじゃない！終わらせるんだ！
Slide 71
Slide 71 text
遠くの的ではなく、近くの的を狙い続ける
近くの的を繰り返し狙い続けることで、
精度の高い計画を立て続けることを目指す！
一度計画して終わりではなく、計画し続けることが重要
Check
Do
Plan
Do
Do
Do
Do
Do
Plan
時間
Check
Do
Plan
Check
Do
Plan
Check
Do
Plan
時間
Slide 72
Slide 72 text
短い期間で素早く検知する
取り組んだこと
● 2週間ごとに”動くソフトウェア”で、
プロダクトの状況を把握する
● 仕事をチケット化することで、
”あと何をすれば完了するのか？”を見える化する
自分たちの計画ではなく、
プロダクトの状況と残っている仕事に向き合う！
Slide 73
Slide 73 text
改善したいと思ったこと
自発的に改善を重ねられるチームになる
● 個、チームが成長に向かえる状態を作る
● PDCAサイクルを回し、積み重ねる状態を作る
プロジェクトマネージメントの問題を解決する
● 遅延を減らす & 遅延を早く検知する
● マネジメントコスト下げる
再掲
Slide 74
Slide 74 text
マネジメントコストが高い状況
Slide 75
Slide 75 text
最後にひっくり返ると、特にコストが高い
● 正確な計画を立てることは、そもそも難しい
● すべての仕事を最初に洗い出すことも難しい
● プロジェクト終盤に、ちゃぶ台返しが発生すると、
再計画時のコストが、非常に高くなる
最後にひっくり返らないように、
プロジェクト初期から
プロダクトを確認し続けることが重要
Slide 76
Slide 76 text
機能の中で優先順位を決める
機能の中で優先順位を決め、集中するべき点を定める
● リリースに必須な機能
● リリースに必須ではないが、できれば欲しい機能
● リリース時には不要、またはプロダクトとして不要な機能
全部やりきるのではなく、
どうすればリリースできるのかに焦点をあてる
特に、やらないことを決めることができると、
プロジェクト終盤でひっくり返りづらくなる。
Slide 77
Slide 77 text
変化を受け入れ、コストの低い状態を目指す
● マネジメントコストが0になることはない
● マネジメントコストが低い状態を保つことが重要
● プロダクト開発を通して得られた経験こそ重要な事実
計画通りに進むことを目指すのではなく、
プロダクト開発を通して得られた経験を
計画に組み込み続ける
Slide 78
Slide 78 text
導入に向けて行ったこと
Slide 79
Slide 79 text
LeSS導入までの1年間でやったこと
観察
1
1on1
MTG参加
ドキュメントを読む
不明点のヒアリング
対話
新規チーム全体へのLT（全16回くらい）
一部のメンバーを通しての対話
検証
1チームで小さく試す
試した結果を共有してもらう
2
3
Slide 80
Slide 80 text
LeSS導入までの1年間でやったこと
観察
1
1on1
MTG参加
ドキュメントを読む
不明点のヒアリング
対話
新規チーム全体へのLT（全16回くらい）
一部のメンバーを通しての対話
検証
1チームで小さく試して共有してもらう
2
3
Slide 81
Slide 81 text
① 観察 1on1
ヒアリング内容
● やっていること、困っていること、改善したい
と思っていること
立場の異なるメンバーから幅広く
チームの雰囲気もつかめる
否定せず、相手の立場や考えを理解する
『他者と働く』P.43
Slide 82
Slide 82 text
② 新規チーム全体へのLT
As is
To be
GAP
解決策
LT第1部
LT第1部
LT第2部
Slide 83
Slide 83 text
② 新規チーム全体へのLT 第1部
チームについて
● HRT
● 心理的安全
● 自己組織化
プロセスについて
● 不確実性
● 効率
● 計画づくり、見積もり
Slide 84
Slide 84 text
② 一部のメンバーを通しての対話
全員と対話をするのは難しいので、LTに対してFBをくれた方を中心
に対話をした。
彼らが後に、他のメンバーに伝えていってくれている。
引用：https://ncase.me/crowds/ja.html
Slide 85
Slide 85 text
③ 1チームで小さく試して共有してもらう
スプリントプランニング
● みんなで見積もり
● 相対見積もり
スプリントレトロスペクティブ
● スプリント期間にフォーカスした振り返り
● 想定通りに進まなかった理由の深堀り
Slide 86
Slide 86 text
なぜこのやり方にしたのか
● 仕事の進め方が複雑になっていて、
まず体制を変えないと、チームが変
化していくのは難しいと考えた
● 目的を理解し、納得して変化しなけれ
ばいずれ形骸化してしまう
● 自分の考えを伝えつつ、メンバーとの
対話の時間を作りたい
Slide 87
Slide 87 text
これから目指していきたいこと
Slide 88
Slide 88 text
チャレンジを経て、チームの課題が変わった
これまでの話題の中心
直近のリリースまでを
どのように進めるか
これから目指したいこと
価値提供に着目していく
● なぜこれを届けたいのか
● 届けた結果どうだったのか
● 価値をより早く届けよう
Slide 89
Slide 89 text
なぜ？と結果を理解する意味
● チームの内発的モチベーション、自主性の向上
● 課題を仮説立て、ユーザーの反応を見て、次の打ち手を決める
引用：https://mobiusloop.com/
Slide 90
Slide 90 text
価値をより早く届けよう
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
①
②
Slide 91
Slide 91 text
価値をより早く届けよう
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
リリース
①
②
Slide 92
Slide 92 text
価値をより早く届けよう
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
①
②
Slide 93
Slide 93 text
価値をより早く届けよう
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
リリース
リリース
①
②
リリース
Slide 94
Slide 94 text
価値をより早く届けよう
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
リソース効率
できる人ができることをやる。リソースをムダなく利用する
フロー効率
優先度に沿って上から着手。リリースまでのリードタイムが短い
①
②
Slide 95
Slide 95 text
価値をより早く届けよう
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
リソース効率
できる人ができることをやる。リソースをムダなく利用する
フロー効率
それぞれ助け合いながらタスクを割り振りする。リリースまでのリードタイムが短い
①
②
Slide 96
Slide 96 text
価値をより早く届けよう
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
リソース効率
できる人ができることをやる。リソースをムダなく利用する
フロー効率
それぞれ助け合いながらタスクを割り振りする。リリースまでのリードタイムが短い
①
②
Slide 97
Slide 97 text
価値をより早く届けよう
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タスクごとの進捗は見えづらく、
マネジメントコストも高く、リリースが遅い。
優先度の高いものから着手・リリースしていく。
やっていること、進捗が見やすく
マネジメントコストが低く、リリースが早い。
①
②
Slide 98
Slide 98 text
価値をより早く届けよう
ゲームは、リリースして初めてユーザーに価値提供ができて、売上
にもつながる。なので、リリースを早くしていきたい。
内部で決めた計画どおりに作業が進むかは、ユーザーや事業に
とっては、実はそれほど大事なことではないこともある。
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
リリース
リリース
②
リリース
Slide 99
Slide 99 text
具体的に取り組んでいきたいこと
Slide 100
Slide 100 text
No content
Slide 101
Slide 101 text
優先度の高い機能からリリースする
Slide 102
Slide 102 text
提供価値を理解し、振り返れるようになる
ロードマップや機能単位で、どのようなユーザーアウトカムやKPIを
狙っているのかを分かるようにし、
リリース後に結果を振り返る。
引用：https://note.com/ozyozyo/n/nfb370fadd70c
Slide 103
Slide 103 text
まとめ
Slide 104
Slide 104 text
課題とやったこと
自発的に改善を重ねられるチームになる
心理的安全の土台の構築 & 適切なPDCAサイクルの導入で、声を
上げやすい、改善が動きやすい組織づくり
プロジェクトマネージメントの問題を解決する
不確実性を考慮した、短スパン & 動くプロダクトをベースにした進
捗把握で、問題を早期検知するプロセスの構築
Slide 105
Slide 105 text
これからやること
提供価値に着目する
なぜを意識できる計画づくりと、結果の振り返り
フロー効率の高い開発プロセスにより、早い価値提供を
Slide 106
Slide 106 text
良いものを、みんなで、どんどん届けるぞ！
ご清聴ありがとうございました