第一回 目黒スタートアップ勉強会での発表 http://connpass.com/event/14407/

1. 7営業日でAndroidア
プリをリリースした話
Livesense, inc
藤村 宗彦

2. 自己紹介

3. 自己紹介
• 藤村 宗彦(社内では@Godと呼ばれています)
• Livesense, inc
• 転職会議メディア開発担当
• Twitter : @kurobara
• Facebook : https://www.facebook.com/fujimura.munehiko
• blog :http://moonstruckdrops.github.com/

4. よくやること
• Java / Groovy
• Ruby / Rails
• Android
• iOS(Objective-C / Swift)
• DevOps(最近流行のものとか)
• FullText Search
• etc…

5. Androidアプリ開発歴
• 国内初のAndroid端末が発売される以前から(2008年前後)
• やり始めたキッカケ
• 学生時代で時間は潤沢にあった
• 当時のお仕着せガラケーアプリが嫌い
• Googleが開発している
• 前職はSIerでAndroidに関わる業務を色々
• プライベートはお勉強がてらに書くことが多かった
• キッカケができたので、最近真面目にアプリを実装し始めた

6. 7営業日でリリースしたもの

7. プロダクト INSPICE とは
• 雑誌 WEBの最適解を目指した、良質な 衣・食・住 を
提案するクオリティマガジンです。
• インテリア、家具、ファッション、雑貨、キッチン用品、
オーガニックフィードなど、作り手のフィロソフィー(信
念/哲学)に裏付けられた高品質かつ高感度なアイテムを
通じて、みなさまの日々を充実させるコンテンツを随時
お届けします。
• 世の中には、あまり知られていないけれど、こだわって
作られている『質の良いモノ』はたくさんあると私たち
は考えています。素材職人さんの技、ずっと使える耐久
性と普遍性...。そういった質の良さや、商品に隠された
ストーリーを広く知っていたたきたい。
• 私たちは、『質の良いモノ』にフォーカスし、商品の世
界観/バックグラウンドにあるブランドヒストリー、ある
いは作り手の信念 /哲学などを読み応えのあるストーリー
として読者にお届けいたします。

8. 今回の話
• webサイト • iOS
• Android
Androidアプリ開発
にフォーカス

9. 雑誌のようなインターフェース
のアプリ

10. 本題

11. 7営業日リリースにおける3つ
のキーワード
1. プロジェクト運営
2. サービスの設計思想
3. Andoirdアプリを取り巻いた環境

12. 1. プロジェクト運営

13. よくある流れ
仕様を用意したからxx日までによろしく
デザインはざっくりこんな感じだけど、詳細
はデザイナーにきいてやってくれ
デザイン用意しました。
xxは△△のような感じでお願いします。
デザイナー
ディレクター
エンジニア
あ、はい分かりました

14. 辛くなってくる
1. 機能の仕様が複雑
2. 実現が難しいデザインを渡される
3. UXが関わるので、意図が伝わりづらい
1. 画面切り替えのフェードイン/フェードアウトのタイミングや方式
2. タブ切り替え時のアニメーション
3. ページングなのか、スクロールなのか
4. etc...
4. できたものを見て、やっぱりこうしたい(by ディレクター/デザイナー)
5. コミュニケーションが少ないので、エンジニアサイドからの意見が減少

15. まとめると
• ディレクターが決めたアプリの仕様が絶対
• アプリはウォーターフォールで固く作る
• エンジニアは、開発したアプリをデザイナーに確
認のお伺いをする
• 開発に携わるメンバー間のコミュニケーションは
最低限

16. 辛いことを繰り返すことでエ
ンジニアが疲弊

17. 意識して取り組んだこと
1. 開発に対する勢い
• 「俺が考えた最強のInspice for Androidアプリを見せてやる！！」を掲げ
ていた！！
2. ワクワクするものを作る
• 作るアプリが使いたいと思うもので無ければ、開発モチベーションが低下す
る為
3. 不要な機能を作らない
• 関わるメンバーの誰も必要としていない機能は無駄
• 事実、iOSとAndroidでは、機能差分がある

18. エンジニアドリブンな開発の
流れに変える

19. UI / UXのギャップを埋める
• スクラップ&ビルドで、動くプロトタイプをさっさと用意する
• 紙でシミュレートと実機での動きは異なることがある
• プロトタイプは、とりあえず動作するレベルの雑さでもよい
• 確認のサイクルを早くする
• 席を隣や向かいにするなどの工夫
• ちょっとしたことでもすぐに共有 / 確認を実施
• 自動化が視野にないことが多いので、共有作業における手作業
が増える

20. 具体的にやったこと(1)
• ワイヤーフレーム
• 画面や機能の構成をブレイクダウン
• 画面の表示構成を決定
• ペーパープロトタイプ
• UXの詳細をデザイナーと詰める
• 画面の動きのイメージをつける

21. 具体的にやったこと(2)
• デザインモックに「Invison」を活用
• 具体的な表示イメージを確認
• 簡単なプロトタイプでUXの挙動を確認

22. 具体的にやったこと(3)
• 実データに近い内容で、捨てる前提のモックアップ
を作る
• スクロールにより目次の効果を
期待したList
• 記事へのアクセスが近くなる効果を
期待したGrid
• ページャーを使い、ページ送りの動きを
期待したページング

23. 2. サービス設計思想

24. 開発前提
• Web / iOS / Androidのプラットフォームに対
応させたい
• それぞれのプラットフォームで、リッチなUI / UX
を実現したい
• Android• webサイト • iOS

25. 全体構成
• よくある構成を取っている

26. Webviewでもマルチプラットフォーム
はできるが...
• 処理の振り分けが必要
• 制約が出てくる
• 使用する技術
• Android / iOSでのUI / UXの動作
• 修正の影響が大きい
• iOSでは動作するが、Androidでは動かないと
いったこと等
• 修正をするためのネゴシエーションなど調整が
必要

27. JSONでデータモデルを返すことで...
• 処理の振り分けが不要
• 制約無し
• プラットフォーム固有のリッチなUI/UX
の実現
• 使用する技術
• 修正影響を考慮する必要無し
• 実装にフォーカスできる
• データモデルが変わらない前提

28. マルチプラットフォームでサービス
が展開できるような設計思想を持つ

29. 3. Androidアプリを取り巻い
た環境

30. 開発する環境の変化
• 開発するにあたって便利な世界
デファクトになるような
ライブラリも増加

31. 面倒な処理(1)
• HttpRequest

32. OkHttpを使いわかりやすく

33. 面倒な処理(2)
• Databaseを使用する
• カラムを指定したり等、selectクエリを書くのが面倒
• cursorをループさせないと値が取得できない
• 忘れそうになるクローズ処理が必要

34. Android向けORMであるDBFlowを使用
• モデルをこういう感じで用意
• こういう感じで使う

35. 補足(1)
• OkHttpを使って以下のようなコードを書くと
「ストリームが閉じてるよ！」ってエラーが出て
怒られます

36. 補足(2)
• 当たり前ですが、ストリームからの受け取りを1
度のみに修正
• 確認するとOkHttp側の実装はこうなってた

37. • テスト(ユニットテスト, functionalテスト)
• mockito + JUnit + Robolectric + Robotium
• Espresso
• Calabash-Android
• 配信ベータテスト
• Deploygate
• Google Developer Console
• クラッシュレポート
• crashlytics
• ACRA
テストやアプリ配信系のツール類

38. まとめ
• エンジニアが意識を持って取り組むことで、プロ
ジェクトの進め方を変えることができたこと
• 1つのプラットフォームの不具合が、他のプラット
フォームに影響を及ぼさなくするための全体設計
• 素早くアプリ開発できる環境 / デファクトのライブ
ラリも増えつつあるような状況が整いつつあること