モバイルアプリエンジニアの山下です。
LCLでは今年の4月から社内で利用するチャットツールをSlackに完全移行しました。弊社は小さな組織ではあるものの、全社で日々利用しているツールの移行を一エンジニアが遂行することはあまりない機会なので、今回得たの知見をブログに残しておこうと思います。
なぜSlackに移行する必要があったか
移行に至るまでの理由は多くありますが、ここでは最も重要だと感じている3つを挙げたいと思います。
- 外部サービス連携の豊富さ
弊社は効率化や自動化が好きなメンバーが多く、サービスのデプロイから蔵書貸出まで様々なシチュエーションでチャットを起点にしたChatOps環境を作っています。また、国内外製問わず多くのサービスを利用しており、それらの情報もチャットへ集約しているため、チャットツールはコミュニケーションのみでなく、情報や機能を集約する役割を担っています。
しかし、これまでのツールでは外部サービス連携が弱かったため、大半のサービスでは自前で一から仕組みを作る必要がありました。加えてチャット自体の表現も乏しく、様々な情報をテキストのみで表示するのに限界もありました。
ChatOpsは便利で効率的な取り組みですが、度々開発やメンテナンスに工数が取られていては私たちが本来やるべき"ユーザに価値を提供する"時間が減ってしまいます。
これまで採用していたツールでは、働き方の拡張性と効率化に限界を感じたのが一番の理由でした。
- リアクションによるコミュニケーション手段の拡張性と効率化
これまでのツールでも絵文字を単体で返信してリアクションする文化はありました。絵文字でのリアクションは雰囲気を明るくし、日々のコミュニケーションを効率化する2つのメリットがあります。
しかし、これまでのツールは絵文字のリアクションひとつひとつが投稿として扱われていたため、絵文字だけの未読が大量に発生し、既読する手間と煩わしさがありました。加えて、オリジナルの絵文字を追加することができなかったので決まったリアクションしか返せず、表現手段に拡張性がありませんでした。
Slackのリアクションでは、投稿に絵文字を付けることで未読判定になりません。また、カスタム絵文字を追加することでタイピング不要であらゆる表現をリアクションできます。
チャット文化が浸透した組織には、よりリッチなコミュニケーション手段が必要でした。
- 全未読と全既読ボタンによる効率化
情報と機能のHUBとなっているチャットツールでは多くの未読が発生します。これまでのツールでは既読にするために個々にチャンネルを開く手間があり、とても効率が悪い作業でした。
Slackでは未読を一括で既読にできますし、その上で未読を横断的に確認することができます。たかが既読手段ですが、全員が毎日何回も行う作業なのでトータルでかなりの効率アップなのは間違いありません。
他にも情報がオープンベースになったり、色々なサービスのサムネイルが表示されるようになったりと大小含めて多くのメリットがあります。
どのように移行を流れを作ったか
移行プロジェクトにおいての一番の課題は「移行したい」と言って移行できるわけではないところです。特にチャットツールは毎日使っているものですし、社員全員を巻き込むことになるので色々な方面で理解と協力が必要です。
そのため、まずは身近なエンジニアメンバーに移行を訴求して協力してくれるメンバーを増やすことを始めました。幸い、LCLには日々の生産性を上げることに意欲的なメンバーが多く在籍しており、声を上げれば協力してくれるメンバーもたくさんいました。
チームへどのように訴求したか
エンジニアメンバーは、Slackの存在や一部機能も認知しているメンバーが多いのでより具体的な既存ツールの課題とSlackのメリットを2つの手段で伝えていきました。
1つ目は、ことある毎に「Slackだったら〜」という流れでメリットを訴求しました。半分ぼやきなのでしつこかったり、言っといて行動に起こさないと嫌われる恐れがあるので注意です。
2つ目は、上で発信していた内容や細かいけどあると嬉しい細部の機能を既存のツールと比較したスライドを作ってミーティングで共有しました。
その甲斐あって2つ目のミーティング後から一部のメンバーで試験導入する流れになり、業務に支障のないエンジニアだけのチャンネルを利用して2~3ヶ月ほど運用しました。やはり、全員がいる時に時間を確保して訴求すると話が確実に進むので事前準備とファシリテートは大切です。
試験導入をしてからは初めはチャンネル一覧の表示順などで慣れないこともありましたが、使っていくうちに既存のサービスにはもう戻れなくなりました。
十分な試用期間を経て改めてチームと相談した結果、正式に導入することは決まりましたが、次に課題となるのが社内で2つのチャットツールを運用しなければいけないことです。
しかし、これについては部長が上層部のミーティングで事前に共有してくれていたおかげで、他部署メンバーにも「エンジニアが良いと判断したツールなら」と快く協力していただけることになり、全社導入の流れになりました。
合意を得ることが終わりではない
これでめでたく全社導入の合意を取ることができたものの、まだやるべきことはあります。そのうちのひとつが"稟議"です。
口頭による合意を得られたとはいえ、会社としてコストが発生するものなので経営層が快く承認を出せるような稟議書を提出する必要がありました。
エンジニアメンバーは既存のサービスよりもSlackの方が有名で様々な企業で採用されているツールという前提知識はありましたが、他の社員の大半は知らないのでフラットな視点でどのようなメリットがあるかを丁寧に明文化しなければなりませんでした。
経営層へどのような訴求をしたか
稟議ではより具体的な機能ではなく、「工数を削減できるか」、「会社全体としてどういうメリットがあるか」を訴求しました。はじめは丁寧に書きすぎてかなりの長文になってしまったのですが、あまり長すぎても伝わらないとアドバイスをいただき、最終的には以下の3つを中心に書きました。
・作業効率向上と余分な工数削減
冒頭で書いたようにチャットツールは情報や機能のHUBになっていること、その上で効率化するためにもエンジニアの工数が掛かっていることを挙げ、Slackを導入すること削減できたりエンジニア以外も普段使っているサービスと連携してより効率的に作業が進むことを強調しました。
・エンジニア採用での魅力
Slackの知名度や多くの企業で採用されていることを背景に新たなメンバーが業務を進める上で立ち上がりが早くなること。またいわゆる『イケてるツール』を使っていること自体がすごく重要で、職場の魅力に直結する部分で採用にも影響があることを強調しました。
・通話やグループ通話、画面共有でリモートでのやりとりを軽減
事業やチームの規模が広がっていく中で、リモート勤務時の打ち合わせや緊急の障害対応なども増えてきており、テキストベースよりも口頭で話した方がよい場面も増えてきました。これらはリアルタイム性が高い時に発生することで、その際に外部サービスや環境の準備を行わずともデスクトップやスマートフォンで直ぐに通話や画面共有ができることが、より作業を円滑に進めやすくなり負荷の軽減や効率アップに繋がることを強調しました。
その他にも権限管理や閲覧制限の範囲など全社で利用するための管理が問題なくできるかも補足しました。
合意を得ていたので稟議書の内容で却下されることはありませんが、こういうところも丁寧に対応することで信頼を得て、任せて良かったと思ってもらうことが次にも繋がるので大切ですね。
移行の準備は何をしたか
稟議も通り、ここからは改めてチーム内外のメンバーと全社移行の準備を進めました。
- 全員向けの「ガイドライン」を用意
エンジニアチームは全社移行する前から先行してチーム内で完結するチャンネルのみ移行していたため、方針は既に固まっていました。その内容を他部署メンバーにも伝わりやすくまとめたドキュメントを作成しました。
このガイドラインは4つの項目で構成されています。
1. 名前はローマ字で登録しましょう
Slackは@を打つことでメンション相手の候補を表示することができますが、日本語だと変換するまで候補が表示されません。
漢字での登録は利便性が損なわれるので必ずローマ字で登録しましょう！
やりがちな先頭にlcl-を付けるのも、候補を絞り込みづらくなってしまうためNGです🙅
2. 一目でわかりやすいアイコンを設定しましょう
同じようなアイコンが並んでいて見づらい思いをするのは自分ではなく周りのメンバーです😢
デフォルトアイコンから一目でわかりやすいアイコンに変更しましょう👀
他のサービスとアイコンを統一することでより視認性が上がります！
3. チャンネル作成時は頭文字を付けましょう
Slackのチャンネル一覧はアルファベット順に固定で表示されます。
そのため、対象や用途が類似するチャンネルの並びを意図的にまとめることで、
チャンネルを探したり、乱立してしまうことを防げます！
チャンネルを作成する際は、以下の命名規則を参考にしてください。
> 部署-カテゴリ-用途
例：lcl-all-勤怠連絡、en-tech-ios
⚠️ 注意
・連結に使う記号は ハイフン（-）のみ
・チャンネル名には「チャンネル」、「ルーム」の文字列は含めない
(以下、階層ごとの説明は省略)
4. チャンネルはパブリックチャンネルで作りましょう
機密性の高い情報や個人情報を扱うチャンネル以外は、原則パブリックチャンネルとして作成しましょう。
加えて、DM（ダイレクトメッセージ）も極力使わないようにしましょう。
これは、「情報格差」を生まないようにすることを目的としています。
社内の動きを必要であれば誰でも"見に行ける"状態にすることで、一次情報をキャッチアップできるため不安定で非効率な伝達を無くしたり、同じ認識を全員で共有することができるようになります。
具体的に減らせることの例
・「XXさんはn日までが期日だと言ってました」というような伝達
💀 その期日が合っているかは不確実
💀 期日の根拠を知ることができない
・特定の人物のみが知り得ていた知識や作業
💀 その人物が不在の時に対処することができない
💀 その人物が退職する際に引き継ぎのリスクが高い
・バラバラに届く同じ質問
💀 説明の機会が度々発生する
💀 質問しなかった（できなかった）人は情報を得られない
前述の命名規則を元に所属部署のチャンネルへ自分で参加することで、個別にチャンネルへ招待する手間も省くことができます。
3のチャンネルの命名は一覧の視認性と運用コストのバランスをとって、このような運用方法に決めました。細かく命名に口は出さず、基本的には部署階層で区別できていれば各部の裁量に任せています。
4については、中には情報をオープンにする組織に慣れていないメンバーもいるので、情報を閉じることでどういう問題が発生するのかの例をいくつか載せています。
- Slack初心者向けの「はじめてガイド」を用意
これはSlack公式のヘルプセンターの重要項目のみをスクショで切り貼りしたドキュメントで、Slack特有の機能や設定を知ってもらうために作りました。
- 管理者向けの「運用ガイド」を用意
全社で使うツールなので権限や公開範囲、ユーザグループ等の機能説明をまとめたドキュメントを作成し、管理者向けに共有しました。
これらのドキュメント作成以外にもチャンネルの準備、権限の設定、ChatOpsの機能を移行等などやることが沢山ありましたが、エンジニアメンバーの協力も得ながら無事に発足から半年近く掛かって移行が終わりました。
移行してからどう変わったか
エンジニアはもちろん他部署メンバーも今ではSlackに慣れ、これまで以上に部署を跨いだコミュニケーションも増えました。特にこれまではエンジニアのみで使っていた外部サービス連携や自前のbotもエンジニア以外のメンバーが見たり、操作できるようになったのでよりChatOpsの領域が広がりました。
情報のオープン化もダイレクトチャットがやや高めなもののパブリックチャンネルが90%前後なので良い結果のように思います。
この背景には「部横断の個別連絡」チャンネルという、主にメンション用のチャンネルがあることがひとつの要因かと思っています。どのチャンネルにも属さないような連絡はDMでやりとりされがちなところ、このチャンネルがあることにより第三者も見れる状態を作れています。
敢えて期待より少し劣る部分があったとすれば、リアクションがあまり盛り上がってないところです。全く使われていないわけでなく、至る所で色々なカスタム絵文字が使われていて当初のコミュニケーションの拡張としての働きは十分にできているのですが、ひとつの投稿にたくさんのリアクションが付いているところはまだあまりありません。LCLの特徴として比較的落ち着いている社員が多いこともあると思いますが、少し寂しいのでもう少し盛り上げられたらと思っています。
さいごに
改めてですが約半年ほど掛けて主体的に全社ツールを移行できたのは良い経験になりました。今回の内容では書き切れませんでしたが、Chatbotの基盤も汎用性の高い設計で用意したり、これまで使っていたチャット通知基盤を整備したり、業務と並行して移行作業を地道に進めてきましたが、周りの協力があったおかげで大きな問題なく進めることができました。
LCLでは、組織全体で働きやすい環境・チームづくりに日々取り組んでいます。 少しでも興味をもっていただけた方は、カジュアルな面談からでもぜひお越しいただければと思います！
