People コミュニケーション＆チームメンバーエンゲージメント

はじめに

「社内コミュニケーション」は、会社のすべてと全員を同じ方向に前進させ続ける結合組織です。それは広範な用語であり、すべてのチームが何らかの形で貢献している私たちの文化の一側面です。

People Communications & Engagement チームは、説得力のある社内ストーリーテリングとタイムリーな情報共有を通じてチームメンバーに情報を提供しエンゲージメントを高め、チームメンバーが GitLab のアンバサダーになれるよう支援することを目指しています。

このページでは、私たちの People Communications & Engagement チームが、GitLab のチームメンバーと GitLab 内のさまざまなクロスファンクショナルチームを支援するためにどのように運営されているかを定義します。

指針となる原則

• 👁 信頼でき、透明で、オープンで、誠実であること
• 🤝 コンテキスト、理由、コールトゥアクションを提供すること。
• 📈 提供、頻度、トーンに一貫性を持たせること。
• ⏱ 人々の時間と注意を尊重すること。

People コミュニケーション＆エンゲージメントの目的

• 説得力のあるストーリーテリングとタイムリーな情報共有を通じて、チームメンバーのエンゲージメントと会社へのアドボカシーを高める
• ビジネスのアップデートを私たちのバリュー、ミッション、パーパスと結びつけることで、チームメンバーが私たちのタレントブランドのアドボケイトになれるよう支援する
• チームメンバーが情報を探す場所で出会えるよう、さまざまなタッチポイントを作成してチームメンバーのエンゲージメントを促進する
• クロスファンクショナルなチェンジマネジメントプロセスに運用上の厳密さを浸透させる
• リーダーとチームメンバーの間の信頼とつながりを高める

GitLab のチームメンバーは、私たちの Engagement Strategy presentation を確認することで、コミュニケーションとエンゲージメントがどのように連携するかをより深く理解できます。

People コミュニケーション＆エンゲージメントとの協業

世界中の GitLab チームメンバーに伝える必要のある情報の量を考えると、チームメンバーが GitLab 全体で起きていることの全体像を把握できるよう、コミュニケーション＆エンゲージメントに対して構造化されたアプローチを取ることが重要です。

私たちの People Communications & Engagement チームがクロスファンクショナルなプロジェクトを支援できる方法は、ニーズに応じていくつかあります。次のとおりです。

特定のプロジェクトに必要な支援レベルに応じて、People Communications & Engagement チームからその作業にアサインされた人が、プロセス、使用される標準テンプレートやプラクティスについてアドバイスし、GitLab でのコミュニケーションのベストプラクティスを提案できます。

すべてのチームメンバーと共有する重要なメッセージを準備する際にコミュニケーションをリードするためコミュニケーションを依頼する場合は、すべての部門に次のプロセスに従うようお願いします。

1. 内部コミュニケーションサポートリクエストテンプレート をできる限り完全に記入してコミュニケーション支援の必要性を共有し、私たちの People Communications & Engagement チームのメンバーにその必要性を伝えます。
   • これらの依頼は #internal-communications-requests チャンネルを使って Slack で共有できます。または、機密性が懸念される場合は、次の人に直接連絡してください。
   • Devin Rogozinski, Senior Director, People Strategy & Engagement
2. プロジェクトブリーフを受け取った後、私たちの People Communications & Engagement チームは #comms-asks チャンネルでその必要性を周知し、People Communications & Engagement チームまたはより広範な talent & engagement チームから誰がそのプロジェクトの DRI またはパートナーになるかを決定します。
3. リリースのタイミング、頻度、適切なチャンネルを含むコミュニケーション計画を策定します。
   1. 単一のメッセージの共有を計画するには、少なくとも約 48 時間前の通知が必要です
   2. より複雑な社内コミュニケーションの依頼については、コミュニケーション計画について効果的に協働するため、少なくとも約 7 〜 10 営業日前の通知をお願いします。コミュニケーションの範囲と適時性に応じて、より計画的に進めることを選択します。
4. このプロセスを迅速化するために、このテンプレートを使用して初期のコミュニケーション計画を作成できます。
   1. 初期のコミュニケーション計画を作成したら、#internal-communications-requests チャンネルを使って Slack で People Communications & Engagement チームと共有してください。または、機密性が懸念される場合は、次の人に直接連絡してください。
      • Devin Rogozinski, Senior Director, People Strategy & Engagement

People コミュニケーション＆エンゲージメントのチャンネル

私たちは、GitLab 内のさまざまなオーディエンスとコミュニケーションを取るためにさまざまなチャンネルを使用しています。私たちが使用する主要なチャンネル、各チャンネルの目的、そして誰もが各チャンネルにどのように貢献できるかは、次のとおりです。

1. 「While You Were Iterating」ニュースレター… 月に 2 回、すべてのチームメンバーが認識すべき重要な新しいアップデートを伝えます。
   • 🤝 貢献するには: 最新のニュースレター GitLab issue にコメントを書き、@cmotes をタグ付けします。コンテンツを送る際に注意すべき点:
     • GitLab チームメンバーの 75% 以上にグローバルに関連していますか？
     • すべてのチームメンバーが知っておくべき、または対応すべきことですか？
     • 私たちの GitLab バリューと整合していますか？
     • チームメンバーのアクションが含まれていることを確認してください
     • コンテンツの 1 〜 2 文のドラフト説明を送ってください。必要に応じて、社内コミュニケーションチームの背景知識のために追加のコンテキストを含めてください。これはメッセージをレビューし確定する際に役立ちます。
2. Manager README 月次ニュースレター: ピープルマネージャーへの月次の能動的なコミュニケーションで、次を含みます。今後の予定、重要な点のリマインダー、チームメンバーへのトーキングポイントのガイダンス、取るべきアクション
   • 🤝 貢献するには: 最新のマネージャーコミュニケーション GitLab issue にコメントを書き、@cmotes をタグ付けします。コンテンツを送る際に注意すべき点:
     • GitLab のピープルマネージャーの 75% 以上にグローバルに関連していますか？
     • すべてのピープルマネージャーが知っておくべき、または対応すべきことですか？
     • 私たちの GitLab バリューと整合していますか？
     • ピープルマネージャーのアクションが含まれていることを確認してください
     • コンテンツの 1 〜 2 文のドラフト説明を送ってください。必要に応じて、社内コミュニケーションチームの背景知識のために追加のコンテキストを含めてください。これはメッセージをレビューし確定する際に役立ちます。
3. 全チームメンバー向け Slack チャンネル（#company-fyi および #company-fyi-private）: すべてのチームメンバーへのタイムリーで重要かつアクション志向の重要なアップデート
   • 🤝 貢献するには: 内部コミュニケーションの階層システム を読み、あなたのメッセージが #company-fyi または #company-fyi-private のメッセージを示す Tier 1a/1b に該当するかどうかを判断します。該当する場合は、内部コミュニケーションサポートリクエストテンプレート のコピーを作成して記入し、#internal-communications-requests チャンネルを使って Slack で共有してください。または、機密性が懸念される場合は、@devinrogo に直接連絡してください。
4. GitLab Handbook: 恒久的で機密性のないアップデートについては、情報が GitLab Handbook にどのように存在すべきかを検討します。
5. GitLab Assembly: GitLab のリーダーから話を聞き、チームメンバーの質問に答える全社的な同期型の時間
   • 🤝 貢献するには: コンテンツ作成は People Comms & Engagement チームが決定し、E-Group のメンバーがレビューします。

GitLab Assembly

GitLab Assembly は私たちの四半期ごとの全社ミーティングであり、チームメンバーが会社全体のリーダーやチームから話を聞く機会です。Assembly は、最優先事項、顧客のストーリーやデータ、クロスコラボレーション、部門の詳細な掘り下げ、その他のチームメンバーのストーリーを総合的に提供し、チームメンバーのエンゲージメント、可視性の共有、会社のつながりを強化します。Assembly は、約 35 分のコンテンツと約 15 分の Q&A で構成される 50 分のミーティングであり、各四半期の 2 か月目の終わりまたは 3 か月目の初めに開催されるよう予定されています。グローバルのチームメンバーがライブで参加する機会を提供するため、四半期ごとに 2 回のライブ開催の Assembly イベントがあり、1 回目のイベントは通常午後 5 時 PT（午前 0 時 UTC）に、2 回目のイベントは翌日の午前 8 時 PT（午後 3 時 UTC）に予定されています。ただし、一部の四半期では両方のセッションが同じ日に行われます。

各四半期の Assembly を制作するために、People Communications & Engagement の DRI は次を行います。

1. EBA チームと協力して 6 〜 8 週間前に日程を調整する
2. ライブイベント制作のために制作パートナーを起用する
   • 制作パートナーと進行表（run of show）について協働する
   • 制作パートナーと事前収録について調整する
   • Assembly に向けた 6 週間、毎週制作パートナーと会う
3. アジェンダを作成し、Assembly の 3 〜 4 週間前にすべてのチームメンバーに Assembly のカレンダー招待を送る
4. 両方の Assembly イベントの前に質問の受付を開始するため、Slido でイベントを作成する
5. 関心の高いトピックについて Functional Leader と連携し、ホスト、スピーカー、セグメントを提案する
6. 提案されたホストとトピックについて People Leadership のレビューと承認を促進・確保する
7. CoS と CoS チームと協力して次を行う:
   • CEO プレゼンテーションの詳細を決定する
   • CEO のキーメッセージと提示するテーマについて合意する
   • CEO とのフィードバックセッションを調整し参加する
8. ホストや追加のスピーカーとそのプレゼンテーションについて連携する
   • プレゼンテーションの詳細を決定する
   • コンテンツのドラフトを作成する、または必要に応じてコンテンツのドラフト作成を追加のチームメンバーに委任する
9. Assembly のプレゼンテーションデッキについて制作パートナーと連携し、次を確保する:
   • People Leadership のレビュー
   • Marketing と Design のレビュー
10. 事前収録されたビデオコンテンツの編集のためのリソースを確保するため、社内の Digital Production チームと制作パートナーと連携する
11. CEO プレゼンテーションを収録し、その他の事前収録コンテンツの収録を促進する
    • Digital Production チームが必要に応じてアクセスできるよう Google Drive にアップロードする
    • Digital Production チームのためにビデオのタイムスタンプ遷移を追加する
12. 次の者によるビデオコンテンツと Assembly プレゼンテーションデッキの最終レビューと承認を促進・確保する:
    • ホストとスピーカー
    • People Leadership
    • Legal
13. 制作会社、ホスト、ライブスピーカーのための最終技術チェック／ドレスリハーサルを促進する

Assembly 当日:

1. Assembly のホスト、スピーカー、E-Group は、イベント 1 はイベント開始時刻の 15 分前に、イベント 2 はイベント開始時刻の 5 分前に、全チームメンバー向けの Zoom に配信される別のスピーカー Zoom に参加します。
   • スピーカーは、ミーティングの全時間を通じてカメラをオンにし、マイクをミュート（話す時間まで）にするようお願いされます。彼らが常に表示されるわけではありませんが、スピーカー Zoom でカメラのオン・オフを切り替えるとライブ制作に影響する可能性があります。
   • スピーカーと制作チームは、People Communications & Engagement チームの 1 名とともにスピーカー Zoom に参加します。
2. People Comms & Engagement の DRI は、チームメンバーのニーズに対応するために全チームメンバー向けの Zoom に参加します。制作会社がイベントのカウントダウンを配信し、待機室を運営します。
   • この Zoom のチャットは参照用にバックアップされます。
3. 各イベント開始時、カウントダウンが完了するとホストがミーティングのリードを開始し、イベントの進行表に沿って進めます。
4. チームメンバーは Slido イベントに質問を送信し、回答してほしい質問にアップボートすることが推奨されます。
5. Q&A では、ホストがアップボート順に質問を読み上げます。
6. E-Group は Q&A ドキュメントで協働し、各質問に誰が回答するかを調整します。
7. アサインされた書記が、アジェンダドキュメントに直接 Q&A を記録します。

2 回目の Assembly イベントの後:

1. 制作パートナーが両方の Assembly イベントの録画を People Comms & Engagement の DRI と共有します。
2. People Comms & Engagement の DRI が、Level Up にアップロードするために Learning and Development チームと Assembly の録画を共有します。
3. Level Up にアップロードされたら、People Comms & Engagement の DRI が、全社ニュースレター While You Were Iterating の次の号で、最終的な録画と必要なフォローアップをすべてのチームメンバーと共有します。
4. People Comms & Engagement の DRI／チームは、Assembly 後にチームメンバー、People Leadership、E-Group からフィードバックを求めます。

People コミュニケーション＆エンゲージメントの計画

私たちは、会社全体の主要な発表、キャンペーン、イベントを含む社内コミュニケーションの編集カレンダー（小規模な社内グループに限定して機密）を運用しています。このリストに追加されるには、内部コミュニケーションの階層システム を確認して、あなたのメッセージが #company-fyi または #company-fyi-private のメッセージを示す Tier 1a/1b に該当するかどうかを判断してください。該当する場合は、内部コミュニケーションサポートリクエストテンプレート のコピーを作成して記入し、#internal-communications-requests チャンネルを使って Slack で共有してください。または、機密性が懸念される場合は、@kaylagolden に直接連絡してください。

複数のチャンネル全体での大規模コミュニケーション＆エンゲージメントの取り組みの計画

さまざまなメッセージや社内キャンペーンのタイミング、そしてしっかりとした計画を持つことが、コミュニケーション成功の鍵です。成長モードにある会社として、変化は絶え間なく、チームメンバーと共有する必要のあることがたくさんあります。

私たちはリーンなチームとして運営しており、限られたバンド幅のため、すべてのコミュニケーションを完全に対応することはできません。私たちがどのように、どのようなタイプのコミュニケーションを支援できるかを理解するために、内部コミュニケーションの階層システムを確認してください。

GitLab チームメンバーの関与と情報提供におけるあなたの役割

GitLab のチームメンバーのエンゲージメントを維持し情報を提供し続ける上で、誰もが役割を担っています。People Communications & Engagement チームと協働する場合は、次のベストプラクティスを念頭に置いてください。

• 📈 自分の専門知識にオーナーシップを持つ: チームメンバーに何かを伝えるよう依頼する場合、その変更に関するあなたの専門知識が鍵となる可能性が高く、特定の変更についてできる限り多くを共有することが役立ちます。
• 🤝 効果的にフィードバックを行い、ポジティブな意図を前提とする: 非同期での協働は、整合に至るまでに何度かのやり取りを必要とすることがあり、それは想定内のことです。
• 👣 期限を設定し、イテレーションを受け入れる: いつ何かが必要なのか、または特定の作業に別の優先順位があるのかを理解することは、優先順位付けに役立ちます。
• 👁 何をだけでなく、なぜを伝える: フィードバックを行う場合でも、必要性をブリーフィングする場合でも、できる限り多くの「なぜ」を加えてください。

GitLab 内のさまざまなグループへの情報のカスケード

すべてのチームメンバーと情報を共有する前に、その情報が GitLab 内のさまざまなサブグループにどのように受け取られるかを検討することが重要です。重大な変更が導入される場合、典型的な情報のカスケードは、さまざまなチャンネルを通過することになるでしょう。

たとえば、大きくてワクワクする新しいプログラム を発表する場合、次のように情報をカスケードするかもしれません。

1. E-group がインプットとフィードバックを提供する
2. People Group がチームメンバーの質問に備えて計画できるよう可視性を提供する
3. マネージャーが情報を受け取り、消化する時間を確保する（#people-managers-and-above および Manager README）
4. チームメンバー全員が、すでに変更について十分に理解しているマネージャーやリーダーとともに情報を受け取る（#company-fyi または #company-fyi-private、および「While You Were Iterating…」ニュースレター）

情報のカスケードは透明性に欠けると見なされる可能性があることに注意することが重要です。そうではなく、むしろマネージャーやリーダーが主要な変更を十分な時間をかけて理解し、その後チームの質問に答える機会を持つことで、人々により多くの情報を提供できるようにするものです。

議論を呼ぶ内部発表のためのランブック

チームメンバー間で激しい議論や意見の相違につながる可能性のある社内発表のためのランブックがあります。次のステップが含まれます。

1. DRI が @devinrogo に全社的なコミュニケーションの必要性があることを伝えます。DRI は、この社内コミュニケーション発表テンプレートを使ってコミュニケーションのドラフトを作成する責任を負います。これには、少なくとも次が含まれます。
   1. 投稿の責任者
   2. メッセージが共有される場所
   3. メッセージが最適に共有されるタイミング
   4. 伝えるべき主要メッセージとメッセージの内容
   5. 主要な参加者とその責任を含む活動とコミュニケーションのタイムライン。最初のコミュニケーションの後、数分、数時間、数週間に計画されたフォローアップを明記します。これには次が含まれるべきです。
      1. 調整されたリーダーシップの参加を含め、発表直後に Slack やその他のチャンネルで対応するために待機する人。E-Group のメンバーや、しばしば VP-Directs Group のメンバーを含む主要リーダーは、発表がいつ行われるか、そして彼らに対する対応の期待を認識しておくべきです。たとえば、議論を呼ぶ Slack 発表がある場合、指定されたグループがスレッドを監視し、発表直後に対応するべきです。
      2. AMA、その他の指定された議論やフォローアップコミュニケーションの計画
   6. メッセージと計画について承認が必要な人
   7. 承認の望ましいタイムライン
2. DRI は、ドラフトのコミュニケーションを Executive Sponsor やその他の主要なシニアステークホルダーと共有します。SAFE に共有できる内容について疑問がある場合は、CLO またはその他の法務担当者をレビューに含めるべきです。
3. この種の計画されたコミュニケーションについては、コミュニケーション計画で特定された各チームの適切なステークホルダーとともに、legal と corporate comms の両方もレビューするべきです。
4. Executive Sponsor と主要ステークホルダーがコミュニケーションと計画について合意したら、それを #e-group-confidential または E-Group Weekly のディスカッション項目として E-Group 全体と共有するべきです。計画のフィードバックを取り入れるべきです。
5. 該当する場合、計画が E-Group のレビューを通過したら、B.V. Netherlands Works Council およびレビュー権を持つその他の評議会と共有するべきです。可能な場合は、レビューとフィードバックのための十分な時間を確保するため、計画された発表の少なくとも 2 週間前にこれを行うべきです。
6. 可能な場合は、（より広範な発表の 1 〜 2 日前に）事前にマネージャーと共有し、チームへのフォローアップで支援を求めます。私たちは、彼らにどのように支援を期待するか（質問への回答、情報のカスケードなど）を明確にするべきです。
   1. マネージャーコミュニティと発表を共有する際、より広範なチームメンバーコミュニティと MR を共有する前に変更や明確化を可能にするため、MR をドキュメント形式でステージングする場合があります。
7. 投稿にマージリクエスト（MR）が含まれる場合、投稿する前に MR のベストプラクティスに従っていることを確認するべきです。
   1. MR はすでにマージされているべきではありません。チームメンバーは変更についてフィードバックを共有するよう招かれ、意図されたマージのタイムラインを明確にされるべきです。
   2. コンテンツの削除と追加に別々の MR を使用するべきではありません。これはチームメンバーが変更を追跡することを難しくします。
8. コミュニケーションが共有された後、Executive Sponsor と指定されたチームが同期的に集まり、フィードバックをレビューし、（合意された場合）対応するためのプレースホルダーを設けるべきです。コミュニケーションの 25 〜 50 分後にカレンダーホールドを設定するべきです。
9. 同様の Executive Sponsor と指定されたチームのチェックインを翌日にスケジュールするべきです。このミーティングは、必要ないと合意された場合はキャンセルできます。
10. チームメンバーとの AMA やその他の同期的なタッチポイントがある場合、Executive Sponsor または指定されたチームメンバーは、参加者がそれぞれの役割とコミュニケーション計画について整合できるよう、セッションの直前（最適には 1 〜 2 時間前）にミーティングをスケジュールすることを選択できます。

このランブックは、従うべき主要なステップを概説しています。コミュニケーションと必要な調整のレベルに基づいて、追加のステップが加えられる場合があります。

リソースと便利なリンク

• 内部コミュニケーションサポートリクエストテンプレート
• 内部コミュニケーションの階層システム
• GitLab のコミュニケーション

続きはこれから

People Communications & Engagement 機能を成長させ続けるにつれて、このページにより詳細な情報を追加していきます。このページへの編集を提案するか、Slack の #talent-brand-engagement チャンネルで連絡することで、フィードバックをお寄せください。

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