@Open network space

1. 「一人で進めるモバイル開発
」
第一回スタートアップIOS/ANDROID勉
強会 10/01 @JUMBOS5

2. 最近、
骨折って皆さんしました？

3. 転職して社内でたった一人の
アプリエンジニアになったし
骨折もしたけど無事リリースできたので
その話

4. 一人になった人の自己紹介
KENTARO HANEDA (27) @JUMBOS5
▸ 職種
▸ Marketing Dept. Mobile Developer
▸ 職歴
▸ Retty 👉 Yahoo!JAPAN（ヤフオク）👉 RareJob
▸ 仕事
▸ Go/iOS/Kotlin/Python/Marketing

5. いろいろ作ってます
作っているもの
「レアジョブ日常英会話アプリ」
フルスクラッチでSwift2.3で作りました
InShade
趣味で作りました
サーバはRails, アプリはSwift2.0です
androidもkotlin+RxJavaで作ったけど
リリースしてない
lanskip
週末で手伝ってます
web側はGo(Revel), AppleTVもあります

6. 一人になり
まして
導入

7. アプリを作るときの意思決定者の移り変わり
前々職
アプリ関係者 5人
- エンジニア
- デザイナー
- プランナー
前職
アプリ関係者 めちゃめちゃたくさん
- エンジニア（ベトナム・委託）
- デザイナー
- プランナー
- CS
- 偉い人
- その他
今
アプリ関係者 1,2人

8. 一人のアプリエンジニアのお仕事
▸ 企画
▸ 戦略立案、効果測定
▸ 開発
▸ 新機能、バグ修正、新OS、デバイス対応、デザイン
▸ 運用
▸ CS返答対応、クラッシュ監視
なんでもやりたいと言っ
たらほんとに
なんでもやることになっ
たでござる

9. なんでもできるとは言
ってない
（白目）
しかもリリース日
決まっている
しかもリリース
前に1週間アメリカ
行く・・・
〜 入社後すぐ 〜

10. 気づいた、
うまくやらないと
詰む

11. うまくやるための
進め方、
実装、
仕事の領域

12. うまくやるための
進め方

13. 進め方
WEBサービスのアプリ化
▸何年もあるサービスのアプリ化を実施する
▸様々な問題がある。
▸A. 仕様がプロダクト
▸B. APIチームのリソース不足
▸C. 優先度決め

14. A. 仕様がプロダクト
. 問題
仕様書がない、それをまとめる時間もない、人がいなくなってわからな
い、ビジネスロジックがクライアントに寄りすぎている
進め方

15. A. 仕様がプロダクト
. 問題
仕様書がない、それをまとめる時間もない、人がいなくなってわからな
い、ビジネスロジックがクライアントに寄りすぎている
. 取り組み 「めちゃめちゃドッグフーディングしてもらう」
進め方

16. 進め方

17. 進め方
PHPが動くサーバで
あればだいたい動きます
あとで公開します

18. A. 仕様がプロダクト
. 結果
バグや仕様漏れ、使用感についてサービスに詳しい社員から50件以上のフィー
ドバックがもらえた。特に大きなバグもなくリリースできた
. 取り組み 「めちゃめちゃドッグフーディングしてもらう」
• 自作のフィードバックツール
• すぐフィードバックできるUIもアプリに用意
• 社内カフェスペースに実機も用意
進め方

19. B.APIチームのリソース不足
. 問題
APIのログとかよしなに見てくれない
APIのログ見たいので
Fluentd+Kibanaでよ
しなに・・・
・・・（忙しそうだ）
リソースが、
セキュリティが、
工数が・・・
進め方

20. B.APIチームのリソース不足
. 問題
APIのログとかよしなに見てくれない
APIのログ見たいので
Fluentd+Kibanaでよ
しなに・・・
・・・（忙しそうだ）
リソースが、
セキュリティが、
工数が・・・
. 取り組み
「仕方ないので
自分で集めて自分で見る」
進め方

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

22. C. 優先度決め
. 問題
一人だと管理がザルになりがち、優先度も主観で決めちゃう
振り返ってみるとリリース後に何を検証したかったのか見失う・・・
進め方

23. C. 優先度決め
. 問題
一人だと管理がザルになりがち、優先度も主観で決めちゃう
振り返ってみるとリリース後に何を検証したかったのか見失う・・・
. 取り組み 「なにごともKPIツリーで説明する」
例）次のリリース何するの？
なんでUI変更なんてするの？
うごくやん！
進め方

24. テキストまず
WEBと比較した
KPIツリーを作る

25. WEBだと初回起動からの会員登録が
〇〇%なのでアプリでも同程度のパフォーマンスが
出ると思うので検証します
いつもどの数値の検証をしてい
るかを全体への影響を考慮して
話せるようにする
進め方

26. うまくやるための
実装

27. 入社してすぐアメリカへ行き
帰ってきてすぐ腕を骨折をし、
メガネを割りPCにヒビを入れる
〜 リリース2ヶ月前 〜
やばいとにかく時間がない・・・
しかも予想よりAPIも重い・・・
うまくキャッシュ使わなきゃ・・・
振る舞いが複雑になる予感、
データアクセスに闇が生まれそう
＿人人人人人人人人＿
＞ 助けて！OSS！ ＜
￣Y^Y^Y^Y^Y^Y^Y￣
実装

28. Reserve
View
Reserve
ViewModel
:StateView
Model
Teacher
DataStore
Teacher
Model
RxSwift
ViewController ViewModel Repository Model
APIKIT
MVVM
実装

29. Reserve
View
Reserve
ViewModel
:StateView
Model
Teacher
DataStore
Teacher
Model
RxSwift
ViewController ViewModel Repository Model
APIKIT
RxSwiftで振る舞いと
データの動きを全部
関連づける
ビルドはすごい重く
ナッタorz
MVVM
実装

30. Reserve
View
Reserve
ViewModel
:StateView
Model
Teacher
DataStore
Teacher
Model
RxSwift
ViewController ViewModel Repository Model
APIKIT
ViewModelはキャッ
シュやAPIを意識せ
ず
アクセスできる
MVVM
実装

31. Reserve
View
Reserve
ViewModel
:StateView
Model
Teacher
DataStore
Teacher
Model
RxSwift
ViewController ViewModel Repository Model
APIKIT
＊Realmを初めて使うときの注意点
- Relam使うならModelをClassにしなければ
- Model変更時にMigrationのコードがないと落ちる
- 別スレッドに値を渡すと落ちる
- AND検索とかはサブクエリ使わないといけない
この辺守ればめちゃ便利！！！！
MVVM
実装

32. 〜 リリースした後 〜
リリースしたら安心した。
たくさんアップデートしたいけど
申請ビルドとかテスト配信
めんどくさい
＿人人人人人人人人＿
＞ 助けて！誰か！ ＜
￣Y^Y^Y^Y^Y^Y^Y￣
助けるで
実装

33. bitrise
実装

34. ・こんなとこがいい
- 無料プランで十分回せる
- 設定が簡単
- fastlane連携でitunesconnect
へのアップロードや
テスト配信可能
- 外部サービスと連携簡単
- androidも使える
実装

35. うまくやるための
仕事の領域

36. . マーケティングをやる
ノンプロモでのオーガニックでの獲得を取るのはもちろん重要、
でも使える予算があるなら、それをもとにコンテンツがあるのにユーザーを集めないのは
もったいない！！
広告は設計できるアプリユーザーの入り口、
媒体ごとにどんなユーザーが入ってきているのか、
その人たちにどれだけお金をかけていいのか・・・
実装の優先度もそれで変わってくる。
仕事の領域

37. おわり
まとめ
▸bitrise最高
▸OSS最高
▸マーケティング超楽しい
一人でうまくやるために
「ロボット」
「周りの人に頼る仕組み」
「説明しやすい仕組み」
を作る・整理する

38. お約束
絶賛エンジニア・デザイン募集中です、英語喋れるようになる環境です
よろしくお願いいたします
（入社すぐアメリカ行って骨折しても優しくしてくれるいい会社です）
上場企業のアプリ事業を一緒に進めてくださいいいいいい！！！！