Slackでの「脱出チャンネル方式」運用の限界

コンプル導入以前はどのような管理をされていましたか？

Slackで、いわゆる「脱出チャンネル方式」の運用を行っていました。具体的には、タスク未対応な従業員を絞りこんだうえで期日とタスク内容を記載したチャンネルに招待し、期日後に残っている人全員にメンションをつけて催促連絡を送っていました。チャンネル上でどうしても対応してもらえない場合は、上長を含めたダイレクトメッセージで連絡しました。対象者が少ない時は、タスク完了時に依頼メッセージへ「済」のスタンプを付けてもらう運用も行っていました。

コンプル導入前の課題を教えてください。

最大の課題は、手作業によるリマインドの工数が膨大になっていたことです。脱出チャンネルでは「上長を含めない限り動かない人が一定数いる」状態になり、そういった人々に対して上長を入れてDMを手作業で送ることに大きな負担を感じていました。 副次的な課題もありました。依頼内容によっては完了率を100%にする必要があり、その計測が必須でしたが、脱出チャンネルの場合、脱出されると元々何人に依頼していたかがわからなくなり、タスク完了率の算出に手間がかかっていました。 さらに、Slackのチャンネルに一度に追加できるのは1,000人までのため、大人数の場合は複数回に分けて追加する必要があり、これも面倒さを感じていました。

「唯一無二のサービスであること」と「導入ハードルの低さ」

コンプル導入の決め手は何でしたか？

一番の決め手は、コンプル以外に似たサービスが存在しなかったことです。やりたいことは明確だったので自分で調査してみましたが、「自前で実装を進めた」という記事があるのみ。コンプル以外の製品は見つけられませんでした。コンプルを発見して話を聞いたところ、やりたいことに合致していたので導入を決めました。 また、当初行いたかったSlackとの連携が非常に簡単だったことと、タスクを対応する側の従業員がサインアップやログインの手間なくすぐに使い始められるハードルの低さも決め手の一つとなりました。

コンプル導入にどのような不安がありましたか？

大きく2つの不安がありました。1点目はタスクの完了率が本当に上がるのか、2点目はコンプルを用いた依頼が増えるのかという点です。 タスク対応側の従業員は脱出チャンネルでの運用に慣れていたため、コンプルのAppからメッセージが届く体験に対応できるか心配でした。 また、依頼する側も脱出チャンネルの運用に慣れていたこと、私が感じている課題を他の依頼者も同様に認識しているかわからなかったため、コンプルを使った依頼が増えるか不安でした。

増える「コンプルで依頼してほしい」の声

コンプル導入をどのように推進されましたか？

導入初期は、管理部門が草の根的に活動し、脱出チャンネルが利用されているケースで「コンプルを使いませんか？」と声がけする地道な普及活動を行いました。その後、コンプルの利便性を実感したタスク対応側の従業員からも、Slackの脱出チャンネル上で「コンプルを使用してほしい」という要望が投稿されるようになりました。結果として、自然と多くの依頼がコンプルを通じて行われるようになっていきました。

コンプル導入後の効果について教えてください。

導入時に不安だった2点について、効果が見られました。まず、タスクの完了率については、80%を超えるまでの速度が非常に早くなりました。依頼内容によっては100%完了になるケースも増え、依頼側の負担が大きく軽減されたことに満足しています。 コンプルを用いた依頼の増加についても、当初の心配は杞憂でした。脱出チャンネルを運用する側から「コンプルを使わせてほしい」という声が続々と届き、現在ではバックオフィス系だけでなく事業系の部署も含めて多くの方に利用が広がっています。コンプルでの依頼は既に月30件を超えており、今後も増加すると考えています。 さらに、タスク対応側の従業員からも、現在でもまだ脱出チャンネル方式で運用しているケースで「コンプルにしてくれたら楽なのに」という声を耳にすることがあります。

最後に一言お願いします。

自分がやりたかったことがそのままサービスとして提供されていたことに驚きと喜びを感じました。また、Speeeさんという上場企業が母体であることで、導入時に安心感がありました。また、定期的なヒアリングを通じてサービスが改善され、実際に反映されていることにも感謝しています。今後の発展に期待していますので、これからもよろしくお願いします。

撮影：タシロケンジ