7営業日でAndroidアプリをリリースした話

Livesense, inc 藤村 宗彦

自己紹介

自己紹介• 藤村 宗彦(社内では@Godと呼ばれています)

• Livesense, inc

• 転職会議メディア開発担当

• Twitter : @kurobara

• Facebook : https://www.facebook.com/fujimura.munehiko

• blog :http://moonstruckdrops.github.com/

よくやること• Java / Groovy

• Ruby / Rails

• Android

• iOS(Objective-C / Swift)

• DevOps(最近流行のものとか)

• FullText Search

• etc…

Androidアプリ開発歴• 国内初のAndroid端末が発売される以前から(2008年前後)

• やり始めたキッカケ

• 学生時代で時間は潤沢にあった

• 当時のお仕着せガラケーアプリが嫌い

• Googleが開発している

• 前職はSIerでAndroidに関わる業務を色々

• プライベートはお勉強がてらに書くことが多かった

• キッカケができたので、最近真面目にアプリを実装し始めた

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

プロダクト ~INSPICE~ とは• 雑誌×WEBの最適解を目指した、良質な“衣・食・住”を提案するクオリティマガジンです。

• インテリア、家具、ファッション、雑貨、キッチン用品、オーガニックフィードなど、作り手のフィロソフィー(信念/哲学)に裏付けられた高品質かつ高感度なアイテムを通じて、みなさまの日々を充実させるコンテンツを随時お届けします。

• 世の中には、あまり知られていないけれど、こだわって作られている『質の良いモノ』はたくさんあると私たちは考えています。素材職人さんの技、ずっと使える耐久性と普遍性...。そういった質の良さや、商品に隠されたストーリーを広く知っていたたきたい。

• 私たちは、『質の良いモノ』にフォーカスし、商品の世界観/バックグラウンドにあるブランドヒストリー、あるいは作り手の信念 /哲学などを読み応えのあるストーリーとして読者にお届けいたします。

今回の話

• webサイト • iOS

• Android

Androidアプリ開発 にフォーカス

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

本題

7営業日リリースにおける3つのキーワード

1. プロジェクト運営

2. サービスの設計思想

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

1. プロジェクト運営

よくある流れ仕様を用意したからxx日までによろしく

デザインはざっくりこんな感じだけど、詳細はデザイナーにきいてやってくれ

デザイン用意しました。 xxは△△のような感じでお願いします。

デザイナー

ディレクター

エンジニア

あ、はい分かりました

辛くなってくる1. 機能の仕様が複雑

2. 実現が難しいデザインを渡される

3. UXが関わるので、意図が伝わりづらい

1. 画面切り替えのフェードイン/フェードアウトのタイミングや方式

2. タブ切り替え時のアニメーション

3. ページングなのか、スクロールなのか

4. etc...

4. できたものを見て、やっぱりこうしたい(by ディレクター/デザイナー)

5. コミュニケーションが少ないので、エンジニアサイドからの意見が減少

まとめると• ディレクターが決めたアプリの仕様が絶対

• アプリはウォーターフォールで固く作る

• エンジニアは、開発したアプリをデザイナーに確認のお伺いをする

• 開発に携わるメンバー間のコミュニケーションは最低限

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

意識して取り組んだこと1. 開発に対する勢い

• 「俺が考えた最強のInspice for Androidアプリを見せてやる！！」を掲げていた！！

2. ワクワクするものを作る

• 作るアプリが使いたいと思うもので無ければ、開発モチベーションが低下する為

3. 不要な機能を作らない

• 関わるメンバーの誰も必要としていない機能は無駄

• 事実、iOSとAndroidでは、機能差分がある

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

UI / UXのギャップを埋める• スクラップ&ビルドで、動くプロトタイプをさっさと用意する

• 紙でシミュレートと実機での動きは異なることがある

• プロトタイプは、とりあえず動作するレベルの雑さでもよい

• 確認のサイクルを早くする

• 席を隣や向かいにするなどの工夫

• ちょっとしたことでもすぐに共有 / 確認を実施

• 自動化が視野にないことが多いので、共有作業における手作業が増える

具体的にやったこと(1)• ワイヤーフレーム

• 画面や機能の構成をブレイクダウン

• 画面の表示構成を決定

• ペーパープロトタイプ

• UXの詳細をデザイナーと詰める

• 画面の動きのイメージをつける

具体的にやったこと(2)

• デザインモックに「Invison」を活用

• 具体的な表示イメージを確認

• 簡単なプロトタイプでUXの挙動を確認

具体的にやったこと(3)• 実データに近い内容で、捨てる前提のモックアップを作る

• スクロールにより目次の効果を期待したList

• 記事へのアクセスが近くなる効果を期待したGrid

• ページャーを使い、ページ送りの動きを期待したページング

2. サービス設計思想

開発前提• Web / iOS / Androidのプラットフォームに対応させたい

• それぞれのプラットフォームで、リッチなUI / UXを実現したい

• Android• webサイト • iOS

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

Webviewでもマルチプラットフォームはできるが...

• 処理の振り分けが必要

• 制約が出てくる

• 使用する技術

• Android / iOSでのUI / UXの動作

• 修正の影響が大きい

• iOSでは動作するが、Androidでは動かないといったこと等

• 修正をするためのネゴシエーションなど調整が必要

JSONでデータモデルを返すことで...

• 処理の振り分けが不要

• 制約無し

• プラットフォーム固有のリッチなUI/UXの実現

• 使用する技術

• 修正影響を考慮する必要無し

• 実装にフォーカスできる

• データモデルが変わらない前提

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

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

開発する環境の変化• 開発するにあたって便利な世界

デファクトになるようなライブラリも増加

面倒な処理(1)• HttpRequest

OkHttpを使いわかりやすく

面倒な処理(2)• Databaseを使用する

• カラムを指定したり等、selectクエリを書くのが面倒

• cursorをループさせないと値が取得できない

• 忘れそうになるクローズ処理が必要

Android向けORMであるDBFlowを使用

• モデルをこういう感じで用意

• こういう感じで使う

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

補足(2)• 当たり前ですが、ストリームからの受け取りを1度のみに修正

• 確認するとOkHttp側の実装はこうなってた

• テスト(ユニットテスト, functionalテスト)

• mockito + JUnit + Robolectric + Robotium

• Espresso

• Calabash-Android

• 配信ベータテスト

• Deploygate

• Google Developer Console

• クラッシュレポート

• crashlytics

• ACRA

テストやアプリ配信系のツール類

まとめ• エンジニアが意識を持って取り組むことで、プロジェクトの進め方を変えることができたこと

• 1つのプラットフォームの不具合が、他のプラットフォームに影響を及ぼさなくするための全体設計

• 素早くアプリ開発できる環境 / デファクトのライブラリも増えつつあるような状況が整いつつあること