Upload
ken-haneda
View
505
Download
4
Embed Size (px)
Citation preview
「一人で進めるモバイル開発」
iOS Bash #1 1/18
@jumboOrNot
KENTARO HANEDA (27) @jumboOrNot
レアジョブでiOS/Androidの開発をしています。
あと趣味で色々作ったり、開発のお手伝いをしてます
このWebサービスのアプリ化をしました(iOS/Android準備中)
Webサービスのアプリ化で生じる問題・解決策いろいろ取り組んできた試行錯誤を話します
(アプリエンジニア一人の場合)
①Web会社で一人でアプリを作る時の進め方②Web会社で一人でアプリを作る実装パターン③Webの会社でアプリを育てていく手法
①Web会社で一人でアプリを作る時の進め方②Web会社で一人でアプリを作る実装パターン③Webの会社でアプリを育てていく手法
アプリ化をしよう!!
- ユーザーの継続率向上への期待- ユーザービリティ改善・最適化- ユーザーの可処分時間へのアクセスハードルの軽減
- マーケティングにおけるアプリチャネルの獲得
- etc…
アプリ化のメリット
WEBサービスのアプリ化で起きる問題
何年もあるWebサービスのアプリ化を実施する
デザイン・開発を進めていく上で生じる問題例
「仕様がプロダクト」問題
「 APIチームのリソース不足」問題
「優先度決め」問題
「仕様がプロダクト」問題
• Webフロントの仕様書がない
• アプリ側でそれをまとめる時間もない
• 人がいなくなってわからない
• ビジネスロジックがクライアントに寄りすぎている
「仕様がプロダクト」問題とは?
「仕様がプロダクト」問題
どうやって解決したのか?
A. めちゃくちゃフィードバックしてもらう
フィードバックの仕組みを作りました🎉
A. めちゃくちゃフィードバックしてもらう
いいフィードバックをたくさんしてもらう必要がある
いつでもできる、誰でもできる何を言いたいかを理解できるようにする
これらを技術で解決する
how
A. めちゃくちゃフィードバックしてもらう
社内配布+社内に「設置」することで気軽にフィードバックできるようにした。バグだけでなく、使い勝手などももらうようにしたことで50件/1週でもらえた!
大きなバグもなく無事リリース、反響も◎
フィードバック内容をすぐ観れるページを自作
どの画面からもフィードバックを投稿できるよう
にした
社内にポップも設置して盛り上げる
A. めちゃくちゃフィードバックしてもらう
Slackに投稿するようにすることで、フィードバックを残したり管理する。Androidでの試行錯誤をQiitaにも書いていますのでぜひ。「Androidのアプリのフィードバックをslackに投稿する」http://qiita.com/jumbOrNot/items/33a3340608fd9a6c1e38
Birtiseを使ってたくさん回す-無料プランで十分回せる-設定が簡単- fastlane連携でitunesconnect
へのアップロードやテスト配信可能
-外部サービスと連携簡単
A. めちゃくちゃフィードバックしてもらう
「APIチームのリソース不足」問題
バックエンドエンジニア氏〜、APIのログ見たいのでFluentd+Kibanaでよしなに・・・
・・・(忙しそうだ、頼めない)
リソースが、セキュリティが、工数が・・・
「APIチームのリソース不足」問題とは?
どうやって解決したのか?
A.ある程度のログやエラーに関してはアプリ側で観れる仕組みを入れる
ユーザーの振る舞いや、APIのエラーコードなどをログサービスに落とすようにしました
「APIチームのリソース不足」問題
他部署工数や都合で開発を止めない
A.ある程度のログやエラーに関してはアプリ側で観れる仕組みを入れる
人に頼んでそれが優先度後回しになって開発が止まることは超ヤバイ
自分ですぐ動いて解決できることは全部やる
これらはサービスで解決する
why
A.ある程度のログやエラーに関してはアプリ側で観れる仕組みを入れる
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と常に比較することでアプリで届けるべき体験を数値をもとに話せる
①Web会社で一人でアプリを作る時の進め方②Web会社で一人でアプリを作る実装パターン③Webの会社でアプリを育てていく手法
入社してすぐアメリカへ行き帰ってきてすぐ腕を骨折をし、メガネを割りMacにヒビを入れる
〜リリース2ヶ月前、iOS設計時〜
全然時間ないし、フィリピン人の部下が来るかもしれないし、Androidも作らないといけないし、APIもなんか変更して欲しいとこ多いし、腕も骨折しているし、メガネも割れているし・・・
一番変更の多いところは??追加箇所の多いところは??同じ書き方でかけるのは??
忘れがちな振る舞いを明示的にかけるのは?
MVVM
ViewController ViewModel Repository Model
bind
UpdateUpdate Update
Request Request
MVVM
RxSwift
▲
- 振る舞い・状態に関する部分は全てRxSwiftでBind
- 状態を定義した基底ViewModelの実装- Notificationも全てRxで書く、イベントは
Enumでタイポなどを防ぐ- APIリクエストとはbindしない
ViewController ViewModel Repository Model
bind
UpdateUpdate Update
Request Request
MVVM
▲- APIリクエストが予測できない
- キャッシュをうまく使う必要がある- Repository Layerで抽象化
- Himotoki+APIKitでAPIリクエストをドキュメント化してAndroidで実装時にこれを見ながら作れるように
APIKit
*最初困ったこと- Realm使うならModelをClassにしなければ- Model変更時にMigrationのコードがないと落ちる
- 別スレッドに値を渡すと落ちる- AND検索とかはサブクエリ使わないといけない
ViewController ViewModel Repository Model
bind
UpdateUpdate Update
Request Request
MVVM
◎iOSもandroidも同じアークテクチャで書ける
APIKit OKHttp
RxSwift RxJava
iOS Android
①Web会社で一人でアプリを作る時の進め方②Web会社で一人でアプリを作る実装パターン③Webの会社でアプリを育てていく手法
リリースすると・・・
ユーザーレビュー
ユーザー評価
社内評価
DL数
継続率
ファネル
DAUお問い合わせ
めちゃめちゃいろいろな数値とか意見が来るようになる。
ユーザーレビュー
ユーザー評価
社内評価
DL数
継続率
ファネル
DAUお問い合わせ
めちゃめちゃいろいろな数値とか意見が来るようになる。
❌直接受けない固執しない
目的がぶれるメンタル的にきつい整理しきれない
ユーザーレビュー
ユーザー評価
社内評価
DL数
継続率
ファネル
DAUお問い合わせめちゃめちゃいろいろな数値とか
意見が来るようになる。
なんでもKPIツリーと紐付ける
着手すべきか、そうじゃないか、目的に対する意味ある
数値かに確信を持てる
DLはKPIとして持たない方がいいのかもしれない
スモールスタートした時はDL数はプロダクトの品質に関わらないし、ランキング・フューチャー枠に依存してしまう部分もあるし、また予算次第でコントローラブルである。
重要な数値ではあるが、目標にしてしまうと手段が変わってくるのでKPIには入れないのが吉◎
あとWebにはない指標なので評価がブラックボックスになりがち
最後に
①Web会社で一人でアプリを作る時の進め方②Web会社で一人でアプリを作る実装パターン③Webの会社でアプリを育てていく手法
「一人でモバイル開発」はできる◎でもあくまでモバイル領域を検証する手段です。一緒に進められる仲間がいれば選択肢は広がるし
協力者をシレッと増やしていくことが一番のソリューション
ということで
絶賛エンジニア・デザイン募集中です、英語喋れるようになる環境ですよろしくお願いいたします
(入社すぐアメリカ行って骨折しても優しくしてくれるいい会社です)上場企業のアプリ事業を一緒に進めてくださいいいいいい!!!!2/7に外国人エンジニアもくるミートアップ@原宿でやるのでぜひ!