作ります

1. ジリツ的なチームの作り方
株式会社リクルートマーケティングパートナーズ

2. 自己紹介
名前： 犬の光@soplana
経歴： SIer -> スタートアップ -> 現在、RMPでエンジニア組織のマネージャー
技術： Ruby, JS, Java, AWS, vim, ethereum, デザイン・フロント周りが一番得意
趣味： 読書、プログラミング、ゲーム、YouTube、インターネット

3. そもそもジリツとは何か
・自律： 他からの支配や助力を受けず，自分の行動を自分の立てた規律に
従って正しく規制すること
・自立： 他の助けや支配なしに自分一人の力だけで物事を行うこと

4. では、ジリツ的なチームとは何か？

5. プロダクト開発における、ジリツの段階
長期的なビジョンが描けて、ロードマップを考える事が出来る
↓
中長期的なKGI・KPIを描けて、施策を考える事が出来る
↓
施策に対して、技術選定、実装方法等を考え実装する事が出来る
↓
決まった技術、実装方法の中でコーディングする事が出来る
今日はこの辺りの話
ジリツ的
非ジリツ的

6. ジリツ的なチームがなぜ必要か？

7. 「人はイノベーションを『良いアイデアを有することだ』と考えるが、イ
ノベーションの多くは、すばやく動き、多くを試すことを意味する」
“People think innovation is just having a good idea but a lot of it is just
moving quickly and trying a lot of things.”
By マーク・ザッカーバーグ

8. 「失敗」の重要性
・「達成・成功」への近道は柔軟な失敗の積み重ねである
・ 失敗を積み重ねるスピードは、エンジニアが圧倒的に一番早い

9. どうやってジリツ的なチームを作るのか？

10. プロダクト開発における、ジリツの段階
長期的なビジョンが描けて、ロードマップを考える事が出来る
↓
中長期的なKGI・KPIを描けて、施策を考える事が出来る
↓
施策に対して、技術選定、実装方法等を考え実装する事が出来る
↓
決まった技術、実装方法の中でコーディングする事が出来る
← まずはここの話
『KPIチーム編』

11. KPIチーム編

12. KPIチームを作るための2つのポイント
・適切なKPIツリーを作る事
・適切な権限委譲が行えている事

13. 適切なKPIツリーを作る（ココが一番大変）
アプリ
課金
アプリ
Install
流入
売上
新規プレミアム会員数
既存プレミアム会員数
表示数（経路：ストア内
）
表示数（経路：ストア外
）
新規訪問
再訪問

14. 適切な権限委譲（の例）
アプリ
課金
アプリ
Install
流入
売上
新規プレミアム会員数
既存プレミアム会員数
表示数（経路：ストア内
）
表示数（経路：ストア外
）
新規訪問
再訪問
このKPI粒度で3チームを編成

15. 適切な権限委譲
アプリ
課金
アプリ
Install
流入
売上
新規プレミアム会員数
既存プレミアム会員数
表示数（経路：ストア内
）
表示数（経路：ストア外
）
新規訪問
再訪問
・ チームやメンバーの実力に合わせた粒度で、KPIに対する責任を持ってもらう
・ 何をやるべきか、何をモニタリングするべきか、担当領域の数字を形成する
KPIツリーはどうなっていて、どこに注力するべきか、は自分で考えてもらう
・ 納期ではなく、担当領域の数字に対して厳しくする
・ 勿論実装までチームのエンジニアで行う

16. KPIチーム運用イメージ
・ 週に一度30 ~ 45分程、プロダクト責任者が同席するミーティングを行う
・ その中でモニタリング報告、先週やったこと、今週やること、中期的な
ロードマップの再確認等を行う
・ 全ての施策に対してコンセンサスを取る必要はない

17. KPIチームは何が良いのか？

18. KPIチームのメリット
・ 自分で考え、自分で実装し、自分で失敗と成功を判断できるので圧倒的に早い
・ 担当領域に対する当事者意識が目に見えて高まる
・ 視座とスキルが成長し、次世代のリーダーが育つ

19. KPIチームを運営する上での課題

20. 課題を大別
・ 数字が絶対的になりすぎる問題
・ リソースの問題

21. 課題を大別
・ 数字が絶対的になりすぎる問題
・ リソースの問題
・ 一度決めたKPIが絶対的になりがち
・ 数字の深掘りをしすぎて、手が動いてない状況にな
りがち
・ 局所最適な施策を打ちがち
・ 非連続的な成長が期待できるような、大胆な施策が
出てこなくなりがち

22. 課題を大別
・ 数字が絶対的になりすぎる問題
・ リソースの問題
・ KPIに紐付かない・曖昧な案件に対応するリソース
がいなくなりがち（バグ対応、負荷対策、ユーザ問
い合わせ対応などなど….）
・ 各チームが人手不足になる可能性が高い
（iOSエンジニアがいないチームなどなど…）

23. 余談として・・・
ジリツ的なチームになることで、問題もジリツ的に発生するようになった

24. 課題への対処
・ 数字が絶対的ではない
・ 横断チームを作る

25. 課題への対処
・ 数字が絶対的ではない
・ 横断チームを作る
・ KPIは可変である
・ 何より失敗を繰り返すのが最優先
・ 全体を俯瞰している視座からのアドバイス
・ 守破離。数字に縛られすぎない、非連続的な施策
も大切

26. 課題への対処
・ 数字が絶対的ではない
・ 横断チームを作る

27. プロダクト開発における、ジリツの段階
長期的なビジョンが描けて、ロードマップを考える事が出来る
↓
中長期的なKGI・KPIを描けて、施策を考える事が出来る
↓
施策に対して、技術選定、実装方法等を考え実装する事が出来る
↓
決まった技術、実装方法の中でコーディングする事が出来る
← ここの話
『横断チーム編』

28. 横断チーム編

29. 依頼は確実に遂行する。アサシンのようなチームを作る。

30. 横断チーム運用イメージ
・ スクラムを1週間スプリントで回す
・ KPIチームから出てきた施策で、KPIチームで実現できない施策を巻き取って実装する
・ 技術を使って（時には使わずに）、如何にスマートに課題を解決するかを楽しめる人物が
向いている

31. 横断チームのメリット
・ 「施策を考えたいワケでもない」 or 「一つの技術領域に集中したい」を叶える
・ リソースを集中させたい時は、KPIチームのメンバーもスクラムに入れる事ができる
※ スクラムのタブー

32. 最後に・・・

33. メンバーの力量と、任せられるKPIの粒度が密接に関連するため、KPIツリーを作成しチーム
編成を考える事で、今チーム（や会社）に足りない人材像が明らかになるので、採用もそこか
ら逆算して考えるといいかもしれない。

34. おしまい