Space 設計のベストプラクティス
Space 設計のベストプラクティス
チームやプロジェクトに合った Space の分け方・命名・運用の指針です。
Space を分ける判断基準
| 分けるとよい | 1 つにまとめるとよい |
|---|---|
| 公開範囲が異なる（社外秘 / 部門限定） | 全員が同じドキュメントを共有する小規模チーム |
| 管理者・メンバーが明確に異なる | ページ階層だけで十分整理できる |
| 監査・承認フローが独立している（EE） | プロトタイプ段階で試験運用中 |
目安: 「このメンバーだけに見せたい」が 1 つでもあれば、別 Space を検討します。
命名とスラッグ
| 項目 | 推奨 |
|---|---|
| 名前 | チーム名・プロダクト名で一目で分かる表記 |
| スラッグ | 英数字のみ（engineering、product-docs は不可 → productdocs） |
| 説明 | Space の目的を 1〜2 文で記載（新メンバーのオンボーディング用） |
→ 作成手順: 「Space の作成と設定」（No.5.2）
Open と Private の選び方
| 種類 | 向いているケース |
|---|---|
| Open | 社内 Wiki、全員が閲覧・参加できるナレッジベース |
| Private | 人事・法務・未公開プロジェクトなど限定共有 |
Open でもページレベル権限（EE）で細かく制限できますが、Space 境界は最初に決める のが運用しやすいです。
→ 詳細: 「Open / Private Space と参加方法」（No.5.3）
メンバーとロール設計
| ロール | 割り当ての目安 |
|---|---|
| Admin | Space 責任者・情報整理担当（少数） |
| Writer | 日常的にドキュメントを書くメンバー |
| Reader | 閲覧・コメントのみのステークホルダー |
グループ（WS 横断）と組み合わせると、大規模組織でも管理しやすくなります（No.8.3）。
ページ階層との役割分担
ワークスペース
└── Space（チーム・プロジェクトの境界）
└── ページ階層（トピックの整理）
└── ラベル（横断分類）
- Space … アクセス制御とゴミ箱・エクスポートの単位
- ページ階層 … ドキュメントの論理構造
- ラベル … ステータスやカテゴリの横断検索
運用チェックリスト
- Space の目的を description に記載した
- Open / Private を決めた
- Admin / Writer / Reader を適切に割り当てた
- ルートページまたはテンプレートで初期構成を用意した
- 命名規則をチームで共有した（No.4.10）
- 定期レビュー・検証の方針を決めた（No.6.5、EE: No.4.9）
関連ナレッジ
- Space 概要: 「Space とは — いつ・どう分けるか」（No.5.1）
- 作成: 「Space の作成と設定」（No.5.2）
- メンバー: 「Space メンバーとロール」（No.5.4）
- ページ設計: 「ページの設計と書き方」（No.4.10）
- 運用サイクル: 「ドキュメント運用サイクル」（No.6.5）