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

iOS bust #1

Embed Size (px)

Citation preview

Page 1: iOS bust #1

「一人で進めるモバイル開発」

iOS Bash #1 1/18

@jumboOrNot

Page 2: iOS bust #1

KENTARO HANEDA (27) @jumboOrNot

レアジョブでiOS/Androidの開発をしています。

あと趣味で色々作ったり、開発のお手伝いをしてます

Page 3: iOS bust #1

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

Page 4: iOS bust #1

Webサービスのアプリ化で生じる問題・解決策いろいろ取り組んできた試行錯誤を話します

(アプリエンジニア一人の場合)

Page 5: iOS bust #1

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

Page 6: iOS bust #1

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

Page 7: iOS bust #1

アプリ化をしよう!!

- ユーザーの継続率向上への期待- ユーザービリティ改善・最適化- ユーザーの可処分時間へのアクセスハードルの軽減

- マーケティングにおけるアプリチャネルの獲得

- etc…

アプリ化のメリット

Page 8: iOS bust #1

WEBサービスのアプリ化で起きる問題

何年もあるWebサービスのアプリ化を実施する

デザイン・開発を進めていく上で生じる問題例

「仕様がプロダクト」問題

「 APIチームのリソース不足」問題

「優先度決め」問題

Page 9: iOS bust #1

「仕様がプロダクト」問題

• Webフロントの仕様書がない

• アプリ側でそれをまとめる時間もない

• 人がいなくなってわからない

• ビジネスロジックがクライアントに寄りすぎている

「仕様がプロダクト」問題とは?

Page 10: iOS bust #1

「仕様がプロダクト」問題

どうやって解決したのか?

A. めちゃくちゃフィードバックしてもらう

フィードバックの仕組みを作りました🎉

Page 11: iOS bust #1

A. めちゃくちゃフィードバックしてもらう

いいフィードバックをたくさんしてもらう必要がある

いつでもできる、誰でもできる何を言いたいかを理解できるようにする

これらを技術で解決する

how

Page 12: iOS bust #1

A. めちゃくちゃフィードバックしてもらう

社内配布+社内に「設置」することで気軽にフィードバックできるようにした。バグだけでなく、使い勝手などももらうようにしたことで50件/1週でもらえた!

大きなバグもなく無事リリース、反響も◎

フィードバック内容をすぐ観れるページを自作

どの画面からもフィードバックを投稿できるよう

にした

社内にポップも設置して盛り上げる

Page 13: iOS bust #1

A. めちゃくちゃフィードバックしてもらう

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

Page 14: iOS bust #1

Birtiseを使ってたくさん回す-無料プランで十分回せる-設定が簡単- fastlane連携でitunesconnect

へのアップロードやテスト配信可能

-外部サービスと連携簡単

A. めちゃくちゃフィードバックしてもらう

Page 15: iOS bust #1

「APIチームのリソース不足」問題

バックエンドエンジニア氏〜、APIのログ見たいのでFluentd+Kibanaでよしなに・・・

・・・(忙しそうだ、頼めない)

リソースが、セキュリティが、工数が・・・

「APIチームのリソース不足」問題とは?

Page 16: iOS bust #1

どうやって解決したのか?

A.ある程度のログやエラーに関してはアプリ側で観れる仕組みを入れる

ユーザーの振る舞いや、APIのエラーコードなどをログサービスに落とすようにしました

「APIチームのリソース不足」問題

Page 17: iOS bust #1

他部署工数や都合で開発を止めない

A.ある程度のログやエラーに関してはアプリ側で観れる仕組みを入れる

人に頼んでそれが優先度後回しになって開発が止まることは超ヤバイ

自分ですぐ動いて解決できることは全部やる

これらはサービスで解決する

why

Page 18: iOS bust #1

A.ある程度のログやエラーに関してはアプリ側で観れる仕組みを入れる

Firebase/Flurryでログをほぼ全て落とすようにしてみた。これでAPIチームに負担かけることなく意図せず出ているエラーの頻度や他とのファネルが見れるようになった

*ここが辛いよFirebase

FirebaseはUIも使いやすいし、広告と紐付けてCVの定義が簡単なのでとても便利なんだけど-イベントの値がBigQuery使わないと扱えない(有料)- A/B TestのRemoteConfigも使い難い-痒いところに手が届かない😢

Page 19: iOS bust #1

最近のオススメの分析サービス

- 無料- 過去のログまでイベント残っている- イベントの値ごとに集計したりしやすい- CSVでもエクスポートできる- ファネル分析もできる- 導入簡単- iOS/Android対応

- 無料- 直近のイベントログしか残ってない- 集計はできないがダッシュボードが便利- ユーザーのアクティブ/非アクティブなどが見やすいので離脱を考えやすい

- 導入簡単- iOS/Android対応

我が家はイベント管理のStaticなクラスがいて、一括で値として落とせるものには値付きで、それ以外はイベント名煮含めて

落とすようにしています

Page 20: iOS bust #1

「優先度決め」問題

• 一人だと適当なタスク管理になりがち

• 優先度も主観で決めちゃう

• 振り返ってみるとリリース後に何を検証したかったのか見失う

• 質問された時、なんでやってるかすぐ言えず困る

「優先度決め」問題とは?

Page 21: iOS bust #1

どうやって解決したのか?

A. KPIツリーで何事も考え・話す

「優先度決め」問題

???

いつ何時でも、すべての施策がここにある数値に紐づくようにする

Page 22: iOS bust #1

新規事業の数値を他と比較できるようにする

社内にアプリの数値がわかる人もいないつまり標準化が必要。

それにはKPIツリーが適切なことが多かった。

なぜその施策を?効果は良かったの悪かったの?を明確にし続ける

A. KPIツリーで何事も考え・話す

why

Page 23: iOS bust #1

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

Page 24: iOS bust #1

「webだと初回起動からの会員登録が〇〇%なのでアプリでも同程度のパフォーマンスが

出ると思うので検証します」

いつもどの数値の検証をしているかを全体への影響を考慮して

話せるようにする

そうするとやることが明確になる

Webと常に比較することでアプリで届けるべき体験を数値をもとに話せる

Page 25: iOS bust #1

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

Page 26: iOS bust #1

入社してすぐアメリカへ行き帰ってきてすぐ腕を骨折をし、メガネを割りMacにヒビを入れる

〜リリース2ヶ月前、iOS設計時〜

全然時間ないし、フィリピン人の部下が来るかもしれないし、Androidも作らないといけないし、APIもなんか変更して欲しいとこ多いし、腕も骨折しているし、メガネも割れているし・・・

Page 27: iOS bust #1

一番変更の多いところは??追加箇所の多いところは??同じ書き方でかけるのは??

忘れがちな振る舞いを明示的にかけるのは?

MVVM

Page 28: iOS bust #1

ViewController ViewModel Repository Model

bind

UpdateUpdate Update

Request Request

MVVM

RxSwift

- 振る舞い・状態に関する部分は全てRxSwiftでBind

- 状態を定義した基底ViewModelの実装- Notificationも全てRxで書く、イベントは

Enumでタイポなどを防ぐ- APIリクエストとはbindしない

Page 29: iOS bust #1

ViewController ViewModel Repository Model

bind

UpdateUpdate Update

Request Request

MVVM

▲- APIリクエストが予測できない

- キャッシュをうまく使う必要がある- Repository Layerで抽象化

- Himotoki+APIKitでAPIリクエストをドキュメント化してAndroidで実装時にこれを見ながら作れるように

APIKit

*最初困ったこと- Realm使うならModelをClassにしなければ- Model変更時にMigrationのコードがないと落ちる

- 別スレッドに値を渡すと落ちる- AND検索とかはサブクエリ使わないといけない

Page 30: iOS bust #1

ViewController ViewModel Repository Model

bind

UpdateUpdate Update

Request Request

MVVM

◎iOSもandroidも同じアークテクチャで書ける

APIKit OKHttp

RxSwift RxJava

iOS Android

Page 31: iOS bust #1

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

Page 32: iOS bust #1

リリースすると・・・

ユーザーレビュー

ユーザー評価

社内評価

DL数

継続率

ファネル

DAUお問い合わせ

めちゃめちゃいろいろな数値とか意見が来るようになる。

Page 33: iOS bust #1

ユーザーレビュー

ユーザー評価

社内評価

DL数

継続率

ファネル

DAUお問い合わせ

めちゃめちゃいろいろな数値とか意見が来るようになる。

❌直接受けない固執しない

目的がぶれるメンタル的にきつい整理しきれない

Page 34: iOS bust #1

ユーザーレビュー

ユーザー評価

社内評価

DL数

継続率

ファネル

DAUお問い合わせめちゃめちゃいろいろな数値とか

意見が来るようになる。

なんでもKPIツリーと紐付ける

着手すべきか、そうじゃないか、目的に対する意味ある

数値かに確信を持てる

Page 35: iOS bust #1

DLはKPIとして持たない方がいいのかもしれない

スモールスタートした時はDL数はプロダクトの品質に関わらないし、ランキング・フューチャー枠に依存してしまう部分もあるし、また予算次第でコントローラブルである。

重要な数値ではあるが、目標にしてしまうと手段が変わってくるのでKPIには入れないのが吉◎

あとWebにはない指標なので評価がブラックボックスになりがち

Page 36: iOS bust #1

最後に

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

「一人でモバイル開発」はできる◎でもあくまでモバイル領域を検証する手段です。一緒に進められる仲間がいれば選択肢は広がるし

協力者をシレッと増やしていくことが一番のソリューション

Page 37: iOS bust #1

ということで

絶賛エンジニア・デザイン募集中です、英語喋れるようになる環境ですよろしくお願いいたします

(入社すぐアメリカ行って骨折しても優しくしてくれるいい会社です)上場企業のアプリ事業を一緒に進めてくださいいいいいい!!!!2/7に外国人エンジニアもくるミートアップ@原宿でやるのでぜひ!