More Related Content
Similar to Salesforce (20)
More from Salesforce Developers Japan
More from Salesforce Developers Japan (20)
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
- 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
- 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
- 23. 各フェーズ タスクと成果物 概要
凡例
タスク
成果物
u プロジェクト計画
u 業務分析
u ソリューション設計
・プロジェクト要員計画とワークショップ開催
・チェンジマネジメント
・ビジネスペインポイント(課題)分析
・プロジェクトチャーター作成
ダッシュボード/レポートを活用した業務改革設計
・ビジネス目標とゴールの設定
・プロジェクトスケジュール策定
・ビジネス目標の実現に向けてのソリューション設計
・業務要件確定/Fit & Gapの分析
・ワークショップ形式による反復型の設計
と優先順位設定
・プロトタイプの構築
・To-Beプロセス定義
・Salesforceコンフィグレーション設計
アドオン開発詳細設計
・運用定着支援計画の立案
プロジェクト定義書
• 業務プロセスフロー
・ソリューション定義書
・プロジェクト憲章
• 業務要件定義書 ・設定仕様書/プロファイル設定書
・スコープ定義書
• データ関連図
・インテグレーション定義書
・スケジュール
• スコープ定義（更新）
・リスク管理
・品質計画
・コミュニケーション計画
u 構築
u 検証
u 移行
・Salesforceアプリケーションの コンフィグレーション
・開発環境での統合テスト
・本番環境構築：
・アドオン開発および システムインテグレーション開発
・本番環境での業務シナリオに沿った ユーザ評価支援
ユーザ登録/最終初期データおよび環境整備
・テストスクリプト作成
・初期データ移行支援
・ユーザトレーニング
・トレーニングカリキュラム策定と準備
・ドキュメント作成
・プロジェクト管理
・ユーザおよびカスタマサポートへの知識移転（KT)
スコーピング/予算/品質/コミュニケーション
・テスト指針
・テストスクリプト（UT/UAT) ・運用マニュアル
・テスト計画
・トレーニングマテリアル
・テスト兼報告書
23
