Salesforce
- 1. Salesforce アジャイル開発プロジェクトの進め方 株式会社セールスフォース・ドットコム
- 2. 目次 § ADM（Agile Development Methodology）とは § Salesforceのプロジェクト・アプローチ § プロジェクト体制 別紙 § プロジェクト導入方法論（抜粋） § サンプル成果物 2
- 3. ADM（Agile Development Methodology） ADM（Agile Development Methodology）とはSalesforce.comに特化した形のアジャイル開発手法です。 一般的なWF開発よりも、リスクを軽減したスピード導入を可能とさせます。 ウォーターフォールでの開発 アジャイルでの開発(ADM) プロジェクトの進行 3 デイリー・スタンドアップ 2 スプリント 見直できる期間 正確に要件を満たし プランニング ていることを確認 統合 要件定義 テスト 30日間 4 スプリント スプリント・レビュー 結合 コミットメント 外部設計 テスト プロダクト・バックログ リリース可能な成果物 1 5 レトロスペクティブ 内部設計 単体テスト 1 2 3 4 5 6 7 開発 原則 • 柔軟に変更を対応 • チームでの協業 • ビジネス要件の実現 • ヒアリングを基本としたお客様の巻き込み • 確定したプロジェクト期間 • 柔軟なプライオリティ変更（スコープは変更なし） • その場でのディシジョン 3
- 4. 3 ADMでのプロジェクト・タイムライン 2 ※2×2週間のケース コミットメント 30日間 スプリン 4 1 ト 5 1 2 3 4 5 6 7 Week 0 Week 1 Week 2 Week 3 Week 4 (プランニング) Tasks: • ユースケース、業務要件確認の ためのワークショップ実施 リリース リリース • 業務要件の優先順位付け ベータ 1.0 • 要件の難易度精査 • 業務要件実現のための全体デ ザイン整理 Tasks: 要件の優 • トレーニング・マテリアル作成 • 全体業務要件整理 先順位付 要件の優 • チーム・ビルディング け 先順位付 • エンドユーザー・トレーニング け • プロダクト・バックログに詳細業 実施 務要件をインプット • 運用引き継ぎ実施 • 初回スプリントまでのロードマッ • 次期アプリケーション準備： プ策定 デイリー・ ・ユーザー設定 デイリー・ お客様受 スクラム・ アプリケー お客様受 スクラム・ アプリケー ・利用率確認ダッシュボード 入れテスト ミーティン ション構築 入れテスト ミーティン ション構築 ・Salesforce Ideasによる改 グ グ 善要望の収集 ・運用サポートフロー策定 要件とア 要件とアプ プリの リのギャッ ギャップ確 プ確認 認 スプリント1 スプリント2 4
- 5. プロジェクト・ステージ（全体） ビジョンとバリュー • プロジェクトの目的、ビジョンとバリューを定義 • ビジネスKPIの定義（どう成功を計測するか） の定義 ロードマップ策定 • プロジェクトの目的に対しての目標達成ロードマップを定義 • Force.comでのアプリケーション実装 開発スプリント • 各チェックポイントでのアプリケーションとドキュメント準備 リリース • Force.comでのPDCAサイクルによる業務改善の遂行 継続的な改善 • オペレーションの継続 • ユーザーからのフィードバックの収集と継続的な改善 5
- 6. ビジョンとバリュー プロジェクトの目的、ビジョンとバリューを定義 の定義 ビジネスKPIの定義（どう成功を計測するか） 目的 • 課題と現状ステータス認識の共通化 AsIs業務の • エグゼクティブ・レベルでのビジネスゴールの合意形成 • ビジネスKPIの定義 理解 • お客様によるプロジェクト・メソドロジーのご理解 成果物 • ハイレベルなビジネス目標（お客様の業務用後で） • ビジネスKPIリスト 課題の明確化 プロジェクト・タスク（サンプル） • 現行業務、アプリケーションのレビュー • ビジネス目標理解のためのエグゼクティブおよびリーダーとのインタビュー • 現状の業務課題とあるべき姿を理解するためのキーマンとのインタビュー • 現状のシステム課題とあるべき姿を理解するためのキーマンとのインタビュー ビジネス目標と • プロジェクトチームの形成とForce.com開発メソドロジーの共有 KPI設定 • お客様ビジョン、ゴールとビジネスKPIの共有 実例 オンプレミスのシステムをクラウド化することにより、大幅なサポート負荷の改善を目指すべく、 発生しうる課題を克服する必要があります。以下は実例 ToBe業務策定 • 次期四半期に200ユーザをデプロイし、旧システムを同時に停止させたい • 2か月のパイロット運用の中で、旧システムのデータも移行させたい • 新たなソリューションの導入は段階的なアプローチではなく、ビックバンでリリースしたい • 利便性向上のため、あまり使用されていない既存機能がリスト化したい SCRUM 101: Product Backlog 6
- 7. プロジェクトの目的に対しての目標達成ロードマップを定義 ロードマップ策定 あるべき姿（ビジョン）の 目的 定義 • ユーザー・レベルでのビジネスゴールの合意形成 • ビジネス・バリューを基本とした要件の優先順位付け • リリース・ロードマップ策定 成果物 プロジェクト・プラン策定 • 優先順位付き機能要件一覧 • プロジェクト・プラン、リリース・ロードマップ、WBS／見積作成 • 開発スプリント計画 • スケジュール • リソース – 各チームサイズ確定 業務要件の難易度、 プロジェクト・タスク（サンプル） 優先順位の定義 • 顧客キーマンとのセッション開催： ユーザー・ストーリーとKPI定義のた め • ユーザー・ストーリーの優先順位付けと難易度の定義 • ユーザー・ストーリーの技術的、業務的評価 優先順位、リソース、スケ • スクラム・チームサイズの確定 ジュールと言う観点での • プロダクト・バックログタブに詳細ユーザー・ストーリーをインプット 業務要件のカテゴライズ • 初回スプリント用として、スプリント・バックログタブに開発スプリントとリ リース計画をインプット リリース・ロードマップの 共有 SCRUM 101: Sprint Planning 7
- 8. Force.comでのアプリの実装 開発スプリント 各チェックポイントでのアプリケーションとドキュメント準備 目的 • ユーザー・ストーリー毎のテストシナリオ策定 タスク定義（ユーザー・ • 開発作業およびテスト実行 ストーリーの詳細化） • ユーザー受入れテストの事前準備 成果物 • テスト結果報告書 • Force.comアプリケーション アプリケーション作成 • ユーザー受入れテスト • 本開発スプリントの振り返り • 次回スプリントのためのスプリント・バックログの再優先順位付け ユーザー・ストーリーを プロジェクト・タスク（サンプル） • Force.com上でのプロジェクト管理 ベースとした評価項目策 • ドキュメント作成 • ユーザー・ストーリー • 受入れテストのクライテリアと WBSタスクとの関連付け • リリース・マネジメントとプロジェクト全体 ユーザー受入れテスト 管理 SCRUM 101: Daily Stand-Up, Sprint Review, Team Retrospective 8
- 9. Force.comでのPDCAサイクルによる業務改善の遂行 リリース 目的 変革への • ユーザー利用定着化支援 準備 • ビジネスゴール達成への合意 成果物 • ユーザー受入れ検証 • デプロイ済みForce.comアプリケーション • トレーニング済みエンドユーザー 変革への プロジェクト・タスク（サンプル） サポート • エンドユーザー・コミュニケーション • トレーニング・マテリアル作成、およびエンドユーザー・トレーニング実施 • 管理者マニュアル作成 • 新規アプリケーションのためのデプロイ計画: • データ移行 • システム連携開始 • ユーザー設定 ビジョンに • ユーザー利用定着化ダッシュボード作成 対しての評価 • Salesforceアイディアの有効化、サポートプロセスの確立 SCRUM 101: Sprint Review, Team Retrospective 9
- 10. オペレーションの継続 継続的な改善 ユーザーからのフィードバックの収集と継続的な改善 アプリケーションの 目的 • オペレーションの成熟化 継続的改善 • エンドユーザーからのフィードバックを集められるような環境の整備 • KPI達成度の継続的チェック 成果物 ユーザー・コミュニティの • トレーニング済みSalesforce管理者ユーザー • 管理者マニュアル 活性化支援 • エンドユーザーからのフィードバック収集と継続的改善 プロジェクト・タスク（サンプル） • エンドユーザー・コミュニケーション • 実施中エンドユーザー・トレーニングのプログラム改善 継続的な改善への • ユーザー利用定着化とデータ品質のチェックと改善 タスク定義 • エンドユーザーからのフィードバック収集 • プロダクト・バックログとスプリント・バックログの再優先順位付け 新たなプロジェクトに向け たタスクの再優先順位付け SCRUM 101: Product Backlog, Sprint Planning 10
- 11. Salesforceのプロジェクト・アプローチ 日本のビジネス環境に合わせた形で、実際の日本のセールスフォース導入プロジェクトは W/Fとアジャイルのハイブリッド形式を選択することが多いです。 ウォーターフォールでの開発 アジャイルでの開発(ADM) プロジェクトの進行 3 デイリー・スタンドアップ 見直できる期間 正確に要件を満たしているこ 2 スプリントプランニング とを確認 統合 要件定義 テスト 4 スプリント・レビュー 結合 30日間 外部設計 スプリント テスト コミットメント リリース可能な成果物 1 プロダクト・バックログ 内部設計 単体テスト 5 レトロスペクティブ 1 2 3 4 開発 5 6 7 高コスト、ハイリスクな進め方 請負SI契約が主流の日本では、採用が難しい※ ※T&M契約のUSでは採用されている Salesforceのハイブリッド開発手法 プロジェクトの進行 見直できる期間 ソリューション 設定の 統合テスト 要件定義 の確認 確認 （UAT） ×N回 ×N回 設定 設定 11
- 12. ハイブリッド開発手法におけるプロジェクトマネジメント・ライフサイクル プロジェクトのタイム・フレーム（サンプル） 0W 1W 2W 3W 4W 5W 6W 分析（要件定義） ＜デザインレビュー＞ ・コーディングレビュー（VF/Apex） 標準機能は - ガバナ制約 ソリューション設計 Agile開発 - パフォーマンス ・ソリューション・レビュー - データモデル 構築 - データ・シェアリング ＜デザイン支援＞ ・インテグレーション・パターン リアル・非同期・バッチ etc 分析（要件定義） 開発機能は Waterfall開発 ソリューション設計 構築 検証 ・Sandbox（Full/Config）の移行プラン Go Live! - 検証用 移行 - データ移行 - トレーニング - 運用後の保守環境ステージング計画 運用設計 12
- 13. Salesforce導入成功のポイント ü 全世界200万人以上のアクティブユーザの声を年3回のバージョンアップに反映し続けてきた Salesforceは、まさにお客様のベストプラクティスを集めたツールセットです。これらを最適に組 み合わせる事により、“ゼロ”から設計・開発する場合に比べて、専用のアプリケーションを圧 標準機能を最大限 倒的に早く簡単に構築することが出来ます。 活用する ü Salesforceの標準機能を工夫する事により必要ない追加開発を減らすことが出来ます。導入 のスピードとお客様自身がカスタマイズできる事により利用開始後の保守コストを下げ、かつ 長期的にSalesforceのバージョンアップによる拡張性を最大活用できるメリットがあります。 ü 曖昧な要件を実際に利用して実現イメージを掴み、それを要件定義にフィードバックできるパイ ロットの手法は、フロントシステムの開発手法として非常に有効であり、改善周期を繰り返し パイロットを実施し つかえるシステムを実現します。 要件をブラッシュアップ ü SaaS型のアプリケーション開発は、旧来のシステム導入方式で必要なHW/SWのサイジングや調 達、初期設定などの作業が必要なくパイロット導入できます。 ü お客様がSalesforceの最大のメリットを享受できるのは、システム開発が終了し実際に運用開 始した後です。Salesforceのカスタマイズの柔軟性は、お客様自身でエンドユーザの声をシス テムに反映し、常に改善を続けられる点にあります。 お客様と一緒に作る ü プロフェッショナルサービスは、Salesforceのメリットを最大限活かしていただくために、お客様 にSalesforceのノウハウを吸収していただくことが必要と考えています。開発フェーズでお客様 に専属のSalesforce担当者をアサインしていただき、一緒にSalesforceの設定を行うことをお 願いしています。 13
- 14. Salesforceアジャイル開発とウォーターフォールの比較 (工数とリスク) Salesforceのアジャイル開発手法は、ドキュメント作業／開発作業／環境構築において、 大きく工数を削減することができ、プロジェクトのリスクを低減することを可能にします。 以下に、各プロジェクト・フェーズにおける相違点と、プロジェクトへの影響度を比較します。 ＜プロジェクトへの影響度比較＞ No. フェーズ ウォーターフォール Salesforceアジャイル開発 工数 リスク 備考 工数 リスク 備考 1 要件定義 △ × ・ドキュメントの工数負荷が高い ○ ◎ ・ドキュメントの工数負荷が少ない ・要件ギャップのリスクが高い ・要件ギャップのリスクが少ない 2 ソリューション設計 △ × ・要件ギャップのリスクが高い ○ ◎ ・同上 ・アジャイル開発の場合、要件が膨らむ可 能性があるので、設計フェーズ以降の変 更管理がポイント 3 構築 △ × ・開発工数だけでなく、サーバー ◎ ○ ・開発工数の効率が良い を含めた環境構築の作業も多い ・要件が広がるリスクがあり、変更管理が 重要（ただし、標準機能を含め、影響範囲 が少ない要件は対応するケースもある） 4 検証 △ × ・初めて画面を確認するタイミン ◎ ○ ・標準機能のテストは基本不要なので、 グでの要件ギャップのリスクが高 工数負荷が低い い ・要件が広がるリスクがあり、変更管理が 重要（ただし、標準機能を含め、影響範囲 が少ない要件は対応するケースもある） 5 移行 × ○ ・移行に関しては、進め方と作業 ○ ○ ・トレーニングや保守に関しても、 負荷は関係しない Sandboxの準備なので、効率的 ・トレーニング環境や保守環境の の準備に負荷が掛かる プロジェクトへの影響度 ◎：小 → ○ → △ → ×：大 14
- 15. Salesforceアジャイル開発とウォーターフォールの比較 (アウトプット) No. フェーズ タスク詳細 ウォーターフォール Salesforceプロジェクト アウトプット アウトプット 備考 1 要件定義 要件確認 ・要件定義書 ・プロトタイプ ・実際にプロトタイプで画面を確認しなが ら要件を確認 2 要件FIX ・要件定義書 ・機能要件一覧 ・要件一覧をWalk Through ・機能要件一覧 ※サンプル参照 3 ソリューション設計 デザイン設計 ・概要設計書 ・プロトタイプ 4 ・詳細設計書 ・機能設計書 ・開発機能に関しては、設計書で要件を （開発機能） 確認するケースあり（お客様に合わせる） 5 テスト計画 ・テスト計画 ・テスト計画 ・開発機能に関しては、テスト実施 ・単体テスト ・開発機能テスト ・各種Sanboxのテスト、移行、トレーニン ・結合テスト ・Sandboxにおける グ、本番環境のプランニング ・総合テスト デプロイ計画 ・UAT ・UAT 6 構築 開発 ・システム・アプリ ・Salesforce環境 ・デプロイ計画に基づき、Sandboxを準 ・サーバー環境 備 ・テスト機。。 ・本番機 ・クライアント環境 7 検証 各種テスト ・テスト報告（テスト機／本番機） ・テスト報告 ・テストを完了しだい、各種設計書を作成 ・単体テスト ・開発機能テスト し、納品する ・結合テスト ・各種設計書 ・運用フェーズ以降での変更管理ドキュメ ・総合テスト ントとしてご利用頂く 8 本番Go Live ・移行計画 ・移行計画 までの計画 ・トレーニング計画 ・トレーニング計画 ・保守体制計画 ・保守体制計画 ・アプリ以外のサーバーなどを含 めた保守計画 9 移行 ・移行結果報告 ・移行結果報告 ・テスト機／本番機 ・Sandbox／本番環境 ・トレーニング・マニュアル ・トレーニング・マニュアル 15
- 16. プロジェクト体制（案） － エキスパート・サービス お客様 プロジェクト･チーム プロジェクトオーナー プロジェクト責任者 営業 プロジェクト管理者 プロジェクトマネジャー ビジネス・ アナリスト 1名 業務 ﾁｰﾑ ﾘｰﾀﾞｰ ｼｽﾃﾑ ﾁｰﾑﾘｰﾀﾞｰ コミュニケーション レビュー Scrum Team 業務チーム I/F仕様 I/F開発 プロジェクトリーダー 提示 （SBA) テクニカル・ ビジネス・ ビジネス・ アーキテクト アナリスト（BA) アナリスト（BA) テクニカル・ テクニカル・ アーキテクト（TA） アーキテクト（TA） SFDCパートナー様 Salesforce.com 16
- 17. 弊社プロジェクトメンバーの役割(サンプル) 必要な資格・スキル PM系 スクラム系 認定アドミニ Sales Cloud Service Cloud 認定 認定上級 ロール名 定義 ストレーター コンサルタント コンサルタント デベロッパー デベロッパー § プロジェクトの責任者 ◎ ○ ◎ ○ ○ ○ △ § 計画策定と進捗管理 プロジェク ト管理者 § 課題管理 （課題と解決策の （PM） 管理と優先順位付けと交渉） § スコープの変更管理 （仕様 要件変更管理と交渉） シニアビ § 業務プロセスの分析要件定義 ○ ◎ ◎ ◎ ◎ ○ △ ジネスア とソリューションデザインの ナリス ワークショップ（打合せ）の主導 （Sr.BA） § 報告資料の作成 § ソリューションデザイン ◎ ◎ ◎ ◎ ○ ビジネス § アプリケーション設定作業 アナリス （BA） § 設計ドキュメント作成 § 操作マニュアル作成 § 機能テスト遂行 § アプリケーション・デザインレ ◎ ○ ○ ◎ ◎ テクニカ ビュー ル・アーキ § Salesforceアドオンプログラム テクト 開発 （Apexコード）） （TA） § システムインテグレーション構 築 17
- 18. お客様プロジェクトメンバーの役割(サンプル) ロール名 定義 プロジェクトオーナー • プロジェクト最終責任者 • プロジェクトメンバーアサイン プロジェクトマネジャ • 業務メンバーのご要件取りまとめ、指示・通達・調整・推進役 • 弊社との折衝窓口 他 業務メンバー • ユーザ要件の提供 • システム評価（検証シナリオ作成および評価） • 業務マニュアル作成 • エンドユーザへのトレーニング（計画/実施） I/F開発（システム連携） ・システムテスト実行 • 初期データ作成 • 検証用データ作成 I/F仕様定義 • システム連携サーバの開発・本番の環境手配および構築 18
- 19. アジャイル・プロトタイプの進め方 プロトタイプを回す際は、内部レビューとお客様レビューをそれぞれ繰り返し回していきます。 お客様 AsIs業務説明 レビュー お客様 KPI AsIs AsIs 帳票 業務概要 ② ToBe業務 AsIs業務 ToBe業務策定 提案デモ ヒアリング プロトタイプ・ （プロトタイプ） シナリオ Salesforce 誰が、どの画面 プロジェクト・ で、何をするか プロトタイプ・ カスタマイズ シナリオ チーム PDCAサイクル （画面） Salesforce 画面、セキュリティ（Role/ ① Profile）関連など データ 投入 テスト データ カスタマイズ （レポート／ダッ お客様との シュボード） 内部作業 ミーティング Salesforce 19
- 20. セッション・プラン策定（サンプル） プロジェクト序盤はお客様のお時間も確保して頂くため、プロジェクト開始当初に大枠のプランを共有します。 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
- 21. 別紙 § プロジェクト導入方法論 抜粋 21
- 22. プロジェクトマネジメント・ライフサイクル プロジェクトマネジメント・ライフサイクルは以下の様な「計画」から「運用定着支援」の７つの局 面から成り立ち、更に、導入管理には以下に示した7つの管理項目（7トラック）が含まれます。 プロジェクトマネジメント・ライフサイクル プロジェクト編成 導入管理 運用支援 0 POA 計画 分析 設計 構築 検証 移行 7 „ 運用定着 ハイレベル・ デザイン (Force.com 適用性検証) リスク管理 1. プランニング／ ビジョン・ゴールセット スコープ管理 2. アセスメント 3. POC 4. ハイレベル・デザイン スケジュール管理 以下のような難易度の高いと リソース管理 想定されるシステム構築の場合、 Feasibility Studyを実施し、 プロジェクト損益管理 Force.comの適用性を検証します。 例： コミュニケーション管理 ・データ量 ・トランザクション量 ・要件の難易度 ・処理の複雑性 22
- 23. 各フェーズ タスクと成果物 概要 凡例 タスク 成果物 u プロジェクト計画 u 業務分析 u ソリューション設計 ・プロジェクト要員計画とワークショップ開催 ・チェンジマネジメント ・ビジネスペインポイント(課題)分析 ・プロジェクトチャーター作成 ダッシュボード/レポートを活用した業務改革設計 ・ビジネス目標とゴールの設定 ・プロジェクトスケジュール策定 ・ビジネス目標の実現に向けてのソリューション設計 ・業務要件確定/Fit & Gapの分析 ・ワークショップ形式による反復型の設計 と優先順位設定 ・プロトタイプの構築 ・To-Beプロセス定義 ・Salesforceコンフィグレーション設計 アドオン開発詳細設計 ・運用定着支援計画の立案 プロジェクト定義書 • 業務プロセスフロー ・ソリューション定義書 ・プロジェクト憲章 • 業務要件定義書 ・設定仕様書/プロファイル設定書 ・スコープ定義書 • データ関連図 ・インテグレーション定義書 ・スケジュール • スコープ定義（更新） ・リスク管理 ・品質計画 ・コミュニケーション計画 u 構築 u 検証 u 移行 ・Salesforceアプリケーションの コンフィグレーション ・開発環境での統合テスト ・本番環境構築： ・アドオン開発および システムインテグレーション開発 ・本番環境での業務シナリオに沿った ユーザ評価支援 ユーザ登録/最終初期データおよび環境整備 ・テストスクリプト作成 ・初期データ移行支援 ・ユーザトレーニング ・トレーニングカリキュラム策定と準備 ・ドキュメント作成 ・プロジェクト管理 ・ユーザおよびカスタマサポートへの知識移転（KT) スコーピング/予算/品質/コミュニケーション ・テスト指針 ・テストスクリプト（UT/UAT) ・運用マニュアル ・テスト計画 ・トレーニングマテリアル ・テスト兼報告書 23
- 24. Thank you! 24