スクラムでスマホアプリ開発する時の効率の良いスプリントの回し方
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さんのチケットキャンプのお話です。 よろしくお願いします。
Realm meetupでiOS、Androidの家族アルバムみてねの開発風景について話してきた
Realmとはmobile向けのDBなのだけど、みてねでは7月にリリースしたv1.5.0から利用していて、その経緯とか背景とか実装内容ついて話してきました。 内容的には他の人とか過去の発表と被るのを避けるためRealm的な話は薄くて、普段の開発スタイルとか同期APIの実装の話がメインだったりする。
あと質疑応答で、「今回の実装でAndroidとiOSで設計が違ってきた場所ってなんですか？」という質問があって「AndroidはRxJavaを使って通知を飛ばしてUIにデータを反映させてるが、iOSだとNSNotificationCenterを使って素朴に実装している」みたいな返答しちゃったけどiOSではモデルをKVOで監視してUIに反映の間違いでした。（細かい）
懇親会では、スクラムを導入したい・しているけどよくわからない的な方々とお話する機会があり、 うちではこうしてます〜とかスクラムを上手くやるのが目的ではなく良い製品を届けるのが目的なんだ〜みたいな偉そうなことを喋ったりしました。
弊社では全社的にスクラムを取り入れているおかげで、思考方法としてスクラムのような考え方が標準で出来るような人が 多いので今のチームでも多少は苦労していてもそれなりに良い体制で開発出来ているなーということが実感できた。
スクラムスクラム言っているけど俺自身、認定スクラムマスターでもなんでもないしスクラムという手法が好きなわけでもないけど、 良い製品を生み出すために日々改善していこうという目的意識の部分は好きでこうやって外部でも発表したりブログに書いたりしている。
Realm、非常にシンプルで強力だしiOS/Androidで使用感がほぼ一緒なので両方のプラットフォームを 両方実装するような人たちにとってはすごいマッチしたライブラリーだと思う。ぜひみんな使ってみて欲しい。
野球観戦
先月、社会人になってから初めて野球観戦しに行ったのだけど、野球場の開放感のある場所で ビール飲む体験がかなり良かったのでまた行きたくなった。
シルバーウィークに有給をくっつけてこのまま9連休コースなのだけど、旅行とか行く予定も無く暇なのでまた明日行ってみることにした。 前回は会社の同僚と行ったけど、今回は完全に気まぐれでいきなり行こうと思い立った上に平日なので特にだれとも予定合わせずに1人で行ってみる。 コンビニのコピー機でチケットを買うことも出来て会員登録も要らないので、今さっき明日の試合のチケットを買った。
小・中学生時代はヤクルトファンだったけど、今となっては知っている選手ほとんど居ない。 ホームラン打つたび会場がわーってなるの好きだ。
動画で学ぶモダンなiOS/Androidアプリ開発技術
iPhone6sとiPad Pro発表されましたね。早くXCode7をstore配布して欲しいです。
スクラムチームで属人化させずにiOSもAndroidもRailsもAWSも全部やっていく話 - ainameの日記
この記事で、スマホアプリのチーム開発のことを書こうと思って先週はちょっとリリース前とか飲み会で忙しかったのであまり手がついておらず、どうやって書いてくかを考えてはいたけれど書いてこうとすると大分壮大になっていくので、ひとまず日常的な行いを少しづつ書きためていき、リンクで参照できるようにしておくことにした。
ということで今回は、社内で最近行っているプラクティスというか勉強手法で、動画でスマホアプリの技術を学ぶ方法を紹介する。
続きを読む