招待フロー
以下のステップに沿って招待を進めます。
Step 1：招待提案
招待提案ができるのは、山本、および山本が指定したメンバーに限ります。
招待提案の権限
- 山本は常時招待提案が可能
- その他のメンバーは、山本から招待提案権限を付与された場合に提案可能
- 権限の付与・解除は山本が管理する
提案時に整理する情報
- 候補者の名前・背景・専門領域
- 既存メンバーとの関係性（√N ルールの充足確認）
- 招待の理由・期待する貢献
Step 2：事前告知（#all-general）
招待実施の 3〜5 日前に、ワークスペース内で告知を行います。
告知内容
- 候補者のプロフィール概要
- 既存メンバーとの関係性（mention でざっくり示す程度で OK）
招待理由・期待する貢献は告知文には載せません（運営内の判断材料としてのみ扱います）。
告知期間中のチェック
- 利害関係のチェック：ビジネス上の競合・利益相反がないか
- 人間関係のチェック：既存メンバーとの間に懸念がないか
Step 3：同意確認
本フローでは、ソシオクラシー（Sociocracy）の**「同意の原則（Consent Principle）」**を採用します。
同意（Consent）とは
- 「全員が積極的に賛成する」こと（＝コンセンサス）ではなく、**「重大な反対意見（Objection）がない」**ことをもって同意とみなす考え方
- 「ワークスペースの安全性を損なう」といった理由のある反対のみが「反対意見」として扱われる
- 「どちらでもいい」「特に意見はない」は同意とみなす
なぜコンセンサスではなく同意なのか
- コンセンサスは全員の積極的な賛成を求めるため、意思決定が停滞しやすい
- 同意の原則では、「反対の理由がない限り前に進める」ため、スピーディかつ全員の安全性を担保できる
- 多数決とも異なり、少数の声が埋もれるリスクを回避できる
運用
- 告知期間中に反対意見（Objection）が提出されなければ、招待に同意したものとみなす
- 反対意見がある場合は、Step 4（アラート申告）で提出する
Step 4：アラート申告（必要な場合のみ）
「この人が苦手」「関係性的に難しい」などの懸念がある場合は、専用フォームからアラートを提出してもらいます。
アラートフォームの要件
- アラートの提出者は記名制とする（匿名ではない）
- ただし、アラートを出したこと自体が不利益にならないよう、心理的安全性を運営が責任を持って保証する
- 提出内容は運営のみが閲覧可能とし、他メンバーには開示しない
- 具体的な理由の記載は任意（心理的負担を最小化）
Step 5：アラート発生時の対応
- アラートが 1 件でも上がった場合、原則として招待を取りやめる（既存メンバー優先ポリシーを厳格に適用）
- アラートの内容はナレッジとして保存し、将来の判断材料として活用する
- 個人が特定されない形で記録を残す
- 同一候補者について再度招待提案があった場合に参照する
招待手続き（アラートなしの場合）
同意期間中にアラートが発生しなかった場合、以下の手順で候補者を招待します。
- 運営は、管理アプリ
tied-workspace-adminで、配信する招待リンク（Slack ワークスペース参加リンク）とメール文面をあらかじめ設定しておく - 候補者に内製の ご招待フォーム を案内する
- 候補者がフォームで利用規約に同意して送信すると、同意が記録され、設定済みの招待リンクが自動でメール配信される
招待リンクの送付はフォーム送信時に自動で完結するため、運営側の追加作業は不要です（従来の Notion フォーム + Notion オートメーションを内製アプリへ置き換えました）。
フロー全体図
mermaid
flowchart TD
A["招待提案"] --> B["√N ルール確認"]
B -->|未充足| Z["招待見送り"]
B -->|充足| C["ワークスペース内に事前告知<br>（3〜5 日前）"]
C --> D{"アラートの有無"}
D -->|アラートなし| E["候補者にご招待フォームを案内"]
E --> F["候補者が利用規約に同意して送信"]
F --> G["同意を記録し<br>招待リンクを自動でメール配信"]
G --> H["招待完了"]
D -->|アラートあり| I["招待取りやめ"]
I --> J["ナレッジとして保存"]