組織への変更の計画

「アプリケーションライフサイクルと開発モデル」モジュールを修了した方は (修了していない場合は、このモジュールを始める前に受講することをお勧めします)、Zephyrus Relocation Services の Calvin Green を覚えているでしょう。このモジュールでは、Zephyrus のチームが宣言型変更セット開発を使用して、Salesforce のカスタマイズの 1 つを配信します。

Zephyrus では海外に駐在するクライアントに語学研修サービスを提供したいと考えています。同社の教育チームに語学のスペシャリストが加わり、幅広いコースを考案しています。クライアントの中には、新しい言語を学び始める人もいれば、復習コースで十分という人もいます。また、仕事で必要になるであろう専門用語を学びたいという人もいます。クライアントに語学コースを勧めるときは、さまざまな要素を考慮する必要があります。

Calvin とそのチームは、変更セット開発を使用して、組織に語学コースの情報を追加することにします。

Calvin はリリース計画を書き出して、関係者が業務を把握でき、この先混乱が生じないようにします。また、業務を書き出すことで、気付かなかった問題点が明らかになることもあります。割り当て、テスト計画、決定、マイルストンなどは、漠然と考えるよりも、具体的に書き出した方がまとまりやすくなります。そして、Calvin はこれが一案にすぎないことを認識しています。つまり、リリースの過程で新しい情報が明らかになれば、いつでも計画を修正していくつもりです。

変更セット開発モデルを使用する場合は、各変更、特に手動で移行する必要のある変更を追跡することが重要です。変更を手動で移行するときは、ある環境から変更を取得して、別の環境にまったく同じものを作成し直します。変更済みのコンポーネントがまだメタデータ API でサポートされていない場合は、変更を手動で移行する必要があります。

Calvin が、メタデータ API でどのコンポーネントがサポートされているのかを知るにはどうすればよいでしょうか? メタデータカバー率レポートを使用します。このレポートには、メタデータ API やその他のメタデータチャネルでどのメタデータ型がサポートされているかが表示されます。この動的に生成されるレポートは、メタデータカバー率の最適な情報源です。メタデータカバー率レポートにアクセスするには、https://developer.salesforce.com/docs/metadata-coverage に移動します。

Calvin は営業チームから依頼された変更と機能強化をすべて追跡しています。そのために、開発者が行った変更がすべてログに記録されるようにカスタマイズされたツールを使用しています。Calvin は安全を期してこのツールに、リリースの各変更の次の重要な情報を記録する項目と、本番組織で直接実行された変更を記録する項目を設定しています。

• この変更は誰に割り当てられたか?
• この変更を手動で移行する必要があるか?
• この変更の影響を受けるコンポーネントはどれか?
• 現在この変更はどの組織にあるか?
• 各環境でいつ変更が行われたか?

本番組織で実行された変更は、開発組織のリリースとは関係ないのに、なぜ Calvin は追跡するのでしょうか? この追跡が、リリースされたカスタマイズによって、本番組織の動作が上書きされたり、予期せず変更されたりしないようにする唯一の術であるためです。

Calvin または Ella が Salesforce ユーザインターフェースを使用して行ったほぼすべての変更が、設定変更履歴に記録されます。Calvin はこの変更履歴をチームの変更追跡ツール内のレポートと照合して、変更が漏れていないことを確認します。

設定変更履歴の使用についての詳細は、Salesforce ヘルプの「設定の変更の監視」を参照してください。