REALITY株式会社における開発生産性向上の取り組み: 失敗と成功から学んだこと

by gree_tech

Slide 1

Slide 1 text

REALITY株式会社における開発生産性改善の取り組み: 成功と失敗から学んだこと REALITY株式会社シニアエンジニアリングマネージャー清貴幸

Slide 2

Slide 2 text

清貴幸 / ションロー 2018年グリー株式会社にiOSエンジニアとして中途入社、REALITY株式会社に出向 2020年 iOSチームエンジニアリングマネージャー 2022年エンジニアリンググループシニアエンジニアリングマネージャー REALITY株式会社シニアエンジニアリングマネージャー 2

Slide 3

Slide 3 text

目次 ● REALITY株式会社の紹介 ● アプリ「REALITY」の紹介 ● REALITYの開発組織 ● 開発生産性の捉え方 ● フロー効率改善の取り組み ● まとめ 3

Slide 4

Slide 4 text

REALITY株式会社 4

Slide 5

Slide 5 text

5 会社紹介

Slide 6

Slide 6 text

6 REALITY株式会社会社紹介

Slide 7

Slide 7 text

数字で見るREALITY株式会社 7

Slide 8

Slide 8 text

REALITY 8

Slide 9

Slide 9 text

REALITY 9

Slide 10

Slide 10 text

REALITY 10

Slide 11

Slide 11 text

REALITY 11

Slide 12

Slide 12 text

REALITYの開発体制 12

Slide 13

Slide 13 text

REALITYの開発体制 13 アバタープロダクトライブ配信横断 DevOps Product Manager Product Engineer Product Manager Product Engineer Product Manager Product Engineer Product Manager Product Engineer Product Manager Avatar System Data Engineering Analytics Product Design Art Operation QA Product Engineer

Slide 14

Slide 14 text

REALITYのエンジニア組織 ● Product Engineering チーム ○ 主に Backend / iOS / Android が得意なエンジニアが所属 ○ REALITYのバックエンドとネイティブアプリの開発に責任をもつ ● Avatar System チーム ○ 主に Unity / C# が得意なエンジニアが所属 ○ REALITY Avatarと呼ぶ「ライブラリ」の開発に責任をもつ ● DevOps チーム ○ インフラストラクチャの管理、横断的な開発生産性に責任をもつ ● Data Engineering チーム ○ 活用しやすいデータ基盤の構築に責任をもつ ● 全体で40名超 14

Slide 15

Slide 15 text

ネイティブ Unity クイズ 15

Slide 16

Slide 16 text

ネイティブ Unity クイズ 16 フルUnity フルネイティブ Unity + ネイティブ

Slide 17

Slide 17 text

REALITY Avatar ● Unity as a Library を利用 ● Unityで構築された3DのViewにアバターやなんやらかんやらをレンダリングする ● APIサーバーとの通信や、リアルタイムなモーションデータのやりとりもする 17

Slide 18

Slide 18 text

REALITYの開発組織 ● アプリの新機能をユーザーに届けるまでに、バックエンド・ライブラリ・ネイティブアプリをいい感じにリリースする必要がある ○ アバターで利用する3Dモデルの更新はアセットのリリースも必要 ● このような環境の中で、エンジニア組織全体のマネージャーとして「横断的な開発生産性の改善」について試行錯誤してきた 18

Slide 19

Slide 19 text

開発生産性の捉え方 19

Slide 20

Slide 20 text

なぜ開発生産性を高めるのか？ ● ユーザーに素早く価値提供をし、世界中のユーザーに楽しんで欲しい ● 事業成長のための戦略に基づいた仮説検証を素早く実行したい ● 開発組織の成長と共に、メンバーも成長できる環境でありたい 20

Slide 21

Slide 21 text

開発生産性が高い状態とは ● 「価値あるもの」を「素早くユーザーに届けられる」状態 ○ 「価値がある」とは「ユーザーに受け入れられる」「事業課題をクリアする」を満たしているもの ○ 「本当に価値があったのか」はリリースしてみないとわからない ● 仮説検証のサイクルを素早く回したい ○ 一つ一つの開発のリードタイムが短い状態を目指す ○ 「フロー効率が良い状態」を作る 21

Slide 22

Slide 22 text

フロー効率とは ● 「ニーズの特定されてからそれを満たすまでのリードタイムの短さの効率性」のこと ○ 二クラス・モーディグ, パール・オールストローム. This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント. 翔泳社, 2021年 ● 対立する概念として「リソース効率」がある ○ リソース効率 = 稼働率の効率性、リソースに遊びがないことが良い ● くわしくは This is Lean を読んでください！ 22

Slide 23

Slide 23 text

リソース効率 vs フロー効率 23 高リソース効率の例

Slide 24

Slide 24 text

リソース効率 vs フロー効率 24 高フロー効率の例

Slide 25

Slide 25 text

リソース効率 vs フロー効率 ● 「リソース効率」重視による弊害として起きていたこと ○ メンバーの「手が空かない」ようタスクを渡す「アサインパズル」が発生していた ○ 結果、相対的に重要度の低い（スキマでできそうな）タスクが積まれていた ● 「フロー効率」を高め重要な施策が素早くリリースされる状態に ○ 「ユーザーへの価値提供のスピード」と「仮説検証サイクル」の両方を早める 25 フロー効率の高い組織を目指す！

Slide 26

Slide 26 text

効率性のマトリクス ● フロー効率を高めるには一時的にリソース効率を落とさないと行けない場合がある ● これを理解してもらえるよう説明する必要あり 26 引用: This is Lean https://www.shoeisha.co.jp/book/detail/9784798169521

Slide 27

Slide 27 text

フロー効率改善の取り組み 27

Slide 28

Slide 28 text

フロー効率改善の取り組み ● リソース効率重視からフロー効率重視へ意識を変える ● サイクル時間の改善 28

Slide 29

Slide 29 text

リソース効率重視からフロー効率重視へ意識を変える 29

Slide 30

Slide 30 text

「フロー効率」の概念を広める ● This is Leanの輪読会を実施 ● 開発部門全体MTGの場でとにかく「フロー効率」について何度も話す ● Slackの表示名を「フロー効率おじさん」にする 30

Slide 31

Slide 31 text

This is Lean 輪読会 ● 開発チームの有志で毎週開催 ○ 開発チームのマネージャーに参加してもらった ○ 30min読む ■ 内容から「ぐっと来た」「疑問におもった」とこをろ拾う ○ 30minディスカッションをする ● 知識の獲得だけではなく、開発プロセスの FBに至ったのが良かった 31

Slide 32

Slide 32 text

「フロー効率を上げようとするとリソース効率が下がる」をメンバーとすり合わせる 32 ● （一時的に）「リソース効率」を下げる取り組みになるため、認識齟齬がおきないように ○ 効率性のマトリクス ● 弊社の経営陣はすぐに理解してくれたので特に問題はなかった

Slide 33

Slide 33 text

開発チームと一緒にフロー効率の良い行動をつくる 33 ● 「フロー効率改善」の理解度が高いメンバーが開発チームに参加してファシリテーションする ○ まとめて意思決定ができるようにmtg の時間を調整したり ○ なんとなく「宿題」になりそうなものに対して「今決めちゃおう！」と背中を押したり

Slide 34

Slide 34 text

「意識を変える」取り組みをしてどうだったか ● うまくいった ○ 「フロー効率」という概念とその意味が一部メンバーに浸透した ■ 「フロー効率を上げるために〜」という言葉がメンバーから出てくるようになった ○ 他職種の仕事を引き受ける、という動きが増えた ■ ソフトウェアエンジニアがPdMやQAのタスクを拾ったり ● うまくいかなかった ○ 自分と直接的な関わりが少ない方面には意識が広まりきらなかった ■ 各チームのキーになるメンバーとの個別の対話をもっと持つべきだった ○ 「フロー効率を上げる」が有効ではなさそうなチームもあった ■ 横断した取り組みとして進めたが、適用するチームは適宜判断してもよかった 34

Slide 35

Slide 35 text

フロー効率改善の取り組み ● リソース効率重視からフロー効率重視へ意識を変える ● サイクル時間の改善 35

Slide 36

Slide 36 text

サイクル時間の改善 36

Slide 37

Slide 37 text

サイクル時間の改善 ● フロー効率を低下させる要因 ○ フローユニットの数が多い ○ サイクル時間が長い ○ ボトルネックが存在する ○ 大きい変動要因が存在する 37 引用: This is Lean https://www.shoeisha.co.jp/book/detail/9784798169521

Slide 38

Slide 38 text

サイクル時間を短縮する 38

Slide 39

Slide 39 text

サイクル時間を短縮する ● エンジニアチームのサイクル時間がどうなっているのかを可視化 ○ Findy Team+ を利用してサイクル時間を特定 39

Slide 40

Slide 40 text

サイクル時間を短縮する 40

Slide 41

Slide 41 text

サイクル時間を短縮する ● ﬁrst commit から merge までの時間をサイクル時間と捉える ○ 「コミットからオープン」「オープンからレビュー」「レビューからアプルーブ」「アプルーブからマージ」の4つに分類される ● サイクル時間のどこに時間がかかっているのか？を特定する ○ 正直「全体的に時間かかってますね」という所管だった ○ エンジニアがコントローラブルなところから取り組み、成功体験を積みたい ■ -> まずはコードレビュー時間を改善にとりくんだ 41

Slide 42

Slide 42 text

コードレビューの改善 42 ● コードレビューに時間がかかる要因 ○ 「レビューを優先する」という意識が作れていなかった ○ PRが「コードレビューしやすい状態」ではなかった ○ 特定のレビュアーがボトルネック状態になっていた

Slide 43

Slide 43 text

コードレビューの改善 43 ● コードレビューに時間がかかる要因 ○ 「レビューを優先する」という意識が作れていなかった ○ PRが「コードレビューしやすい状態」ではなかった ○ 特定のレビュアーがボトルネック状態になっていた

Slide 44

Slide 44 text

「レビューを優先する」という意識作り 44 ● 「自分の開発タスク」と「コードレビュー」の優先順位を決めていなかった ○ 基本的に「コードレビューを優先しようね」と決めた ● 「レビュー時間」を目標に取り入れる ○ 定性的に「依頼してから1日以内に帰ってきてほしいよね」= 24h をスタート地点にした ○ またストレッチ目標として 12h を目指した ● コードレビューを頑張るためのキャンペーンを実施 ○ 「みんなで改善頑張っていこうぜ！」という空気感を醸成したかった ○ Monthly Win-Session で、頑張ってくれたメンバーやチームをしっかり褒める

Slide 45

Slide 45 text

「レビューを優先する」という意識作り 45

Slide 46

Slide 46 text

「レビューを優先する」という意識作り 46

Slide 47

Slide 47 text

コードレビューの改善 47 ● コードレビューに時間がかかる要因 ○ 「レビューを優先する」という意識が作れていなかった ○ PRが「コードレビューしやすい状態」ではなかった ○ 特定のレビュアーがボトルネック状態になっていた

Slide 48

Slide 48 text

「コードレビューしやすい状態」を作る 48 ● レビュー依頼に気づきづらい ○ GitHubのSlack Integrationを設定する ○ レビュアのアサイン時に依頼者が都度Slackでメンションを投げる、botを活用する ● レビューしやすいPRになっていなかった ○ レビューしやすい「粒度」でPRを作れるように ○ 適切な範囲でPRを分割する ○ 「小さければ良いわけではない」

Slide 49

Slide 49 text

レビューしやすいPRの粒度を作る 49 引用: 開発生産性実践入門 Pullrequestの粒度編 https://speakerdeck.com/starﬁsh719/kai-fa-sheng-chan-xing-shi-jian-ru-men-pullrequestnoli-du-bian

Slide 50

Slide 50 text

レビューしやすいPRの粒度を作る 50 ● コードを書く前にタスク分解をする ○ 各開発チーム内でタスクの洗い出しとアサインを丁寧に実施 ● Topic Branchを活用できるようにする ○ いわゆる「親」のブランチを作り、そこに「子」のブランチを小さく作ってレビュー・マージする ■ develop ● Topic Branch（親） ○ Work Branch（子） ○ Work Branch（子） ○ Work Branch（子）

Slide 51

Slide 51 text

コードレビューの改善 51 ● コードレビューに時間がかかる要因 ○ 「レビューを優先する」という意識が作れていなかった ○ PRが「コードレビューしやすい状態」ではなかった ○ 特定のレビュアーがボトルネック状態になっていた

Slide 52

Slide 52 text

レビュアーのボトルネック解消 52 ● Findy Team+のレビュー分析を見て、明らかに時間が長い人が数名いる ○ 話を聞いてみると、「重い」レビューが一部の人に集中していることがわかった

Slide 53

Slide 53 text

レビュアーのボトルネック解消 53 ● コードレビューの依頼が、基本的に「ランダムアサイン」 ● 一方で、特定のモジュールに詳しい人に「直接指名」の依頼が投げられていた ○ さらに「直接指名」のコードレビューは重めの内容が多かった ○ 「直接指名」の件数が多い人は「ランダムアサイン」の対象から外すことに

Slide 54

Slide 54 text

コードレビューの改善 54 結構早くなってえらい！が、代わりに質が落ちてたりしないか？が気になった

Slide 55

Slide 55 text

アンケートで定性面を評価する 55

Slide 56

Slide 56 text

アンケートで定性面を評価する 56

Slide 57

Slide 57 text

アンケートで定性面を評価する 57

Slide 58

Slide 58 text

アンケートで定性面を評価する 58 ● ポジティブだったコメント ○ 「コメントが付くまでだいぶ早くなったので、修正をするのも早くできるようになった。また、マージを早くできるようになったのでコンフリクトの発生頻度が下がった」 ○ 「ファーストチェックのレスポンスが早くなったので、手戻りが少なく感じて快適だった」 ○ 「レビュワー側もなるべく早く見れるように綺麗(理解しやすい)なPRを心がけるようになった」 ● 課題が見えたコメント ○ 「機械的な統計なので、金曜夜依頼のレビューがあって月曜にレビューしたりすると数値悪化したりするのは、うーんという気持ちだった。」 ○ 「自分の行うレビューも含め、PRレビューの品質面で妥当なレビューを回せているか疑問が残る」

Slide 59

Slide 59 text

コードレビューの改善をやってみてどうだったか ● うまくいった ○ 「コードレビューの時間」を目標に置いたことで、メンバーに強い意識付けができた ○ Findy Team+を活用することでサイクル時間の可視化が容易にできた ○ 取り組み後のアンケートによって「定性的な改善」が確認できた ● うまくいかなかった ○ 「コードレビューの時間」を目標に置いたことで、数値ハック的な動きが一部発生していた ■ 夕方にコードレビュー依頼を投げない、など・・ ■ チーム・メンバーと「自分たちがありたい姿」についてもっと話すべきだった ○ 「PRを分割すること」を簡単に考えすぎて、メンバーと対立することがあった ■ バックエンド、iOS / Android、Unityなどの技術領域でやりやすさが違うことを理解できていなかった ■ 特定の領域で成功した取り組みが、他方の領域でもうまくいくとは限らない 59

Slide 60

Slide 60 text

サイクル時間を短縮する ● 「コードレビューの時間」以外も含めた改善にも着手 ○ 「サイクルタイム全体」を目標として持ってみる運用を開始 ● 改善対象の意識が全体に向いたものの、具体的になにをやればいいか？が難しくなった 60

Slide 61

Slide 61 text

「開発者体験」に着目する 61 引用: 開発者体験サーベイ、めっちゃよかったんで、おすすめです https://moneyforward-dev.jp/entry/2024/03/07/090000

Slide 62

Slide 62 text

「開発者体験」に着目する ● Four Keysなどの「遅行指標」に対する「先行指標」 ● 開発者体験が改善 -> 開発生産性改善に寄与する 62

Slide 63

Slide 63 text

「開発者体験」に着目する ● フロー状態、認知負荷、フィードバックループの3カテゴリ ○ アンケートも上記のカテゴリのもと質問を作成 ● 各カテゴリの値や、回答結果から改善ポイントを見つける 63 引用: 卓越したDevExが高める生産性 https://github.blog/jp/2024-01-24-good-devex-increases-productivity/

Slide 64

Slide 64 text

開発者体験サーベイ ● 2024/03から Q に1回実施 ● 質問項目40問程度 64

Slide 65

Slide 65 text

開発者体験サーベイ 65

Slide 66

Slide 66 text

開発者体験サーベイ ● サーベイの結果から、以下2つの問題を特定 ○ フロー状態に入りづらいMTGの入り方になっている ○ テスト環境に問題がある ● それぞれ改善を実施 ○ MTGの入れ方を改善 -> 特定の時間にMTGを集中させるルールに変更 ○ テスト環境改善のプロジェクトを進行 -> カバレッジの可視化、改善が進めた 66

Slide 67

Slide 67 text

開発者体験サーベイをやってみてどうだったか ● うまくいった ○ 「開発者体験」という観点で、全体感としてどのへんに問題がありそうか、が把握できた ○ 個別のコメントや対話の中から、具体の改善のうごきに繋がった ■ カバレッジの話を追加 ● うまくいかなかった ○ 自分の立場で全体感を把握し横断的な改善を進める役立ったが「各開発チームのマネージャーが活用する」ところまではまだ至っていない 67

Slide 68

Slide 68 text

その後なんやかんやあり・・ 68

Slide 69

Slide 69 text

最近のサイクル時間 69

Slide 70

Slide 70 text

取り組み前の状態から1/3に改善！ 70

Slide 71

Slide 71 text

「その後のなんやかんや」についてはブースでお話しましょう！ 71

Slide 72

Slide 72 text

まとめ 72

Slide 73

Slide 73 text

まとめ 73 ● 開発生産性が高い状態 ○ 「価値あるもの」を素早くユーザーに届けられる状態 ○ 「フロー効率」を高めることが重要 ● フロー効率を高めるには ○ 「リソース効率」重視から脱却する ○ 「フロー効率」を下げる要因を排除 ● サイクル時間の改善 ○ 時間全体を可視化し、問題を特定できるように ○ 「コードレビューの時間」は意識とテクニックの向上で改善 ○ 開発者体験をサーベイで具体的な改善ポイントを探索する