ソリューションアーキテクチャの活動ロギング

Phase 1 の展開に関する理由、方法、例外的なケースの記録方法、既知の制限、FAQ を、Solutions Architecture 組織全体が参照できるよう 1 か所にまとめています。

ステータス: Phase 1 は 2026-09-07 に開始 · Rattle での活動記録は廃止 · 最終更新 2026-09-07

1. この変更の理由

活動データの質を高めることで、リーダーシップは個別の体験談ではなく根拠に基づいて SA の人員数、担当範囲、投資の必要性を訴えられ、チームのどこに負荷が集中しているかも把握できます。目的は監視ではなく、SA がすでに行っている業務を評価し、可視化することです。

• パイロット · 2026-09-07 - Q3 が最初の実データセットになります。目標は完璧な数値ではなく習慣を身につけることです。不完全でも、正直に記録してください。
• Phase 1 · 現在 - GitLab でホストする軽量なフォームが Rattle に代わり、SA の活動を追跡する唯一の方法になります。
• Phase 2 · 今後数か月 - 自動化された MCP 機能（承認待ち）により、手入力を減らして Salesforce に直接書き込みます。

2. 必要な対応

1. 2026-09-07 月曜日から、SA の活動追跡に Rattle を使うのをやめてください。Slack 連携は同日停止します。（Rattle のその他の機能は引き続き稼働します。SFDC のケースのトリアージ/SA Requests やその他の通知は、今のところ影響を受けません。）
2. GitLab SA Activity Formで記録を開始してください。
3. 可能であれば当日中に記録し、難しければ活動の記憶が新しいうちに、遅くとも週に 1 回は記録してください。
4. 開始前に短い「ある 1 日」のデモ（顧客向けとそれ以外の活動の記録方法を紹介）を視聴してください。
5. 難しい質問はチームリーダーに相談してください。リーダーシップによる説明会はそのためにあります。

3. よくあるケースの記録方法

Salesforce でのアカウント ID または商談 ID の確認方法: アカウント URL は .../Account/0016100000SwqPFAAZ/view のような形式（ID は 0016 で始まります）、商談 URL は .../Opportunity/006Qq00000qM2jcIAC/view のような形式（ID は 006 で始まります）です。ドロップダウンの有効な項目を選択する必要はなく、ID を直接貼り付けられます。

4. 既知の問題と制限

• 商談の同期遅延。 商談一覧は Salesforce から 4 時間ごとに更新され、その後約 15 分間キャッシュされます。キャンペーン一覧と地域の検索結果も 15 分間、トークンからメールアドレスへの検索結果は 5 分間キャッシュされます。Salesforce Connector の更新やクエリの編集直後は、フォームに最大 15 分間古い一覧が表示される可能性があります。
• ドロップダウンに表示されない商談。 New Business SA などから、SFDC で実際に割り当てられている商談よりも、表示される商談が大幅に少ないという報告があります。Account レベルではなく Opportunity レベルで割り当てられていることが原因かもしれません（Command Center でも同じ根本原因が指摘されています）。2026-09-07 時点で未解決です。回避策は商談 ID を手動で貼り付けることです。
• 過去の送信内容を確認する方法がありません。 ツールには、すでに記録した内容の履歴やダッシュボードがありません。「Download backup CSV」ボタンはありますが、読みやすい名前ではなく Salesforce ID だけが表示されます。自分で参照できるよう、Notes にアカウント名/商談名を追加することを検討してください。
• ローカルバックアップは失われやすい状態です。 記録は「このデバイス上のローカルバックアップ」として保存され、ブラウザーのキャッシュを消去すると削除されます。
• カレンダー連携はまだありません。 Rattle の Slack による会議の通知とは異なり、新しいフォームにはカレンダーに基づく記録や会議の自動検出がありません。Phase 2 で最も要望の多い機能ですが、2026-09-07 時点では、文書化された機能リクエストのプロセスによる一元的な追跡はまだ行われていません。
• Ecosystem/Partner SA 向けのカテゴリが不足しています。 「Customer-facing」は Ecosystem SA の業務の大半に当てはまらず、「Partner enablement」と「Workshop」の分類も曖昧です。最初の数か月分のデータが集まった後に調整する項目として指摘されています。
• 不足している活動タイプ。 Rattle にあった「Post-sales support」は、新しいフォームのドロップダウンにはまだありません。追加が要望されていますが、まだ追加されていません。
• フォーム自体に費やす時間のカテゴリがありません。 新しいプロセス自体の負担を測定できるようにするため、追加が要望されています。
• アクセシビリティ/作業負荷に関する懸念。 複数の SA（特に多数のアカウントを担当する SA やニューロダイバージェントな SA）から、Rattle/Troops にあったカレンダーに基づく通知がなく、自動化されていない手作業の記録は認知負荷と過少報告のリスクを増やすとの指摘がありました。
• 自動化を進めています。 データ入力を支援するツールは、2026-09-07 時点で社内レビュー中です。

5. FAQ

1:1、チーム通話、コーヒーチャット、メンタリングなど、すべての社内会議を記録する必要がありますか？

いいえ。顧客に関する会議（準備、通話前後の作業、計画）の場合のみ記録してください。従来のプロセスから変更はありません。

新しい商談（以前は自分に割り当てられていなかったもの）がドロップダウンに表示されるまで、どのくらいかかりますか？

同期は 4 時間ごとに実行され、さらに約 15 分間キャッシュされます。まだ同期されていない商談に記録する必要がある場合は、商談 ID を直接貼り付けてください。フィールドでドロップダウンの有効な項目を選択する必要はありません。

商談/アカウントのフィールドではドロップダウンの有効な項目を選択する必要がありますか、それとも ID を入力するだけでよいですか？

ID を直接入力するだけで構いません。

複数の顧客が参加するマーケティングサミットやウェビナーなど、幅広い対象のイベントはどのように記録しますか？

Salesforce の Campaign ID（701 で始まります）を使用してください。フォームの下部にあるキャンペーン選択欄で確認できます。一覧にない場合は、ID を直接貼り付けてください。

パートナーイネーブルメントや MDF を使用した訪問業務はどのように記録しますか？

パートナーの Salesforce Account ID を使用してください。パートナーはアカウントとして追跡されます。

商談もアカウントもまだない場合（パイプラインの初期/リード段階）はどうすればよいですか？

Account ID がある場合はそれを使用してください。まだ何もない場合は、フィールドに「Pipeline Gen」と入力してください。

ブログ記事、オンボーディングバディの業務、面接などの社内への貢献はどのように記録しますか？

Non-Customer Facing → Activity Type の「Other」を選択 → Notes で説明します。

1 回の出張で複数の顧客/パートナーを訪問します。移動自体はどのように記録しますか？

複数の商談 ID を入力するか、主要な顧客を 1 社選んでそこに移動を記録してください。各訪問/ワークショップは、それぞれのアカウントに対して個別に記録します。移動時間自体は顧客対応ではないため、Non-Customer Facing に記録するだけでも構いません。

Rattle は完全に廃止されますか？

完全な廃止ではありません。SA の活動追跡での使用は 2026-09-07 に停止しますが、Salesforce のケースのトリアージ（SA Requests）やその他の自動化/通知といった機能には、今のところ引き続き使用します。

すでに送信した内容をすべて一覧で確認できますか？

ツール内で直接確認することはまだできません。「Download backup CSV」ボタンはありますが、名前ではなく Salesforce ID のみが表示されます。参照しやすくするために、Notes にアカウント名/商談名を追加することを検討してください。ブラウザーのキャッシュを消去するとローカルバックアップが削除されるため、消去する前にバックアップしてください。

カレンダーと連携し、会議のたびに手動で記録しなくてもよくなりますか？

まだできません。その種の自動化（Salesforce に直接書き込む MCP 機能）は Phase 2 で計画されていますが、2026-09-07 時点では、承認を条件として今後数か月以内の予定です。機能リクエストは sa-activity リポジトリで提出できます。

New Business SA として割り当てられた商談の大半がドロップダウンに表示されないのはなぜですか？

Salesforce で New Business SA が Account レベルではなく Opportunity レベルに割り当てられているためと考えられます（同じ問題が Command Center にも影響しています）。2026-09-07 時点で未解決の問題であることが確認されています。当面は、商談 ID を手動で貼り付けてください。

記録を忘れたり、記録が遅れたりした場合はどうすればよいですか？

できるだけ当日に近いタイミングで、遅くとも週に 1 回は記録してください。リーダーシップからのメッセージは、整っていても作り上げたデータより、不完全でも正直なデータのほうがよいというものです。

6. 活動タイプ

以下は活動を記録するときに選択できる活動タイプです。従来のプロセスから引き継いだもので、一部の説明には Rattle のフィールド名が残っています。フォームのドロップダウンの変更に合わせて更新を進めています。

Enterprise および Commercial SA 活動タイプ

Enterprise および Commercial SA チームによる活動をキャプチャする際には、これらのタイプを選択します。

• Customer No Show - SA は、顧客が出席しなかった予定された顧客会議について活動をログする機会があります。SAE/AE/Channels Manager と協力して、SA は顧客の不在の根本的な理由を理解しようとし、[SA] Activity Description に記録すべきです。

• Customer Strategy Plan Review - （注: この活動タイプは依然としてレガシー名「Customer Strategy Plan」を使用していますが、Customer Success Plan の活動を指します）ビジネスステークホルダー、影響度の高い戦略要件と主要技術、顧客の技術エコシステムの現状、現在および望ましい能力、戦略目的との運用整合、そして現在の能力における認識されたギャップと欠陥を特定して文書化する SA と顧客の協働セッション。詳細は カスタマーサクセスプラン を参照してください。この活動を報告する際には、最新のカスタマーサクセスプランへのリンクを含める必要があります。

• Demo - SA は、計画された GitLab 製品デモが顧客に提供されたときに活動を記録できます。Rattle の [SA] Activity Description フィールドで、SA はデモの目的と製品ウォークスルーの領域に関する洞察も参照すべきです。オプションは、フルでハイレベルなエンドツーエンドの GitLab 概要、特定の GitLab ステージのデモ、部分的な GitLab プラットフォーム概要、または製品への非常に特定の技術ディープダイブが考えられます。

• Discovery Session - SA は、顧客との初回ディスカバリーセッション中の主要な洞察を記録する機会があります。SA は、現在の環境がプロジェクトの成果物の制限となっているかどうか、または既存のプラットフォームを当社の提供で拡張する必要があるかどうかを理解するため、顧客と協働できます。カテゴリ化されたディスカバリーセッションの例:

  • DevOps ディスカバリーディスカッション
  • 継続的インテグレーションディスカッション
  • デプロイメント環境ディスカッション
  • アプリケーションフロントエンド・バックエンドディスカッション
  • クラウドジャーニーと戦略のディスカッション

• Other - SA は、オプションのドロップダウンリストにリストされていない活動を記録するためにこの [SA] Activity タイプを利用すべきで、想定外のすべてのタイプの SA サービスのために予約されています。この活動タイプを使用するときは、Rattle の [SA] Activity Description フィールドで活動の詳細を記録するために正確であることが不可欠です。

• Post-sales technical account management - SA は、CSM の対象とならないアカウントの技術アカウントマネジメント業務、および販売後ケイデンスコールの一部としての CSM とのコラボレーションを記録するためにこのタイプを使用します。ケイデンスコールを使用してアカウントを拡大する成長商談については、他の適切なタイプで活動をログしてください。

• PoV related activity - クライアントによる PoV および / または Technical Evaluation の意向は、Discovery セッションまたは別の [SA] Activity 中に共有されることが想定され、PoV 関連活動は SA が PoV または Technical Evaluation の準備、実行、完了に関連する活動記録として使用されます。PoV 関連活動の例:

  • PoV/Technical Evaluation スコーピング: SA は、要件を理解するためにクライアントとエンゲージし、評価のタイプ [PoV または Technical Evaluation] とスコープ内の成功基準について合意するために協働する活動を記録する機会があります。クライアントは一方で、ハイタッチかライトタッチの PoV が必要かを定義する機会があります。オプションとして、クライアントは自己管理型の Technical Evaluation で十分で、SA がアドホックに支援することを決定することを好むかもしれません。
  • Technical Evaluation ケイデンス: SA は、Technical Evaluation に関連するクライアント特有の活動を記録する機会があります。プラン、特定の要件、成功の定義に同意した上で、SA は顧客との協働により定期的または不定期のケイデンスを設定することがあります。
  • PoV ケイデンス: SA は多くの場合 PoV プラン、期間、スコープ内の PoV 成功基準のサインオフに同意し、定期的なケイデンス [週次、隔週、複数週] でクライアントと協働します。この [SA] Activity は、PoV の頻度と進捗をキャプチャする機会です。SA は、評価の最終完了のサインオフに同意するためにクライアントとの最終ケイデンスセッションをホストすることを検討すべきです。

• Presentation / pitch - SA は、クライアントへのプレゼンテーションの準備と実際の提供を記録する機会があります。SA なしでクライアントとの大幅な議論があったため、SAE/AE からピッチがリクエストされることがあり、これは完全に許容されます。このタイプの [SA] 活動 の検討事項:

  • SA がクライアントとの最初の Technical Discovery セッションに参加し、最初の要件が SA と明確に協働され、プレゼンテーションの準備のためにイニシアチブを取った。
  • SA が SAE/AE/Channels Manager と内部でデブリーフし、クライアントとの初回 SA 接続の要件と最初のプレゼンテーション / ピッチへの期待を理解した

• Ride Along - この活動タイプは、ある SA が別の SA をシャドーイングして商談をサポートし、メインのソリューションアーキテクトへのフィードバックを提供し、メインのソリューションアーキテクトの仕事方法を学ぶときに使用されます。Ride Along の動作の詳細については、Ride Along ハンドブックページを活用してください。この活動はアカウントレベルで記録します。アカウントレベルでの記録が必要なのは、セグメント間または地域間の Ride Along では、ライダーが商談にアクセスできないためです。

• Guided Trial - この活動タイプは、見込み顧客または既存顧客が GitLab Free trial 提供を使用した自己評価中に SA からのサポートを必要とする場合に使用されます。

• Security Questionnaire / RFP - SA は、セキュリティアセスメントの完了や入札プロセスを通じた商談の進行に関連するアクションを記録するためにこの活動タイプを使用すべきです。このカテゴリに該当する活動の例:

  • Security Assessment: 技術的には入札プロセスの一部ですが、Security Assessment は通常 SA が GitLab の管理部門と連携して、正確性と法的応答を確保するためにエンゲージします。そのため、SA はそれらのセキュリティ固有の要件に対処するために GitLab の部門と内部でエンゲージしますが、プロセスに先立って、SA はクエリへの最初の試みとして対応する責任があります。
  • Procurement / Tender process（RFx - RFP, RFQ, RFI, FRB, RFT - Request for Anything）: SA はクライアントとエンゲージし、その組織が公的入札プロセスを実施することが示されました。入札プロセスは、提案、見積もり、情報、関心の表明をリクエストする可能性があり、通常はリクエストの一部として GitLab プラットフォームの機能要件と非機能要件への応答を SA に求めます。多くの場合、入札プロセスは早期に示され、市場へのアプローチで公平に共有され、書面によるアーティファクトの形で技術的なものに対処する SA を含む正式なプロセスを必要とします。

• Technical Deep Dive - SA はテクノロジーと GitLab 機能の詳細なレビュー、およびクライアントソリューションの作成に関するクライアントセッションを記録すべきです。

• Technical Support - SA はアカウントチームとして、また GitLab Support と協力して特定の技術的な問題や課題のトラブルシューティングと対処に関する技術サポートセッションを実施します。

• Positioned Professional Services - この活動タイプは、Solution Architects プロセス の一部としてプロフェッショナルサービスをポジショニングしたときに使用すべきです。

• Professional Service Support - SA はクライアントの利用可能な内部スキルと能力を明確に理解し、スキルギャップが特定された場合に、より迅速に成功する方法でクライアントを支援します。その結果、GitLab プロフェッショナルサービスのサポートは、リスクを軽減し成功への速度を加速するために顧客価値を追加します。SA は、ここで概説されている当社の顧客のための GitLab の ProServ 部門の開始を所有しているため、地域の顧客への SA サービスとして、相当量のフォローアップとケイデンスが期待されます。

• SA Assistance - Subject Matter - 特定のエンゲージメントや商談を所有することなく、特定の主題における高度な知識と理解で別の GitLab チームメンバーをサポートすることを [SA] にリクエストされます。

• SA Assistance - Manager - 顧客エンゲージメントを支援する場合に [SA] Manager によって使用されます。

Strategic Field SA 活動タイプ

Strategic Field チームによる活動をキャプチャする際にこれらの [SA] Activity タイプを選択しますが、Enterprise の他の活動タイプも使用できます。

• SA Assistance - Strategic Field - エンタープライズ DevOps 戦略と、デジタルやクラウド変革などの全社的なイニシアチブとの整合をレビューするためのクライアントの管理職や経営陣とのコール。
• Executive Solution Plan - 組織全体の変革のための DevOps ソリューションを議論、戦略化、レビューするクライアントの管理職や経営陣とのコール。業界のソートリーダーシップとの信頼できるアドバイザリ関係を構築し、ベストプラクティスでの DevOps 採用に向けてエンタープライズを導きます。

Ecosystem SA 活動タイプ

Ecosystem チームによる活動をキャプチャする際にこれらの [SA] Activity タイプを選択しますが、Enterprise の他の活動タイプも使用できます。価値の高い活動が最も上 / 最初に、最も低い / 最後にリストされる暗黙の優先順位があります。

単一の活動に複数の活動タイプを使用できますが、行われた最も価値の高い単一の活動のみをタグ付けするようにしてください。たとえば、コールを Partner Enablement の実施に活用した場合、Partner Cadence Call を追加しないでください。

ある活動が MBO の1 つにカウントされることを提案する場合は、その活動にオーバーレイタグとして MBO 関連活動タイプを 必ず追加してください。MBO タイプを使用するときは、Activity Description にドキュメント、Issue へのリンク、または根拠となるコンテンツを配置してください。

🎥 ビデオ: 忙しい Solutions Architect 向け: 多数の Rattle エントリをすばやく記録、分類、トリアージする方法 9:17、Highspot。 以下のテキストを補完します。

• ESA MBO Strategic - Strategic Partner Activation - 合意されたタイムラインに対する相互パートナー技術関係目標を推進するための Partner Activation Plan。PAP を活用して、パートナーの能力、チャンピオン、人材リソース、活性化成果を追跡します。
• ESA MBO Contribution - Partner Contribution to Pipeline - 適格パイプラインと収益貢献を生成する PAP で定義された構造化された準備プログラムを通じて、パートナーの技術プリセールス能力を高めます。
• ESA MBO Capability - Ecosystem Services Capability - 顧客アカウント関係でのサービス提供の統合を通じて、顧客のオンボーディングと採用を加速します。
• ESA MBO Commitment - Commitment and Advocacy - GitLab Champions プログラムを活用して、パートナー技術リソースからの価値の高い技術投資とアドボカシーを推進します。

さらに、各 Rattle 活動には、以下のいずれか1 つ（そして1 つだけ）の Rattle タグをタグ付けしてください。Partner Opportunity 💸 💸 💸 💸 💸 が最も価値の高い活動で、Partner Cadence Calls が最も価値の低い活動です。

• Partner Opportunity - 💸 💸 💸 💸 💸 パートナーが関与する特定のセールス商談で、フィールド SA とともに整合した Sales opportunity # アライン業務。これには、パートナーテクノロジーと GitLab とのジョイント価値提案のオーバーレイ SME であること、および / またはチャネル / サービスパートナーがジョイント顧客で成功するのを支援することが含まれます。
• Partner Assisted Demand Gen - 💸 💸 💸 💸 需要創出 / リード創出に焦点を当て、パートナーと協働して顧客向けのウェビナー、ワークショップ、ロードショー、類似の活動を提供または開発すること。
• Partner VSA Enablement - Value Stream Assessment および類似のプリセールス価値販売モーションをピッチまたは実行するためのパートナーのイネーブルメントを含む活動。
• Partner Technical Evangelism - 💸 💸 💸 パートナーの内部カンファレンス、ミートアップ、ウェビナー、オープン招待ブートキャンプ、ブログ、カスタマーサクセスストーリーなど、パートナー向け（顧客向けではない）のイベントとエバンジェリズムの提供または開発。
• Internal Enablement and SME Assistance - 💸 💸 パートナープロモーションと GitLab フィールドチーム支援のための GitLab 向けの内部コール、会議、ウェビナー。
• Partner Solutioning - 💸 💸 パートナーソリューションを定義・開発し、GitLab との統合を行うソリューションアーキテクチャ業務。特定のセールス商談で行われる業務については「Partner Opportunity」を検討してください。
• Partner Services Attach - 💸 💸 将来のサービスエンゲージメント向けにパートナーサービスカタログと / または SoW を開発する。
• Partner Enablement - 💸 GitLab 製品とプリセールスでパートナーチャンピオンをイネーブルするための準備業務を含む、パートナー向けのコール、会議、ワークショップ、ウェビナー。
• Partner Cadence calls - パートナーシップ構築と顧客商談やアカウント戦略におけるプリセールス活動のためのパートナーとのケイデンスコール。

Value Stream ワークショップ（アセスメント）活動タイプ

注: これらのオプションは依然として「VSA」の旧名称を参照していますが、データ追跡が継続している理由により、選択を更新できません。これにご注意ください。

• VSA Pitch - 顧客 / 見込み顧客への最初の VSW ピッチで、関係者の賛同を得て、次のステップを議論し、VSW 計画会議の前にフォローアップを送信します。
• VSA Execution - VSW 計画、VSW ワークショップ、VSW エグゼクティブプレゼンテーションのための外部の顧客 / 見込み顧客とのコール。

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