Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Salesforce Agile 事例

3,296 views

Published on

「JEITA ソフトウェアエンジニアリング技術ワークショップ2013」講演資料です。

開催案内URL:
http://home.jeita.or.jp/cgi-bin/page/detail.cgi?n=611&ca=1

Published in: Technology

Salesforce Agile 事例

  1. 1. Salesforce Agile 事例 Yoshi Oikawa CTO, Japan /yoikawa @yoikawa in/yoikawa
  2. 2. Safe Harbor Safe harbor statement under the Private Securities Litigation Reform Act of 1995: This presentation may contain forward-looking statements that involve risks, uncertainties, and assumptions. If any such uncertainties materialize or if any of the assumptions proves incorrect, the results of salesforce.com, inc. could differ materially from the results expressed or implied by the forward-looking statements we make. All statements other than statements of historical fact could be deemed forward-looking, including any projections of product or service availability, subscriber growth, earnings, revenues, or other financial items and any statements regarding strategies or plans of management for future operations, statements of belief, any statements concerning new, planned, or upgraded services or technology developments and customer contracts or use of our services.   The risks and uncertainties referred to above include – but are not limited to – risks associated with developing and delivering new functionality for our service, new products and services, our new business model, our past operating losses, possible fluctuations in our operating results and rate of growth, interruptions or delays in our Web hosting, breach of our security measures, the outcome of any litigation, risks associated with completed and any possible mergers and acquisitions, the immature market in which we operate, our relatively limited operating history, our ability to expand, retain, and motivate our employees and manage our growth, new releases of our service and successful customer deployment, our limited history reselling non-salesforce.com products, and utilization and selling to larger enterprise customers. Further information on potential factors that could affect the financial results of salesforce.com, inc. is included in our annual report on Form 10-K for the most recent fiscal year and in our quarterly report on Form 10-Q for the most recent fiscal quarter. These documents and others containing important disclosures are available on the SEC Filings section of the Investor Information section of our Web site.   Any unreleased services or features referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Customers who purchase our services should make the purchase decisions based upon features that are currently available. Salesforce.com, inc. assumes no obligation and does not intend to update these forward-looking statements.
  3. 3. 本日のアジェンダ • Salesforce.comについて • マルチテナント・アーキテクチャー • Salesforce.comの開発手法 • Q&A
  4. 4. Salesforce.comについて
  5. 5. Salesforce.com のご紹介 創業・サービス開始 年間売上 (2013年1月31日発表) ご採用社数 従業員数 (2013年4月30日) 対応言語数 米国 : 1999年創業 2000年サービス開始 日本 : 2000年創業 2001年サービス開始 30億5,000万ドル (前年度比 35%増) 100,000社以上 10,283人 ユーザ向け : 31以上 (管理者向け : 16 以上) ソフトウェア企業の 成長率ランキングでトップ10 入り 30.5億ドル FY13
  6. 6. セールスフォース・ドットコムのミッション ∼ クラウドコンピューティングの普及、推進、拡大 エンタープライズ メインフレーム クライアント・サーバ クラウドコンピューティング ハードウェアやソフトウェアは不要 従量課金モデル アップグレードは自動 継続的なイノベーション 1960 年代 1980 年代 現在
  7. 7. クラウドコンピューティングと CRM のリーダー #1 革新的な企業 世界 No.1 の CRM アプリケーション クラウド コンピューティング 市場でのシェア 2011 年 2012 年 2013 年 マーケットリーダー エンタープライズ市場向け、 中小企業市場向け、 営業支援
  8. 8. 就業時間・株式・製品の % 1 5,300 万ドル を超える 助成金 53 万時間 を超える 地域貢献活動 20,000 の NPO に ライセンスを無償提供
  9. 9. コンピューティングの第 3 の波
  10. 10. コンピューティングの第 3 の波 モノのインターネット クラウド サーバ LTE メインフレーム SNA ターミナル 数千ユーザ デバイス LAN/WAN 各種製品 クライアント 数百万ユーザ 500 億のモノがつながる
  11. 11. コミュニティ チャット ポスト 製品 ツイート すべての もの の向こうにはお客様がいる アプリケーション デバイス Web サイト 買物カゴ
  12. 12. 新しいカタチで顧客とつながる
  13. 13. Salesforce1: A New Customer Platform for the Future Sales Cloud Service Cloud ExactTarget Marketing Cloud AppExchange Salesforce1 アプリケーション Salesforce1 Platform API Force.com Heroku1 Salesforce1 Platform サービス ExactTarget Fuel
  14. 14. マルチテナント・アーキテクチャー
  15. 15. 利用が簡単: 年 3 回のリリースを通じて継続的なイノベーションを実現 シームレスな自動アップグレード 42 回のメジャーリリース すべてのカスタマイズとインテグレーションを 自動的にアップグレード コミュニティに寄せられた顧客の声にもとづき 機能を拡張 アップグレード、新しいリリース、旧バージョンとの互換性といった悩みから解放され、 イノベーションや業務上の課題に心おきなく取り組めるようになりました。
  16. 16. 信頼: 最重要価値としての徹底した取り組み trust.salesforce.com 四半期当たりのトランザクション 平均ページロード時間 790億件 FY12: 306ms FY13: 241ms
  17. 17. 1999年の話:シングルテナントは無駄が多い App App Db Db App App Db Db
  18. 18. マルチテナント型の利点は自明 ...しかし、顧客の分離は決して容易ではない App Db
  19. 19. マルチテナントこそが目指す方向 「このお客様だけ特別に、別サーバーに してほしい」 「このお客様だけですから」... App App Db Db
  20. 20. マルチテナントは「クラウド」を可能にする シングルテナント (オンプレミス、ホスティング等) 100,000+ の企業 マルチテナント 100,000+ の企業 App 2 App 1 App 1 App Server App 3 Database App Server App 3 App Server Database App Server OS App Server OS Database Database Server Database Server OS OS Storage OS Storage Server Server Network Server Network Storage Storage Storage Network Network Network 100,000+ のアプリ・スタック 1つのアプリ・スタック
  21. 21. Salesforce.comの開発手法
  22. 22. 創業当時 • 3名の開発メンバー • 共通の目標、進捗の把握が容易 • 素早く、効率よく、かつ創造的な作業が可能 • 年4回のメジャーリリースを実践
  23. 23. Agile • 2006年にAgileへ移行 • 移行前はウォーターウォールをベースにしたスパイラル方式 Daily Scrum Meeting Product Backlog Sprint Backlog Sprint Review: Demo Potentially Release-able New Functionality
  24. 24. Agileへ移行した背景 • スケールしなくなった • 機能数の増加、多様化 • エンジニア、チーム数の増加 • コードベース、依存管理の複雑化 • 品質の低下 • リリースサイクルの長期化 • リリース計画の未達成 • 機能の詰め込み 顧客満足度、サービスに対する信頼の低下
  25. 25. Agile @ Salesforce • ADM (Adaptive Development Methodology) • スクラム、XP、Lean • 200+のスクラムチームがシングル・コードベース上で開発 • 1年に3回のメジャーアップグレード • 30日間のタイムボックス • 月単位で仕事を完了
  26. 26. ADM導入の成果 移行直後の調査結果: • 100% 予定通りにリリース • +94% 1年で追加した新機能 • +38% デベロッパーあたりの新機能数
  27. 27. Agile移行に成功した要因 • トップマネージメントのコミットメント • 徹底した教育(特にマネージャー) • 柔軟性は維持 • 素早いフィードバックループ体制の構築 • 継続的インテグレーション • 自動化 • ビルド • 自動化テスト • リリース
  28. 28. スクラムチームの構成例 • プロダクトオーナー • スクラムマスター • デベロッパー • 品質エンジニア(QE) • UI デザイナー • ドキュメントライター • パフォーマンス・エンジニア
  29. 29. 品質にどのような効果があったか? • 品質向上に大きく貢献 • スケジュール通りの安定したリリースを2007年から継続 • 「品質」に対する考え方の変化 • 品質を作り込む実装行程 • バグを出さない仕組み、プロセス、環境作り • 品質はチーム全体が負う
  30. 30. Agileと品質エンジニア • 品質エンジニアに求められるスキルに変化 • より高いテクニカルスキル • プロダクトデザイン • プロジェクトマネージメント • 3段階のステージと「役割」の変化 品質エンジニアの開発行程への統合 品質を作り込む開発環境へ 品質エンジニア => エンジニア
  31. 31. 品質エンジニアの開発行程への統合 • デザイン、開発初期行程から参加 • 仕様、テクニカルデザイン、ユーザビリティのレビュー、問題の早期 発見と修正 • アーキテクチャ、実装詳細、開発環境の理解度が大幅にUP • マニュアルテストから自動化テストへ(API, UI) • スクラムマスターとしてプロジェクト管理
  32. 32. 品質を作り込む開発環境へ • テストを意識したコードへ • テスタビリティ向上のための開発プラクティスの実施 • リファクトリング • API駆動型のデザイン、実装方式 • テスト駆動型の開発 • 徹底した自動化 • より深く、幅広いカバレッジ • 効率の高いテストコード
  33. 33. 品質エンジニア => エンジニア • デベロッパーと品質エンジニアの役割の希薄化 • DevOps • 品質はチームが負う • 標準化された開発プラクティスの実施、徹底 • 品質エンジニアの技術力、スキル向上 • デベロッパ向けのテストケース作成、デザインの教育 • エンジニア で構成されたスクラムチームへ

×