こんにちわ
Make Your Goals Come True. Easier + Faster.
をコンセプトに開発環境の改善や統一化をおこなっているanzaiです。
2013年10月よりチャットツールとして某Hを導入しておりましたが、2015年12月にSlackへ乗り換え（移行し）ました。
今回は、管理者視点で以下項目について書かせていただきました！
- 数あるチャットツールの中から、なぜ、Slackを選んだのか？
- 移行時に意識したところ
- はまったところ
- 大規模組織で運用してみて
- 今後の課題
※以下記載した情報は移行時点のものです。Slackは日々アップデートが行われていて、新しい機能やAPIが実装され続けています。あくまでもご参考までとして、移行を計画する際には、最新情報をご確認ください！
数あるチャットツールの中から、なぜ、Slackを選んだのか？
Integrationが豊富である
昨今、IT界隈で"CI"が注目のキーワードであるように、弊社でもCI環境については常に見直しが検討されています。
そういった流れの中で、Integrationが豊富で、様々なCIツール群と連携させることが可能なSlackへの移行は必然的という印象です。
弊社では以下の図のように、CI環境を構築し、GHEやJenkins等のツールからの通知をSlackに出すことで、業務の効率化や品質向上を目指しています。
通知（メンション）が気付きやすい
Slack上でメンション(@ユーザ名)を付けられて呼ばれた場合、通知や会話があったチャットルームの更新情報が、オンラインになった時に通知されます。
某Hはオフラインからの復帰時に通知されない仕様だったので、これは気付きやすくて便利です。
また、チャットルーム毎に通知の仕方を変更できるので、チャットルームの目的・用途に応じて通知レベルの変更も可能です。
また、デスクトップのアプリと、モバイルアプリで違いを付けることもできます。
より良いCI環境を整備していく上では、小さなメリットと思われがちの機能ですが大きなメリットだと考えています。
UIの良さ
SlackのUIは直感的でわかりやすいUIです。弊社でも多くの方がこのポイントをメリットとして挙げ、Slackに移行したいという要望が多くありました。
また、サイドバーの色もデフォルトで8パターンあったり、自分で色を変更できたりと、UIの色のカスタマイズが出来るところも愛着が湧きます。他にも、コメントの修正が簡単、絵文字が豊富などの良さもあります。
移行時に意識したところ
弊社はチャットツールへの依存度がかなり高いです。
コミュニケーションだけでなく、サービス状況のレポーティング等も行われているなど、某H上の会話履歴がなくなってしまったり、移行時に短時間でも利用できなくなることは業務に与える影響が大きいと考え、
「業務に一切影響を与えずに、スムーズにユーザがSlackへ移行できること」
を重要な要件とし、全てのチャットルーム、会話履歴、添付ファイルを営業時間外で移行することにしました。
また、1日も早くSlackを利用したいという声が大きかったので、2015年12月にまずは、移行の必要のないチャットルームやダイレクトメッセージを利用したい方向けに、Slackをリリースしました。
はまったところ
某Hのエクスポート機能
某Hからエクスポートしたデータをインポートしてくれる機能がSlackにはデフォルトで備わっていますので、当初は某Hのエクスポート機能を利用しデータをSlackへ簡単にインポート出来るであろうと考えていました。
しかし、その目論見は外れ…某Hのエクスポート機能は利用できなかったのです。 。
何千個もルームがあることや、ルーム名に日本語や記号を多様していたためかもしれません。
とにかく、エクスポートが途中で止まってしまい、某Hへ問い合わせをしても解決することはできませんでした。
不要なデータ（チャットルーム）の洗い出し
某H上にあるデータ量が膨大であることがは、移行時の足かせになることはエクスポート問題が発生した時に学んだので、まずは、不要なデータ（チャットルーム）を削除することにしました。
某HのAPIは、非公開チャットルームであっても最終更新やオーナー情報を取得することが可能でしたので、それを利用し、すべてのチャットルームの情報を取得しました。ここまではさくさくっと進んだものの・・・。
チャットルームの要/不要はオーナーにしか判断できないため、約7000件を超えるチャットルームのオーナーへひたすらヒアリングする作業が必要になりました。
もちろんできる限りヒアリングを自動化しましたけど・・・詰めの部分は人の手がどうしても必要になり、これが、なんと、大変だったことか。。
さらには、ヒアリングをしている間にも新しいチャットルームは次々と作成され・・・ヒアリングの繰り返し…途方も無い闘いでしたが、6000件近くの不要なチャットルームを削除し、最終1150個のチャットルームに絞りました。
某HとSlackの仕様把握
某HのAPIを活用して、会話履歴等を取得して、Slackの仕様に合わせてCSV出力させるスクリプト作成する上ではまったところです。※SlackではCSVファイルから会話履歴と添付ファイルをインポートすることが可能（参照:csv import）、
- Slackのインポート機能を使うと、エクスポートした会話履歴にいるメンバーがチャットルームに参加した状態になってしまう。※つまり、会話をしたことがある人は、退席していても参加している状態になり、逆に一度も会話してな人は参加してない状態になってしまうのでメンバーの精査と追加が必要になります。
- 某HのAPIでは、公開チャットルームのメンバーは移行開始時にログインしているメンバーしか取得できない。
- Slackではチャットルーム名に英数字しか使用できない
- ダブルクォーテーションにはバックスラッシュを付けないとインポートに失敗する
- HTMLタグは削除しないとインポート時にタグがそのまま表示される
- 某Hは最新順でデータはき出すので、古い順に時系列をソートしないといけなかった。
jqコマンドによるSlack仕様へのデータ変換
某HとSlack間の仕様を合わせる箇所が多くて、jqコマンドで変換したんですが、
会話履歴が10MBytes程度のチャットルームを変換するのに6時間もかかりました。当初は移行にそれほど時間がかからないと思っていましたが、2015年12月のリリースから移行完了まで2～3ヶ月の時間を要してしまいました。。
大規模組織で運用してみて
UIはすべて英語
Slackは日本語未対応です。そのためUIはすべて英語です。※2016年度内に対応するという噂ありw
英語というだけで拒否反応を起こしてしまう方も中にはいるので、全ての職種の方へ浸透させるには大きなハードルになりますので、弊社ではwikiにマニュアルを作成しました。
Usernameとかチャットルーム名とか
英数字であれば21文字制限付きですが、自由に設定できます。
管理者からすると、これが地味に困ってしまう問題です。
弊社ではUniqueなPersonalIDは、メールアドレスの左側か社員番号なんですが、
メールアドレスをUsernameにしようとすると21文字を超えてしまう方がいたり・・・自由に設定できてしまうことで、あだ名を設定されてしまう方がいて、誰なのかわからない状況になってしまったり・・・
大規模でSlackを利用する場合は、検索及び表示における利便性を考えて最低限のルールを策定したほうがベターです。
非公開チャットルームへ管理者権限でもアクセスできない
これはユーザーからするとメリットですが、管理側からすると若干デメリットでもあります。
例えば、非公開チャットルームを操作するには、管理者自身もそのチャットルームのメンバーになる必要があったり、非公開チャットルームのデータは管理者権限でもエクスポートできないので、つまり、他チャットツールへの移行時には非公開チャットルームの移行が大変になります。
今後の課題
Integrationとセキュリティ
新しいIntegrationが次々と増え、利便性が向上するに比例して、誤って重要な情報を外部に漏えいする危険性も高くなりますので、どのIntegrationをどの様に利用しているのか、情報漏えいしてしまうような使い方をしていないか、定期的にチェックをしていく予定です。