はじめに
Boxを企業間のファイル共有に利用している環境は多いと思います。
1社対1社のファイル共有であれば、
- フォルダを作成する
- 外部ユーザーを招待する
- 権限を設定する
- ファイルを共同利用する
という比較的シンプルな構成で運用できます。
ところが、自社が「Boxを共有する側」ではなく、複数の顧客からBoxフォルダを共有される側になると、少し違った問題が見えてきます。
例えばSIer、コンサルティング会社、業務委託会社などでは、
- A社からプロジェクトフォルダを共有される
- B社からも別のフォルダを共有される
- C社からも共有される
- さらに自社所有のBox領域も利用する
という状態が発生します。
個々の共有設定には問題がなくても、受け手側から見ると徐々に情報を整理しにくくなります。
この記事では、この問題を「Boxが使いにくい」という話ではなく、クロステナント共有における情報設計の問題として考えてみます。
Boxの共有は「所有者起点」で考えると分かりやすい
Boxの企業間共有では、まず「誰がフォルダを所有しているか」を意識する必要があります。
例えばA社が以下のフォルダを作ったとします。
A社プロジェクト
├─ 01_管理
├─ 02_設計
├─ 03_テスト
└─ 04_移行
ここへ自社の担当者が招待されます。
A社から見れば、この構造は非常に分かりやすいものです。
一方、B社では次のような構成かもしれません。
システム更改
├─ PJ管理
├─ 要件定義
├─ 基本設計
├─ テスト
└─ 移行
C社はさらに違う構造を採用しているかもしれません。
それぞれ単独で見れば、特に問題はありません。
問題になるのは、これらを全部受け取る人の画面です。
受け手側には、複数企業の情報設計が集まってくる
複数の顧客から共有されると、自分のFilesには例えば次のような入口が並びます。
Files
├─ プロジェクト
├─ システム更改
├─ 共有
├─ PJ共有
├─ 開発
└─ 自社共通
それぞれを所有している会社から見れば意味のある名前でも、受け手からすると、
この「共有」はどの会社だったか？
という問題が発生します。
さらに案件数が増えると、
共有
プロジェクト
PJ共有
プロジェクト共有
システム更改
システム更改PJ
といった似た名称が増える可能性があります。
ここで発生しているのはアクセス権限の問題ではありません。
情報の発見性の問題です。
共有そのものには成功しています。
しかし、受け手が「どの顧客の、どの案件の、どの情報なのか」を判断するためのコストが増えています。
受け手側では自由に再設計できない
ここが通常のファイルサーバーとの違いとして意識したいところです。
顧客が所有するBoxフォルダは、当然ながら顧客側の管理下にあります。
受け手側が、
自社ではこの構造の方が使いやすいから全部組み替えよう
とはできません。
基本的には、所有者が設計した入口を受け入れることになります。
そのため、顧客が増えるほど、
複数企業がそれぞれ最適化した情報設計を、一つのFiles画面で受け取る
という状態になります。
これは技術的な共有可否とは別の問題です。
Box Driveにすると「企業の境界」がさらに意識しにくい
Box Driveを使うと、Box上のファイルをWindowsのエクスプローラーから扱えます。
これは非常に便利です。
普段利用しているファイルと同じ感覚で、
Box
├─ A社案件
├─ B社案件
├─ C社案件
└─ 自社資料
へアクセスできます。
しかし、複数企業との仕事を並行している場合には、別の視点も必要です。
人間の業務としては、
A社の仕事
↓
B社の仕事
↓
自社業務
とコンテキストを切り替えています。
一方、エクスプローラー上では単純に、
フォルダA
↓
フォルダB
↓
フォルダC
と移動しているだけです。
つまり、ファイルシステム上の移動と業務上の境界が一致していません。
ドライブを切り替える方が分かりやすい場合もある
従来のファイルサーバーであれば、例えば、
X: A社
Y: B社
Z: 自社
のように業務領域を分離する設計も考えられます。
利用者からすると、
今はXドライブなのでA社の仕事をしている
という認識を持ちやすくなります。
一方、Box DriveではBoxという一つの入口から各共有フォルダへアクセスする形になります。
そのため、複数顧客から共有を受ける利用者にとっては、顧客単位で仮想ドライブそのものを切り替えるような感覚を作りにくいと感じることがあります。
これはBox Driveの問題というより、ファイル共有サービスと人間の業務コンテキストの違い、と考えた方がよいかもしれません。
欲しいのは「フォルダ切り替え」ではなく「コンテキスト切り替え」ではないか
この問題を考えていて思ったのは、複数顧客と仕事をする人が本当に切り替えたいのは、
フォルダではなく顧客コンテキスト
なのではないか、ということです。
例えば、
[A社 Workspace]
Box
Teams
メール
チケット
議事録
設計資料
から、
[B社 Workspace]
Box
Teams
メール
チケット
議事録
設計資料
へ切り替える。
実際の業務感覚はこちらに近いはずです。
人間は、
Boxの○○フォルダの仕事をしよう
と考えるのではなく、
午前中はA社案件をやろう
と考えます。
つまり、業務の主語は「ファイル」ではなく「顧客」や「案件」です。
共有する側が「相手のFiles画面」を考える
現状のBoxを使う前提であれば、共有する側の情報設計が重要になります。
例えば外部企業へ共有する入口を、
プロジェクト
とするより、
A社_基幹システム更改_共有
など、受け手から見ても識別できる名称にします。
受け手は自社以外にも複数の企業からBoxを共有されている可能性があります。
そのため、共有フォルダを設計するときには、
「自社から見て分かりやすいか」だけではなく「招待された人のFilesに並んだときに識別できるか」
という観点を持った方がよさそうです。
外部共有用のトップ階層をあらかじめ設計しておくことも有効でしょう。
A社_○○プロジェクト_外部共有
├─ 01_プロジェクト管理
├─ 02_設計
├─ 03_テスト
└─ 04_成果物
このような入口であれば、受け手側も比較的判断しやすくなります。
Boxが多対多に弱い、というより「チーム同士の交差」を表現しない
この問題を「Boxは多対多共有ができない」と表現すると少し違います。
実際には複数企業・複数ユーザーとの共有は可能です。
ただし、
A社
├─ 開発部
└─ 品質部
×
B社
├─ 開発チーム
└─ 運用チーム
というような、異なる企業の組織構造をクロステナントで掛け合わせることをUIの中心には置いていないと考えると分かりやすいと思います。
Boxの基本的な考え方は、
フォルダ所有者
│
├── User A
├── User B
└── User C
というハブ型に近いものです。
1社が共有空間を作り、必要な人を招待する用途では非常に分かりやすい。
一方、
顧客A ─┐
顧客B ─┼─ 自社
顧客C ─┤
顧客D ─┘
という「多数の企業から共有を受ける側」になると、受け手側で情報を整理する別の仕組みが欲しくなります。
まとめ
複数企業からBox共有を受ける環境では、単純なアクセス権限だけではなく、次のような点も考える必要があります。
- 共有フォルダ名だけで企業・案件を識別できるか
- 受け手のFiles画面でどう見えるか
- 顧客ごとのフォルダ構造の違いをどう吸収するか
- Box Drive利用時に企業の境界をどう意識させるか
- 案件数が増えた場合でも情報を発見できるか
そして一番重要なのは、
共有できることと、整理された状態で共有できることは別
という点だと思います。
企業間のファイル共有が増えれば増えるほど、「誰にアクセス権限を与えるか」だけではなく、
相手の環境では、この共有フォルダがどう見えるのか？
まで考える必要があります。
さらにその先には、ファイルやフォルダを切り替えるUIではなく、
顧客・案件という業務コンテキストそのものを切り替えるワークスペース
という考え方が必要になってくるのかもしれません。
Boxを使っていて感じる「複数顧客になると整理しにくい」という感覚は、単なるフォルダ整理の問題ではなく、ファイル中心の情報設計と、顧客・案件中心で動く実際の業務とのズレとして考えると、いろいろ見えてくる気がします。