はじめに
ウェルスナビでiOSアプリ開発を担当している長（ちょう）です。
ウェルスナビには2023年6月に入社しました。
私の入社時点でモバイルアプリチームは存在していたものの、エンジニアの人数も少ない状態でした。
そんな少人数のモバイルアプリチームが、どのようにしてチームとして成長していったのか、
その軌跡をお話しします。
モバイルアプリチームの誕生
前述の通り、私の入社時点でウェルスナビにはモバイルアプリチームが存在していましたが
少人数でした(iOSエンジニア:2, Androidエンジニア: 1)。
そこからチーム責任者も入社し、エンジニアの人数も増えて、
新生モバイルアプリチームとしての業務が始まりました。
チームの課題
モバイルアプリチームとしての業務がスタートしましたが、
以下の課題がありました。
- 誰かどんな業務を担当しているのかわからない
- スプリントの終了間際になってから、チケットが終わっていないことが発覚する
- プルリクエスト(以下、PR)のレビュー時点で仕様の不備が発覚する
- チームメンバーごとに実装のスタイルが異なる
- etc ...
モバイルアプリチームは、2週間サイクルのスクラム開発を採用しており、
1スプリントごとに上記の課題を解決していきました。
課題への解決アプローチ
担当業務の可視化
チームメンバーが増えたことにより、業務量を増やすことができた一方で、
誰がどの業務を担当しているのかがわからなくなっていました。
そこで、誰がどの業務を担当しているか、その業務がどんな状態にあるか可視化することにしました。
可視化には、Notionのスプリントボードを活用しました。
業務を可視化したことで、チーム全体の業務状況が把握できるようになりました。
また、進捗の遅れが発生した際にも、他のメンバーがフォローしたり、業務の再分配できるようになりました。
スプリント内の進捗管理
ウェルスナビでは、原則2週間ごとにアプリのリリースを実施しており、
モバイルアプリチームもそれに合わせて2週間サイクルのスクラム開発を採用しています。
前述のようなスプリントボードでの業務可視化を行ってからも、
スプリントの終了間際になってから、開発チケットが終わっていないことが発覚することがありました。
そこで以下のようなアプローチを取りました。
- 毎日各チケットをどこまで進めるかを決める、確認する
- GitHubのPRステータスとスプリントボードのチケットステータスを連携させる
1.に関して、毎朝、毎夕にデイリーミーティングを実施し、その日の目標および目標の達成状況をチーム内で共有するようにしました。
やることだけではなく、どこまでやるのかを明確にすることで、
各チケットの何％が終わったのか確認できるようになりました。
また、その日の目標に満たない場合は、他のメンバーが早期にフォローできるようになりました。
2.に関して、GitHubのPRステータスとスプリントボードのチケットステータスを連携させることで、手動でのステータス更新を減らすことができました。
これにより、チケット側のステータス更新を忘れることがなくなり、スプリントの進捗管理がしやすくなりました。
仕様の明確化と共有
チームメンバーが増加に伴い業務量が増えた一方で、仕様に関する不備がPRレビュー時点で発覚することがありました。
PRレビュー時点での仕様不備は、開発の進捗を遅らせる原因となります。
そこで、仕様およびテスト項目を実装着手前に確定させ、チーム全体でレビューすることにしました。
実装着手前に仕様およびテスト項目を確定させることで、実装内容が明確になり、開発チケットごとになにがどこまで実装できているかどうかがわかるようになりました。
また、仕様とテスト項目をチーム内でレビューすることで、チームメンバー全員が各チケットの実装内容を把握でき、流動的に業務を再分配できるようになりました。
実装スタイルの統一
チームメンバーが増加したことで、メンバーごとに実装スタイルに違いがあり、
コードの可読性低下やメンテナンス性の低下が懸念されました。
また、PRレビュー時に実装スタイルの違いが指摘され、追加の修正が発生することがありました。
そこで、
- Linterによる警告表示
- コーディング規約の作成
を実施しました。
まずはLinterについて、
iOSでは SwiftLint、Androidでは Android Lint を導入しています。
以前からもLinterによるコードフォーマット統一は実施していました。
上記に加え、カスタムルールを定義することでLinterの標準で検知ができない複雑な実装パターンに対しても自動で警告を表示できるようにしました。
これにより、PRレビュー時に指摘される内容を減らすことができ、レビュワーの負担軽減につながりました。
コーディング規約については、Swift API Design Guildeline などを参考にし、
命名規則や記法に関する方針を明確にしました。
将来的には、コーディング規約に沿っていない実装があった場合に自動で警告を表示するようにしたいと考えています。
まとめ
ご紹介したような様々な改善策を実施し、モバイルアプリチームはチームとして成長してきました。
新生モバイルアプリチームとしての業務がスタートした時と比べ、安定したアウトプットを出すことができるようになりました。
また、チームメンバーが業務を共有、フォローし合うことで、チーム全体の業務効率が向上しました。
今後もチームとしての成長を続け、スピードと品質を両立しながらアプリを提供していきます。
最後に、ウェルスナビでは一緒に働く仲間を募集しています。
興味ある方は以下のリンクをご覧ください。
Discussion