QualiArts Advent Calendar 2022 9日目の記事になります。
初めまして、IDOLY PRIDEでバックエンドエンジニアをしている朝倉です。
本記事では、IDOLY PRIDEのバックエンドチームが属人化解消のためにこれまでに取り組んできたことを紹介します。
はじめに
IDOLY PRIDEでは約1年半の開発期間の間に、QualiArtsのバックエンドとしてGo、gRPC、Cloud Spannerに初めて挑戦したり、ライブ・お仕事・フォト・メッセージなど数多くのゲーム機能を開発する必要がありました。そのため、2021年6月のリリースまでは、技術やゲーム機能への専門性を高めるために担当エンジニアをなるべく固定し、あえて属人化させることで品質や開発スピードを担保して無事リリースすることができました。
リリース後の運用フェーズになり、次の新規タイトルの開発のためにチームを離れるメンバー、新卒入社で新たにチームに参加するメンバーなどチームの体制も徐々に変化していきました。チームの体制が変化していくなかでも、新機能の追加や安定した運用が継続できるように属人化を解消していく必要があり、属人化解消のためにバックエンドチームで実際に取り組んだ内容を紹介したいと思います。
ローテーション
リリースまでは、クライアントとの通信基盤は〇〇さん、GKEなどのインフラ周りは□□さん、ライブは△△さんなど技術領域やゲーム機能単位で担当を固定していました。コードレビューも、その領域に詳しいメンバーで実施して品質や開発速度を担保していました。
リリース後ある程度運用が安定してからは、担当エンジニアの固定を少しづつ解消し、これまでのメンバーがサポートしながら、これまで担当したことのないメンバーが担当できるようにタスクをローテーションして進めています。コードレビューに関してもこれまで担当していたメンバーもサポートしつつ、GitHubのAuto Assignで下記のように設定しランダムにアサインされるようにしています。
スキルマップ
各メンバーのスキルや理解度を可視化するためスキルマップを作成しています。言語やフレームワークのなどの要素技術、ライブやお仕事などのゲーム機能、管理ツールなどのゲーム運用に関する機能、インフラ構成、公式サイトなどの周辺システムに至るまで必要なスキルや知識は200を超えました。各項目の頻度、影響度、難易度から算出した重要度と、各メンバーに記入してもらった理解度から優先的に属人化の解消を進めていく項目が可視化されました。半期に1度、項目の追加やメンバーの理解度の更新を行いスキルマップを最新の状態に保つようにしています。
作成したスキルマップを紹介します。
頻度：機能修正や調査が発生する頻度
影響度：障害や不具合が発生したときのユーザ影響の大きさ
難易度：機能の複雑さや特別な技術や知識が必要かどうか
理解度：全く知らない〜他メンバーに教えることができる
モブワーク
リリース作業やライブスキルの開発など、発生頻度が高く、特定のメンバーに作業が偏っている業務に関しては、同じ時間・環境でチームで協力して業務を行うモブワークという手法で作業方法や知識の伝搬を行いました。また、コロナ禍で全社的にリモートワークになり、新規メンバーと既存メンバーのコミュニケーションが少なくなっていたため、一緒に作業することでお互い知る機会にもなりました。
バックエンドチームで実施したモブワークの目的・進め方を紹介します。
モブワークの目的
- チームで作業することで知識の伝搬を行う
- 協力して課題を解決することでお互いを知る
モブワークの進め方（zoomで実施）
- 取り組む業務の説明（5分）
- 参加メンバーが同じ認識をもって、課題や作業を進められる
- 役割を決める（5分）
- ファシリテーター1名（作業の流れをみてタイムキープする人）
- ドライバー1名（画面を写して作業する人）
- ナビゲーターその他全員（画面を見て誘導する人）
- モブワーク（20分*2週）
- なるべく顔出しして、内職しないようにする
- 20分で役割を交代する
- 振り返り（10分）
コードリーディング
ショップやガチャなどの修正・調査の頻度高く、不具合によるユーザ影響の大きい機能についてはより理解を深められるようにコードリーディングを実施してしています。
進め方は、1週間前に機能のざっくりした説明やリーディング範囲の共有を行い、各自コードを読んで重要だと思ったところ・理解できなかったところなどスプシに記入してきて共有するようにしています。コードリーディングの学びをアウトプットしたり、誰かが理解できなかったところを他メンバーが教えたりすることでより学びが深まっています。
実際にコードリーディングで使ったスプシを紹介します。
みんなの知らない勉強会
IDOLY PRIDEのバックエンドチームでは、ゲームのバックエンド以外にも、公式サイトの管理などIDOLY PRIDEに関わるさまざまな周辺システムも扱っています。
スキルマップで各メンバーの理解度を可視化したところ、公式サイトなどの周辺システムを中心に属人性が極端に高く、どういうものなのかまったく知らないという機能があることがわかりました。これらの機能についてはまずは概要を理解して、何かあったときにどこを調べたらいいのかあたりがつけられるようにするため、詳しいメンバーが重要な概念や設計などを説明する「みんなの知らない勉強会」を開催しました。
公式サイトやTYPOLY PRIDEなどの周辺システム、プッシュ通知や問い合わせなどのゲーム機能等これまでに全10回開催されています。
副次的な効果として、勉強会用に作った資料がドキュメントとしてチームの資産にもなりました。
まとめ
今回は、IDOLY PRIDEのバックエンドチームが属人化解消のためにこれまでに取り組んできたことを紹介しました。
バックエンドチームの業務範囲はゲーム機能の開発からゲームインフラの管理、公式サイトなどの周辺システムの管理まで幅広く、属人化を一気に解消することは難しいですが、これからも新機能の追加や安定した運用を続けられるように少しづづでも属人化の解消に取り組んでいきたいと思います。
また今後は、作業の単純化や必要なくなった機能の棚卸しなど、必要となる知識を減らしていけるようなことも取り組んでいきたいと思います。