iOSとAndroidで展開しているアプリのプロジェクト管理方法
この記事はピクシブ株式会社 Advent Calendar 2017の17日目の記事です。
ぼくの所属しているチームではBOOTHという創作物のC to CマーケットプレイスのiOS/Androidアプリを開発しています。
世の中、1つのリポジトリで管理するウェブサービスを想定したプロジェクト管理方法はあれど、スマートフォンアプリを想定した方法はなかなかないと感じたので、ぼくたちがどのようにプロジェクト管理をしているか共有したいと思います。
こういう人には読む価値があるかもしれない
この記事を読むと何がわかるか
- 複数プラットフォーム/リポジトリのタスクを集約して管理する方法
- 使用するツール(Zenhub)とその運用方法
プロジェクト管理方法
前提
- ひとつのチームで継続的にリソースを確保できていること
- コミュニケーションが適宜行われること
使用するZenhubについて
GitHubのIssueをカンバン風に表現してくれたりするツールです。
使用感は動画を見てください。
ZenHub Product Tour from ZenHub on Vimeo
これのいいところは、ひとつのボードで複数のリポジトリのIssueたちを集約できるところです。また、GitHubと連携されているので、TrelloなどからGitHubといったりきたりする必要もありません。
Zenhubをつかうにあたっての基本的な用語
- Issue : ユーザーの課題を解決するために行うタスク。
- Epic : 複数のIssueをまとめるもの(○○機能、などいくつかのIssueを包含するもの)。Zenhubにある機能。
- やることリスト : プロダクトへ対する実施リスト。ディレクター/プロダクトオーナーは順序 = 優先度をに並べ替える。基本的に実装はリストの上から行う。Backlogとほぼ同義。
- トリアージ待ち : やりたいこと、をまとめたアイディアリスト。自由に、誰でも起票して良い。やることリストに入れていく。Iceboxみたいなもの。
- リリースインクリメント:作業は完了しているが、リリースはされていないもの(審査待ちなど) のリスト
運用フロー
スプリント(イテレーションと言ってもいい、開発期間の区切り)は火曜日から開始し、2週後の火曜日までとするサイクルとしています。
Day1
- 定例MTG
- 数値確認
- 前スプリントでやったことの進捗確認
- 次スプリントでやることの決定
- なにがそろったらリリースできるかの確認
- チームランチ
Day2~Day14
- 実装
Day1で決めたものを実装していきます。
- コードレビュー/動作チェック
基本的にチーム内で行っています。問題なければ、Closeせずにリリースインクリメントのリストに入れて、リリースされるまで保管します。審査などで手戻りがある可能性があるためです。
- リリース
週末対応を防ぐため金曜は避けます。基本的に火曜を目標とすることでルーチンにして突発リリースを防いでいます。
リリース前には他チームの人間にも軽く見てもらいリスクヘッジをします。
- 効果測定
特に数値に影響のあるリリース後は注視します。あらかじめEpic or Issueの時点で効果測定方法を確認しておくと「埋めてないイベントがある!」とかにならなくて安心です。
随時行うこと
- 朝会 : 毎日朝5~10分で「昨日やったこと、今日やること、共有したいこと」を話します。
- 全員:解決したい課題、アイデアをトリアージ待ちへepic or Issueとして作成する
- プロダクトオーナー/ディレクター:トリアージ待ちの中身を精査し、優先順位を元にやることリストの適切な位置に移動する
- プロダクトオーナー/ディレクター:やることリストの優先順位を決定する
- 全員:Issue or epicの仕様を詰める(必要に応じてメンバーを集めて議論する)
中長期的なマイルストーンは視覚化
目の前のプロジェクト管理についてはこのようにZenhubをつかいつつスプリントをまわしていくのですが、中長期的なマイルストーンについては別途視覚化しています。
直近のことだけではなく、ざっくりと何をどういう順番でやっていくのかを共有して意識を共通化することが目的です。
Q&A
Q.数値確認は2週間に1回しかしないの?
ディレクターは随時数値を確認していて、大きな変動があればチームに報告します。また、数値を見るダッシュボードはチームメンバーならいつでもアクセスできるようになっています。
Q.スプリントが2週間の理由は?
当初1週間単位でしたが、チームメンバーが課題解決に集中できる時間を増やし、それ以外の時間をできるかぎり減らすために2週間に変更しました。
これ以上長いと動きが鈍くなりそうなのでいまのところ変える予定はありません。
Q.予定していたより早く作業が終わった場合は?
やることリストの上からタスクを持っていきます。
Q.仕様定義はいつやるの?
随時必要なメンバーで行います。MTGを設けてから話し合うというよりは、誰かが用意した提案をもとに検討していくことが多いです。
Q.iOSとAndroidで足並みは揃えている?
基本的に、機能追加などの順番は揃えています。ただ、リソースの違いなどでどうしてもスピードは異なってくるので、とくにリリース日を揃えたりはしていません。また、無理にiOSにデザインを揃えたりはせず、OSに合った実装をデザイナーとエンジニアで相談しつつ進めています。
Q.やることリストはどう管理している?
iOS/Android/デザイン/API/運営でわけています。
Q.Zenhubを使うことは必須なの?
必須ではありません。GitHubのIssueをカンバンライクに整理できるならいいかなと思っています。
実はぼくたちももともと類似ツールのGitHub Projectsを使っていたのですが、チームメンバーに業務委託の方がジョインして、権限問題からZenhubに移行した経緯があります。(Read/Writeしてほしくないリポジトリの管理)
2つのツールは似ていて、それぞれにいいところ弱いところがあります。
GitHub ProjectsはIssueにひもづけなくてもよいカード作成機能があり、運営のちょっとしたタスクなどをメモするのに便利です。あと無料。ただ無骨。
ZenhubにはEpicやEstimate,BurnDownChartといった豊富な機能、直感的なソート機能などがあります。ただし、必要なリポジトリから必要なIssueだけをカンバンに載せることができないなど不便な点もあってどっちもどっちです。
おわりに
社内でも別のチームではまた違うやり方で進めていますし、聞いたところではふせん紙オンリーで管理しているところもあるそうです。
そのくらい向き不向きは人によって異なるので、自分たちに合っていると思うやり方を模索するのがよい(というかそれしかない)と思います。
ただ、この記事がその方法を模索するときのひとつの助けになれば幸いです。
ぼくたちも、これからもよりよい進め方を模索していきたいと思います。
ピクシブではよりよいプロジェクト管理を模索できる方をお待ちしておりますので、中で変えていってみせるぞ!という方はデザイナー、エンジニアなど職種問わずご応募ください!