大規模アジャイル開発の実態～セールスフォース・ドットコムの作り方（前編）

2011年3月23日

クラウド上に構築したアプリケーションをサービスとして提供するセールスフォース・ドットコム。同社は千人以上の開発者を抱える開発部門全体でアジャイル開発手法を採用し、開発を行っています。

アプリケーションのメジャーアップデートは年3回。クラウドで提供しているサービスという性格上、もしもアップデートにバグがあればそれは全ユーザーに対して大きな影響を与える可能性があります。バグがないこと、性能低下を起こさないこと、品質管理はパッケージソフトウェア以上に重要です。

同社はどのようにしてアジャイル開発手法を採用し、品質を重視した開発を進めているのか。2月17日に行われたデベロッパーズサミット2011で、株式会社セールスフォース・ドットコム CTO 及川喜之氏のセッション「salesforce.comの作り方　どのように世界最大規模のアジャイル開発を実現したか」で詳しく紹介されていました。

同社の開発手法が国内で紹介されるのははじめてのこと。大規模アジャイル開発の事例としても非常に貴重な例といえます。セッションの内容を紹介しましょう（注：スライドは、ほぼ同じ内容の講演が行われた2月28日の「Salesforce Developer Conference Tokyo 2011」のものを引用しています）

スクラムをカスタマイズした「ADM」を採用

セールスフォース・ドットコムでは「ADM」（Adaptive Development Methdology」と呼ぶ、スクラムをセールスフォース・ドットコムに合わせてカスタマイズしたアジャイル開発手法を採用している。この手法は、セールスフォース・ドットコムが最高のソフトウェア品質を提供するためのカギだと考えている。

私たちも創業当時はウォーターフォール型の開発手法を採用していた。最初は3名の開発メンバーで、素速く効率よく創造的な作業をしており、年4回のメジャーリリースを実現していた。

創業後、お客様が増大してもっと多くの機能を早く実装してほしいという要求が高まり、それに応えるために開発部隊の人数が増えた（創業から7年後に350名）が、それにつれて問題も増えてきた。

開発プロジェクトの中身が不透明になり、誰がなにをやっているのか、誰が最終決定者なのかが分からなくなってきた。また、発見されるバグと修正すべきバグが増え、バックログがたまっていった。リリースサイクルは延びていき、いちばんひどいときには1年に1回しか新バージョンをリリースできなかった。そのリリースも、機能は大量だが品質は決して良くなかった。

なぜこうなったかというと、ウォーターフォール型ではリリースの終盤にならないと成果物を確認できず、それが本来の目的に沿うのか、本当にユーザーに必要なものなのか判断できないからだ。これが品質の低下につながり、お客様にいいサービスを提供することが難しくなっていった。

ウォーターフォールを否定する気はないが、セールスフォース・ドットコムではうまくいかなくなった。

あらゆる手を使ってアジャイル導入を盛り上げた

問題を解決するには、根本的な変化を必要としていた。

ADMはこれらの問題を解決するために導入した。約3カ月の準備期間の後に全社一斉に導入し、そのあとでツールなどを採用してチューニングをかけてきた。

ADMの導入は、創業者でCTOのParker Harrisがほかのエグゼクティブを説得したし、デベロッパたちもすでにフラストレーションを感じていたため新しい手法に乗り気であった。

アジャイル開発はその当時から米国で話題になっていたが、全員が「スクラムとは何か、どういうことをやらなければいけないのか」を理解しなければいけないので、外部のトレーニングを利用して全員にトレーニングを行った。ちなみに、いまは社内にトレーナーがいる。

もちろん最初はうまくいかないチームもあったが、ADM用のポータルサイトを立ち上げて、読んでおくべき本のリストとか、次のスプリントはいつからですとか、今月なになにで貢献したアワードとか、あらゆる手を使って盛り上げた。

成果は、ADMに切り替えた最初のリリースから出た。1つの機能に費やした工数が劇的に縮まり、1つのリリースでの機能の数もはねあがった。リリースの直後に起きるリグレッションやバグが劇的に減った。

ADMを導入したときにはデベロッパは数百人で、いまはそこから桁が変わっている。この数年間にリリース直後の大きな問題はなく、リリースごとに社員でさえ覚えるのに苦労するほどのあたらしい機能がどんどん開発できている。

小規模なデリバリはリスクが小さく、ゴールもシンプルになる

ADMのベースとなったクラムの特徴として、短い期間にリリースを繰り返す事が可能なことがあげられる。小規模のチームで小規模なデリバリを繰り返すためリスクも小さく、短いサイクルでリリースを繰り返すのは方向性も微調整しやすい。小さなプロジェクト、短いゴールはチームにとって目標がシンプルになりやりやすい。

これによって予定通りのリリースを実現できるようになり、1年で追加した新機能は増加し、デベロッパーあたりの新機能も増えた。

開発部門のメンバーからの反応も、92％が効果的な手法だと思うと回答し、91％が品質が同等か改善されたと感じ（改善されたとの回答は56％）、86％が仕事が楽しいか最高であると答えている。

自己組織化、品質優先、自動テスト

ADMの3大要素は「スクラムによる自己組織化型のチーム」「品質優先」「自動化テストとそれを支えるツール全般によるオートメーション」だ。

スクラムチームは横断的な構成で、各チームは特定の製品、機能の開発割り当てられる。例えばSalesforce CRMの商談予測機能チームとか、Chatterのチームとか。現時点で100以上のスクラムチームがある。

チームはこのようなメンバーで構成されている。機能を組み込んだときにシステム全体のパフォーマンスが落ちないようにパフォーマンス担当もいる。

プロダクトオーナーは、スクラムチームの責任者で開発をリード。リリースのための全般に関与する。スクラムマスターはスクラムチームの「コーチ」にあたり、チームをスクラムの原則と方法に従わせるとともに、チームの障害を排除する役割。

リリースサイクルは年に3回。1スプリントは1カ月日で、開発のスプリントが終わった段階で次のスプリントが始まるので、スプリントはつねに動いている。

1つのリリースの中でなにをしているのか？まず各スクラムチームでリリース計画を立てる。

そして開発スプリント。スプリントは1カ月で、これを3回繰り返す。

開発スプリントは日付が決まっているので、チームはスコープを調整して日付に合わせることもある。それを管理するためのウォール。当初は壁に貼っていたが、いまではForce.comのアプリケーションを作って管理している（それを基にしたプロジェクト管理ツールが、CAテクノロジーからAgileVisionとして販売されている）。

スプリントで予定していたタスクを終わらせるのが「Done」（完了）。完了の定義の一例をあげてみる。これは人やチームによって違うことがある。

スプリントの最後の日には「スプリント・レビュー」として、開発部門のマネージャや関連部門を対象として、各スクラムチームの成果発表会とデモが行われる。これが進捗の共有やフィードバックと改善につながる。

開発スプリントを3回繰り返し、各開発メンバーの完了を確認し、リリース計画が達成されると「フィーチャー・フリーズ」となり、潜在的にリリース可能な状態となる。

しかし、ときにはフィーチャー・フリーズに間に合わないチームもある。そのときには3つの選択肢がある。それは「コードをなかったことにして元に戻す」「フラグを立てて機能を無効にし、次のリリースを目標にする」「最大1週間の期間延長を申請する。ただし執行役員クラスの承認が必要」のいずれか。どのパターンも過去に行われたことがある。

そしてリリースに向けた最後のスプリントが「リリーススプリント」。これは安定した製品を出すためだけでなく、スムーズにリリースするためのステップだと思っている。

ここでは各スクラムチームの横断的テスト、機能ごとの兼ね合いやユーザーインターフェイス、ユーザー体験に統一感があるか、パフォーマンス、セキュリティ、システムにかかる負荷がどれくらいか、などのチェック。そしてデータベースの変更がある場合には、データベースへのアップデートスクリプトの最終確認などが行われる。