Salesforce開発プロジェクトの進め方とアプリケーションライフサイクルマネジメント
•
51 gostaram•24,779 visualizações
6月12日に開催された「Salesforce開発プロジェクトの進め方とアプリケーションライフサイクルマネジメントWebinar」で使用された資料です。
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Salesforce開発プロジェクトの進め方とアプリケーションライフサイクルマネジメント
Semelhante a Salesforce開発プロジェクトの進め方とアプリケーションライフサイクルマネジメント (20)
Mais de Salesforce Developers Japan
Mais de Salesforce Developers Japan (20)
Último
Último (8)
Salesforce開発プロジェクトの進め方とアプリケーションライフサイクルマネジメント
- 2. #forcedotcomjp 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. #forcedotcomjp#forcedotcomjp Speaker Takayuki Nakao Partner Enablement Senior , Salesforce.com Japan @developerforcej
- 4. #forcedotcomjp Developer Forceをフォローください @developerforcej/ #forcedotcomjp Developer Force Japan +Developer Force Japan Developer Force Japan Developer Force Group
- 5. #forcedotcomjp Agenda § Salesforce開発プロジェクトの進め方 § アプリケーションライフサイクルマネジメント § リリースに向けた準備 / トレーニング・保守体制
- 7. ADM（Agile Development Methodology）とはSalesforce.comに特化した形のアジャイル開発手法です。一 般的なWF開発よりも、リスクを軽減したスピード導入を可能とさせます。 要件定義 外部設計 内部設計 開発 単体テスト 結合 テスト 統合 テスト プロジェクトの進行 見直できる期間 ウォーターフォールでの開発 正確に要件を満たして いることを確認 アジャイルでの開発(ADM) プロダクト・バックログ1 7 1 2 3 4 5 6 デイリー・スタンド アップ 3 レトロスペク ティブ 5 コミットメント スプリントプランニ ング 2 リリース可能な成果物 4 スプリント・レ ビュー 30日間 スプリント 原則 • 柔軟に変更を対応 • チームでの協業 • ビジネス要件の実現 • ヒアリングを基本としたお客様の巻き込み ADM（Agile Development Methodology） • 確定したプロジェクト期間 • 柔軟なプライオリティ変更（スコープは変更なし） • その場でのディシジョン
- 8. #forcedotcomjp Week 1 Week 2 Week 3 Week 4 リリース ベータ リリース 1.0 Tasks: • トレーニング・マテリアル作成 • エンドユーザー・トレーニング 実施 • 運用引き継ぎ実施 • 次期アプリケーション準備： ・ユーザー設定 ・利用率確認ダッシュボード ・Salesforce Ideasによる改善 要望の収集 ・運用サポートフロー策定 Tasks: • ユースケース、業務要件確認の ためのワークショップ実施 • 業務要件の優先順位付け • 要件の難易度精査 • 業務要件実現のための全体デ ザイン整理 • 全体業務要件整理 • チーム・ビルディング • プロダクト・バックログに詳細業 務要件をインプット • 初回スプリントまでのロードマッ プ策定 デイリー・ スクラム・ ミーティン グ 要件 の優 先順 位付け アプリ ケー ション 構築 要件と アプリ の ギャッ プ確認 お客様 受入 れテス ト Week 0 (プランニング) スプリント1 スプリント2 ADMでのプロジェクト・タイムライン ※2×2週間のケース 1 7 123456 3 5 コミットメント 2 4 30日間 スプリン ト デイリー・ スクラム・ ミーティン グ 要件の優 先順位付 け アプリケー ション構築 要件とアプ リのギャッ プ確認 お客様受 入れテスト
- 10. #forcedotcomjp 標準機能を最大限 活用する パイロットを実施し 要件をブラッシュアップ お客様と一緒に作る ü 全世界200万人以上のアクティブユーザの声を年3回のバージョンアップに反映し続けてきた Salesforceは、まさにお客様のベストプラクティスを集めたツールセットです。これらを最適に組 み合わせる事により、“ゼロ”から設計・開発する場合に比べて、専用のアプリケーションを圧 倒的に早く簡単に構築することが出来ます。 ü Salesforceの標準機能を工夫する事により必要ない追加開発を減らすことが出来ます。導入 のスピードとお客様自身がカスタマイズできる事により利用開始後の保守コストを下げ、かつ 長期的にSalesforceのバージョンアップによる拡張性を最大活用できるメリットがあります。 ü 曖昧な要件を実際に利用して実現イメージを掴み、それを要件定義にフィードバックできるパイ ロットの手法は、フロントシステムの開発手法として非常に有効であり、改善周期を繰り返し つかえるシステムを実現します。 ü SaaS型のアプリケーション開発は、旧来のシステム導入方式で必要なHW/SWのサイジングや調 達、初期設定などの作業が必要なくパイロット導入できます。 ü お客様がSalesforceの最大のメリットを享受できるのは、システム開発が終了し実際に運用開 始した後です。Salesforceのカスタマイズの柔軟性は、お客様自身でエンドユーザの声をシス テムに反映し、常に改善を続けられる点にあります。 ü プロフェッショナルサービスは、Salesforceのメリットを最大限活かしていただくために、お客様 にSalesforceのノウハウを吸収していただくことが必要と考えています。開発フェーズでお客様 に専属のSalesforce担当者をアサインしていただき、一緒にSalesforceの設定を行うことをお願 いしています。 Salesforce導入成功のポイント
- 11. プロジェクトマネジメント・ライフサイクル プロジェクトのタイム・フレーム（サンプル） 分析（要件定義） ソリューション設計 構築 検証 移行 運用設計 Go Live! 1W 2W 3W 4W 5W 6W 0W Sandbox（Full/Config）の移行プラン - 検証用 - データ移行 - トレーニング - 運用後の保守環境ステージング計画 ＜デザインレビュー＞ ・コーディングレビュー（VF/Apex） - ガバナ制約 - パフォーマンス ・ソリューション・レビュー - データモデル - データ・シェアリング ＜デザイン支援＞ ・インテグレーション・パターン リアル・非同期・バッチ etc分析（要件定義） ソリューション設計 構築 標準機能は Agile開発 開発機能は Waterfall開発
- 13. Salesforceアジャイル開発とウォーターフォールの比較 (1/2) No. フェーズ ウォーターフォール Salesforceアジャイル開発 工数 リスク 備考 工数 リスク 備考 1 要件定義 △ × ・ドキュメントの工数負荷が高い ・要件ギャップのリスクが高い ○ ◎ ・ドキュメントの工数負荷が少ない ・要件ギャップのリスクが少ない 2 ソリューション設 計 △ × ・要件ギャップのリスクが高い ○ ◎ ・同上 ・アジャイル開発の場合、要件が膨ら む可能性があるので、設計フェーズ以 降の変更管理がポイント 3 構築 △ × ・開発工数だけでなく、サーバーを 含めた環境構築の作業も多い ◎ ○ ・開発工数の効率が良い ・要件が広がるリスクがあり、変更管理 が重要（ただし、標準機能を含め、影 響範囲が少ない要件は対応するケー スもある） 4 検証 △ × ・初めて画面を確認するタイミングで の要件ギャップのリスクが高い ◎ ○ ・標準機能のテストは基本不要なので、 工数負荷が低い ・要件が広がるリスクがあり、変更管理 が重要（ただし、標準機能を含め、影 響範囲が少ない要件は対応するケー スもある） 5 移行 × ○ ・移行に関しては、進め方と作業負 荷は関係しない ・トレーニング環境や保守環境のの 準備に負荷が掛かる ○ ○ ・トレーニングや保守に関しても、 Sandboxの準備なので、効率的 プロジェクトへの影響度 ◎：小 → ○ → △ → ×：大 ＜プロジェクトへの影響度比較＞
- 14. No. フェーズ タスク詳細 ウォーターフォール Salesforceプロジェクト アウトプット アウトプット 備考 1 要件定義 要件確認 ・要件定義書 ・プロトタイプ ・実際にプロトタイプで画面を確認しながら要件を確 認 2 要件FIX ・要件定義書 ・機能要件一覧 ・機能要件一覧 ・要件一覧をWalk Through ※サンプル参照 3 ソリューション設計 デザイン設計 ・概要設計書 ・プロトタイプ 4 ・詳細設計書 ・機能設計書 （開発機能） ・開発機能に関しては、設計書で要件を確認する ケースあり（お客様都合） 5 テスト計画 ・テスト計画 ・単体テスト ・結合テスト ・総合テスト ・UAT ・テスト計画 ・開発機能テスト ・Sandboxにおけるデプロイ計画 ・UAT ・開発機能に関しては、テスト実施 ・各種Sanboxのテスト、移行、トレーニング、本番環 境のプランニング 6 構築 開発 ・システム・アプリ ・サーバー環境 ・テスト機 ・本番機 ・クライアント環境 ・Salesforce環境 ・デプロイ計画に基づき、Sandboxを準備 7 検証 各種テスト ・テスト報告（テスト機／本番機） ・単体テスト ・結合テスト ・総合テスト ・テスト報告 ・開発機能テスト ・各種設計書 ・テストを完了しだい、各種設計書を作成し、納品す る ・運用フェーズ以降での変更管理ドキュメントとして ご利用頂く 8 本番Go Liveま での計画 ・移行計画 ・トレーニング計画 ・保守体制計画 ・アプリ以外のサーバーなどを含めた保 守計画 ・移行計画 ・トレーニング計画 ・保守体制計画 9 移行 ・移行結果報告 ・テスト機／本番機 ・トレーニング・マニュアル ・移行結果報告 ・Sandbox／本番環境 ・トレーニング・マニュアル Salesforceアジャイル開発とウォーターフォールの比較 (2/2)
- 15. #forcedotcomjp プロジェクト体制（案） － エキスパート・サービス お客様 プロジェクト･チーム ｼｽﾃﾑ ﾁｰﾑﾘｰﾀﾞｰ プロジェクトオーナー プロジェクト責任者 営業 プロジェクトリーダー （SBA) コミュニケーション 業務チーム I/F開発 プロジェクト管理者 業務 ﾁｰﾑ ﾘｰﾀﾞｰ プロジェクトマネジャー 1名 I/F仕様 提示 テクニカル・ アーキテクト Scrum Team ビジネス・ アナリスト テクニカル・ アーキテクト（TA） テクニカル・ アーキテクト（TA） ビジネス・ アナリスト（BA) ビジネス・ アナリスト（BA) レビュー SFDCパートナー様 Salesforce.com
- 16. 弊社プロジェクトメンバーの役割(サンプル) ロール名 定義 必要な資格・スキル PM系 スクラム系 認定アドミニ ストレーター Sales Cloud コンサルタント Service Cloud コンサルタント 認定 デベロッパー 認定上級 デベロッパー プロジェ クト管理 者（PM） § プロジェクトの責任者 § 計画策定と進捗管理 § 課題管理 （課題と解決策 の管理と優先順位付けと交 渉） § スコープの変更管理 （仕様 要件変更管理と交渉） ◎ ○ ◎ ○ ○ ○ △ シニアビ ジネスア ナリス （Sr.BA） § 業務プロセスの分析要件定 義とソリューションデザインの ワークショップ（打合せ）の主 導 § 報告資料の作成 ○ ◎ ◎ ◎ ◎ ○ △ ビジネス アナリス （BA） § ソリューションデザイン § アプリケーション設定作業 § 設計ドキュメント作成 § 操作マニュアル作成 § 機能テスト遂行 ◎ ◎ ◎ ◎ ○ テクニカ ル・アー キテクト （TA） § アプリケーション・デザインレ ビュー § Salesforceアドオンプログラ ム開発 （Apexコード）） § システムインテグレーション 構築 ◎ ○ ○ ◎ ◎
- 17. お客様プロジェクトメンバーの役割(サンプル) ロール名 定義 プロジェクトオーナー • プロジェクト最終責任者 • プロジェクトメンバーアサイン プロジェクトマネジャ • 業務メンバーのご要件取りまとめ、指示・通達・調整・推進役 • 弊社との折衝窓口 他 業務メンバー • ユーザ要件の提供 • システム評価（検証シナリオ作成および評価） • 業務マニュアル作成 • エンドユーザへのトレーニング（計画/実施） I/F開発（システム連携） ・システムテスト実行 • 初期データ作成 • 検証用データ作成 I/F仕様定義 • システム連携サーバの開発・本番の環境手配および構築
- 18. セッション・プラン策定（サンプル） No. フェーズ セッション概要 日時 参加メンバー（お客様） 参加メンバー（弊社） PM 業務L ITL PM SBA BA TA 1 分析 業務ヒアリング① ○ ○ ○ ○ ○ 2 業務ヒアリング② ○ ○ ○ ○ ○ 3 業務ヒアリング③ ○ ○ ○ ○ ○ 4 システム連携1. ○ ○ ○ ○ ○ 5 ソリューション 設計 プロトタイプ① ○ ○ ○ ○ ○ 6 プロトタイプ② ○ ○ ○ ○ ○ 7 プロトタイプ③ ○ ○ ○ ○ ○ 8 システム連携2. ○ ○ ○ ○ ○ 9 構築 プロトタイプ①-2 ○ ○ ○ ○ ○ 10 プロトタイプ②-2 ○ ○ ○ ○ ○ 11 プロトタイプ③-3 ○ ○ ○ ○ ○ 12 検証 テスト報告1. ○ △ ○ ○ 13 テスト報告2. ○ △ ○ ○ 14 テスト報告3. ○ △ ○ ○ 15 移行 データ移行計画 ○ ○ ○ ○ 16 データ移行報告 ○ ○ ○ ○ 17 運用設計 Sandbox環境プラン ○ △ ○ ○ ○ 運用メンバープラン ○ △ ○ ○ ○ 18 ○：必須 △：可能であれば
- 20. リスク管理 コミュニケーション管理 スケジュール管理 リソース管理 スコープ管理 プロジェクト損益管理 プロジェクトマネジメント・ライフサイクル 計画 分析 設計 構築 検証 移行 プロジェクトマネジメント・ライフサイクル 7 „ 運用定着 プロジェクトマネジメント・ライフサイクルは以下の様な「計画」から「運用定着支援」の７つの局面から成り立ち 、更に、導入管理には以下に示した7つの管理項目（7トラック）が含まれます。 プロジェクト編成 導入管理 運用支援 ハイレベル・ デザイン (Force.com 適用性検証) 0 POA 1. プランニング／ビジョン・ゴール セット 2. アセスメント 3. POC 4. ハイレベル・デザイン 以下のような難易度の高いと 想定されるシステム構築の場合、 Feasibility Studyを実施し、 Force.comの適用性を検証します。 例： ・データ量 ・トランザクション量 ・要件の難易度 ・処理の複雑性
- 21. ・ビジネスペインポイント(課題)分析 ・ビジネス目標とゴールの設定 ・業務要件確定/Fit & Gapの分析 と優先順位設定 ・To-Beプロセス定義 • 業務プロセスフロー • 業務要件定義書 • データ関連図 • スコープ定義（更新） ・チェンジマネジメント ダッシュボード/レポートを活用した業務改革設計 ・ビジネス目標の実現に向けてのソリューション設計 ・ワークショップ形式による反復型の設計 ・プロトタイプの構築 ・Salesforceコンフィグレーション設計 アドオン開発詳細設計 ・運用定着支援計画の立案 ・ソリューション定義書 ・設定仕様書/プロファイル設定書 ・インテグレーション定義書 ・開発環境での統合テスト ・本番環境での業務シナリオに沿った ユーザ評価支援 ・初期データ移行支援 ・トレーニングカリキュラム策定と準備 ・プロジェクト管理 スコーピング/予算/品質/コミュニケーショ ・テスト指針 ・テスト計画 ・テスト兼報告書 ・本番環境構築： ユーザ登録/最終初期データおよび環境整備 ・ユーザトレーニング ・ドキュメント作成 ・ユーザおよびカスタマサポートへの知識移転（KT) ・運用マニュアル ・トレーニングマテリアル ・Salesforceアプリケーションの コンフィグレーション ・アドオン開発および システムインテグレーション開発 ・テストスクリプト作成 ・テストスクリプト（UT/UAT) ・プロジェクト要員計画とワークショップ開催 ・プロジェクトチャーター作成 ・プロジェクトスケジュール策定 ・プロジェクト定義書 ・プロジェクト憲章 ・スコープ定義書 ・スケジュール ・リスク管理 ・品質計画 ・コミュニケーション計画 u プロジェクト計画 u 業務分析 u ソリューション設計 u 検証 u 構築 u 移行 タスク 成果物 凡例 各フェーズ タスクと成果物 概要
- 23. どこで開発すればよいのか？ § 開発とテストのためのオンデマンド型の環境を用意しています § Developer Edition – 小規模で無料の組織 – デフォルトの設定のまっさらな環境 – ISVが独立したアプリケーションを開発するのに最適 § Force.com Sandbox – 本番環境から有効化した機能や設定をコピー – Full Sandboxは、本番環境からデータもコピー • データまでは必要がないケースが多いがオプションとして用意
- 24. Sandboxとは？ 特徴 § ある時点の自社の本番環境をコピーして作成（複数所有可能） § 設定やデータの内容は完全に本番と独立 § Sandbox上で設定した内容を本番環境に送ることができる § Sandboxは3種類あり、コピー内容やデータ容量に違いがある 用途 § 導入時のトライアンドエラー § 本番導入前のトレーニング § 運用時の追加機能の検証 § バージョンアップ時の新機能の検証 ある時点の自社の本番環境がコピーされた環境。 テストやトレーニングで利用。 本番環境 開発環境 トレーニング 環境 コピー コピー 設定更新 テスト環境 コピー
- 25. Sandboxの種類 ※各Sandboxは追加でご購入頂くことも可能 価格 #Developer sandbox 更新 インターバル コピー対象 データ 容量 Include license 備考 EE UE PxE Full Copy ライセンス金額×30% 15 Developer 環境 が含まれる 29日 設定+データ Full - 1 1 ・ステージング ・ロードテスト Partial Copy ライセンス金額×20% 10 Developer 環境 が含まれる 5日 設定+サンプルデータ ※ 各オブジェクト上限 レコード数：10,000件 5GB - - 1 ・ＵＡＴ ・トレーニング ・結合テスト Developer Pro ライセンス金額×5% 5 Developer 環境 が含まれる 1日 設定のみ 1GB - 5 5 ・単体テスト ・開発 Developer -- 1日 設定のみ 200MB 1 15 30 ・単体テスト ・開発
- 27. Sandbox を使った開発サイクル 中規模プロジェクトでの構成 本番環境 開発環境 本番 凡例 Developer Sandbox 設定のみコピー Sandbox＋テストデータ テスト環境
- 28. Sandbox を使った開発サイクル 本番環境 ステージング 環境 ユーザ受入れ テスト環境 テスト環境 開発環境 開発環境 本番 凡例 Developer Sandbox 設定のみコピー Sandbox＋テストデータ フルコピー Sandbox 大規模プロジェクトでの構成
- 29. バージョン管理ツールを使った開発サイクル 本番環境 ステージング 環境 ユーザ受入れ テスト環境 テスト環境 開発環境 開発環境 本番 凡例 Developer Sandbox 設定のみコピー Sandbox＋テストデータ フルコピー Sandbox バージョン 管理ツール
- 30. Sandboxを使った複数プロジェクトのリリースサイクル 本番環境 本番サポート 環境 ステージング 環境 本番 フルコピー Sandbox 設定のみコピーSandbox＋テストデータ 設定のみコピーSandbox＋トレーニングデータ 凡例 開発環境 統合環境 大規模プロジェクト トレーニング 環境 統合環境 小規模プロジェクト Developer Sandbox 開発環境 開発環境 開発環境 複数プロジェクトでの構成
- 31. 補足 Force.com Builderを利用したコーディングレス開発や，小規模なApexコードであれば，IDE（統合開発環境）がなくてもアプリケーショ ンを開発することが可能です。 しかし，大規模なアプリケーション開発を行う場合，複数の開発者による分業や，プログラムのバージョン管理などを行う必要が出 てきます。 そのためForce.comでは，「Force.com IDE」と呼ばれるEclipseのプラグインを提供しています。 「Force.com IDE」 はForce.comネイティブアプリケーションを開発するためのデベロッパー向けの開発環境で、 統合開発環境（IDE: Integrated Development Environment）であるEclipse上で動作いたします。 Force.com IDEでは、コードの記述から、テスト、デプロイまでの一連の開発作業を統合して行えるメリットがあります。 Force.com IDE を用いることによって、ApexコードやVisualforceのページの開発を行ったり、 XMLベースのメタデータコンポネントの編集（ オブジェクト定義や画面定義等）や、テスト、バージョン管理、 アプリケーションの管理を複数の環境に渡って行うことができます。 これらの情報は基本的にテキスト・データですので，オープンソースの構成管理ツール「Subversion」などを使って管理できます。 Force.com IDEはそのほか，ApexやVisualforce向けのシンタックスハイライト（キーワードの色分け表示）機能， コード入力支援を行う高性能なエディタ機能，作成したアプリケーションをコピーするデプロイ機能，などが備わっています。
- 33. リリースまでの準備 1. データ移行とSandbox環境プラン 2. トレーニングとお客様問合せサポート体制プラン 3. システム稼働後の保守体制プラン
- 34. 本番運用までの各タスクをいつ、どのSandboxで実施するかを計画します。 下記：トライアル環境（ご契約前のプレ環境）で開発を進め、開発終了後にSandbox環境を作成する想定 1/2～ 1/16～ Sandbox環境プラン 開発/単体テスト 12/12～1/26 UAT 2/22～ 28 トレーニング 代表者・エンドユーザ向けオペ・トレ 本番運用 3/1～ ライセンス契約 Ｓａｎｄｂｏｘ作成 SANDBOX作成 （設定・データコピー） SANDBOX作成 （設定コピー） テストデータ削除 マスタデータ登録 本番環境 トレーニング環境（Config Only Sandbox） 検証環境（FullSandbox） 準備・結合テスト 2/2～ 1/9～ 2014年1月 1/23～ 2014年2月 1/30～ 2/13～ 2/6～ 2/20～ 2/27～ 2014年3月 本番用マスタデータ準備 1/4～16 本番マスタ移行 1/25～31 オペレーショントレーニング 2/6～2/27 マスタ移行 2/2～3 移行リハ 1/4～6 メールアドレス 切り替え 2/21 代表者向け トレーニング 2/13
- 35. Salesforceメンテナンス計画を外したリリース作業 以下のSalesforceメンテナンス計画を外したリリース作業を計画する必要があります。 https://help.salesforce.com/apex/HTViewSolution?urlname=Salesforce-com-Maintenance-Schedule&language=ja 【補足事項】 ・上記は現状の弊社サービス運用作業の基本ルールをご説明したものであり、将来変更される可能性もあります。 ・計画メンテナンスにつきましては、上記作業時間枠内の30分間から最長4時間の範囲で作業計画されます。具体的な作業時間およびサービス への影響は、実施決定の都度1週間前までにトラストサイト（http://trust.salesforce.com/trust/jp/status/）にてお客様に告知いたしますので、同サイ トを随時ご参照ください。 ・メジャーリリースは基本的に年3回を計画しておりますが、変更される可能性もあります。 ・作業時間はUS（太平洋時間PST）を基準に計画されておりますため、夏時間（サマータイム制）が適用される3月第2日曜日から11月第1日曜日まで は作業時刻が1時間繰り上がります。 ・計画メンテナンス枠はUS時間の第1,第3土曜日に計画されますため、月初日が日曜日の月には、第2,第4日曜がメンテナンス枠となります。 種類 内容 頻度 作業時間枠 サービス停止 メジャーリリース （機能の追加）Salesforceメ ジャーバージョンアップ 年3回 AP0:日曜早朝 CS5,CS6 :日曜早朝 5分間以内の停止 計画メンテナンス データセンター運用上のメ ンテナンス作業 月2回まで AP0:第1,第3 日曜3:00～7:00 CS5,CS6:第1,第3 日曜0:00～4:00 停止または瞬間停止 緊急メンテナンス 緊急のデータセンター運用 上のメンテナンス作業 例外的 都度決定 停止または瞬間停止
- 37. 大規模展開へのトレーニング・プラン 通常Salesforceの本番運用開始前のトレーニングは、以下のような役割分担と進め方を実施しています。 ＜ドキュメント関連＞ ※トレーニングでのメモを追記し、自席でバイブルとしてご利用頂く ＜トレーニング関連＞ ü 通常、Salesforce展開のためのトレーニングはハンズオン形式を採用することが多く、その場合、10-15名程度が一回の トレーニングの対象となります。 ü その場合、時間とコストが掛かり、Scalabilityが弱いので、Train the Trainer形式を採用し、お客様のキーマンに対して、 トレーニングを実施し、そのキーマンの方が現場への展開、および問合せのサポートの窓口として各現場をサポートする 体制を構築頂くことをご提案するケースが多くあります。 No. タイトル 担当 備考 1. 業務マニュアル お客様 業務面での変更点を説明 2. 操作マニュアル プロジェクト・チーム 画面スクリーン・ショットを中心に、各画面での項目やボタン、操作を説明 No. タイトル 担当 対象 備考 1. Train the Trainer （現場担当向け） お客様 現場のキーマン （お客様） ・お客様：業務面での変更点をご説明 ・プロジェクト・チーム：主に画面操作に関して、ご説明 2. Train the Trainer （マネジメント向け） プロジェクト・チーム マネジメント層 （お客様） 特にレポートやダッシュボードに関して、ご説明 ・お客様：業務面での変更点をご説明 ・プロジェクト・チーム：主に画面操作に関して、ご説明 3. 現場でのトレーニング Train the Trainer 受講者（お客様） 現場担当 ・業務面での変更点、および各画面操作に関してご説明
- 39. Premier Success Plan 体制イメージ お客様 セールスフォース・ドットコム システム 管理者様 テクニカル サポート 技術問い合わせ対応 アプリケーション/開発者サポート アドミン作業実施 < 組織パスコード > R&D オペレーション センター 貴社担当者* システム状況の通知 統括 責任者 連携 情報共有 定着化・活用支援 担当営業 お客様状況の共有 ユーザ 様 問い合わせの受付/確認 (*)一定金額のご契約を頂きますと、お客様担当者がアサインされます。 テクニカルサポート
- 40. お客様 業務 ・AAA様 ・BBB様 全体体制（イメージ） セールスフォース・ドットコム コンサル IT ・CCC様 ・DDD様 担当営業 ・777 SIパートナー様 お客様担当者 ・666 ・111様 ・222様 ・333様 Premier Success Plan (サポート) ・444 ・555 お客様とSI パートナー様 とのご契約に 準じる 通常サポート時間 平日 9:00-18:00 緊急電話窓口 24時間365日 開発物関連 ・利用促進・定着化施策ご提案 ・弊社・他社お客様活用事例紹介 • お客様にて問題の1次切り分けを行っていただき、開発物関する事象はSIパートナー様へ、Salesforceの機能 に関する事象はSFDC Premier Success Plan テクニカルサポートまでご連絡ください。 • お客様による1次切り分けが難しい場合は、SIパートナー様にご連絡を頂き、切り分けを行って頂いてください。 (そのために、導入後の保守サービス契約が必要です) • 切り分けの結果、製品の問題と判断した場合は、プレミアサポートによる対応となります。 必要に応じてSFDCコンサルティングサービスによる支援(有償)をご提案致します。 製品サポート
- 41. 各社の対応範囲 内容 対応範囲 対応窓口 Premier Success Plan ・Salesforce製品に関する問い合わせ対応 ・開発者サポート ・24時間365日緊急電話窓口 ・お客様担当者(一定金額以上) サポート (SFDC) SIパートナー様 ・担当開発部分に関しての問い合わせ、障害、瑕疵対応 SIパートナー様 SFDCコンサル ・エキスパートサービス コンサル (SFDC) 費用のお見積りは各会社担当営業までお問い合わせください。
- 42. #forcedotcomjp Developer Forceをフォローください @developerforcej/ #forcedotcomjp Developer Force Japan +Developer Force Japan Developer Force Japan Developer Force Group