Slack の全学包括契約によるワークスペース利用環境の提供
竹内 朗 1), 玉造 潤史 1)
1) 東京大学情報システム本部

Providing Slack workspace usage environment through a comprehensive
university-wide contract
TAKEUCHI Akira 1), TAMATSUKURI Junji 1)
1) Division for Information and Communication Systems, the University of Tokyo.
概要
東京大学で行っている全学包括契約による Slack の運用について報告する．運用にあたっては，教職員が申請により必要なワークスペースを作成できるようにしており，1000 個を超えるワークスペースが作成されている．これにより，研究室をはじめとした学内のコミュニティのニーズに沿った利用環境が実現されている．また，Slack のさまざまな機能について，大学組織に特有の事情に合わせた利用ができるよう調整を重ねている．これらの結果，デイリーアクティブユーザが 4000 人を超えるなど，学内のコミュニケーション環境として一定の役割を果たすことができた．
報環境機構において，教員・技術職員・事務職員の1 はじめに100 人規模で導入した事例がある．この事例では「Slack」1は，Slack Technologies, LLC（Slack 社）

利用者へアンケートを行った結果が詳細に分析さが提供するビジネスチャットツールである．2020

れており，コミュニケーションの改善について高年以来の新型コロナウイルス感染症 (COVID-19)

い評価を得られていることや，Slack を利用してい2の影響や，それと呼応してのデジタルトランスフ

るユーザと利用していないユーザとの間でコミュォーメーション (DX) 推進の動きもあり，大学でニケーションに齟齬が生じている可能性があるこ

も Slack をはじめとしたチャットツールが導入される事例が出てきている．
Slack を用いた大学教育に関する研究としては，となどが報告されている[8][9]．
東京大学でも，学内での Slack の利用が拡大していることなどを背景に，Slack の「Enterprise Grid」

プログラミングやネットワークに関する演習におプランによる全学包括契約を行い，2022 年 8 月かけるツールの一つに（他のツールと組み合わせつら「UTokyo Slack」として全構成員に提供している．

つ）Slack を用いる手法を開発・提案しているもの

東京大学における運用の特徴は，教職員であれば誰でも申請により必要なワークスペースを作成で[1][7]が見られる．
Slack の導入に関する事例としては，全学的な導きる，ということである．実際に研究室・研究プロ入が行われたものでは，2020 年から全学生・教職ジェクト・授業・学科・委員会などさまざまな活動

員約 3 万 6000 人に対して Slack を導入した近畿大でワークスペースが作成されており，2023 年 10 月

学のケース[6]や，2021 年から東京工業大学が全教職員に対して Slack を導入し 3500 人以上が参加し現在，その数は 1000 個以上にのぼる．
Slack を全学的に導入している事例であっても，ているというケース[5]がある．前者の事例に関し東京工業大学では 3 個のワークスペースのみで利ては，運用管理を補助するツールを独自に開発し用している3，近畿大学では学部・学科等の組織ごたという報告[10]がある．とにワークスペースを設けている[10]，といった運

比較的小規模な導入事例としては，京都大学情用が取られており，教職員の申請によって柔軟にどは株式会社セールスフォース・ジャパンが行っている．
3 https://www.dx.titech.ac.jp/slack/workspace.html （参照2023-10-10）による．

1

https://slack.com/intl/ja-jp
2021 年 7 月に Salesforce, Inc.に買収されたが，Slack社としての法人格は現在も存続しているようである．
なお，日本法人は合併しており，日本における営業な
2267

ワークスペースを作成できるようにしている事例れている．

は管見の限り報告されていない．

2.2 ワークスペースを単位とした利用環境の提供

そこで本稿ではこの UTokyo Slack について，ワ以上のような前提のもと，チャンネル・ワークークスペースの作成に関する点をはじめ，管理・スペース・オーガナイゼーション (OrG) という 3運用に関する側面を中心に報告する．全般的な方

つのレベルの単位をどのように運用するかが問題針に加え，Slack の機能や設定項目などの詳細につとなる．Slack はチャットツール・コミュニケーシいても，必ずしも汎用的な情報とは言えないが，ョンツールであり，複数人でメッセージのやり取今後の取り組みにあたって参考になる部分があるりをすることがその機能の中核であるから，そのと考えて報告に含めることとしたい．なお，各ワやり取りをどのようなメンバーで行うかは最も基ークスペースにおける実際の利用実態などについ本的な要素である．関係ない第三者によってやりては，必ずしも一元的に把握できているわけでは取りを見られることがないようになっているべきなく，今後アンケート等により取りまとめを行うなのはもちろん，各メンバーが関心のあるメッセ予定としているが，本稿執筆時点では実施に至っージだけを選択的に確認できれば効率的である．ていないことから，さらに詳細な報告は別の機会

Slack においては，各メッセージ4はいずれかのに譲ることとする．

チャンネルでやり取りされ，そのチャンネルに「参加」しているメンバーのみがメッセージを受け取

2 基本的な運用方針

る．チャンネルには，ワークスペースのメンバー

東京大学における Slack 全学包括契約の基本的であればいつでも自分から参加することのできるな運用方針について述べる．そのための前提とし「パブリックチャンネル」と，そのチャンネルのて，Enterprise Grid プランに特有の概念として「オメンバーに追加してもらわなければ参加できないーガナイゼーション (OrG)」について理解する必要があるので，まず 2.1 節でこれについて説明する．その後 2.2 節で基本的な考え方を述べ，2.3 節「プライベートチャンネル」の 2 種類がある．各
自が関心の有無に応じて参加するかどうかを選べるのはこのうちパブリックチャンネルの方である

で実際の運用体制などについて述べる．

が，その一方でパブリックチャンネルのやり取り

2.1 ワ ー ク ス ペ ー ス と オ ー ガ ナ イ ゼ ー シ ョ ン(OrG)
通常の（無料プランあるいは Enterprise Grid 以はワークスペース内のメンバーであれば誰でも見外の有料プランの）Slack では，1 つの「ワークスバーとすることで，パブリックチャンネルを効果ペース」が利用の単位となる．ワークスペース内的に利用できるようになる．言い替えると，関心に複数の「チャンネル」があり，それぞれのチャンの有無によるメンバー管理はチャンネルで行い，ネルでメッセージのやり取りが行える．利用者は関係の有無によるメンバー管理はワークスペース

アカウントをワークスペースごとに作成する（プで行うということになる．

ることが可能である．そこで，メッセージが見られてもよい範囲の人のみをワークスペースのメンロフィールやパスワードをワークスペースごとに以上のように考えると，関係者の範囲すなわち設定する）ようになっている．また，ワークスペーコミュニティの単位（研究室・研究プロジェクト・ス内に管理権限を持つユーザがおり，ワークスペ授業・学科・委員会など）に合わせてワークスペーース全体の設定やメンバー管理などを行える．

スを作成するのが最も合理的であるという結論に

一方 Enterprise Grid プランでは，ワークスペー至る．一方，ワークスペースは OrG 内に作成するスの上位に「オーガナイゼーション (Organization,ものであるから，OrG すなわち全学包括契約の運OrG)」という別の管理単位がある．1 契約につき，用としては，どのようにワークスペースを管理す

OrG の数は 1 個であるが，OrG 内のワークスペーるかが問題となる．企業であれば階層的な組織構スの数に制限はない．アカウントは OrG 内を通し成に応じて機械的にワークスペースを作成するよて共通であり，その 1 つのアカウントで OrG 内のうな選択肢もあり得るのかもしれないが，大学に各ワークスペースに参加する形を取る．管理権限おける研究室などのコミュニティ単位は必ずしもも OrG 全体とワークスペースごとの 2 段階で分か

組織的に明確に定まっているわけではなく，全学4ダイレクトメッセージ（個人間でのメッセージ）は除く．

268

で一元的な名簿があるわけではない（たとえば，クスペースが作成される（承認までの所要時間は複数の部局に所属しそれぞれの部局から学生を受1～2 営業日程度である）．承認にあたって確認しけ入れている教員の研究室では，メンバーであるているのは東京大学での活動のための利用である

学生は組織上別々の部局に所属していることになかという点で，問題があるケースは皆無に近い．

る）．特に大規模総合大学である東京大学ではこ申請ができるのは教職員に限っており（学生にの傾向が顕著である．そのため東京大学では，トよる申請は認めていない），申請者をワークスペップダウンでワークスペースを体系的に作成するースの「代表責任者」として扱っている．代表責任のではなく，Slack を利用したいコミュニティから者にはワークスペースの利用が適切なものとなるボトムアップ的に申請を行ってもらい，それに応よう管理・運用することを求めている．このようじてワークスペースを作成し提供する運用を取るな形で責任を持つ者を明確に定めることで，全学ことにした．

的なシステムを学内の活動に利用してもらうこと

なお，いま一つの考え方として，トップダウンを実現している．

でいくつかの固定的なワークスペースのみを作成

また，ワークスペースの管理権限で設定可能なし，やり取りの場を必要とするユーザはチャンネ項目を制限する機能（OrG ポリシー）もあるが，ルを作成して利用してもらう，という運用もあり極力制限を行わずに自由度の高い状態で利用でき得る．たとえば，東京工業大学では前述のように 3るようにし，管理を代表責任者に委ねる形を取っつのワークスペースのみを設けている．このケーている．これにより全学レベルで個々の機能の利スでは全構成員へ向けたお知らせ用のチャンネル用について管理する必要がなくなり，運用の負担なども設けられており ，大学全学で共通となる基が軽減されている．

5

盤的なコミュニケーション環境を構築しようとするものと見受けられる．一方東京大学では，大学3 運用の詳細

全体でのお知らせについては既存の仕組み（教職以下，Slack の個々の機能や設定をどのように運員向けポータルサイト，学生向けの学務システム

用しているか，やや羅列的なきらいはあるが，詳でのお知らせ機能）がある程度定着しており，細に述べていく．

Slack がそれを置き換えられるほどすぐに浸透す

3.1 ワークスペースの自動作成るとも考えられなかったことから，かえって連絡手段が分散してしまい混乱を招くといったことのないよう，全構成員が必須で参加するようなやり取りの場（ワークスペース・チャンネル）を設けないことにした．そのようなわけで，大学全体で統一的なコミュニケーション環境を整備することを目的とせず，代わりに既存の学内コミュニティでワ ー ク ス ペ ー ス の 作 成 申 請 は ， Microsoft のPower Automate6を用いて自動化している．東京大学の認証基盤は Microsoft のクラウドサービスと密に連携していることから，申請フォームはMicrosoft Forms を用いて作成した7．サインインしているユーザ名を記録する設定とすることで，本人が申請したという事実を確実に確認できる．のニーズに応えることを第一の目的と考えたため，フォームに新たな回答が送信されると自動処理それに必要な環境としてワークスペースを作成でが起動し，まず運用担当者専用にあてて承認を求きる運用を取ったのである．

めるメッセージが送られる．承認が行われると実2.3 ワークスペースの管理体制

際のワークスペース作成処理に入る．ワークスペ

前述の通り，UTokyo Slack では申請によりワークスペースを作成することができる．申請は Webースの作成は Slack の API を用いて行っている．
なお，Slack には「ワークスペース作成のリクエフォームで受け付けており，ワークスペースの名スト」という機能もあり，Slack 内部でワークスペ

称・URL などのほか，用途・目的を自由記述で入ースの作成申請に相当する操作が行えるようにな力してもらっている．フォームが送信された後は，っているが，全ワークスペース間で共有された特UTokyo Slack の運用担当者による承認を経てワー
https://www.dx.titech.ac.jp/slack/defalt_student.html および https://www.dx.titech.ac.jp/slack/defalt_faculty.html（参照 2023-10-10）による．
6 https://powerautomate.microsoft.com/ja-jp/5269

東京大学では Google Workspace も導入しており，Google フォームと Google Apps Script を用いることも考えられたが，システム構成の都合上ユーザ名を取得できないため見送った．
7

殊なチャンネルを利用する必要があり UTokyo

ことから，利用者は学内の構成員に限っている．

Slack の運用の考え方に合わないことや，教職員か既存の認証基盤と SAML によるシングルサインオらの申請だけを受け付けることが難しいことなど

ン (SSO) で連携しており，利用者は認証基盤上のから，無効化している．

アカウントで UTokyo Slack にサインインすること3.2 ワークスペースの権限管理になる．

Slack の管理権限には，権限の強い方から順に一方，Slack 上ではワークスペースにメンバーを「プライマリーオーナー」「オーナー」「管理者」招待する機能があり，任意のメールアドレスを指の 3 種類がある．また，Enterprise Grid では OrG と定して招待することが可能である．つまり，認証ワークスペースのそれぞれで別々に各権限を設定基盤上に存在しないユーザ名のアカウントが作成できる．このうち OrG の管理権限については全学されてしまう．ただ，「SSO からのメンバー除外」の運用担当者のみが保持し，ワークスペースの管という OrG 全体の設定項目があり，これを OFF に理権限については「オーナー」と「管理者」をワーすると SSO 以外ではサインインすることができなクスペースのメンバーに付与している．ワークス

くなるため，それによって認証基盤上に存在しなペースの管理権限のうち「プライマリーオーナー」

いアカウントを実際には利用できないようにするについては UTokyo Slack 全体の管理用アカウントことができ，利用を学内構成員に限ることができが保持する形を取り，ワークスペースの実際の利る．費用算定にあたりカウントされるのはアクテ用者には付与していない．

ィブユーザ数であることから，作成されただけでその理由は，OrG の管理権限を持っていてもワークスペースに対する特権的な操作のすべてが行

サインインされていないアカウントが存在しても影響はない．

えるわけではないということが大きい．特に，ワ

ただ，この仕組みは，UTokyo Slack を利用する

ークスペースの削除はワークスペースのプライマすべてのアカウントが認証基盤上のアカウントとリーオーナーしか行えず，OrG の管理権限を持っ紐付けられていなければならないことを意味する．ているだけでは不可能な操作となっている．また，言い替えると，認証基盤に登録されていない学外

前述したように API を用いてワークスペースを作のユーザを通常のメンバーとして受け入れるよう成しているのだが，その際 API を実行したユーザな余地は存在しない．

が強制的にワークスペースのプライマリーオーナ

なお，通常のメンバーのほかに「ゲスト」機能ーとなってしまう上，それを API では変更するこもあり，学外のユーザを受け入れるためにこの機とができない仕様となっているという事情もある．

能を使用することも考えられるが，残念ながらそこの仕様のもとでは，ある 1 個のユーザが全ワーれにも難点がある．
「ゲスト」には複数のチャンネクスペースのプライマリーオーナー権限を保持すルに参加できる「マルチチャンネルゲスト」と一るほかないのである．

つのチャンネルにしか参加できない「シングルチワークスペースの「オーナー」と「管理者」のャンネルゲスト」があるが，前者は費用算定のカ権限については，ワークスペース作成時に API でウント対象になる一方，後者だけを利用できるよ申請者（代表責任者）にオーナー権限を付与してうにする設定が存在しない．そのためゲスト機能いる．また，オーナーが他のユーザにオーナー権を幅広く利用させることはできず，OrG 全体で管限・管理者権限を付与することは可能となってお理した上で限定的な利用とすることも運用の負担

り ，各ワークスペースの運用に委ねている．学生が大きく難しいことから，ゲスト機能は利用しなにオーナー権限・管理者権限を付与することも特い状態となっている．

段禁止していない．

3.4 コネクト機能

8

3.3 ユーザ管理およびゲスト機能の取り扱い

UTokyo Slack 内に直接学外のユーザを受け入れ

UTokyo Slack は大学として行っている包括契約

ることはできないが，Slack には組織を越えてやりであり，また利用者数（正確にはアクティブユー取りをするための機能として「コネクト」機能がザ数）をもとに費用が算定される契約形態である存在する．これはチャンネルを複数のワークスペ一方削除については，管理者権限はオーナー権限で削除できるが，オーナー権限を削除するにはワークスペースのプライマリーオーナーあるいは OrG 管理権限を持つ者が操作するしかないため，必要になった際にUTokyo Slack 全体の運用担当者に連絡してもらい個別対応する形となってしまっている．

8270

ースの間で共有することができるというものであに制限し，全学の運用担当者へ連絡してもらってる．UTokyo Slack に学外のユーザがメンバーとしOrG 管理権限により（API 経由で）設定するといて参加しなくても，学外者が参加しているワークう形を取っている．これにより一定の運用負担がスペースとコネクト機能でチャンネルを共有する生じているが，少数ながらも一定数 MWSC を利用ことで，学内者は UTokyo Slack から，学外者はコしたいとの問い合わせがあり，やむを得ずこのよネクト先のワークスペースからそれぞれチャンネうな対応を取ることにしたものである．

ルに参加し，互いにやり取りをすることができる．

3.6 カスタム絵文字

情報管理の観点では利用に注意が必要な側面も「カスタム絵文字」は，Slack 上で利用できる絵あるが，ゲスト機能の利用を不可としていること，文字リアクションを利用者が自由に追加できると共同研究や産学連携などで学外者とともに Slackいう機能で，Slack の大きな特徴の一つと言えるもを利用したいニーズは少なくないことから，のである．Enterprise Grid プランでは，カスタム絵UTokyo Slack ではコネクト機能の利用を制限せず，文字は OrG 全体に追加することしかできず，特定各ワークスペースで管理権限を持つ者がコネクトのワークスペースだけに追加するということがで機能の設定をできるようにしている．

きないため，OrG として管理を行う必要があった．

なお，通常コネクト機能は有料プランのワーク

カスタム絵文字自体は気軽なやり取りを助けるスペース同士でしか利用できないが，Enterprise

有益な機能ではあるが，気軽である反面，内輪ネ

Grid プランのワークスペースに存在するチャンネ

タの延長のような形で問題含みのカスタム絵文字

ルであれば，無料プランのワークスペースに対しが登録されてしまうという事態も懸念されたため，て共有することが可能となっている．また，無料やむを得ずカスタム絵文字を追加できる利用者をプランでは（後でも触れるように）参照できる過制限することとした．Enterprise Grid プランの仕様

去のメッセージの範囲に制限があるが，Enterprise

上，カスタム絵文字を追加できるユーザの範囲とGrid プランとコネクトしたチャンネルは無料プラして設定できる選択肢は「ゲスト以外の全員」かンのワークスペース側からでも過去のメッセージ「ワークスペースのオーナーと管理者のみ」のどを無制限に参照できる ．

ちらかであるため，後者で設定を行った．なおワ

3.5 マルチワークスペースチャンネル機能

ークスペースのオーナー・管理者権限は全学の運

9ワークスペース間でチャンネルを共有する際，用担当者以外の一般のユーザにも付与しているが，通常はコネクト機能を用いるが，同じ OrG 内のワ各ワークスペースの代表責任者に責任を持って権ークスペース間でチャンネルを共有する場合はコ限を付与するよう案内していることも踏まえ，カ

ネクトではなく「マルチワークスペースチャンネスタム絵文字の追加についても適切に利用してもル (MWSC)」という別の機能を利用するようにならえることを期待して，許容可能な形で運用できっている．

るであろうと判断した．実際問題としてカスタム

この MWSC 機能を利用すると，当該チャンネル絵文字の利用は非常にニーズが高いと考えられると同じチャンネル名が OrG 内のすべてのワークスので，カスタム絵文字を一切利用できないというペースで使えなくなる,という仕様がある．いわば運用は，仮に技術的に可能であったとしても実際OrG 全体の名前空間を占有してしまうのである．

は困難であると考えられる．

各ワークスペースからすれば，まったく無関係な結果として，本稿執筆時点で 2600 個を超えるカワークスペースで MWSC が利用されているためスタム絵文字が追加されている．一部，著作権なに希望するチャンネル名が利用できない，というどの観点から疑問のあるカスタム絵文字も見受け事態が生じてしまうことになる．そのため，チャられるが，差別的なものといった重大な問題を生ンネル名に一定の形式でワークスペース URL をじさせるようなケースは起きていない．ただ，カ含めるようにする，というルールを設けて限定的スタム絵文字を強制的に削除する措置などは（技に運用することにした．ルールを遵守させるため，術的には可能だが実際には）行った実績がないた

Slack 上の画面での MWSC の設定はできないようめ，今後課題となってくる可能性はあり得る．

ちなみにこの機能では，Enterprise Grid プラン側に存在するチャンネルを無料プラン側に共有できるだけで，逆向きに無料プラン側に存在するチャンネルを共有することはできないため，既に無料プランで利用していた場合にそのメッセージを無制限に参照できるよ
うになるわけではない．

9271

3.7 プロフィール超える数にとどまったため，調整により全件を実プロフィールはユーザが表示名・アイコンなど施することができ，抽選という事態は避けることを各自で設定するものであるが，Enterprise Grid プができた．その後，1 年後の 2023 年 8 月まで受付

ランではプロフィールが UTokyo Slack 全体で共通を続け，合計で約 150 件の編入を実施した．となっており，ワークスペースごとに異なる内容に設定することができない仕様となっている．通

4 導入にあたっての取り組み

常のワークスペースであればワークスペース内でここまで，Slack そのものの運用について紹介しの役割や立場をプロフィールに入力しておく使いてきた．以下では，Slack の導入にあたっての時系方ができるが，UTokyo Slack ではそのような利用列や利用者向けの取り組みなどについて述べる．

は難しくなってしまっている．

4.1 導入までの時系列

さらに，OrG 内の全ユーザのプロフィールを検索することや，そこからダイレクトメッセージ（個人間のメッセージ）を送信することも可能となっており，無効化することができない．同じ大学に所属しているからといって全員が相互に面識があるわけではなく，ハラスメント等のトラブルに繋東京大学での Slack の全学包括契約については，2021 年夏頃から検討を開始し，契約の実施と運用開始に向けての調整を経て，2022 年 8 月から運用を開始した．運用開始にあたっては，その直前の2022 年 7 月 19 日に，Slack から無料プランを事実上縮小するサービス内容変更が発表されたため，がる可能性も懸念されたが，幸いなことに現在の大きな混乱を招いた．具体的な変更内容は，無料ところそのような事態は生じていない．なお利用プランではそれまで過去のメッセージを 1 万件ま者に対しては，初めてサインインする際に表示される注意事項においてプロフィール機能などについて説明を行っており，取り扱いとしては同意を取った上での利用（一種のオプトイン）という形になっている．

で参照することができたのだが，参照できる範囲が 90 日間に変更されるというものであった．変更の期日は 2022 年 9 月 1 日とされた．1 つのワークスペースで 1 万件ものメッセージを扱うことは少ないため，この変更は参照できるメッセージが大3.8 既存ワークスペースの編入幅に縮小されるものと受け止められた．

UTokyo Slack は新たに契約した Enterprise Grid

有料プランであれば参照できる過去のメッセープランによる利用であり，ワークスペースも OrGジの範囲に制限はないため，全学包括契約は実質内に新しく作成することが基本となる．ただ，的に，それまでの無料プランでの利用の代替策・

UTokyo Slack 開始前から利用しているワークスペ受け皿としての役割が期待されることとなった．

ースを UTokyo Slack の有料プラン環境で利用した

当初の想定で lack は無料プランでも十分な利用がいというニーズは当然想定された．Slack にはワーできる状態であったため，全学包括契約は有料プクスペースの「移行」という仕組みがあり，ワークランの高度な機能を必要とするワークスペースをスペースを OrG 外から OrG 内に移動することが中心に徐々に展開していければよいと考えていたできるのだが，1 ヶ月におよそ 20 個（後に 40 個）が，ここで方針転換を迫られることになった．

までという上限があった．希望するすべてのワー

そのようなわけで，急ピッチで準備・調整を行

クスペースの移行を受け付けると上限を大きく超って，8 月 5 日に運用開始の旨の通知を発出し10，えてしまうことが想定されたため，代替手段とし8 月 24 日に説明会を開催，8 月 26 日からワークスて正規の移行ではなく新しいワークスペースでAPI を用いて擬似的にメッセージを再現する「移植」という方法を案内するなど，なるべく移行をペース作成申請の受付を開始するに至った．
4.2 利用者への情報提供とサポート
東京大学では，学内システムの情報を集約してせずに対応するように呼びかけた．また，「移植」提供する「utelecon」というポータルサイトを設けとの混同を避けるため移行ではなく「編入」といている（2020 年のオンライン授業をきっかけとしう表現を用いることにした．

たものである）[2][3][11]．そこで UTokyo Slack に結果として，編入（移行）を希望したワークス
ペースは初月においても 42 件と上限をわずかに10

https://utelecon.adm.u-tokyo.ac.jp/notice/2022/0805-slack272

ついても，この utelecon ポータルサイト上に説明ページを作成し11，手続きや注意点などを案内する
11

https://utelecon.adm.u-tokyo.ac.jp/slack/

ことにした．

料プラン契約で）Slack を利用していた学内の事例それに加えて，運用開始のタイミングでオンラについて，それぞれの利用者に発表してもらい紹イン (Zoom) での説明会も行うこととし ， 3 つ介する回とした．全学的なシステムとしての導入のパートに分けて日程を設定した．パート 1 はにあたっては，Slack を利用したことがない構成員

UTokyo Slack の概要やワークスペース作成というに向けた説明も必要と考え，どういったユースケ

基本的な内容を扱い，上述のように Enterprise Gridースで役に立つかが分かるように事例を紹介するプラン特有のさまざまな制約があることや，各ワことにしたものである．取り上げた事例は 5 件で，ークスペースで責任を持って利用してもらう必要授業・学科・留学事業・学生サポーター事業など幅があることについて，順を追って説明して理解し広い内容を扱うようにした．

12てもらう機会とした．また，Slido などのツールをさらに Slack 側からも運用支援を適宜受けてお併用した質疑応答により構成員からの疑問や要望り，2023 年 7～8 月には，編入（3.8 節）の終了にをあげてもらうこともできた．また，続くパート 2

合わせて「お役立ち情報共有会」というオンライは既存ワークスペースの編入に特化した内容としンイベントを開催した14．今後も利用者のさらなるた．結果として，説明会での質疑応答には多数の活用に繋がる施策を展開していくこととしている．

13

質問・意見が寄せられたが，その後に問い合わせが殺到するということはなく，安定した運用が行5 利用の状況えている．
またパート 3 は，「学内のこれまでの利用事例」と称し，従来から（無料プランあるいは個別の有

UTokyo Slack の利用状況として，ユーザ数およびワークスペース数の推移（図 1）を紹介する．ユ図 1：UTokyo Slack のユーザ数およびワークスペース数の推移

1213

14

https://utelecon.adm.u-tokyo.ac.jp/events/2022-slack/https://www.slido.com/jp

273

https://utelecon.adm.u-tokyo.ac.jp/events/2023-slack/ーザ数・ワークスペース数とも運用開始直後に顕謝辞

著な増加を見せているほか，その後も継続的に増加傾向にあることが読み取れる．また，学期が始utelecon ポータルサイト・サポート窓口の運営をまる時期（10 月初め・4 月初め）に特に増加のペ

通して UTokyo Slack の運用を支援してくださってースが速いこと，多少ではあるが授業が終わる時いる皆様（学生サポーターを含む）に感謝します．

期（1 月末～2 月初め，7 月末～8 月初め）に落ち込みが見られることから，授業をはじめ教育活動において利用されている様子が窺える．
直近では，ワークスペースは 1000 を超える数が利用されている15ほか，デイリーアクティブユーザ数は 4000 を超えてピークでは 5000 に達することもあるなど，活発に利用される状況にある．

6 おわりに
以上，東京大学において Slack「Enterprise Grid」プランの全学包括契約により提供している「UTokyo Slack」の運用について紹介した．
Slack に限ったことではないが，学内の多様な活動で利用される情報システムの管理・運用においては，利用者のユースケースに沿った利用が実現できるように工夫が必要であり，ときには適切に権限を委譲することも検討しなければならない．
特に Slack のようなクラウドサービスについては，権限の構成や設定についてカスタマイズできる範囲に限りがあり，思うような運用が実現できないことがある．実際，東京大学での運用も事前にさまざまな機能・設定について試行錯誤した上で定めたものである．
Slack の場合，複数のワークスペースを統合したEnterprise Grid プランの仕様が，必ずしも（たとえば研究室のような）比較的独立性が高いコミュニ
ティでワークスペースを作成・運用することを想定したものになっておらず，無理が生じてしまっている部分も出てきている．
しかし全体としては，多くのユーザによって活発に利用される環境を作ることができた．今後の方向性としては，ユーザ層の拡大や高度な機能の活用に向けた取り組みを進めることを考えている．
本報告のように運用事例・設定事例を蓄積・共有することで，大学の情報システムの運用をよりスムーズに行える環境に繋げることができればと思う．
ワークスペースに関してはアクティブか否かを考慮せず集計しているため，利用されていないものも相当
15274

参考文献
[1] 浦上理ほか，Slack を用いたプログラミング学
習者のつまずきの検出支援，情報教育シンポ
ジウム論文集 2021, pp. 9-13, 2021.
[2] 田浦健次朗ほか，東京大学におけるオンライン授業の始まりと展望，コンピュータソフト
ウェア 37(8), pp. 2-8, 2020．
[3] 田浦健次朗，授業オンライン化：情報基盤センターの取り組みの記録，東京大学情報基盤センター年報 21, pp. 91-98, 2021．
[4] 田浦健次朗，utelecon：コロナ禍での授業オンライン化で始まった教職学生共同の情報サービス向上の取り組み，東京大学情報基盤セン
ター年報 22, pp. 61-68, 2022．
[5] 高木望，3500 人もの教職員が参加！国立大初となる東工大の Slack 活用事例，
TECH +, 2021,
https://news.mynavi.jp/techplus/article/techp5613/. （参照 2023-10-10）[6] 高橋正和，近畿大学 全学生・教職員 3 万 6 千
人に Slack 導入 利便性と同時に「大学のブランディング」にも，INTERNET Watch, 2020,
https://internet.watch.impress.co.jp/docs/column/
slack_info/1254859.html. （参照 2023-10-10）[7] 宮城勝・吉原和明・井口信和，設定コマンドの入力インターフェイスに Slack を活用するネットワーク演習環境に対応した LMS の提案，2022 年度情報処理学会関西支部支部大会講演論文集，2022.
[8] 森村吉貴・渥美紀寿・古村隆明，多様な構成員を持つ大学 ICT 組織への Slack 導入によるコミュニケーション改善試行，大学 ICT 推進協議会 2018 年度年次大会論文集，2018.
[9] 森村吉貴・渥美紀寿・古村隆明，多様な構成員を持つ大学 ICT 組織への Slack 導入によるコミュニケーション改善の継続調査，大学ICT 推進協議会 2019 年度年次大会論文集，
2019.
[10] 山下和真・坂田志旺・谷口義明，大学内 Slack
ワークスペースの運用管理補助エージェントの開発，2022 年度情報処理学会関西支部支部
大会講演論文集，2022.
[11] 吉田塁，オンライン授業導入の舞台裏：東京
大学のオンライン授業を支えた一教員の視点から，情報処理 62(11), pp. 614-618, 2021．
数あると考えられる．