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展示会でプリインされたり