Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

gree_tech

October 25, 2024
Tweet

Video

More Decks by gree_tech

Other Decks in Technology

Transcript

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

    エンジニアリンググループ シニアエンジニ アリングマネージャー REALITY株式会社 シニアエンジニアリングマネージャー 2
  2. 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
  3. REALITYのエンジニア組織 • Product Engineering チーム ◦ 主に Backend / iOS

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

    バターやなんやらかんやらをレン ダリングする • APIサーバーとの通信や、リアル タイムなモーションデータのやり とりもする 17
  5. フロー効率とは • 「ニーズの特定されてからそれを満たすまでのリードタイムの短さの効率 性」のこと ◦ 二クラス・モーディグ, パール・オールストローム. This is Lean

    「リソース」にとらわれずチームを変える新時代のリーン・マネジメント. 翔泳社, 2021年 • 対立する概念として「リソース効率」がある ◦ リソース効率 = 稼働率の効率性、リソースに遊びがないことが良い • くわしくは This is Lean を読んでください! 22
  6. リソース効率 vs フロー効率 • 「リソース効率」重視による弊害として起きていたこと ◦ メンバーの「手が空かない」ようタスクを渡す「アサインパズル」が発生していた ◦ 結果、相対的に重要度の低い(スキマでできそうな)タスクが積まれていた •

    「フロー効率」を高め重要な施策が素早くリリースされる状態に ◦ 「ユーザーへの価値提供のスピード」と「仮説検証サイクル」の両方を早める 25 フロー効率の高い組織を目指す!
  7. This is Lean 輪読会 • 開発チームの有志で毎週開催 ◦ 開発チームのマネージャーに参加し てもらった ◦

    30min読む ▪ 内容から「ぐっと来た」「疑 問におもった」とこをろ拾う ◦ 30minディスカッションをする • 知識の獲得だけではなく、開発プロセスの FBに至ったのが良かった 31
  8. 「意識を変える」取り組みをしてどうだったか • うまくいった ◦ 「フロー効率」という概念とその意味が一部メンバーに浸透した ▪ 「フロー効率を上げるために〜」という言葉がメンバーから出てくるようになった ◦ 他職種の仕事を引き受ける、という動きが増えた ▪

    ソフトウェアエンジニアがPdMやQAのタスクを拾ったり • うまくいかなかった ◦ 自分と直接的な関わりが少ない方面には意識が広まりきらなかった ▪ 各チームのキーになるメンバーとの個別の対話をもっと持つべきだった ◦ 「フロー効率を上げる」が有効ではなさそうなチームもあった ▪ 横断した取り組みとして進めたが、適用するチームは適宜判断してもよかった 34
  9. サイクル時間を短縮する • first commit から merge までの時間をサイクル時間と捉える ◦ 「コミットからオープン」「オープンからレビュー」「レビューからアプルーブ」「アプ ルーブからマージ」の4つに分類される

    • サイクル時間のどこに時間がかかっているのか?を特定する ◦ 正直「全体的に時間かかってますね」という所管だった ◦ エンジニアがコントローラブルなところから取り組み、成功体験を積みたい ▪ -> まずはコードレビュー時間を改善にとりくんだ 41
  10. 「レビューを優先する」という意識作り 44 • 「自分の開発タスク」と「コードレビュー」の優先順位を決めていなかっ た ◦ 基本的に「コードレビューを優先しようね」と決めた • 「レビュー時間」を目標に取り入れる ◦

    定性的に「依頼してから1日以内に帰ってきてほしいよね」= 24h をスタート地点にした ◦ またストレッチ目標として 12h を目指した • コードレビューを頑張るためのキャンペーンを実施 ◦ 「みんなで改善頑張っていこうぜ!」という空気感を醸成したかった ◦ Monthly Win-Session で、頑張ってくれたメンバーやチームをしっかり褒める
  11. 「コードレビューしやすい状態」を作る 48 • レビュー依頼に気づきづらい ◦ GitHubのSlack Integrationを設定する ◦ レビュアのアサイン時に依頼者が都度Slackでメンションを投げる、botを活用する •

    レビューしやすいPRになっていなかった ◦ レビューしやすい「粒度」でPRを作れるように ◦ 適切な範囲でPRを分割する ◦ 「小さければ良いわけではない」
  12. レビューしやすいPRの粒度を作る 50 • コードを書く前にタスク分解をする ◦ 各開発チーム内でタスクの洗い出しとアサインを丁寧に実施 • Topic Branchを活用できるようにする ◦

    いわゆる「親」のブランチを作り、そこに「子」のブランチを小さく作ってレビュー・ マージする ▪ develop • Topic Branch(親) ◦ Work Branch(子) ◦ Work Branch(子) ◦ Work Branch(子)
  13. アンケートで定性面を評価する 58 • ポジティブだったコメント ◦ 「コメントが付くまでだいぶ早くなったので、修正をするのも早くできるようになった。また、マージを 早くできるようになったのでコンフリクトの発生頻度が下がった」 ◦ 「ファーストチェックのレスポンスが早くなったので、手戻りが少なく感じて快適だった」 ◦

    「レビュワー側もなるべく早く見れるように綺麗(理解しやすい)なPRを心がけるようになった」 • 課題が見えたコメント ◦ 「機械的な統計なので、金曜夜依頼のレビューがあって月曜にレビューしたりすると数値悪化したりする のは、うーんという気持ちだった。」 ◦ 「自分の行うレビューも含め、PRレビューの品質面で妥当なレビューを回せているか疑問が残る」
  14. コードレビューの改善をやってみてどうだったか • うまくいった ◦ 「コードレビューの時間」を目標に置いたことで、メンバーに強い意識付けができた ◦ Findy Team+を活用することでサイクル時間の可視化が容易にできた ◦ 取り組み後のアンケートによって「定性的な改善」が確認できた

    • うまくいかなかった ◦ 「コードレビューの時間」を目標に置いたことで、数値ハック的な動きが一部発生していた ▪ 夕方にコードレビュー依頼を投げない、など・・ ▪ チーム・メンバーと「自分たちがありたい姿」についてもっと話すべきだった ◦ 「PRを分割すること」を簡単に考えすぎて、メンバーと対立することがあった ▪ バックエンド、iOS / Android、Unityなどの技術領域でやりやすさが違うことを理解できていな かった ▪ 特定の領域で成功した取り組みが、他方の領域でもうまくいくとは限らない 59
  15. 「開発者体験」に着目する • フロー状態、認知負荷、 フィードバックループの3カテ ゴリ ◦ アンケートも上記のカテゴリのも と質問を作成 • 各カテゴリの値や、回答結果

    から改善ポイントを見つける 63 引用: 卓越したDevExが高める生産性 https://github.blog/jp/2024-01-24-good-devex-increases-productivity/
  16. 開発者体験サーベイ • サーベイの結果から、以下2つの問題を特定 ◦ フロー状態に入りづらいMTGの入り方になっている ◦ テスト環境に問題がある • それぞれ改善を実施 ◦

    MTGの入れ方を改善 -> 特定の時間にMTGを集中させるルールに変更 ◦ テスト環境改善のプロジェクトを進行 -> カバレッジの可視化、改善が進めた 66
  17. まとめ 73 • 開発生産性が高い状態 ◦ 「価値あるもの」を素早くユーザーに届けられる状態 ◦ 「フロー効率」を高めることが重要 • フロー効率を高めるには

    ◦ 「リソース効率」重視から脱却する ◦ 「フロー効率」を下げる要因を排除 • サイクル時間の改善 ◦ 時間全体を可視化し、問題を特定できるように ◦ 「コードレビューの時間」は意識とテクニックの向上で改善 ◦ 開発者体験をサーベイで具体的な改善ポイントを探索する