複数キャンパスの学校グループを一つのプラットフォームで運営する
各キャンパスは自律を求め、グループは比較できる数字を求め、どちらも正しい。何を共有し、何を現場に残すか、そしてグループの修了率が嘘をつく理由。
複数のキャンパスを運営する学校グループには、互いに引き合う二つの正しい直感があります。各キャンパスは自分の職員、家庭、時間割を知っており、本部でそれについて下された決定は、届いたときに少しずれています。グループは、キャンパスをまたいで比較できる数字を必要としますが、それはいくつかの定義がどの建物でも同一でなければ不可能です。実務的な分け方は、多くのグループが思うより狭くなります。どこでも同じ意味でなければならないもの — カリキュラムの構造、評価の基準、そして報告されるすべての数字の定義 — を共有し、人の一週間に触れるものはすべて現場に残すことです。
ほとんどの統合プロジェクトは、この文の後半で失敗します。グループは一つのプラットフォームを買い、そのうえで、そもそも問題ではなかったもの — 時間割、クラス名、学年度を指す言葉 — を標準化し、修了、出席、習熟の意味は各キャンパスに委ねます。それは逆であり、結果として、誰も信用しないグループのダッシュボードと、静かにシステムを迂回する校長たちが生まれます。
議論のどちらの側も正しい
キャンパス側の言い分は正確さについてのものです。校長は、一つの建物、一つの職員名簿、一つの入学者集団、一つの現地の事情のもとで、結果に責任を負います。200 マイル離れた中央のチームに時間割を決められた経験のある人なら、どれだけの細部がその道中で失われるかを知っています。ここでの自律は政治ではありません。データが建物に対して真であり続けるための方法です。
グループ側の言い分は比較可能性についてのものです。三つのキャンパスが合格率を報告するなら、誰かがその数字を一枚の紙に並べ、差に対して手を打たなければなりません。比較できる数字がなければ、グループは共有のロゴと共有の給与計算にすぎず、ある建物で見つかった改善はそこに留まります。キャンパスは運用の制御を望み、グループは意味の制御を望んでいます。
連合型の学校グループ
小さな中央の層が、決まった数の共有された定義 — カリキュラムの到達目標、評価の基準、報告されるすべての数字の背後にある規則 — を所有し、それ以外のすべて — 職員、クラス、暦、言語、一日 — を各キャンパスが所有する学校の集まり。本部が各キャンパスを構成する中央集権型のグループと、キャンパスが所有者を共有するだけで運用は何も共有しない持株会社型のあいだに位置します。これを定義づけるのは、中央がどれだけ制御するかではなく、共有される一覧がどれだけ短いかです。
何を共有し、何を現場に残すか
共有するもの、四つ
- カリキュラムの背骨。 教科、順序、そして学校が責任を負う学習到達目標。キャンパスごとに教え方は変えられますが、それぞれが独自の到達目標の一覧を持つことはできません。あるキャンパスで記録されたコンピテンシーは、家族が町の向こうへ引っ越したときにも同じ意味でなければならないからです。
- 評価の基準。 ルーブリック、評定の境界、そして何が習熟の根拠として数えられるか。基準が現地のものなら評定も現地のものであり、キャンパスをまたいで結果を比べることは、採点の文化を比べることになります。
- レポーティングの定義。 何が修了、欠席、アクティブな学習者、期限超過のモジュールとして数えられるか。グループはこれを飛ばしますが、これこそがグループという層を持つ価値があるかどうかを決めます。
- データの方針。 保持、同意、誰が何を見てよいか、そして開示請求にどう答えるか。規制当局が尋ねるのはキャンパスではなくグループです。
共有するとは、一つの定義、一人の所有者、一つの変更手続きを持つことです。一つの時間割や一つの指導案を持つことではありません。共有されたルーブリックが教員の授業を止めることはありません。中央が所有するのは言葉の意味であり、キャンパスが所有するのはその下で起きることです。
現場に残すもの、一週間に触れるすべて
- 職員、ロール、権限。 管理者アクセスを必要とする人は現場にいます。学年主任がクラスを一つ作るために、中央のチケットを 2 日待つべきではありません。
- グループとクラス。 コホートは現地の暦に沿って、現地の理由で、ときには毎週変わります。
- 暦。 学期、休暇、試験週間、報告のサイクルは、本部が思うよりも頻繁に一つのグループ内のキャンパス間で異なり、国をまたげば必ず異なります。
- 用語。 Year 7 か Grade 7 か。学期かセメスターか。担任かホームルーム担当か。見た目の問題に見えますが、そうではありません。ものを間違った名前で呼ぶシステムを、職員は信用しなくなります。
- 現地の教材と家庭への連絡。 家庭へ送る手紙は、その家庭を知っている人が書きます。
キャンパスは自前の管理者を持つべきですか、それとも本部がすべてを運営すべきですか
キャンパスは、自分のキャンパスに範囲を絞った自前の管理者を持つべきで、そのうえで、すべてのキャンパスに権限が及ぶ少人数をグループ層に置きます。中央のみのモデルの失敗はセキュリティではなく遅延です — 90 秒で済む変更が 2 日待つことになります。キャンパスのみのモデルの失敗は、グループ全体についてのどんな質問も、11 人に尋ねなければ答えられなくなることです。どちらも、キャンパスごとに権限を付与するのではなく、構造上の位置に権限を紐づけることで避けられます。
ブランチとサブ組織は同じものではありません
共有する一覧が合意されたら、構造がそれを表現しなければなりません。組織図の上では同じに見えて、システムの中では違う振る舞いをする形が二つあります。呼び方はベンダーによって異なります。この記事ではブランチとサブ組織と呼びます。
ブランチは、一つの組織の中の運用単位です。キャンパス、部門、地域、キーステージ。ブランチのツリーにあるものはすべて、その組織のメンバー、プログラム、ロール、ブランディングを共有します。ブランチの要点は権限の流れです — ブランチで付与されたロールは、その下のすべてのブランチに適用されます。北部キャンパスの統括は、キャンパスごとに一つではなく、付与が一つ。その人が異動するときも、取り消す付与は一つです。
サブ組織は、完全な子組織です。独自のメンバー、プログラム、ロール、ブランディング、用語、ドメインを持ち、自分の子を持つこともできます。フォルダーではなく境界です。二つのサブ組織は、どちらも特例扱いにならないまま、異なるカリキュラムと入学制度を運営できます。
One organisation, campuses as branches
Northbridge School one brand, one staff list, one curriculum
├── North campuses branch — regional head: one grant
│ ├── Northbridge Central branch
│ └── Northbridge Riverside branch
└── South campuses branch
└── Northbridge Park branch
One group, schools as sub-organisations
Northbridge Education Group parent organisation
├── Northbridge School sub-org — own domain, own staff
│ ├── North campuses branch, inside that sub-org
│ └── South campuses branch
├── Cedar Academy sub-org — acquired, keeps its own brand
└── Northbridge Online sub-org — own programmes, own intake- キャンパスが複数の建物にある一つの学校であるときはブランチを使います。一つの名前、一つの雇用契約、一つのカリキュラム、一組の方針。ブランチのツリーは既定でそれらを比較可能に保ちます。比べるべきものが、それぞれ一つしかないからです。
- キャンパスが、保護者にも分かる独自性を持つときはサブ組織を使います。異なるブランド、異なる規制当局、独自の入学制度、独自のドメイン、そして他のキャンパスのユーザー一覧に現れるべきでない職員。グループが、すでに名前を持ち、それを手放す気のない学校を取得したときも同様です。
- 実際の形が両方を必要とするなら、両方を使います。学校ごとにサブ組織を一つ、その中に各校のキャンパスと部門をブランチとして。
ブランチとサブ組織の違いは何ですか
サブ組織は、テナントの中にある別個の組織です。独自のメンバー、プログラム、ロール、ブランディング、用語、ドメインを持ち、自分の子を含むこともできます。ブランチは一つの組織の中の単位で、その目的は権限の流れです。ブランチで付与されたロールは、その下のすべてのブランチへ継承されます。手早い判定は玄関です。その単位が独自の住所と独自のユーザー一覧を必要とするなら、サブ組織です。主に独自の管理者を必要とするだけなら、ブランチです。
選び間違えると、どちらの方向にも代償があります。すべてをサブ組織としてモデル化すればグループは比較可能性を失います。四つの学校、四つのカリキュラムのツリー、四通りの合格点の考え方。すべてをブランチとしてモデル化すれば、独自のブランドと職員名簿を必要としていた学校は、そのどちらも得られません。どちらも初日には安く直せますが、1 年分の在籍が積み上がってからは高くつきます。
レポーティングの罠
グループのダッシュボードがどうやって作り話になるかを示します。グループは各キャンパスにプログラム別の修了率を求めます。キャンパス A は、学習者が最終アセスメントを提出した時点でプログラムを修了と数えます。キャンパス B は、その 2 週間後に教員がそのアセスメントを採点した時点で数えます。キャンパス C は最終アセスメントのないコースを運営していて、レッスンの 5 分の 4 が開かれた時点で数えます。どの規則も、その現場だけを見れば筋が通っています。平均すると、何も表しません。学習でも、処理量でも、採点の余力でもない。三つの違う測定を足し合わせたものです。
間違った数字は、欠けている数字より悪い。使われてしまうからです。欠けている数字は、誰かに質問をさせます。間違った数字は、人員、予算、介入を、採点のサイクルが最も遅いキャンパスへ動かします。数字がスライドに載っていて、定義は載っていない会議の中で。
修了は一度だけ定義され、グループ層の名前の分かる担当者が所有し、すべてのキャンパスのダッシュボード、書き出し、取締役会資料がその定義に解決されます。
修了は各キャンパスのダッシュボードが設定された意味のとおりであり、グループの数字は四つの違う質問を平均しています。
キャンパスの数字が、グループ層で合わないのはなぜですか
ほぼ必ず、元のデータが間違っているからではなく、同じ言葉がキャンパスごとに違う計算をされているからです。よくある四つは、修了、出席、アクティブな学習者、期限超過です。何かを比べる前に、各キャンパスが使っている正確な規則を書き出してください。数え始める出来事、数え終える出来事、そしてプログラムの途中で去った学習者の扱いです。四つのキャンパスに三通りの修了の定義があり、そのうち一つは登録を取り消した人を数えていた、というのはよくあることです。
直し方は、よりよいダッシュボードではありません。レジストリです。報告されるすべての数字を一度だけ定義し、名前の分かる所有者、一つのソース、一つの集計規則、そして分解に使ってよいディメンションの閉じた一覧を添える。キャンパスはその上に好きなビューを作れます。できないのは、その下にある言葉を定義し直すことです。認定済み指標の定義は、そのためにあります — 指標が認定済みの印を得るのは、人が手で確認した期待結果がその背後にあり、定義が変わるたびに再実行されるときです。ですから修了の規則を変えると、昨年の数字が静かに書き換わるのではなく、テストが落ちます。
規模のうえでの姿
Lurno 上で動いているこの形の最大のもの — 他社の事業なので匿名にします — は、一つのプラットフォームで 114 校を運営する K-12 出版社です。幅の違う同じ構造が、一つのテナントから 15 社の顧客企業向け研修を運営する企業アカデミーです。どちらも特別なビルドではありません。子組織を抱える親組織と、その各子組織の中にある運用のツリーです。
Lurno は、二つのツリーを意図的に分けています。サブ組織は入れ子になり、それぞれが独自のメンバー、プログラム、ロール、ブランディング、用語、そして TLS が自動発行される独自ドメインを持ちます。ブランチは二つ目のツリーで、一つの組織の中にあり、ブランチで付与されたロールはその下のすべてのブランチへ継承されます。三つ目がグループで、学習者が属するクラスやコホートです。三つのどれを使うかはホワイトラベルとマルチテナンシーにまとめてあります。
レポーティングは、認定済み指標のレジストリの上に置かれた読み取り専用のレイヤーです。各指標は一つのソースと決まったディメンションの一覧とともに一度だけ定義されるため、キャンパスのダッシュボードのタイルとグループの取締役会資料の数字が、二通りに計算されることはありません。すべてのクエリは、プラットフォームの他の部分を統べるのと同じ権限のもとで、読む本人として実行されます。だからこそ、月次の PDF ではなくライブのレポーティングを校長に渡しても安全なのです。この層についてはレポーティングと分析で説明しています。学校どうしの分離はアプリケーションコードではなくデータベースの中にあり — 676 のマイグレーションにわたる 868 の行レベルセキュリティポリシー — 新しい書き出しでフィルタが一つ抜けていれば、他校の学習者ではなく、何も返しません。
グループが移行を計画する前に片づけておくべき制約が三つあります。SCORM、xAPI、LTI 1.3 は開発中です — キャンパスが出版社のコンテンツを SCORM パッケージで購入しているなら、まず時期を尋ねてください。決済とチェックアウトも開発中なので、学費は御社の財務システムに残ります。そして SAML と OIDC のシングルサインオンは、提供済みではなくロードマップ上にあります。現在利用できるのはパートナーサインオン(サイレント SSO)で、これは別の仕組みであり、御社の ID プロバイダーを運用している担当者と話しておく価値があります。モデルの残りは学校向けの Lurnoにあります。
統合する前に
- グループの報告に現れるすべての数字を列挙し、それぞれの横に、各キャンパスが今日使っている正確な規則を書いてください。その一覧の突き合わせは、何かを移行した後ではなく、前に行います。
- キャンパスごとに、独自の玄関と独自のユーザー一覧が必要かを尋ねてください。その質問は、どんな組織図よりもうまくブランチとサブ組織を仕分けます。
- 共有される定義のそれぞれに所有者を指名してください — カリキュラムの到達目標、ルーブリック、報告されるすべての指標。所有者のいない定義は 1 年のうちにずれていきますし、所有者のいない数字が取締役会資料に届くべきではありません。
- 各キャンパスが尋ねずに変更してよいものを書き出し、公表してください。グループのプラットフォームへの抵抗のほとんどは、どの決定がまだ自分のものなのか分からないことから来ています。
- グループ層で付与されたロールが下まで届くこと、そしてキャンパスで付与されたロールがそこで止まることを確かめてください。通話で説明されるのではなく、製品の中で見せてもらってください。
- 学校がグループを離れるときにどうなるかを、あらかじめ合意してください。何が削除され、何が書き出され、そのあいだ誰がデータを保持するのか。
短くまとめると
定義を共有し、運用は現場に残す。キャンパスが複数の建物にある一つの学校であるときはブランチを、一人の所有者のもとにある複数の学校であるときはサブ組織を使う。そして最初のグループ報告が印刷される前に、修了が何を意味するかを片づけておく — その後は数字が出回り、それが三つの違う質問だったことは誰も覚えていません。