こんにちは。ASKULウェブサイトの保守・運用を担当している新卒エンジニアメンバーです。
今回は社内の問い合わせ対応を集約化および効率化するため、Backlogというツールを利用し始めたことについて記事にしたいと思います。
はじめに
背景
私たちは、日々社内から寄せられるASKULウェブサイトのシステムに関する問い合わせ対応をする業務を行っています。
「この値が知りたい」「ここの画面のスクリーンショットが欲しい」など問い合わせの内容は多様で、さらにその経路もメールやSlack、Microsoft Teamsなど多岐に渡ります。その都合で、問い合わせを見落としてしまったり、管理が行き届かないために回答までに長い時間を要してしまうケースがありました。
これに対し、以前、社内からの問い合わせ窓口としてフォームを開設した記事が上がっています。
目的
今回はさらに一歩進んだ段階を目指しています。
具体的には、問い合わせの起票と対応の場所を1か所に集約し、過去の問い合わせが一覧的に表示・検索できる環境を構築することで問い合わせに関わる業務の効率化を目指そうというものです。
これにより問い合わせをする人も問い合わせ対応状況のステータスを追うことができたり、オープンになった過去のナレッジから問い合わせ解決までのスピード感が増したり、問い合わせ対応の総残量を掴みやすくなり解決までの対応をお互いに協力し合えたりと副産物的な利点があると考えています。
問い合わせ窓口をBacklogに統一しました
Backlogとは
まず、今回問い合わせの窓口として使用したBacklogというツールについて紹介したいと思います。 一言でいうと、Backlogとはプロジェクト管理に必要なさまざまな機能を搭載したプロジェクト管理ツールです。 具体的な機能としては次のようなものがあります。
- 課題：タスクを追加、管理する機能
- Wiki：プロジェクトメンバーに向けた情報を文書で管理する機能
- 外部サービスとの連携：JiraやRedmine、slackなどと連携できる機能
- ガントチャート：プロジェクトの進捗を見える化する機能
- バージョン管理：GitやSubversionを使ってソースコードを管理できる機能
- カンバンボード：課題の状態を直感的に変更できる機能
その中で今回はこの3つの機能を用いて問い合わせ管理を行いました。
- 課題
- Wiki
- 外部サービスとの連携
各問い合わせを課題として追加します。
Wiki機能は問い合わせをするうえでのマニュアルとして活用しました。
また、外部サービスとの連携については「テクニカルな工夫」にて詳しく説明したいと思います。
Backlog化のメリット
1. 問い合わせの総量やステータスが可視化されているので把握がしやすい
従来の運用だと多様な経路で問い合わせがきてしまうため、「問い合わせがどのくらいあるのか」「どの問い合わせを担当しているのか」「問い合わせの進捗はどうか」などの管理をすることが難しい状況にありましたが、Backlogに集約して管理できるので総量や進捗の把握がとてもしやすくなりました。私たちも常にBacklogで問い合わせの進捗をみて、今後どう対応していくかを考えることができていると実感しています。
2. ナレッジを蓄積できる
Backlogにて管理することで、過去の問い合わせと対応のナレッジを蓄積できます。蓄積することで類似の問い合わせを探すことができるようになるため、対応を際に活用できると考えています。今はナレッジを蓄積する段階ではありますが、今後問い合わせを解決するスピードが上がることを期待しています。
テクニカルな工夫
Backlogを用いた問い合わせに関する業務を効率よく行うために、普段チャットツールとして使用しているSlackにBacklogを連携しました。
1. プロジェクトへの参加フォーム
問い合わせをBacklogで起票と管理をするためには、問い合わせする人がBacklogのプロジェクトに参加している必要があります。この参加のフローをスムーズにするため、Microsoft Formsでプロジェクト参加申請フォームを作成しました。このフォームには、送信されるとSlackに通知されるというフローをMicrosoft Power Automateを用いて組んでいて、通知があれば手動でユーザの追加を行います。
2. 課題起票時の通知
Backlogには課題の起票やコメントなどをメールで通知する機能があります。しかしメールでの通知だと他のメールに埋もれて見逃してしまう可能性や、起票に気づくのが遅れる可能性があります。そこでBacklogのプロジェクト設定のインテグレーションからSlackを連携し、課題起票の際にはSlackの指定チャンネルへ通知を投稿するようにしました。この機能はBacklogの機能なので簡単に設定できます。
困ったこと・大変だったこと
新しく問い合わせのフローを作成するにあたり、事前に既存の問い合わせがどのように運用されているかを知らなかった私たちは、まず現状の把握から行いました。非効率な点や問題のある箇所を把握するために、既存の問い合わせを利用している人（問い合わせする側/受ける側）に対して現状のヒアリングを行いました。問い合わせBacklog化をするにあたって弊害となる箇所や懸念点を洗い出し、それをどのように新体制に落とし込むか議論を行いました。その際、Backlogを知っている部署と知らない部署があったため、Backlogの操作方法をまとめたマニュアルを作成して説明会を実施しました。問い合わせを利用する人のアカウントをBacklogに追加する方法を検討した際には、追加するメールアドレスの一覧のCSVファイルを作成し、Backlogに一括追加することで解決しました。
そうして運用が開始されましたが、想定外のケースが頻発したことで頭を抱えることがしばしばありました。たとえば、問い合わせ内容の都合で対応者が複数出てきたケースや、それにより担当者が不明瞭となり課題の対応に無駄な時間を要してしまう場面などがありました。また、個人情報の受け渡しはセキュリティの観点からBacklogに直接の記載ができない中でいかにスマートに問い合わせのフローを組むかなど、運用の改善に向け引き続き話し合いを重ねていきました。
まとめ
運用開始から1ヶ月。結論を出すにはまだいささか早いですが今時点でもよい試みであったといえます。 まだまだ改善すべき点があるこの「問い合わせのBacklog化」ですが、前述したBacklog化のメリットは徐々に享受できていますし、さまざまな方に利用していただいています。 これからどんどん改善していくことでとてもよいものになる予感がしています。
改善したいものやアイデアはすでにいくつか浮かんできており、「よいものになる予感」が現実になる日もそう遠くありません。 たとえば、問い合わせする人をプロジェクトに追加する際、最後は手動でユーザの追加をしなければならないところを自動化出来ないだろうか?というアイデアがあります。 これが実現すれば今よりもっと簡単にBacklogを使っていただけるようになると考えています。
改善だけでなく、ASKULウェブサイトのシステムに関する問い合わせに限定した運用をしているこのプロジェクトを、ゆくゆくは全社的に展開しようという考えもあります。 改善が積み重なり、社内全体にこのプロジェクトが波及した暁には間違いなくこのプロジェクトは「よいもの」になるでしょうし、業務効率も上がることでしょう。 そうなるように今後も私たち新卒エンジニアメンバーで改善を続けていきたいと思っています。
また直接的なメリットではありませんが、新しいプロジェクトをゼロから進めるノウハウや、色々なステークホルダーの方々と関わる経験が新人時点で得られたことが私たち新卒エンジニアメンバーとしては大きな財産になったと感じます。 今回得られた財産を活かし、何か効果的なことができた際には再び筆を取ろうと思います。拙文ではございましたが閲読いただきありがとうございました。
