アジャイル開発を成功に導くために ウォーターフォール開発からアジャイル開発に移行した セールスフォース・ドットコムの事例と実態 From salesforce.com to CA to the world: How agile came to the cloud 目次 概要 .............................................................................................................................................................. 3 アジャイル開発とは ......................................................................................................................................... 3 アジャイル確実性の原則 ................................................................................................................................ 4 セールスフォース・ドットコムにおけるアジャイル開発の成功 .............................................................................. 5 透明性、活性化、生産性 ............................................................................................................................. 5 透明性 .................................................................................................................................................. 5 活性化 .................................................................................................................................................. 6 生産性 .................................................................................................................................................. 6 セールスフォース・ドットコムにおけるアジャイル開発の「ビッグバン」 .................................................................... 6 大胆なアプローチ ........................................................................................................................................... 7 アジャイル開発の管理 .................................................................................................................................... 8 Scrumforce から CA Agile Visionへ ........................................................................................................... 9 アジャイル開発成功の秘訣：コラボレーション .................................................................................................. 9 WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud 概要 1990年代半ばに考案されたアジャイル開発手法は、世界中のIT企業の注目を集めてきました。 ただし、その 成功となると話は別です。 多くの企業がアジャイル開発の導入を検討し、 その中にはパイロットプロジェクトを 実施した企業もあります。 しかし、導入に成功した企業となると、その数は激減します。 多くのCIOが実感した ように、1つの開発グループを単独でアジャイル開発に移行させることと、組織全体にアジャイル開発を浸透させ ることはまったく異なります。 セールスフォース・ドットコムも2006年後半、研究開発チームを一斉にアジャイル開発へと移行した際、この問題 を経験しています。 結果から言ってしまうと、全社規模でアジャイル開発の導入に成功した企業はごくわずかで す。 当社では、2週間のトレーニング後、開発スタッフ全30チームがアジャイル開発に移行しました。 それから 約4年が経過した現在では、アジャイル開発は当社の開発業務を持続する上で中核的な存在となり、成長の 原動力にもなっています。 ただし、その導入にあたり、特に初期段階ではさまざまな問題がありました。 アジャイル開発への移行を企業全体に拡大する上で最大の問題とな るのは、アジャイル開発に対応した管理ソフトウェアが存在しないこと アジャイル マニフェスト でした。 2006年当時、アジャイル開発プロジェクトを管理するには、 プロセスやツールよりも個人と対話を 従来の管理ツールを利用する以外に方法がありませんでしたが、従 包括的なドキュメントよりも動くソフトウェアを 来型のツールでは十分な対応はできませんでした。 そのため、当社 契約交渉よりも顧客との強調を は自社で開発したシステムをForce.comのクラウドプラットフォーム上 計画に従うことよりも変化への対応を に構築しました。 それが、「Scrumforce」です。当社は、スクラム型 詳細については、 のアジャイル開発プロジェクトの管理フレームワークとしてこのツールを http://agilemanifesto.org/iso/ja/ をご参照ください 使用しましたが、このツールは社内での利用を前提に、セールスフォー ス・ドットコムの開発者や管理者の固有のニーズに対応したものでした。 当社はアジャイル開発を積極的に推進していますが、アジャイル開発用のツールの提供をビジネスにしているわ けではありません。しかし幸いにもこのツールを提供している企業があります。 プロジェクト・ポートフォリオ・マネジ メントの市場リーダーであるCA Technologies (以下CA)が、Scrumforceのベストプラクティスのガイドラインを活 用した管理ツールCA Agile Visionを提供しているのです。 CAは、Force.comのプラットフォームを使用してア ジャイル開発の新規ユーザと既存ユーザの両方に向けて開発したCA Agile Visionにより、アジャイル開発の支 持層を拡大しています。 このホワイトペーパーでは、セールスフォース・ドットコムとCAがどのようにしてクラウド環境でのアジャイル開発を実 現したか、また、パイロットプロジェクトから全社規模へとアジャイル開発導入の拡大を検討している企業にむけ て、この事例がどのように役立てられるかについてご説明します。 アジャイル開発とは 厳密に言えば、「アジャイル」という言葉は2001年に初めて定められた12の原則を指しています。それから約10 WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud 年が経過した現在でも、短いサイクルでユーザのフィードバックをもらう、といったような開発サイクルの短縮に焦 点を当てたアジャイルマニフェストは卓越した存在です。 アジャイル開発では、ユーザが絶えずソフトウェアの性 能を確認するため、開発者が憶測に頼りながらユーザが必要とする機能を構築することはほとんどありません。 また、開発チームは数か月先の成果目標をあらかじめ設定しておく必要もありません。 これによりユーザが実際 に必要としている機能により近い開発ができるのです。 開発チームは数か月ではなく数週間単位の計画を立 てればよいため、ソフトウェアの新規メジャーリリースが予定通りに提供される確実性が高くなります。 アジャイル 開発チームはアジャイルプロセスを「継続的な改善」と呼んでおり、アジャイル開発の導入に成功し、その利点を 享受した組織が従来の開発手法に戻ることはないでしょう。 アジャイル確実性の原則 当社を含め、多くの企業にとってアジャイル開発の最大の利点は、その見通しのよさにあります。 これをアジャイ ル確実性の原則と呼びます。 従来の「ウォーターフォール」型のソフトウェア開発では、企業は6か月から1年後 に提供できる成果物の予測を試みますが、実際の開発サイクルには未知の要素が多いため計画通りにいかな いことも尐なくありません。 その点アジャイル開発では各開発サイクルを「小さい箱」のように区切るため、リリース をほぼ予測通りに提供できます。 日程、人的リソース、品質基準が定義されていても、ソフトウェアの機能を柔 軟に変更できます。 セールスフォース・ドットコムにおいても、リリースを短い期間で分割し、それぞれが1か月以 内に完了できるように定義しています。 このアジャイルプロセスをウォーターフォールプロセスと比較してみると、ウ ォーターフォールプロセスでは開発サイクルの開始時に優先順位が設定され、数か月や1年が経過しないとユー ザのフィードバックは反映されません1。 これに対しアジャイル開発では、サイクルを短期化することで、すぐにユーザのフィードバックが得られ、次の主要 なリリースに反映できます。 また、機能や修正の優先順位リストを製品バックログと呼び、これを管理することに より、優先度の高い項目に焦点を当てることができます。 ユーザのフィードバックが得られることで、バックログを 継続的に再評価できるだけでなく、必要に応じて次のサイクルにおける優先順位の変更も可能になります。 そ のために、セールスフォース・ドットコムの IdeaExchange カスタマーフォーラム などのユーザコミュニティに強力なパイプを築いておくと役立ちます。 継続的な フィードバックを得ることによって、優先順位の上位項目が適切なものであるか を確認できます。 確実に提供できる成果物のみを約束するアジャイル開発の価値は、各スプリ ント終了時のレビューでも表れます。 レビューの際に開発チームがユーザに見 せるのは、数か月かかって作り上げた完成品ではなく、提供する準備の整った 部分です。 つまり、ユーザは「ベイパーウェア」ではなく、実際にリリースされる現 物を確認できるのです。 WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud セールスフォース・ドットコムにおけるアジャイル開発の成功 セールスフォース・ドットコムはアジャイル開発手法を導入したおかげで、これまでに見失っていた重要な本質的 価値観を取り戻すことができました。 以前のように、リリーススケジュールを遵守するようになったことです。 セー ルスフォース・ドットコムは1999年、サンフランシスコのアパートの一室で設立されました。当時、スケジュールの設 定と遵守は比較的簡単でした。当社の研究開発組織の規模はまだ小さく、ダイニングテーブルを囲んで座れる ほどの人数しかいなかったためです。 しかしながら、会社の成長とともに当社のクラウドベースの製品は複雑化 し、メジャーリリースの期限の遵守は困難になっていきました。 2006年はセールスフォース・ドットコムにとって「ア ジャイル導入前」の最後の年ですが、その頃には毎年4回発表していたリリースが年1回にまで減尐していました。 これは、クラウドコンピューティングの本質に反する現象です。 各リリースの提供までに15か月もかかるようになっ たことを契機に、当社は開発手法の抜本的な変革に乗り出しました。 当社はアジャイル開発に移行して以来、 メジャーリリースを予定された期日に提供しています。 セールスフォース・ドットコムは再び、定期的なリリースサイ クルで製品を提供できるようになり、研究開発チームは今後もスケジュール通りに新たなリリースを提供できると 確信しています。 また、実績値においても確実な向上が見られます。 メジャーリリースの開発期間は61％短 縮されました。 顧客満足度やロイヤリティを示す指標、ネットプロモータースコアは94％を記録しています。 透明性、活性化、生産性 アジャイル開発によって、セールスフォース・ドットコムにはさらに3つのメリットがもたらされました。 それは、透明性、 活性化、生産性です。 透明性 開発チームの規模が小さければチームの透明性は容易に確保できますが、チームの規模が大きくなると問題が 飛躍的に増大します。 セールスフォース・ドットコムの研究開発部門チーフであるスティーブ・フィッシャーは、17 年に渡り研究開発チームを管理してきたなかで、アジャイル開発の導入によって、これまでで最も効果的に開発 チームを管理できるようになったと述べています。 当社ではアジャイル開発によって透明性が強化されましたが、 その手法には、継続的なインテグレーション、ユニットテストや機能テストの自動化、毎日の会議、チームの進捗 を全員がウォール（壁）上で確認できる情報ラジエータ、「スプリント」と呼ばれるイテレーションの月例レビューなど があります。 また、透明性を社外にも示すことで、ユーザとの信頼関係を強化してきました。 たとえば、過去30日間のシステムの状況を http://trust.salesforce.com でユーザに提供しています。このよう な革新的なサービスは、外の世界に対して問題を隠そうとする従来の習慣とは完全に相反するものです。 問 題が発生した場合1、ユーザは問題の内容と、その問題がどのように解決されているかを確認できるのです。 1 1 ウィキペディアによると、ウォーターフォールモデルは順次的なソフトウェア開発プロセスであり、そのプロセスは要件の収集、設計、導入、検証、保守と、下方 に向かって（滝のように）一つずつ進められます。（http://en.wikipedia.org/wiki/Waterfall model） WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud 活性化 アジャイル開発の2つ目の利点は、セールスフォース・ドットコム創設当時 の創造性や意気込みを再びもたらしたことです。多くの企業では規模が 大きくなるにつれ、初期の頃には効果的であった意思決定プロセスの集 中化が、創造性を阻むようになります。アジャイル開発では責任と意思 決定が開発チームに委ねられることで、意思決定プロセスが分散されま す。アジャイル開発の基盤である継続的な改善によって、開発者から QAエンジニアや文書作成者までを含む全員に、個人やチームの作業を 改善する機会が提供されるため、社員の職場環境の改善にもつながり ます。 当社の研究開発チームを対象とした社内調査の結果を見れば、その効果がわかります。セールスフォース・ドッ トコムのアジャイル開発関係者の94％が会社の内外のメンバーに対してこの手法を推奨すると回答しています。 研究開発チームのメンバー間でこれほど意見が一致するのは非常に珍しいことです。 生産性 アジャイル開発の3つ目の利点は組織の生産性の向上ですが、これは当社が本来目標として掲げていたもので はありませんでした。しかし生産性の向上は、開発者1人当たりが開発した機能で測定すると38%にまでのぼり ます。これはなぜでしょうか。結局のところ、入社当初のエネルギーと意気込みを再び感じられることにより、仕事 に対する満足度が上昇し、それに伴い生産性も向上した、ということです。生産性の向上は、優秀で知的な社 員が自由に意思決定を行えることによって得られる達成感からくる副産物です。 セールスフォース・ドットコムにおけるアジャイル開発の「ビッグバン」 これまでのセールスフォース・ドットコムの経験は、クラウドがアジャイル開発にとって理想的な環境であることを証 明しています。 なぜでしょうか。 クラウド上に新しい機能を導入するコストは実質的にゼロです。 さらに、クラウ ドコンピューティングモデルは本質的に、ユーザに価値あるサービスを迅速に提供し、そのフィードバックをすばやく 得て、それに基づいた早急な変更を行うことを目的としています。 このように迅速な開発サイクルはクラウドコン ピューティングならではの利点であり、従来の開発モデルではデリバリコストが高額なためこの利点を得るのは困 難です。 Force.comのクラウドプラットフォームを活用することで、セールスフォース・ドットコムの研究開発チームは年間3 つのメジャーリリースを開発するばかりでなく、さらに毎月、毎週、毎日という単位で改善を積み重ねていくことも 可能になりました。 ユーザからのフィードバックは現在、すべての段階で取り込まれています。 今日電子メール で送ったフィードバックや IdeaExchange に投稿したアイデアがきっかけで新機能が開発され、明日にはオンラ インで提供されることもあるのです。 WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud 大胆なアプローチ アジャイル開発を企業規模で導入するにあたりセールスフォース・ドットコムでは、今振り返っても大胆と思えるよ うなアプローチを採用しました。一晩で一斉に研究開発組織全体をアジャイル開発へと移行したのです。もちろ ん準備作業は行いました。部門を超えたチームを新しく編成し、組織のあらゆるレベルの責任者同席のもと、ア ジャイル開発採用の提案を検討するために 1 時間程度の会議を 45 回行ないました。また、各開発スタッフから のフィードバックを提案に盛り込み、それを現場から離れたところにいる技術責任者に提出しました。 そしてそのチームからゴーサインが出た上で、「ビッグバン」アプローチに取り掛かったのです。その実行にはリスクが ないわけではありませんでした。懐疑的なメンバーは、尐数の不慣れなチームが犯すだけですんだかもしれない 誤りを多くのチームが繰り返してしまうのではないか、と異議を唱えました。また、日常的にサポートできる指導者 の人数が足りないことを懸念する声もありました。その一方で、ビッグバン導入を実施することにより、組織内の 不一致を回避できるだけでなく、会社として断固たるアクションを決行するという明確なメッセージを示すこともで きます。 移行の初期段階では、多くのスタッフが認定スクラムマスター（アジャイルで言うプロジェクトリーダー）のトレーニン グを受講し、アジャイル開発の関連書籍がオフィスに配布されました。また、部門を超えて編成されたチームによ ってアジャイル開発のプレゼンテーションとトレーニング用資料が作られました。 すべてのチームが 2 時間のトレー ニングに参加し、用意されたウィキベースの Web サイトにより、アジャイル開発に関連するすべての要素を参照で きるようにしたのです。 最大の障害はアジャイル開発の仕組みではなく、チームメンバーの考え方にありました。アジャイル開発の手法に は開発に対する考え方の転換が必要とされますが、10年20年と開発に携わってきたスタッフにとってそれは困難 なことです。スクラムチーム（開発チーム）のメンバーからアジャイルの実行チームに対して、新しいアプローチについ て次のような率直な意見や懸念が寄せられました。 「セールスフォース・ドットコムに関する議論や作業よりも、スクラムについて議論するのに多くの時間を費やし ているように思えます。」 「スクラムの導入を中止して、1年間にいくつのリリースを提供できるか考えましょう。」 「用語が意味不明で話になりません。」 アジャイル開発の導入に対する評価が好転したのは、移行から4か月ほどが経過したときでした。 社員が構造 を理解するに従って不満の声が聞かれなくなり、 実行チームに対する否定的なコメントも減尐しました。 また、 リリーススケジュールは以前より予測しやすくなり、安定しました。 徐々に、アジャイル開発の導入に価値がある という考えが企業全体に浸透していきました。 初期の目標としていたScrumforceの開発は、当社の Force.comプラットフォームにおけるJavaのようなプログラミング言語（Apex）とForce.comページのユーザインター フェイス開発ツール（Visualforce）を使用することにより、わずか3週間で完成することができました。 WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud アジャイル開発の管理 アジャイル開発の実行チームは早くから、各機能を追跡し優先順位付けすること で現在のイテレーション（またはスプリント）にどの機能が適合するかを判断すること の必要性も認識していました。このような管理は、アジャイル開発を拡張し、複数 の研究開発チームを連携させるには必要不可欠です。 もちろん、世界にはプロ ジェクト管理ツールはたくさんありますが、それらはアジャイル開発を実施する組織 には向いていません。 多くの不確定要素に基づいた長期的な計画には適してい ますが、短距離走（スプリント）のような瞬発力と迅速なフィードバックが必要とさ れるアジャイル開発の管理には不向きです。 当社ではまず、スプレッドシートを使用してアジャイル開発プロセスの管理を試み ましたが、すぐに、Excelが共同作業に適したツールではないと感じました。そこで、 Force.comの開発プラットフォームを使用して、当社独自のクラウドベースの管理アプリケーションを構築しまし た。Scrumforceはアジャイル開発の経験に基づいたモデルと、1週間から一か月といった短い開発サイクルに対 応することを踏まえて設計されています。 そのため、ユーザのために開発する機能の優先順位を決定し、製品 ごとに分類できます。チームはスプリントバックログにある上位の機能を選択し、それらを個々のタスクに分類して から作業を開始します。 Scrumforceでは作業の進捗を随時確認でき、必要に応じて機能の優先順位を変 更できます。 また、Scrumforceはクラウド上に構築されているため、チーム間の連携において、特にその効果を発揮します。 これは、当社のように全員が同じコードベースで作業をしている開発環境では特に重要です。1つのチームが開 発した機能は必然的に、他のチームが開発中の機能に依存します。 Scrumforceを使用すると、これらの依 存関係を定義および管理して、関係するすべてのチームに対して正しく優先順位付けされているかを確認でき ます。Scrumforceはクラウド上にあり、企業のどこからでもアクセスできるため、各開発のステータスをダッシュボー ドに表示できます。マネージャとチームのメンバーは表示された最新情報を、製品ラインやスクラムチームで、もし くはリリース全体で、または部門や製品ラインを超えたイニシアチブなどによって、細分化することができます。 また、Scrumforceにはアジャイル開発の「ウォール（壁）」が仮想的に組み込まれています。これは、アジャイル開 発手法にとって必要不可欠の要素であり、リモートチームにとって優れた管理ツールであることが実証されていま す。基本的な考え方は単純なものです。チームは各メンバーのタスクの状態（終了、進行中または開始予定な ど）を示す色分けされた付箋紙をウォール（壁）に貼ります。 ウォール（壁）に掲示されたその付箋紙を元に、短 時間の会議（「スタンドアップ」と呼びます）が毎日実施され、優先順位の決定と状況の確認が行われます。こ のクラウドベースの仮想ウォール（壁）を使用することで、Scrumforceではリモートのチームとも十分に連携するこ とが可能です。 WHITE PAPER From salesforce.com to CA to the world: How agile came to the cloud Scrumforce から CA Agile Visionへ さまざまな利点を備えているとはいえ、Scrumforceはセールスフォース・ドットコムの研究開発チームが社内の要 件を満たすために開発したツールにすぎません。そのため、CAから当社の経験をベースにした一般企業向けのア ジャイル開発管理ツール構築のアイデアを提案されたとき、当社は積極的にサポートしました。 その成果がCA Agile Vsionです。CAがセールスフォース・ドットコムのScrumforceチームとのコラボレーションを通して開発し、ア ジャイル開発/非アジャイル開発の両チームを対象としたクラウドアプリケーションです。CAの豊富なソフトウェア 開発における知識と経験は ドラッグ・アンド・ドロップ機能をはじめ、強力な視覚的プレゼンテーションの機能に 反映されています。 マネージャはチームの「ベロシティ」（チームが取り組むバックログの量）や、ウォーターフォール 開発手法でこれに相当する「ユーザの活用状況」を一目で確認できます。この両方の表示により、従来のウォ ーターフォール開発でスタッフの負荷状況を評価するのに慣れているマネージャにとって、ウォーターフォールのモデ ルからアジャイル開発への変換が容易になります。また、CA Agile VisionはCA Clarity PPMと連携するため、各 種プロジェクトにおけるリソース、財務、ガバナンスの管理プロセスに一貫性を持たせることができます。 さらに、CA Agile Visionはそれ自体がクラウドベースのアジャイル開発の利点を活かして開発された画期的な製 品です。 CA Agile Visionの開発プロジェクトチームを構成する26名のスタッフは、3つの大陸、4つの異なるタイ ムゾーンをまたぐ、6つの異なるサイトから開発を行いました。スタートから完成までの作業は2週間ずつのスプリン トに分割され、16回のスプリントで完了しました。 CA Agile Visionのスタンドアロンバージョンは、毎年開催され るDreamforce Conferenceの2009年11月に初めて発表され、2010年4月に製品がリリースされました。CA Clarity PPMと連携するCA Agile Vision Enterprise Editionは2010年7月に英語版が発表され、10月に日本 語版がリリースされる予定です。他のクラウドアプリケーションと同様、CA Agile Visionでもユーザのフィードバック の利点を迅速に活用しており、製品は継続的に改善される予定です。 アジャイル開発成功の秘訣：コラボレーション 当社の経験から、アジャイル開発の組織規模での取り組みできわめて重要なのは、強力なコラボレーションだと いえます。あらゆる場面で、開発者が開発ツールだけに向かうことなく、開発者同士が協力して作業するような 環境を提供する必要があります コラボレーションは、CA Agile Visionやその 先行バージョンであるScrumforceのどちらを使用する上でも、アジャイル開 発の成功の鍵となります。アジャイル開発の導入を契機に、マネジメント層 はコラボレーションを企業文化に浸透させていく必要があります。セールスフ ォース・ドットコムにとって、それは従来型の偏在する開発手法からの脱却を 意味しました。 リリースを計画するとき、当社ではまず、チームの優先順位とバックログに加 え、チーム間の依存関係にも注目します。そして、60から70のチームがすべ て集まって、コラボレーション会議を一度に行ないます。ただしこの会議の目 的は対話であって、プレゼンテーションではありません。当社ではリリース計 WHITE PAPER 画の正式なレビューを行ないません。また、ずっとプレゼンテーションを聞いていなくてはいけないようなミーティング を何度も繰り返し行なうこともありません。アジャイル開発向けのセールスフォース・ドットコム独自のミーティング 手法は、こうした従来型の会議よりもっと柔軟で自由なものです。 コラボレーションにはトップダウンとボトムアップの両方のプロセスを採用していますが、これは新機能開発の場合 特に重要です。マネジメント層は、会社の方向性とより幅広いビジネスの促進要因について説明します。 開発 者は、次回のリリースで可能なことと不可能なことを判断し伝えます。この意見交換は当然、堂々巡りになるこ ともありますが、しばらくするとリリースの方向性について全員が共通した理解を持てるようになり、製品のリリース 時期の現実的な予測が可能になります。 アジャイル開発におけるコラボレーションにとって最も重要なことは、開発チームを効率化することではなく、開発 自体の効果を向上させることにあります。効率と効果には大きな違いがあります。 効率とは、開発者が作業時 間を短縮しながらより多くのプログラムを開発することを意味するのに対し、 効果とは、ユーザにとっての価値を向上させることを意味します。しかし、あま りに多くの企業でこの2つの意味が取り違えられています。もちろん、開発者 が効率的であるに超したことはありません。しかしながら、それはユーザには関 係のないことです。 ユーザにとって重要なのは、依頼した新しい機能や修正プログラムがただ開 発されるだけでなく、それが次のリリースで迅速に反映されることです。まさに そのために、組織全体で取り組むアジャイル開発の手法が重要になるので す。当社の次回の製品イテレーション、つまり次の1か月のスプリントを計画 する会議では常に、ユーザの要望が重要な位置を占めています。
© Copyright 2024 Paperzz
