家計簿サービス Zaim の iOS チームの @y_sumida です。

今回はアプリチームがどのように事業に関わっているのかについて書いてみました。

Zaim のアプリチーム

Zaim には Web 版とアプリ版がありますが、圧倒的にアプリを使うユーザーが多いです。
そのため、施策もアプリを使いやすく発展させる施策を優先します。
多くの場合、iOS/Android でなるべく差分がないように開発するため、両 OS のチームをまとめてアプリチームとして活動しています。

使っているツール類

GitHub

iOS/Android 版のそれぞれのリポジトリがあり、開発タスクを issue 登録して プルリクエストを作ってチーム内でレビューしてマージという、よくあるフローで開発します。
UI 変更の場合、デザイナーにレビューしてもらうこともあります。

仕様書用のリポジトリもあり Figma と合わせて仕様を管理しています。
仕様書の話はこちら。

Kibela

施策の概要、目的、ゴールなどをまとめたものを置いています。
規模によっては Figma だけの場合もあります。
開発者は Figma とともに要件の理解のために読み込みます。

また、個別の施策とは関係ない開発のためのルールや資料なども Kibela にまとまっています。

Figma

要件整理のアイデア出しからまとめ、デザインの仕様などに使います。
目に見えるものがある分、細かい部分の質問、指摘がしやすいです。

Slack

ユニットのチャンネル、アプリチームのチャンネル、他チームとのチャンネルなど、チーム内外のコミュニケーションに使用します。
直接話す必要がある場合は、Zoom、Meet、oViceなども使います。

Asana

プロジェクト全体の管理、他チームからの依頼タスクの管理など、すべてまとめています。
おそらく施策を進めるに当たって Asana が使えなくなったら一番影響が大きいのではないかと思います。

アプリチームの仕事

アプリチームの仕事はだいたい 4 種類にわかれます。

1. 所属ユニットの施策

アプリチームのメインの仕事です。

こちらで紹介したようにZaim ではユニット制で動いています。

人によって掛け持ちはありますが、アプリチームは全員同じユニットの所属です。

施策ごとにデザイナーからの要件の実現方法を調査・検討し、既存の仕様を含めた仕様の整合性を確認して、最終的に仕様書をプルリクエストとしてまとめます。
アプリチームとしては、ここまでを一人で担当することが多いです。

他のメンバーも要件検討中の Slack、Asana、Figma などを見られるので、全員で自由にアイデアを出し合っています。

仕様書と Figma のデザインが揃ったら、メンバーで分担して開発開始です。

最近の施策についてはこちらで紹介しています。

2. 別のユニットの施策や依頼

データ分析、広告など他のユニットから来る新機能の相談、既存の実装の調査、 AB テストの実施などに対応します。

クライアント案件やキャンペーン対応など、リリースしたい時期が決まっているものが多いです。
効率よくリリースするため、リリースを希望する時期が所属ユニットの施策のリリース時期と近ければ、できるだけ同じタイミングでリリースするようにお願いしています。

アプリチームから一人が参加して他チームと相談しつつ、要件および仕様を整理します。規模にもよりますが、開発は各 OS ごとに一人で開発することが多いです。

3. 要望、問い合わせ、不具合対応

ユーザーさんや社内からの要望、問い合わせの調査や不具合への対応です。

要望はサポートチームが日々の問い合わせに寄せられる要望を Asana に貯めています。
週に一度の「要望仕分け会」で内容を吟味し、実際に開発候補とするかを決めます。
開発候補になったものはアプリチームの Asana プロジェクトに移動します。

問い合わせの調査もサポートチームから Asana で調査依頼が来るので、調査の結果、不具合と判明したものはアプリチームの Asana プロジェクトに移動します。

4. アプリチーム内のタスク

チーム内で見つかった不具合や、リファクタリング、定期的なライブラリの更新など、必要なタスクは、各チームで予定を組んで進めます。

開発タスクの決め方

上に挙げた仕事の多くは、 Asana のアプリチームプロジェクトにタスクとして集めています。

集めたタスクをリリース希望時期、工数、バグの場合は影響範囲などから、次のリリースに含めるかどうかを決定します。

決まったタスクを各 OS の GitHub リポジトリに issue として登録します。
issue はプルリクエストする単位にもなるので、 Asana 上の大きめの粒度から実際の開発に合わせて分割して登録することが多いです。

以前は次回リリースに含めるタスクを決定するところまでを iOS/Android のリーダーが話し合って決めていましたが、最近、チーム全員で決めるためのミーティングを始めました。
だいたい二週間サイクルでリリースするため、隔週で次回リリースに含めるタスクについてアプリチーム全員で相談して決めるようにしています。

しばらくこの形で運用してみて、また見直す予定です。

現状の課題

試行錯誤の結果ではありますが、Asana と GitHub で二重管理になってしまっている部分があるのが課題です。
ただ、 Asana は社内にアプリチームの状況がわかるようにするため、 GitHub は実際の開発の粒度でタスクを管理するためと、それぞれ役割が違うこと、タスクの粒度が違うので集約すると混乱しそうなことなどから、現状この運用にしています。

問題はあるものの、 Asana はプロジェクトやタスクの親子関係などでタスク間の繋がり、まとまりがわかりやすくできるので、施策全体のリリースまでの管理や、他チームから発生したタスクの管理、コミュニケーションがしやすいと感じています。

最後に

Zaim のアプリチームが、どのようにZaimの事業に関わり、開発しているかを紹介しました。

まだまだ改善の余地はたくさんあります。一緒にアプリチームの改善を手伝ってくれる方、ぜひお話しましょう。