Digital Experience ハンドブック

概要

🙌 パーパス

なぜ私たちが存在するのか

私たちは、GitLab がどのようにソフトウェアをより速く、より安全に提供できるようにしているのかについて、見込み顧客を教育するため、顧客中心のアプローチを取ります。

チームメンバー

スコープ

私たちのチームは GitLab のデジタルマーケティングプラットフォーム、つまり「Marketing Site」（https://about.gitlab.com）をリードしています。 私たちは以下のリポジトリをオーナーとして保有しています:

• About.gitlab.com
• GitLab Blog
• Navigation
• Slippers Design System
• Buyer Experience（非推奨）

私たちのチームの強みとコアケイパビリティ:

• about.gitlab.com のエンジニアリングと UX デザイン
• クロスコラボレーション
• スピードとデリバリー
• カスタマージャーニーマップ

私たちのチームがサポートするもの:

• HTML メールテンプレート
• PathFactory
• Marketo
• learn.gitlab.com
• www-gitlab-com
• グローバリゼーション

私たちはサポートしません:

• Handbook
• Internal handbook
• コンテンツのコピーライティングや編集
• Cloudflare サーバーインフラ

密に連携するチーム:

• SEO
• Analytics
• Product Marketing
• Content Marketing
• Brand Strategy
• Marketing Ops
• Blog
• Globalization
• Events
• Competitive Intelligence

OKR

私たちは、各四半期の前にクロスファンクショナルなパートナーとともに、チームとして協調的に OKR を定義します。OKR の候補が出揃ったらレビューし、サイズ／スコープを評価し、ビジネス目標達成に最も寄与するものに合意します。

現在の四半期プラン

FY26Q3 Digital Experience Quarterly Plan & OKRs

イテレーションプロセス

私たちは月曜日にイテレーションを開始します。イテレーション中、リリースを継続的に行います。月曜日のイテレーションプランニング後の翌週木曜日には、同期ミーティングで成果、ブロッカー、Start／Stop／Continue を議論し、Slack チャンネルでハイライトする 3 つの項目を選びます。

Issue ボード

• Digital Experience ボード

ラベルとワークフローボード

私たちは、イテレーション中の Issue 進捗を追跡するために Issue ボードを使用しています。Issue ボードは、グループ内のネストされたすべてのプロジェクトを可視化するため、最も上位のグループレベルで参照すべきです。

Digital Experience チームでは、専門領域間の Issue オーナーシップを区別するために次の Issue ラベルを使用しています:

Digital Experience チームでは、マージリクエスト率と、Issue ／マージリクエストのオーナーシップを追跡するために、次のラベルを使用しています。

Digital Experience チームは、複数のグループとプロジェクトを横断して GitLab コードベース全体で作業しています。たとえば:

• gitlab.com/gitlab-org グループ
• gitlab
• customers-gitlab-com
• gitlab.com/gitlab-com グループ
• www-gitlab-com
• Buyer Experience
• GitLab Blog
• Slippers Design System
• Marketing Site Navigation Package
• About.gitlab.com

見積もり

Issue に着手する前に、まず予備調査を行ったうえで見積もりを行います。これは通常、イテレーションプランニングミーティングで実施されます。

プランニングと見積もりにおいて、私たちは 予測可能性よりも速度 を重視します。プランニングと見積もりの主な目的は、MVC にフォーカスし、盲点を浮かび上がらせ、過度に最適化することなくベースラインの予測可能性を達成することです。私たちは 90% ではなく 70% の予測可能性を目指しています。速度（マージリクエスト率）への最適化が、Growth チームが 週次の実験ケイデンス を達成することを可能にすると信じています。

• 1 か 5 か判断がつかないほど不明点が多い Issue は、慎重を期して高い見積もり（5）を取ります。
• 不明点が多い Issue は、2 つに分割できます。1 つ目は調査用 Issue（Spike とも呼ばれる）で、不明点をデリスクし潜在的なソリューションを探索します。2 つ目は実装用 Issue です。
• 初期見積もりが不正確で調整が必要な場合、すぐに見積もりを修正し、プロダクトマネージャーに通知します。プロダクトマネージャーとチームが、マイルストーンへのコミットメントを調整する必要があるかどうかを判断します。

プランニング（イテレーション計画同期）

イテレーションプランニングは、イテレーションの開始を告げるイベントです。ミーティングの目的は、キャパシティの議論と、来期イテレーションの作業計画です。

ケイデンス: 50 分、隔週（zoom）

内容:

• キャパシティの議論
• イテレーションボードのレビュー

イテレーションリリース: レトロスペクティブとフィードバック

私たちは成果を祝い、何がうまくいっていて何がうまくいっていないかを議論します。議論のトピックには、ブロッカーの特定、止めるべきこと・始めるべきこと・続けるべきことの判断などが含まれます。その後、完了した作業の中から 3 つを選び、イテレーション告知 Issue と Slack でハイライトします。プランニングおよびリリースミーティングで使用しているアジェンダはこちらです。

いつ: 木曜日、50 分、隔週（zoom）

内容:

• 成果を祝う
• 議論のトピック
• ブロッカーはあるか？
• 止めるべきことは何か
• 始めるべきことは何か
• 続けるべきことは何か
• ハイライトする 3 つの項目

レトロスペクティブ

レトロスペクティブは各四半期末に開催するイベントで、何がうまくいったか、何が改善できるかを議論する場です。進捗を追跡するために四半期レトロスペクティブ Issue を使用しています。こちらからアクセスできます。

いつ: 四半期の第 12 週、50 分

内容:

• 何がうまくいったか、何を改善できるかを議論する。
• プロセス変更などをコミュニケーションする。

FAQ:

イテレーションボード

イテレーションの長さはどのくらいですか？

イテレーションは 2 週間で、月曜日から翌々週の木曜日までです。

イテレーションボードはどこで見つけられますか？

イテレーションボードは チームレベル と個人レベルで作成されます:

Digital Experience > Issues - Boards で、ドロップダウンリストから個人名またはグループを選択します。

イテレーションボードは何のために使うのですか？

イテレーションボードは、チームが何に取り組んでいるかの概観と、チームがイテレーション内でどれくらいの量を生み出せるかの大まかな目安を提供するためのものです。

Issue を最初から最後まで動かすにはどうすればよいですか？

イテレーションの開始時、すべての Issue は dex-status::todo ラベルが付いています。Issue が進行するにつれて、dex-status ラベルを更新する必要があります。これは（個人ボード上で）カラム間でドラッグするか、Issue 上で dex-status ラベルを手動変更することで可能です。

イテレーションボードを完了できなかった場合は？

ストレスを感じる必要はありません。ウェイトポイントは見積もりであり、予期せぬ事象は起こります。残った作業は次のイテレーションに繰り越せます。

イテレーションボードを早く終えた場合は？

個人のイテレーションボードが完了した場合の選択肢は次のとおりです:

1. 他のチームメンバーをサポートする。
2. バックログから新しい Issue を引き出して現在のイテレーションに入れる。
3. スキルやツールを磨く。
4. 全般的なハウスキーピング。

ウェイトポイント

ウェイトポイントとは何ですか？

ウェイトポイントは、Issue 完了に必要な作業量の大まかな見積もりに使用される測定単位です。1 ウェイトポイントは 0.5 日として測定されます。

Issue は何ウェイトポイントにすべきですか？

推奨される作業期間は 2〜4 ウェイトポイント（1〜2 日）の間です。例外もありますが、Issue をより小さな作業単位に分割することが推奨されます。小さな作業単位は、レビューサイクルを早め、コラボレーションを促進します。

エンジニアは 1 イテレーションあたり何ウェイトポイント完了させるべきですか？

エンジニアは 1 イテレーションあたり 12 ウェイトポイント以上、つまり 6 日分のエンジニアリング作業を完了することが期待されます。これは、マージリクエストレビューや、Frontend Engineer および Fullstack Engineer のジョブファミリーに記述されている職務要件のための余地を残しています。シニアエンジニアの場合、期待値は 15 ポイント以上です。

Issue

イテレーションの途中で新しい Issue が割り当てられた場合はどうすればよいですか？

通常、イテレーション中に Issue が追加される場合は優先度が高いものです。同量のウェイトポイント分、自分のイテレーションから取り除いてスペースを作るために、チームと連携することが推奨されます。これらの取り除かれた Issue はバックログに戻すべきです。

ラベルを追加する必要はありますか？

イテレーションに入る前に、Issue は適切なラベルですでにリファインメントされているはずです。変わるラベルは dex-status ラベルのみです（Issue が始まりから終わりへ進むにつれて）。

コンテンツ／データ収集のためにクローズできない Issue が割り当てられた場合は？

残念ながら、イテレーション内で解決できないエッジケースの Issue は常に存在します。繰り越し量を緩和するためには、Issue をより小さなチャンクに分割することが推奨されます。

例 A: コンテンツ／アセットを待っている間に Issue が開いている場合、コンテンツ／アセット収集用の Issue を作成し、元の Issue をクローズすることが望ましいです。

例 B: AB テストからのデータ収集を待っている間に Issue が開いている場合、情報収集を開始する Issue と、最後にデータを分析する Issue を作成するのが望ましいでしょう。

ウィークリーチェックイン

私たちは Geekbot を使い、イテレーション進捗の非同期な週次チェックインを実施しています。

Digital Experience チームの各メンバーは、ウィークリーチェックインの参加者として登録されているべきで、誰もが当チームのアプリケーションを管理できる権限を持つべきです。アプリは Geekbot ダッシュボード から設定できます。直接アクセスするか、Slack の Geekbot 会話をクリックして About タブに移動し、App Homepage をクリックすることで見つかります。

Production Change Lock (PCL)

エンジニアリング部門 と同様に、チームの可用性が下がったり、（注目度の高い公開イベント中など）非定型なユーザー行動が予想されたりする際には、About.gitlab.com リポジトリへの本番変更を一時的に停止することがあります。

これらの期間中に本番環境を変更するリスクには、即時の顧客影響、および／またはインシデント発生時のエンジニアリングチームの可用性低下が含まれます。そのため、Production Change Lock (PCL) というメカニズムを導入しました。チームが PCL 期間を認識できるよう、ここにイベントを掲載しています。

以下が現在スケジュールされている PCL 期間です。下記の日付の時間は 09:00 UTC に始まり、翌日 09:00 UTC に終わります。

PCL 期間中は、マージリクエストとデプロイは、シニアチームメンバー、マネージャー、および当チームより上位のマネジメントレベルのメンバーのみが実施できます。

Figma プロセス

• Figma の使い方

GitLab 製品プロセス

私たちのチームは時折、GitLab 製品 でのコラボレーションを必要とする目標を持ちます。エンジニアのオンボーディングプロセスについて詳しくはこちら

リリースポストスケジュール中の特例: リリースポスト の日には、www-gitlab-com リポジトリへの変更を控えます。リリースポストプロセスは別チームが担当しており、毎月のリリースケイデンス周辺で依存関係や CI/CD などの大きな変更をリリースすると、彼らの作業に支障をきたす可能性があるためです。

リポジトリ健全性への貢献

各イテレーションサイクルの最後に、Digital Experience チームのメンバーは 1 日を使って、about.gitlab.com の健全性、開発者体験の改善、技術的負債への対処、ドキュメント改善に関する Issue に取り組めます。

リポジトリ健全性日のしくみは次のとおりです:

1. チームメンバーは、その日に取り組みたいことを選びます。
2. 各チームメンバーは、リポジトリ健全性日の終わりまでに Slippers Design System、Navigation、または About.gitlab.com リポジトリにマージリクエストを 1 件提出します。
3. このマージリクエストは、GitLab 内のあらゆるパートナーやグループの Issue に関連付けられます。

私たちのチームメンバーがリポジトリの健全性に 1 日貢献することで、私たちのチーム、パートナー、マーケティングサイト全体に成果をもたらす低工数・高インパクトのソリューションを生み出せます。これにより Digital Experience チームメンバーが、自身の強みを活かして https://about.gitlab.com/ に効率的に成果を出せるようになります。私たちは皆、得意なことが異なり、異なる背景を持っています。これを活かし、毎日それを使うチームメンバーを包摂する、より良いテックスタックを構築しましょう。

アナリティクス

Digital Experience のアナリティクスリクエストには、Marketing Strategy and Analytics プロジェクトで dex_analytics_request テンプレートを使って Issue を作成し、具体的な要件を整理してください。スムーズなマイルストーン計画のために、可能な限り 1 週間以上前に @dennischarukulvanich に Issue をアサインしてください。

Sales シャドウイング

Sales シャドウイングを設定する方法

SMB

1. Sales Development Manager（Jonathan Rivat）または Director of Sales Dev Operations（Ramona Elliott）に連絡します。
2. どのチームから来たのか、また実際の GitLab 見込み顧客と Sales チームのやり取りを観察してシャドウしたい目的を伝えます（例: 潜在顧客が Sales チームと議論したい一般的なトピックを学ぶため）。
3. Sales Development Manager または Director, Sales Development に、シャドウしたい回数とおおよそのタイムラインを伝えます。
4. Sales Development Manager または Director, Sales Development が Sales Development Reps（SDR）に連絡し、SDR が Account Executive（AE）との今後のディスカバリーコールに参加させてくれます。
5. 招待を承諾し、提供される資料を確認してカレンダーに追加します。
6. コールに参加する際は、次のことを覚えておきましょう:
   1. あなたは観察するためにそこにいます。自己紹介を求められたら、ミュートを解除して紹介し、再度ミュートに戻して Sales チームに任せます。
   2. カメラはオンにしておきます。
   3. メモドキュメントを準備し、観察と気づきをメモします。
7. コール後、メモを確認し、整理してアクションアイテムを作成します。
8. ホストしてくれた Sales チームメンバーに感謝メッセージを送ります。
9. すべてのシャドウが完了したら、メモと気づきをチームと共有します。

チームのシャドウイングへの期待

顧客に最も近い者が勝つ。これを念頭に、Digital Experience チームは Sales コールを定期的にシャドウすることが期待されています。

お問い合わせ

Slack グループ

@digital-experience をどのチャンネルでも使うと、私たちのチーム全員にメンションできます。

Slack チャンネル

#digital-experience-team

Slack アプリケーション

私たちは Dex Bot という Slack アプリケーションを作成しており、重要な CMS 変更をチームに通知しています。詳しくはこちらをご覧ください

GitLab Unfiltered プレイリスト

YouTube で私たちのチームの活動を見られます！

Digital Experience

サポートのリクエスト

私たちが行わないこと

1. コンテンツの変更、更新、またはコンテンツの移動。これらは リポジトリ でページを編集するか、about.gitlab.com の任意のページの下部にある「Edit this page」をクリックして自分で行えます:
   1. 新規または更新ページをリクエストする場合、Issue を提出してください（/handbook/marketing/digital-experience/#issue-template-to-submit-an-idea-to-drive-our-business-goals）
2. コンテンツの作成。このニーズには、優れた Global Content チーム と協業できます。
3. ブランド資産、カスタムグラフィック、イラストの作成。私たちの Brand デザインチーム はこれが非常に得意なので、ぜひ彼らの専門性を活用してください。

ビジネス目標達成のためのアイデアを提出する Issue テンプレート

私たちは、ノーススターと支援指標に資する作業でのコラボレーションが大好きです。アイデア、戦略的イニシアチブ、または OKR について私たちのサポートが必要な場合、コラボレーションを開始する方法は次のとおりです:

1. Issue が優先される確率を高める事前作業に関連する FAQ セクションをレビューします。
2. このテンプレート を使って Issue を作成します。

プラットフォームアクセスを持つ DEX チームメンバー

マーケティングサイトのデプロイプロセス

私たちがオーナーであるリポジトリのうち、Buyer Experience リポジトリと GitLab Blog は、ビルド済みファイルを www-gitlab-com と同じ GCP バケットにプッシュします。これらのプロジェクトのいずれかで（マージや webhook によって）パイプラインがトリガーされると、そのリポジトリ固有のデプロイジョブが走り、ビルド済みファイルをバケットにプッシュして既存ファイルとマージします。このプロセスは、各リポジトリ内の Deploy.sh ファイルによって管理されます:

• WWW Deploy ファイル
• BE Deploy ファイル
• GitLab Blog Deploy ファイル

バケットをクリーンに保つために、これらのリポジトリで delete フラグ付きのスケジュールパイプラインを実行し、クラウドバケットから古くなったファイル（マーケティングサイトから削除されたページや古い JS バンドルなど）を削除しています。

• WWW クリーンアップロジック
• GitLab Blog クリーンアップロジック

BE ファイルの削除は、同じ WWW delete ジョブで BE リポジトリから最新のビルド成果物を取得する ことによって処理されます。

Digital Experience FAQ

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