Skip to content

Instantly share code, notes, and snippets.

@gfx

gfx/mobile-team-checklist.md

Last active December 27, 2017 19:16
Show Gist options
  • Save gfx/9448b5a1205de0c7c7df6292f321762a to your computer and use it in GitHub Desktop.
Save gfx/9448b5a1205de0c7c7df6292f321762a to your computer and use it in GitHub Desktop.
Download ZIP
Raw
mobile-team-checklist.md

最初期 - 開発人数: 1人, リリース前

このフェーズはほぼすべてのことが唯一の開発メンバーのスキルとマインド次第で決まるので、チームとしてできることは極めて少ないです。また、この段階のプロジェクトはリリース前に捨てる可能性もあるので、導入コストの高い開発ツールはまだ必要ありません。

  • バージョン管理をしている
  • リポジトリへのアクセス権を広げた（上長やチームメイト、開発基盤的な組織に権限を渡しておく）
  • CIをセットアップし、最低限ビルドだけしている
  • コーディングスタイルガイドを用意した
    • （Androidの場合）.idea/codeStyleSettings.xml を用意してスタイルガイドに沿ってフォーマットできるようにした

初期 - 開発人数: 2人~, リリース前

開発人数が2人以上になると、お互いの作業を見えやすくして開発効率を落とさないような工夫が必要です。しかし、サービスの価値が確立している段階でなければ堅固さよりも開発速度を重視したいところです。

なお「最初期」と「初期」は一応分けましたが、最初からこの段階のタスクをすべてやってしまっても構わないと思います。たとえば私は趣味でもいくつかAndroidアプリを開発していますが、この段階のタスクはほとんどすべて実施済みです。

  • TDDしやすい環境をつくり、気軽にTDDできるようにした
  • CIでユニットテストを実行している
  • pull-request駆動開発をしている
  • 開発ブランチへのコミットをPR経由で行うようにしている
  • PRごとにCIを実行している
  • commit, PR, 起票, CIの結果などをチャットに通知している
  • 採用する技術について判断ポリシーをメンバー間で統一しておく

リリース前後　− 開発人数: 1人~, リリース前後

リリース前後については関連したタスクが非常にたくさんありますが、必要不可欠なタスクについては紹介しません。情報の共有と記録を心がけましょう。

また、ここで開発人数「1人~」となっているのは、成長の目処がたつまでは1人で開発するということがわりと一般的だからです。その場合、この前の「初期」タスクは必須ではなく、余裕があればやってもいいという程度です。人数が増えたら「初期」タスクを検討しましょう。

ところでAnalyticsやCrash reportのプロジェクトは本番用、開発用の2種類用意してください。開発版については、dev, stagingなどこまかく用意する必要はありません。

  • Analyticsを用意して、どういうイベントをとるか検討した
  • Firebase Crash ReportなどのCrash report toolを用意した
  • リリースサイクルを決めて関係者に周知した
  • リリースしてタグを作成した
  • リリースを社内にアナウンスした
  • 今後のリリースアナウンスの方法（フォーマット）を決めた
  • サポートチームとの情報共有の方法（フォーマット）を決めた

成長期 - 開発人数: 3人~, リリース後

この段階では、すでにサービスはある程度成功している、または成功しつつあり、安定したリリースサイクルを回すことが重要となってきます。たとえば、この前の段階まではQAチームは必ずしも必須ではないかもしれませんが、このころはQAチームと関わらずにリリースするのは危険でしょう。

  • 開発ブランチをprotectして直接pushを禁止している
  • pull-requestのCIが通るまでマージ禁止にしている
  • pull-requestごとに成果物をつくりテストアプリ配布サービスにデプロイしている
  • リリースエンジニアリングを文書化した
  • リリースエンジニアリングを行ったメンバーは直近四半期で2人以上いる
  • リリース候補の成果物をCIでビルドしするようにした
  • 実際にリリースする成果物のタグ生成をCIで行うようにした
  • AppStore, Google Playの新着レビューをチャットに通知している
  • コードフリーズするタイミングとQA期間を設けて関係者にアナウンスした
  • リリース前にQAを行っている
  • QAエンジニアがいてリリースに関わっている
  • QAチームがリリースの拒否権をもっている
  • リリース後の監視体制を整えて文書化した
  • Android SDKコンポーネントやライブラリのアップデートを定期的に行っている
  • 成果物のデプロイをツールで行っている
    • （Androidのみ） Google Play Developer APIをつかってstore listingをバージョン管理している
    • （Androidのみ） Google Play Developer APIをつかってAPKをデプロイしている
    • （iOSのみ）fastlaneをつかってIPAをデプロイしている

拡散期 - 複数のモバイルアプリチームが生まれ始めた

これは一つのサービスの成長とはまた別の軸ですが、複数のサービスを開発するようになると、知見の共有を検討しましょう。

  • 社内ライブラリのレジストリをたてて共通コードをライブラリとして管理できるようにした
  • チームを横断してこのチェックリストにあるような作業をするチーム（たとえば「モバイル開発基盤」）を設置する
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment