価値実証 (POV)

価値実証 (POV) とトライアル

ステータス: SA リーダーシップ、Sales、Fulfillment、Professional Services、Product によるレビューに向けた作業中のドラフトです。

目的: 現行の POV ページを、共通のライフサイクルと Simple および Extended の 2 つの実行モードを使用する、顧客評価の統一運用モデルに置き換えます。

エグゼクティブサマリー

価値実証（Proof of Value、POV）は、実施の適格性を確認した成果重視の技術評価であり、顧客と GitLab に、商業上の意思決定や導入判断の根拠を提供します。

トライアルは製品へのアクセスを提供する仕組みであり、POV はそのアクセスを中心に管理するビジネス面・技術面の取り組みです。正式な POV にはすべて、評価する理由、明確な参加者、定義されたスコープ、測定可能な成功基準、実行責任者、意思決定日、記録された結果が必要です。この基準は、コマーシャル顧客向けや複雑性の低い取り組みでは意図的に軽量にし、エンタープライズ顧客向け、戦略的、使用量の影響を受けやすい、複数チームにまたがる評価では、より綿密な計画と測定を行います。

1. POV とは？

価値実証は、期限を設けて実施の適格性を確認した評価であり、GitLab と顧客は次の事項に合意します。

• 対応する顧客の課題またはビジネス成果。
• 検証する技術的な能力とユースケース。
• 成功を判定する測定可能な基準。
• 必要な人員、環境、スケジュール、責任。
• 評価後の判断：技術的勝利、技術的敗北、または結論不明。

POV は次のものではありません。

• 汎用的なデモ。
• 成功基準がなく、何の確約も求めないサンドボックス。
• ディスカバリー、アーキテクチャ設計、導入、トレーニング、有料コンサルティングの代替。
• あらゆる無料トライアルや技術的な質問をひとまとめにする名称。

主な目的が機能や能力の検証である場合は、トライアルを使用します。評価の適格性を確認済みで、成果を重視し、技術上または商業上の意思決定に結び付く場合は、POV を使用します。トライアルは顧客が開始して自ら進められますが、POV では通常、明示的なスコープ設定と説明責任を負う GitLab の担当者が必要です。

2. 標準 POV モデル

GitLab は、2 つの実行モードを備えた 1 つのライフサイクルを使用します。

Simple モードでの実行

顧客が自ら進める評価、コマーシャル顧客向け、複雑性が低い、または軽度の支援を伴う評価に最適です。

必要な資料・体制は、簡潔なスコープ、事前チェックリスト、ユースケースのプレイブックまたはスモークテスト、明確な責任者、簡易な進捗管理、成果の確認です。適格性の確認や測定を省くことなく、迅速性と再現性を実現することを目指します。

Extended モードでの実行

エンタープライズ顧客向け、戦略的、複数チームにまたがる、リスクが高い、使用量の影響を受けやすい、または変革を志向する評価に最適です。

必要な資料・体制には、スコープ文書、成功基準表、参加者一覧、前提条件、リスク記録、スケジュール、コラボレーションプロジェクト、ユースケースのプレイブック、基準値と目標の指標、中間確認、最終報告、正式な記録システムの完全な維持管理が含まれます。

コマーシャル顧客だから必ず Simple、エンタープライズ顧客だから必ず Extended とは限りません。セグメントは最初の判断の目安であり、最終的なモードは、複雑性、リスク、ステークホルダーの数、デプロイモデル、使用量に伴う経済性によって決まります。

3. POV とトライアルの種類

3.1 顧客起点または顧客主導のトライアル

顧客は SA を介さず、利用資格のある GitLab トライアルを直接開始できます。

• Ultimate セルフサービストライアル — Web サイトまたは製品内のアップグレード案内から開始する、GitLab.com またはセルフマネージド向けのトライアルです。
• 見込み顧客向けの DAP（Duo Agent Platform）セルフサービストライアル — 100 ユーザーを上限とする 30 日間の無料 SaaS トライアル、またはユーザー数の上限がない無料セルフマネージドトライアル（GitLab 18.9+）です。いずれも DAP 評価クレジットが自動的に付与されるため、見込み顧客は Fulfillment へのクレジット申請を行いません。既存の有料顧客は、有効なサブスクリプションに対する 1 回限りのクレジット割り当てとなるため、代わりにセクション 6 の SA 支援付き DAP トライアルを使用します。
• Monthly Commitment のセルフサービス購入 — 2026 年 2 月 3 日以降、利用資格のある Premium/Ultimate の SaaS 顧客またはセルフマネージドのクラウドライセンス顧客は、営業担当者を介した注文なしで、Customer Portal から DAP Monthly Commitment クレジットを直接購入できます。セルフマネージドのオフライン環境、Dedicated、リセラー経由、複数年のサブスクリプションでは、引き続き営業担当者を介した購入が必要です。

アカウントチームは、すべての顧客主導トライアルを自動的に POV に切り替えるべきではありません。次のいずれかに該当する場合に、SA 支援付き POV に切り替えます。

• 顧客がビジネス成果と意思決定日を明確にしている。
• 商談が後期段階にある、または戦略的に重要である。
• 顧客がアーキテクチャ、デプロイ、セキュリティ、コンプライアンス、移行、インテグレーションのガイダンスを必要としている。
• 評価に従量制またはクレジットで管理される機能が含まれる。
• 複数のチーム、環境、意思決定者の調整が必要である。

顧客主導を継続するトライアルでは、製品のプレイブック、前提条件、スモークテスト、サポート経路を顧客に提供します。適格性を確認せずに SA の専用の時間を確約しないでください。

3.2 SA 支援付きトライアル

顧客が技術的なガイダンスを必要とし、本格的な変革プログラムまでは必要としない場合、SA 支援付きトライアルを標準モデルとします。SA と AE は、トライアル開始前に実行モードに合意します。

エンタープライズ顧客およびコマーシャル顧客 / Lite 向け SA 支援付きトライアル

顧客がエンタープライズ顧客または戦略的顧客であり、評価に複数のステークホルダー、複数の製品、Self-Managed または Dedicated のデプロイ、セキュリティ / コンプライアンス要件、複雑なインテグレーション、または重要な商業上の意思決定が含まれる場合は、原則として Extended を選択します。

GitLab では、これを Use Case Validation と位置付けています。これは、定義された成果に照らしてビジネス価値を実証するもので、多くの場合、3 Goals in 30 Days（「3-in-30」） フレームワークを使用します。ビジネス成果に結び付く 1 〜 3 つの測定可能な技術目標を、体系的な週次確認を行いながら 30 日間で実証します。

コマーシャル顧客向けで複雑性の低い商談において、限られた SA の関与で顧客が迅速に進められる場合は、原則として Simple を選択します。Lite の進め方は、適格性の確認を省いたエンタープライズ向け支援付きトライアルではありません。

キックオフ前の必須事項

Lite トライアルに重要なリスクが 2 つ以上ある場合、複数のチームが必要な場合、カスタムアーキテクチャが必要な場合、使用量の影響を受けやすい製品を含む場合、またはパイロットに発展する可能性が高い場合は、代わりに Extended を使用します。

3.3 パートナー主導のトライアル

パートナーは顧客と直接、技術評価を主導できます。その際、GitLab アカウントチームは製品の専門知識、エスカレーション支援、商業面の監督を提供します。トライアル開始前に、パートナー側責任者、顧客側責任者、記録上の GitLab AE/SA を明確にします。パートナーの担当が終わり GitLab の担当が始まる引き継ぎポイントと、その逆の引き継ぎポイントを定義します。また、パートナー独自の成功基準が GitLab の技術的勝利の定義にそのまま対応するとは限らないため、成功基準と商業上の次のステップを共同で確認します。

3.4 Professional Services トライアル

Professional Services（PS）トライアルは、自主的な評価ではなく、サービス主導の導入またはワークショップとして実施し、原則として Extended を使用します。作業範囲記述書または明確に定義されたサービス範囲、提供計画、顧客と合意した成功基準、正式な受け入れ手順、エンゲージメント終了後にアカウントチーム（AE/SA/CSM）へ戻す移行計画が必要です。

3.5 パイロット

パイロットでは、デモ環境ではなく、ユーザー、チーム、プロジェクトを限定した顧客の実環境の代表的な一部分で GitLab を検証し、原則として Extended を使用します。本格的な Extended POV と同じ規律あるプロジェクト運営（明確な役割、指標、ガバナンス、リスク管理）に加え、正式な報告と、パイロット対象者以外にも拡大するための明示的な展開推奨事項が必要です。

4. 標準的なトライアルのライフサイクル

4.1 フィードバックと Issue 管理の要件

フィードバックは、最終報告時だけに行う活動ではなく、ライフサイクルにおける明確な通過条件です。トライアルの中間時点と終了時にアンケートのフィードバックを収集し、週次のやり取りでもフィードバックを記録します。どのユースケースがうまく機能しているか、どのユースケースにバグ修正や機能強化が必要か、どの問題に Product Management、Engineering、Customer Support のフォローアップが必要かを尋ねます。

顧客からの新しいリクエストまたは重要な問題ごとに、次を実施します。

• 該当する顧客リクエストテンプレートに準拠した Issue を作成し、顧客の背景、ユースケース、期待する動作、実際の動作、ビジネス面または技術面の影響、エビデンス、優先度、顧客向けのコメントを含めます。
• POV レポートに Issue のリンクと現在のステータスを記録します。
• 評価文書またはコラボレーションプロジェクトに Issue と関連するフィードバックを記録します。
• 技術的な結果への影響が分かるように、Issue を関連するユースケースと成功基準に紐付けます。
• 未解決の Issue、責任者、次のアクションを最終報告と移行計画に引き継ぎます。

4.2 正式な記録システムの最低限のフィールド

POV レコードには次を含めてください。

• 関連付けられた商談、
• 該当する場合はサブスクリプション、
• POV の種類、
• 実行モード、
• 製品 / 取り組み、
• 開始日と終了日、
• ステータス、
• 結果、
• SA/AE の責任者、
• 顧客側の推進者、
• 成功基準、
• コラボレーションのリンク、
• トライアルまたはクレジット申請のリンク、
• および次のステップ。

従量制トライアルでは、使用量とトライアルの状況をまとめて確認できるように、サブスクリプション識別子とクレジット申請を関連付けます。

4.3 POV の日々の進め方

このセクションでは、実際に作業する人の視点から POV のライフサイクルを示します。AE、SA、SA Manager 向けに、誰が行動するか、望ましい状態とは何か、POV が次の段階に進む前に何を満たす必要があるかを示す運用上の見取り図です。

以下の役割別の進行サイクルは 30 日間の評価を想定していますが、責任は Simple、Extended、Enterprise、Commercial/Lite、パートナー主導、PS 主導、パイロット、DAP の取り組みに共通します。詳細なテンプレートとタイミングの例は、DAP AE チェックリストと POV 評価計画チェックリストを使用してください。

段階別・役割別の運用

段階 1: 申請 — POV の最初の日

申請段階では、評価が実際のもので、責任者がいて、計画する価値があるかを確認します。アカウントチームは、顧客からの申請を実行開始の承認として扱ってはいけません。

AE / 営業担当者のアクション

• 顧客の評価理由、望む成果、意思決定日、顧客側責任者、求められる GitLab の支援を確認します。
• 商談と契約に至る道筋を確認します。経営幹部の購買責任者、技術面の推進者、意思決定者をできるだけ早く特定します。
• DAP POV では、申請のスコープが十分に定まったら、顧客、商談、サブスクリプション、ユーザー数、申請クレジット数、ユースケース、スケジュール、評価計画へのリンクを含む DAP トライアルまたはクレジット申請 Issue を提出します。
• 評価は申請を最初に受け取った時点ではなく、計画、準備、承認が完了した後に始まることを伝えます。

SA のアクション

• 顧客が先に進む意向を示したら、直ちに Salesforce の POV オブジェクトを作成します。
• オブジェクトを正しい Account と Stage 3 — Technical Evaluation の Opportunity に関連付けます。
• 予定している将来の Start Date と End Date、POV Name、POV Type、Products Being Evaluated、責任者、初期の Success Criteria または POV 計画へのリンクを入力します。
• 初期の評価ワークスペースを作成するか、POV 計画を作成する場所を特定します。
• 評価が承認され、キックオフが行われるまでは、オブジェクトを New に保ちます。

SA Manager のアクション

• 申請に説明責任を負う SA、信頼できる商談、見込みのある実行経路があることを確認します。
• 申請に Simple と Extended のどちらの運用規律が必要かを特定します。ただし、その指定は Salesforce のフィールドとして扱わず、POV 計画と評価文書に記録します。
• 対応能力、法務、セキュリティ、プラットフォーム、DAP クレジット、パートナー、PS、サポートに関する依存事項を早期に指摘します。
• 承認とキックオフの前に満たすべき条件を明確にします。

申請段階の成果物

• 将来の日付が入力され、New に設定された Salesforce の POV オブジェクト。
• 正しい Account、Opportunity、責任者、SA、顧客、POV Type、製品 / 取り組み。
• 初期申請または計画へのリンク。
• Opportunity の Next Steps フィールドに明記された次のアクション、責任者、期限。

30 日間の POV 運用サイクル

DAP 固有の注意事項

DAP では、通常の POV ライフサイクルに使用量とクレジット管理の経路が加わります。

1. AE / 営業担当者が DAP 申請 Issue を提出します。 商談、サブスクリプション、顧客固有の評価計画、ユーザー数、ユースケース、申請クレジット数、日付、デプロイモデル、再トライアルや延長の背景を含めます。
2. SA が技術計画を検証します。 顧客のユースケース、ユーザー、プラットフォーム、バージョン、アクセス、設定、Runner / ネットワークの準備状況、スモークテスト、エビデンス、スケジュールを確認します。
3. SA Manager がレビューして承認します。 Salesforce の POV オブジェクト、更新以外の商談、顧客固有の計画、信頼できる意思決定への道筋、ユーザー数、準備計画、スケジュール、顧客向けスライド、測定計画を確認します。
4. SA Manager または権限を持つ付与担当者が、承認後にクレジットを付与します。 承認済みのクレジット上限内でのみ付与し、付与結果を POV 記録に残します。
5. 顧客が実行できるようになるまで、アカウントチームは DAP の評価期間を開始しません。 設定、スモークテスト、キックオフ、定例、アンケート、経営幹部への報告、Issue 管理、最終報告を計画する必要があります。
6. AE / 営業担当者は、経営幹部の購買責任者に週次で進捗を報告します。 SA は技術的な状況、ユースケースの進捗、Issue、フィードバック、エビデンスを提供します。

情報の種類ごとの記録場所

ベストプラクティスは、Salesforce を見通しの確認に十分な簡潔さに保ちつつ、評価計画では完全な POV の継続レポートを維持することです。SA Manager は General Notes から現在の状況を把握でき、見通しについて詳細が必要な場合は POV レポートを参照できるようにしてください。

5. トライアル評価チェックリスト

このチェックリストは特定の製品に依存しません。製品固有の事前チェックリストは詳細を追加するものであり、共通要件を省くものではありません。

5.1 統一トライアル評価チェックリスト

このチェックリストは特定の製品に依存しません。製品固有の事前チェックリストは詳細を追加するものであり、共通要件を省くものではありません。以下のすべての行に対応する必要があります。「エンタープライズ顧客 / Extended」と「コマーシャル顧客 / Lite」の列は、各モードで最低限必要なエビデンスを定義しています。

5.2 その他の準備作業

1. セルフマネージドの評価では、顧客のアーキテクチャが準備できていることを確認します。
2. SaaS の評価では、顧客のネットワークから GitLab.com に接続できることを確認します。
3. カスタマーサクセスのコラボレーションプロジェクトを作成します。
4. 最大規模の戦略的商談では、該当する Slack チャンネルで GitLab Support に POV の日程と顧客の詳細を通知します。
5. CI/CD を必要とする SaaS トライアルでは、トライアル用 Runner の有効化を申請します。

6. POV の製品と取り組み

各ソリューション分野に同じライフサイクルを適用します。選択した取り組みのカテゴリ別プレイブック、成功基準ライブラリ、スモークテストを使用します。

6.1 プラットフォーム別の適格性確認と実行上の留意点

どの取り組みも、顧客が評価に使用するプラットフォームを踏まえて適格性を確認する必要があります。プラットフォームの選択によって、前提条件、責任者、スケジュール、サポートモデル、セキュリティの協議、必要なエビデンスが変わりますが、別個の POV ライフサイクルを作るわけではありません。

3 つのプラットフォームすべてについて、SA は、プラットフォーム、対象環境、バージョンまたはリリースの制約、アクセス責任者、前提条件、既知のリスク、スモークテスト、エビデンスの情報源を POV 計画に記録する必要があります。

6.2 製品別の POV の進め方

製品ごとに別個の POV ライフサイクルを作成しないでください。代わりに、適格性確認の質問、成功基準の例、前提条件、設定チェックリスト、スモークテスト、ユースケースのプレイブック、エビデンスのテンプレート、既知の注意点といった、カテゴリ固有の活用支援資料を作成します。すでに構築済みの 4 つの成功基準ライブラリ（DAP、セキュリティ / コンプライアンス、アジャイル計画、CI/CD）をモデルとして、それぞれの取り組みが成熟するにつれて、Flex、Duo Hosted Runners、Secrets Manager、Orbit に展開します。

6.3 DAP セルフホストモデル

カスタム / セルフホストモデル: セルフホストまたはカスタムの AI モデルを含む POV はすべて、Custom Models プロジェクトの機密 Issue で追跡する必要があります（必須）。Custom Models チームが同時に対応できる件数には限りがあるためです。スケジュールを確約する前に、適格性確認の段階で同チームに参加してもらい、実現可能性を検証し、サポートの対応可否を確認し、成功基準に合意します。

7. Salesforce での追跡（正式な記録システム）

Salesforce の POV オブジェクトは、すべての POV とトライアルに共通する唯一の正式な記録システムです。商談に関する管理用の要約を提供し、POV 計画、評価文書、顧客コラボレーションプロジェクト、Issue 記録には実行の詳細なエビデンスを保存します。

SA が関与するすべての Self-Managed、Cloud、Dedicated、従量制トライアルには、次が必要です。

• Salesforce の POV オブジェクトへの登録。
• POV 計画と準備状況のレビュー後の SA Manager の承認。
• 関連する商談との明確な関連付け。
• ステータス、進捗、結果、次のステップの継続的な記録管理。

顧客が先に進む意向を示し、評価が Stage 3 — Technical Evaluation の関連商談に関連付けられたら、POV オブジェクトを作成します。評価が完了するまで作成を待ったり、同じ評価に対して重複する POV オブジェクトを作成したりしないでください。

DAP の注記: DAP の申請、クレジット、準備状況、実行に関する要件は、Duo Agent Platform の POV とトライアルのハンドブックで管理しています。このセクションでは、DAP と、SA が関与するほかのすべての POV に必要な Salesforce の記録管理を定義します。

7.1 POV が依頼されたとき: 直ちにオブジェクトを作成する

顧客が POV を依頼した場合、技術評価に合意した場合、またはアカウントチームが SA 支援付きトライアルを確約した場合は、次を行います。

1. 直ちに Salesforce の POV オブジェクトを作成します。
2. 正しい Account と Stage 3 の商談に関連付けます。
3. 予定している将来の Start Date と予定の End Date を入力します。開始日を申請日に遡らせたり、実行開始後に過去のオブジェクトを作成したりしないでください。
4. POV Type を選択します。Simple/Light または Extended/Heavy は、POV 計画と補足の評価文書に記録します。Salesforce の POV オブジェクトのフィールドではありません。
5. 初期の顧客の課題、提案するユースケース、製品 / 取り組み、予定する意思決定日を追加します。
6. 利用可能であれば、ドラフトまたは作成中の POV 計画、評価文書、コラボレーションプロジェクトにリンクします。
7. 評価の適格性確認、計画、レビューの間は、Status を New に保ちます。

将来の Start Date は予定されるキックオフを示すものであり、実行開始の許可ではありません。評価期間は、チームの準備が整い、顧客が計画に合意し、必要な承認が完了した後にのみ開始します。

7.2 Salesforce の POV オブジェクトのフィールド

申請時に必須フィールドを入力し、計画が具体化するにつれて補足フィールドを追加または更新します。

個別の SA が検証した技術評価の開始 / 終了日フィールドは廃止されています。POV の追跡を Salesforce の POV オブジェクトに集約します。

7.3 SA Manager の承認ワークフロー

まず AE / 営業担当者または SA が POV オブジェクトを作成します。SA Manager はオブジェクト、POV 計画、商談の背景をレビューした後、評価を承認します。

承認前に、SA Manager は次を確認してください。

• POV オブジェクトが正しい商談と Account に関連付けられている。
• 商談が信頼できる技術評価であり、更新のみの取り組みではない。
• 予定している将来の Start Date と End Date が現実的である。
• POV Type、製品 / 取り組み、プラットフォームが明確である。実行モードは Salesforce の POV オブジェクトではなく POV 計画に記録します。
• POV 計画が顧客固有のものであり、テンプレートのコピーではない。
• 目標、ユースケース、成功基準、参加者、ユーザー、責任、意思決定日が定義されている。
• 顧客向け計画を提示済み、または顧客の合意を得る予定が設定されている。
• 技術的な準備、設定、スモークテスト、アクセス、サポートの前提条件が完了しているか、責任者と日付が設定されている。
• コラボレーションプロジェクト、評価文書、Issue 管理の場所がリンクされている。
• 対応能力、リスク、クレジット、必要な部門横断の承認を把握している。

承認後、SA Manager Leader Approved を Yes に設定し、条件や例外を General Notes に記録します。承認待ちの間は、POV を開始したりトライアルのリソースを提供したりしないでください。

7.4 POV を In Progress にする

顧客と GitLab が合意した評価活動を開始した キックオフ時に、POV オブジェクトを New から In Progress に変更します。

ステータスを変更する前に、次を行います。

• 顧客がスコープ、スケジュール、役割、成功基準に合意していることを確認します。
• 予定の Start Date、End Date、意思決定日 / 報告日を確認します。
• SA Manager の承認が記録されていることを確認します。
• 必要なプラットフォーム、アクセス、設定、スモークテスト、サポートの前提条件が整っているか、日付入りの計画に沿って実際に作業中であることを確認します。
• POV 計画、コラボレーションプロジェクト、Issue 管理の場所がリンクされていることを確認します。

オブジェクトを作成した、ディスカバリーの通話を行った、汎用デモを実施したというだけで、POV を In Progress にしないでください。In Progress は、合意した計画に沿って評価を実際に実行していることを意味します。

7.5 POV の進捗に応じて General Notes を更新する

General Notes は、SA Manager が技術面の見通しを確認するために使用する、Salesforce 上の簡潔な管理用要約です。詳細な POV レポート、評価計画、コラボレーションプロジェクト、Issue ボード、会議メモの代わりではありません。

General Notes は少なくとも毎週、およびすべての重要なマイルストーンで更新します。見出しには日付ではなく Week # を使用します。標準的な 30 日間の評価では Week 1、Week 2、Week 3、Week 4 を使い、最新の週を先頭に置き、Week 4 を最後の評価週とします。

推奨形式:

Week 4
Status: Green / Yellow / Red
Progress: <what was completed against the success criteria>
Customer Sentiment: <positive / mixed / at risk, with evidence>
Main Blocker / Issue: <primary blocker or issue affecting progress, owner, and escalation>
Decision / Readout: <current decision, readout date, or next commercial/technical step>

Week 3
Status: <prior-week status>
Progress: <prior-week progress>
Customer Sentiment: <prior-week sentiment>
Main Blocker / Issue: <prior-week blocker or issue>
Decision / Readout: <prior-week decision or next step>

Week 2
Status: <prior-week status>
Progress: <prior-week progress>
Customer Sentiment: <prior-week sentiment>
Main Blocker / Issue: <prior-week blocker or issue>
Decision / Readout: <prior-week decision or next step>

Week 1
Status: <initial-week status>
Progress: <initial progress against the success criteria>
Customer Sentiment: <initial sentiment>
Main Blocker / Issue: <initial blocker or issue>
Decision / Readout: <initial next step>

良い General Notes の更新は、次の質問に答えるものです。

• 合意したユースケースと成功基準について、今週何が変わりましたか？
• 現在のステータスは Green、Yellow、Red のどれですか？
• 顧客の反応と関与の度合いはどうですか？
• 主な阻害要因または Issue は何で、誰が責任者で、エスカレーション経路は何ですか？
• 現在の判断、報告日、商業面 / 技術面の次のステップは何ですか？

評価文書の POV レポートタブ は実行の詳細記録です。完全な状況説明、週次進捗、顧客のフィードバック、SA またはアカウントチームが作成または対応に協力したすべての Issue を POV レポートに記載します。レポート内の各 Issue と関連エビデンスを、ユースケースまたは成功基準に関連付けます。

SA Manager は技術面の見通しに General Notes を使用してください。さらに詳細が必要な場合は、評価計画の POV レポートタブを参照してください。評価全体を通して POV の継続レポート を維持し、完全な実行履歴に基づいて最終報告と Salesforce の終了処理を行うとよいでしょう。

詳細な Issue 履歴、会議の文字起こし、長い状況説明を General Notes に貼り付けないでください。そこには管理上の要点を要約し、元の詳細は POV レポート、評価計画、コラボレーションプロジェクト、Issue 記録に保存します。

7.6 POV オブジェクトを閉じる

評価が合意した終了日 / 報告に達した場合、顧客が判断した場合、またはアカウントチームが評価を再開しないと判断した場合は、POV オブジェクトを閉じます。

終了前に、次を行います。

1. すべての成功基準に照らした最終技術レビューを完了します。
2. 顧客と経営幹部の購買責任者からのフィードバックを記録します。
3. 未解決のバグ、機能強化、Product Management の対応、Engineering の対応、Customer Support の対応を記録します。
4. 最終報告を実施するか予定に設定し、商業上または本格展開の次のステップを文書化します。
5. 最終的なエビデンスと判断で General Notes を更新します。
6. Status を Closed に設定します。
7. Result を Successful または Unsuccessful に設定します。
8. 理由、エビデンス、未解決の不足、次の責任者 / アクションを含む簡潔な終了メモを追加します。
9. 関連する商談、コラボレーションプロジェクト、評価計画、トライアル / クレジット記録を更新します。

成功

合意した技術的成功基準を満たしたことを顧客と GitLab が十分なエビデンスで確認できる場合、または顧客が成果を明示的に受け入れ、合意した商業面、本格展開、導入の次のステップへ進んでいる場合は、Successful を使用します。

終了メモには次を含めてください。

• 検証したユースケースと成功基準。
• 結果を裏付けるエビデンスまたは指標。
• 顧客による確認または報告の結果。
• 商業面、本格展開、調達、移行の次のステップ。
• 明記した結果を妨げない残存の Issue。

失敗

POV が合意した成功基準を満たさなかった場合、顧客が別の道を選んだ場合、製品またはアーキテクチャが適合しなかった場合、顧客が実行できなかった場合、または信頼できる今後の道筋がないまま評価が終了した場合は、Unsuccessful を使用します。

失敗の理由は具体的でエビデンスに基づく必要があります。例は次のとおりです。

• 技術的成功基準を満たさなかった。
• 製品の不足、バグ、必要な機能強化が成功を妨げた。
• デプロイ、セキュリティ、ネットワーク、データ、設定の制約が実行を妨げた。
• 顧客が必要なユーザー、時間、アクセス、データ、意思決定への参加を提供しなかった。
• 競合比較またはアーキテクチャの判断で別のソリューションが選ばれた。
• タイミング、予算、調達、組織の優先事項が変わった。
• 合意したフォローアップの手順を経ても、顧客が関与をやめたか判断しなかった。

理由なく「Unsuccessful」を使用しないでください。評価がまだ継続中であるものの阻害されている場合は、代わりに Stalled を使用します。

7.7 POV を Stalled にする

重要な阻害要因、顧客による一時停止、前提条件の不足、リソースの問題、意思決定の遅れによって POV が実際に進行していない一方、チームが最終的な終了判断をまだ行っていない場合は、Stalled を使用します。

POV を Stalled にする際は、次を行います。

• Status を New または In Progress から Stalled に変更します。
• 停滞の理由を General Notes と終了メモに追加します。
• 阻害要因の解消に責任を持つ担当者を明記します。
• 次のアクションと、具体的なレビュー日または再開日を記録します。
• 阻害要因となる Issue、顧客とのコミュニケーション、意思決定記録にリンクします。
• 顧客と GitLab が再開に合意するまで、POV を実行中として提示しないようにします。

阻害要因が解消したら計画を更新し、再開 / キックオフの確認時点で POV を In Progress に戻します。再開しない場合は、「停滞 / 判断なし」またはその他のエビデンスに基づく理由を明記し、Unsuccessful として閉じます。

7.8 ステータスと記録管理の規則

次のような記録管理の不備を避けてください。

• トライアル開始後に POV オブジェクトを作成する。
• Start Date または End Date を空欄にする、または顧客の計画と一致しない日付を使用する。
• 同じ POV に重複するオブジェクトを作成する。
• キックオフ後も Status を New のままにする。
• 阻害されている評価を In Progress のままにする。
• Successful または Unsuccessful を選択せず、理由も文書化しないまま終了する。
• 元の記録にリンクせず、詳細な会議メモを General Notes に貼り付ける。
• POV オブジェクト、商談、評価計画、コラボレーションプロジェクト、Issue 記録の内容が一致しない状態にする。

ページのソースコードを見る - ページの編集 - please contribute.