こんにちはモバイル請求書チームでAndroidEngをしているmananです。
はじめに
freeeのモバイル請求書アプリが9/6にリリースされましたね。 そこでモバイル請求書アプリでの開発についてオムニバス形式で紹介していく全3回の第3回として 開発していく中でのチーム体制の変遷の話。
チーム体制の変遷
最初のチーム体制
モバイル請求書アプリでは開発途中でチーム体制の変更がありました。 最初はiOS,Android混合のPride-AチームとPride-Bチームからなる体制となっていて、 AチームとBチームでそれぞれ片方は大きめの機能開発、細かめの機能開発を回すといった 割り振りで進めていくような体制になっていました。
最初のチーム体制の狙いとしては下記のようなものがありました。
- OS間での仕様差異をなくす
- QAで発覚してその分の手戻りが発生するみたいなことが過去あったので防ぎたい
- 機能の共通部分(ビジネスロジックやモデル定義など)をKMPで作ることで開発速度を上げたい
- OSごとにPMやPdM、デザイナー間で発生していたコミュニケーションをOS混合にすることで実質的なやり取りの窓口を減らして少なくする
- iOSの方が人数としては多かったので先行実装する形でAndroidが後追いしてAndroidの実装工数を短縮したい
ここで出てきた問題点
問題点として両チームで同じアプリを開発している状況だからなのか、 アプリをリリースするではなくあの機能を開発する部分に視野がいってしまい、 アプリ全体でのオーナーシップの意識を持ちづらいことがありました。
そのためこぼれだま的な細かい改修などに対して拾いにいきづらかったり、 いつアプリをリリースできそうか？という質問に対して機能単位での視野になってしまい 答えられないなどの反省点が見えてきました。
加えて上述のKMP を利用した共通部分の開発が想定していたよりも発生せず 開発速度の向上への寄与が少なかったこと、 請求書アプリ自体の開発が遅れてきたこともありチーム体制を変更することに。
変更後のチーム体制
前述していた問題点を解消するために以下のような意図を込めてOSごとのチームとなりました。
- 単純にOSごとのチームにすることで開発速度を上げられないか
- 実装周りの困りごとなどが解決しやすくなるなど
- OSごとになることで機能単位の視野をアプリリリースの視野にもっていく
- 仕様差異よりもリリースをまず優先
- 物は試しという気持ち(大事)
同日入社のnakaji-sanと自分がこの頃にはAndroidに加わったりで 以前に比べて人数も増えた形となりました。
体制を変えてみて
私が入社したタイミングで既にチーム体制を変更しようという話が出ていて、 変更以前を詳しく知らないため比較はあまり出来ませんが、
- 機能を作るというゴールからOSごとにアプリをリリースするまでのゴールが意識しやすくなった
- 実装周りではOSごとのチームになったことで実装周りのコミュニケーションが増えたり
- チームでのデイリーでもOSごとになったため話自体が進めやすくなったり。
- シンプルに人数が増えたので速度が上がったり(それはそう)
など個人的にもやりやすいかな〜と感じました。
あとは入社直後にチーム体制が変わるという話が出てどうなるんだろう？とか、 入社したばかりなので旧体制、新体制どちらにせよ慣れることには変わらないだろうとか 思いつつなんだかんだ気がついたらリリースまで走り切っていた印象が強いです(チーム内外の皆さんとてもお世話になりました🙇♂️)
そんな感じで無事リリースまではできましたが最初のチーム体制の時の狙いの一つであった OS間での仕様差異によるQA段階での手戻りなどがチラホラと発生していて、 まだまだチーム体制の改善の余地はあるのかなと感じています。
今後のチーム体制
10月からはモバイル請求書チームのエンジニアは 人事労務と請求書に半々で分かれて行くのでまた違ったチーム体制になる予定です。
iOSとAndroidが半々の混合チームとなりまた元の形に近いような運用になりますが 請求書アプリでのこの経験を活かしていければなという気持ち。
チーム体制がどうであれアプリへのオーナーシップ意識をチーム全員で持つことや、 各OS同士で更に密にコミュニケーションをとるなどは出来るはずなので意識しつつ言うは易く行うは難しかもしれませんが もっといい開発が出来るようにモバイル請求書チーム頑張っていきます！
