Developer Relations のイベント

イベントは、GitLab と Developer Relations チームが顧客や広範な GitLab コミュニティとつながるための優れた手段です。

イベントの種類

Developer Relations チームは、以下の種類のイベントに定期的に参加しています。

  • コミュニティイベント
  • コーポレートマーケティングイベント
  • フィールドマーケティングイベント

コミュニティイベント

GitLab の Developer Relations チームは、GitLab ハッカソン や コミュニティオフィスアワー を含むバーチャルイベントを定期的に開催しています。 また、対面のコントリビューターデーや コミュニティ主催のミートアップ もサポートしています。これらの活動の多くは、Meetup 上の GitLab ネットワーク ページを通じて運営されています。

コーポレートマーケティングイベント

コーポレートイベントには、KubeCon や AWS Re:Invent のような大規模な参加者を集めるカンファレンス、ユーザーカンファレンス（DevSecOps World Tour）、社内カンファレンス（GitLab Summit）などが含まれます。

コーポレートマーケティングイベントについて詳しくは、GitLab ハンドブックの「コーポレートイベントマーケティング」ページ をご覧ください。

フィールドマーケティングイベント

フィールドマーケティングイベントは、対面およびバーチャルでのインタラクションを通じて、地域レベルで Large、Mid-Market、Public Sector の go-to-market チームを戦略的に支援するイベントです。

フィールドマーケティングイベントについて詳しくは、GitLab ハンドブックのフィールドマーケティングページ をご覧ください。

イベント参加の評価基準

Developer Relations が対面イベントをどのようにサポートするかを判断する際、以下の基準を使用します。

  1. イベントが Tier 1 または Tier 2 の国で開催されること。 Tier の詳細は 社内ハンドブック に記載されています。
  2. 参加者が 1,000 人以上で、内容と聴衆のフォーカスが社内ハンドブックに詳述されている GitLab のマーケティング戦略 と一致していること。
  3. GitLab がスポンサーであること。

Developer Relations チームは、これらの基準のうち少なくとも 2 つを満たすイベントを優先します。ただし、これらの基準を満たすすべてのイベントをサポートできるとは限りません。これらの基準を満たさないイベントについても、参加する説得力のあるビジネス上の理由がある場合は検討します（例：優先市場における 500 人規模のイベントでの基調講演の機会）。

チームメンバーの出張と時間を効果的に管理するため、以下の基準を使って対面イベントへの参加優先度を決めています。

  1. チームメンバーは、PTO を予定している期間中はイベントに参加しません。
  2. イベントの開催地域に居住するチームメンバーが、可能な限り優先されます。
  3. チームメンバーは、月に 1 回を超える対面イベントには参加しません。
  4. チームメンバーは、四半期に 1 回を超える地域外の対面イベントには参加しません。
  5. いかなるイベントにも、Developer Relations チームから 2 名を超えて参加することはありません。

注: バーチャルイベントについては、必要な時間と移動が少ないため、ケースバイケースで機会を評価します。

パートナーおよびコミュニティイベントの評価基準

パートナーや広範な GitLab コミュニティのメンバーが主催するイベントについて、GitLab チームメンバーが参加するためには、主催者が以下を提供することを条件としています。

  1. 登録ページ。イベントの 4 週間前までに公開され、スピーカーと共有されること
  2. イベントの 1 週間前までに登録状況の更新を提供すること
  3. すべての参加者にとって安全な環境を確保するため、強制力のある公開された行動規範があること。必要であれば、イベント主催者は GitLab の コミュニティ行動規範 を使用していただいて構いません。

これらのステップにより、イベントの準備と参加にかかる時間とコストを正当化するだけの十分な聴衆が確保されることを担保します。

イベントコンテンツの作成

Developer Advocate チームは、イベント用のコンテンツを作成しています。これには Call for Paper（CFP）の応募プロセス の管理、プレゼンテーション、デモ、ライトニングトーク、その他のコンテンツの制作が含まれます。

スピーカーとしての登壇機会についてサポートを求める GitLab チームメンバーは、ハンドブックの Speaking Resources を確認してください。このページには、GitLab スピーカーが参加するためにイベントが満たすべき要件を含む、チームメンバーの承認取得プロセスが記載されています。

イベントレポート

Developer Relations がイベントレポートを必要とする理由

イベントレポートは、Developer Relations チームの戦略的成功にとって不可欠です。

  • データ駆動の意思決定: ROI とパフォーマンスを測定し、将来のイベント投資を最適化し、予算配分を正当化する
  • プロダクトインテリジェンス: 開発者と顧客のフィードバック、ペインポイント、機能要望を収集し、製品ロードマップの意思決定に直接反映する
  • クロスチームの価値: 営業には適格なリードを、マーケティングには市場の洞察を、リーダーシップにはコミュニティの知見を提供する
  • 継続的な改善: 何が機能したかをドキュメント化し、組織の知識を保存し、成功した戦略を他のイベントにも横展開する

イベントレポートの作成方法

イベントレポートは Google Slides を使って作成し、イベント終了後 2 週間以内 に完成させる必要があります。レポートは Developer Relations チームの共有 Google Drive 内、events > devrel-event-reports に整理されます。このフォルダはすべてのチームメンバーと共有されています。

レポートの作成

  1. テンプレートを探す: トップレベルフォルダ内のイベントレポート用テンプレート: TEMPLATE: DevRel & Strategy event report: [EVENTNAME YEAR]

  2. テンプレートのコピーを作成 し、命名規則に従ってリネーム: DevRel & Strategy Event Report: [EVENT NAME YEAR]

  3. レポートの各セクションを記入 し、包括的なイベントデータを含める:

    • イベント結果: 参加者数、エンゲージメント指標、ブースのトラフィック、デモのリクエスト
    • 顧客の学び: 開発者との会話やフィードバックから得られた重要な洞察
    • 製品フィードバック: 機能要望、ペインポイント、改善提案
    • フィールドの洞察: 市場動向、競合インテリジェンス、コミュニティの感情
    • リードの質: 適格な見込み客とフォローアップの機会

    注: テンプレートは、聴衆やフォーカスがイベントによって異なるため、オプションのセクションを提供しています。構造は自由に変更できますが、イベント概要とエグゼクティブサマリーは最初のスライドに残してください。

配布とフォローアップ

  1. イベント追跡へのリンク: 完成したレポートを、各会計年度のイベント戦略エピック 内の対応するイベントエピックまたは Issue に追加します。

  2. オプション: 読み上げ録画の作成: イベントレポートの読み上げ録画を作成し、音声・映像での要約を好むステークホルダー向けに同じ GDrive フォルダにアップロードします。

  3. Slack で結果を共有: #developer-relations または #whats-happening-at-gitlab に以下を含むアップデートを投稿:

    • 主要指標（参加者数、獲得リード、実施したデモ）
    • 上位 2〜3 件の洞察や学び
    • 完全なレポートへのリンク

  4. 週次アップデートに追加: リーダーシップに見えるよう、DevRel & Strategy の週末アップデートドキュメントにイベントレポートを含めます。

サポートが必要なときは

質問、テンプレートのアクセス問題、このプロセスへの貢献については、DRI である @dnsmichi に連絡してください。

イベントコンテンツ

Developer Advocate チームは、イベント向けコンテンツの作成において重要な役割を担っています。私たちが作成するコンテンツには以下が含まれます。

  • ライトニングトーク
  • デモ
  • イベントブーストレーニング
  • イベントプレゼンテーション
  • コードチャレンジ

注: 作成されるコンテンツの種類は、サポートするイベントによって異なります。

ライトニングトーク

Developer Relations チームのメンバーは、イベントでライトニングトークを行うことで参加します。セッションの長さは、イベントの要件に応じて短いもの（5 分）から長いもの（20 分）まであります。チームメンバー、GitLab パートナー、広範なコミュニティメンバーがライトニングトークを発表します。

トピックは、インフォーマルなものから技術的・文化的な洞察まで多岐にわたり、時間が許せばライブデモで内容を充実させることもあります。トピックは、コーポレートイベントチーム と協力して、ライトニングトーク CFP を通じて方向性を合わせています。例として KubeCon NA 2023（社内） があります。

ライトニングトークの推奨構成は以下のとおりです。

  • イントロダクション（1 分）: トピックと参加者にもたらす価値を紹介
  • 発表者について（1 分）: 自己紹介、役職、ソーシャルメディアのハンドル
  • メインコンテンツ（13 分）: メインのプレゼンテーション
  • 質疑応答（5 分）: 最後にユーザーの質問に答える時間を確保

注: 参加者にプレゼンテーションの PDF をダウンロードできるリンクを提供することで、プレゼン終了後も聴衆が GitLab とのつながりを維持し、リソースを集めることができます。関連リンクを示す QR コードを含めることも強く推奨されます。

ライトニングトークの内容は、イベントのテーマと関連している必要があります（例: セキュリティカンファレンスであれば、ライトニングトークは GitLab のセキュリティおよびガバナンスソリューションを中心とする）。こちら には、KubeCon EU 2023 で行われたライトニングトークの例があります。

デモ

Developer Advocate チームは、ブーススタッフが顧客に GitLab の機能を紹介する際に活用できるデモブース用アセットの提供を担っています。アセットの内容は以下のとおりです。

  • インタラクティブなウォークスルー
  • GitLab.com デモプロジェクト

注: 私たちが提供するものよりも、ご自身のデモやデッキを使うほうが快適な場合は、それでまったく問題ありません。これらのアセットは皆さんに利用していただくために提供・維持しています。

インタラクティブなウォークスルー

インタラクティブなウォークスルー（プロダクトツアーとも呼ばれる）は、主要な機能とワークフローを紹介するために設計されています。デモには Developer Advocacy コンテンツライブラリ からアクセスできます。

ブーススタッフとしてイベントに参加する場合は、プロダクトツアーに精通していることを確認してください。製品のさまざまな領域について質問が出る可能性があり、これらのデモは特定の機能を素早く効果的に紹介するための手段となります。

来場者は、ブースで見たデモを自分のチームと共有したいと希望することがよくあります。これを促進するために、デモハブで利用可能な QR コードをスキャンすれば、リンクに簡単にアクセスして後で共有できます。

ヒント: Ctrl + P を使ってダイアログを切り替えると、デモがよりスムーズに進みます。インタラクティブなポップアップに頼らず、矢印キー（→/←）でナビゲートしましょう。

GitLab.com デモプロジェクト

GitLab.com デモは、カンファレンス、セールスコール、ウェビナーなどでライブで実行できるプロジェクトです。これらは DevSecOps プラットフォーム全体を見せることも、必要に応じて個々のコンポーネントに焦点を当てることもできます。利用可能な環境は以下のとおりです。

  • Simple Notes - The Complete DevSecOps Platform Demo: このデモ環境では、CICD ファイルの設定、テンプレートの追加、セキュリティスキャンの実行、脆弱性管理など、GitLab のさまざまな側面を紹介します。また、完全な使用方法のチュートリアル も提供しています。
  • Ask Me Anything - GitLab Duo AI Demo: このデモ環境では、コード・Issue・MR の説明と要約、レビュー担当者の提案、脆弱性の説明など、さまざまな GitLab Duo の機能を紹介します。
  • GitLab Flow: このデモ環境では、計画からデプロイ（モニタリングを含む）までの GitLab フローをカバーします。Feature Flags、GA4K、Flux、Kubernetes 概要、Compliance Pipelines、Operational container scanning、GitLab Duo、CD などの GitLab 機能をカバーしています。

これらのデモ環境がニーズに合わない場合は、ユースケース別に分類された 他のデモプロジェクト を参照できます。また、他のソリューションアーキテクトが作成した、すぐ使えるセールスデモが揃った CS Shared Demo Library もあります。

Developer Advocacy が維持しているすべてのプロジェクトは プロジェクトハンドブック にドキュメント化されています。 カンファレンス固有のデモは gitlab-da/conferences グループで管理されています。

注: これらのプロジェクトを使ってデモする前に、プロジェクト自体と README に記載されている手順をよく理解しておいてください。プロジェクトはクローンして、自分のスペースで使うことを想定しています。

イベントブーストレーニング

Developer Advocate チームは、イベント前にブーススタッフへのトレーニングとガイダンスも提供しています。このトレーニングとガイダンスには以下が含まれます。

  • 利用可能なデモ環境の説明
  • デモの実施方法に関する指示
  • イベントでよく聞かれる質問のリストの提供
  • ブーススタッフからの質問への対応

前提条件: ブーススタッフとしてイベントに参加する前に、デモハブ に精通していることを確認してください。これにより、来場者の質問に応じて、さまざまな GitLab ワークフローを素早く実演し、説明できるようになります。

GitLab.com プロジェクトを使ったデモの実施方法

イベント参加者がウォークスルーデモのガイド付きフローを越えて、GitLab の動作とフローを実際に見たいと希望することがあります。以下の手順は、ライブデモを成功させ、GitLab が組織にもたらす価値を強調するためのインサイトを提供します。

注: このガイドは Simple Notes - The Complete DevSecOps Platform Demo を使用していることを前提としていますが、別のプロジェクトでも同様のデリバリーを適用できます。

  1. GitLab が最も包括的な DevSecOps プラットフォームであり、以下を実現できることを説明します:
    • 一元化された場所でアプリケーションの管理、テスト、デプロイ、セキュリティ、ガバナンスを行える
    • SDLC 全体で AI を活用してワークフローを高速化できる
  2. GitLab を使い始めるのがいかに簡単かを示すことから始めます:
    • .gitlab-ci.yml ファイルを見せ、パイプラインの定義方法を説明
      • 組み込みテンプレートを示し、それらを使ってパイプラインに自動的に異なるジョブを追加する方法を説明
    • パイプラインの実行を見せ、パイプラインがいかに拡張可能で、ルールによって自分のニーズに合わせて調整できるかを説明
      • さらに各ステージを説明し、ビルドからコンテナレジストリへのプッシュ、Kubernetes（または他のメディア）へのデプロイまでの流れを説明
  3. プラットフォームツールに進みます:
    • GitLab Issue を作成または閲覧し、アジャイルプランニングでの使い方を説明
      • Issue を素早く要約できる AI 機能を見せ、開発者がコメントの多い大きな Issue を解読する時間を節約できることを説明
    • マージリクエストを閲覧し、フィーチャーブランチからデフォルトブランチへコードを移動するものであることを説明。パイプラインが実行され、失敗するとブロックできることなどを説明
      • アクティブなセキュリティポリシーを見せ、安全でないコードが本番にマージされるのを防ぐ仕組みを説明
  4. セキュリティツールに進みます。セキュリティは GitLab Ultimate の主要な部分であり、参加者に活用してもらいたい部分です:
    • 脆弱性レポートを閲覧し、脆弱性のトリアージと管理を可能にし、セキュリティチームとのコラボレーションを実現することを説明
    • 脆弱性に深く入り、AI: Explain this Vulnerability 機能を見せ、セキュリティチームがリスクを容易に評価し修正できることを説明
  5. 最後に、これらすべての機能が GitLab Ultimate で提供されることを説明します。
  6. リードをスキャンし、関心に基づくメモを必ず追加してください。これは Salesforce に追加されます。
  7. リードに資料、名刺などを提供し、GitLab Ultimate の 30 日間無料トライアルを取得する方法を説明します。

注: これらのステップは、GitLab が価値を提供する多くの領域を紹介する一般的なデモのステップです。参加者が特定の機能について学びたい場合、GitLab プラットフォームの他の部分に進む前に、必ずその機能を最初に紹介してください。

よくある質問と回答

よくある質問とそれに対する回答は、該当するイベントの「Event Booth FAQs」Google ドキュメントに記載されています。

注: これらは各イベントで予想される一般的な質問です。ただし、イベントが特定の分野に特化している場合、その分野の特定の問題に GitLab がどう対処するかについて、より具体的な質問が予想されます。たとえば、BlackHat（セキュリティカンファレンス）では、GitLab が特定のセキュリティ問題をどのように解決するかを聞かれる可能性が高いです。これらの質問と回答は、通常、そのイベントのメッセージングドキュメントに記載されています。

イベントプレゼンテーション

イベントでの登壇は、私たちのチームが広範な GitLab コミュニティおよびテックコミュニティ全体とつながるための不可欠な道です。 チームメンバーや広範なコミュニティのメンバーのプレゼンテーションについても、私たちは喜んでサポートします。

CFP

Developer Advocate チームは、自らカンファレンスで登壇することで広範なコミュニティに直接貢献しています。 チームはまた、Issue ボードを通じて GitLab 全体のチームメンバー向けに CFP の対応とサポート、管理 を行っています。

スピーカー支援

Developer Advocacy チームは、必要に応じて新規および経験豊富なスピーカーをサポートします。これには、プレゼンテーションのレビュー、CFP のアイデア出し、ドライランセッションなどが含まれます。利用できるさまざまなリソースとアクティビティについて 詳しく知る ことができます。

コードチャレンジ

コードチャレンジは、イベント参加者が GitLab を使用したり、GitLab に直接貢献したりする方法を提供します。これらのチャレンジは、GitLab を使って特定の問題を解決するというものです。チャレンジは通常、Developer Advocate が コーポレートイベントチーム や他のチームと協力して調整するイベントで開催されます。

CodeChallenge.dev は、GitLab の機能に紐づいたチャレンジを作成するためのアプリケーションです。アプリケーションの使い方については ドキュメント を確認してください。

イベント用に新しいコードチャレンジ Issue を作成するには、コードチャレンジチェックリストテンプレート を使用してください。要件を確認し、すべてのコンポーネントが揃っていることを保証するためのガイドとして使用してください。 新しいコードチャレンジ Issue をイベントエピックに追加してください。

スポンサーシップ

GitLab の Developer Relations チームは、イベントスポンサーシップ用の予算を保有・配分していません。 すべてのイベントスポンサーシップのリクエストは、コーポレートイベント または フィールドマーケティング に送ってください。スポンサーシップ対象イベントの提案に関する判断パス に従ってください。

学生主催のハッカソン

学生のハッカソンは、GitLab に対して最も頻繁にサポートを依頼してくるイベントです。GitLab の DevOps プラットフォームをイベントで活用したいハッカソン主催者には、イベント用に無料トライアルを使用することを推奨しています。これは、ハッカソン参加者にハッカソン中に使用するための GitLab の無料トライアル を申し込むよう案内することで可能になり、GitLab のすべての機能を使用できるようになります。場合によっては、上記の 基準 を 9 点以上のスコアで満たすイベントには、参加者向けのステッカーや賞品としてのスワッグを送ることもあります。受け取るリクエストの量を考えると、これらのイベントへの金銭的支援は実現可能ではありません。

ダイバーシティ、インクルージョン、ビロンギング

このセクションは、Developer Relations チームと GitLab チームがイベントや活動を計画する際に念頭に置くべきヒントとベストプラクティスをドキュメント化することを目的としています。

イベント運営のベストプラクティス

  • ツール: 私たちは、聴衆と関わるために使用するツールについて意図的に考えています。たとえば、オープンソースの世界の一部の人々はプロプライエタリソフトウェアを使えない場合があります。また、特定の国の人々は、国の規制によって特定のツールを使えない場合もあります。事前に異なるツールオプションを含むサーベイを送ることで、特定のイベントに適したツールを特定できます。
  • タイムゾーン: できるだけ多くの異なるタイムゾーンを包含するようにしています。参加を分散させるために 4 時間のセグメントを設けることを推奨します。可能な時間帯: EMEA と NORAM 向けに 16:00 UTC〜20:00 UTC、APAC とインド向けに 02:00 UTC〜06:00 UTC。
  • 行動規範: GitLab のすべてのイベントで 行動規範 を必須としており、コミュニティの摩擦や対立に積極的に対処しています。
  • アクセシビリティ: すべてのイベントと資料におけるアクセシビリティを推進しています。
  • キャプションと通訳: オンラインイベントでは、キャプション提供者と通訳の両方を確保することが重要です。たとえば、アメリカ英語とアメリカ手話には違いがあるため、キャプションだけでは不十分です。最悪の場合のキャプション・通訳の代替として、ダイヤルイン中継サービスを利用する手もあります。これは、視覚障害のある人がビデオ電話やキャプション電話を使ってこれらのサービスにアクセスできるかどうかに依存します。
  • スライドを事前に共有する: オンラインイベントの 1 週間前にスライドを参加者と共有し、スクリーンリーダーを使う人がついていけるようにしましょう。
  • 画像には alt テキストを付ける: これは視覚障害のある人や視覚に困難のある人のためのスクリーンリーダー用です。画像の説明は記述的にしてください。最も重要なコンテンツについて数文書くと良いでしょう。
  • エディターで適切な見出しを使う: エディターの見出しを使うことで、スクリーンリーダーがページの構成を理解できるようになります。
  • トーク開始時に自分自身を記述的に紹介する: トークの導入で、視覚障害のある人や視覚に困難のある人があなたの見た目をイメージし、その姿を声と関連付けられるよう、簡単に外見を説明してください。
  • 30:5 ルールで休憩をスケジュールする: 30 分のセクションごとに 5 分の休憩を必ず入れてください。
  • インフォグラフィックを音声で説明する: アクセシビリティを支援するため、インフォグラフィックの最も重要な部分を説明してください。
  • ハイブリッドイベント: 対面イベントの隣にバーチャルオプションを提供してください。

追加リソース

イベントに関する追加情報は、GitLab ハンドブックの Events ページで確認できます。今後の GitLab イベントのリストについては、当社ウェブサイトの Events ページを参照してください。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License