パートナーオフィスアワー ウェビナー資料

1. パートナーオフィスアワー
(Partner Office Hour) 第九回
テーマ “構築⼒”
アプリケーションライフサイクル管理について
2017/12/21
AppExchange アライアンス部 川畑 隆博

2. 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.
Forward-Looking Statement
Statement under the Private Securities Litigation Reform Act of 1995

3. 話者紹介
AppExchange アライアンス部
テクニカルエバンジェリスト
川畑 隆博
AppExchange アプリケーション開発の技術⽀援を担当
略歴：Web デベロッパ → Force.com デベロッパ → テクニカルアーキ
テクト → テクニカルエバンジェリスト

4. 本⽇のトピック
​Sandbox
​アプリケーション
ライフサイクル管理
​SalesforceDXとSandbox

5. アプリケーションライフサイクル管理
概要とアジャイル開発例

6. アプリケーションライフサイクル管理（ALM）とは?

7. ステップ 1: 計画
- アプリケーション計画
- 要件の収集と分析
- 設計仕様の作成
ステップ 2: 開発
- 設計仕様に基づくアプリケーション開発
- 宣⾔型ツール (ユーザインターフェースで使⽤可
能なツール)
- プログラム型ツール (Apex、Visualforce、
Lightning コンポーネントなど)
ステップ 3: テスト
- 単体テストと機能テスト
- UAT
- ステージングと最終テスト
ステップ 4: リリース
- 本番リリース
- トレーニング
アプリケーションライフサイクル管理のステップ

8. アプリケーションライフサイクル管理の役割
役割 主な責務
リリースマネージャ リリーススケジュールの管理およびリリースと業務の調整を担当します。また、バー
ジョン管理からの変更のプルも担当する場合があります。
プロダクトマネージャ アプリケーションや機能のビジネス要件を定め、開発チームと協⼒してこれらの要件
を満たします。また、ユーザ受け⼊れテストを実施して、要件を満たしていることを
確認します。
ソフトウェア開発者 Sandbox で新しい機能を開発します。ポイント & クリックによる宣⾔型開発とコー
ドによる開発の両⽅を⾏います。
品質管理技術者 Sandbox で新しい機能をテストします。
システム管理者 本番組織で管理タスクを⾏うほか、本番組織で⾏われたすべての変更を追跡します。
トレーニング講師 新しいアプリケーションおよび機能について企業の従業員にトレーニングを実施しま
す。

9. ガバナンスを使⽤した変更の管理
応答性と適応性の⾼いガバナンス フレームワーク 3 つの要素。
1. センターオブエクセレンス
- さまざまな機能グループの数⼈のステークホルダーが協⼒して、変更がビジネス⽬標をサ
ポートし、IT のベストプラクティスとプロセスに従うようにします。
2. リリース管理
- 変更セットや Sandbox のようなツールを使⽤して変更を管理します。バックログリストを
使⽤して優先順位を管理すれば、最も重要な変更を最初に処理できます。また、組織につい
ての知識を深めながら完全なリリース管理プロセスを設計してドキュメント化すると、
Salesforce を使⽤する全ユーザが安全な実⾏⽅法を理解できます。
3. 設計標準
- コーディング、テスト、インテグレーション、⼤量データ、他の Salesforce ユーザと共有
するサービスに影響するその他の領域について主要な標準に従います。

10. リリース管理プロセスの作成
デイリーリリース
• バグフィックス
• 単純な変更
マイナーリリース
• 数週間に⼀度
• 限定されたテスト
• ⽇々のビジネスに影響を与えない、またはトレーニングが必要ない単純な変更
メジャーリリース
• 四半期に⼀度
• 新しい取り組み
• ⼊念なテストとトレーニングが必要
※Salesforceアップグレードのテスト
• 多くのお客様がメジャーリリースにリンクしています

11. ソフトウェア開発⼿法
アジャイル(テスト駆動 / ビジネスフォーカス)
• ビジネスにフォーカス
• 短いスプリントによるリスクの低減
• 定期的なフィードバックと透過的なコミュニケーション
管理で可視性を向上
ウォーターフォール（ステージ駆動/リリースフォーカス）
• リリースと機能にフォーカス
• フルスコープでのフェーズ分析によるリスクの低減する
• ドキュメンテーションとコミュニケーションにより可視性が向上
×顧客に価値を届けるまで時間がかかります。×顧客はリリースされるまで価値がわかりません。

12. ⽇本のビジネス環境に合わせた、W/Fとアジャイルのハイブリッド形式
ハイブリッド開発⼿法
要件定義
外部設計
内部設計
開発
単体テスト
結合
テスト
統合
テスト
プロジェクトの進⾏
⾒直できる期間
ウォーターフォールでの開発
正確に要件を満たしてい
ることを確認
アジャイルでの開発(ADM)
プロダクト・バックログ
1
7
1
2
3
4
5
6
デイリー・スタンドアップ3
レトロスペクティブ5
コミットメント
スプリントプランニ
ング
2
リリース可能な成果物
4 スプリント・レビュー30⽇間
スプリント
プロジェクトの進⾏
要件定義
設定
ソリューション
の確認
設定
設定の
確認
×N
回
×N
回
統合テスト
（UAT）
⾒直できる期間
Salesforce.comにおけるハイブリッド開発⼿法
⾼コスト、ハイリスクな進め⽅ 請負SI契約が主流の⽇本では、採⽤が難しい※
※T&M契約のUSでは採⽤されている

13. 分析（要件定義）
ソリューション設計
構築
検証
移⾏
運⽤設計
Go Live!
1W 2W 3W 4W 5W 6W0W
Sandbox（Full/Config）の移⾏プラン
- 検証⽤
- データ移⾏
- トレーニング
- 運⽤後の保守環境ステージング計画
＜デザインレビュー＞
・コーディングレビュー（VF/Apex）
- ガバナ制約
- パフォーマンス
・ソリューション・レビュー
- データモデル
- データ・シェアリング
＜デザイン⽀援＞
・インテグレーション・パターン
リアル・⾮同期・バッチ etc
分析（要件定義）
ソリューション設計
構築
標準機能は
Agile開発
開発機能は
Waterfall開発
タイム・フレーム（サンプル）

14. お客様
開発チーム
AsIs業務説明
AsIs業務
ヒアリング
KPI
AsIs
帳票
AsIs
業務概要
ToBe業務策定
カスタマイズ
（画⾯）
データ
投⼊
カスタマイズ
（レポート／ダッ
シュボード）
ToBe業務
提案デモ
（プロトタイプ）
お客様
レビュー
Salesforce
テスト
データ
Salesforce
プロトタイプ・
シナリオ
Salesforce
プロトタイプ・
シナリオ
お客様との
ミーティング
内部作業
誰が、どの画⾯
で、何をするか
画⾯、セキュリティ
（Role/Profile）関連など
プロジェクト進⾏（サンプル）

15. 標準機能を最⼤限
活⽤する
パイロットを実施し
要件をブラッシュアップ
お客様と⼀緒に作る
ü 全世界のアクティブユーザの声を年3回のバージョンアップに反映し続けてきたSalesforce
は、まさにお客様のベストプラクティスを集めたツールセットです。これらを最適に組み合
わせる事により、“ゼロ”から設計・開発する場合に⽐べて、専⽤のアプリケーションを圧倒
的に早く簡単に構築することが出来ます。
ü Salesforceの標準機能を⼯夫する事により必要ない追加開発を減らすことが出来ます。導⼊
のスピードとお客様⾃⾝がカスタマイズできる事により利⽤開始後の保守コストを下げ、⻑
期的にSalesforceのバージョンアップによる拡張性を最⼤活⽤できるメリットがあります。
ü 曖昧な要件を実際に利⽤して実現イメージを掴み、それを要件定義にフィードバックできるパ
イロットの⼿法は、フロントシステムの開発⼿法として⾮常に有効であり、改善周期を繰り返
しつかえるシステムを実現します。
ü SaaS型のアプリケーション開発は、旧来のシステム導⼊⽅式で必要なHW/SWのサイジングや
調達、初期設定などの作業が必要なくパイロット導⼊できます。
ü お客様がSalesforceの最⼤のメリットを享受できるのは、システム開発が終了し実際に運⽤
開始した後です。Salesforceのカスタマイズの柔軟性は、お客様⾃⾝でエンドユーザの声を
システムに反映し、常に改善を続けられる点にあります。
ü プロフェッショナルサービスは、Salesforceのメリットを最⼤限活かしていただくために、
お客様にSalesforceのノウハウを吸収していただくことが必要と考えています。開発フェー
ズでお客様に専属のSalesforce担当者をアサインしていただき、⼀緒にSalesforceの設定を
⾏うことをお願いしています。
Salesforce導⼊成功のポイント

16. 参考：鉄の三角形
• スコープ/費⽤/納期は同時に3つ固定することは
できない
• 固定できるのは2つまで。アジャイル開発では
通常費⽤と納期を固定する
• スコープと納期を固定し、費⽤を可変にするこ
とは⼈を増やすということを意味するが、チー
ムはリニアにスケールしない
※引⽤元：スクラムの落とし⽳ #RSGT2017
https://slide.meguro.ryuzee.com/slides/83#

17. Sandbox
概要と種類
シナリオ別のパターン

18. 簡単に⾔うと、「業務で利⽤する環境(設定・コード・データ)に影響を与えないコピー環境。」
“コンピュータセキュリティ技術において、 サンドボックス（sandbox）は、外部から受け取ったプログラムを保護され
た領域で動作させることによってシステムが不正に操作されるのを防ぐセキュリティ機構のことをいう [1]。
実⾏されるプログラムは保護された領域に⼊り、ほかのプログラムやデータなどを操作できない状態にされて動作するた
め、プログラムが暴⾛したりウイルスを動作させようとしてもシステムに影響が及ばないようになっている。
ウェブページに配置されたJavaアプレットやFlash、JavaScriptなどのプログラムは⾃動的に実⾏される。そのため、気
づかないうちにコンピュータ上にあるファイルを盗み⾒られたり書き換えられたり、あるいはコンピュータウイルスに感
染させられたりするおそれがある。そこで安⼼してウェブサーフィンを楽しめるように提供されたのが、そういった攻撃
のできない安全な「砂場」(サンドボックス)である。”
(出典 : WikiPedia サンドボックス （セキュリティ）)
Sandbox って何?
Wikipediaに聞いてみた

19. 本番環境に影響を与えず、本番環境の設定やレコードを利⽤して
• 新しい機能をいち早く試す
• 新⼊社員のトレーニングに利⽤する
• 新しい設定や開発コードをテストしリリースする
Sandbox は何のために使うの?
利⽤シーン

20. Sandboxは何のために使うの?
主要な利⽤シーン
​主要な⽤途 ​理由
新規プロジェクトの迅速な開
発と実装を実現する柔軟性
アプリケーションのカス
タマイズと開発
テスト・ステージング・
本番環境サポート
トレーニング と定着化
ビジネス要件の実現
利⽤者の操作性の最適化と信
頼性の保証
ビジネス要件の迅速な実装
を実現するためのリソース
開発やテストと切り離した利
⽤者の早期習熟を⽀援
​期待する効果
ê 価値創造の時間短縮
ê リスク低減
é ⽣産性向上
é ビジネス⾰新
é 迅速な実装
リスク回避
売上損失などビジネスへの影響
を予防するための品質管理

21. Sandbox の種類
developer developer
pro
partial
copy
full
copy
更新間隔 1 ⽇ 1 ⽇ 5 ⽇ 29 ⽇
データのコピー なし なし あり あり
サイズ 200 MB 1 GB 5 GB 本番組織と同じ
テンプレート/サンプリング なし/なし なし/なし あり/あり あり/なし
Developer Sandbox のバンドル N/A 5 10 15
25 1
※種類別 Sandbox ライセンスおよびストレージ
https://help.salesforce.com/articleView?id=data_sandbox_environments.htm&type=5

22. Sandbox の選択
開発
QA
インテグレーションテスト
バッチデータテスト
トレーニング
UAT
パフォーマンスおよび読み込
みテスト
developer developer
pro
partial
copy
full
copy

23. ひとつの Sandbox – ⼩規模プロジェクトでのシナリオ
• 新規のカスタムオブジェクト、タブ、およびアプリケー
ション
• 他のシステムとの統合
• Visualforce、ワークフロー、または新しい⼊⼒規則を含
むアプリケーション
• 新規組織/新規顧客
• ⼩規模の取引先
• 新しい管理者/開発者
• 本番環境が未稼働
• 本番データへ⼲渉しない
Challenge
誰のため
Why
何を
• 本番環境で⾏われている変更を追跡できないことが
ある
• 現場での開発によるCOEの脱線

24. 複数の Sandbox – 開発の柔軟性を⾼める
• 新しいアプリ/機能の開発
• AppExchange Appのインストール
• テスト/ QA
• 成⻑が早い顧客/単⼀組織
• 上級デベロッパー
• AppExchange /パートナープロジェクト
• 開発者環境を隔離する
• 本番環境ではカスタマイズは⾏わない
• 競合が発⽣
• テスト環境の変更が上書きされるリスク
Challenge
誰のため
Why
何を

25. 複数の Sandbox – デプロイ前に変更をマージする
• 統合サンドボックスでのテスト
• UAT環境への変更の移⾏
• ユーザー承認テスト（UAT）
• 変更をステージング環境に移⾏
• リリースをスケジュールする
• エンタープライズ顧客
• 単⼀/複数組織
• 組織をチームとして同期させる
• 不完全な追跡と変更の記録
• 展開時に検出された競合とエラー
• 開発者ごとに開発者サンドボックス
を1つ作成する
Challenge
誰のため
Why
何を

26. ⼤規模 Sandbox アーキテクチャの構築例
Dev
Developer
QA
Developer Pro
Production
Full Copy
Developer Pro
Partial Copy
Legend
Developer
Dev
Developer
Dev
Developer
Dev
Developer
…
… Integrated
Dev
Developer Pro
Integrated
QA
Partial Copy
Staging
Full Copy
Production
Production
Support
Full Copy
Training
Partial Copy
UAT
Full Copy
Performance
Testing
Full Copy

27. Sandbox 留意点
Sandbox の更新
• 本番組織のデータおよびメタデータコンポーネントを使⽤して Sandbox を定期的に更新します。
Sandbox を更新しておけば、別の Sandbox によって本番組織にリリースされた変更や、本番組織に⼿動
で⾏われた変更をもらすことがありません。（Sandbox を更新可能な頻度は、Sandbox の種別によって
異なります。）
更新プロセス
• Sandbox を更新すると、環境が再構築され、古いコンテンツが消去されます。新しい Sandbox のコンテ
ンツが、本番組織のコピーと置換されます。注意しないと、Sandbox で⾏った開発がすべて上書きされ
てしまうことがあります。そのため、各開発者に個々の Sandbox を⽤意して、各⼈がバックアップする
ことをお勧めします。チームの全員と Sandbox の更新プロセスを確⽴しておきます。
データの使⽤
• Sandbox にはさまざまな⽅法でテストデータを提供できます。Sandbox テンプレートを使⽤して実際
のデータを提供し、テスト環境を本番インスタンスに近づける。Sandbox テンプレートは、Partial
Copy または Full Sandbox でのみ使⽤できます。
• 外部データを Sandbox にインポートして、テストを簡単に繰り返せるようにする (データセットが静的
で、変更されていないことを確信できるため)。

28. Salesforce DX と Sandbox

29. 環境は
容易に作成でき、
破棄できる
メタデータ
及びコードは
モジュラー化
開発環境は
オープン標準で
拡張可能なもの
を利⽤する
モダンなソフトウェア開発の要件
Salesforceがより⽣産性の⾼いソフトウェア⼯場になるためには？
全ては
ソースコード
から駆動する
開発は
チームメンバー
と共同で⾏う
プロセス及び
ツールは
継続的デリバ
リーをサポート
柔軟な
パッケージング
はアジャイルな
配布を可能にす
る

30. Salesforce DXを発表
ソース駆動開発
• コード、メタデータ、設定情報などをソースコードで管理
素早い開発 & デプロイ
• Scratch Orgsを開発およびテストで使⽤
チームコラボレーション
• 開発⽣産性を上げて、製品を素早く市場へ投⼊
継続的デリバリー及び継続的インテグレーション
• よりアプリケーションのクオリティを⾼める
オープンで標準的
• 好きなツールを使い、Force.com と Heroku をおなじプロセスで開発
チームで開発し、継続的にリリースする

31. Salesforce の開発を変える
開発者、管理者、ISV に新しい⼒を与える
*TBD
新しい
Salesforce CLI
ソース駆動
開発
揮発的な
スクラッチ組織
IDEやエディタと統合した
⾔語サービス
新しい概念の
パッケージング
Pipelinesによる
継続的デリバリー*
継続的
インテグレーション
Partial/Full
Sandbox

32. Salesforceの開発を変える
今までのSalesforce開発とこれからのSalesforce開発
要素 今まで これから
ソースコード ランタイム環境 (組織) バージョン管理システム
開発環境 少量 / ⻑期間⽣存 多数 / 揮発的
開発モデル 個⼈ベース チームベース
パッケージング ビルド / 差分のリリース バージョン
デリバリー ⼿動のリリース管理 継続的デリバリー
ツール 独⾃ CLIベース、統合可

33. Developer Experience (DX) を改善
新しい開発サイクル
Plan
Code
BuildTest
Release
CLI でサードパーティ
ツールと統合
スクラッチ組織で
ソース駆動に開発
継続的デリバリー/
ビルドの⾃動化
継続的インテグレーション
/テストの⾃動化
Sandboxesで
パフォーマンステスト
やUAT
パッケージング
し、本番へ提供
バージョン管理
システムを基軸に
IDEsやテキストエディタと
統合した⾔語サービス

34. 開発
Develop + Unit Tests
品質保証
Code Merge + Functional
テスト
UAT + Load + Staging
リリース
Training + Deploy
本番
Dev
SBX
ALM 応⽤例 - 単⼀の Sandbox
宣⾔型開発：コードは、
変更セット、移⾏、メ
タデータAPIを介して
リリースされます。
変更セットによるリリース

35. 開発
Develop + Unit Tests
品質保証
Code Merge + Functional
テスト
UAT + Load + Staging
リリース
Training + Deploy
Dev
SBX
本番
Dev
SBX
ALM 応⽤例 - フル Sandbox
Full
SBX
宣⾔型開発：コードは、
変更セット、移⾏、メ
タデータAPIを介して
リリースされます。
変更セットによるリリース

36. 開発
Develop + Unit Tests
品質保証
Code Merge + Functional
テスト
UAT + Load + Staging
リリース
Training + Deploy
Dev
SBX
本番
Dev
SBX
Dev
SBX
Partial
SBX
Dev
Pro
SBX
ALM 応⽤例 - 隔離した環境
Full
SBX
宣⾔型開発：コードは、
変更セット、移⾏、メ
タデータAPIを介して
リリースされます。
変更セットによるリリース

37. 開発
Develop + Unit Tests
品質保証
Code Merge + Functional
テスト
UAT + Load + Staging
リリース
Training + Deploy
Dev
SBX
本番Full
SBX
Dev
SBX
Dev
SBX
Partial
SBX
Dev
Pro
SBX
Dev
Pro
SBX
Scratch
Org
Scratch
Org
Scratch
Org
ALM 応⽤例 - Salesforce DX と ALM
バージョン管理システム (VCS)
ソース駆動開発：ソース
プルおよびプッシュ、お
よびプログラムによるテ
ストのために、CLIを使⽤
します。変更は VCS で追
跡します。
新しいツールSalesforce
DXは、最新の開発と
VCS をサポートする⼀連
のツールとプロセスを提
供します。
CLI駆動の変更/リリース
宣⾔型開発：コードは、
変更セット、移⾏、メ
タデータAPIを介して
リリースされます。
変更セットによるリリース

38. スクラッチ組織と Sandbox
ユースケース スクラッチ組織 Developer Developer Pro Partial Copy Full
開発 ● ● ●
QA ● ● ● ●
インテグレーションテスト ● ●
バッチデータテスト ● ●
トレーニング ● ●
UAT ● ●
パフォーマンスおよび読み込みテ
スト
●
ステージング ●
​スクラッチ組織は Sandbox の代替ではない
スクラッチ組織のアクティブ上限/⽇
• Enterprise: 40
• Unlimited: 100

39. おわりに

40. まとめ
1. アプリケーションライフサイクル管理とは
• 設計から最終的なリリースまでアプリケーションの開発を管理、変更管理プロセスを確⽴します。
• プロジェクトに応じたより良いプロセスを確⽴しましょう。
2. Sandbox は⽬的/利⽤⽤途にあった選択をしましょう。
3. より⽣産性を⾼めるため、Salesforce DX を含めたアーキテクチャパターンを活⽤していき
ましょう。（例：⼀部の開発者組織をスクラッチ組織に置き換え ）

41. 次のステップと関連リソース
アプリケーションライフサイクル管理
- チームアプリケーション開発およびライフサイクル管理のベストプラクティスを学習します。
• https://trailhead.salesforce.com/ja/modules/alm_deployment
変更管理
- 変更をアプリケーションのように開発して安全にリリースします。
• https://trailhead.salesforce.com/ja/modules/app_deployment
Salesforce DX 開発モデル
- Salesforce DX ツールを使⽤して、モジュールベースの開発を促進します。
• https://trailhead.salesforce.com/ja/modules/sfdx_dev_model
クイックスタートからプロジェクトまで豊富なラインナップ

42. 株式会社テラスカイ
Salesforce MVP
株式会社フレクト
テクニカルスペシャリスト
讃岐 ⾏ ⽒ 中⼭ 純⼦ ⽒
次回予告
株式会社セールスフォース・
ドットコム
テクニカルエバンジェリスト
川畑 隆博