ブランドクリエイティブハンドブック

GitLab ブランドクリエイティブハンドブック:

GitLab ブランドクリエイティブハンドブックへようこそ

私たちは、市場で関連性を保ち、製品の利点と品質を反映するために、ブランドのビジュアルアイデンティティデザインを発展させています。私たちは GitLab マーケティングのクリエイティブパートナーです。私たちは、高品質なブランド体験を創造し、概念化し、デザインします。

概要

目的

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

GitLab ブランドのスチュワードとして、私たちの目標は、社内外のオーディエンスに会社の活動を効果的かつ誠実に伝えるためのリソースで、より広い組織を教育し、可能にすることです。

ビジョン

どこに向かっているのか

GitLab ブランドデザインおよびビデオチームは、ロゴとビジュアルを超えてブランドを高めます。ブランド戦略と振る舞い（ブランドがどのように自分自身を提示するか、どのように知覚されるか、何が本物にするか）の専門家として自分自身を位置づけます。

ミッション

私たちが何をするか

複雑な問題を解決することで、シンプルで効果的かつ意図的なブランド体験を創造します。何を、なぜ、どのように行うかを定義し、理解しやすいメッセージを生み出します。

ブランドおよびクリエイティブサポートの依頼

クリエイティブインテイクプロセスを合理化し、チームがより効率的に作業できるようにするため、デザインおよびビデオリクエストの提出方法を更新しました。

ブランドビデオプロセスの詳細については、ブランドビデオチームのハンドブックページをご覧ください。

依頼に関するサービスレベルアグリーメント (SLA)

以下は、主要なリクエストタイプ（ブランドレビュー、デザインリクエスト、カスタムグッズ、チームエクスプレッション、ビデオリクエスト）の SLA です。

最低限のターンアラウンドタイムは、デザインを開始するために必要なすべての情報を受け取った日から開始され、リクエストが提出された日からではないことに注意してください。

締め切りがいずれかのリクエストタイプの最低限のターンアラウンドタイム内にある場合、その日までの納品を保証することはできません。
プロジェクトの締め切りを入力する際は、タイムゾーンの違いに注意してください。例えば、私たちのブランドデザインチーム (PT / GMT-8 タイムゾーン) より 1 日進んだところで活動しており、2 月 20 日（火）までに納品物が必要な場合は、時差を考慮して 2 月 19 日（月）を締め切りとして選択してください。

クリエイティブリクエストについて質問や懸念がある場合は、Senior Creative Operations Manager にお気軽にご連絡ください。

ブランドレビューリクエスト - ターンアラウンドの最低 1 週間
- これには、議論やフィードバックに対処し、再度レビューする時間が含まれます。最初のレビューは通常 72 時間以内に行われます。
デザインリクエスト - ターンアラウンドの最低 3 週間
グッズリクエスト - ターンアラウンドの最低 4 週間
- GitLab チーム、TMRG グループ、または特別なプロジェクトのカスタムグッズをリクエストする場合は、まず以下のセクションでリンクされているデザインリクエストを使用して Tanuki Tab for Teams Expressions リクエストを 最初に提出する必要があることに注意してください。
- リクエストを提出する前に、チームまたはプログラムがこの注文の予算を承認していることを確認してください。不明な場合は、ファイナンスビジネスパートナーに連絡してください。注文を完了するには PO が必要です。ハンドブックのカスタムグッズクリエイティブリクエストプロセスを確認してください。
- クリエイティブグッズリクエストに関する質問、コメント、懸念がある場合は、#brand Slack チャンネルにご連絡ください。
Tanuki Tab for Teams Expressions リクエスト - ターンアラウンドの最低 4 週間
- グッズや追加アセットのリクエストに対処する前に、以下のセクションにリンクされている「Tanuki Tab for Team Expressions」Issue テンプレートを使用して、まず Tanuki Tab を作成する必要があります。グッズや追加アセットが必要な場合は、別のリクエストを開いてください。
- Tanuki Tab リクエストに使用するGitLab チームエクスプレッションスタイルガイドをご確認ください。
ビデオリクエスト - 更新された SLA は近日公開！

注意: プロジェクトの優先順位は時間とともに変化することがあります。プロジェクトボードを整理し、アクティブな作業に集中させるため、2 か月間アクティビティのないリクエストはクローズされます。プロジェクトを引き続き開いたままにする必要がある場合は、リクエストを再開し、Slack で Senior Creative Operations Manager に通知してください。

リクエストの提出方法

サポートをリクエストするには、以下の Issue テンプレートのいずれかに記入してください。これらが入力されていない場合、リクエストをサポートするために必要な情報がないことに注意してください。

リクエストが Asana、Slack、またはその他の非公式チャンネルを通じて提出された場合、適切なインテイクフォームを使用してリクエストを再提出するように求められることに注意してください。これにより、作業を効率的に開始するために必要なすべての情報を確保し、すべてが GitLab で適切に追跡されることを保証します。

ブランドデザインおよびビデオ Issue テンプレート

1. ブランドレビューリクエスト

ブランドレビューリクエスト - ブランドレビューのみ - 新しいアセットやデザインのリクエストにはこのテンプレートを使用しないでください。
ローカライズアセットのブランドレビューリクエスト - ローカライズアセットのブランドレビューのみ。新しいアセットやデザインのリクエストにはこのテンプレートを使用しないでください。
- 英語以外のデザインまたはビデオアセットのみ。

2. デザインリクエスト

以下の Issue のいずれもブランドレビューには使用しないでください

ブログ画像リクエスト
コンテンツデザインリクエスト - 以下のアセットタイプの新しいクリエイティブまたはリフレッシュにこの Issue リクエストテンプレートを使用してください:
- eBook / ソリューションブリーフ
- 情報グラフィック / 図表
- 1 ページ資料 / 2 ページ資料
- 役員候補者情報パケットの四半期更新
- 調査
- ホワイトペーパー
- その他、ただし同じカテゴリのアセット内
デジタル広告リクエスト - 以下のような新規または更新のデジタル広告アセットをリクエストする場合に、この Issue テンプレートを使用してください:
- 有料ソーシャル
- オーガニックソーシャル
- ネイティブ広告
- ディスプレイアセット
メールアセットリクエスト
イベントアセットリクエスト - 以下のいずれかのイベント関連アセットの新規または更新をリクエストする場合に、この Issue テンプレートを使用してください:
- 注意: イベントグッズ + プレゼントには、このイベントリクエストテンプレートを使用しないでください。代わりに、グッズリクエストIssue テンプレートを使用してください。
  - イベントブース
  - イベントサイネージ
  - イベントソーシャル投稿
イラスト + アイコノグラフィーリクエスト
OOH リクエスト
プレゼンテーションリクエスト - 既存のプレゼンテーションデッキの更新、または新規デッキのデザインをリクエストする場合は、この Issue リクエストテンプレートを使用してください。
一般デザインリクエスト - デザインリクエストが上記のカテゴリに該当しない場合、または Zoom 背景が必要な場合は、この Issue テンプレートを使用して、複数または単一のアセットの新しいデザインをリクエストしてください。

3. グッズリクエスト（新規または既存/リフレッシュ）

グッズリクエスト - この Issue テンプレートは、TMRG プログラムのグッズ、イベントグッズ + プレゼントなどを含むすべてのカスタムグッズリクエストに使用する必要があります。

4. チームエクスプレッション（TMRG、特別プロジェクト、部門チーム）

チームエクスプレッションのための Tanuki Tab リクエスト - TMRG、部門、特別プロジェクト用のカスタムバッジまたはアセットには、この Issue テンプレートを使用してください。これは Tanuki Tab リクエストに使用されるシステムなので、必ずGitLab チームエクスプレッションスタイルガイドを確認してください。

5. ビデオリクエスト

新規ブランドビデオリクエスト - 新しいビデオをリクエストする場合は、この Issue を使用してください。
ビデオアップロードリクエスト - Vimeo、YouTube、または同様のプラットフォームにビデオをアップロードしてもらうリクエストには、この Issue テンプレートを使用してください。
ビデオ編集リクエスト - 既存のビデオの更新や、Zoom 録画にロワーサード、バンパー、スライドを追加するなどのビデオ映像の編集をリクエストする場合は、この Issue を使用してください。

リクエストの手順とヒント

リクエストを提出する際は、リクエストのタイトルを「CREATIVE REQUEST: [説明的な名前]」としてください。
できる限り Issue フォームを完成させてください。事前にチームが受け取れる情報が多いほど、リクエストの作業を早く開始できます。
クリエイティブリクエストに関する質問、コメント、懸念がある場合は、Senior Creative Operations Manager にご連絡ください。

チームへの問い合わせ

クリエイティブチームに連絡する最良の方法は、上記の Issue テンプレートのいずれかにリクエストを記入するか、または:

可視性のために GitLab の Issue とエピックで @gl-design タグを使用する。
GitLab の Issue とエピックで個人を @-mention する。
#brand Slack チャンネルで質問する。
ビデオに関する質問やサポートについては、#brand_video Slack チャンネルにご連絡ください。

ブランドとの作業

ブランドガイドライン、セルフサービスのリソースとアセット、トレーニング資料の詳細については、ブランドリソースハンドブックをご確認ください。以下に、ブランドとクリエイティブ素材を扱う際の詳細を記載しています。

フィードバックの提供

ブランドクリエイティブチームは、各プロジェクトにさまざまなビジュアルスキル、知識、ブランドの専門知識を持ち込むチームメンバーで構成されています。ブランド認知度、ビジュアルの一貫性、ビジネス価値は、私たちがクリエイティブな決定を下すために使用する主要な要素です。これらすべては、ブランドガイドラインに概説されているシステムに従いつつ、それを基盤として構築する形で行われます。私たちのチームと作業する際は、これらの同じ要素を念頭に置いて建設的なフィードバックを提供することが重要です。

建設的なフィードバックは、コラボレーション、効率、結果という私たちの価値観を考慮しています。以下のツールは、フィードバックを集中させると同時に、プロジェクトをタイムリーに進行させるのに役立ちます。

編集をリクエストする際は、ブランド認知度、ビジュアルの一貫性、ビジネス価値を念頭に置いた客観的なフィードバックを使用してください。客観的な ✅ vs. 主観的な ❌ フィードバックの例を以下に示します。
- ✅ 業界データによると、暗い背景の広告がより多くのトラフィックを獲得することが示されています。色を Purple 02p に更新できますか？
- ❌ 背景色がデザインの邪魔になっています。マゼンタの色の広告を見て気に入ったので、代わりにそれにできますか？
最終承認とフィードバックは、プロジェクトのライフスパンを通して、1 人のDRIが伝えるべきです。
- 注意: DRI が Issue でフィードバックを共有する前に、関係する他のチームメンバーからのフィードバックを統合できると最も役立ちます。
プロジェクトを軌道に乗せるため、レビュー用のクリエイティブドラフトは最大 3 ラウンドあります。
- 注意: ドラフトが共有されるたびに、それはすでにブランドクリエイティブチーム内で多くのイテレーションとレビューを経ており、可能な限り最高のバージョンがステークホルダーと共有されることが保証されています。
コンセプト作成に役立つ外部の例やインスピレーションは奨励されますが、特に独自のブランドアイデンティティを犠牲にして他者のデザインを複製できないことを認識することが重要です。
作業をレビューする際、コンテンツ（文法、句読点、スペルを含む）をレビューするのはステークホルダーの責任です。

クリエイティブアセットのソース

セルフサービスのニーズに対するクリエイティブアセットを調達するには、以下の手順を順番に実行してください。

既存のブランド承認済みコンテンツを使用する: 写真、イラスト、アイコン、グラフィックなどのキュレーションされたリソースを閲覧します。ブランドのライブラリ内のコンテンツは、ブランドからの事前承認なしに使用できます。
Adobe Stock でコンテンツを検索する: 写真ガイドラインを確認してから、Adobe Stockから適切なものを選択します。アセットを確認してダウンロードするには、ブランドチームに連絡してください。
新規アセットをリクエストする: ブランドチームがカスタムビジュアルコンテンツを作成するためのIssue リクエストを提出します。
AI を使用してコンテンツを生成する: すべての AI 生成コンテンツは、使用前にブランドによってレビューおよび承認される必要があり、私たちの法的パラメータを遵守する必要があります。画像が写真およびブランドガイドラインに従っていることを確認してください。承認をリクエストするには、ブランドチームに連絡してください。

可視性が高い、ビジネスクリティカル、または外部向けの作業は、開発のためにブランドクリエイティブチームを通してルーティングされる必要があることに注意してください。これらの種類のアセットはセルフサービスにせず、社内デザイナーが作成または直接サポートする必要があります。Issue テンプレートのいずれかを使用してクリエイティブリクエストを提出してください。

ストック写真

私たちのチームは、フォトライブラリに承認されたすぐに使用できるストック画像を集めました。

そのライブラリにある画像以外のものが必要な場合、ブランドデザインチームにはAdobe Stockから無制限の画像をダウンロードするライセンスがあります（注意: 標準メディアのみ。プレミアムおよび編集コンテンツはライセンスに含まれません）。

新しい画像を検索する前に、私たちの写真ガイドラインを確認してください。承認、ダウンロード、または質問については、Slack または関連する Issue で私たちのチームに連絡してください。

一般的に、実在の人々、物体、風景の画像は、視聴者が認識し関連付けやすくなります。AI 生成画像を使用する場合は、写真ガイドラインと法的パラメータを遵守してください。

サードパーティとのパートナーシップ

特定のケースでは、プロジェクトのためにサードパーティのエージェンシーまたはデザインパートナーの支援が導入される場合があります。デザインを外部委託するタイミングの基準は以下のとおりです:

ブランドガイドラインがサードパーティが作業するための十分なクリエイティブな方向性とパラメータを提供する、ステッカーや現在のビジネス優先順位に合致しないリクエストなどの小規模プロジェクト。
リクエストのタイムラインや規模を考慮して、ブランドおよびデジタルチームが追加のサポートを必要とする大規模なプロジェクト。

サードパーティがデザインをサポートするために導入される場合、ブランドの整合性を確保し、お互いに透明性をもって作業するために、作業をブランドデザインチームと共有する必要があります。

タヌキの保護

タヌキのカスタマイズされたバージョンが、私たちのコミュニティにとって意味のあるものであり、私たちの文化と価値観の重要な側面を表していることを理解しています。2022 年にリブランドした際、タヌキを変更しないという戦略的決定を下しました。これらのパラメータは、私たちのブランドガイドラインに反映されており、以前のロゴからの意図的な転換であり、以前のロゴはさまざまな色やアクセサリーでカスタマイズすることが多くありました。

タヌキの一貫した外観を維持する理由:

代替手段を構築しました。 2024 年、ロゴを保護しつつコミュニティのクリエイティブな表現のニーズに具体的に対応するため、Team Expressions Tanuki Tabsを立ち上げました。このスケーラブルなシステムは、コミュニティが私たちのロゴを変更することなく、コミュニティグループ、地理的位置、ビジネス機能、TMRG など、活気のあるグループを表現する力を与えます。
一貫性は私たちのブランドを強化します。 私たちのタヌキは最も価値のあるブランドアセットです。変更はブランドアイデンティティを希薄化し、市場プレゼンスを確立し続けるにつれて認識を低下させます。
私たちはブランドの成熟度とエンタープライズフォーカスを構築しています。 タヌキを再スタイリングすることは、ブランドにおけるそのビジュアルな役割を弱め、私たちのブランド戦略と矛盾します。
戦略的なリソース管理が結果を促進します。 私たちの小規模なブランドデザインチームは、会社全体の成長するクリエイティブニーズをサポートしており、ビジネス目標と一致し、明確なビジネス価値を生み出す作業を優先しています。カスタムロゴリクエストはチームの能力を超えて増加し、戦略的な優先事項と一致しません。
ブランドの整合性はあらゆる場所に及びます。 「内部のみ」のデザインでさえ、意図された用途を超えて頻繁に拡散し、ブランド認知度を損なう可能性があります。私たちのロゴは、私たちの会社の最初の印象になることが多いです。一貫して登場することで、業界標準を満たし、リブランド後の年に必要な、明確で信頼できるイメージを維持します。

マスコット

私たちは、タヌキにインスピレーションを得たマスコットを使用したり作成したりしないという戦略的アプローチを取りました。この立場は、ブランドの真正性、顧客への結果への焦点を維持し、世界を動かすソフトウェアを作成するために GitLab を毎日使用しているコミュニティとのより深い信頼を構築します。以下のフレームワークは、マスコットキャラクターなしでブランドが生命を吹き込むためのビジョンを概説しています:

競合他社からの戦略的差別化: 私たちの主要な競合他社は、マスコットをブランドと同義にするアプローチを取っています。マスコットを諦めることで、GitLab は同じ遊び心のあるキャラクター主導の空間で競争しない明確なブランドアイデンティティを確立し、最大の競合他社から差別化するのに役立ちます。
ブランドの成熟度とエンタープライズフォーカス: GitLab のプロフェッショナルなソフトウェア開発とエンタープライズ DevSecOps への焦点は、キャラクター主導のマーケティングではなく、ビジネス価値に焦点を当てたより洗練されたブランドと一致します。
タヌキをマスコットではなくブランド要素として活用: タヌキロゴマークは、GitLab の価値観を表すブランドの象徴的要素として慎重に統合されています。その構造の中心に DevSecOps を置くことで、タヌキはプラットフォームの無限の可能性を表す戦術的なブランドデバイスになり、そのように高められるべきです。
マスコットの落とし穴を避ける: 私たちの競合他社のブランドガイドラインは、マスコットが「内部で最も効果的に機能する」と認め、「お金、セキュリティ、販売、エンタープライズ提供」のようなトピックには使用しないように特に助言しています。タヌキを擬人化されたキャラクターではなくロゴマークとして保持することで、私たちはブランドにポジティブなビジネスインパクトと信頼を生み出すことができます。

私たちは、マスコットに頼ることなく、ブランドとコミュニティの間の楽しいエンゲージメントを引き出す代替方法があると信じています。これには以下が含まれますが、これらに限定されません:

ユーザー生成コンテンツとコミュニティストーリー
実際の GitLab チームメンバーを紹介する舞台裏のコンテンツ
ユーザーと交流し価値を提供する教育コンテンツ
ブランドアクティベーションを通じたインタラクティブな体験とツール
顧客の成功とイノベーションの祝賀

このアプローチの将来の再考には、マーケティング戦略、ブランドアイデンティティ、ビジネス目標の根本的な変化が必要になります。そのようなイニシアチブは広範な計画とソートリーダーシップを必要とし、キャンペーンや美的使用などの反応的な対策として行われることはありません。

ファンアート

GitLab ブランドは、その始まり以来、チームメンバーやより広いコミュニティのクリエイティブインスピレーションの源となっています。多くの場合、チームメンバーは私たちの価値観、ソフトウェア、タヌキロゴにインスパイアされたスピンオフアートを作成することがあります。

GitLab の知的財産にインスパイアされた、または基づいたアートワーク（「ファンアート」）は、私たちのブランド、製品、会社を必ずしも正確に表現しているわけではなく、ブランドを希薄化させたり、知的財産権を侵害したりする可能性があります。私たちのブランドを保護するため、GitLab チームメンバーは以下のガイドラインに従う必要があります:

やるべきこと:

ファンアートに「unofficial fanart」（非公式ファンアート）ラベルを追加して、コンテンツが公式の GitLab コンテンツではないことを明確にします。テキストは小さくても構いませんが、ファンアートを見る人がラベルにも気付くほど目立つようにしてください。
共有する権限のあるファンアート（例: あなた自身が作成したファンアート）のみを共有してください。疑わしい場合は、#legal Slack チャンネルで法務チームに連絡してください。
以下の承認されたプラットフォームでのみ共有してください:
- 内部 GitLab Slack チャンネルおよび友人へのプライベートメッセージ。
- Facebook、Twitter、Instagram、TikTok、Reddit の個人ソーシャルメディアアカウントから、より広いオーディエンスに公開で共有できます。
「公開」共有について:
- LinkedIn での共有は、個人の LinkedIn プロフィールと職場との密接な関連性のため禁止されています。
- 上記以外のプラットフォームで公開でファンアートを共有したい場合は、#brand Slack チャンネルで議論してください。

やってはいけないこと:

GitLab ロゴまたはワードマークを使用したファンアートを作成または共有しないでください。
- ファンアートに他の GitLab IP（GitLab の素材から直接取得したスクリーンショット、肖像、画像など）が組み込まれている場合は、レビューのために #brand に連絡してください。
ファンアートが公式の GitLab コンテンツであることを示唆しないでください。例:
- スライドデッキ、印刷資料、グッズなどの GitLab 素材でファンアートを使用しないでください。
- GitLab の顧客や、GitLab を代表して参加するイベントでファンアートを使用または配布しないでください。
ファンアートを販売したり、商業目的で使用したりしないでください。例:
- ファンアートステッカーや T シャツを販売しないでください。
- ビジネス、サービス、製品の広告にファンアートを使用しないでください。
攻撃的、または GitLab のブランドや他のブランドに有害となる可能性のあるファンアートを作成または共有しないでください。
他の会社の素材や GitLab に関係のないものとファンアートを組み合わせないでください。

質問がある場合は、#brand Slack チャンネルでブランドクリエイティブおよびブランド戦略チームに連絡してください。

Canva のベストプラクティス

Canva は、ブランドデザインテンプレートを活用することで、チームメンバーがデザインニーズをセルフサービスで対応し、ブランドに沿ったアセットを素早く作成できるようにします。Canva は、チームメンバーが提出したデザインの内部ブランド承認をプラットフォーム上で直接サポートしています。Canva は、コンテンツの多い、または印刷物の資料ではなく、デジタル広告やプロモーションアセットに最適です。コンテンツを頻繁に更新する必要のある資料、A/B テスト用の代替バージョン、またはコアブランディングを使用する迅速なターン要求の資料については、以下の手順と Canva のテンプレートライブラリを参照してください。

印刷作業、詳細なコンセプト作成、またはコアブランディングを超えたカスタムデザインを必要とするより大規模なプロジェクトについては、代わりにデザインリクエストを提出してください。これは以下に適用されます:

GitLab 主催イベント: より高い品質を必要とする、私たちが主催またはスポンサーするイベント
複数会場イベント: ビジュアルの一貫性が必要な、複数の都市で開催されるイベント
カスタムまたはイベント固有のブランディング: 利用可能な Canva テンプレートで提供されるものを超えた、特定のルックアンドフィールを使用するアセット

Canva を始めるには、以下のチェックリストを完了してください

GitLab Enterprise アカウントへのアクセスをリクエストします。
詳細なチュートリアルについては、Canva のヘルプセンターとYouTube チャンネルをご覧ください（Canva Pro プレイリストから始めるのがおすすめです）。
以下に概説されているベストプラクティスをお読みください。
GitLab Enterprise アカウントに慣れるためにデモをご覧ください（視聴するには YouTube で GitLab Unfiltered にログインする必要があります）。

GitLab Enterprise アクセス

定期的に Canva でデザインを作成する場合、無料または個人アカウントを使用するのではなく、GitLab Enterprise Canva Pro アカウントで作業することをお願いします。アクセスを取得するには、アクセスリクエストIssue を提出してください。これが完了したら、ブランドデザインチームの誰かがアクセスを許可します。

利用可能なシート数は限られているため、チームはアクセスが必要なチームメンバーの数を統合することをお勧めします。注意: 共有ログインは禁止されています。

GitLab Enterprise アカウントで作業する利点:

完全な機能性: アカウント内で作業すると、Canva の Pro 機能とブランドテンプレートにすべてアクセスできます。
可視性: すべてのアセットを 1 つのアカウントに整理することで、より高い透明性が得られ、デザインのイテレーションが合理化されます。
ワークフロー: ブランドアセット、テンプレート、ブランドチームの承認に素早くアクセスできるため、コラボレーションが容易になります。

追加のヒント:

Canva にいるときは GitLab Enterprise アカウントにログインしていることを確認してください。既存のログインがある場合、間違った方にログインしているのは簡単です。
左側のナビゲーションメニューで、自分のデザイン (Projects) とチームのデザイン (GitLab Enterprise) を切り替えることができます。
Canva の権限を変更する必要がある場合は、ブランドデザインチームに連絡してください。アカウントに参加するチームメンバーは自動的に member ステータスに設定され、ファイルの編集と共有が許可されます。

Canva ブランドレビュープロセス

すべてのセルフサービスアセットは使用前にブランドレビューが必要です。既存の Canva テンプレートから作業している場合、ファイルの右上にデザイン承認をリクエストするオプションが表示されます。これにより、レビューのためにデザインがブランドチームに自動的に提出されます。このオプションが表示されない場合は、ブランドレビュー Issueを開き、Canva ファイルをリンクしてください。

レビューターンアラウンドタイムについては、サービスレベルアグリーメント (SLA)を参照してください。緊急のリクエストについては、Issue またはファイルへのリンクとともに Slack の #brand チャンネルにご連絡ください。

ファイルとフォルダ

フォルダには、Canva デザインファイル、サブフォルダ、デバイスからアップロードしたアセットを含めることができます。フォルダを作成すると、Projects の下のフォルダにデフォルトで保存されます。組織の他の人がフォルダを表示および/または編集するには、フォルダを GitLab Enterprise と手動で共有する必要があります。

左側のナビゲーションメニューから Projects を選択 > Folder にホバー > 三点リーダー をクリック > Share > GitLab Enterprise ドロップダウンから eye icon (閲覧アクセス) または pencil icon (編集アクセス) を選択

Canva でのデザイン

テンプレート

Canva には独自のテンプレートが多数ありますが、これらの使用は控えめにすることをお勧めします。再デザインに多くの作業が必要であり、私たちのガイドラインに従わないブランディングを導入するためです。
GitLab Enterprise アカウントのテンプレートは、ブランドに沿ったデザインを作成するための優れた出発点です。すべての広告サイズと、その他のプロモーションとリソースのテンプレートがあります。
- 注意: テンプレートは GitLab Enterprise アカウントの Folders タブにあります。これは、構造のない Templates タブの代わりに、テンプレートをフォルダに整理できるようにするためです。
テンプレートファイルをクリックすると、紫色のボタンに Use this template が表示されます。このオプションを選択すると、デザインを開始できるコピーが自動的に作成されます。
- 注意: ブランドデザインチームから事前承認がない限り、Edit Original を選択しないでください。これにより、全員のテンプレートが変更されます。
新しいデザインの名前を変更し、ファイル内の未使用のページや指示を削除し、GitLab Enterprise アカウントの関連するフォルダに移動することを忘れないでください。

新しいファイル

カスタムサイズで新しいデザインを作成、移動、ファイル名の変更ができます。
ファイル名は小文字で、スペースの代わりにハイフンを使用する必要があります。ファイル名にファイルの寸法を含めてください。頭字語を避ける。

ページ

1 つの Canva ファイルには最大 200 ページを含めることができ、同じサイズで関連する複数のアセットを作成する場合に便利です。
Canva ファイル内の各ページを複製、削除、命名できます。
コピーアンドペーストのキーボードショートカットは、1 つのページから別のページに、または 1 つのファイルから別のファイルに要素を複製するのに機能します。
異なる寸法でデザインを複製している場合、ファイルを簡単にリサイズできます。ファイルがリサイズされると要素がシフトされるため、それに応じてデザインの要素をリサイズしてください。

ブランドキット

左側のナビゲーションメニューの Styles タブで、GitLab ブランドキットの色パレットとフォント (Inter) が表示されます。
Logos タブには私たちのロゴが表示され、デザインにドラッグアンドドロップできます。

タイポグラフィ

Text または Styles タブからテキストを追加します。これにより、Inter と適切なフォントウェイトを持つテキストボックスが自動的に追加されます。ただし、これらのテキストボックスは、私たちのタイポグラフィガイドラインに従って書式設定する必要があります:
- すべてのテキストを左揃えにします。
- 見出しと CTA には GitLab Sans Bold を、サブヘッドとボディコピーには Regular を使用します。
- 行間隔は見出しで 1.1、その他のテキストで 1.2 に設定します。すべてのコピーで文字間隔は 0 のままにします。
- CTA スタイリングについては、既存のテンプレートからコピーするか、ガイドラインを参照してください。
- テキストの背景が読みやすさのために十分なコントラストを提供していることを確認してください。
- アクセシビリティのために White または Charcoal テキストを使用してください。

グラフィック

Elements タブからグラフィックを検索および追加できますが、慎重に使用してください。このタブは基本的な形状、ライン、画像フレームを見つけるのに最適です。それを超えて、デザインをブランドに沿わせるために、GitLab のアイコンライブラリのグラフィックを使用してください。
すべての要素はデザインにドラッグアンドドロップできます。Uploads タブでブランド化されたアセットをアップロードします。透明な背景を持つ .png ファイル形式が最適です。
ほとんどの Canva 要素について、GitLab の色パレットを使用していることを確認するためにグラフィックの色を調整できます。色のガイドラインを参照し、アクセントカラーは控えめに使用してください。
一部の Canva 要素のラインウェイトも変更できます。私たちのイラストガイドラインと一貫性を保つため、1〜2 のラインウェイトが最適です。

写真

デザインに写真を追加する必要がある場合、Elements タブに表示される Canva の写真ではなく、私たちのフォトライブラリからの承認された画像を使用するのが最適です。
画像を選択して配置するときは、私たちの写真ガイドラインを参照してください。
- 追加のオプションが必要な場合、ブランドデザインチームにAdobe Stockから画像をソースしてもらうリクエストを行うことができます。

レイアウトと整列

ファイルに Canva の推奨される余白間隔を使用してください。これらは、デザイン内で要素を移動するときにマゼンタの線として表示されます。
破線のマゼンタの線が、要素同士が整列している場合にハイライトされます。
項目は、ツールバーのツールを使用して、固定、グループ化、整列、反転、回転、スケール、レイヤー化することができます。

エクスポート

デザインをエクスポートするには、右上隅の Share を選択 > Download > ファイルタイプを選択 > Download をクリックして、アセットをデバイスにダウンロードします。 Share メニューから、他の人をファイルでコラボレーションするように招待することもできます。 Canva の権限に応じて、Template > Publish Template を選択してファイルをテンプレートとして共有できる場合があります。

私たちの働き方

ブランドデザインチームの構造

私たちは皆、ブランドデザイナー、ブランドチャンピオン、批判的思考の問題解決者、戦略家、チームメイトです。お互いの強みを活用しながら、集合的な知識と専門知識を成長させています。私たちは、GitLab の価値観に従い、Issue とエピックを使用して作業を追跡することによって作業します。

責任

リーンで効率的: 全員の強みと専門知識を活用し、チームとブランドのために最善の決定を下すことをお互いに信頼します。
多くの帽子をかぶる: 役割の要求するさまざまなタスクに取り組む柔軟性を持ち、すべてはチームと会社の最善のために。
クリエイティブコンセプトを開発する: 個々のプロジェクトのクリエイティブな方向性を推進します。大規模プロジェクトでは、Adam と Luke がコアコンセプト開発を担当し、それを議論、フィードバック、洗練のために広いチームに提示します。
クリエイティブを実行する: クリエイティブな方向性に基づいたタッチポイントの素材で、クリエイティブな方向性を生命に吹き込みます。すべては時間を適切に管理しながら行います。
GitLab ブランドを擁護する: 私たちのブランドガイドラインを知り、貢献し、維持し、ブランドの整合性を保つために、チーム内外の素材をレビューします。
ツールを知る: Adobe Suite と Figma（デザイン用）、Mural と FigJam（ブレーンストーミング用）、Canva（セルフサービスアセット作成用）、Google Suite（全社向け素材用）に習熟していること。

デザイン承認

チームは、できる限り頻繁にチームから構造化された直接的なフィードバックを求めながら、GitLab ブランドのために可能な限り最善の決定を下すことができるようにエンパワーされていると感じるべきです。Adam と Luke は必要に応じて最終的な決定を下すためにここにいますが、進歩のボトルネックである必要はありません。

チームワークフロー

チームチェックイン: 私たちには 2 つの定期的なチームシンクがあります: (1) 月曜日のブランドクリエイティブアワーコールで、追いつきと今後 1 週間の作業について話します。(2) 水曜日のブランドクリエイティブアワーコールで、プロジェクトに対するフィードバックを得たり、対処すべきトピックについてコラボレーションしたりします。
Issue での作業: すべてのデザインリクエストには、私たちのIssue テンプレートを使用し、mktg-status::triage、corporate-marketing、design Issue ラベルを含めて、チームのトリアージボードに表示する必要があります。チームの Senior Creative Operations Manager である Michelle は、週の初めに作業をトリアージし、チームメンバーは自分自身に作業を割り当てることもできます。
- 注意: 検索バーの左側で現在「Brand Design TRIAGE Board」と表示されている場所のドロップダウンオプションを選択することで、誰もが個人化されたボードを見ることができます。
- 注意: エピックはEpic ボードで見ることができます。
共同作業: 各人の強みを活用してチームとして一緒に作業します。作業は通常、デザインスキルがリクエストに合うチームメンバーにトリアージされるか、または組み合わせた才能を使用してプロジェクトで一緒にコラボレーションします。
小規模プロジェクト: 小規模プロジェクトは通常、1 人のデザイナーに割り当てられ、2 週間以内に完了します。GitLab での迅速なターンアラウンドを考えると、私たちは小さなイテレーションで作業し、それを MVC（最小有用変更）アプローチと呼びます。
中規模および大規模プロジェクト: より大規模なプロジェクトについては、リクエストを評価してからタイムラインを提案します。ユニークなコンセプトを持つキャンペーンやプロジェクトについては、非同期または広いチームとのクロスファンクショナルコールでブレーンストーミングセッションを開始するか、誰が割り当てられたかにかかわらず、コンセプトをステークホルダーに提案します。
作業の共有: 作業は早く頻繁に共有する必要があり、チームコールまたは私たちのプライベート #brand-design-team Slack チャンネルで非同期に共有します。ドラフトは通常、Issue のデザインタブを使用するか、コメントのスクリーンショットとしてステークホルダーと非同期に共有されます。

作業の保存

私たちはブランドデザインリポジトリから作業をローカルにアップロードおよびプルします。機密プロジェクトと大きな印刷ファイルは、リポジトリと同じ方法で整理されているチームのGoogle ドライブに保存されます。共同作業のためのチームのFigmaもあります。

リポジトリのトップレベルフォルダはプロジェクトタイプによって整理されています。そこから、カテゴリによって、場合によっては会計年度によって細分化されます。
デフォルトでは、すべてのソースファイルは、より小さなエクスポートファイル（デジタル広告など）と一緒にリポジトリに保存する必要があります。より大きなエクスポート（印刷可能ファイルなど）の場合は、チームドライブに保存および共有してください。
フォルダ名には、小文字、スペースの代わりにダッシュを使用し、特殊文字は含めないでください。
- 例: field-marketing-events

ブランドデザインリポジトリにターミナルを使用する

作業を最新に保つために、少なくとも 1 日 1 回は頻繁にプッシュとプルしてください。他の人も作業しているかもしれないファイルで作業している場合は、誰も他の人の作業を上書きしないようにチームと連絡してください。
デザインアセットのプッシュとプルを開始するには、brand-design リポジトリのローカルクローンをマシンにセットアップします。日常の作業のために、ここでは作業のプルとプッシュに使用される一般的な git コマンドを、使用すべき順序で示します:
- cd brand-design - このコマンドはターミナルアプリを開いたときに 1 回だけ使用する必要があります。マシンにリポジトリを保存した場所によっては、brand-design フォルダに到達するまで、cd [親フォルダ名] コマンドを複数回実行する必要があるかもしれません。
- git pull - これにより、ローカルリポジトリがチームの他のメンバーが行った変更を反映するように更新されます。作業を開始する前、または新しい作業をプッシュする前にこのコマンドを実行します。
- git status - オプションコマンド。これにより、リポジトリにプッシュバックする必要があるローカルでの変更の概要が提供されます。
- git checkout [挿入ファイルパス] - オプションコマンド。これは、リポジトリにプッシュしたくないファイルを削除するために使用できます。
- git add . - 作業をプッシュする前にこのコマンドを使用します。これにより、変更を加えたすべてのファイルが追加されます。
- git commit -m "[変更の説明を挿入]" - 変更の概要を含むメッセージを含めてください。これは全員に表示され、コンテキストを提供します。
- git push origin main - これにより、変更を説明するコミットメッセージとともに、すべての変更がリポジトリにプッシュバックされます。
- git pull --rebase, それに続いて git push origin main - プッシュ時にエラーが発生した場合にリセットするためにこの 2 つのコマンドを使用します。

ファイル命名規則

ファイルは次の規則で命名する必要があります: [project-type]-[project-name]-[asset-type]-[issue-number]-[asset-dimensions]-[fiscal-year]
- 例: display-ad-banner-0842-160x600-fy25
ファイル名にキャラクター記号を追加しないでください: % , _ / （必要な場合のみ、ピリオドは使用可）
ベンダーの仕様またはプロジェクトが特定の命名規則に従うことを要求している場合、その規則が私たちのものをオーバーライドします。配信されたらファイル名を変更する必要はありません。
ファイル名は小文字で、スペースの代わりにハイフンを使用する必要があります。ファイル名にファイルの寸法を含めてください。頭字語を避ける。
Google ドライブとリポジトリの両方がバージョン履歴を保存します。そのため、ファイルへの編集が行われると、ファイルは上書き保存できます。

eBook、ホワイトペーパー、1 ページ資料

各出版物のデザインテンプレートはこちらにあります。
私たちの出版物は翻訳のために Smartling に送られることがよくあります。簡単にダウンロードできるよう、パッケージ化された作品の .zip ファイルを保存してください。
ほとんどの 1 ページ資料は、私たちのGoogle ドキュメントテンプレートのいずれかを使用してセルフサービスできます。

デジタル広告

デジタル広告は作成後にカスタマイズが必要なことが多く、そのためセルフサービスを容易にするために Canva を推奨します。一部の広告は、特定の仕様とファイル要件で Demandbase によって編集する必要があります。

イベント

展示会ブースは、デフォルトで一般的な GitLab ブランドを使用する必要があります。これらのような一般的なイベントは、リポジトリ内で年ごとに整理されています。
私たちが主催する定期的なイベント（Sales Kickoff、Contribute、Commit）は毎年異なるテーマを持ち、新しいクリエイティブな方向性をインスパイアします。これらのイベントには独自のフォルダがあり、その中で年ごとに整理されています。

design.gitlab.com (Pajamas) のブランドガイドラインの維持

ブランドデザインチームは、design.gitlab.com (Pajamas) のブランドガイドラインを維持しています。私たちのチームの目的のために、コミットの修正を除き、Web IDE を使用してガイドラインを更新できます。

開始するには、以下のワークフローに従い、製品チームとのデモをご確認ください。ローカルで変更を加えるか、コミットを修正するには、これらのターミナル用の指示に従ってください。

Web IDE の使用

Pajamas を開き、更新が必要なページに移動します。
ページの一番下までスクロールし、Open Web IDE を選択します。

Web IDE での Pajamas コンテンツ構造

私たちのブランドガイドラインのページは Contents フォルダにあります。対応する .md テキストファイルで変更を加えます。関連するコンテンツは以下のとおりです:

brand-design: このフォルダには、デザインの基礎に関連するページが含まれています。
brand-logo: このフォルダには、ロゴガイドラインに関連するページが含まれています。
brand-messaging: このフォルダには、メッセージングとブランドアイデンティティに関連するページが含まれています。
brand-introduction.md、resources.md、style-guides.md: これらは、ブランドガイドラインに関連するサイトの追加のトップレベルページです。
static > img > brand: brand フォルダには、ブランドガイドラインにリンクされるすべてのメディアが保存されます。
nav.json: このファイルは、Pajamas のナビゲーションバーに反映される構造を決定します。

Pajamas に新しいページを追加する

ページが配置されるフォルダを右クリックします。New File を選択します。
ファイル名を追加します（これは URL パスに反映されるものです）。新しい Markdown ページを示すために .md 拡張子で終わります。
nav.json ファイルを開いて、新しいページでナビゲーションバーを更新します。
ページを整理するためにナビバー設定に従います。他のページの下にページをネストすると、ナビゲーションバーにドロップダウンが作成されます。
1. title は、ページに表示する名前です。
2. path は、URL パスに反映されるものです（これは作成したページのファイル名と一致する必要があります）。

注意: Pajamas は markdown を使用し、見出しスタイルはハンドブックと一致します。通常通りコンテンツを追加します。

メディアの最適化とアップロード

適切なファイル形式を選択し、それに応じて最適化します:

.svg 形式はページに合わせてスケールするため理想的です。アップロード前にSVGOを使用してファイルを最適化してください。
.png または .jpg は画像を含むグラフィックに適しています。アップロード前にグラフィックを最適化してください。
.gif 形式は受け付けられません。
すべてのファイルを brand フォルダ (static > img > brand) にアップロードします。
ビデオは Vimeo または YouTube から埋め込みできます。

figures を使用してメディアを追加します。これは、ビジュアルとキャプションを接続します。figures 形式の内訳は次のとおりです:

aria-label= このテキストは、fig caption と同じにすることができます。
img class= これは、画像の表示サイズを書式設定します。img-50 は、ページの幅の 50% に幅を縮小します。gl-p-5 はページの全幅にスケールします。
src= これは画像の場所に対応します。これは、static > img > brand フォルダにアップロードしたものに対応するファイル名と一致する必要があります。
1. .png で作業している場合は、light src= または dark src= を使用して、画像がライトモードとダークモードで一貫して表示されるように、固定された白または黒の背景を作成します。
alt= これは、メディアがページに表示されない場合に表示される代替テキストです。これは、aria-label と fig caption よりも説明的でユニークである必要があります。
1. ページに十分な詳細がすでに提供されている場合は、空白のままにできます: alt=""
fig caption これは、グラフィックの下に表示される説明的なテキストです。

マージリクエストのプッシュ

小さなコミットによりコラボレーションが容易になります。物事を整理整頓するために、単一のマージリクエスト内で必要な最小の変更のみを行ってください。例えば、Typography と Brand Motion の両方のページに更新が必要な場合は、変更を 2 つの MR に分割してください。

conventional commits を使用します。コミットメッセージは 72 文字未満である必要があります。マージリクエストの説明では、より詳細を追加できます。
1. コミット例: Feat(BrandMotion): embed video samples.
  1. ‘Feat’ はコミットの ‘type’ を示します。F を必ず大文字にしてください。
  2. ‘BrandMotion’ は変更が行われたサイトページを識別します。
  3. ‘embed video samples’ は行われた変更を説明します。
コミットを new branch に push します。次に、create MR を選択します。
マージリクエストの説明を使用して、変更に関連する Issue またはドキュメントを含む、レビュアーに役立つ追加の詳細を追加します。
マージリクエストを自分自身に割り当てます。
チームの少なくとも 1 人を Reviewer として割り当てます。理想的には、必要な変更についてすでに認識している人物です。
行ったコミットのタイプを反映するラベルを追加します。私たちの目的では、ほとんどの場合 type:feature: ラベルになります。
1. type:feature: 新機能、機能変更、改善を提供する取り組み。
2. type:maintenance: 機能でもバグでもない、維持作業と追いつき修正の改善。
3. type:bug: 出荷されたコードの欠陥とそれらの欠陥の修正。
希望のタイムラインに合致するマイルストーンを添付します。私たちの目的では、最新の GitLab リリースをデフォルトとします。例: 18.11
Merge options の下で、Squash commits when merge request is accepted. のボックスを選択します。
create merge request を選択します。
必要に応じて編集または修正を行います。より大きな編集の場合は、マージリクエストの Changes ページに移動し、3 つの積み重ねられたドットをクリックして、Edit in Web IDE を選択します。これにより、変更を含む別のコミットをプッシュできます。または、より小さなコンテンツ編集の場合は、Changes ページのコード行に移動して、コメントアイコンをクリックし、コメントツールバーの Insert suggestion アイコンをクリックして、ハイライトされた緑のテキストに直接変更を加えるだけです。次に、複数の提案を一度にバッチ処理し、Apply suggestion(s) を選択して、これらの編集が自動的に MR に追加されるようにできます。
GitLab Duo チャット機能を使用すると、パイプラインが失敗した場合に必要な変更を特定するのに役立ちます。また、ジョブページに移動して Troubleshoot pipeline を選択して、修正を特定することもできます。
Reviewer は、自分の名前の横にある緑のチェックマークを押すことで承認する必要があります。review app をチェックして、行われた変更をプレビューしてください。
パイプラインが正常に通過し、私たちのチームからの承認が得られたら、製品チームから Jeremy または Taurie のいずれかを reviewer として割り当てます。

最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)

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