くらめその情シス:チャットシステム(Chatwork)について語ってみようか

くらめその情シス:チャットシステム(Chatwork)について語ってみようか

はじめに

こんにちは植木和樹@上越妙高オフィスです。本日もクラスメソッドの情報システムについて書いてみたいと思います。

前回のおさらい

  • 2013年当時、社員数は40人ほど拠点も秋葉原本社1つのみだった。
  • 2018年現在、社員は200名強、拠点は国内10拠点と海外2拠点に拡大
  • 社員や拠点の増加に伴い、これまでの仕組みや体制では運用に耐えられなくなってきた
  • IT推進室は社内にツールやサービスを展開し効率的な事業・業務が行えることを支援する部署

今回は「チャットシステム」についてです。

5年間のできごと

2013年当時、社内のチャットシステムは IPメッセンジャーでした。 社員のほとんどが会社に出勤して業務していたため、ユーザー管理不要で、ファイルの送受信もでき、会話ログもローカルにテキストファイルで残るため少人数で利用するには十分でした。

その後AWSコンサルティング部(現在のAWS事業本部)のメンバーが増え、客先訪問に伴うリモートワークが徐々に増えてくるとIPメッセンジャーでのやりとりが行えなくなりました。そのためチャットシステムの選定が開始されました。

最初に検討したのはSkypeです。チャットに加え、ビデオ通話もでき、スマホ用のアプリもある点で採用されました。しかしスマホアプリがバッテリーを著しく消費するという問題があり、早々に次の候補を検討することになります。

Hipchat等いろいろな候補があがりましたが、最終的にChatworkが選ばれました。確か社員の知り合いが開発に参加してたとかそんな理由だった気がします(記憶曖昧)。

なお当時SlackやTypetalkという候補が挙がったかは不明です。なにぶん私が東京にでてきたばかりで世間の流行に疎かったので。

実施した施策と今

2013年に導入してからずっとChatworkを使っています。5年間特に大きな見直しはしていません。

2014年頃から徐々にChatwork APIを利用した自動通知の仕組みが整備されていきました。

特にAWSのアップデート情報をRSSで取得してChatworkの部屋に通知する仕組みは、日々新機能をチェックしてブログを書くお兄さん達に好評のようです。

2017年にChatworkがWebhookに対応してからは、チャットにメッセージを書き込むと裏でLambdaが動いてメッセージを返してくれる、いわゆるchatbotの開発が盛んになってきました。

課題と今後について

Chatwork障害発生時の代替手段について、業務の継続という点で検討が必要です。緊急時はSlackやGoogle Chatで行うようになっていますが、緊急度の高い通知については別経路でも気付けるような仕組みが望まれます。

また代替ツールとしてSlackは引き続き検討中です。DevOpsツールの観点から評価するとSlack対応サービスの多さやスラッシュコマンドによるchatbotとの連携しやすさは魅力です。またSlackを利用している顧客も多く、開発プロジェクト単位でメッセージツールとして併用する場合もあるようです。(社内はChatwork, 社外はSlackと使い分けることで誤爆を防ぎやすいという意見もあります)

蓄積された過去のメッセージ自体にも価値があるので、そう簡単に切り替えできないのも悩みどころです。

チャットツールとしてChatworkの社内評価は高く、全社的な別サービスの採用については社員(特に非エンジニア部門)の意見を聞きながら進めるのが良いと思っています。エンジニアはなんでもそこそこ使いこなしますので。

まとめ

リモートワークが盛んな弊社においてチャットは業務の要です。スピード感のある情報連携と意思決定はチャットの上に成り立っています。

また仕事の面だけでなく「雑談部屋」等でやりとりされる雑多なコミュニケーションは、その人が元気に仕事できているかのバロメーターとも思っています(元気がなかったり、仕事がパツパツだと書き込みが顕著に減る)。

今後も様々なコミュニケーションツールがでてくると思います。コミュニケーションを活発しつつ、かつ業務の邪魔にならない点で選定していきたいと思います。

おまけ

「キーボードタイピングがどれくらい早ければチャットコミュニケーションに困らないか?」ということで、オペレーション部内でタイピングコンテストを開いたことがありました。

使ったサイトはこちら

結果、スコアが200あれば通常の会話に支障がないようです。エンジニアは250前後、オンラインゲームやる勢が300超。 一番早い人は「423」でした。