📱

FY2022 アプリ開発グループの開発体制とAndroidチーム下期振り返り

2022/09/20に公開

こんにちは。

弊社ではiOS/Androidのネイティブアプリを提供していることをご存じの方も多いと思いますが、今まで開発についてのお話を対外的にすることはありませんでした。
本記事では現在のアプリ開発グループの開発体制について触れつつ、2022年度下期（3月〜8月）にAndroidチームが行った取り組みを紹介いたします。

アプリ開発グループについて

仕事全体の流れ

開発の流れ

現在ココナラでは、大きく分けて業務が2種類存在します。

一つは経営戦略やKPI指標を元にプロデュースチームが考えた施策、もう一つは他部署やユーザー様から上がった要望などを実施する見積タスクという形でまとめられています。
プラットフォームごとに分かれた部署が各施策・見積タスクに開発者をアサインし、担当になった開発者が別部署とも適宜連携をとりながら仕事を進めております。

アプリ開発グループからは、iOS/Androidの開発者を最低でも一人ずつタスクにアサインして対応することが多いです。
またこの時、iOS/Androidのどちらかの開発者がメインの担当者となり、iOS/Android共通の仕様がばらばらにならないようにプロデューサーと調整を行います。

アプリ開発の流れ

開発の流れ

見積タスク

見積タスクはグループマネージャーが開発者をアサインするか、開発者が自らが手を上げることで実施されます。
下記のフローを2〜5日程度の時間をかけてタスクを完了させます。

開発者はプロデューサー・依頼者・別部署の開発者と必要に応じて仕様調整を行う。
固まった仕様をもとに、実装を行う。
プロデューサーに動作確認をお願いする。
動作確認後、問題がなければリリースする。

施策

施策はプロダクトオーナー、プロデューサー、デザイナーがまとめた企画を、グループマネージャーが開発メンバーのシステム知識や経験を十分考慮した上でアサインします。
開発期間は1ヶ月〜4ヶ月と長いものが多く、開発期間中は各部署からアサインされたメンバーと一つのチームとしてコミュニケーションを取りながら開発を行います。

開発の流れは大きく分けて、設計 > 実装 > QA > リリース の４つのフェーズに分かれます。

1. 設計

画面デザイン・仕様を元に設計とタスクの洗い出しを行う。
デザインや仕様に問題がある場合は適宜調整をする。
洗い出したタスクを元にWBSを作成する。
チーム内でWBSや、設計に問題がないかレビューをしてもらう。
施策チーム内にWBSを共有し、工数などの認識合わせをする。

2. 実装

実装を開始する。
定期ミーティングを行い進捗に問題がないかや、実装開始してからわかった懸念点などを相談する。
MTGで要対応項目などがあった場合、対応する。
1~3を実装完了まで繰り返す。

3. QA

QAチームによるQAを実施。
バグや仕様抜けなどがあった場合、修正をする。
プロデューサーが修正率を確認し、リリース予定日にリリースが可能かを判断する。
リリース可能と判断された場合、チーム内でのリグレッションテストを行う。
クリティカルな問題が存在した場合は問題の修正を行う。

4. リリース

アプリの申請を行う。
申請通過を待つ。もし、リジェクトされた場合最優先で修正を行う。
申請通過を確認する。
リリース当日、バックエンド、フロントエンドのメンバーと連携をとりながらリリースする。
リリース完了報告を社内のSlackにする

アプリ開発グループの構成

グループマネージャー(GM)：1人
iOSチーム: 4人
Androidチーム: 3人

グループ毎のメンバー数で見た時、バックエンド開発グループ、フロントエンド開発グループと大きく人数差はありません。
しかし、アプリはiOS/Android両方の対応が必要なため、実質的には半分ほどのマンパワーしかないのが現状です。

そのため、アプリ開発グループの各メンバーには仕事に対しての責任感と、高いパフォーマンスが求められています。

FY2022のAndroidチームを振り返って

FY2022はどんな期だった？

来期に向けての準備期間
アプリのクオリティアップのための、開発フローの改善
新メンバーのオンボーディング

スタッツ

iOS

最新バージョン：v5.23.3
リリース回数：21回
クラッシュフリー率：99.79% (8月の1ヶ月間のクラッシュフリー率)

iOSクラッシュフリー率

Android

最新バージョン：v5.24.3
リリース回数：21回
クラッシュフリー率：99.77% (8月の1ヶ月間のクラッシュフリー率)

Androidクラッシュフリー率

施策での開発中にチェックポイントを設置

FY2022で開発チームに課せられた目標に、QA時のバグ発見率を全プロジェクト10％以下にするというものがあり、こちらを達成するためにはアプリ開発グループ内でのチェック体制を強化する必要がありました。

そのため、現在アプリ開発グループでは施策の開発期間中にQAを実施するチェックポイントの設置を行なっています。各チェックポイントで特定の機能まで実装を義務付けることで、プロデューサー・デザイナーから早い段階でフィードバックを受けられるようになりました。
それにより、開発終盤で「今更そんなことを言われても」という状況を軽減する一助になっています。

また、チェックポイント中にiOS/Androidの開発者同士でアプリのクロスチェックをすることで、お互いが認識合わせをせずに実装していた箇所を洗い出せるようにもなりました。

結果、プロジェクト初動での開発者の負担は増えましたが、開発終盤のQA期間中に出るバグ数が減ったことで、仕様変更や修正対応を余裕を持って対応できるようになりました。

QAタスクの管理方法の一新

スプレッドシート管理のQAタスク

ココナラでは発見したバグをプロジェクト毎に作成したスプレッドシートで管理しています。
しかし、スプレッドシートでは詳しい内容を記入するのが不向きなため、あまり内容が書かれず、プロジェクト終了後に調査内容や意思決定の理由などが追い難い問題がありました。
そのため、Androidチームでは全てのスプレッドシートへの記入をGithub上でチケット化して、修正方針や調査内容などを記載するようにしています。

チケット転記のコマンドラインツールの作成

上記の対応は非常に有用だったのですが、スプレッドシートの内容をチケットに転記するのに最低でも2分ほど掛かるというデメリットがありました。
QA期間中にチケットが必要な項目が20項目以上は出てしまうので、チケット転記自体が大きな手間となってしまいます。

プロジェクト後にログを追いやすいなどのメリットが多いとは言え、チケットを切ること自体に時間を取られてしまっては本末転倒です。
その問題を解決するため、Androidチームではコマンドラインツールを作成し、簡単にスプレッドシートの内容をGithubのチケット化できるようにしました。

コマンドラインツールの技術仕様

内部ツールで外部からは利用できないのであまり詳しくは書きませんが、以下のような仕様となっています。

コマンド

$ coconala-app-qa-helper-tool [-r row_num, … 複数指定可能] [-p setting_file_path]

処理のフロー