進行状況の追跡を始めよう
Trailhead のホーム
Trailhead のホーム

効果的なチームの編成

学習の目的

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

  • 効果的なプロジェクトチームを編成する。
  • アプリケーションのビジネス関係者を特定する。
  • アプリケーションのテクノロジ関係者を特定する。

従来の Salesforce 開発ライフサイクルでは、アプリケーション作成者は Sandbox を使用して作成と変更のテストを行います。信頼できる情報源は動く標的です。Salesforce DX に含まれるツールと機能を使用すれば、会社のアプリケーション開発ライフサイクルとメタデータの管理方法を変えることができます。最も画期的な変更の 1 つは、ロック解除済みパッケージの採用です。

ロック解除済みパッケージ

ロック解除済みパッケージを使用すれば、反復とスクリプト実行と追跡が可能な方法で、組織に変更を導入し管理することができます。ロック解除済みパッケージを使用する場合、パッケージはメタデータを整理するために使用するコンテナとなります。また、パッケージは環境間でメタデータを移行する手段にもなります。さらに、パッケージ化の採用は、Salesforce 組織の構造そのものの管理方法と考え方に影響します。

ロック解除済みパッケージを採用するには、チームが次のような長所があるモジュール形式のアプリケーション開発を採用する必要があります。 

  • 機能所有権の改善
  • 変更管理の効率の向上
  • 開発プロセスの効率の向上 (迅速なテスト実行、メンテナンスしやすいコードなど)
  • 新しい機能の配信コストの削減

ただし、モジュール形式の開発の採用には労力を要します。必要なステップではありますが、Salesforce コマンドラインインターフェース (CLI) などの新しいツールの使用方法の習得、またはメタデータを管理するために Git や Subversion などのバージョン管理システムの採用の他にも必要なことがあります。また、モジュール形式の開発は、組織のアプリケーション開発のさまざまなフェーズの整理および管理方法や、アプリケーション開発に関わるチームにも影響を及ぼします。 

最も大きな影響の 1 つは、組織を分離する必要があるということです。分離プロセスでは、組織のメタデータのパターンを探し、メタデータを意味のある単位に整理します。これらの単位は、モジュール形式の開発とロック解除済みパッケージの基盤となります。組織を分離し、モジュール形式の開発とロック解除済みパッケージを採用するための最初のステップは、組織とチームの準備を整えることです。

関係者の特定

Salesforce 組織は、会社全体に影響を及ぼします。アプリケーションを作成しているときには、アプリケーションを使用するチームからフィードバックを得ることが、最適なソリューションを提供するうえで重要なのはご存知でしょう。関係者またはプロジェクトの成果による影響を受ける人物に、フィードバックサイクルに参加してもらうための戦略は多数あります。たとえば、アジャイル開発の場合は、アプリケーションを作成し、それを関係者に見せ、フィードバックをもらい、作成したアプリケーションで反復します。

しかし、組織のメタデータのパターンやカスタマイズを確認するといったプロジェクトに取り組んでいる場合、技術者以外の同僚を参加させるにはどうしたらよいのでしょうか? さらに肝心なのは、なぜそうする必要があるのでしょうか? 組織を分離することの真意は、アプリケーション配信チームのみが関心を持つプロセスやツールを採用することではないのでしょうか? アプリケーション配信の社内担当者が参加しているのであれば、わざわざエンドユーザや技術者以外の経営陣を煩わせる必要があるのでしょうか?

アプリケーションへの変更は組織全体に波及します。ビジネスの動力であるアプリケーションの管理および配信方法の変更を検討し始めるときに、ビジネス全体でそれらのアプリケーションに依存するユーザの意見や視点を必ず含めるようにしてください。ただし、組織を分離するために巨大でまとまりのないチームを編成することは、最も効果的な始め方ではありません。では、適切な人を含め、適切な規模の適切なチームを編成するにはどうしたらよいのでしょうか?

効果的なチームの編成は、適切な関係者を特定することから始まります。したがって、組織の分離は、組織の多数の関係者を整理することから始まります。関係者にはいくつかの種類があります。技術的観点とビジネス的観点の両方から組織について知識がある人物を見つける必要があります。

次のような特徴を持つ人物を探します。 

  • ビジネスに関する質問に正確に回答できる。
  • 会社および社内方針について認識している。
  • 自分のチームがアプリケーションをどのように使用しているか把握している。
  • 回答できない質問をされたときに情報を探す方法を知っている。

社内の関係者を特定したら、彼らを効果的な作業グループにまとめます。1 つの戦略は、組織内のさまざまなビジネスユニットに基づいてチームを編成することです。もう 1 つの戦略は、組織内に作成したさまざまなアプリケーションに基づいてチームを編成することです。どちらの戦略を選んでも、関係者のグループが組織内の実際の機能と一致している必要があります。欠けているものや重複があればそれを記録します。

チームの編成

実在する A 社と B 社のチーム編成の例を見てみましょう。両社とも、Salesforce 組織を調査し、アプリケーション開発のベストプラクティスを取り入れたいと考えています。

A 社は、規模が小さいオンライン小売業者で、Sales Cloud、Commerce Cloud、Marketing Cloud を使用して、直接販売ビジネスを管理しています。従業員は社内で複数の役割を担っています。ビジネスは部門よりもプロセスごとに整理されているので、Salesforce でプロセスをサポートするために作成されたアプリケーションに基づいてチームを結成することにします。

B 社は、規模が大きいオンライン小売業者で、Sales Cloud、Service Cloud、Commerce Cloud、コミュニティ、Marketing Cloud を使用して、販売業者とのビジネスと直接販売ビジネスを管理しています。会社は部門ごとに整理され、これらの部門は各事業部門と異なる関係を持ちます。特定の部門のニーズに基づいて Salesforce 内の機能が構築されているので、部門ごとにチームを結成することにします。

両社ともチーム間でコミュニケーションを図る必要がありますが、2 つの異なるアプローチは、分離プロセスを開始するうえで、それぞれの会社が扱いやすり方法を示しています。

リソース