この記事は SaaS Designer Advent Calendar 2023 の15日目の記事です。

アプリケーション上で、複数の事業体によって単一のオブジェクトインスタンスが共同で管理されることがよくあります。特に「プラットフォーム」を名乗るプロダクトであれば、複数人でのコラボレーションが重要な要素となるため、そういったことは頻繁に起こることでしょう。

私が所属している株式会社 Shippio でも、提供しているサービス内でそういったコラボレーションが発生します。コアな提供価値のひとつなので、このあたりの設計についてはよくチーム内で議論するのですが、思ったよりややこしく、よく議論が白熱するので、そこで話したようなことをあらためてまとめてみることにしました。

前提

この記事では、特に断りがないかぎり、BtoBサービスを想定しています。そのため「コラボレーションの媒介となるオブジェクト」は基本的には会社間で行われる契約・取引・案件にまつわるものとなります。

複数事業体間のコラボレーションとは

比較対象として、まず単一事業体内でのコラボレーションを考えてみます。

• ある事業体がそのサービスを契約しており、従業員がログインして使用する

• そのワークスペース内で、複数の従業員が単一のオブジェクトインスタンスを管理する

各種ドキュメントツールや案件管理、経費精算など、いわゆる普通のアプリケーションで起こっていることだと思います。そのインスタンスのステークホルダーは基本的に同じ会社の従業員なので、全員が同じ情報を見えています。もちろん、労務管理ソフトウェアや会計ソフトウェアなど、従業員ごとに異なるパーミッションが設定される場合も数多くありますが、そのパーミッションは事業体内のシステム管理者などによって管理されており、たいていの場合「管理者」という形で「そのインスタンスのすべてを見られる人」が存在します。

それに対して、複数事業体間のコラボレーションを次のようなものと定めます。

• 複数の事業体がそれぞれサービスを契約しており、それぞれのワークスペースを持つ

• 複数のワークスペースに所属する従業員が、あるオブジェクトインスタンスを共同で管理する

BtoBにおいては、たとえば受注企業と発注企業が受発注管理プラットフォーム上で見積や請求の情報を共同で管理したり、求人を行う企業と求職者の斡旋を行うエージェントが採用管理ツール上で候補者情報を共同で管理したりします。Shippio でも、国際輸送される貨物情報を、その貨物の持ち主（雑）である荷主と、各種輸送手配を行うフォワーダーが共同で管理します。単一事業体内でのコラボレーションと異なる点として、ざっくり言うと「各事業体がそれぞれの観点でそのインスタンスを捉える」ことが挙げられます。これにより生じる複雑さは下の「論点」の章で考えます。

「管理する」とは

雑に「オブジェクトインスタンスを管理する」と言っていますが、ここにはどういった操作が含まれるでしょうか。細かく挙げればキリがありませんが、抽象化するとこれくらいでしょうか。

• インスタンスの作成（コラボレーションの開始）

• そのインスタンスに対するコメント・チャットなど、ステークホルダー間の直接的なコミュニケーション

• 各種プロパティや、そこに紐づくトランザクション情報のアップデート

• （トランザクションデータの場合）そのインスタンスが指している業務の終了

• システム外で参照できるようにするためのデータ出力

• アクセス権の付与・剥奪

なお、「共同で」とありますが、必ずしも両者が同じようなUIでそのインスタンスに関与しているとは限らず、管理のありかたが非対称な場合も数多くあります。

設計時の論点

このような、あるオブジェクトを媒介として複数事業体間でのコラボレーションが行われるシステムの設計にあたって、コンセプトを定めていくための論点がいくつかあると考えています。粒度がバラバラなのがあれですが、思いつくものを書き出してみます。

下記、ごちゃごちゃ書いてますが、結局のところ、オブジェクトに関連する情報が「そのオブジェクトが表す業務自体の性質」なのか「ある視点からその業務をとらえたときの解釈」なのかを整理するというのが重要という話な気がします。

論点1. 誰がそのインスタンスを所有しているのか

インスタンスを共同で管理するとは言いつつ、そのデータの「所有者」を定めておく必要があります。サービス上でインスタンスのデータを作成した事業体が所有者である場合もありますが、その業務における発注元の事業体が所有者である場合もあります。

インスタンスの所有関係を整理することで、以下のような事項の答えにつながりそうです。

• そのインスタンスへのパーミッションを変更できるのは誰なのか。基本的にはそのインスタンスの所有者、および所有者から同等の権限を付与された人が該当します。

• サービスがそのオブジェクトを計測対象とした従量課金制を取っている場合、そのインスタンスに対しては事業者A,Bどちらが料金を支払うのか、またはどちらも支払うのか。

論点2. インスタンスのステータス管理

たとえばある案件の一部分だけを委託するとき、その案件を取り上げたオブジェクトインスタンスは両者からどのようなステータスで表示されるでしょうか。委託元Aからするとまだその案件は終わっていない、進行中のものですが、委託先Bにとっては自分の作業分がすべて終わったものであるかもしれません（そのあとの請求・入金みたいなフェーズもあるかもしれませんが）。

その場合、A, B それぞれのオブジェクトコレクションにおけるステータスの表示は「その人から見たステータスを表示する」のか「オブジェクトがあらわす案件全体におけるステータスを表示する」のかを選択する必要があります。選択の基準は「ステータスの情報がコラボレーション自体に使用されるかどうか」「オブジェクトを管理するビューがAとBで同じものなのか」あたりにありそうです。

論点3. オブジェクト内のどの情報を共有しているのか

たとえばドキュメンテーションツールの場合、「自分に見えている情報は他の人にも見えている」という前提で人はそのインスタンスの編集を行います（そういったツールはよく WYSIWYG だったりする）。複数事業体間のコラボレーションでも、ユーザーは同じような認識で操作をするかもしれませんが、必ずしもそのインスタンスにおけるすべての情報を共有していない場合があります。それぞれの事業体の社員間でのみ共有したいメモなどが業務上発生するからです。

もちろん単一事業体内コラボレーションであってもアクセス権の論点は発生しますが、システム管理者であっても、他社の情報に容易にアクセスすることはできません。そのため、サービス側で「何が共有されており、何がされていないのか」を理解しやすいように考慮しなければなりません。

• たとえばメールアプリでメールにスターをつけるような、なんらかのフラグをつけられるようにする場合に、そのフラグは自分だけ（または同じ会社の従業員だけ）に見えているのか、そのインスタンスを見られる他社の従業員も見られるのかが自明になっている必要があります。そのフラグをつけることで間接的に会社間のコミュニケーションを行おうとするユーザーがいるからです。

• カスタムプロパティを実装する場合に、そのプロパティを他社と共有するのかを定義する必要があります。仮に共有する場合、ある事業体Aからすると、Bと共同管理するインスタンスと、Cと共同管理するインスタンスとでオブジェクトの構造が異なるという問題が起こるため、そのケアが必要です。

論点4. マスターの取り扱い

言うまでもありませんが、ある事業体が管理するマスターはそれ自体が機密情報になりえます（たとえば取引先マスターはそれ自体が「どういった会社と取引しているのか」という営業秘密です）。そのため、意図しない相手にその内容が見えてしまうことは避けなければなりません。一方で、効率的なコラボレーションのためには、双方がマスターを用いたインスタンス管理を行う必要もあるでしょう。インスタンス管理と、マスター自体の管理にはどういった関係性が必要でしょうか。

「そのインスタンスの所有者によって管理されているマスターが、そのインスタンスの管理にも使用できる」というのが基本的な形になりそうです。ただ、複数の事業体とのやりとりがあり、契約上すべてのマスターデータを見せることができない場合には、何らかの方法で「他の会社の人から見える/見えないマスターデータ」を区別する必要があります。よくある方法としてはマスターデータにタグなどで参照条件を付与しておき、インスタンスにも同じタグをつけることで「このインスタンス管理で使えるマスターデータである」ことを示す、というものがあります。

オブジェクト設計の類型

先述の論点から導き出されたものというわけではないのですが、自分の中でおおよそのパターンみたいなものが出てきたので、まとめてみます。

パターン1. 単一インスタンスへの招待

いわゆる「ゲスト招待」に代表されるものだと思います。事業体Aが管理するオブジェクトコレクションのうちひとつのインスタンス（取引）について、その取引にかかわる他社Bをインスタンス管理に招待します。個人事業主から見た電子契約サービスなどはこれに該当します。

コラボレーションと言いつつ、インスタンスXの所有者および管理主体はほぼAなので、BはあくまでAから提供された情報にアクセスできるにすぎません。Bは基本的にコレクションを持たず、実際、このサービスのアカウントすら持たないことが珍しくありません。A視点では、Bにどのプロパティを見せるのかといったことを完全にコントロールできますし、カスタムプロパティなどのリッチなオブジェクト管理が可能です。

パターン2. 複数インスタンスへの招待

1の発展形です。1と同じく、オブジェクトの管理主体はほぼAでありつつ、そのうちの多くのインスタンスにBを招待します。こうなってくると、BはBで、このサービス上での振る舞いを効率化する必要があるため、独自のコレクションを持ち始めます。

プラットフォームサービスを作り始めた MVP などがこれに該当することがよくあります。ネットワーク効果によるユーザー数拡大を狙う前に、まずコラボレーションによる価値創出を検証している段階です。そのため、ユーザー同士のつながりが増えてくると、後述のパターン3,4あたりに変化していきやすいのではないでしょうか。

パターン3. ワークスペースへの招待

個別のインスタンスではなく、ワークスペースそのものに招待をして、ワークスペース内のコレクションに自由にアクセスできるようにします。たとえば会計ソフトウェアの場合、ある会計ソフトを契約している企業Aに対して顧問契約を結んでいる税理士事務所Bは、Aのワークスペースにログインし、その中の仕訳コレクションを管理します。

事業体Aに招待された事業体Bの従業員は、Aの従業員と同等の振る舞いをするため、ほぼ「単一事業体内でのコラボレーション」として捉えることができ、先に上げた複数事業体間のコラボレーションにおける論点の大半が考慮不要になります。その代わり、「たとえばアカウント数での課金の場合に、招待したB従業員の分のアカウントをAが支払う必要があるのか」といった細かい問題が発生します。

発展形として、事業体Bの従業員は、他の複数の事業体のワークスペースに招待されることがあります。この場合、Bの従業員は「Aに関する作業をする場合はAのワークスペースにログイン」というように、取引相手ごとにモードを切り替えて業務を行うことになります。先程と同様、論点の大半が考慮不要ですが、B視点では業務管理が複雑です。関与するコレクションが複数に分散してしまうため、自身が関心を寄せるインスタンスがどのコレクションにあるのかの判断が必要になるためです。基本的にBは独自のコレクションを持ちませんが（例に挙げた会計ソフトウェアの場合、顧問である税理士は、顧問先である企業AとC両方の仕訳が網羅されたコレクションを必要としません）、「新しく自分宛てのコメントがついたインスタンス」といった情報をワークスペース横断で管理したくなるでしょう。その場合、Bのワークスペース側に業務管理のためのポータルサイトなどの作成が選択肢に上がります。

パターン4. 双方が管理しているインスタンス間の関連付け

AとBはそれぞれ自身の視点でオブジェクト管理を行っていますが、業務上、インスタンスの関連付けがなされている状態です。お互いが誰とも関連しないインスタンスを持ち得ますし、「誰と関連しているか」を問わない横断的なコレクションでそのオブジェクトを管理します。なお、「関連付け」と書いてはいますが、システム上は単一のリソースである場合もあります。

事業体間の関係性は多対多に絡み合うので、ひとつのコレクション上で「このインスタンスはA社と、このインスタンスはC社とコラボレーション中」といった状況が日常的に発生します。もちろんインスタンスごとに参照できるマスターデータも変わりますし、関連付けされたインスタンスについて、どの情報が双方から参照できるのかを考慮する必要があります。個人的な感覚では、パターン3よりも設計においての考慮項目が多くなりがちです。

システムが複雑になるにもかかわらずパターン3ではなくパターン4を選ぶ理由は、簡単に言うと「ユーザーがそのように業務を行う」からです。パターン3は「コラボレーション相手ごとにモードを切り替えて業務を行う」ことに適応させた設計です。それに対してパターン4は相手ごとではなく、あくまで「インスタンスごとに業務を行う」設計です。相手がだれであろうと、単一のインスタンスに注目するだけで業務が完結するのであれば、コレクションを分割しないほうが業務効率が上がるでしょう。他社とインスタンスを共有して情報入力を効率化しつつ、自社のみに適用されるプロパティなどで社内での業務効率を効率化する、といった流れを生めることがこのパターンのメリットです。が、先述の通り、マスターや共有範囲など、うっかりすると情報漏洩につながってしまうので、慎重に設計する必要がありますし、UI上もユーザーの誤操作を防げるものになっていないといけません。

おわりとおことわり

書いてみてあらためて、あんまりまだ言語化が進んでないなと感じました。こういう話だけをして生計を立てていきたいですね。
パターン化したことで意図せず捨象されている構造があるかもしれないので、そういうのがありそうなら容赦なくツッコんでください。
ここに書いてある以外の論点、類型など、知見があったら教えてください。

なお、この記事に書かれている例としての業務のありかたやシステム設計例は、自分の経験や想像によるものなので、綿密なリサーチに基づくものではないことをご承知おきください。