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

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

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

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

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

• Mobileの開発スケジュールは以下
  

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

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

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

• 以下、静的解析などのテストで行っていること
  

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

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

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

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