マーケティングチームは一緒に働く。今やSTRATUMもそうなった。

「まだアルファなのに、なぜチーム機能を作っているんですか？」

もっともな質問です。ユーザーは50人未満。ほとんどのSaaSファウンダーなら、チームについて考える前に100ユーザーに達することに集中するでしょう。

でも、アルファユーザーを観察してわかったことがありました——彼らは一人で働いていなかった。マーケティングディレクターはCEOにスクリーンショットを送っていた。エージェンシーオーナーはAIの出力をWhatsAppで友人にコピペしていた。ファウンダーは妻にメールを転送していた。

広告業界で18年間働いてきた私には、これは驚くべきことではないはずでした。マーケティングは決してソロの活動ではありません。エージェンシーのフロア全体が、Slackのスレッド、メールの転送、「それスクリーンショットしてもらえる？」というリクエストが混ざり合った混沌の中で動いているのを見てきました。それが実際のチームコラボレーションの姿——そして、それは苦痛です。アルファ版で同じパターンが現れたとき、無視するわけにはいきませんでした。

だからチームコラボレーションを構築しました。アルファの段階で。「賢い」ファウンダーなら待っていたはずのところで。:P

出荷したもの、それをこの形で作った理由、そして途中で学んだことを共有します：

1. 全員に適切なアクセスを — SMEとエージェンシーチームが実際に機能する15のロール、エージェンシーのためのクライアントレベル分離

2. 往復なしで一緒に働く — 承認ワークフロー、コメント、タスク、通知が「私のメッセージ見た？」というSlackスレッドに取って代わる

3. 新入りが即座に生産的に — 招待 → ロール割り当て → 仕事開始。30秒、3日じゃない。

出荷されたもの、チームにとっての意義、そしてそれを機能させた判断の詳細をお伝えします。

---

「ログインを共有すれば？」の本当のコスト

これらの機能が実装される前、チームがSTRATUMをどう使っていたかを見てみましょう：

オプションA：認証情報を共有する（セキュリティの悪夢）

- 全員が同じログインを使用

- 誰が何をしたかわからない

- 一人がパスワードを変更したら全員がロックアウト

オプションB：別々のアカウント（高コストで断片化）

- 各自が別々に支払い

- AIの出力は別々のアカウントに分散

- 「そのストラテジーをエクスポートして送ってもらえる？」

オプションC：スクリーンショットとコピペ（現実）

- 一人がAIエージェントを動かす

- スクリーンショットかコピペでチームメートに共有

- コンテキストが失われ、フォーマットが崩れ、誰も作業を積み上げられない

これらはどれも本当のコラボレーションではありません。回避策です。

ビジネスコスト？ あるエージェンシーオーナーが1日に20分、AIの出力をツール間で移動させるだけに費やしているのを見ました——メールを転送し、Google Docsで再フォーマットし、元の会話を見られないチームメートに文脈を再説明して。

それで年間80時間以上。一人が。一つのチームで。

---

機能1：ITの手間なく全員に適切なアクセスを

広告業界で18年間の経験から、マーケティングチームがどう機能するかは正確にわかっています：異なる人々が異なるものへの異なるアクセスを必要としています。

シニアストラテジストはクライアントAとクライアントBで働く。ジュニアアナリストは小さなアカウントで学んでいる。フリーランスのクリエイターは割り当てられたクライアントだけに関わる。そして、見るべきでないクライアントデータは絶対に誰も見てはいけない。

これはコスト管理の話だけではありません（それも重要ですが）。チームが実際にどう機能するかの話です。

2つの権限モデル：SMEとエージェンシー

3人のスタートアップと15人のエージェンシーでは、ワークフローがまったく異なることはかなり早い段階で理解しました。一つの権限モデルに押し込もうとするのは混乱のもと——エンタープライズツールがそれをやっているのを見てきましたが、常に小チームが複雑さに溺れ、大チームはコントロールが足りないという結果になります。だから、2つの異なるモデルを構築しました。

SMEロール（5ロール）

シンプルな階層を持つ中小企業向け：

|------|-------------|-----------------|-----------------|

なぜこの5つ？ SMEマーケティングチームで実際に見たロールをマッピングしました。何でもこなすオーナー。戦略を設定するディレクター。実行するマネージャー。測定するアナリスト。状況を把握するだけでいいVAや経理担当者。

エージェンシーロール（10ロール）

複雑なチーム構造で複数クライアントを管理するエージェンシー向け：

|------|-------------|--------------|-----------------|

クライアントスコープロール

はエージェンシーにとってのゲームチェンジャーです。アカウントマネージャーをクライアントAに割り当てると、クライアントBのデータは文字通り見えません。「UIで隠す」のではなく——データベースレベルで強制されます。

クライアント割り当て管理

エージェンシーチームでは、チーム管理ページにクライアントアクセスカラムが表示され、各チームメンバーがどのクライアントにアクセスできるかが一目でわかります。任意のチームメンバーのアクションメニューをクリックすると：

- 「全クライアント」アクセスを付与： 新しいクライアントが自動的に見えるようになります

- 特定クライアントを割り当て： 見るべきクライアントを正確に選択

- いつでも割り当てを更新： クライアントポートフォリオの変化に合わせてアクセスを変更

つまり、クライアントAのアカウントマネージャーは、直接APIリクエストを作ったとしても、クライアントBのダッシュボード、キャンペーン、AIの出力を文字通り見ることができません——フィルタリングはUIではなくデータベースレベルで行われるからです。

新しいチームメンバーのオンボーディング： 誰かを招待するとき、同じフローでロールとクライアントスコープの両方を選択します。別のステップは不要。アクセス制限を忘れることもありません。

権限対応UI

これを実際に使えるものにしているのは：UIがロールに合わせて変わることです。

チームメンバーを招待できなければ、チーム設定は見えません。クライアントにアクセスできなければ、そのクライアントはダッシュボードに表示されません。エージェントを実行できなければ、ロックされた状態で明確なインジケーターが表示されます。

「クリックしてみたらエラーが出た」はもうなし。「なぜ見えるのに何もできないんだ？」という混乱もなし。

エージェンシーディレクターへ： クリエイターにはクリーンで集中されたインターフェース——自分のツールだけが見えます。トレーニングが減り、ミスも減ります。

ファウンダーへ： ビューアーロールのVAにはシンプルなダッシュボードが見えます。圧倒されることなく、必要なものを見つけてコピーできます。

37の細かい権限（触る必要はありません）

これらのロールの背後には37の個別権限がありますが、手動で設定する必要はありません。各ロールはマーケティングチームが実際にどう機能するかに基づいて事前に設定されています：

| カテゴリ | なぜ重要か |

|----------|----------------|

| AIエージェント（9） | クリエイターが間違ったクライアントで戦略エージェントを誤って実行しない |

| キャンペーン（6） | アナリストはレポートのためにキャンペーンを閲覧できるが、誤ってアーカイブはできない |

| クライアント（5） | 新しいクライアントを追加できるのはオーナーと管理者だけ——データの肥大化を防ぐ |

| アナリティクス（3） | 全員が基本的な統計を見られる；エクスポートはアナリストだけ |

| ドキュメント（3） | 機密アップロードを保護——VAは閲覧できるが削除はできない |

| 組織（4） | 請求アクセスはオーナー限定——「誰がプランを変更した？」という驚きをなくす |

| チーム（3） | マネージャーはオーナーの承認なしに友人を招待できない |

| ワークスペース（2） | 全員が新しいワークスペースを作成しないように整理 |

| 管理者（2） | システム機能は何をやっているかわかる人のためだけ |

各ロールは仕事に必要なものだけを持ちます——それ以上でも以下でもなく。ロールを一度設定すれば、権限は自動的についてきます。

---

機能2：スクリーンショットとSlackスレッドを追いかけるのをやめる

これは私が最もこだわった機能です。権限は誰が何をできるかをコントロールしますが、コラボレーションはどうやって一緒に働くかについてのもの——そして私の経験では、往復が実際に一日を消費するものです。私はエージェンシー側でこの問題を20年間生きてきました :D

共有キャンペーンとAI出力

旧モデル： あなたのキャンペーン。あなたのAI出力。あなたのサイロ。

新モデル： 組織スコープのコラボレーション。

ストラテジストがペルソナエージェントを実行すると、そのペルソナは個人アカウントではなく組織のものになります。コピーライターは：

- スクリーンショットを求めずにペルソナを見られる

- コンテンツエージェントを実行するときにそれを参照できる

- ゼロから始めるのではなく積み上げられる

アナリストが競合分析を生成すると、マーケティングディレクターは転送されたPDFではなく直接レビューできます。

承認ワークフロー

コンテンツは作成されるだけでなく——公開前にレビューと承認が必要です。

|----------|-----------|-------------|----------|

仕組み：

1. クリエイターがコンテンツ作品を完成 → 「承認をリクエスト」をクリック

2. アカウントマネージャーが通知を受信 → 文脈の中でレビュー

3. メモ付きで承認・却下・変更リクエスト

4. クリエイターが決定を通知される

5. 変更リクエストの場合 → 修正して再提出（ラウンド追跡）

「クライアントAのコピーについてのメールは見た？」というSlackスレッドはもう不要です。

コメントとメンション

AIが生成した作業について、失われてしまうSlackスレッドではなく、出力に直接コメントして議論できます。

- 任意のキャンペーン・出力・ペルソナへのスレッドコメント

- 特定のチームメンバーに通知する**@メンション**

- 対応済みかどうかがわかる解決追跡

- エージェンシー向けのクライアントスコープ——フリーランサーは担当クライアントのコメントだけ見えます

タスク割り当て

SMEマーケティングディレクターへ： 誰が何をしているかをスプレッドシートで追うのをやめましょう。出力から直接、コンテンツ作成・レビュー・キャンペーンタスクを割り当てる——チームは自分の作業キューを見て、あなたはステータスを見るだけ。

エージェンシーアカウントマネージャーへ： クライアントの成果物をスケジュール通りに。クライアントスコープ内でタスクを割り当て、優先度と期日を設定し、何かブロックされたらすぐにわかります。

仕組み：

- タスクタイプ：コンテンツ作成・レビュー・分析・キャンペーンセットアップ

- 優先度レベル：低・通常・高・緊急

- 期日が近づいたときの期限通知付き期日

- リンクされたリソース：タスクは特定のキャンペーンや出力に紐づく——「どのドキュメントの話？」はなし

- ステータス追跡：未着手 → 進行中 → レビュー中 → 完了

ロール階層がすっきり保ちます——アカウントマネージャーはクライアントスコープ内で割り当て、ディレクターはチームに割り当て、オーナーは誰にでも割り当てられます。

リアルタイム通知：注意が必要なことを見逃さない

忙しいマーケティングディレクターとエージェンシーオーナーへ： 誰かが必要としているかどうかを確認するために5分ごとにSlackをチェックするのをやめましょう。STRATUMは、いつアクションが必要かを正確に教えます：

- 誰かがあなたの承認をリクエスト → すぐにわかります

- あなたの承認リクエストが解決 → 「見てもらえた？」と不安にならなくていい

- コメントで@メンションされた → 関連する会話があなたを見つける

- タスクが割り当てられた → 作業キューに表示される

- 期日が近づいている → 遅れる前に警告される

通知はアプリでリアルタイムに表示され、見逃した場合はメールダイジェストにまとめられます。

---

機能3：新入りが3日ではなく30秒で生産的に

以前： 新しいチームメンバーが加わる際のプロセス：

1. 別々にサインアップ

2. 手動で組織に追加するよう私にメール

3. データベースでロールを割り当て

4. ログインして……うまくいくかも？

今：

1. 設定 → チーム → 招待

2. メールアドレスを入力してロールを選ぶ

3. リンクをクリックしてパスワードを設定

4. 入れた。適切な権限で。即座に。

なぜ30秒が重要なのか

新しいアナリストをオンボーディングするマーケティングディレクターに：3日目ではなく、初日から生産的になれます。

フリーランスのクリエイターを追加するエージェンシーオーナーに：ITチケットなし、待ち時間なし、「明日やります」もなし。

VAを採用するファウンダーに：Slackメッセージを送る時間でビューアーアクセスを付与できます。

これを可能にした技術的な選択

ほとんどのプラットフォームはメール確認フローを使います：招待 → 確認メール → リンクをクリック → パスワードを設定 → さらに確認 → やっとログイン。

私は冗長な確認をスキップしました。招待メールを受け取ったなら、そのメールアドレスを所有していることはすでに証明しています。なぜ2回証明させるのですか？

招待リンクは安全で、サーバーに保存されており（誰かが改ざんできるURLパラメータではなく）、7日間で期限切れになります。承認すると、すべてが一つのステップで起こります：

1. アカウントが作成される

2. 適切な組織に追加される

3. ロール権限が割り当てられる

何かが失敗すれば、何も作成されません。中途半端なアカウントなし。権限の欠落なし。「招待したのに何も見えない」というサポートチケットなし。

---

多層防御：データ分離の構築方法

このセクションはほとんどの読者に必要以上に技術的かもしれませんが、特にクライアントデータを私に信頼してくれているエージェンシーユーザーのために、セキュリティについての考え方を透明にすることが重要だと思います。まだプライベートアルファですが、アーキテクチャで妥協したわけではありません。データ分離はDay 1から構築されていました——後で追加されたものではありません。ここに多層アプローチを示します：

Layer 1：データベースレベルの強制（Row Level Security）

権限はアプリケーションコードだけでチェックされるのではなく——データベース自体がPostgres Row Level Security（RLS）を使って強制します。すべてのクエリは自動的に組織でフィルタリングされます。アナリストは別の組織のデータを見ることができません。なぜなら、データベースがそれを返さないからです——アプリケーションが何をリクエストしても。

クライアントスコープロールの場合、2番目のRLSポリシーが割り当てられたクライアントでフィルタリングします。クライアントAのアカウントマネージャーは、直接APIリクエストを作っても、クライアントBのデータにアクセスできません。

Layer 2：アプリケーションレベルの権限チェック

UIも同じ権限ルールを尊重します。クライアントにアクセスできなければ、ダッシュボードに表示されません。エージェントを実行できなければ、ボタンが無効になります。ナビゲーション・ボタン・ページはすべて同じ権限ソースをチェック——「UIでは表示されるのにAPIでは却下される」という非一貫性はありません。

Layer 3：アトミックトランザクション

招待承認のような重要な操作は単一のデータベーストランザクションとして発生します。アカウント作成・組織への追加・ロール割り当て・クライアントアクセス設定——すべてが一緒に成功するか、すべてが一緒に失敗します。中途半端な状態なし。孤児レコードなし。

Layer 4：サーバーサイドの秘密情報

招待の詳細（組織・ロール・クライアント割り当て）はサーバーに保存され、セキュアなトークンで参照されます。招待URLにはトークンだけが含まれます——それを改ざんしても、実際の権限はデータベースに存在するため、異なるアクセスは付与されません。

---

アルファの透明性： これらの層を意図的に構築しましたが、私たちは小さなチームであり、STRATUMはまだ進化中です。アルファ期間中に私たちが保証できることとできないことについては、プライバシーポリシーと利用規約をご覧ください。

---

なぜアルファでこれを構築したのか？

正直な答えは：マルチテナント機能をあとから追加するのは過酷だからです。

ローンチ後にマルチテナント機能を追加しようとした企業を見てきました。それは悪夢です。すべてのテーブルに新しいカラムが必要になる。すべてのクエリに新しいフィルタが必要になる。すべての権限チェックを書き直す必要がある。データマイグレーションは恐ろしい。

STRATUMはDay 2から組織スコープのデータで構築しました（それはまた別の話）。アーキテクチャはチームの準備ができていた。機能は……作るだけでよかった。

50人のユーザーでチーム機能を構築するということ：

- 高速なイテレーション： 出荷し、フィードバックを得て、数ヶ月ではなく数日で修正できる

- 実際の使用パターン： チームが実際にどうコラボレーションするかを見られる——想像していた方法ではなく

- マイグレーションリスクなし： 壊すべき既存のチームワークフローがない

代替案——1,000人のユーザーになるまで待ってから「サプライズ、チームのために全ワークフローを再構築してください」と言う——はもっと悪そうです。

今すぐ試す

チーム機能はすべてのSTRATUMユーザーに公開されています。

既存ユーザーの方：

1. 設定 → チームに移動

2. 「チームメンバーを招待」をクリック

3. 30秒でオンボーディングするのを見る

新規の方：

stratum.chandlernguyen.comでアルファアクセスをリクエストしてください。リクエストに「チームコラボレーション」と記載してください——私はまだ「すべてのユーザーと話す」フェーズにいるので、これらの機能があなたのチームにどう合うか一緒に確認したいです。

---

型破りな賭け

アルファでチーム機能を構築するのは型破りです。ほとんどのアドバイスは：まずユーザーを獲得し、コラボレーションはあとで追加すると言います。

でも、チームはマーケティングが実際に機能する方法です。マーケティングディレクターは一人で戦略を作りません。エージェンシーオーナーは一人でクライアントアカウントを管理しません。コラボレーションはあったらいい機能ではなく——それが仕事が成し遂げられる方法です。

チームのために最初から構築するということは、STRATUMがあなたと一緒に成長することを意味します。一人で始め、準備ができたら最初のチームメートを招待し、プラットフォームを切り替えることなくフルエージェンシーチームまでスケールできます。

この賭けは間違っているかもしれません。でも、アルファユーザーが共有機能のなさを回避するためにスクリーンショットやコピペをしているのを見ていると……間違っていないと思います。

結局のところ、プロダクトを構築することは、実際の人々の実際の問題を解決することについてです——「1,000人のユーザーになるまで待て」というプレイブックに従うことではありません。1,000人という数字を追いかけるより、今この50人のユーザーが実際に必要としているものを作りたい。

もしあなたがマーケティングチーム（またはエージェンシー）を運営しているなら、今日どうコラボレーションしているか本当に聞いてみたいです。「スクリーンショットとコピペ」派ですか？「一つのログインを共有」派ですか？もっといい方法を使っていますか？教えてください——まだ学んでいる最中で、すべての会話がこれをより良く構築する助けになります。

よろしくお願いします、Chandler

DIALØGUEも構築中です——AIポッドキャスト生成に「早めにチームのために構築する」という同じ考えを適用するとどうなるか興味があれば、ぜひチェックしてください。