NPSP や Salesforce のリリースに向けた準備をする

学習の目的

この単元を完了すると、次のことができるようになります。

NPSP と Salesforce の両方のリリースサイクルの頻度を述べる。
NPSP と Salesforce のリリース後に実行する必要があるアクションを特定する。

更新の時期

更新の対応に追われている NPSP システム管理者

Salesforce の継続的なイノベーションサイクルは Salesforce 最大の特長の 1 つですが、こうした更新に対処するシステム管理者に負担になることがあります。特に、団体で他の役割もこなしながら、Salesforce のサポートも手がける兼任のシステム管理者にとっては大変です。

そのため、最新リリースに合わせて効率的かつ実行可能な実務を確立することが、システム管理者にできる極めて重要な対策の 1 つになります。リリースへの適切なアプローチを定めておけば、システム管理者自身やユーザーがすべての変更を把握し、Salesforce に対する投資を最大限活用できるようになります。ですから、この確立を優先事項にします!

この単元では、NPSP と Salesforce のリリースの頻度を確認し、イノベーションへの対応方法に関するヒントをご紹介します。

NPSP による継続的なイノベーション

NPSP は、Salesforce.org の開発者の取り組みや、日常的に使用するユーザーやシステム管理者の貢献によって常に進化し続けるアプリケーションです。

リリースの内容とその時期を把握していることが次の点で役立ちます。

厄介なバグがいつ修正されるかを知る。
新機能と NPSP への投資を最大限に活用する。
新機能が既存のカスタマイズにどのように影響するかを熟考する。
更新が本番に導入される前に Sandbox でテストする。

NPSP の新機能は Spring、Summer、Winter の年に 3 回リリースされるため、システム管理者が新しいツールについて確認し、実装し、テストする時間を確保しておくことができます。変更内容はまず Sandbox に転送され、2 週間後に本番に転送されます。各年のリリーススケジュールについての詳細は、「Keep Up With Salesforce.org Releases (Salesforce.org リリースの最新情報の確認)」を参照してください。

NPSP のバグ修正も 2 週間ごとに、Sandbox での 1 週間のプレビューを経て本番組織に自動的に転送されます。

NPSP の新機能の大半は、システム管理者が組織で使用可能にするかどうかを管理し、エンドユーザーに表示する場合には事前に有効にしておく必要があります。システム管理者が機能を Sandbox でテストしたうえで、ユーザーに導入する適切な時期を判断します。Sandbox については後続の 2 つの単元で説明します。

特定のリリースのトリガーとクラスは常に自動的に追加されますが、開発者でない限りさほど重要ではありません。

NPSP リリースの構成要素

Sandbox と本番の更新の具体的な時期やその更新で対処されている問題はすべて、Trailblazer Community の「Nonprofit Release Readiness」グループで発表されます (ページ末尾の「リソース」セクションに、このグループへのリンクが掲載されています)。このグループでは、非営利団体に関するリリースのお知らせ、更新、リソースなどをすべて確認できます。

NPSP リリースが投稿されるときには、通常、次の 3 つの要素で構成されています。

重要な変更: システム管理者による緊急かつ直接的なフォローアップを必要とします。
変更: リリースに含まれる NPSP の更新や機能がリストされます。
クローズ済みの問題: バグや特定された操作上の他の問題のうち、NPSP リリースで修正されているものです。

追加のインストール手順セクションには次の内容が含まれています。

転送スケジュール: リリースが Sandbox と本番組織に転送される時期
最新リリースのインストール URL: 必要に応じて更新を手動で適用できる直接リンク (詳細は「リソース」を参照)。
Trialforce テンプレート ID: 環境ハブを使用しているパートナー向け(コンサルティングパートナー以外は関係ありません)

特に厄介なバグによる直接的な問題に悩まされている場合 (極めて稀です!) を除き、ごく頻繁に行われるバグ修正のお知らせに対して、システム管理者が実行するアクションは通常ほとんどありません。他方、年に 3 回のリリースには新機能が含まれ、システム管理者や団体がまとまった時間を取って変更内容を確認し、ユーザーへの影響を検討することが求められます。NPSP に重要な新機能が導入される場合には、Salesforce.org から十分な時間的余裕をもって通知されます。

では、No More Homelessness (NMH) という架空の非営利団体の Salesforce システム管理者である Gorav Patel が、NPSP の大規模な機能リリースに向けて準備を整えるところを見ていきましょう。

NPSP をフルに活用する

Gorav は Trailblazer Community の「Nonprofit Release Readiness」グループをフォローしています。皆さんもぜひサインアップしてください。詳細は、「リソース」のリンクを参照してください。

最新リリースのお知らせが届くたびに、Gorav はまず組織に影響がありそうなものがないか確認します。新機能のリリースでは、次のチェックリストに従って確認します。これは、あらゆるシステム管理者にとってのベストプラクティスです。

リリースノートを詳しく確認する。
Sandbox を使用して、新しい機能を本番で有効にする前にテストする。リリースに含まれる新しい項目やオブジェクトはすべて、デフォルトでシステム管理者を含む誰にも表示されないため、Sandbox でも有効にする必要があります。
主なユーザーと協力して、団体で新機能をどのように活用できるか判断する。
新しい機能に、組織に既存のカスタマイズと競合するものがないか検討する。
新機能の中にセキュリティ設定の更新を要するものがないか調査する。
新機能を実装することにした場合は、スタッフが新機能について学習できるようにコミュニケーションとトレーニングの計画を立てる。

Gorav がこのチェックリストに従えば、新機能のリリースからトレーニングまで効率的に対処できます。ただし、Gorav が対応する必要のあるメジャーリリースは NPSP だけではありません。

Salesforce Platform の定期リリース

NPSP と同様、Salesforce Platform も常に進化しています。Salesforce は、年に 3 回 (Spring、Summer、Winter) のリリースで、優れた新機能を配布しています。Salesforce Platform のリリースは、NPSP や非営利団体向けの Salesforce の定期リリースの約 1 か月前に実施されます。

どれが NPSP で、どれが Salesforce なのかわかりづらいかもしれません。この 2 つを明確に区別できないこともありますが、人々が Salesforce あるいは Salesforce Platform と言う場合は通常、Sales Cloud Enterprise Edition を意味します。NPSP は Sales Cloud Enterprise Edition ライセンスを基盤としていることから、Salesforce のすべての新機能をこの両方で利用できます。

Salesforce Platform のリリース自体は自動的に実施されますが、大半のシステム管理者はアップグレードの前後に何らかの作業を行う必要があります。一部の機能は自動的に有効になるため (リリースノートに明記)、どのようなことが行われるのか把握して、ユーザーを驚かせないようにします。こうした驚きは決して嬉しいものではありません。

定期リリースについて学習し、リリース計画を立てる最適な手段は、「Salesforce リリースへの準備」トレイルを受講することです。各定期リリースには、専用の Trailhead モジュールもあり、そこでは新しいリリースに含まれる機能の詳細を学習できます。

「無料」の Salesforce.org リリース Web セミナーにも参加できます。このセミナーでは、Salesforce.org のガイドが重要な新機能を紹介し、参加者が質問する機会も設けられます。サインアップの方法については、Trailblazer Community のお知らせや情報を参照してください。

リリースの重要性

ただでさえ時間がない中、NPSP や Salesforce のリリースまで手が回らないと思うかもしれませんが、リリースがいつ行われ、どのような作業を実行すべきかを理解しておくことは、テクノロジーを最大限活用するために不可欠で、ひいては活動目的の達成促進につながります。

リリースに向けて準備をするときは、その重要な作業を Sandbox 組織で実行します。後続の 2 つの単元で、Sandbox という便利なツールと、その使い方のベストプラクティスについて説明します。