なんとなくチームを構成することから脱却する方法 / Clean Teams

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バイナリ改修必要バイナリ改修不要運⽤⾮運⽤

バイナリ改修必要バイナリ改修不要運⽤⾮運⽤実は運用経験に深く関わりがある

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

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

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

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

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

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

26 他社事例

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

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

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

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

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

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

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

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

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

なんとなくチームを構成することから脱却する方法 / Clean Teams

なんとなくチームを構成することから脱却する方法 / Clean Teams

More Decks by Yoshihiro Yunomae

Other Decks in Technology

Featured

Transcript