こんにちは。MNTSQの下村です。 コーポレートエンジニアとして、MNTSQ従業員の生産系向上施策等を実施していたりします。
Twitterもやっているのでフォローしてもらえると嬉しいです!
本日は社員からの問い合わせ業務 いわゆる ヘルプデスク業務について効率化するためのツールを自作した 話を書いてみます。
この記事の要約
- 一人目コーポレートエンジニアとして参画したがヘルプデスク業務が非効率だったので効率化した。
- 質問に対して特定のemojiを押すとGitHub ProjectsのItemを作成するようにした。
- SlackスレッドのコメントとGitHub ProjectsのItemを双方向同期するようにした。
- Azure OpenAIも利用して効率化した。
きっかけ
2023年5月からMNTSQの一人目コーポレートエンジニアとして参画しています。
情報システムを色々と整備している真っ最中なのですが、ヘルプデスク業務のフローが未整備である というものがありました。
(あるあるですね。)
放置するとヘルプデスク業務の工数が増加する恐れがあったので対策を打つことにしました。
どんな問題があったか?
- 様々なSlackチャンネルで質問があり、どこでどんなステータスになっているかわからない。
- 「あの回答したっけ、、」とかとなり、Slackの過去書き込み等を検索して状況整理していた → ムダ
- ナレッジがたまらない。
- Slackでのみ回答をしているので類似事例等を検索できない → 属人化
- ヘルプデスクにどの程度の時間を費やしているか等の傾向分析ができない。
よくある解決方法として
ヘルプデスク用チャンネルを作ってSlackワークフロー等で質問を受け付ける というのがセオリーかと思います。 私自身もそうしようとしたのですが、下記のような悩みを抱えることになるなと思い何か別の方法を考えることにしました。
- 社員の生産性向上を行うのがコーポレートエンジニアなのに社員にルールを増やすことになる。
- ワークフローで質問してねーというルールを社員に周知徹底する必要がある。
- ワークフローを知らない方や、急ぎの質問などはワークフローが使われないケース等がありそう。
- ワークフローを知らない方にはワークフローのことを説明して、急ぎの質問だったりすると場合によってはコーポレートエンジニアが代筆するとかありそう。
- ワークフローで質問を受け付けるのは良いが、解決済か否かのステータス管理は結局難しいまま。
別の方法を探ってみる
まず、どんな機能が欲しいのかを整理してみました。 初手として下記機能を満たすSaaSを探してみることにしました。
- 問い合わせ内容をチケット管理したい。
- 従業員側はSlackにコメントするだけにしたい。
- 従業員にヘルプデスク用SaaSにログインさせて、質問をしてーみたいな面倒なことはさせたくない。
- どのSlackチャンネルからでもヘルプデスクメンバー側に負担なくチケット化したい。
- Slackの投稿内容がチケットに同期して欲しい。
- ヘルプデスク業務をアウトソースしたいので、アウトソースしやすいシンプルな仕組みが欲しい。
- 質問傾向等や対応時間などを解析できるようにしたい。
- せっかくなのでAIを活用して業務を簡略化したい。
- できるだけコストも抑えたい。
そんなわけでSaaSを探してみる。
探してみたのですがズバピタなものは見つかりませんでした。。。。
- Halp がイメージに近い。
- ただ、MNTSQではJiraを使ってないので断念。
- THENA も良さそうだが、GitHub連携は無い。
- issit が良さそう!と思いつつチケット化するだけなので、同期とかは難しそう。
じゃあどうする?
無いなら作ろう! ということで1週間ほどかけて突貫で作ることにしました。
こんな感じ のを作りました。
こういうフローになりました。
- 質問者
- 質問者は任意のパブリックチャンネルで質問をして、そのスレッドで状況の説明をする(だけ)
- ヘルプデスクメンバー
それぞれの機能についての解説1: ヘルプデスク宛の質問にemojiをつける
10分おきに下記処理を行うCloud Runを用意してヘルプデスク宛の質問だった場合はhelpdesk
といったemojiを該当メッセージに付けるようにしました。
(なぜemojiを付けるのかは後述します)
- 質問者が記載した質問内容をsearch.messages API を利用して検索。
- 検索条件はヘルプデスクメンバーが含まれるグループメンション or ヘルプデスクメンバーのメンション。
- 検索した内容をAzure OpenAIのAPIを利用してヘルプデスク宛の質問か否かをAIに判断させる。
- 下記のようなプロンプトで判断させてます。
投稿された内容はITヘルプデスクチームの問い合わせだと思いますか?なお、回答については「Yes」もしくは「No」という回答のみで答えてください。
- このようにすることで後続の判定処理に利用しやすくしています。
- 下記のようなプロンプトで判断させてます。
- AIがヘルプデスク宛だと判断した場合、reactions.add API を利用して
helpdesk
といったemojiを該当メッセージに付ける。 - 次回実行時用に、Firestoreに「どこまで検索済か」を記録するようにして終了。(同じメッセージに対して二重でemojiを付けないようようにしています)
それぞれの機能についての解説2: GitHub ProjectsのItemを作成
先述した、emojiを利用して下記のような処理を行います。
- Slack公式ツールである リアク字チャンネラー を使い、ヘルプデスク用Slackチャンネルにメッセージを転送する。
- emojiがついたことをトリガーにヘルプデスク用Slackチャンネルにチケット化したい内容が通知されるのでEvent Subscriptions を利用して、Cloud RunにGitHub ProjectsのAPIを利用してItemを作成する処理を命令する。
- このようにリアク字チャンネラーの機能を利用することで下記のようなメリットがあります。
- 各SlackチャンネルにEvent Subscriptions用のbotを招待しなくても良い。
- ヘルプデスク用チャンネルに転送するといった機能を自前で実装しなくて良くなる。
- このようにリアク字チャンネラーの機能を利用することで下記のようなメリットがあります。
- GitHub APIを利用して、該当メッセージに関するGitHub ProjectsのItemを作成する。
- 後述の同期処理用にFirestoreにSlackスレッドの情報(タイムスタンプなど)とGitHub ProjectsのItem ID等を記録しておく。
それぞれの機能についての解説3: SlackとGitHub ProjectsのItemを同期
10分おきに下記処理を行うCloud Runを用意して、SlackとGitHub ProjectsのItemを同期します。 こうすることによりヘルプデスクメンバーはGitHub Projectsだけを見る or コメントすれば良いことになります。
- GitHub API 及び Slack APIを利用して、ItemやSlackスレッドの内容に新しい投稿が無いかをチェックする。
- 新しい投稿があれば、その内容を同期して投稿する。
- 次回実行時用に、Firestoreに「どこまで同期済か」を記録するようにして終了。(同じメッセージに対して二重で投稿しないようにしています)
それぞれの機能についての解説4: 解析用のデータを蓄積
後ほど、ヘルプデスク対応について解析するために上記Cloud Runが実行されるたびに、下記内容を Google Sheets API を利用してスプレッドシートに記録、スプレッドシートの内容をもとにLooker Studioでレポート化しています。
- 質問者メールアドレス
- 質問者所属部署
- 対応開始、終了日時
- 全体所要時間
その他、工夫したポイント
- 対応開始と終了をbotから通知させるようにしてます。
- ちょっとしたことなのですが人対人のやりとりだと、「対応します!」→「お願いします!」みたいなやり取りが発生しがちなのでその時間も節約。
- 対応開始メッセージ
- ヘルプデスクは即対応を求められがち、ヘルプデスクメンバーも即対応をしがち。ただ、優先度に応じた対応をしたほうがいいのでその旨を毎回周知する。
- 対応終了メッセージ
- ヘルプデスク側は対応終了したつもりだったが、当人は「そうじゃない(まだ終わってない)」みたいなケースもあるので、その旨も告知。
リリース後の結果
リリース後は下記のように問題が解決しました。
- 様々なSlackチャンネルで質問があり、どこでどんなステータスになっているかわからない。
- → ストレスなくチケット化できる環境が整ったので、GitHub Projectsだけを見ればステータス管理できるようになった。
- ナレッジがたまらない。
- → すべてGitHub ProjectsのItemに蓄積されているので過去ナレッジが集約された。
- 今後は溜まったナレッジをAIに学習させて自動返答なども検討したいと考えているが、それの礎になるものができた。
- → すべてGitHub ProjectsのItemに蓄積されているので過去ナレッジが集約された。
- ヘルプデスクにどの程度の時間を費やしているか等の傾向分析ができない。
- → Looker Studioにより見える化できるようになったので傾向分析が可能に。
- 今後、どの部署に対してどのように手厚くすべきかなどが検討可能になりました。
また、運用が簡略化されたことで 対応工数が削減 できたのもポイントです。
「あれ?あの回答したっけ??」みたいにSlackを検索する時間も無くなりました。
また、未回答の総量等も見れるようになったので、「ある程度連続して時間を確保して一気に片付けよう」
みたいな計画も立てられるようになりました。
その他嬉しいこと
- 開発者から褒められた。
- 本業の方から褒められるのは純粋に嬉しいですね☺️
- 横展開を希望された。
- 横展開できるように想定していたのでこう言われるのも嬉しいですね☺️
- 低コストでできた。
- 月額3,000円程度の維持費。
- Halpだと最低でも一人あたり月額$150- なのでだいぶ低コストで出来た☺️
- 自作ツールなので汎用性がある。
- 今後、仮にNotionやasanaにタスク管理を移行する!となっても同じ仕組みで流用できそう。
後悔することも
- 自作なので 自分の理想形 になるのは良いのですが、自作なので自社メンテが必要になるため、負債化してしまったなと思ってます。
- 今後もヘルプデスク管理ツールの動向を見守りながら、良さそうなツールがあれば即リプレイスしたいなとは思っています。
- wrangle.io は今は気になり(このシステム構築後にこのツイートを気づいた)
2024年1月追記
GitHub Issueにチケットを貯めるのではなく、Notionでヘルプデスク用のDatabaseを作成してそちらに貯めるように変更しました。
チケット作成ごとにNotion Pageを作成して、Slackスレッドの内容はNotion Page上のコメントに同期するようにしました。
この形の方が便利でした。
(問い合わせ者への返信はNotion Pageのコメントに投稿、そうじゃない内部向けのメモはPage上に記載するようにすることで情報整理できる)
ニーズがありそうなら、どこかのタイミングで新たに投稿したいなと思っています。
最後に
本記事ではヘルプデスク業務を自作ツールで効率化した話を記載しました。 同じようにお困りの方の参考となれば嬉しいです。
MNTSQでは すべての合意をフェアにする というミッションを掲げています。 sg.wantedly.com
そんなミッションに共感してくれる方、ぜひMNTSQで一緒に働きましょう!