20150219 ベストアプリ勉強会

Androidアプリ開発編

Sansan

評価・品質の話

• ベストアプリ／フィーチャーはないが足切りはある
  • 4.3以上。可能なら4.4以上
• 累計平均評価をひたすら上げよう
  • 品質を上げる
  • ex. 起動しない
  • 大改修時に品質が下がって0.5下がった
  • ユーザーの声を毎朝共有
    • 直接話す
    • 可能であればすぐに直して出す
  • ドロワーの下部に、「問題を報告」
    • 問題が出ると、GooglePlayに書くか、使うのをやめるか
      • 悪い評価をされづらくなる
  • Crashlytics
  • 適切なタイミングで評価をお願いする

MoneyForward

デザインリニューアルの話

• なんのためのリニューアル？
  • 目的をもったリニューアルでないと意味が無い
  • 現状の課題を解決する
  • KPI明確に
    • 課題が明確で無い＝リニューアル時期ではない
• 痛みを伴う
  • ネガティブなレビュー・ツイート
  • 評価が一時的に下がる
  • 4.0を下回るとデメリット発生

• リニューアルをゴールにしない

  • 画面遷移を極力かえない（KPI追えなくなる）
  • 継続的な改善

• すすめかた

  • 短期集中
    • 他のコミットのマージ大変
    • デグレやすい
    • 作業中に方向性が変わる
    • 徹底的に議論
      • 途中でコンセプトがぶれないため
    • こだわる部分を決める
    • 開発中はWIPで共有
    • ツール・サービスを活用（Sketchとか）
  • 一気に変える
    • ２つのアプリ同居状態。一本化がつらい
    • 部分的に変えると、長い間ネガティブレビュー。スクショの更新もめんどくさい

Fablic

Fril 3.0リニューアル

• 背景
  • TV CM 駆動開発
  • iOS likeなUIが残ってた
• 時間がない。合宿した
• 3人
  • デザイナー、デザイナー&ディレクター、エンジニア
• ペーパープロトタイピングを事前に読む
• リサーチ・共有
  • Googleや他社のアプリをリサーチ。マテリアルデザインのガイドラインも
• ペーパープロトタイピング
  • 紙で書く。全パターン。検討して潰しておくことが大事
• 議論・集約
• ツールプロトタイピング
  • Popで動きをつける
  • PC / Flintoで清書
• ユーザーテスト
  • 社内ユーザーでテスト
  • Popで作ったモックを触ってもらう

• 3.0

  • リニューアル & フラグメントベースに移行

• 質疑

  • POを巻き込むの大事
  • タブレット対応１ヶ月弱
    • フラグメント対応をやってたから

開発体制編

Sansan 開発責任者(webエンジニア)

開発のリズム

• 開発体制の紹介

  • Eng 12(mobile3 web8 aws1)
  • その他6
  • PDCA
  • 使用策定。ストーリーベース
    • Pivotal Tracker を使ってる
  • フィードバック
    • 3つのKPI
      • 事業, UserGrowth,？
  • 重要なストーリー: mobile中心
    • mobile サイクル2weeks ~ 1month
    • web 1week
    • 振り返りはどちらも2weeks

• プレミアム機能開発

  • 開発1.5month 全体3month
  • Eightとしては大きいプロジェクト
  • いつもの1weekリリース
  • 1monthを超えるプロジェクトは、フェーズを切って成果物を明確にする
  • リズムを大切に

MoneyForward CTO

• マーケット出身
  • リスクコントロール
  • 本質を見る
  • 俯瞰的な視点を持つ

• 体制

  • 2013前半
    • 一人
    • 直接つくる。ベンチャーっぽい
  • 後半
    • 二人
    • 開発スピードは加速
    • 気合と根性
  • 2014前半
    • 四人。デザイナーやマーケなど他の部隊
    • ワイヤーを作り、UIデザインも作りこむように
    • 手戻りはあまりない
    • 雲行きが怪しく
  • 2014後半
    • 8人
    • 暗黙知、技術的負債、コミュニケーションコスト
  • 個人ではなくチームの効率を重視
  • 暗黙知対策
    • コードレビュー会
    • Qiita:Team導入で、ナレッジ共有
  • 技術的負債
    • リリース後振り返り会し、リファクタリング時間を確保
  • コミュニケーション効率化
    • 目的に応じて分ける（中長期開発とグロースハック）
    • チームに最適化したプロセス

Fablic チーフエンジニア（バックエンド）

• 開発体制

  • 2012/4創業,
  • 2012/7 iPhoneリリース（２人）
  • 2013/1 Android開発開始（３人）
  • 2014/1 10人
  • いま 50人
  • Android/iOS/Backend 3:3:4
    • A/i両方できる人も多い

• ベストアプリを取るために

  • 品質を良くする
    • githubでレビュー
    • CIをパスしたコードのみリリース
    • Androidは段階的リリース。10%から
    • 実機テスト
      • テストシートを作って、開発者テスト
      • テストシートもレビュー＆メンテ
      • webと違って修正できない
    • ユーザーとともに開発。実際のユーザーとテスト
      • サポートスタッフとして採用。QAチームを組織
      • リリース前の本番アプリを数週間使ってもらうとか
  • レビュー
    • 良い物も悪いのも返信
    • 困ったらサポートへ案内
    • 最適なタイミングでのレビュー
      • 気持ちが高まるとき（売れた時、買えた時）
  • Platformとのコミュニケーション
    • GoogleIO
      • マテリアルデザイン対応
      • 何よりも早く対応することが大事
      • UX向上になるかは見極める
    • 開発ロードマップをGoogleと共有
      • Nexus6展示会でプリインされたり