プレイド開発チームにおけるチーム・ジャーニー

1
プレイド開発チームにおける
チーム・ジャーニー
ɹɹʛɹɹ© 2020 PLAID Inc. 2020.03.05 ʛ νʔϜɾδϟʔχʔൃץΠϕϯτʮνʔϜ͸Ռͨͯ͠δϟʔχʔͰ͖Δͷ͔ʁ ݱ৔δϟʔχʔɾϓϨΠυฤʯ ʛɹ
株式会社プレイド Head of Engineering ⾨脇恒平

View Slide

2
2020.03.05 ʛ νʔϜɾδϟʔχʔൃץΠϕϯτʮνʔϜ͸Ռͨͯ͠δϟʔχʔͰ͖Δͷ͔ʁ ݱ৔δϟʔχʔɾϓϨΠυฤʯ ʛɹ
ɹɹʛɹɹ© 2020 PLAID Inc.
⾃⼰紹介
⾨脇恒平株式会社プレイド
Head of Engineering KARTE の開発
2017年4⽉⼊社フットサルキャンプカラオケ⾳楽英会話
開発チームの⽣産性向上/リズムづくり
twitter : @kadoppe github : kadoppe
35

View Slide

ɹɹʛɹɹ© 2019 PLAID Inc. 3
yyyy.mm.ddɹɹʛɹɹEvent name hereɹɹʛɹ
株式会社プレイドについて
OUR MISSON
データによって⼈の価値を最⼤化する

View Slide

4
KARTEについて
$9 ސ٬ମݧ
ϓϥοτϑΥʔϜ

View Slide

5
KARTEについて
֬ೝ͢Δ
جຊαʔϏε΍͝ར༻ํ๏Λ͝঺հ͠·͢ɻ
͓ಘͳಛయ΍໾ཱͭ৘ใ͕ຬࡌͰ͢ɻ
ॳΊͯͷํ΁
ְתּׅ然钠ׅ׷
6*رؠ؎ش٦׌ֽוזַזַ♳麦׃זְծ➙
״׶إٔؗ،حف׃׋ְהְֲ倯䗳铣דׅկ
UIرؠ؎ش٦ָ濼׏גֶֻץֹ
7אךرؠ؎ٕٝ٦ٕ
DESIGN
RULES
» CHECK
׆׏ה⢪ִ׷،؎ذي׌ֽ׾䲧ִת׃׋կ
ֿך堣⠓׾ֶ鋅鷕׃זֻկ
窫㼎ծ
妜׃ְ
ౙͷओ໾ɺ
Ξ΢λʔ
COLLECTION
OUTER
嗚稊勴⟝׾㼰׃㢌刿ׅ׷׌ֽדծ֮ז׋ך椚
䟝ך暟⟝ח⳿⠓ִ׷〳腉䚍ָ넝ֻז׶תׅկ
勴⟝׾㢌ִג嗚稊׃ג׫גֻ׌ְׁկ
׀䋞劄ך暟⟝כ
鋅אַ׶תׇ׿ד׃׋ַ
ꟗׄ׷
⼀⼈⼀⼈に合わせた
顧客体験を提供
Webサイトの訪問者の⾏動を
顧客ごとにリアルタイムに解析
$9 ސ٬ମݧ
ϓϥοτϑΥʔϜ

View Slide

本⽇のテーマ
6
プレイドの開発チーム
における
チーム
・
ジャーニー
変化していないこと
変化したこと
これから変えたいこと
ɾ
ɾ
ɾ
話すこと

View Slide

7
プレイドの歴史（ざっくり）
2017/4
kadoppe ⼊社
20⼈
2⼈
2011/10
プレイド創業
1⼈
0⼈
エンジニア
デザイナー
2015/3
KARTE リリース
6⼈
1⼈
2018/3
KARTE for App
リリース
約25⼈
3⼈
2018/12
KARTE Datahub
リリース
約30⼈
約5⼈
2020/3
KARTE 5周年
約50⼈
約10⼈
今⽇お話するのはこの期間について
この期間ついてはあまり話せません

View Slide

本⽇のテーマ
8
における
チーム
・
ジャーニー
変化したこと
ɾ
ɾ
話すこと

View Slide

プレイド開発チームのチームジャーニー - 変化していないこと
9
前提・制約
• 正解がない中でプロダクトをつくる
• 世の中にも⾃分たちの中にも答えがない
• 世界観や市場を⾃分たちがつく
る
• タイムリミットがある中でつくる
• 崖の上から⾶び降りながら⾶⾏機をつく
る
その上で世界に通⽤する強いプロダクトを作りたい!!

View Slide

10
そのために必要なこと
• 個⼈の想像⼒
・
発想を最⼤限活かす
• プロセスではなく⼈を信じる
• トライ＆エラーを⾼速に繰り返す
• サイクルをどれだけ⾼速に回せるか
• サイクルからどれだけ多くを学べるか

View Slide

11
⼤事にしていること
• ルールはできるだけ決めない
• 硬直化する要因は極⼒なく
す
• 常にゼロベースで考える
• 前提にとらわれず常に最適な選択を
• プロダクトアウトを⼤事にする
• 良いと思うものはすぐつく
って出す
• ダメなら壊してつく
りなおす

View Slide

12
詳しくはこちら
IUUQTTQFBLFSEFDLDPNLBEPQQFQVSFJEPGBMTFFO[JOJBLBSBNJUB[IFOHTJJNPGBMTFXP[IFOHTJLVUVLVSV

View Slide

本⽇のテーマ
13
における
チーム
・
ジャーニー
変化したこと
ɾ
話すこと

View Slide

14
変化したこと：前段
"変化していないこと"の⼤切にしながら
"変化すること"の⾯⽩さと難しさ
ポイント:

View Slide

15
これまでのチームの変化について考えてみた
あらためて：

View Slide

16
そもそもチームは変化してるんだろうか
今や前だけを⾒ていると変化を感じにくい
疑問：

View Slide

17
焦り：
変化のスピード・⼤きさは⼗分？
環境の変化についていけてる？

View Slide

18
さらに焦り：
プレイドの開発チームにおける
チーム・ジャーニーってなんだ？
発表できるような変化ある？

View Slide

19
煮詰まった＼(^o^)∕
登壇 48 時間前

View Slide

20
みんなにヘルプミー
たくさん集まった!!
• ⼊社してから今までに体験した変化教えて
！
！
• どんな変化が重要だった？
• ⼤変だった変化ってあった？
• 思いがけない結果を⽣んだ変化ってあった？

View Slide

21
マインドマップで整理
書き出すとめっちゃ変化してる！

View Slide

22
カテゴライズした結果
今⽇紹介する部分

View Slide

23
プロダクトの価値
クライアントへの提供価値
エンドユーザーへの提供価値
⽬的：なぜチームを変化させるのか
チームの⽣産性
アウトプットの質
アウトプットの量
アウトプットの頻度
これらを全部上げたい☝
流れをスムーズにロスなく

View Slide

変化したこと：５つの変化
24
変化したこと
開発サイクルと組織構造
リズムの作り⽅
システムアーキテクチャ
問い合わせ/不具合対応
ストック/スケールの意識
ɾ
ɾ
ɾ
話すこと
ɾ
ɾ

View Slide

25
この後対談セッションがあるのサクッと紹介
詳しく知りたい / 気になる部分があれば質問してください

View Slide

26
⾊んな⼈が考えて⾏動した結果の変化です
思い⽴ったらすぐ Try & Error のサイクルをみんなが回せるのが弊社のいいところ。

View Slide

27
変化したこと
ɾ
ɾ
ɾ
話すこと
ɾ

View Slide

28
変化したこと - 開発サイクル・組織構造
Why の⽅向付けと
How / What をどうスケールさせるか
チームの並列性を上げる戦い
ジャーニーのポイント:
What
How
Why
ゴールデンサークル

View Slide

29

View Slide

30
フォーカスの誕⽣
権限移譲、分権化が進んだ。
やらないことも決められるように
• Before
• 個⼈商店の集まり
• 開発⽬標や期間が曖昧
• Problem
• CPOが意思決定
・
判断のボトルネックに
• 「やらないこと」
が決められない
• After
• 注⼒テーマと各チームの Why を決める
• What とHow は各チームが決める

View Slide

31
延々と続くフォーカス
• Before
• 期間が明確に決まっていない
• Problem
• 繰り返される期間延⻑
• 外から何がいつできるのかわからない
• 疲弊、
モチベーション低下
• After
• 2-3ヶ⽉でフ
ォーカスを切るように
• すぱっと切り替えて次へ
できたこと/できなかったことは
各チームで振り返り

View Slide

32
チームがすごく並列化
• Before
• 15チーム以上が横並びで開発
• Problem
• 毎回のフ
ォーカス設計の負荷増加
• CPOが全体を⾒るのが困難に
• After
• チームを複数のグループにわける
• 各グループに優先順位/体制は任せる
Why / How / What のスケール
が更に進んだ

View Slide

33
Why! How! What!
①初期
Why!
How! What!
②フォーカス/チームが⽣まれた時期
Why!
How! What!
③チームが増えて並列性が上がった時期
Why!
Why!
How! What!
④グループ/チームの階層ができた時期
組織構造・スケールの変遷

View Slide

34
変化したこと
ɾ
ɾ
話すこと
ɾ

View Slide

35
変化したこと - リズムづくり
共通のWhyが⾒いだせないものは
全体のルールにしない
個別事象に合わせたシンプルな仕組みを設計しよう

View Slide

36
過疎化する朝会
• Before
• 毎朝、
任意参加で朝会を開催
• チーム間の相談
・
共有が⽬的
• Problem
• Why に共感できないメンバーの存在
• 次第に参加⼈数が減少
• After
• 「挨拶によるリズムづく
り」
を⽬的化
参加⼈数も増えて
相談・共有も⾏われるように

View Slide

37
過疎化する⾊んな仕組み
• Before
• ⽇報 / 週報を各メンバーが投稿
• 毎週チームの進捗
・
学びの共有会開催
• Problem
• Whyに共感できないチーム
・
メンバー
• 次第に参加⼈数が減少
• After
• 全体の仕組みとしては廃⽌
「必要なら各チームで
⾃由にやってください」と伝える

View Slide

38
Demo Dayのリズム
• Before
• チームのアウ
トプッ
トを共有する場がない
• Problem
• アピール、
議論、
フィードバックが少ない
• After
• 隔週⾦曜⽇に任意参加
・
⾃由発表の
Demo Day を開催
• 順番に⼿を上げてプロジェクターでデモ
⼀番リズムづくりに寄与
チームのアウトプット増加・安定

View Slide

39
変化したこと
ɾ
話すこと
ɾ

View Slide

40
変化したこと - システムアーキテクチャ
ビジネスと開発効率を加速させる
疎結合なチーム/システムへの段階的な移⾏

View Slide

変化したこと - システムアーキテクチャ
41
マイクロサービス化
• Before
• モノ
リスなシステムの巨⼤
・
複雑
・
⽼朽化
• エンジニアメンバーの多様化
• Problem
• 全員がシステム全体を理解するのが困難
• 密結合による開発効率/スピード低下
• After
• 逆コンウェイの法則
（チームを先に分割）
• チームの粒度に合うようにシステムを分割
システム全体を知らなくても
各チームで独⽴して開発可能に
エンジニアが⾃由なタイミングで
⾃律的にデプロイできるように

View Slide

42
詳細はこちら
IUUQTTQFBLFSEFDLDPNLPNVLPNPNJHSBUJOHUPNJDSPTFSWJDFT

View Slide

43
変化したこと
話すこと
ɾ

View Slide

44
変化したこと - 問い合わせ/不具合対応
"プロダクトへのフィードバック強化"と
"⼿厚いサポート強化"のバランス
どちらもクライアントにとってメリットになるけど、取り組む順番が難しい

View Slide

45
エンジニアが
問い合わせ対応
• Before
• CSチームが問い合わせ対応
• ⼿厚い
・
クオリティの⾼い
・
属⼈的な対応
• Problem
• プロダク
トやサポートサイ
トへの
フィードバックが弱まる
• After
• エンジニアが問い合わせを⼀次受け
• プロダク
ト
・
サポートサイ
トを修正して返答
プロダクトへのフィードバック
改善を半強制化

View Slide

46
問い合わせ・不具合等のエスカレ
補⾜と現状:

View Slide

47
ナレッジシェアと属⼈化とバランス
どちらがプロダクトのクオリティやチームの⽣産性にとって重要

View Slide

48
• Before
• 問い合わせ
・
不具合発覚時は
該当機能をつく
った個⼈にアサイン
• Problem
• 機能の実装
・
仕様が過度に属⼈化
• 個⼈の負荷増⼤
• After
• Bot にIssue のURLを投稿すると
エンジニアが順番にアサインされるように
アサインガチャ登場
全員が全体を理解している
状態を"強いチーム"と置いた

View Slide

49
アサインガチャ廃⽌
• Before
• マイクロサービス化が進んだ後も
ガチャによるアサインを継続
• エンジニアの専⾨化が進んだ
• Problem
• 対応の負荷増⼤
（他機能の理解がきつい）
• 適切に問題を解けない/品質低下
• After
• 機能と担当チームの対応表作成
• 詳しいチームにIssue上でメンション
詳しい⼈にナレッジをストック
クオリティを上げる判断
チーム内で解く/解かない
解き⽅/優先度をしっかり考える

View Slide

50
変化したこと
話すこと

View Slide

51
変化したこと - ストック・スケールの意識
ノリ/根性/気合/テンション任せからの脱却

View Slide

52
役割・責任の明確化
例)障害対応
• Before
• ⼀部のエンジニア / ビジネスメンバーに
障害ハンドリング
・
対応が集中
• Problem
• 障害多発時に特定のメンバーに負荷集中
• ノウハウが属⼈化、
スケールしない
• After
• 障害発⽣時の役割
・
責任
・
フロー
・
基準の
明確化
スケールできる役割から
適切に⼈を巻き込めるように

View Slide

53
暗黙的/カオスなフローを可視化役割・責任・フローを明⽂化

View Slide

54
"組"の誕⽣
• Before
• 個⼈がチーム間に落ちるルーズボール
を拾っている状況
（例は後述）
• Problem
• ナレッジがス
トックされない
（属⼈化）
• スケールする仕組みが構築できない
• After
• 各ルーズボールに責任を持つ"組"を設⽴
• エンジニア/デザイナーは副業として参加
ナレッジのストック/
仕組みのスケールに責任を持つ

View Slide

55
組のラインナップは
フォーカスごとに状況⾒て変更
専⾨性・興味・チャレンジ意欲
をもとにメンバーをアサイン
メンバーもフォーカス毎に
ローテーションしていく

View Slide

本⽇のテーマ
56
における
チーム
・
ジャーニー
変化したこと

話すこと

View Slide

57
今が⼤きく変化できる
チャンス
• 環境の変化によるストレスが強まっている
• 利⽤クライアン
トの増加
• 求められる機能価値
・
クオリティの⾼まり
• ⾮連続な成⻑の必要性の⾼まり
• （個⼈的に）
特定チームに所属しなくなった
• 独⽴遊軍
• 事業や開発チームを俯瞰的に観た上での
変化にチャレンジできる

View Slide

58
抽象的ですが
• 個⼈の"創造性/開発⼒"をもっと活かす
• 阻害する環境要因がたく
さんある
• 少しずつ障害物の排除に投資できるようになっている
→もっと加速させる
• "完了の定義"をもっと先へ
• 「開発するだけじゃダメだった」
という
５年⽬の気づき
• クライアン
トにより⾼い価値を届けるまでやる
• プロダク
トへのフィードバックループを回すまでやる
• "プロダクト/チームジャーニー"をもっと先まで
• 次のフ
ォーカスだけではなく、
更に先のフ
ォーカスまで⾒据えて
変化を起こす→組織の学習サイクルを回す

View Slide

59
事業・プロダクトに⾮連続な成⻑を
次々と⽣み出せるチームに変化していきたい
結果として・・・

View Slide

60
おわりに
おわりに

View Slide

おわりに
61
振り返ると
チームの変化の軌跡が
たくさん積み上がってた
• 今や前だけを⾒ているときは
あまり変わっていないように思える
• でも、
振り返ってよく⾒ると
たく
さんの⼩さな変化が積み上がっている
• でも、
本質的に⼤事な部分は変わってない
これまでのチームジャーニーの振り返りを
これからのチームジャーニーにつなげていける⾃信に

View Slide

62
おわりに
プレイド開発チームの
これからのチーム・ジャーニーに
ご期待ください

View Slide

View Slide

プレイド開発チームにおけるチーム・ジャーニー

プレイド開発チームにおけるチーム・ジャーニー

kadoppe

More Decks by kadoppe

Other Decks in Technology

Featured

Transcript