Facebookのモバイルアプリ開発におけるリリース2

1つ前の記事にFacebookのモバイルアプリ開発のYouTubeを貼付けました。

少しそこからいくつか重要そうな、開発スタイルの移り変わりに関してピックアップしてみます。
※使っている画像は、すべて動画からのスナップショットです。

  • 今まで、以下の形でWebアプリ/Mobileアプリの開発を行っていたが、スケールしない事態になった。
    • Webは各サービスの責任範囲で開発を行う
    • Mobileは専用のエンジニアが開発を行う
      Screen Shot 2014-05-18 at 19.33.05

  • 現在は、以下のように開発者を区分していった
    • 各サービスの責任範囲で横断的にサービスを開発する
      Screen Shot 2014-05-15 at 1.03.05
  • Webの開発スケジュールは以下
    Screen Shot 2014-05-15 at 1.08.58

  • Mobileの開発スケジュールは以下
    Screen Shot 2014-05-15 at 1.10.20

  • Mobileの開発において、Alpha tester/ Beta testerという区分でテスト実施も行われる

  • 自動的に誤りを検出するなどのシステム化も十分にされている※本編か文字起こしされたものをご確認ください

  • release branchがきられたら、以下のようにmasterから必要なものをとってくる。そして、RCでは完全にそのブランチでの不具合修正になる
    Screen Shot 2014-05-15 at 1.11.50

  • 以下、静的解析などのテストで行っていること
    Screen Shot 2014-05-15 at 1.20.24


  • 所感
    • やはりと言ってはあれですが、サービスを受けもつチームが横断してサービスを開発できたほうが、専門性もさることながら、そのサービスの責任範囲において高速な意思決定、開発が実施できる
    • 開発同様、テスト実施によるサービスの評価/検証においても、各サービスチームが主体的にどんなテストを行い、どうテストしていくか、考えて行動するという段階になるのでしょうね
    • そのためには、おそらくFacenbookでは社内共通用語としてxxxテストだとか、yyyテストレベルという言葉が作られていると思うので、弊社内でも開発の現状に即した形で、そういう言葉を定義し、”○○の障害を防ぐために、yyyテストレベルでxxxテストを行おう”というような共通認識で議論ができる場を作ることが重要そう

開発サイクルを見ていると、時間を変数にせず、固定化させるというのはSOAで開発を行い、複雑に利害関係が絡む中では重要そう。
WebはDeployの問題が小さいのでさほど気にする必要が無かったのですが、Mobileアプリはそれとは違う。

機能を優先に、リリース日を決めることは複数のサービスが1つのアプリをがんがん開発していく流れが加速すれば、社内調整にすごく時間を使いそう。それは開発に関連する人たちの速度を落とすので、できればさけたい。
それよりは、リリース日をある程度一定のリズムで設定しておき、それに合わせてサービス側が自分たちの戦略の調整、Web側でカバーするなどの意思決定をした方が、サービス全体としてみれば素早い意思決定を小さな労力で回せそう。

※これはAgileとか、スクラムとか言っているのではないのであしからず。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中