iOS bust #1

「一人で進めるモバイル開発
」
iOS Bash #1 1/18
@jumboOrNot

KENTARO HANEDA (27)@jumboOrNot
レアジョブでiOS/Androidの開発をしています。
あと趣味で色々作ったり、開発のお手伝いをしてます

このWebサービスの
アプリ化をしました
(iOS/Android準備中)

Webサービスのアプリ化で生じる問題・解決策
いろいろ取り組んできた試行錯誤を話します
（アプリエンジニア一人の場合）

① Web会社で一人でアプリを作る時の進め方
② Web会社で一人でアプリを作る実装パターン
③ Webの会社でアプリを育てていく手法

アプリ化をしよう！！
- ユーザーの継続率向上への期待
- ユーザービリティ改善・最適化
- ユーザーの可処分時間への
アクセスハードルの軽減
- マーケティングにおけるアプリチャネルの
獲得
- etc…
アプリ化のメリット

WEBサービスのアプリ化で起きる問題
何年もあるWebサービスのアプリ化を実施する
デザイン・開発を進めていく上で生じる問題例
「仕様がプロダクト」問題
「 APIチームのリソース不足」問題
「優先度決め」問題

• Webフロントの仕様書がない
• アプリ側でそれをまとめる時間もない
• 人がいなくなってわからない
• ビジネスロジックがクライアントに寄りすぎている
「仕様がプロダクト」問題とは？

どうやって解決したのか？
A. めちゃくちゃフィードバックしてもらう
フィードバックの仕組みを作りました 🎉

いいフィードバックをたくさんしてもらう必要がある
いつでもできる、誰でもできる
何を言いたいかを理解できるようにする
これらを技術で解決する
how

社内配布＋社内に「設置」することで気軽にフィードバックできるようにした。
バグだけでなく、使い勝手などももらうようにしたことで50件/1週でもらえた！
大きなバグもなく無事リリース、反響も◎
フィードバック内容を
すぐ観れるページを自作
どの画面からもフィード
バックを投稿できるよう
にした
社内にポップも設置して
盛り上げる

Slackに投稿するようにすることで、フィードバックを残したり管理する。
Androidでの試行錯誤をQiitaにも書いていますのでぜひ。
「Androidのアプリのフィードバックをslackに投稿する」
http://qiita.com/jumbOrNot/items/33a3340608fd9a6c1e38

Birtiseを使ってたくさん回す
- 無料プランで十分回せる
- 設定が簡単
- fastlane連携でitunesconnect
へのアップロードや
テスト配信可能
- 外部サービスと連携簡単

「APIチームのリソース不足」問
題
バックエンドエンジニア氏〜、APIのログ見たいので
Fluentd+Kibanaでよしなに・・・
・・・（忙しそうだ、頼めない）
リソースが、セキュリティが、
工数が・・・
「APIチームのリソース不足」問題とは？

A.ある程度のログやエラーに関してはアプリ側で
観れる仕組みを入れる
ユーザーの振る舞いや、APIのエラーコードなどを
ログサービスに落とすようにしました
「APIチームのリソース不足」問
題

他部署工数や都合で開発を止めない
人に頼んでそれが優先度後回しになって
開発が止まることは超ヤバイ
自分ですぐ動いて解決できることは全部やる
これらはサービスで解決する
why

Firebase/Flurryでログをほぼ全て落とすようにしてみた。
これでAPIチームに負担かけることなく意図せず出ている
エラーの頻度や他とのファネルが見れるようになった
＊ここが辛いよFirebase
FirebaseはUIも使いやすいし、広告と紐付けてCVの定義が
簡単なのでとても便利なんだけど
- イベントの値がBigQuery使わないと扱えない（有料）
- A/B TestのRemoteConfigも使い難い
- 痒いところに手が届かない 😢

最近のオススメの分析サービス
- 無料
- 過去のログまでイベント残っている
- イベントの値ごとに集計したりしやすい
- CSVでもエクスポートできる
- ファネル分析もできる
- 導入簡単
- iOS/Android対応
- 無料
- 直近のイベントログしか残ってない
- 集計はできないがダッシュボードが便利
- ユーザーのアクティブ/非アクティブなどが
見やすいので離脱を考えやすい
- 導入簡単
- iOS/Android対応
我が家はイベント管理のStaticなクラスがいて、一括で
値として落とせるものには値付きで、それ以外はイベント名煮含めて
落とすようにしています

• 一人だと適当なタスク管理になりがち
• 優先度も主観で決めちゃう
• 振り返ってみるとリリース後に何を検証したかったのか
見失う
• 質問された時、なんでやってるかすぐ言えず困る
「優先度決め」問題とは？

A. KPIツリーで何事も考え・話す
？？
？
？
いつ何時でも、すべての施策がここにある数値に
紐づくようにする

新規事業の数値を他と比較できるようにする
社内にアプリの数値がわかる人もいない
つまり標準化が必要。
それにはKPIツリーが適切なことが多かった。
なぜその施策を？効果は良かったの悪かったの？
を明確にし続ける
A. KPIツリーで何事も考え・話す
why

webと比較した
KPIツリーを作る

「webだと初回起動からの会員登録が
〇〇%なのでアプリでも同程度のパフォーマンスが
出ると思うので検証します」
いつもどの数値の検証をしている
かを全体への影響を考慮して
話せるようにする
そうするとやること
が明確になる
Webと常に比較することで
アプリで届けるべき体験を
数値をもとに話せる

入社してすぐアメリカへ行き
帰ってきてすぐ腕を骨折をし、
メガネを割りMacにヒビを入れる
〜リリース2ヶ月前、iOS設計時〜
全然時間ないし、
フィリピン人の部下が来るかもしれないし、
Androidも作らないといけないし、
APIもなんか変更して欲しいとこ多いし、
腕も骨折しているし、
メガネも割れているし・・・

一番変更の多いところは？？
追加箇所の多いところは？？
同じ書き方でかけるのは？？
忘れがちな振る舞いを明示的にかけるのは？
MVVM

ViewController ViewModel Repository Model
bind
Update
Update Update
Request Request
MVVM
RxSwift
▲
- 振る舞い・状態に関する部分は
全てRxSwiftでBind
- 状態を定義した基底ViewModelの実装
- Notificationも全てRxで書く、イベントは
Enumでタイポなどを防ぐ
- APIリクエストとはbindしない

bind
Update
Update Update
Request Request
MVVM
▲
- APIリクエストが予測できない
- キャッシュをうまく使う必要がある
- Repository Layerで抽象化
- Himotoki+APIKitでAPIリクエストを
ドキュメント化してAndroidで実装時に
これを見ながら作れるように
APIKit
＊最初困ったこと
- Realm使うならModelをClassにしなければ
- Model変更時にMigrationのコードがないと落ち
る
- 別スレッドに値を渡すと落ちる
- AND検索とかはサブクエリ使わないといけない

bind
Update
Update Update
Request Request
MVVM
◎iOSもandroidも同じアークテクチャで書ける
APIKit OKHttp
RxSwift RxJava
iOS Android

リリースすると・・・
ユーザーレビュー
ユーザー評価
社内評価
DL数
継続率
ファネル
DAUお問い合わせ
めちゃめちゃいろいろな数値とか
意見が来るようになる。

ユーザーレビュー
ユーザー評価
社内評価
DL数
継続率
ファネル
DAUお問い合わせ
❌直接受けない
固執しない
目的がぶれる
メンタル的にきつい
整理しきれない

ユーザーレビ
ュー
ユーザー評価
社内評価
DL数
継続率
ファネ
ル
DAU
お問い合わ
せ
なんでもKPIツリーと
紐付ける
着手すべきか、そうじゃないか、目的に対する意味
ある
数値かに確信を持てる

DLはKPIとして持たない方がいいのかもしれない
スモールスタートした時はDL数はプロダクトの品質に関わらないし、
ランキング・フューチャー枠に依存してしまう部分もあるし、
また予算次第でコントローラブルである。
重要な数値ではあるが、目標にしてしまうと手段が変わってくるので
KPIには入れないのが吉◎
あとWebにはない指標なので評価がブラックボックスになりがち

最後に
① Web会社で一人でアプリを作る時の進め方
② Web会社で一人でアプリを作る実装パターン
③ Webの会社でアプリを育てていく手法
「一人でモバイル開発」はできる◎
でもあくまでモバイル領域を検証する手段です。
一緒に進められる仲間がいれば選択肢は広がるし
協力者をシレッと増やしていくことが一番のソリューション

ということで
絶賛エンジニア・デザイン募集中です、英語喋れるようになる環境です
よろしくお願いいたします
（入社すぐアメリカ行って骨折しても優しくしてくれるいい会社です）
上場企業のアプリ事業を一緒に進めてくださいいいいいい！！！！
2/7に外国人エンジニアもくるミートアップ@原宿でやるのでぜひ！

iOS bust #1

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (6)

Similaire à iOS bust #1

Similaire à iOS bust #1 (20)

Plus de Ken Haneda

Plus de Ken Haneda (6)

iOS bust #1

Notes de l'éditeur