Shibuya.apk #20 https://shibuya-apk.connpass.com/event/72347/ にてお話した（する）内容です。 Qiita https://qiita.com/kikuchy/items/0c43eb014ed5c9b83e9d

1. 新規Androidアプリ開発において
何より大切なこと
@kikuchy

2. Who?
● @kikuchy
● 菊池 紘
● 株式会社Diverse（ミクシィグループ）
● 一人で新規アプリ開発やってる最中です
● 求む、Androidエンジニア！！（iOSエンジニアも）

3. https://qiita.com/kikuchy/items/0c43eb014ed5c9b83e9d

4. 今日の話はエモい話です
技術の話じゃなくてすみません …

5. 想定リスナー
● 職業Androidエンジニア
● 自社サービスの開発に携わっている、またはアプリの開発を受注した方
● コードがない状態から開発することになった、または開発したい方

6. 一人で新規アプリの開発！？

7. 押し寄せる不安
● この設計を採用して大丈夫なんだろうか…
● どんな勢いで仕様が拡大していくのだろう…
● 今は一人だけど、後で何人増えるんだろう…
● 守りやすい設計規約になっているかな…
● ここはディティールを詰めたほうが良いのか、それとも…
● 開発の順番的に、これは後に回して良いのかな…
● このライブラリ使っても良いかな…

8. そんな不安なく
開発しています

10. プロダクト
オーナーへの
ヒヤリング

11. コンセプトが決まれば戦略も戦術も決まる (1)
● 提供するサービスのコンセプトを知っている（はず）なのは
プロダクトオーナー
● プロダクトオーナーからコンセプトを聞き出す
一緒に明確にしていく
● ビジネスサイドとエンジニアサイドで共通認識を持っておく

12. コンセプトが決まれば戦略も戦術も決まる (2)
あとはコンセプトに合わせて選択肢を選んでいけば大きく外すことはない。
ここをどうするか/コンセプト通りにできるかどうかがエンジニアの腕の見せ所。
● 設計
● 言語
● ライブラリ
● 機能の優先順位
● 力の入れかた/力の抜き方
● レビュー方針
● テストの役割
● などなど

13. ヒヤリングをしよう

14. 聞くべきこと
最低限は以下の３項目
1. アプリが提供する重要な価値
2. 開発リソース
3. コードベースの寿命

15. 1. アプリが提供する重要な価値
アプリを通して何を提供したいのか？
● アプリの存在価値、利用してもらえる動機、収益の理由
● これがわかると決められること
○ 機能の優先順位
○ 力の入れ方/力の抜き方

16. 2. 開発リソース(1)
● リソース＝時間と人と金
○ 開発に使える残り時間（スケジュール）
○ エンジニアの人数とレベル
○ 予算
● リリース後に気になるこれも
○ アップデートのペース
○ 大規模な施策の予定
○ 人員増減の予定
○ 多言語対応

17. 2. 開発リソース(2)
● わかると決められること
○ 設計
○ 言語
○ ライブラリ
○ レビュー方針
○ などなど

18. 3. コードベースの寿命
コードはいつか必ず腐る
● 実際にかかる保守コストが想定保守コストを上回ったら寿命
● 大規模リファクタリングが必要になるが…
○ 予めそのコストを認識しておいてもらう
○ いつまで腐らせないで運用すれば良いのか考える
○ 最終手段として想定保守コストを引き上げるという手も …
● わかると決められること
○ 設計
○ 力の入れ方/力の抜き方
○ ドキュメンテーションの方針
○ などなど

19. どう聞いたら良いのか
わからない？

20. いいものが
ありますよ！！

22. https://goo.gl/fTZhvg

23. ご自身のユースケースに合わせて
改変してお使いください

25. コンセプトからの戦略例

27. swishの場合
● iOS版が既にリリースされている
● ヒヤリングの結果
○ アプリの価値
■ 男性：たくさんの女性をデートに誘える
■ 女性：魅力的な人の魅力的なデートプランを選べる
■ 仕様もアップデートのペースも iOS版と揃えたい
○ 開発リソース
■ 2018年1Qリリースが望ましい
■ もし間に合わなくても機能充実が優先
■ Androidエンジニア1人増員予定
■ 4系は切っていい
○ コードベースの寿命
■ 3年は保たせたい

28. コンセプトに沿って(1)
● 設計
○ 3年は保たせないといけない
■ シンプルな方針で
○ iOS版の仕様変更は頻繁に起きている
■ 画面間の結合はできるだけ疎にする
○ 人員入れ替えが頻繁に起こる予定はなく、開発に使える時間はあまりない
■ 多少属人性があってもいいか …？
■ 最初は試行錯誤、最終的に落ち着くところで改めてドキュメント化する
● 言語
○ 初期メンバーが使える言語でよい
○ 速度が求められる
■ Kotlin!!!!!!!!!!!

29. コンセプトに沿って(2)
● ライブラリ
○ RxJavaを使って問題ないレベルのエンジニア陣
○ ライブラリは必要ベースで追加
○ 使いづらいライブラリで消耗したくないので、要件に合わなかったら自前で開発 or 改造
● テスト方針
○ 開発速度を上げる or 開発者が安心するためのテスト
○ Local Testのみ
○ CIでテストとLintのタスクを走らせる
○ 治安維持のためAndroid Lintは abortOnError true に
● レビュー方針
○ 画面を触れるようになるまではレビューイーが動作確認後に
レビューを依頼
○ その後はまだ未定

30. どんな設計になったのかとかは
またいつかの機会に…

31. まとめ
● ヒヤリングしましょう！
● テンプレ使ってください！
● その後どうするかがエンジニアの腕の見せ所です

32. 宣伝
● DiverseではAndroid(Kotlin, Java), iOS(Swift), サーバー(Ruby, Kotlin)
開発ができるエンジニアを募集中です
● 特に新規事業のiOS開発チームリーダー募集に注力中
● 自分の力でサービスを成長させることに興味がある方、
お話させてください！
DM to @kikuchy or https://diverse-inc.co.jp/recruit/