2015年振り返り
23:45までぐったりと寝ていて、23:52から書き始めたのですごいざっくりと振り返る
家族アルバムみてね
家族アルバムみてねを去年から開発していたけどちゃんと世に出たのは今年だった。 これまでずっとWeb開発ばかりだったけど、少人数チームの新規プロジェクトでiOS/Androidだけでなく、 Rails〜AWSなどのインフラまで全て担当するという感じで、似非フルスタックエンジニアにはなれた気がする。 今年の大半はみてねの開発について考え続けていたと思う。
7つの大罪、アルスラーン戦記、鉄血のオルフェンズ
日5枠のアニメ面白かった
ジャンプ＋
アプリで毎週ジャンプ読むようになった
Googleベストアプリ
そんな家族アルバムみてねがGoogleベストアプリ取れた。 喜ばしいけどまだまだ頑張りたい
渋谷区に引っ越した
シェアハウス解散ってことで、改めて一人暮らしになった。 渋谷区富ヶ谷いいところ。
来年も宜しくお願いします。
渋谷区に引越した
ここ2年半ほど卓球ハウスという目黒区にあったシェアハウスに住んでいたのだけど、この度シェアハウスそのものを解散するということで渋谷区に引っ越した。
2013年の6月末からシェアハウスをしていて、@gong023が大江戸RubyKaigiでシェアハウスしませんかと自分に声かけてきたのがその発端だったと記憶している。 当時、大学を卒業してそのまま学生の頃から住んでいた、大学からはめっちゃ近いけど狭くて駅から遠くて不便な場所に住んでいたのでたまたま引越したいと思っていた時期だったから 二つ返事でOKした*1そっからいろんな人に声かけたり物件探したりなんてのをやっていった。
住んでいる間は、住人全員がエンジニアなため他社ではこうやっているだとか最近こういうの作ったみたいな話ができてエンジニアとしては結構良い環境だった。 トルネでアニメが撮り貯められていきリビングで快適に見られて前よりもアニメを見るようになったり、たまにインターネットから人が遊びに来たりして面白かった。 家賃はシェアハウスにしては高かったがそれ相応の広くて良い家だった。あれと同じレベルの家に今後住むことって今後あるのか・・・？ってたまに考えけど都内だとかなり難しいかもしれない。 良い体験だった。
今回は、特に貼り付ける鶏肉を両手で持つおじさんの画像は特に無く引き続き転職せずに今の職場で働き続ける感じ。 会社が去年ぐらいから渋谷駅から3km圏内に住むと住宅手当3万円が支給されるようになった*2ので渋谷区に引越て消耗することにした。 このタイミングでの引越でマイナンバー周りがとにかく面倒くさかったが、とりあえずマイナンバーの通知書持って引越先の役所に持って行くといろいろ説明してくれたり対応してくれました。
渋谷区の富ヶ谷という地域の物件に決めて、最寄駅は千代田線の代々木公園駅だが、バスで渋谷駅まで通勤したり徒歩で往来できる。 卓球ハウスに住んでいた時からバス通勤をしていたのだが、バス通勤になると満員電車を避けられるのでとても良かった。 今回の物件を決める際の条件にもバス通勤可というのを念頭に入れて物件を探した。 富ヶ谷〜神泉近辺に住んでいる人いたら飲みにきましょう!!
引越て2週間ほど経ってインターネットがようやく開通して洗濯機とベッドは家に設置されたがシェアハウスに引越する際に もともと一人暮らししてた時に持っていたものはほとんど捨ててしまっていたので再び一人暮らしする際に必要なものはわりと揃っていない。 部屋が狭いので部屋に物を置くのは完全に部屋が片付いてからだなーと思っていたらもう年末になってしまったがようやく片付いた。 シンプルな部屋にしていきたい。
最後に、例のやつです。 www.amazon.co.jp
see also:
emacsでSwiftを書く
SwiftがOSSになったことで、いろんなところでSwiftを使えるようにこれからなっていくと思う。 そんなわけで、XcodeでだけじゃなくEmacsでもSwiftがかけると嬉しい。
メジャーモードは昔からある。
- chrisbarrett/swift-mode package.elで入るし、flycheck対応で本格的。Swift2.0の文法対応してない。
- swift/swift-mode.el at master · apple/swift · GitHub 公式のやつsyntax highlightだけ。Swift2.0の文法対応ずみ。
補完はどうやらRealmの中の人こと、jpsim氏のSourceKittenってツールによって実現できるらしい。 どうやら、XcodeをリバースエンジニアリングしてわかったXPCというプロトコルでsourcekitdと通信できるCLIらしい。
SourceKittenを使った補完のためのプラグインはすでにある。 auto-complete-mode, company-mode用はそれぞれあるが、前者はpackage.el対応してないし実際に試してみたけど通信が同期処理となっていて emacsが固まるしsourcekittenに与える引数が間違っているように見える。後者はcompany-modeを現在導入していないので試していないけど非同期に通信しているように見える。 copmany-modeのもダメだったらauto-complete-modeで動くやつを自分で書いてみたい。
スクラムでスマホアプリ開発する時の効率の良いスプリントの回し方
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で使用感がほぼ一緒なので両方のプラットフォームを 両方実装するような人たちにとってはすごいマッチしたライブラリーだと思う。ぜひみんな使ってみて欲しい。
