Regional Scrum Gathering® Tokyo 2014 : 1A-3 「Bing開発グループはどのようにして毎日リリースをしているのか」 #sgt2014
今年もRegional Scrum Gatheringに参加させて頂いています。
参加したセッションについてのレポートを書いていきたいと思います。
まずは、マイクロソフトのヤマモトジン氏による、「Bing開発グループはどのようにして毎日リリースをしているのか」です。
2ヶ月×4の、「6ヶ月」周期
Bingでは、以下の様な開発サイクルで開発を行っているそうです。
最初のステップのデータ解析・ゴール設定フェーズでは、Bingが持つ、膨大なユーザの行動データを解析し、どのような改善を行ったら良いか、そして何を目標とするか(基本的には数値で表せる、「検索精度」を目標にするそう)を2ヶ月かけて練るそうです。
その後、4ヶ月の開発期間があり、開発締め・効率改善フェーズがあります。
ここではリファクタリングなど、開発効率向上につながる取り組みを、デベロッパが行うそうです。
また、この4番目のフェーズと、次のサイクルの1番目のフェーズは期間が重なっており、デベロッパが改善を行っている間に、製品に責任を持つプログラムマネージャは次のゴール設定を行うそうです。
既に現在のサイクルのゴールは明確になっている状態なので、プログラムマネージャは開発チームと別れて、次の案件に集中することができるそうです。
Daily Shipping
上記のようなサイクルで開発は行われていますが、企画開始から6ヶ月、ないし8ヶ月後にようやく機能がリリースされるわけではありません。
Bingでは常時新しい機能をリリースし(100%のリリースではなく、基本的にABテスト)、ユーザの反応を見て、さらなる改善につなげる、ということをしているそうです。
Dailyとは言っても、次の日に引っ込めるようなことをするわけではなく(そりゃそうだ)、大体2週間ほどデータを集めた後、専門のビッグデータ解析部隊によってデータ解析に回されるとのことでした。
Daily Shipping を支えるインフラ
セッション後に、リリース周りの仕組みや準備/オペレーションのコストについて質問してみました。
曰く、デプロイ作業自体はコンフィグファイルにABとかプロダクションとか的なことを書くだけで切り替え可能とのこと。
専門のオペレータもいるそうです。
また、検索ということで多くのサーバを使っており、さらにDCも分散されているため、全てのDC、全てのサーバにデプロイされたことを確認するのが大変で、様々なノウハウが有るとのことでした。
現在はこのノウハウは、Azureの運用部隊に引き継がれているそうです。
(この辺、AmazonからAWSが生まれてきたのと似ていると感じました)
ただし、こういったシステムは元からあったわけではなく、Bing開始当時は少ないサーバで自動デプロイしていたこと、その後時間をかけて現在の仕組みが構築されてきたことを聞くことが出来ました。
さて、私・我々は何をするのか
このセッションで聞いて、ぜひ取り入れたい、自分たちのプロセスを改善したい、と思ったのは、
- 膨大なサーバ群に対して簡単にA/Bテストや本リリースが行える、リリースの仕組み化
- 明示的なリファクタリング期間の設置と、効率改善が評価されている
の2点です。
どちらも昨年から取り組んでいるもので、本年も計画的に行っているものではありますが、引き続きトライしていきたいと思います。
前者に関しては、今まで野良的に行われてきたものが、今年はいよいよ組織化されそうなので、うまく協力して、いい方向に持っていけるようにしたいと思います。
後者は、昨年末試しに一週間、集中して改善だけ行う期間をとってみましたが、細切れにやるよりこちらのほうがいいと感じましたので、またどこかで同じようなことをしてみたいと思っています。