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

GREE Tech Conference 2024で発表された資料です。
https://techcon.gree.jp/2024/session/TrackC-1

Transcript

1. REALITY株式会社における開発生産性 改善の取り組み: 成功と失敗から学んだこと REALITY株式会社 シニアエンジニアリングマネージャー 清貴幸
2. 清貴幸 / ションロー 2018年 グリー株式会社にiOSエンジニアとして中途 入社、REALITY株式会社に出向 2020年 iOSチーム エンジニアリングマネージャー 2022年 エンジニアリンググループ シニアエンジニ アリングマネージャー REALITY株式会社 シニアエンジニアリングマネージャー 2
3. 目次 • REALITY株式会社の紹介 • アプリ「REALITY」の紹介 • REALITYの開発組織 • 開発生産性の捉え方 • フロー効率改善の取り組み • まとめ 3
4. REALITY株式会社 4
5. 5 会社紹介
6. 6 REALITY株式会社 会社紹介
7. 数字で見るREALITY株式会社 7
8. REALITY 8
9. REALITY 9
10. REALITY 10
11. REALITY 11
12. REALITYの開発体制 12
13. 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
14. REALITYのエンジニア組織 • Product Engineering チーム ◦ 主に Backend / iOS / Android が得意なエンジニアが所属 ◦ REALITYのバックエンドとネイティブアプリの開発に責任をもつ • Avatar System チーム ◦ 主に Unity / C# が得意なエンジニアが所属 ◦ REALITY Avatarと呼ぶ「ライブラリ」の開発に責任をもつ • DevOps チーム ◦ インフラストラクチャの管理、横断的な開発生産性に責任をもつ • Data Engineering チーム ◦ 活用しやすいデータ基盤の構築に責任をもつ • 全体で40名超 14
15. ネイティブ Unity クイズ 15
16. ネイティブ Unity クイズ 16 フルUnity フルネイティブ Unity + ネイティブ
17. REALITY Avatar • Unity as a Library を利用 • Unityで構築された3DのViewにア バターやなんやらかんやらをレン ダリングする • APIサーバーとの通信や、リアル タイムなモーションデータのやり とりもする 17
18. REALITYの開発組織 • アプリの新機能をユーザーに届けるまでに、バックエンド・ライブラリ・ ネイティブアプリをいい感じにリリースする必要がある ◦ アバターで利用する3Dモデルの更新はアセットのリリースも必要 • このような環境の中で、エンジニア組織全体のマネージャーとして「横断 的な開発生産性の改善」について試行錯誤してきた 18
19. 開発生産性の捉え方 19
20. なぜ開発生産性を高めるのか？ • ユーザーに素早く価値提供をし、世界中のユーザーに楽しんで欲しい • 事業成長のための戦略に基づいた仮説検証を素早く実行したい • 開発組織の成長と共に、メンバーも成長できる環境でありたい 20
21. 開発生産性が高い状態とは • 「価値あるもの」を「素早くユーザーに届けられる」状態 ◦ 「価値がある」とは「ユーザーに受け入れられる」「事業課題をクリアする」を満たして いるもの ◦ 「本当に価値があったのか」はリリースしてみないとわからない • 仮説検証のサイクルを素早く回したい ◦ 一つ一つの開発のリードタイムが短い状態を目指す ◦ 「フロー効率が良い状態」を作る 21
22. フロー効率とは • 「ニーズの特定されてからそれを満たすまでのリードタイムの短さの効率 性」のこと ◦ 二クラス・モーディグ, パール・オールストローム. This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント. 翔泳社, 2021年 • 対立する概念として「リソース効率」がある ◦ リソース効率 = 稼働率の効率性、リソースに遊びがないことが良い • くわしくは This is Lean を読んでください！ 22
23. リソース効率 vs フロー効率 23 高リソース効率の例
24. リソース効率 vs フロー効率 24 高フロー効率の例
25. リソース効率 vs フロー効率 • 「リソース効率」重視による弊害として起きていたこと ◦ メンバーの「手が空かない」ようタスクを渡す「アサインパズル」が発生していた ◦ 結果、相対的に重要度の低い（スキマでできそうな）タスクが積まれていた • 「フロー効率」を高め重要な施策が素早くリリースされる状態に ◦ 「ユーザーへの価値提供のスピード」と「仮説検証サイクル」の両方を早める 25 フロー効率の高い組織を目指す！
26. 効率性のマトリクス • フロー効率を高めるには一時的にリソース効率 を落とさないと行けない場合がある • これを理解してもらえるよう説明する必要あり 26 引用: This is Lean https://www.shoeisha.co.jp/book/detail/9784798169521
27. フロー効率改善の取り組み 27
28. フロー効率改善の取り組み • リソース効率重視からフロー効率重視へ意識を変える • サイクル時間の改善 28
29. リソース効率重視からフロー効率重視へ 意識を変える 29
30. 「フロー効率」の概念を広める • This is Leanの輪読会を実施 • 開発部門全体MTGの場でとにかく「フロー効率」について何度も話す • Slackの表示名を「フロー効率おじさん」にする 30
31. This is Lean 輪読会 • 開発チームの有志で毎週開催 ◦ 開発チームのマネージャーに参加し てもらった ◦ 30min読む ▪ 内容から「ぐっと来た」「疑 問におもった」とこをろ拾う ◦ 30minディスカッションをする • 知識の獲得だけではなく、開発プロセスの FBに至ったのが良かった 31
32. 「フロー効率を上げようとするとリソース効率が下が る」をメンバーとすり合わせる 32 • （一時的に）「リソース効率」を下げる取り組みになるため、認識齟齬が おきないように ◦ 効率性のマトリクス • 弊社の経営陣はすぐに理解してくれたので特に問題はなかった
33. 開発チームと一緒にフロー効率の良い行動をつくる 33 • 「フロー効率改善」の理解度が高 いメンバーが開発チームに参加し てファシリテーションする ◦ まとめて意思決定ができるようにmtg の時間を調整したり ◦ なんとなく「宿題」になりそうなもの に対して「今決めちゃおう！」と背中 を押したり
34. 「意識を変える」取り組みをしてどうだったか • うまくいった ◦ 「フロー効率」という概念とその意味が一部メンバーに浸透した ▪ 「フロー効率を上げるために〜」という言葉がメンバーから出てくるようになった ◦ 他職種の仕事を引き受ける、という動きが増えた ▪ ソフトウェアエンジニアがPdMやQAのタスクを拾ったり • うまくいかなかった ◦ 自分と直接的な関わりが少ない方面には意識が広まりきらなかった ▪ 各チームのキーになるメンバーとの個別の対話をもっと持つべきだった ◦ 「フロー効率を上げる」が有効ではなさそうなチームもあった ▪ 横断した取り組みとして進めたが、適用するチームは適宜判断してもよかった 34
35. フロー効率改善の取り組み • リソース効率重視からフロー効率重視へ意識を変える • サイクル時間の改善 35
36. サイクル時間の改善 36
37. サイクル時間の改善 • フロー効率を低下させる要因 ◦ フローユニットの数が多い ◦ サイクル時間が長い ◦ ボトルネックが存在する ◦ 大きい変動要因が存在する 37 引用: This is Lean https://www.shoeisha.co.jp/book/detail/9784798169521
38. サイクル時間を短縮する 38
39. サイクル時間を短縮する • エンジニアチームのサイクル時間がどうなっているのかを可視化 ◦ Findy Team+ を利用してサイクル時間を特定 39
40. サイクル時間を短縮する 40
41. サイクル時間を短縮する • first commit から merge までの時間をサイクル時間と捉える ◦ 「コミットからオープン」「オープンからレビュー」「レビューからアプルーブ」「アプ ルーブからマージ」の4つに分類される • サイクル時間のどこに時間がかかっているのか？を特定する ◦ 正直「全体的に時間かかってますね」という所管だった ◦ エンジニアがコントローラブルなところから取り組み、成功体験を積みたい ▪ -> まずはコードレビュー時間を改善にとりくんだ 41
42. コードレビューの改善 42 • コードレビューに時間がかかる要因 ◦ 「レビューを優先する」という意識が作れていなかった ◦ PRが「コードレビューしやすい状態」ではなかった ◦ 特定のレビュアーがボトルネック状態になっていた
43. コードレビューの改善 43 • コードレビューに時間がかかる要因 ◦ 「レビューを優先する」という意識が作れていなかった ◦ PRが「コードレビューしやすい状態」ではなかった ◦ 特定のレビュアーがボトルネック状態になっていた
44. 「レビューを優先する」という意識作り 44 • 「自分の開発タスク」と「コードレビュー」の優先順位を決めていなかっ た ◦ 基本的に「コードレビューを優先しようね」と決めた • 「レビュー時間」を目標に取り入れる ◦ 定性的に「依頼してから1日以内に帰ってきてほしいよね」= 24h をスタート地点にした ◦ またストレッチ目標として 12h を目指した • コードレビューを頑張るためのキャンペーンを実施 ◦ 「みんなで改善頑張っていこうぜ！」という空気感を醸成したかった ◦ Monthly Win-Session で、頑張ってくれたメンバーやチームをしっかり褒める
45. 「レビューを優先する」という意識作り 45
46. 「レビューを優先する」という意識作り 46
47. コードレビューの改善 47 • コードレビューに時間がかかる要因 ◦ 「レビューを優先する」という意識が作れていなかった ◦ PRが「コードレビューしやすい状態」ではなかった ◦ 特定のレビュアーがボトルネック状態になっていた
48. 「コードレビューしやすい状態」を作る 48 • レビュー依頼に気づきづらい ◦ GitHubのSlack Integrationを設定する ◦ レビュアのアサイン時に依頼者が都度Slackでメンションを投げる、botを活用する • レビューしやすいPRになっていなかった ◦ レビューしやすい「粒度」でPRを作れるように ◦ 適切な範囲でPRを分割する ◦ 「小さければ良いわけではない」
49. レビューしやすいPRの粒度を作る 49 引用: 開発生産性実践入門 Pullrequestの粒度編 https://speakerdeck.com/starfish719/kai-fa-sheng-chan-xing-shi-jian-ru-men-pullrequestnoli-du-bian
50. レビューしやすいPRの粒度を作る 50 • コードを書く前にタスク分解をする ◦ 各開発チーム内でタスクの洗い出しとアサインを丁寧に実施 • Topic Branchを活用できるようにする ◦ いわゆる「親」のブランチを作り、そこに「子」のブランチを小さく作ってレビュー・ マージする ▪ develop • Topic Branch（親） ◦ Work Branch（子） ◦ Work Branch（子） ◦ Work Branch（子）
51. コードレビューの改善 51 • コードレビューに時間がかかる要因 ◦ 「レビューを優先する」という意識が作れていなかった ◦ PRが「コードレビューしやすい状態」ではなかった ◦ 特定のレビュアーがボトルネック状態になっていた
52. レビュアーのボトルネック解消 52 • Findy Team+のレビュー分析を見て、明らかに時間が長い人が数名いる ◦ 話を聞いてみると、「重い」レビューが一部の人に集中していることがわかった
53. レビュアーのボトルネック解消 53 • コードレビューの依頼が、基本的に「ランダムアサイン」 • 一方で、特定のモジュールに詳しい人に「直接指名」の依頼が投げられて いた ◦ さらに「直接指名」のコードレビューは重めの内容が多かった ◦ 「直接指名」の件数が多い人は「ランダムアサイン」の対象から外すことに
54. コードレビューの改善 54 結構早くなってえらい！ が、代わりに質が落ちてたりしないか？が気になった
55. アンケートで定性面を評価する 55
56. アンケートで定性面を評価する 56
57. アンケートで定性面を評価する 57
58. アンケートで定性面を評価する 58 • ポジティブだったコメント ◦ 「コメントが付くまでだいぶ早くなったので、修正をするのも早くできるようになった。また、マージを 早くできるようになったのでコンフリクトの発生頻度が下がった」 ◦ 「ファーストチェックのレスポンスが早くなったので、手戻りが少なく感じて快適だった」 ◦ 「レビュワー側もなるべく早く見れるように綺麗(理解しやすい)なPRを心がけるようになった」 • 課題が見えたコメント ◦ 「機械的な統計なので、金曜夜依頼のレビューがあって月曜にレビューしたりすると数値悪化したりする のは、うーんという気持ちだった。」 ◦ 「自分の行うレビューも含め、PRレビューの品質面で妥当なレビューを回せているか疑問が残る」
59. コードレビューの改善をやってみてどうだったか • うまくいった ◦ 「コードレビューの時間」を目標に置いたことで、メンバーに強い意識付けができた ◦ Findy Team+を活用することでサイクル時間の可視化が容易にできた ◦ 取り組み後のアンケートによって「定性的な改善」が確認できた • うまくいかなかった ◦ 「コードレビューの時間」を目標に置いたことで、数値ハック的な動きが一部発生していた ▪ 夕方にコードレビュー依頼を投げない、など・・ ▪ チーム・メンバーと「自分たちがありたい姿」についてもっと話すべきだった ◦ 「PRを分割すること」を簡単に考えすぎて、メンバーと対立することがあった ▪ バックエンド、iOS / Android、Unityなどの技術領域でやりやすさが違うことを理解できていな かった ▪ 特定の領域で成功した取り組みが、他方の領域でもうまくいくとは限らない 59
60. サイクル時間を短縮する • 「コードレビューの時間」以外も含めた改善にも着手 ◦ 「サイクルタイム全体」を目標として持ってみる運用を開始 • 改善対象の意識が全体に向いたものの、具体的になにをやればいいか？が 難しくなった 60
61. 「開発者体験」に着目する 61 引用: 開発者体験サーベイ、めっちゃよかったんで、おすすめです https://moneyforward-dev.jp/entry/2024/03/07/090000
62. 「開発者体験」に着目する • Four Keysなどの「遅行指標」に対する「先行指標」 • 開発者体験が改善 -> 開発生産性改善に寄与する 62
63. 「開発者体験」に着目する • フロー状態、認知負荷、 フィードバックループの3カテ ゴリ ◦ アンケートも上記のカテゴリのも と質問を作成 • 各カテゴリの値や、回答結果 から改善ポイントを見つける 63 引用: 卓越したDevExが高める生産性 https://github.blog/jp/2024-01-24-good-devex-increases-productivity/
64. 開発者体験サーベイ • 2024/03から Q に1回実施 • 質問項目40問程度 64
65. 開発者体験サーベイ 65
66. 開発者体験サーベイ • サーベイの結果から、以下2つの問題を特定 ◦ フロー状態に入りづらいMTGの入り方になっている ◦ テスト環境に問題がある • それぞれ改善を実施 ◦ MTGの入れ方を改善 -> 特定の時間にMTGを集中させるルールに変更 ◦ テスト環境改善のプロジェクトを進行 -> カバレッジの可視化、改善が進めた 66
67. 開発者体験サーベイをやってみてどうだったか • うまくいった ◦ 「開発者体験」という観点で、全体感としてどのへんに問題がありそうか、が把握できた ◦ 個別のコメントや対話の中から、具体の改善のうごきに繋がった ▪ カバレッジの話を追加 • うまくいかなかった ◦ 自分の立場で全体感を把握し横断的な改善を進める役立ったが「各開発チームのマネー ジャーが活用する」ところまではまだ至っていない 67
68. その後なんやかんやあり・・ 68
69. 最近のサイクル時間 69
70. 取り組み前の状態から1/3に改善！ 70
71. 「その後のなんやかんや」については ブースでお話しましょう！ 71
72. まとめ 72
73. まとめ 73 • 開発生産性が高い状態 ◦ 「価値あるもの」を素早くユーザーに届けられる状態 ◦ 「フロー効率」を高めることが重要 • フロー効率を高めるには ◦ 「リソース効率」重視から脱却する ◦ 「フロー効率」を下げる要因を排除 • サイクル時間の改善 ◦ 時間全体を可視化し、問題を特定できるように ◦ 「コードレビューの時間」は意識とテクニックの向上で改善 ◦ 開発者体験をサーベイで具体的な改善ポイントを探索する
74. ご清聴ありがとうございました 74