テストおよび開発 SaaS オファーを計画する

  • [アーティクル]

運用オファーとは別の環境で開発する場合は、個別のテストおよび開発 (DEV) オファーと、個別の運用 (PROD) オファーを作成します。 この記事では、DEV オファーで開発とテストを行うことの利点、さらに DEV オファーと運用オファーとの構成の相違点について説明します。

開発オファーの利点

開発チームが PROD オファーの開発とテスト用に使用する DEV オファーを別途作成する理由をいくつか紹介します。

  • お客様への誤請求を回避する
  • 価格モデルを評価する
  • 実際のお客様を対象としないプランを追加しない

お客様への誤請求を回避する

PROD オファーの代わりに DEV オファーを使用して、それらを開発環境や本番環境として扱うことで、顧客への誤請求を回避できます。

Marketplace API を呼び出すための 2 つの異なる Microsoft Entra アプリを登録することをお勧めします。 開発者は、DEV オファーの設定で 1 つの Microsoft Entra アプリを使用し、運用チームは PROD アプリの登録を使用します。 これにより、開発チームが不注意によるミス (API を呼び出して 1 か月あたり $ 100,000 ドル支払っている顧客のサブスクリプションをキャンセルするなど) を犯さないようにすることができます。 また、消費していない従量制の使用量を顧客に請求することも避けられます。

価格モデルを評価する

DEV オファーで価格モデルをテストすると、開発者がさまざまな価格モデルを使用して実験する際のリスクを軽減することができます。

パブリッシャーは DEV オファーに必要なプランを作成して、オファーに最適な価格モデルを決定できます。 開発者がさまざまな価格の組み合わせをテストする場合、DEV オファーで複数のプランを作成することをお勧めします。 たとえば、さまざまなカスタム従量制ディメンションのセットを使用してプランを作成できます。 定額料金とカスタム従量制ディメンションを組み合わせた、異なるプランを作成する場合があります。

複数の価格オプションをテストするには、一意の価格モデルごとにプランを作成する必要があります。 詳細については、「プラン」を参照してください。

実際のお客様を対象としないプランを追加しない

開発とテスト用の DEV オファーを使用することで、PROD オファーで不要な混乱を減らすことができます。 たとえば、作成したプランを (サポート チケットを提出せずに) 削除して、さまざまな価格モデルや技術構成をテストすることはできません。 そのため、DEV オファーでテスト用のプランを作成することで、PROD オファーでの混乱を減らすことができます。

製品チームとマーケティング チームは、すべてのプランが実際の顧客をターゲットにすることを期待しているため、PROD オファーで混乱が発生すると不満を感じます。 特に、全員が異なるサンドボックスで作業している大規模なチームの場合、2 つのオファーを作成すると、DEV と PROD に 2 つの異なる環境が提供されます。 場合によっては、さまざまなユーザーがさまざまなテスト シナリオを実行する大規模チームをサポートできるよう、複数の DEV オファーを作成することをお勧めします。 さまざまなチーム メンバーが PROD オファーとは別に DEV オファーで作業できるようにすることで、運用計画を可能な限り本番環境に近い状態に近づけることができます。

DEV オファーをテストすると、オファーごとに 30 個のカスタム従量制ディメンションの制限を回避できます。 開発者は、PROD オファーのカスタム従量制ディメンションの制限に影響を与えることなく、DEV オファーで異なる測定の組み合わせを試すことができます。

DEV オファーと運用オファーの構成の相違点

テスト、開発 (DEV)、運用 (PROD) の各オファーでは、ほとんどの設定を同じに構成します。 たとえば、スクリーンショット、ロゴなどの公式のマーケティング言語と資産は同じである必要があります。 構成が同じ場合は、DEV オファーのプランから PROD オファーのプランに、フィールドをコピーして貼り付けることができます。

次のセクションでは、DEV および PROD オファー間の構成の違いについて説明します。

[オファーのセットアップ] ページ

両方のオファーの [エイリアス] ボックスで同じエイリアスを使用するが、DEV オファーのエイリアスには "_test" を付記することをお勧めします。 たとえば、PROD オファーのエイリアスが "contososolution" の場合、DEV オファーのエイリアスは "contososolution_test" である必要があります。 このようにすることで、どの DEV オファーが PROD オファーからのものであるかを簡単に特定できます。

[Customer leads] (潜在顧客) セクションでは、DEV オファーに対して、Azure テーブルまたはテスト CRM 環境を使用します。 PROD プランに対しては、パートナー センターの紹介ワークスペース、または CRM システムを使用します。

[プロパティ] ページ

このページは、DEV と PROD の両方のオファーで同じ構成にします。

[オファー登録情報] ページ

このページは、DEV と PROD の両方のオファーで同じ構成にします。

プレビュー対象ユーザー

DEV オファーには、開発者とテスト担当者の Microsoft Entra ユーザー プリンシパル名または Microsoft アカウント (MSA) のメール アドレス (自分を含む) を含めます。 Microsoft Entra ID 上のユーザーのユーザー プリンシパル名は、そのユーザーの電子メールとは異なる場合があります。 たとえば、jane.doe@contoso.com は機能しませんが、janedoe@contoso.com は機能します。 開発およびテスト フェーズで、[プレビュー] リンクを共有すると、指定したユーザーが DEV オファーにアクセスできるようになります。

PROD オファーには、オファーをライブで公開する [ライブに移動] ボタンを選択する前に、オファーを検証するユーザーの Microsoft Entra ユーザー プリンシパル名または Microsoft アカウントの電子メールを含めます。

[技術的な構成] ページ

次の表では、DEV オファーと PROD オファーの設定の違いについて説明します。

表 1: 技術的な構成の違い

設定 DEV オファー PROD オファー
ランディング ページ URL 開発/テスト エンドポイントを入力します。 運用エンドポイントを入力します。
[Connection webhook]\(接続 Webhook\) 開発/テスト エンドポイントを入力します。 運用エンドポイントを入力します。
Microsoft Entra テナント ID テスト アプリ登録テナント ID (Microsoft Entra ディレクトリ ID) を入力します。 運用アプリの登録テナント ID を入力します。
Microsoft Entra アプリケーション ID テスト アプリの登録アプリケーション ID (クライアント ID) を入力します。 運用アプリの登録アプリケーション ID を入力します。

プランの可視性

テスト プランは非公開のプランとして構成することをお勧めします。これにより、対象の開発者とテスト担当者にのみ表示されることになります。 これにより、誤ってオファーをライブで公開した場合に、テスト プランが顧客に公開されるのを防ぐための追加の保護レベルが提供されます。

DEV オファーではなく運用オファーでプランをテストすることを選択した場合、これは特に重要であり、顧客はプランを購入できなくなります。 別に非公開のテスト プランを作成すること、その非公開のテスト プランをライブで公開しないことをお勧めします。 非公開のテスト プランを使用して、プレビュー版のテストを実行します。 テストが完了したら、ライブで公開するための運用プランを作成します。 その後、テスト プランの配布を停止することができます。

[プランの概要] ページ

プランを作成するときは、DEV および PROD オファーの両方で同じ プラン ID と プラン名 を使用することをお勧めします。ただし、DEV オファーのプラン ID には、_test を付記してください。 たとえば、PROD オファーのプラン ID が "enterprise" の場合、DEV オファーのプラン ID を "enterprise_test" にしてください。 このようにすることで、どの DEV オファーが PROD オファーからのものであるかを簡単に特定できます。 PROD オファーでは、オファーに最適と判断する価格モデルと価格を使用してプランを作成します。

プランのリスト登録

[プランの概要]>[プランの一覧] タブで、DEV および PROD プランの両方に、同じプランの説明を入力します。

[価格と可用性] ページ

このセクションでは、[プランの概要]>[価格と可用性] ページに記載するためのガイダンスを提供します。

市場

DEV および PROD オファーで、同じマーケットを選択します。

価格

DEV オファーを使用して、価格モデルを試します。 1 つまたは複数の最適な価格モデルを確認したら、必要な価格モデルと価格を使用して、PROD オファーのプランを作成します。

プランを購入すると、プランで定義されている料金が請求されます。 テスト コストを最小限に抑えるには、プランに無料または低価格のプランが開発プランに含まれている必要があります。 たとえば、$0.01 (1 セント) のようになります。 これは定額、従量制課金、ユーザーごと、の各料金に適用されます。 PROD オファーには、顧客に請求する価格を含めます。

重要

プレビューで行われた購入は、DEV および PROD オファーの両方で処理されます。 オファーの価格が 100 ドル/月である場合、会社には 100 ドルが請求されます。 このような場合は、サポート チケット を開くことができ、そうすれば、全額のペイアウトを発行します (また、ストア サービスの料金は受け取りません)。

ライブで公開する別の運用プランで、顧客に請求する価格を設定します。

価格モデル

DEV および PROD オファーのプランでは、同じプラン構造を使用してください。 たとえば、PROD オファーのプランが定額料金で、月単位の請求期間がある場合は、同じモデルを使用して DEV オファーでプランを構成します。

Marketplace カスタム メーター ディメンションなどの、価格モデルのテストにかかるコストを削減するには、PROD オファーよりも価格が低い DEV オファーで [価格と可用性] タブの [価格] セクションを構成することをお勧めします。 ここでは、DEV オファーのプランについて価格を設定する場合に従うことができる、いくつかのガイドラインを示します。

表 2: 価格ガイドライン

料金 解説
$0.00 - $0.01 合計トランザクション コストをゼロに設定して、財務に影響を与えないようにするか、1 セントに設定してコストを低くします。 この価格は、メータリング API の呼び出しや、ソリューションの開発中のオファーの購入プランのテストに使用します。
$0.01 この価格範囲を使用して、分析、レポート、および購入のプロセスをテストします。
$50.00 - $100.00 この価格範囲を使用して、ペイアウトをテストします。 ペイアウト スケジュールの詳細については、「支払いスケジュールとプロセス」を参照してください。

重要

テストでストア サービスの料金が請求されないようにするには、テスト購入から 7 日以内にサポート チケットを開きます。

[Microsoft と共同販売する] ページ

DEV オファーの [Microsoft と共同販売する] タブを構成しないでください。

CSP を通して再販する

DEV オファーの [CSP を通して再販する] タブで、[CSP プログラムでパートナーはいません] を選択します。

次のステップ