GitHubの日本および韓国のマーケティングチームは、登録ページ、リンク、メールキャンペーン、顧客データベースの間で各手順を手作業で管理する代わりに、繰り返し発生するイベント業務をGitHub内の実行可能なワークフローへ変換しました。Tomoko Tanakaによると、プロセスは1つのGitHub Issueから始まり、その後GitHub Actionsがイベントの準備、登録者リストの確認、終了後のフォローアップ業務を担います。
この記事は新製品のローンチを紹介するものではなく、Tanakaが既存のGitHubツールを使って発展させた運用方法を紹介するものです。そこでは、GitHub Copilotを活用して社内の手順書を自動化へ変換しています。この取り組みの重要性は、マーケティング管理と、ソフトウェアチームにとってなじみ深いレビュー、変更履歴、トリガー、再現可能なワークフローといった概念を結び付けている点にあります。
課題：小さな手順と連鎖するエラー
チームのイベントには、エンタープライズ開発者向けの定期的なウェビナー、東京でのコミュニティミートアップ、ソウルでのエグゼクティブ向け非公開セッションが含まれます。イベントが承認されると、ランディングページのコピー、各チャネル用のUTMタグ付きリンクの作成、招待メールの準備、送信申請の登録、2つのプロジェクトボードへのイベント追加、そしてイベント当日までの登録者リストの毎日のダウンロードとクレンジングという、一連の繰り返し作業が始まります。
イベント終了後には、参加者リストをエクスポートし、顧客関係管理システムへのアップロードに適した形式へ再構成し、レコードに適切なラベルを付け、レポートを作成する必要があります。個々の手順は難しく見えませんが、リンク、キャンペーン名、または日々の更新におけるミスが、レポートや後続の業務に影響を及ぼす可能性があります。
ワークフローを構築する3つの要素
この取り組みでは、GitHubの3つの主要な機能を利用しました。
- Issue Forms：空のテキストボックスの代わりに、構造化された依頼フォームとして機能し、イベント名、日付、地域、キャンペーン名、対象オーディエンスなどの項目を収集します。ウェビナー用と対面イベント用に異なるフォームがありますが、同じ実行メカニズムへ情報を渡します。
- Labels：単なる説明用のラベルではなく、実行キーとして使用します。たとえばevent-setupのようなラベルを追加すると、それに関連付けられたワークフローが開始されます。
- GitHub Actions：タスクを実行し、依頼本文に含まれる項目を読み取り、外部ツールへ接続してイベントの準備、登録者のフォローアップ、または終了後の処理を行います。
この設計により、Issueは計画、議論、ステータスを集約する作業単位となり、意思決定の可視化された履歴と、各変更へのリンクを提供します。また、ワークフローの変更をコード変更として扱い、プルリクエストとレビューを経てからマージすることもできます。
手順を自動化へ変換するGitHub Copilotの役割
Tanakaは、いきなりコードを書くことから始めたのではありません。チーム独自の運用手順書を作成してGitHub Copilotに提供し、その後、対話を通じて自動化を発展させました。彼女は、Linuxサーバー上でデータベースを運用した過去の経験が、これらの手順をプログラム可能なパイプラインとして捉えるのに役立ったと述べています。一方で、自分のプログラミングスキルは以前ほどではないとも認めています。
計画は、11月にAIを活用した開発に関するウェビナーを開催するといったアイデアを説明する対話から始まります。その後、CopilotはリポジトリのルートにあるAGENTS.mdファイルを読み取ります。これはMarkdown形式で記述されたガイドで、キャンペーンの命名規則、会計四半期と日付の対応、タイムゾーン、招待メールの基準を定めています。これらのルールと、過去の類似イベントに基づき、Copilotはキャンペーン名を提案し、招待メールの文面を2種類作成し、運用手順書が求める質問を提示します。
実務上、何が変わるのか？
この方法により、計画段階での人間による意思決定をなくすことなく、繰り返し発生する手作業を削減できます。対話によって個別イベントのカスタマイズの余地を残しながら、承認後は自動化が固定された手順を実行します。この記事によると、イベントの準備には以前、手作業でおよそ2日かかっていましたが、現在は1つのIssueから始まり、準備、登録者リストの日次確認、イベント終了後のクレンジングまでを実行できるようになりました。
決定的な要素はGitHub Actionsだけではなく、他のツールもプログラムから扱えることです。イベント管理プラットフォームはAPIを提供し、顧客関係管理システムは必要なタスクをカバーする公式CLIに対応しており、ブラウザー経由でログインできるため、TanakaはAPIキーを設定する必要がありませんでした。この記事から導ける原則は、APIまたはCLIがあれば、プログラムによる連携への道が開かれるということです。対象はイベントプラットフォーム、CRMシステム、フォームビルダー、分析サービスのいずれでも構いません。
この事例は、多市場環境でカスタムワークフローを構築することが好まれる理由も示しています。APACチームは単一市場として活動しているわけではありません。同じウェビナーを東京では日本語、ソウルでは韓国語で開催することがあり、対象セグメント、CRM項目、質の高い見込み顧客の定義基準も異なります。Tanakaは、既製プラットフォームをこうした違いに合わせるには、カスタマイズやコンサルティングの予算が必要になり、ベンダーのロードマップを待たなければならない場合がある一方、内製すればプルリクエストとレビューによってワークフローを変更できると述べています。
これは、既製のマーケティングプラットフォームをなくすための処方箋でも、自動化がすべてのチームに適していることを示すものでもありません。ここで紹介された事例の実務的な価値は、まず業務を文書化し、柔軟な人間の判断が必要な意思決定と、自動実行できる繰り返し手順を分離する点にあります。また、このモデルの成功は、外部ツールが連携可能であることと、運用手順書の正確さにかかっています。ルールが不完全だったり、更新されないまま変更されたりすると、エラーが消えるのではなく、自動化されたワークフローへ引き継がれる可能性があります。