モバイルゲーム事業で大規模スクラム（LeSS）を導入するまでの1年間とその後 / CEDEC2021

CEDEC2021登壇資料です。

Transcript

1. 株式会社アカツキ 石毛琴恵、増田謙太郎 モバイルゲーム事業で
 大規模スクラム（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
5. ©Akatsuki Inc. 5 事業だけではなく”組織のあり方”も変化を追及し、 創造性が発揮され続ける組織を目指します。 組織の価値観 個々を自立した存在として信頼すること を出発点に、組織のシステムを構築す る。 信頼と自立 規律と制約を設けることで自由と裁量を 明確にし、創造性と主体性を引き出す。 規律と創造 挑戦と失敗を恐れない一方で計画と学 習に情熱を注ぎ、組織単位で進化し続 ける。 挑戦と学習
6. 1
 2
 3
 4
 LeSS導入前の状態
 導入に向けて行ったこと
 やったことと変化
 これから目指していきたいこと
 目次

7. LeSS導入前の状態

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

9. プロジェクトの全体構成
 新規チーム エンジニアリングが必要な変更 （機能改修、機能追加） 運用チーム エンジニアリングが不要な変更 （イベント追加、ガチャ更新等） Project
 新規チーム エンジニアリングが必要な変更 （機能改修、機能追加等） こちらのチームでの 
 お話をします

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

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

12. 導入前の状態

13. 導入前の状態
 全体統括
 何をいつリリースするか 
 （ロードマップ）
 最終意思決定者

14. 導入前の状態
 バージョンのスケジュール、スコープ 
 各機能のWHY、WHAT 

15. 導入前の状態
 複数バージョン同 時に
 開発や検証

16. 導入前の状態
 ディレクターの進捗管理の補佐 
 コミュニケーションハブ 

17. 導入前の実装・検証の流れ
 エピック1
 エピック2
 エピック3
 エピック4
 実装
 単体テスト
 実装
 総合テスト
 総合テスト
 実装
 総合テスト
 実装
 総合テスト
 FF(Feature Freeze) 
 CF(Code Freeze)
 単体テスト
 単体テスト
 既存バグ
 実装
 総合テスト
 単体テスト

18. すごく良いチーム！
 
 
 
 
 
 
 
 
 
 
 • リリースするために自分がすべきことを考えて動いている
 • セクショナリズムな対立がない
 • チームを大事にする文化が強い
 

19. 課題意識
 自発的な改善を求めたい
 • リーダーなど、ハブとなるメンバーに頼りがち
 • PDCAサイクルが回っていない
 
 スケジュール管理が大変だが、遅延する
 • マネジメントコストが高い
 • スケジュールの終盤になってから遅延が発覚する

20. 改善したいと思ったこと
 自発的に改善を重ねられるチームになる
 • 個やチームが成長に向かえる状態を作る
 • PDCAサイクルを回し、積み重ねる状態を作る
 
 プロジェクトマネージメントの問題を解決する
 • 遅延を減らす & 遅延を早く検知する
 • マネジメントコスト下げる

21. LeSSやろう！

22. スクラムとは
 スクラムは
 • 3つの作成物
 • 3つのロール
 • 5つのイベント
 など最低限のルールの セットで
 構成されています。
 
 引用：『SCRUM BOOT CAMP THE BOOK【増補改訂版】』P.28 

23. LeSSとは
 スクラムをシンプルに拡張したフレームワークと言われる。
 • 全体で1つのプロダクトバックログ
 • 複数の開発チーム
 

24. やったことと変化

25. 自発的に改善を重ねられるチームになる

26. 以前
 流動的なメンバーアサイン
 現在
 クロスファンクショナルなチームでの固定化
 体制の変更

27. チームごとにスクラムイベントを実施
 毎日

30. • コミュニケーションの量が増え、気 軽な相談がしやすくなった
 • セクションを越えて、開発時に気 をつけること、考え方が共有され るようになった！
 • 課題が上がるようになってきた
 クライアントエンジニア QA サーバー エンジニア チーム内のコミュニケーションが活性化
 わい わい がや がや
31. ペア・モブプロやワークが活性化
 • ペアプロやモブプロが増えた
 • QAメンバーのペア・モブワークも始 まった
 • 試してみた結果、属人的なタスクを減 らしていきたいという声の増加
 • 協働作業でレビューを含めているの で、完了スピードUP

32. （+α）チーム内コミュニケーション
 デイリースクラム前の短い雑談
 テーマを定めた雑談
 自己開示や他者理解
 やり方はチームの中で考えて実施
 
 チームランチやディナー
 各チーム自由に。
 ゲームしたり、おしゃべりしたり。

33. （+α）チームを超えたコミュニケーション
 ① ② ①新規チーム全体
 ・仕事の進め方への課題をディ スカッションする自由参加の場 （YYスクラム）
 ・シャッフルランチ
 
 ②セクションごと
 セクションリーダーを中心に
 ・情報共有、課題発見
 ・育成、学習

34. 目的

35. 自発的な改善をしやすく、
 改善を積み重ねやすくするための土台づくり

36. 議論や高め合いのできるチームになりたい
 自発的な改善ができるとは
 
 課題を、衝突を恐れずメンバーに 公開することができ、
 議論ができ、
 意思決定ができ、
 実行できる人やチームになること。
 気軽に話せる
 相談ができる
 議論ができる
 難易度

37. 議論や高め合いのできるチームになりたい
 その状態になるためには土台が必 要。
 
 実際にたどり議論ができるようにな るかはメンバー次第だが、
 土台作りでサポートできる。
 
 気軽に話せる
 相談ができる
 議論ができる
 難易度

38. お互いのことを知ることが大事
 自分のこと 他人のこと
39. お互いのことを知ることが大事
 自分のこと 他人のこと 業務外 業務
40. お互いを知る = 自己開示とフィードバック
 自己開示とフィードバックのサイク ルを回していくことで、相互理解が 深まる
 
 • 雑談
 • 価値観ポーカー
 • ドラッガー風エクササイズ
 • 自己紹介・他己紹介ワーク
 引用：https://qiita.com/hirokidaichi/items/5d8c4294083d85654a04 

41. 主体性を持ちやすい状態とは
 対人関係においてリスクある行動を取っ たときの結果に対する個人の認知の仕 方、つまり、「無知、無能、ネガティブ、邪 魔だと思われる可能性のある行動をして も、このチームなら大丈夫だ」と信じられる かどうか
 引用 ：https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/identify-dyn amics-of-effective-teams/ 

42. 心理的安全のない組織で起こること
 このように 見られたくない 行動 発生する問題 無知 質問をしない 作業の非効率（大きな手戻 り、作業遅延） 無能 失敗を隠す、認めない 何度も同じ失敗が起きる ネガティブ 意見を言わない 解決しない 邪魔 アイデアを提案しない 改善しない
43. 居場所があるから安心して力が発揮できる
 「個として、チームとして成長していく こと」に目を向けてもらうために
 大前提必要な土台を整える必要があ る。
 引用：https://dime.jp/genre/912205/ 

44. 議論や高め合いのできるチームになりたい
 その状態になるためには土台が必 要。
 
 実際に議論ができるようになるか はメンバー次第だが、
 土台作りでサポートできる。
 
 気軽に話せる
 相談ができる
 議論ができる
 難易度

45. より心理的安全の高いチームになるために
 個に求められるマインド
 
 • 仕事を実行の機会ではなく学習の 機会と捉える
 • 自分が間違うということを認める
 • 好奇心を形にし、積極的に質問す る
 引用 ：https://rework.withgoogle.com/jp/guides/understanding-team-effectiveness/steps/fo ster-psychological-safety/ 

46. より良く仕事を進める方法をチームで思考する
 ぬるま湯
 言われたことを やる
 高ストレス
 成長し続ける
 心理的安全の高い状態
 +
 自分たちで考え、改善する必 要がある（責任）
 
 の掛け合わせで、チームは ラーニングゾーンにいることが できる。
 引用：『エンジニアリング組織論への招待』P.108 

47. チームの学びの蓄積
 チームでの学びはチーム内での経験によって積まれる。チームが 変わるとセットされる。
 固定化されたチーム
 流動的なチーム
 時間
 知識
 時間
 知識

48. まとめ
 • クロスファンクショナルチームでチームの固定化
 • PDCAサイクルの導入
 を行いました。
 
 心理的安全のあるチームになり
 チームで適切な責任を持ってもらい
 チームで学びを積み上げながら
 チームで改善できるような状態を作るため

49. プロジェクトマネージメントの問題を解決 する

50. 開発プロセス

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

52. 開発プロセス(2021年1月から)
 スプリント1
 スプリント2
 スプリント3
 スプリント4
 スプリント5
 PBI1
 PBI2
 PBI3
 PBI4
 既存バグ
 実装
 単体テスト
 実装
 単体テスト
 不具合対応
 総合テスト
 総合テスト
 実装
 単体テスト
 総合テスト
 実装
 単体テスト
 総合テスト
 実装
 単体テスト
 総合テスト
 FF
 CF

53. • 大きな粒度のエピックから小さい粒度であるプロダクトバックロ グアイテム(PBI)での完成を目指す。
 • シフトレフトで、FFまでに単体テストの完了を目指す。
 • 新機能に加えて、既存バグの対応を
 バージョン開発開始時に計画する。
 プロセス変更の意図

54. • プロダクトバックログアイテムの見積もり結果を使った
 バージョンごとのバーンダウンチャートにより、
 開発状況の見える化を実施。
 • FFの1ヶ月前には、間に合わせることが厳しい機能を、
 プロダクトオーナーに認識してもらえるようになった。
 プロジェクトの遅延を早く検知できるように！

55. 計画時の見積もり

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

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

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

59. 目的

60. スケジュールの遅延に対する認識を変え、
 変化を受け入れることで、
 マネージメントコストを減らす

61. 改善したいと思ったこと
 自発的に改善を重ねられるチームになる
 • 個、チームが成長に向かえる状態を作る
 • PDCAサイクルを回し、積み重ねる状態を作る
 
 プロジェクトマネージメントの問題を解決する
 • 遅延を減らす & 遅延を早く検知する
 • マネジメントコスト下げる
 再掲

62. ディレクターが1日単位のガントチャートで
 管理しているにも関わらず、
 FFの1週間前に「間に合いません！」と
 エンジニアから告げられる
 発生していた不思議な現象①

63. FFより早く開発完了すると、
 検証開始まで一定時間放置される新機能
 • 毎回スケジュール終盤は忙しいにも関わらず、
 スケジュールの中盤、手持ち無沙汰になるエンジニア
 • 忘れた頃にバグチケットが起票されるので、
 思い出すことから始める必要があるエンジニア
 発生していた不思議な現象②

64. 既存バグの対応がFFからCFの期間に限定されている
 • 既存バグの修正見通しが立ちづらく、
 新機能のバグ対応が優先されるため、
 修正バージョンが以降のバージョンに送られ続ける
 発生していた不思議な現象③
 v1.0
 v1.1
 v1.2
 入らないから 次へ！ 今回も入らないから 次へ！
65. スケジュールが遅延するとは？
 • プロジェクトにおいて、「スケジュールの遅延が
 発生している」とは、どのような状況だろうか？
 ◦ やるべきこと後から見つかってくる
 ◦ バグなど手戻りが多く発生している
 ◦ 差し込み作業で、メンバーがプロジェクトに入れない
 etc
 • 要するに、
 「自分たちが立てた計画通りに、進んでいないこと」

66. そもそも計画を立てることの難しさ
 • スケジュールの見積もりは、 初期に立てるほど、
 ズレが大きくなりやすい。
 • くわえて、見積もる人と
 作る人が異なると、さらに見積 もりがずれるため、
 計画の難易度が上がる。
 引用：『アジャイルな見積りと計画づくり ～価値あるソフトウェアを育てる概念と技法～』 P.27
67. ゲームは、計画通りにできる領域？
 引用：https://slide.meguro.ryuzee.com/slides/90#
68. 全体を把握することの難しさ
 引用：https://twitter.com/haradakiro/status/1415213883443220482
69. • ユーザー操作におけるテンポの良さ
 • 初心者でもわかりやすい操作になっている
 • ユーザーの目を引く演出になっている
 etc
 
 いくら綿密な計画を立てたとしても、
 後から発見することが多く、
 改善することが重要なのが、ゲーム開発
 ゲームにおいて作ってみないとわからないこと

70. • プロダクトは完成し、一定の品質が担保されていることで世にリ リースすることができる
 • 多くの仕事に手を付けたとしても、
 完成しない限り、リリースすることができない
 • 仕掛品の数を少なくすることで、
 小さくとも機能として完成した状態を目指す
 仕事を始めるんじゃない！終わらせるんだ！

71. 遠くの的ではなく、近くの的を狙い続ける
 近くの的を繰り返し狙い続けることで、
 精度の高い計画を立て続けることを目指す！
 一度計画して終わりではなく、計画し続けることが重要
 Check Do Plan Do Do Do Do Do Plan 時間 Check Do Plan Check Do Plan Check Do Plan 時間
72. 短い期間で素早く検知する
 取り組んだこと
 • 2週間ごとに”動くソフトウェア”で、
 プロダクトの状況を把握する
 • 仕事をチケット化することで、
 ”あと何をすれば完了するのか？”を見える化する
 
 自分たちの計画ではなく、
 プロダクトの状況と残っている仕事に向き合う！

73. 改善したいと思ったこと
 自発的に改善を重ねられるチームになる
 • 個、チームが成長に向かえる状態を作る
 • PDCAサイクルを回し、積み重ねる状態を作る
 
 プロジェクトマネージメントの問題を解決する
 • 遅延を減らす & 遅延を早く検知する
 • マネジメントコスト下げる
 再掲

74. マネジメントコストが高い状況

75. 最後にひっくり返ると、特にコストが高い
 • 正確な計画を立てることは、そもそも難しい
 • すべての仕事を最初に洗い出すことも難しい
 • プロジェクト終盤に、ちゃぶ台返しが発生すると、
 再計画時のコストが、非常に高くなる
 
 最後にひっくり返らないように、
 プロジェクト初期から
 プロダクトを確認し続けることが重要

76. 機能の中で優先順位を決める
 機能の中で優先順位を決め、集中するべき点を定める
 • リリースに必須な機能
 • リリースに必須ではないが、できれば欲しい機能
 • リリース時には不要、またはプロダクトとして不要な機能
 
 全部やりきるのではなく、
 どうすればリリースできるのかに焦点をあてる
 特に、やらないことを決めることができると、
 プロジェクト終盤でひっくり返りづらくなる。

77. 変化を受け入れ、コストの低い状態を目指す
 • マネジメントコストが0になることはない
 • マネジメントコストが低い状態を保つことが重要
 • プロダクト開発を通して得られた経験こそ重要な事実
 
 計画通りに進むことを目指すのではなく、
 プロダクト開発を通して得られた経験を
 計画に組み込み続ける

78. 導入に向けて行ったこと

79. LeSS導入までの1年間でやったこと
 観察
 1
 1on1
 MTG参加
 ドキュメントを読む
 不明点のヒアリング
 対話
 新規チーム全体へのLT（全16回くらい）
 一部のメンバーを通しての対話
 検証
 1チームで小さく試す
 試した結果を共有してもらう
 2
 3

80. LeSS導入までの1年間でやったこと
 観察
 1
 1on1
 MTG参加
 ドキュメントを読む
 不明点のヒアリング
 対話
 新規チーム全体へのLT（全16回くらい）
 一部のメンバーを通しての対話
 検証
 1チームで小さく試して共有してもらう
 2
 3

81. ① 観察 1on1
 ヒアリング内容
 • やっていること、困っていること、改善したい と思っていること
 
 立場の異なるメンバーから幅広く
 チームの雰囲気もつかめる
 否定せず、相手の立場や考えを理解する
 『他者と働く』P.43 

82. ② 新規チーム全体へのLT
 As is
 To be
 GAP
 解決策
 LT第1部
 LT第1部
 LT第2部

83. ② 新規チーム全体へのLT 第1部
 チームについて
 • HRT
 • 心理的安全
 • 自己組織化
 
 プロセスについて
 • 不確実性
 • 効率
 • 計画づくり、見積もり

84. ② 一部のメンバーを通しての対話
 全員と対話をするのは難しいので、LTに対してFBをくれた方を中心 に対話をした。
 彼らが後に、他のメンバーに伝えていってくれている。
 引用：https://ncase.me/crowds/ja.html 

85. ③ 1チームで小さく試して共有してもらう
 スプリントプランニング
 • みんなで見積もり
 • 相対見積もり
 
 スプリントレトロスペクティブ
 • スプリント期間にフォーカスした振り返り
 • 想定通りに進まなかった理由の深堀り

86. なぜこのやり方にしたのか
 • 仕事の進め方が複雑になっていて、 まず体制を変えないと、チームが変 化していくのは難しいと考えた
 
 • 目的を理解し、納得して変化しなけれ ばいずれ形骸化してしまう
 
 • 自分の考えを伝えつつ、メンバーとの 対話の時間を作りたい

87. これから目指していきたいこと

88. チャレンジを経て、チームの課題が変わった
 これまでの話題の中心
 直近のリリースまでを
 どのように進めるか
 
 これから目指したいこと
 価値提供に着目していく
 • なぜこれを届けたいのか
 • 届けた結果どうだったのか
 • 価値をより早く届けよう

89. なぜ？と結果を理解する意味
 • チームの内発的モチベーション、自主性の向上
 • 課題を仮説立て、ユーザーの反応を見て、次の打ち手を決める　
 引用：https://mobiusloop.com/ 

90. 価値をより早く届けよう
 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
 ①
 ②

91. 価値をより早く届けよう
 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
 リリース
 ①
 ②

92. 価値をより早く届けよう
 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
 ①
 ②

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
 すべてが着手されて進んでいるように見えて安心感がある。 
 でも実は、1タスクごとの進捗は見えづらく、 
 マネジメントコストも高く、リリースが遅い。 
 優先度の高いものから着手・リリースしていく。 
 やっていること、進捗が見やすく 
 マネジメントコストが低く、リリースが早い。 
 ①
 ②

98. 価値をより早く届けよう
 ゲームは、リリースして初めてユーザーに価値提供ができて、売上 にもつながる。なので、リリースを早くしていきたい。
 内部で決めた計画どおりに作業が進むかは、ユーザーや事業に とっては、実はそれほど大事なことではないこともある。
 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
 リリース
 リリース
 ②
 リリース

99. 具体的に取り組んでいきたいこと

101. 優先度の高い機能からリリースする

102. 提供価値を理解し、振り返れるようになる
 ロードマップや機能単位で、どのようなユーザーアウトカムやKPIを 狙っているのかを分かるようにし、
 リリース後に結果を振り返る。
 引用：https://note.com/ozyozyo/n/nfb370fadd70c
103. まとめ

104. 課題とやったこと
 自発的に改善を重ねられるチームになる
 心理的安全の土台の構築 & 適切なPDCAサイクルの導入で、声を 上げやすい、改善が動きやすい組織づくり
 
 プロジェクトマネージメントの問題を解決する
 不確実性を考慮した、短スパン & 動くプロダクトをベースにした進 捗把握で、問題を早期検知するプロセスの構築

105. これからやること
 提供価値に着目する
 なぜを意識できる計画づくりと、結果の振り返り
 フロー効率の高い開発プロセスにより、早い価値提供を

106. 良いものを、みんなで、どんどん届けるぞ！
 
 
 ご清聴ありがとうございました