Asana
Asana について
Asana は、誰もが私たちの世界を動かすソフトウェアに貢献し共創できるようにするという GitLab のミッションをサポートする、コラボレーティブな業務管理プラットフォームです。GitLab のマーケティングチームは、プロジェクト（例: 製品ローンチ）の追跡、業務とゴールの結びつけ、チーム横断での業務調整に Asana を使用する予定です。
なぜ?
私たちのチームは、マーケティング向けに作られたプロジェクト・タスク管理ツールを追加するために Asana を使用しています。これにより、プロジェクトとプロセスを合理化・簡素化し、効率、コラボレーション、透明性を向上させ、顧客がどのように GitLab を使用するかをより理解するための時間をチームに与えることを目的としています。
マーケティング組織全体のチームメンバーから、効率を改善する機会があると一貫して聞いてきました。私たちが解決しようとしている主な問題は次のとおりです:
- GitLab を、もともと構築されていないマーケティングプロセスや、顧客ベースで決して使用されないユースケース向けのプロジェクト管理ツールとして使うよう拡張していること。
- これは、不必要な管理作業、ボトルネックを引き起こし、日々の効率へのコミットメントから注意を逸らす可能性があります。
- マーケティング向けに作られたプロジェクト・タスク管理ツールを追加することで効率が向上し、顧客がどのように GitLab を使うかをチームが学び理解する時間を解放できます
ユーザー
Asana ライセンスはマーケティング組織全体に展開されます。
閲覧専用ライセンスはすべての GitLab チームメンバーが利用できます。閲覧専用ライセンスを希望する場合は、Lumos でアクセスをリクエストしてください（必ず View Only 権限を選択してください）。
利用可能なフルユーザーシートの数に制限があるため、1 ヶ月以上ログインしていないユーザーを「一時停止」します。再アクティブ化するには、ログインするだけで構いません。さらに 1 ヶ月一時停止された後、「読み取り専用」にダウングレードされ、ライセンスを取り戻すには Lumos でアクセスをリクエストする必要があります。
Asana のヘルプを得る方法
質問がある場合は、まずこのハンドブックページ、Asana ヘルプセンター、および/または Asana Academy を確認してセルフサービスしてください。自分で解決策が見つからない場合は、この GitLab 内部サポートフォーム を使ってお気軽にお知らせください。
セルフペース学習
Asana Academy は、ライブおよびオンデマンドのウェビナーやワークショップを備えた優れたリソースです。
Asana を始める
タスク
タスクは Asana のアクションの基本単位です。タスクは GitLab の Issue に最も似ています。新しいタスクの作成、既存のタスクの複製、2 つのタスクのマージ、サブタスクの作成、タスクの削除ができます。既存のプロジェクトに論理的に当てはまる小規模な作業がある場合は、タスクを作成してください。
Asana は、個人がアイデアを貢献し、アクションアイテムを前進させることができる場合に最も役立ちます。タスクは Asana 内の基本的な作業項目です。タスク名は具体的、明確、アクションベースであるべきです。可能な場合は動詞を使ってください。たとえば、「ブログ投稿」とタスクを命名するのではなく、「[タイトル] のブログ投稿を書く」と命名し、「[タイトル] のブログ投稿を公開する」という第 2 のタスクを作成します。
タスクの説明
タスクの説明は、タスクを完了するために必要なすべての情報を担当者に提供する必要があります。いくつかのヒント:
- タスクの説明で関連する人物に
@mentionし、関連するタスク、プロジェクト、メッセージへのハイパーリンクを設定して、関連する作業にリンクします。 - 外部の作業を含めるためにリンクと添付ファイルを追加し、情報を一元化します。
- 別のタスクに依存するタスクをマークし、前のタスクが完了したらチームメイトがそのタスクを開始するようにします。
- タスクの説明でリッチテキストを使用し、フォーマットされたテキストとリストでメッセージを明確化します。
タスクの割り当て
Asana の各タスクは 1 人の担当者のみを持つことができ、その人物は Directly Responsible Individual（DRI）として機能します。この人物は、タスクが確実に完了することに責任を負います。ただし、タスクには複数のチームメンバーとのコラボレーションが必要となることがよくあります。タスクの所有権とコラボレーションを効果的に管理する方法は次のとおりです:
DRI（タスク担当者）ガイドライン
DRI は次のような人であるべきです:
- 業務の結果に対して主に責任を負う人物
- タスクに関する決定を下す権限を持つ人物
- タスクのタイムライン中に対応可能な人物
コラボレーション構造
タスクのコラボレーター（フォロワー）には以下を含めるべきです:
- 情報を提供し続ける必要があるステークホルダー
- 入力またはレビューを提供するチームメンバー
- タスクの進捗を可視化する必要のある人々
- 業務を監督するプロジェクトマネージャー
コラボレーターを追加するには:
- タスクのコラボレーターフィールドの “+” ボタンをクリック
- チームメンバーを検索して選択
- または、コメントで @mentions を使用してコラボレーターを自動的に追加
チームコラボレーションのためにサブタスクを使用するタイミング
サブタスクを割り当てるときは、担当者が親タスクから、またはサブタスクの説明から十分なコンテキストを得ていることを確認してください。サブタスクを多くの階層の下に埋もれさせるのは避けてください。いつでもサブタスクをタスクに変換できます。
次の場合にサブタスクを作成します:
- 異なるチームメンバーが個別の業務に責任を持つ場合
- タスクが異なる担当者を持つ複数の連続的なステップを必要とする場合
- より大きなタスク内で個々の貢献を追跡する必要がある場合
例の構造:
メインタスク: Q4 ブログ投稿ローンチ [DRI: コンテンツマネージャー] └─ サブタスク 1: コンテンツのドラフト [DRI: ライター] └─ サブタスク 2: グラフィックスをデザイン [DRI: デザイナー] └─ サブタスク 3: SEO レビュー [DRI: SEO スペシャリスト] └─ サブタスク 4: 最終承認 [DRI: コンテンツマネージャー]
タスクのベストプラクティス
- タスク名と説明で明確なコンテキストを提供する
- 現実的かつ合理的な期日を提供する。チームとして、期日がどのように変更されるかを決定できます。タスクのコメントで、期日が柔軟であることを示したり、必要に応じて期日を再調整したりするためのコミュニケーションを取ってください。
- 関連する人物、プロジェクト、タスク、チームを @mention することで、関連するタスクやプロジェクトをハイパーテキスト化する。
- チームに情報を提供し続けるためにタスクのコラボレーターを追加する。
プロジェクト
プロジェクトは、プロセスや施策を完了するために必要なすべてのステップを整理し追跡するために使用されます。プロジェクトは、施策を完了するため、プロセスをメンテナンスするため、またはゴールを達成するために必要な業務を計画するのに役立ちます。プロジェクトは GitLab の Epic に最も似ています。
既存のチームのサブセットまたはチーム全体が関与する大規模な業務（10 以上のタスク）がある場合は、プロジェクトを作成してください。
新しいプロジェクトの作成と命名
プロジェクトを使用すると、特定の施策、ゴール、または重要な業務に関連するすべてのタスクを 1 か所に整理できます。タスクと同様に、誰でもプロジェクトを作成できます。
プロジェクトには 3 つの一般的なタイプと関連する命名規則があります。命名規則は、タスクとプロジェクトを整理しておくのに役立ち、チームが情報をより素早く見つけるのに役立ちます。新しいプロジェクトを作成するときは、まず作成しているプロジェクトのタイプを決定してください。
- Deadline-bound projects は、明確な開始日と終了日、明確な終了基準を持つ a. [FYXX] - [サブチーム名] - [簡潔なプロジェクト名] i. FY25 - Product Marketing - GitLab Duo Launch Plan ii. FY25 - Content - Blog Post - Enterprise Agile Planning
- Ongoing/Operational Processes は、特定の終了がない継続的なプロセスを表す。業務は反復可能なステージのセットを通じて移動する a. OP - Calendar - Events b. OP - Calendar - Email c. OP - Intake - Marketing Ops
- Reference Projects は、情報をキャプチャし整理する方法。これらのプロジェクトには実行可能な業務は含まれません。 a. REF - Asana Naming Conventions b. REF - Events - AMER - Preferred Vendor List
プロジェクトテンプレート
カスタムテンプレートを作成するか、Asana が作成したテンプレートを使用して、共通のワークフローやプロジェクトを標準化します。テンプレートは、プロジェクトを素早く開始し、重要なステップを見逃していないことを確実にするのに役立ちます。
Asana と他のツールの使い分け
クイック決定ガイド
業務を始める前に、自問自答してください:
- これは複数のステークホルダーが関与するマーケティング部門の業務ですか? → Asana を使う
- これはコード変更や技術文書ですか? → GitLab を使う
- 即時のリアルタイムコミュニケーションが必要ですか? → Slack を使う
ツール別の詳細な内訳
Asana: プロジェクト・タスク管理
最適なケース:
- マーケティングキャンペーンの計画と実行
- マーケティング内のクロスファンクショナルなコラボレーション
- プロジェクトの追跡とステータス更新
- アクションアイテムと次のステップ
- タスクの委任と進捗追跡
Slack: リアルタイムコミュニケーション
最適なケース:
- 簡単な質問
- リアルタイムのコラボレーション
- チームの発表
- 非公式な議論
GitLab: 技術的業務、ドキュメント、マーケティング外とのコラボレーション
最適なケース:
- ハンドブックの更新
- コード変更 / マージリクエスト
- マーケティング外のチームからのサポートをリクエストするための Issue を開く
クロスツールワークフロー
Asana + GitLab
- Asana でメインプロジェクトを作成
- 関連する GitLab Issue を作成
- Asana タスクで GitLab Issue をリンクする（タスクの説明またはカスタムフィールドを使用）
- Asana でステータスを更新し、GitLab で技術的詳細を更新
- Issue からの重要な決定や更新を Asana に文書化
Asana + Slack
- プロジェクトに関するすべての詳細と議論を Asana に保管
- 時間に敏感な更新のみ、または重要な Asana 更新へのリンクをクロスポストするために Slack を使用
- 重要な Slack の決定を Asana に文書化
- 必要なときに Slack で Asana タスクのリンクを共有
クロスツールワークフローの例
Web サイト更新プロジェクト
Asana:
- メインのプロジェクト管理
- タイムライン追跡
- ステークホルダー更新
- コンテンツ承認
GitLab:
- マージリクエスト
- 技術文書
- 実装の詳細
Slack:
- 緊急のデプロイメントの質問
- 簡単なステータスチェック
ベストプラクティス
やる:
- 関連する GitLab Issue にリンクする Asana タスクを作成
- Slack の議論がアクション可能なアイテムになったら Asana タスクに移行
- すべてのプロジェクト関連のコミュニケーションと更新には Asana を使用
- 重要な Slack や GitLab の決定を Asana に文書化
やらない:
- プラットフォーム間で重複する追跡システムを作成
- Slack で長いプロジェクト議論をする
- マーケティングタスク管理に GitLab を使う
- プロジェクトのドキュメントを Slack のみに保管
どちらにするか決めかねる?
どのツールを使うか不明な場合:
- 関与する必要がある人を考慮
- 行われる業務のタイプを考える
- タイムラインと緊急性を評価
- 迷ったら、Asana から始めて、必要に応じて他のツールにリンクする
覚えておいてください: ゴールは、関連する業務をまとめておきながら、各ツールをその強みのために使用することです。迷ったら、「他の人はこの情報をどこで探すだろうか?」と自問してください。
Asana とのインテグレーション
GitLab
特定の GitLab Issue は、カスタムビルドされたワークフローに基づいて Asana プロジェクトとタスクを自動的に作成します。詳細は追って追加されますが、現在は Allocadia > GitLab > Asana のフィールドマーケティングワークフローの一部としてのみ利用可能です。タスクとリクエストの大部分は Asana のみに存在するべきであり、GitLab と Asana の使い分けについては上記のガイドを利用してください。
インテグレーションの詳細は internal handbook で確認できます。
Slack
任意の Slack メッセージを数回のクリックで実行可能な Asana タスクに変換できます。できることのいくつか:
- 新しいタスクを作成し、自分自身またはチームメイトに割り当て、既存のプロジェクトに追加
- タスクを完了としてマークするか、コメントを追加
- タスクの作成、完了、または以下の更新を受信
- AI 生成のサマリーでプロジェクトの最新情報を入手
- Asana タスクのリンクが Slack に貼られると、“Summarize task” ボタンをクリックするだけでサマリーが生成されます。
- Slack で Asana AI に質問して、プロジェクトとタスクの最新の更新、次のステップの特定、主要なブロッカーの発見などを理解できます。
- Asana でルールを作成して、Slack チャンネルへの更新をトリガー。
Google Workspace
Google Docs と Sheets
接続により、Asana プロジェクト/タスクをペーストすると、ドキュメント内で適切にフォーマットされます。タスクを作成するには、Chrome 拡張機能を使う必要があります。
G-Mail
メールスレッドを Asana に同期することで、メールをタスクに変換します。受信トレイに送信される通知から、タスクを完了としてマークしたり、返信したりコメントを投稿したりすることもできます。
Google Drive
Asana アプリを使用している場合、GDrive を接続するには次の手順に従います: (YubiKey が必要です)
- YubiKey が Okta に登録されていることを確認
- このガイドを使って接続プロセスを開始 - https://asana.com/apps/google-drive
- メールアドレスを入力した後、Okta パスワードの入力を求められます。それを入力してください。
- 次に生体認証の使用を求められますが、ポップアップは表示されません。この時点で YubiKey を押すだけで、ログインプロセスが続行されます。
- 数秒間黒いウィンドウが表示されることがあります。このウィンドウを開いたまま、次のステップが読み込まれるのを待ってください。
- アカウントをリンクしたいことを確認します。
Google Calendar
サブリージョンと国のカレンダーは、Asana ライセンスに関係なく Google Calendar 経由で同期できます。Google Calendar 経由でサブリージョンまたは国のカレンダーを購読することに興味がある GitLab チームメンバーは、手順について Asana 内部ハンドブックページ を参照してください。
Chrome ブラウザ
Chrome ブラウザの Asana プラグインを利用して、タスクを素早く作成しプロジェクトに追加します。
Figma
限定的なインテグレーションですが、プロジェクトブリーフ内に Figma ダイアグラムやチャートのライブ埋め込みを表示できます。
Figma で
- プロジェクトブリーフに埋め込みたいファイルを開きます。
- Figma ファイル内の特定のフレームにリンクするには、フレームを選択します。
- ツールバーの Share ボタンをクリックします。
- リンク共有権限を更新して、ファイル埋め込みを表示および操作できる人を決定します（任意）。
- ファイルを埋め込む準備ができたら、Copy link をクリックします。
Asana で
- Figma ファイルを埋め込みたいプロジェクトを開きます。
- Overview タブに移動します。
- Key Resources セクションで、Create a Project Brief をクリックします。すでに Project Brief がある場合は、タイトルの任意の場所をクリックします。
- Brief が開いたら、右上の Edit をクリックします。
- Brief 内で埋め込みたい場所をクリックします。
- Figma リンクをペーストすると、その下にプレビューが展開されます。
- 自分がいる行の左側にある + アイコンをクリックして、Insert Media を選択することもできます。Figma リンクをボックスにペーストし、Embed link をクリックします。
ユーザープロビジョニングガイド
概要
GitLab チームメンバーは Lumos アプリストアを通じて Asana アクセスをリクエストできます。このガイドは、Marketing Operations チームメンバー向けのプロビジョニングプロセスを概説しています。
リクエストフロー
- チームメンバーリクエスト: GitLab チームメンバーが Lumos アプリストア経由で Asana アクセスリクエストを提出
- マネージャー承認: リクエストは自動的にリクエスト者のマネージャーに承認のために送信されます
- Marketing Ops レビュー: マネージャーが承認すると、リクエストはプロビジョニングのために Marketing Operations に転送されます
アクセスエンタイトルメント
マーケティングチームメンバー
- エンタイトル: フル Asana ライセンス
- プロビジョニング方法: SCIM 経由で自動（Lumos で承認）
非マーケティングチームメンバー
- エンタイトル: 閲覧専用アクセス
- プロビジョニング方法: Asana 管理コンソールおよび Lumos 経由の手動招待
プロビジョニングプロセス
Step 1: チームメンバーシップの検証
リクエスト者がマーケティングチームに所属しているかを確認し、アクセスエンタイトルメントを判断します。
Step 2A: フルライセンスリクエスト（マーケティングチームメンバー）
リクエスト者がマーケティングチームに所属しており、フルライセンスをリクエストしている場合:
- Lumos でリクエストを承認
- ユーザーは SCIM を介して自動的にプロビジョニングされます
Step 2B: フルライセンスリクエスト（非マーケティングチームメンバー）
リクエスト者がマーケティングチームに所属していないが、フルライセンスをリクエストした場合:
- Lumos スレッドにコメントして、閲覧専用アクセスのみがエンタイトルされていることを説明
- リクエスト者に閲覧専用アクセスのために具体的にリクエストを再提出するよう依頼
- 元の Lumos リクエストを拒否（リクエストは編集できないため）
Step 2C: 閲覧専用リクエスト（任意のチームメンバー）
閲覧専用アクセスリクエストには、手動プロビジョニングが必要です:
手動招待プロセス
- Asana 管理コンソール に移動
- 右上隅の “Invite Members” をクリック
- 招待ダイアログで:
- Email: リクエスト者のメールアドレスをペースト
- Team: “Add to team” ドロップダウンから
All Marketingを選択 - Projects: 任意で、追加する特定のプロジェクトを選択
- License: ライセンスドロップダウンから “View Only” を選択
- 招待を送信
- 重要: Lumos リクエストで “Confirm Provisioning” をクリック
覚えておくべき重要なポイント
- マーケティングチームメンバー はフルライセンスにエンタイトル
- 非マーケティングチームメンバー は閲覧専用アクセスのみにエンタイトル
- 非マーケティングメンバーからの フルライセンスリクエスト は拒否し、閲覧専用リクエストとして再提出する必要がある
- 閲覧専用アクセス は常に Asana 管理コンソール経由の手動プロビジョニングと Lumos での確認の両方が必要
- 手動招待を完了した後は、必ず Lumos で プロビジョニングを確認 してください
クイックリファレンス
| リクエスト者のチーム | リクエストタイプ | アクション |
|---|---|---|
| マーケティング | フルライセンス | Lumos で承認（SCIM 経由で自動プロビジョニング） |
| 非マーケティング | フルライセンス | コメントし、閲覧専用への再提出を依頼、リクエストを拒否 |
| 非マーケティング | 閲覧専用 | 手動招待 + Lumos で確認 |
