ある企業が 15 のクライアント組織向けにアカデミーを運営する方法

15 のクライアント組織向けにアカデミーを運営する研修会社が運営しているのは、一つの組織ではなく 16 の組織です。各クライアントは、独自のブランディング、独自のドメイン、独自の管理者、独自のレポートを求めます。会社のほうは、コースを制作する場所が一つと、15 社すべてを横断するビューが一つ欲しい。この二つの要望は反対方向に引き合っており、設計のすべては一本の線に集約されます。コンテンツはツリーを下へ流れ、人と結果はツリーを横へは決して動かない。

この線を間違った場所に引くと、症状は予測できます。規制が変わるたびに、同じコースの 15 個のコピーを手作業で足並みそろえるか、あるいはクライアントの管理者がレポートを開いて、そこに別のクライアントの従業員を見つけるか。前者は高くつきます。後者は契約を終わらせます。

構造は単純です。親組織が一つ — 研修会社 — そしてその中に 15 のクライアント組織があり、それぞれが自由に自社の拠点や部門を内包できます。

Training company (parent)      authors everything, sees everything
├── Client 1                   learn.client1.com · own admins · own report
│   ├── Operations
│   └── Retail network
├── Client 2                   academy.client2.io · own admins · own report
├── …
└── Client 15                  academy.client15.co · own admins · own report

16 のノード、一つのインストール、一つのアップグレードのサイクル。図は簡単な部分です。防火のコースを編集するのは誰か。クライアント 7 の修了の数字を見るのは誰か。クライアント 3 が別の合格点を求めたら何が起きるか。この三つの問いが、仕事のすべてです。

何を共有し、何を分離するか

一覧が二つ。ここで起きる運用上の議論のほとんどは、あるものがどちらの一覧に属するかについての意見の相違です。ツリーを下へ共有するもの。コピーは一つ、事業者が保守します。

• プログラム、モジュール、レッスン。親で一度だけ制作します。
• 問題バンクと、そこから組み立てる試験 — 問題のコピーが 15 あれば、正解が食い違う機会も 15 あります。
• コンピテンシーのフレームワーク。手作業での運搬ができるが、どのクライアント組織でも同じ意味になるように。
• 証明書のテンプレート — レイアウト、有効期間のルール、公開の検証ページ。
• 決してばらつかせたくないもの。保持期間のルール、監査ログ、アップグレードのサイクル、アクセシビリティの対応。

横へは分離するもの。クライアントごとに一つ、決してまとめません。

• ユーザーとそのサインイン。人は一つのクライアント組織に属します。
• 受講登録、進捗、受験、成績、発行済みの証明書。
• ブランディングと、クライアントの従業員がブラウザに打ち込むドメイン。
• 管理者と、その権限を与えているロール。
• レポートのスコープ — クライアントに見えるすべての数字は、自分のノードで区切られます。
• 通知の送信元アドレス。リマインダーが、クライアント自身のドメインからその従業員に届くように。
• 同意の記録と、クライアントの法務が説明責任を負うもの全般。

そして厄介な中間があります。コンテンツのように見えて、クライアントのアイデンティティを帯びているものです。証明書がいちばん分かりやすい例です。レイアウト、有効期間、検証ページはあなたのもの。ロゴ、署名者、そこに記される組織名はクライアントのものです。証明書を分割できない一つのオブジェクトとして扱うプラットフォームでは、ロゴを一つ変えるためにテンプレートを 15 回フォークすることになります。それを避けるルールはこうです。ブランディングはクライアントのノード上の設定であって、コンテンツのコピーでは決してない。ホワイトラベルは設定の面であって、制作の面ではありません。

一度制作して、15 のクライアントへ展開する

親組織がマスターのライブラリを持ちます。コースはそこで書かれ、そこでレビューされ、そこで公開されます。その次に何が起きるかでプラットフォームは分かれ、仕組みは二つしかありません。

1. 参照による方法。 クライアント組織に、親のコースへのアクセスを付与します。コピーは依然として一つなので、直した誤字は、公開した瞬間にすべてのクライアントに届きます。受講登録と結果は、これまでどおりクライアントのノードにあります。そもそも共有されていないからです。
2. コピーによる方法。 コースをクライアントのノードへ深いコピーで複製します — モジュール、レッスン、問題、設定。クライアントは独立して変更できる別のオブジェクトを持つことになり、上流で何をしても、そこへ届くことは二度とありません。実物のプログラムは大きなオブジェクトなので、そのコピーはバックグラウンドのジョブとして走ります。

既定は参照であり、そこから離れるときには居心地の悪さを感じるべきです。コースが 15 個のコピーとして存在するようになれば、来年の規制対応は、15 回の編集、15 回のレビュー、そして 15 回の見落としの機会になります。

クライアントが共有コースの変更を求めてきたとき

3年目がどれだけ高くつくかを決めるのは、この依頼です。たいていは非公式にやってきます — モジュール3に、うちのインシデント報告の手順を足してもらえませんか — そしてこれには、四つの正直な答えがあります。

1. これは修正です。 そのコンテンツは、全員にとって間違っているか、古くなっています。マスターを直せば、すべてのクライアントに反映されます。事業者が思っているより多くの依頼が、実はこれです。そして気づいたクライアントは、たいてい正しいのです。
2. これは見せ方です。 求めているのは自社のロゴ、自社の色、自社の用語です。そのどれもコンテンツではありません。そのクライアントのノード上の設定です。ロゴを変えるためにコースをフォークさせるプラットフォームがあるなら、それはプラットフォームの落ち度であって、依頼の落ち度ではありません。
3. これは追加です。 求めているのは違うものではなく、余分なものです — 多くの事業者が見落とす答えです。そのクライアント専用のモジュールを、共有のプログラムの隣に、クライアント自身の組織に置いてください。共有コースは共有のままで、追加の教材はクライアント自身が保守できることも多いのです。
4. これは本当の分岐です。 こちらの合格点が 70 のところ、先方の規制当局は 80 に定めています。ここではフォークします — そしてそのフォークには、日付と、所有者と、台帳の1行が付きます。18 か月後に、なぜクライアント 9 の版だけ違うのかと誰かが尋ねるからで、たぶんどこかのクライアントの依頼だったと思いますは答えになりません。

アクセス：先方の管理者、先方の人員、それ以外は誰も

クライアントの管理者の仕事は狭いものです。自社の従業員を追加・削除し、受講登録し、終えていない人を追いかけ、自社の役員会が受け入れるレポートを取得する。そのすべてを、あなたにメールを送らずに。そのどれも、自分の組織の外には及ばずに。

それを安く済ませるのが、下へ継承するスコープです。あるノードでロールを付与すれば、その下すべてに適用されます。クライアントの研修責任者は、クライアント組織での1件の付与であり、その部門は自動的に含まれます。拠点の責任者は、その拠点での1件の付与です。部門が閉じたときは、それより長く生き残った付与を探し回るのではなく、ノードを削除します。

難しいのは先方の人員ではなく、自社の人員のほうです。制作チームはすべてのクライアントのコンテンツを横断して仕事をしますが、学習者の記録を読む必要は一切ありません。クライアント 1〜5 の担当者には、その5社の結果が必要で、クライアント 6〜15 からは何も要りません。親に管理者ロールを一つ置くだけでは、全員に全部を渡すことになります。事業者が、どのクライアントの従業員名簿でもエクスポートできる人を 12 人ほど抱えてしまうのは、こうしてです。権限カタログから組み立てたカスタムロールを、適切なノードで付与する。かかるのは午後いっぱいです。

レポート、両側から

クライアントに見えるもの

自社の人員だけ、他社の人員は一切なし。誰が受講登録しているか、誰が終えたか、誰が期限を過ぎているか、誰が試験に二度落ちたか — 自社の部門別に分解でき、エクスポートでき、自社のブランディングで。そのレポートのスコープは、そのクライアントを守っているのと同じノードの境界です。だから、互いに整合していなければならないセキュリティのモデルとレポートのモデルがあるのではなく、一つの仕組みが両方の仕事をしています。

あなたに見えるもの

すべてのノードを一度に。事業を回すための数字はクライアント横断のもので、どの一社の内側からも見えません。6週間誰も受講登録していないクライアントはどこか、契約席数に近づいているのはどこか、どこでも不合格が出ているために、クライアントの問題ではなくコンテンツの問題を抱えているコースはどれか。この最後の一つが、15 の別々のインストールではなく一つのテナントを選ぶ、いちばん強い論拠です。別々のインストールでは、同じパターンは、誰かが四半期ごとに — やるとしても — 組み立て直すスプレッドシートになります。

次に作りたくなる機能はベンチマークです。クライアント 4 に、上位4分の1に入っていると伝えること。先に二つを片づけてください。契約の面では、各クライアントが、自社の集計結果を他の組織と比較してよいと合意しているかどうか。技術の面では、最小のグループ人数です。小さなクライアント数社をまたぐ比較から、そのうちの1社についての言明を逆算できないように。

Lurno の立ち位置と、構造では解けないこと

Lurno はこの形のために作られています。組織はサブ組織を内包し、それぞれが独自のブランディングと、自動 TLS 付きの独自のカスタムドメインを持つので、クライアントの従業員はクライアント自身のアドレスでサインインします。組織の内側には、そのクライアントの拠点と部門のための二つ目のブランチのツリーがあり、ブランチで付与されたロールはその下へ継承されます。コンテンツは親で一度制作し、そのあとクライアント組織へ共有するか、そこへ深いコピーで複製します。

テナントの境界は、アプリケーションのコードではなく Postgres で強制されています。676 のマイグレーションにわたる 868 の行レベルセキュリティポリシー。フィルターを忘れたエンドポイントは、他人の従業員ではなく何も返しません — これは、どのベンダーに対しても — 私たちに対しても — 試す価値のある主張です。社名は伏せますが、これがすでに動いている形が一つあります。一つのテナントから 15 のクライアント企業向けに研修を運営する企業内アカデミーです。

ツリーを正しく作っても解決しないことが四つあります。ここでは Lurno についてのものを書きます。同じ四つを、他のどのベンダーにも尋ねてください。

• クライアントへの請求。 決済とチェックアウトは開発中です。現時点でクライアントへの請求はプラットフォームの外で行い、プラットフォームは、そのクライアントが何を利用できるかを記録します。多くの事業者では、すでにお金がそのように動いているので噛み合いますが、受講登録の時点でのカード決済は、機能ではなく話し合うべきことです。
• 人をどう入れるか。 アカウントは招待によって作られます。セルフサービスのサインアップは開発中です。実務的な答えは、クライアントの管理者が、あなたにスプレッドシートを送る代わりに、自社の人員を自分でインポートすることです。
• 認証。 パートナーサインオン（サイレント SSO）は利用できます。クライアント自身のシステムが、署名済みのアサーションでユーザーを引き渡す方式です。SAML と OIDC はロードマップ上にあり、提供されていません。クライアントの情報システム部門が、従業員の認証方法をすでに決めているなら、5回目ではなく1回目の打ち合わせで尋ねてください。
• 標準規格。 SCORM、xAPI、LTI は製品の中でモデル化されていますが、ランタイムは開発中です。自社の SCORM パッケージを持ち込むと譲らないクライアントは、そこで止まります。これは早めに伝える必要があります。

このモデルの事業者側の姿は研修事業者向けにまとめています。社内向けの姿 — サブ組織が他社ではなく自社の地域である場合 — は企業向けにあります。

短くまとめると

コンテンツはツリーを下へ共有する。人、結果、ブランディング、レポートは横へ分離する。共有コースはコピーではなく参照し、どのフォークも誰かが署名した判断として扱う。各クライアントには、自分のノードにスコープされた管理者を与え、そのスコープがどこで強制されているのかを確かめる。そのうえで、16 のノードすべてを横断する自社のビューを作る。事業を生かし続ける問い — どのクライアントが静かになったか、どのコースがどこでも不合格になるか — は、上からしか尋ねられません。