スクラムでスマホアプリ開発する時の効率の良いスプリントの回し方
mixiグループアドベントカレンダー1日目です。
「家族アルバム みてね」の開発知見について書きます。 家族アルバムみてねとは今年の4月から正式にリリースして以来開発を続けている写真共有アプリです。
現在みてねは、エンジニア4名、コードの書けるデザイナー1名、他チームと兼任しているテスター1名というメンバーで開発しています。 特徴的なのは、スクラムを採用したチーム開発を行っていて、さらに可能な限り属人化を排除するためにiOS/Android/サーバー(Rails)の開発のタスク、 それぞれの分野に担当を持たせず全員がすべてのスプリントバックログを取っていくというやり方で進めていることです。
スクラムチームで、属人化を排除することによって色々なことが可能となるのですが、 今回は効率の良いスプリントの回し方（バックログの取り方）の話を書こうかと思います。*1
そもそも属人化って？
属人化とは、仕事の中のあるタスクの内容がその人にしかできないという、タスクが人に紐付いてしまっているという状態です。 一般的に、以下のようなことが言えるかと思います。
メリット
- タスク完了するまでの見積もりが正確だったり、遂行時間が短く済む
- 他のメンバーが同様の内容を学習する事が無いため、費用（この場合、人件費）対効果が良い
デメリット
- タスクに熟達した人が何らかの理由（入院、長期休暇、部署異動、転職）で出社できなくなるとそのタスクの進捗が停止する
- タスクに依存関係がある際に、人的リソースがうまく配分できない場合がある
特にスマホアプリ開発の現場では、よくiOS担当、Android担当、サーバー担当などの分業が行われていることが多いかと思われます。 分業自体が悪いというわけではないですし、各分野のスペシャリストな人材が揃っているならばメリットの部分の恩恵も大きいかと思います。
この辺の選択は、スクラムをベースに開発していたとしてもチームが一番パフォーマンスを発揮できる方法を各チームでとれば良いかと思いますが、 みてねチームには元々各プラットフォームのスペシャリストが存在していなかった*2ので、 属人性を排除していく方法でこれまで頑張ってきたという前提があります。
今回着目したいのは「タスクに依存関係がある際に、人的リソースがうまく配分できない場合がある」という部分で、 これが実際やってみると意外と馬鹿にならないのではないか考えており、今現在みてねチーム内で取り組んでるスプリント・バックログの着手の様子を紹介します。
リソース配分
例えば、エンジニア3名がiOS、Android、サーバーそれぞれ1つづつ担当し、テスター1名というチームが存在している時に、 一から新機能を作りiOSとAndroidで同時リリースをするケースについて考えてみましょう。
属人化したまま
属人化したままでは以下のような開発のフローが考えられます。
先行してAさんがAPIを開発し、それが終わった後にBさんとCさんがiOS/Androidを並行して開発してそのあとにテスト行うという流れです。 この場合、クライアント側であるモバイルアプリの担当のBさん, Cさん2名は、AさんのサーバーのAPIに依存しているため依存関係が発生して、空き時間が生まれ開発が始められない状態にあります。 *3 また、iOS/Androidのテストの時期が集中してしまうと、先に審査をするためにiOSがQAを行っている間、BさんはiOSのQAのバグ修正タスクなどを行えますが、 Androidの担当者のCさんは手が空くことになり、リソースに隙が生まれます。
属人化を排除した場合
属人性を排除した場合、このようにタスクを消化することができます。上の図とは異なり、各プラットフォーム（サーバー、iOS、Android）をみんなで順番にこなしていくスタイルです。
ポイントは、以下の3つ。
- 全てのプロダクトバックログをスプリント・バックログに分割する際に、可能な限り分業できる単位で分けて毎日依存関係順に着手する
- サーバーのAPIはクライアントよりも先に実装を行い、開発サーバーにデプロイしておきクライアントは実際に動いているAPIを利用する
- スプリント内で、iOSはAndroidよりも先に開発〜QAを終えてStoreへ申請し、iOSのQA始まった辺りからiOSの審査が通るまでにAndroidも開発する
1のスプリントバックログの分割とをうまくやるというのはなかなか難易度が高いですが、それなりに規模の機能を実装しようと分割できることがあります。 例えば、サーバーのAPI側で「DB設計〜モデルの実装」までのスプリントバックログは他のバックログに依存されてしまうかもしれないですが、 そのあとの「APIの実装」と「cronで回すscript」とかは並行に実装してもうまくいくという具合に、並列度を上げられるようにすると各プラットフォームの実装が素早くできるようになります。
また、2のようにクライアントも書いていく人たち自身が、APIを事前に素早く仕上げることで余計なモックサーバーなど立てずに済み、 APIの詳細も熟知した状態でクライアント側を実装できるようになります。
最後に、iOS・Androidの開発順番ですが、これは基本的にiOSを優先して実装していくことになります。 なぜならiOSアプリはQAを終了してもすぐにリリースすることが出来ず、AppStoreの審査を約7日前後待つ必要があり、その間に待ち時間が発生するからです。 iOS, Androidもサーバーと同様に並列度を上げられるようにスプリントバックログを可能なかぎり分割し、チームメンバーみんなで分担して開発〜レビューをこなしていきます。 同じ機能の実装であれば、Androidでも同じような設計やクラス名・メソッド名を利用できるので、細かな実装方法は利用している各フレームワークに則ったやり方になりますが、 開発やレビューのしやすさが圧倒的にあがるという副作用があります。
これらを頑張ると理想的には、属人化を排除してスプリントバックログを消化した場合に属人化して消化をした場合よりも完成が早くなってくれると嬉しいのですが、 今の所、圧倒的に早くなった！などの効果は体感できておりません。というのも、ここ1年弱ぐらい属人化を排除して開発を行っているので、属人化していた時との前後比較は難しいですが、 KPTの振り返りの度に出てきたProblemを元に、今のチームで効率が良くなるようにはどうすれば良いか？ということを地道に考えてTryしてきたのが、このようなリソース配分のやり方となります。
まとめ
スクラムでスマホアプリを開発する際に、サーバー、iOS、Androidの担当者を決めずに属人化を排除した際のスプリントの回し方について書きました。 まとめるとこんな感じかなと思います。
- 属人化を排除するとリソース配分がうまくできる可能性がある
- API -> iOS -> Androidの順で少しづつ開発していくのがオススメ
- クライアントを作る人がAPIも作るので無駄な諍いが無い
- モックサーバー立てたり、各プラットフォームでオレオレクラスが乱立したりしなくて無駄が少ない
- AppStoreの審査の待ち時間も有効に利用出来る
- チームにしっくりくるうまいやり方は自分たちで振り返りをする中で見つけよう
今回のやりかたが必ずしも他のチームでもうまくいくかどうかは分からないですが、参考になれば幸いです。 今回触れていなかった点として、そもそもどうやって属人化せずにみんながiOS/Android書けるようになるんだ？って点があるかと思います。 これもみてねではいろいろ取り組んでいますがまたあとで書こうと思います。
最後に、Advent Calendarだけでなく、みてねのカレンダー風アルバムでも楽しんでいただけると嬉しいです。 12月はお子様の写真でアプリ内を埋めていってください！*4
明日は、csakatokuさんのチケットキャンプのお話です。 よろしくお願いします。
