Slide 1

Slide 1 text

なんとなくチームを構成することから 脱却する⽅法 アカツキ 湯前 慶⼤

Slide 2

Slide 2 text

2 湯前 慶⼤(ゆのまえ よしひろ) @yunon_phys ・2010~2014(電気メーカー) R & D of Linux カーネル ・2014~(アカツキ) VP of Engineering プロジェクトマネージャー, スクラムマスター

Slide 3

Slide 3 text

3 良いチーム、 作れていますか?

Slide 4

Slide 4 text

4 良いチーム構成、 作れていますか?

Slide 5

Slide 5 text

5 チーム構成はトレードオフの関係

Slide 6

Slide 6 text

6 事例: アカツキのゲーム開発プロジェクト 拠点A 拠点B 各拠点で閉じて開発するのが良いのか? 混ぜて開発するのが良いのか?

Slide 7

Slide 7 text

7 ⽅向性の認識が合いやすい コミュニケーション コスト増⼤ チーム間の整合性 チームを分断すべきか、統合すべきか チーム内の認識すり合わせ

Slide 8

Slide 8 text

8 ⽅向性の認識が合いやすい コミュニケーション コスト増⼤ チーム間の整合性 チームを分断すべきか、統合すべきか チーム内の認識すり合わせ 別の手段 で担保

Slide 9

Slide 9 text

9 PO Area PO Area PO ü ユーザーストーリーをPO同⼠ですり合わせ、受け⼊れ基準の明確化 ü Howは各拠点に任せる

Slide 10

Slide 10 text

10 PO Area PO Area PO ü ユーザーストーリーをPO同⼠ですり合わせ、受け⼊れ条件の明確化 ü Howは各拠点に任せる しかし、これだけでは終わらなかった

Slide 11

Slide 11 text

11 ソーシャルゲームの特徴 üリリースしてからが本番

Slide 12

Slide 12 text

12 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊

Slide 13

Slide 13 text

13 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊 üバイナリアップデート⾟い

Slide 14

Slide 14 text

14 ソーシャルゲームの特徴 üリリースしてからが本番 ü運⽤はノウハウの塊 üバイナリアップデート⾟い üイケてない⾮機能が真綿で ⾸を絞めてくる

Slide 15

Slide 15 text

15 考えなければいけないこと 運⽤どちらがやる? 開発項⽬どう わける? 同じソースを触っ て問題がおきたら どうしよう ⾮機能開発どちら がやる? 採⽤難易度??

Slide 16

Slide 16 text

16 コンテンツ更新必要 コンテンツ更新不要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 ひとまず観点整理(図解思考法)

Slide 17

Slide 17 text

17 運⽤の経験あり ⼀から施策を考えた 運⽤の経験なし こちらが運用を担当する

Slide 18

Slide 18 text

18 コンテンツ更新必要 コンテンツ更新不要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤

Slide 19

Slide 19 text

19 コンテンツ更新必要 コンテンツ更新不要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ 実は運用経験に深く 関わりがある

Slide 20

Slide 20 text

20 コンテンツ更新必要 コンテ ンツ更 新不 要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ コンテンツ更新 不要 運⽤ (⾮機能開発) 運用チームにスイッチ

Slide 21

Slide 21 text

21 コンテンツ更新必要 コンテ ンツ更 新不 要 ソース コード 更新不要 機能追加・改修 非機能追加・ 改修 バイナリ改修不要 バイナリ改修必要 バイナリ 改修不要 運⽤ ⾮運⽤ コンテンツ更新 不要 運⽤ (⾮機能開発) 分断箇所は コミュニケーションに 課題あり

Slide 22

Slide 22 text

22 発⽣しうる問題 üPOが全てを 把握するのが ⼤変 üどちらが担 当なのかわか りづらい PO Area PO Area PO

Slide 23

Slide 23 text

23 機能パートで分類 ログインボーナス プレゼント受け取り ガチャ 育成 クエスト 運⽤施策に 強く依存

Slide 24

Slide 24 text

24 その他コミュニケーションでカバー ü双⽅のPRレビュー ü週1回のお困りごとの共有 ü週1回の出来たものチェック üリアルのつながり ※ 絶賛改善中!

Slide 25

Slide 25 text

25 ここまでのまとめ ü良いチーム構成のために 課題を明らかにする ü課題がごちゃごちゃしてき たら、図で⽰して何が分断 されたのかを理解するとわ かりやすい

Slide 26

Slide 26 text

26 他社事例

Slide 27

Slide 27 text

27 Quipper社の例(改善前) toC toB ü エンジニア5~10⼈規模の頃は各々が全てのドメインを⾒ていたが、 各事業領域が⼤きく、ステークホルダーが増えるにつれて難しく なった ü ステークホルダーは誰に会話すれば良いかわからない エンジニア

Slide 28

Slide 28 text

28 Quipper社の例(改善後) toC toB ü ドメインごとにチームを分割 ü ドメイン知識が深くなり、ステークホルダーとエンジニアの 信頼関係を構築しやすくなった ü チーム横断の解決が難しくはなった Eng Eng Eng Eng Eng

Slide 29

Slide 29 text

29 toC toB 整合性 エンジニア ドメイン知識が 深くなる Quipper社の例(図解思考法)

Slide 30

Slide 30 text

30 エウレカ社の例(改善前) PJT A PJT B PJT C iOS Android Web iOS Android Web iOS Android Web ü featureチーム ü プラットフォーム(PF: iOS/Android/Web)間の整合性を気にする あまり、PFごとの品質が上がらず

Slide 31

Slide 31 text

31 エウレカ社の例(改善後) PJT A PJT B PJT C iOS Android Web CTO VPoP ü Componentチーム ü 各職能がPFごとのクオリティを⾼める ü 各職能のマネージャーはいろいろなPJTをふらふらする ü VPoPが最終アウトプットの整合性を担保する

Slide 32

Slide 32 text

32 iOS Android Web 整合性 整合性 プロダクトの整合性 VPoPや各職能のマネージャーが担保 エウレカ社の例(図解思考法)

Slide 33

Slide 33 text

33 某映像系会社の例(改善前) ü プロダクトに⼈をアサイン ü 個⼈のスキルでベストエフォート ü 兼任業務があるため同時着⼿が出来ず、全体的に優先順位が 最適化されていない プロダクト A プロダクト B プロダクト C プロダクト D 鈴木さん 佐藤さん 田中さん

Slide 34

Slide 34 text

34 某映像系会社の例(改善後) ü 全体のプロダクトバックログを作成 ü 全体を⾒ているPOが負荷度合いを加味して、うまいこと振り分け ü 様々なタスクが降ってくるので、スキルが平準化 ü POの負荷が⾼い状態に 1. A向けの機能 2. B向けの改修 3. D向けの修正 4. A向けの改修 5. C向けの改修 PO Area PO1 Area PO2 PBL

Slide 35

Slide 35 text

35 良いチーム構成のためのポイント ü課題や達成したいことを 明らかにする ü⼀般論は参考にしかならない ü考えうるベストを採⽤する ü観察を怠らない ü変化を受け⼊れる

Slide 36

Slide 36 text

36