page icon

管理者視点のまとめ

 
 

管理者視点での変更影響

  • チームスペースを運用どう決定するかの議論が必要
      • 1.管理者が必ずチームスペースを作成する or 2.ユーザーセルフに解放する。方針決定が必要です。
      申請式
      ユーザーにチームスペース作成を許可させず、申請にする。チームスペースは管理者が必ずチームスペースオーナーになる。
      良い点
      • チームスペース内のコンテンツを管理者配下で管理できる点。
      • 重複したチームスペースなど、情報共有観点でのコントロールがしやすい
      考慮点
      • チームスペース作成依頼の対応（定常作業の増加）
      • ページ単位のシェアで、チームスペース外でのコミュニケーションは残るという事実。（制限することで、ここに逃げるパターンもあると思います）
      ユーザーセルフ
      誰でもチームスペースを作れるデフォルトの設定です。ワークスペースオーナーは招待されないとチームスペースオーナーにはなれません。
      良い点
      • ユーザーが自由にチームを作り、他部署の影響無くNotionを自由に使える感覚を生み出せます。
      • 運用負荷が少なく運用できます。
      考慮点
      • 別にチームスペース乱立する可能性があります。重複・乱立・分散のリスクはあります。
       
  • 周知をどう対応するか。
      • 少なくともワークスペースがチームスペースに変わります。そして、General/一般 配下に格納されるため、UI差はあります。このUI差については言及の必要があるでしょう。
       
      ただし、チームスペース自体をどこまで周知するかは一考の余地があると思います。リスクとして情報分断を生む可能性があるかつ、移行の手間もあります。それに対してメリットも比較的薄いです。
       
  • 発生するオペレーションの運用検討
      • ユーザーセルフ型の自由にしたら、基本的には管理ありません。ただし、チームスペースをアーカイブすると、ワークスペースオーナーに回収されるので「このチームスペース復元してほしいんですど・・・」等の話は発生するでしょう。
      作業タイミング概要
      チームスペース作成 設定次第ワークスペースオーナーがリクエストに基づき、チームスペースを作成する。
      チームスペース復元必ずユーザーがチームスペースを削除したときの復元をリクエストベースで実施する。
      ワークスペース運用運用次第オープンで運用しましょう。などワークスペースが問題ないかを確認する巡回など。
      ワークスペースオーナーであっても、プライベートのチームスペースは見られないです。旧来のシェアと同じ動きです。
 
  • General （一般）への移行
      • 旧来のワークスペースはGeneralとして勝手に移行されます。特段管理者としてのやることは無いですが、その後のチームスペースオーナーのアサインなどは検討の余地があります。
      例えば…
      • 名前はなんとするのか。
      • チームスペースオーナーは誰にするか？どこまで渡して良いのか、判断基準をどこにするのか。
      • メンバーの入れ替えは誰がやるのか、どのタイミングでやるのか。
      • セキュリティ設定を強くするのかどうか。そのときに、一部分だけに共有されているゲストや一部分だけ外部公開されているページはどのようにチームスペース外に出すのか。
       
  • デフォルトチームスペースの有効化
      • オンボーディングとして何を見せるのか、見せないのか設計が必要でしょう。これは管理者のみが設定可能です。
      ※チームスペース作成を解放したとき、「ユーザーが勝手にデフォルト参加を有効化する」と不都合は発生しません。
 
  • SCIMの考慮
      • SCIMを利用している場合は、チームスペースは特別影響がありません。SCIMのプロビジョニング対象は、ユーザーグループです。
      ユーザーグループはチームスペースにアサインすることができるため、SCIMが機能している組織は、大きな手間はありません。
 

移行に関して

まず、参考までに移行対象ページを例示します。
  • ワークスペース共有内ページのチームスペースとしての独立化
      • 元々ワークスペースレベルのものであれば、オープンとしてチームスペースに再配置するかどうか。が論点になるかと思います。
  • シェアページのチームスペース化
      • クローズドとしてチームスペースに再配置するかどうか。
  • マルチワークスペース統合
      • 複数ワークスペースを持っている会社は、おそらく統合できます。そして、統合した方が管理性も高く使いやすいです。（管理の一元化や監査ログ観点でも）
      しかしながら、移行は非常に面倒と思います。すべてリンクも変わるため、リンク切れやゲストの再適用。外部公開ページはリンクを変える必要があるなど。（別サービスで独自ドメインを付与していないと実質的に移行できないです）
      移行負荷に対して、メリットが少ないです。
 
 
しかしながら、実際のところこれらの移行は任意です。必須では有りません。
 
チームスペースに移行するメリットとは？（再掲）
ユーザー視点だと、「サイドバーのトップレベルに、ページを置けるようになる。」のみです。なので、逆にそれがメリットに感じないならば移行の手間の方が面倒と感じるケースも多くあるかもしれません。
 
 
 
移行作業
同一ワークスペース内の移行の作業自体はとても楽でチームスペースの箱を作り、メンバーを入れ、ドラッグアンドドロップで完了します。
  1. チームスペースを作成
  1. 対象ページを 移動/Move to で移動
  1. 移行完了
 
別ワークスペースの場合は少し手間ですが、大枠は同じです。URL等が変わる点だけ注意が必要です。
 
 
移行後の再構築
一番論点になるポイントは移行後のページ構成です。ここは、よく使うページをトップレベルに移動し、逆にあまり使わないページは子ページに残し、メンバー達がどのようにNotionを使っているかの分析ヒアリングのもと、再構築が必要です。
 
たとえば、「１つのページをお気に入りし、そのページ内で多くのコミュニケーションが完結している場合」、下記のような再構築が考えられます。
 
今回用にカスタマイズするならば…
Before
 
After
 
Point
  • よく使う”機能” の社員一覧、タスク、議事録をトップレベルへ昇格
  • サイドバーに雑多に並んでいた、ページ群をHomeに集約
  • 見出しとして表現していたページ群を、1ページ階層化
  • お知らせを周知しやすいようにDB化 & トップページへ
 
 
設計単位
設計は、コミュニケーションの単位で考えるのがよいと思います。例えば、全社、部署、プロダクト/プロジェクト、機能（タスクなど）
そして、揮発性があるかどうか。つまり、このチームスペースが中長期的に続くかどうかも検討のポイントです。3ヶ月で終わるプロジェクトが複数あります。というパターンにはそれごとにチームスペースを作るのは向いていません。
 
 

セキュリティ編

 
  • チームスペースごとに設定可能に。
      • ただし、基本的にはワークスペースの設定を継承して、セキュリティを強める上書きしかできない。
      ※ワークスペースオーナーはセキュリティを弱める上書きもできる。
       
  • セキュリティ観点で、チームスペース作成を解放してOK。
      • セキュリティ観点単体だと問題ありません。チームスペース作成を解放しても、権限を弱める方向に上書きできません。ワークスペースオーナーだけです。つまり　メンバー権限の方が作るのであれば、脆弱なチームスペースは生まれません。
      いわゆるホワイトリスト運用です。
 
 
  • 社外向けワークスペース共有はなくせる
      • なくせます。「外部共有やゲストを有効化したワークスペースには、WSオーナーが必ず入り有効化する」等の運用で、外部公開の場所をコントロールできます。
      ワークスペースでゲスト禁止にして、外部共有/外部公開用 チームスペースを作り、そこで、ワークスペースオーナーが、セキュリティを上書きする。メンバーにはフルアクを与えない。これで、問題ありません。
       
  • ワークスペースのセキュリティは緩めてはダメ
      • シェアやプライベートはワークスペースの設定に依存するので、チームスペースのみで絞ることはできません。
       
  • ワークスペースとチームスペースのセキュリティ設定概念に
      • 以前はワークスペースのセキュリティを意識していれば、問題なかったです。チームスペースはセキュリティの上書きができるので、例外パターンを考慮する必要があります。
      考える変数が増えました。