スクラム体制でのモバイルアプリGの変遷(2022年)

こんにちは!TUNAG事業部モバイルアプリGのカーキです。 2022年ももう残りわずかになってきましたね。 最近は、社内のポケモンマスターズトーナメントに向けて、ポケモンの育成に勤しんでいます。

スタメン TUNAG事業部のプロダクト部では今年から大規模スクラム(通称:LeSS)を導入しています。

今回のブログでは、大規模スクラムを導入した今年、モバイルアプリGがどのような体制で開発してきたのか、その変遷をご紹介できればと思います。

スタメンでの大規模スクラムの紹介

スクラム中でのモバイルアプリGの動きを紹介するのに、そもそもスタメンでのスクラムがどのように導入されているかについての前提が必要なので、先に紹介します。

大規模スクラムでは複数の機能横断のチーム(以下:フィーチャーチームと呼ぶ)に分かれています。 フィーチャーチームでは、メンバーの技術領域ではなく、機能で横断されたチームとして編成されます。

ただモバイルアプリの開発領域に関しては、技術の特殊性と元々開発していたメンバーが2人しかいなかったこともあり、現状は技術横断なグループとして存在しています。 そのため、Web領域では機能横断なものの、モバイル領域では技術横断のチームとなっています。

スクラムの導入前までは、こちらのように完全技術横断の組織構造になっていました。

  • 開発一部
    • アプリケーショングループ
    • SREグループ
  • 開発二部
    • モバイルアプリグループ
    • フロントエンドグループ

そして現在はこのような組織構成になっています。

TUNAG事業部のプロダクト組織図

技術領域に依らないチームになるため、モバイルアプリG以外はユニークな名前がついています。 実際にネーミングの場に立ち会ったわけではないので想像になりますが、メンバーが共通して好きな食べ物から来ているのだと思います(?)

元々、スタメンのモバイルアプリGはモバイルアプリのみを専属で開発しており、開発の途中で発生するAPIの実装に関してはWebのチームが開発していました。 そのため新しい機能の開発がモバイルで発生した場合は、基本的にはAPIが必要になるため、Webのチームと並走して実装する必要がありました。

本格導入前

モバイルアプリのチームへのスクラムの導入は事例が少なく、社内でも手探りの状態から始まりました。 またWebのフィーチャーチームの立ち上げを確実に行いたいという考えから、フィーチャーチームへの移行が優先的に進められました。

その間、モバイルアプリGはある種外注的に動いてプロジェクトに関わっていくことになりました。 もちろんモバイルアプリ開発の専任チームとしてモバイルアプリの体験に関しての提案は行っていましたが、一つのプロジェクトの仕様面に関しては担当しているチームが決めていました。

与えられた仕様を実装するだけなので、技術的な挑戦にはトライしやすい環境ではありました。 ただそのような関係では、プロジェクトに入って一緒に進めているという実感が薄く、メンバーのモチベーションの低下につながっていました。

スクラムの本格導入

ただモバイルアプリエンジニアからはその旨みを享受できていないこともあり、モバイルアプリGにもスクラムを導入していった方が良いのではという声は徐々に大きくなっていきました。 そこで今年の夏頃から徐々にチームにスクラムのプラクティスを適応していき、アジャイルな開発体制を目指していきました。

スクラムイベント

8月ごろからモバイルアプリGを一つのスクラムのチームとして扱ってスクラムイベントに参加するようになりました。 この時開発していたチャットのタスク機能はWeb、モバイル両方に新たに追加される機能になり、スクラムを本格導入するには絶好のタイミングでした。

モバイルアプリGの特色として、iOS/Androidの両OSを開発する必要があったり、Webのチームとの連携が必須なため、どのようにスクラムイベントを導入するのかは手探りの状態から、少しずつ改良を加えていきました。 プロジェクト内でスクラムイベントをどのように行ってきたのかを紹介します。

スプリントレビュー

スプリントレビューではモバイルアプリGの成果物としてデモとレビューを行なっています。

今まではモバイルアプリGのレビューの時間はなく、開発した機能に関しては一緒に連携して動いていたフィーチャーチームの成果物の延長としてデモを実施していました。 モバイルアプリGも一つのチームとして、独立したことでなぜデモを行うのかや、どのような観点でレビューを行うのかなど、より高い次元でスプリントレビューを行えるようになってきました。

スプリントレビューではプロダクト部全体でデモアプリの配信に利用している、App Distribution 経由で行っており、実際に自身の端末に入れて体験してもらうことを重視しています。

スプリントプランニング

スプリントプランニングはフィーチャーチーム全体で実施しているスプリントイベントで他のチームと一緒に行うようにしました。 今まではモバイルアプリGのみ、プロダクト全体とは別のプロダクトバックログで管理を行い、別日にスプリントプランニングを行なっていました。 そのため他のチームからモバイルアプリGがこのスプリントで何を行なっているのかが見えづらい状況でした。

以前まで使用していたモバイルのプロダクトバックログ(Githubのプロジェクトボードで管理)

この時のプロジェクトではお互いのチームが何をしているのかに応じて取れるアイテムが変わる可能性があり、全体のスプリントプランニングの場でモバイルアプリGのスプリントプランニングを実施しました。

リファインメント

チャットタスク機能全体のリファインメントはWebのメンバーと合同で実施をしました。 リファインメントはアイテムを分割し・それを見積もる工程になりますが、見積もりの中でそのアイテムの仕様について議論する必要があります。また大きなプロジェクトのリファインメントには PO や PdM が同席していることが多く、プロジェクトに関わるメンバーとして参加したことで、プロジェクトの背景やモバイルアプリでの見せ方などの議論も早い段階から行うことができました。

またリファインメントでのアイテム分割もWebのチームと一緒に行い、同名のアイテムとしてWebとモバイルでそれぞれを作成しました。これにより、Webのチームと同じストーリーポイントでアイテムを切ることができ、お互いの進捗を把握しやすくなるという利点がありました。

Webとモバイルとで同じストーリーでアイテムを作成する

ただその後の工数見積もりに関してはWebのチームとは分かれて実施をしました。 同じストーリーで作られたアイテムであっても実装する手段がWebとモバイルで異なっているため、見積もるポイントも当然異なるためです。 これらのように合同でリファインメントを実施したことで、一緒に仕様を固めることができ、モバイルアプリGからプロジェクトに参加している実感や開発へのモチベーションも高く行うことができました。

また当時はプロジェクトの中でiOS/Androidで同一の機能を提供するために、モバイルアプリに関するアイテムはiOS/Androidで分けない方針を取っていました。 この時はプロジェクトで開発をしていたのがiOS/Androidで2名しかおらず、実装できるOSにも隔たりがあったためです(自分は両OS実装できるが、片方はiOSしか実装できない)。 あえて同じアイテムで分けたことで、自分がAndroidの実装を先に終えたら相方のiOSの実装にサポートできるという体制に必然的になり、チームでゴールに向かっている実感がありました。

デイリースクラム

チームでのデイリースクラムは朝会として以前から実施しましたが、いくつか改良も加えてました。 朝会では以下の内容をチームメンバーで共有しています。 - 一人ずつ - 昨日やったこと - 今日やること - 困っていることや共有したいこと - 全体で - レトロアイテムの振り返り - 今日のスケジュールの確認

また以前までモバイルアプのプロダクトバックログとして管理していたGithubのプロジェクトボードをスプリントバックログとしてデイリースクラムに利用しています。 GithubのPRの状態と連携させることができるので、現在の作業の進捗状態が分かりスプリントバックログとしては優秀だと感じています。

他には、デイリースクラムの司会を順番に回すなどの工夫を行なっています。 司会が固定されてしまうと、慣れてくると受け身の姿勢で参加してしまうので、チーム全体で主体的に参加できるようにそうしています。

またそれに加えてプロジェクト全体でのデイリースクラムを実施しました。 プロジェクト全体で毎朝進捗の同期が取ることができるため、モバイルアプリGとしても動きやすくなりました。 特にモバイルアプリGではAPIの開発をWebのチームに依存しているので、その辺りの開発の優先度を上げてもらうなど、相互のコミュニケーションを取ることができるようになりました。 また開発をしていて感じた細かい仕様の相談などを早期に共有し、解決できるようになりました。

今後の展望

今後は、今のモバイルアプリGのフィーチャーチーム化を進めていくことを予定しています。 モバイルアプリ開発が主軸のフィーチャーチームでは、現状のチームにWebのエンジニアが数人参画することをイメージをしています。 このようなチーム構成にすることでAPIの改修や追加が必要なタスクであってもチーム単独でWebも含めたインクリメントを生み出すことができるようになります。 最終的にはスクラムの効果を最大限発揮した上でモバイル開発をより加速させることができると考えています。

また来年1月からTUNAG事業部は事業をより加速させていくために、東京での新規開発拠点の設立を予定しています。 東京支社の設立により、TUNAGのモバイルアプリエンジニア増え、モバイルアプリを主軸としたチームも近いうちに複数になってくることも想定しています。 そのような状況で、地理的な条件を超えて、モバイルアプリ開発を主軸としたチーム同士がどう自立して・連携をとっていくのかに関しては、まだまだ分からないことだらけです。

ただ一つわかっているのは、スタメンのモバイルアプリ開発はこれからさらに加速して面白くなっていくということです。 フィーチャーチーム化やチームの増加は新たな課題にはなりますが、アジャイルな組織はそれを乗り越えて、進化することができると確信しています。 株式会社スタメンでは、これから面白くなるモバイルアプリ開発組織を一緒に作り上げていくメンバーを募集しています。

詳細は以下のページをご覧ください

TUNAGの開発体制、使用技術については下記ブログ記事を参照ください。

TUNAGの技術と開発体制のすべてを紹介します!

また弊社では、オンラインサロン用プラットホーム FANTS というサービスも開発・運営しております。 ご興味がある方はぜひ下記のリンクをご覧ください。

FANTSの開発技術・開発組織を紹介します!

またスタメン Engineering Handbookとして体系的にまとめられたページも公開しています。 こちらも是非ご覧ください。