こんにちは。モバイルアプリケーション開発部の福井(Twitter: tinpay)です。この記事はChatwork Advent Calendar 2021の16日目の記事となります。
最近はオフィスにたまーに出社できるようになり、大阪オフィスのある福島駅界隈もにぎやかになってきました。
昨年1月から全社的に原則リモート勤務となり、一緒に働いているチームメンバーともオンラインでの交流ばかりになってしまいました。
その中で、今年の2月からモバイルチームを2つに分割して、モバイルアプリの新機能開発や運用保守を行ってきました。
今回は、チームをどのように分割してチームビルディングや課題に取り組んだのか、また、モバイルチームのスクラム開発をどのように強化していったのかを書きます。
- チームを分けたきっかけ
- 新チームでの運用をはじめてみた
- 1ヶ月経過 〜 出てきたコミュニケーション課題
- 2ヶ月経過 〜 期日に追われる日々
- 5ヶ月経過 〜 チームっぽくないチーム
- 8ヶ月経過 〜 目標に向かって進められるチームへ
- まとめ
チームを分けたきっかけ
7年前まで、Chatworkのモバイルアプリはクロスプラットフォーム開発を行っていました。（Titaniumを利用）
それが6年前にiOSとAndroidそれぞれをネイティブ化する流れとなり、iOSアプリ開発チームとAndroidアプリ開発チームに分かれて開発するようになりました。iOSとAndroidがネイティブ化され、別アプリとしてリリースした後も2021年1月まではプラットフォームごとのチームでの開発は続けられました。
iOSチームとAndroidチームに分けたときに見えてきた課題
そこから6年間、iOSチームとAndroidチームと別れて開発を行ってきたのですが、その間にいくつかの課題がでてきました。
1. iOS/Androidアプリが色々違っている
iOSとAndroidと別れて作業していると、アプリ間で以下のような違いがでてきました。
デザイン、機能仕様のずれ
別プラットフォームの人とあまりコミュニケーションをとらずに実装してしまい、デザインが統一されていないことがありました。その結果、機能は同じなのにUIが違う画面ができたり、そもそも機能的な部分が違っていることもありました。
ユースケースのずれ
同じ機能を作っているはずなのに、実装部分におけるユースケースがそろっていないため、例えばiOSエンジニアがAndroidアプリのコードを追えないことやその逆も然り。お互いが理解しにくいコードになっていました。
2. リソースに偏りがある
iOSアプリとAndroidアプリで同じ新機能の開発をした場合、プラットフォームの特性上、どうしても実装スピードに差がでてくることがあります。
Androidアプリの方は実装が終わったのにiOSアプリの方は実装がまだ完了しない、というようなケースがあり、プラットフォームごとにチームが異なる上に1チーム内にiOS/Androidアプリ両方書ける人もあまりいないため、リソースの余裕に偏りが生まれることがありました。
新チームでの運用をはじめてみた
そこで、2021年2月からiOS/Androidアプリエンジニアが混在している2チームに分けて開発を行いました。
チーム名はChatworkカラーでもある赤と黒をフランス語に訳した「Rouge(ルージュ)」「Noir(ノワール)」という名前にしました。この2チームは特に機能で責務をわけているわけではなく、フラットな関係のチームです。
この新チームでの運用に期待したことは、
iOS/Android両方のエンジニアが存在するチームで密にコミュニケーションをとり、こまめに認識をあわせることにより、仕様やユースケースのズレをできるだけ減らしてUIを合わせたい。
iOS/Androidのコードを両方書ける人を増やすことで、リソースの偏りを軽減したい。
という2点でした。
今までと同様、チームごとにスクラム開発を行ったのですが、2チームで1つのバックログで運用しはじめました。
PBリファインメントやスプリントプランニングは両チーム一緒に行い、プランニングでどちらのチームのスプリントゴールにいれるかどうかを決めました。また、レトロスペクティブはチームごとに行いました。
当初から、いくつか課題が出てくることは想定できたので、チーム分けの際には以下のような対策をとりました。（一部抜粋）
| 想定された課題 | 対策 |
|---|---|
| 不具合対応とか新OS対応などの運用保守はどのようにチームで作業分担するのか？ | どちらかのチームで不具合対応、新OS対応の実作業をチケット化して対応をすすめる。状況はチーム外にもきちんと共有する必要がある |
| 2チームに分けるとそれぞれのチームでやっていることがわからなくなりそう | 現在進めている作業をモバイルエンジニア全員に共有できる会議体を毎週設ける |
| iOS/Androidの垣根をなくすと更にリソースがなくなるのではないか？ | 初期は教育コストがかかるのは仕方がなく、投資と考える |
| iOSエンジニアが複数のチームに存在することになるので、コンフリクトが心配 | Pull Requestを小さくし、細かくdevelopにマージするようにする |
特に、iOSエンジニア同士、またはAndroidエンジニア同士のコミュニケーションが減ることへの懸念が大きかったため、横のつながりのコミュニケーションパスは念入りに設計を行いました。
運用後、1ヶ月後、2ヶ月後、5ヶ月後、8ヶ月後にチームメンバー内でアンケートをとり、ふりかえりを行い、少しずつ改善をすすめていきました。
1ヶ月経過 〜 出てきたコミュニケーション課題
| 良かったところ |
|---|
| iOS/Androidエンジニア間でのコミュニケーションが増えて、作業状況の把握がやりやすくなった。 |
| 今まで話していなかった人とコミュニケーションがとれるようになった。 |
| 課題に感じたところ |
|---|
| メインで作業しているプラットフォームのエンジニアとのコミュニケーションが減り、作業がやりにくくなったり作業内容が把握しづらくなった。 |
| 部署内でのコミュニケーションが減った。チームを跨いだコミュニケーションが減り、別チームのメンバーに声がかけづらい。 |
| チーム内だけでコードレビュー依頼をすると、レビューがあまり回ってこなかったり、1人にレビューが集中してしまったりした。 |
今まで少なかったプラットフォーム跨いだコミュニケーションは増えたと感じるものの、ずっと一緒に作業していたiOSエンジニア同士、Androidエンジニア同士のコミュニケーションが減ったことへのやりにくさを感じる人がでてきました。
1回目のアンケートの後に以下のアクションをとって様子をみました。
- チーム間のコミュニケーションが増えるように、情報共有ミーティングの時間を少し増やした。（30分 → 60分）
- チーム間でのコードレビュー依頼をOKとした。
2ヶ月経過 〜 期日に追われる日々
| 良かったところ |
|---|
| iOS/Androidとの機能やUIの差異が埋まっていくように感じる。 |
| メインではないプラットフォームのチケットを担当するハードルが下がった。 |
| iOS/Androidエンジニア間での共有がやりやすくなった。 |
| 課題に感じたところ |
|---|
| チーム合同でスクラムイベントをやると、すごく時間がかかってしまう。 |
| 別チームがやっている新機能開発の仕様がキャッチアップできない。 |
| 特定の機能に関するドメイン知識が一部の人に固まっている。（属人性） |
このときにとったアクションは、
- 作業時間を確保するために、ミーティングの時間や役割を整理した
- 新機能の仕様をモバイルエンジニア全員が理解できるように、共有会で仕様説明するようにした
です。
5ヶ月経過 〜 チームっぽくないチーム
組織の変更があり人数が減りました。
このころになると、進行中だったプロジェクトが終わり、個々が改善したかったことを立案したり、AndroidエンジニアがiOSアプリ開発をできるようになってきました。
ただ、プロジェクトが終わったことで「プロジェクトを問題なく完遂してアプリをリリースする」というチーム目標がなくなり、個々が別の作業を行うようになり、全員向いてる方向にばらつきがでてくるようになりました。
「チームとして開発している」というよりも、「個人が集まって開発している」という状況です。
| 良かったところ |
|---|
| メインではないプラットフォームのチケットを担当するハードルが前回から引き続き下がっていて、同じチームメンバーからも色々技術的なことを吸収することができる。カジュアルにコミュニケーションを取りやすい。 |
| やりたいことをやる時間は少しとれるようになってきた。 |
| 課題に感じたところ |
|---|
| プロジェクトが終わってしまうと、個々でタスクを進めているだけのような感じになるので、チームの良さを感じられない。 |
このとき、ちょうど別のチームでスクラムマスターをしていたメンバーがモバイルチームに戻ってきて、さらにはアジャイルコーチに支援いただくことになりました。
体制も少し変化した中で、今回は以下のようなアクションをとりました。
- チームの目標やプロダクトゴールをきちんと設定するために、モバイル専任プロダクトマネージャーにプロダクトオーナーとしてスクラムチームに入ってもらった。
- 成果を最大化するためにスクラム体制を見直し（アジャイルコーチ参画、スクラムマスター増員）、スクラムイベントのやり方を継続的に改善した。
- フロー効率を優先した開発を行うために、スプリント内ではできるだけ1チームが1プロジェクトだけにアサインされるようにして、モブプロも積極的に行うようにした。
8ヶ月経過 〜 目標に向かって進められるチームへ
Noirチームにメンバーが増え、プロダクトマネージャーにはプロダクトオーナーとしてスクラムチームに入ってもらいました。（Noirチームに人が多いのは、進めているプロジェクトの作業量に依ります）
また、Rougeチームのスクラムマスターを2人体制にすることで、スクラムを継続的に改善できるチーム体制としました。
このころになると、モブプロのやり方もこなれてきて、うまくタイピストを回しながら進められるようになりました。
PBIにはDoneの定義や受け入れ条件を記入するようになりました。また、少し形骸化していたデイリースクラムにもテコ入れして、バーンダウンの確認、ゴールを達成できそうか確認、モヤッとしていることはあるのか、今日の気分など、チーム全員が今のスクラムの状況が把握できるように工夫しながら改善を進めました。
これらの取り組みが功を奏して、全員がスプリントゴールに対して意識できるようになってきました。
| 良かったところ |
|---|
| モブプロをすることで知識を共有でき、属人性も軽減されていることが実感できた。 |
| デイリースクラムでスクラムやチームの状況が把握できるように改善されていった。 |
| スプリントゴールを意識して、チームで開発していることが実感できるようになってきた。 |
| 課題に感じたところ |
|---|
| そもそも職能別で分けられている組織でスクラムがフィットするのかどうか気になる。 |
| チーム内にiOSエンジニアが多いため、どうしてもチーム内の会話がiOSの話に偏りがちになる。 |
| 2チーム間のコミュニケーションが減っている。 |
まとめ
今年2月時点で課題に感じていたiOSエンジニアとAndroidエンジニアとの壁のようなものはかなり無くなってきたと感じています。
また、現在Chatworkでは新アーキテクチャ、および新組織構造への改善を行っているところで、Scrum@Scaleの導入をすすめています。
会社としてスクラム体制を進めていく上で、モバイルチームにおけるスクラム開発の強化を行えたことは非常に良かったなと感じています。
今後、さらにプロダクトの開発スピードや品質をあげていく必要があり、まだまだ課題がたくさんあります。事業拡大に向けて今後も継続的に改善していきます。
...そこで
このモバイルアプリのチーム開発に少しでも興味を持った方、カジュアル面談をしてみませんか？「そもそもなぜスクラム開発をしているのか」、「どういうアーキテクチャーを採用しているのか」などなど、現状の開発についていろいろお話できることがあると思います。
興味のある方、是非下記のMeetyまでお申し込みください。お待ちしております。
