はじめに

こんにちは。IT本部IT戦略部テクニカルオペレーショングループの増田です。
テクニカルオペレーショングループは社内システムや各種ITツールの運用管理を担当する部署であり、私は主にSlackの運用を担当しています。

DeNAではSlackを用いた他組織（社外）とのコミュニケーションにおいて「Slackコネクト」を活用しています。
今回は従来使用していた「Slackゲスト」から「Slackコネクト」への切り替えを実施し、ライセンスコストと工数を削減した事例を紹介します。

この記事の流れ

• 「Slackコネクト」とは
• Slackコネクト活用の背景
• 具体的な移行手順
• Slackコネクト切り替え実施に伴う社内調整
• Slackコネクト切り替えで苦労したポイント
• 活用による効果
• まとめ

「Slackコネクト」とは

自社Slackワークスペース内の「Slackチャンネル」を、他組織と共有するための機能です。
※Slackコネクトでは「Slackチャンネル」と「DM（ダイレクトメッセージ）」の共有が可能ですが、今回は「Slackチャンネル」の共有について事例を紹介します。

Slackで他組織の方とやり取りする方法は「ゲスト方式」と「Slackコネクト」があり、それぞれ以下の違いがあります。

簡単にまとめるとSlackコネクトには「コスト」と「工数」におけるメリットがあります。

• 無料で他組織のユーザーをSlackチャンネルに参加させることができる。（コストメリット）
• 自組織でのユーザー発行が不要であり、アカウント作成や管理の工数がない。（工数メリット）

Slackコネクト活用の背景

Slackコネクトの使用を開始した理由

DeNAではこれまで、他組織とSlackでやり取りを行う際は「マルチチャンネルゲスト」を使用していました。
Slackコネクトのメリットは先程記載しましたが、なぜSlackコネクトを使用せず、「マルチチャンネルゲスト」を使用していたのでしょうか。
それは「Slackコネクトの使用条件」が理由です。

2023年4月まで、Slackコネクトを使用するには「共有する両組織ともに有料プランを使用中」である必要がありました。
そのため、他組織の状況により「ゲストアカウントを発行 or Slackコネクト使用」を個別に判断する必要があり、確認や設定の手間がかかるため「ゲストでの運用」を行っていました。
2023年5月に使用条件が緩和され「共有元（今回のケースではDeNA）が有料プランを使用していれば可能」となりました。
この変更がSlackコネクトへの切り替えを進める最大のきっかけです。
続いて、これまでのマルチチャンネルゲスト運用の課題を見ていきましょう。

マルチチャンネルゲストの抱えていた課題

マルチチャンネルゲストはSlackの通常メンバーと同じ機能が使用できますが、以下の課題を抱えていました。

• マルチチャンネルゲスト増加に伴うライセンスコストの増加。
  • ゲスト数が増加することでライセンス費用が増加傾向にありました。
  • 切り替え計画の開始時点で約700のアカウントが存在していました。
• ゲストアカウント管理の工数増
  • 手作業でのアカウント管理による工数の増加
    • DeNAの従業員はOktaとSlackの連携によってアカウント管理を自動化しています。
    • ゲストアカウントはSlack上に手作業で作成する必要があり、アカウントの発行工数がかかっていました。
    • ゲストアカウントの廃止や変更の際も依頼による手作業が発生し、アカウント数の増加に伴い運用工数が増加傾向でした。
• ゲスト管理におけるリスクの顕在化
  • 以下のケースで「ゲストに不要な情報を閲覧させてしまう」潜在的なリスクがある。
    • ゲストのがチャンネル内に残置され、情報閲覧可能な状態が続いてしまう。
    • 間違ったチャンネルにゲストを招待してしまう。

条件の緩和によりSlackコネクト使用のハードルが下がったことにより、上記課題解決を目的とした「マルチチャンネルゲストのSlackコネクトへの移行」をDeNAグループ全社での取り組みとして開始しました。

具体的な移行手順

移行は2023年7月から準備を開始し、以下の段取りで実施しました。

1.対象ゲストの確認と切り替え担当者の決定

Slack管理画面から全てのマルチチャンネルゲストを取得し、一覧を作成しました。 一覧はSlack管理画面の「CSVのエクスポート」から取得できますが、デフォルト状態では情報が不足しています。
対応として「列を編集する」から「ユーザーID、解除日、最後にアクティブだった日」等のの項目を追加てからエクスポートすることで「実際に使用されているゲストかどうか」の判断が可能です。

2.ゲストが「参加しているSlackチャンネル」を特定

Slackコネクトを行うためには「Slackチャンネル」と「Slackチャンネルが属するSlackワークスペース」を特定する必要があります。
しかし。マルチチャンネルゲストが「プライベートSlackチャンネル」に参加している場合、セキュリティ上の制約から管理者でも参加の実態を把握することができません。
そのため、ゲスト本人への個別確認を実施し、Slackコネクトを実施するチャンネルを特定しました。
確認にはどうしても手間がかかり、対応工数が大きくなる作業です。しかし、「Slackコネクトへの切り替え」には「どのチャンネルに参加しているか」の情報が不可欠であるため、各部署の従業員とゲスト本人に協力を頂きながら地道に進めました。
管理者目線の注意点として、各Slackワークスぺースの「generalチャンネル」はSlackコネクトを設定することができない仕様です。そのため、これまでゲストがgeneralチャンネルを使用していた場合は「別のチャンネル」に移動してもらう必要があります。

3.DeNA側のSlackコネクト使用ワークスペースの特定と設定実施

ここまでの準備が完了したらいよいよ「Slackコネクトへの切り替え」作業に進みます。
切り替えは大まかに以下のステップで実施します。

• Slackコネクトを行う「Slackアカウント」を特定する
• Slackワークスペース単位で「Slackコネクト」を有効化する。 Slackコネクトは「既存のSlackアカウント」ごとにSlackチャンネルを共有するため、コネクトする「Slackアカウント」を特定する必要があります。
  また、相手方がSlackアカウントを持っていないとコネクトの設定ができないため、「相手方の組織でSlackを利用しているか」の確認を行いました。
  すでにSlackを使用している場合は「Slackアカウント」を特定し、Slackコネクトの設定を進めます。
  Slackを使用していない場合は、相手方に「無料のSlack環境」を開設していただき、Slackアカウントを発行してもらいました。

4.相手方のSlack環境（ワークスペース）でSlackコネクトを許可してもらう

前述したとおり、Slackコネクトの使用条件として「片方が必ず有料プランを使用している必要がある」ため、有料のSlack Enterprise Gridを契約しているDeNA側に「コネクトしてもらう」統一ルールとしました。
コネクトしてもらうには、相手方のSlack環境において「Slackコネクトの許可」をしてもらう必要があります。
この手順が「ゲストの招待」と大きく異なるため、社内及び相手方への説明が難しいポイントでした。
以下のイラストの通り、相手方1件ずつ連絡を取り、共有を実施するSlackチャンネルごとに許可設定を実施して頂きました。

5.Slackコネクト化したチャンネルにメンバーを追加する

ここまでの手順でSlackコネクトを使用した「Slackチャンネルの共有」が完了しました。
続いてはいよいよチャンネルにSlackアカウントを追加していきます。
メンバーの追加も「DeNA側」、「相手側」それぞれのワークスペース管理者で実施が必要です。
試しにDeNAにおいて他組織のアカウントを追加してもエラーとなってしまいます。
この仕様により自社と他組織の間で「アカウントの管理責任」が明確になります。

Slackコネクトが必要なアカウントをすべて登録すれば、Slackコネクトへの移行は完了です！

Slackコネクト切り替え実施に伴う社内調整

これまでの手順で記載したとおり、SlackコネクトではDeNA側で「共有する相手方のアカウント」を統制することはできません。
逆を言えば「先方の管理者が許可すれば誰でもチャンネルに参加できる」状況になります。
そのため、事前にSlackコネクトを行うためのルールとして「業務上の契約有無」や「情報セキュリティの担保」を考慮したルール策定が必要でした。

また、Slackコネクトでは「3社以上の会社間で1つのチャンネルを共有」可能です。
そのため、会社間での秘密保持契約について、DeNA以外の事業者間にも注意喚起が必要でした。
例として外部のチャンネル参加者が「A社及びB社の社員」である場合、「DeNAとA社」、「DeNAとB社」の契約の他、A社はB社社員の投稿やり取りを目にするため、「A社とB社の間」で秘密保持契約等が必要になる場合があります。

上記の内容について社内法務部門やセキュリティ部門と検討・確認を行い、Slackコネクトの提供開始前に社内周知を実施しました。

Slackコネクトへの切り替えで苦労したポイント

Slackコネクトの移行の初期段階は各事業部のマネージャーに「対象ゲストの一覧」をお渡し、切り替え対応を個別に依頼していました。しかし一向に準備が進捗しない状態が続いてしまいました。
原因調査のために担当マネージャーへヒアリングを行うと、以下の課題がわかりました。

• ゲストを招待した管理者が退職・異動しており、現在の管理者が異なる。
• 過去の経緯がわからず、どうして良いかわからない。
• 複数の事業部や案件を横断して使用しているゲストであり、どこから進めていいかわからない。 これらの課題に対して、前述した「切り替え担当者」を明らかにする方法に変更しました。
  切り替え担当者決定後は専用の社内SlackチャンネルやDMで個別連絡を実施し、課題や質問に1つずつ対応していきました。
  約700アカウントが移行対象であり、相当手間はかかりますが、詳細なコミュニケーションを取りながら進めていく方針とし、最終的には100名以上の社内担当者と個別対応を実施しました。
  対応は対人コミュニケーションであり、時間と工数が最もかかったポイントでしたが、各アカウントの課題を1つずつ解消するために必要な対応だったと感じています。

活用による効果

本施策はマルチチャンネルゲストに関わる「コスト増」と「管理の負担増」についての対策として実施しました。
Slackコネクトの開始には工数がかかりますが、開始すればその後のコスト及び管理工数の削減に効果を発揮します。
ここからは具体的な効果を紹介します。

コスト削減効果

コスト削減については、約700名のマルチチャンネルゲストを削減することで相応のライセンスコストを削減することができました。
DeNA全体でのアカウント契約数が本施策実施前は計5,000アカウント存在したため、「約15％の削減効果」につながっています。
Slackは全社での使用ツールの中で最も高額なツールです。またコスト削減効果は単年でなく今後も継続するため実施工数に見合うコスト削減効果を発揮したと評価しています。

工数削減効果

ゲストアカウントの管理工数では、これまで年間で約200件のアカウント作成や削除依頼がありました。
Slackコネクト化により、アカウント管理工数が減り、年間で100時間程度の工数が削減できました。
また、「ゲスト」は自社の人員数と異なり、プロジェクトの発足等により適宜追加や削除が発生します。
そのため、Slack契約更新時のアカウント数量積算が困難になる要因となっていました。
今後は契約におけるゲスト数を考慮する必要が無くなり、更新数量の算出や金額交渉においても工数削減の効果が出ています。

まとめ

今回の施策はSlackコネクトの概念理解や移行対象ゲスト及びSlackチャンネルの精査など、各部門の切り替え担当者に多くの協力を頂きました。
各部門の負担が大きい内容でしたが、各担当者が率先して協力してくれたことが成功の大きな要因と感じています。
事前に全社への協力依頼などの根回しを実施しましたが、全社において施策の必要性を理解してもらえたことが成功につながったポイントでした。
自分自身の気づきとして、「コストや工数削減施策」の成功ファクターは「社内の意思統一が取れていることである」と、身を持って体感しました。

最後に

私の所属するテクニカルオペレーショングループでは新しい仲間を募集しています。
当グループでは、DeNAグループ全社IT環境の運用管理にとどまらず「業務改善や効率化・省力化」を目的とした様々な取り組みを行っています。
ご興味がある方はぜひ下記リンクから内容をご覧ください。