質問対応業務を DX した話
この記事は「 Aidemy Advent Calendar 2022 」の 23 日目の記事です。
はじめに
アイデミーでインターンをしている山本です。インターンでは、受講者からの質問に回答する業務(以下、質問対応業務)に携わっています。
この記事では、質問対応チームで質問管理システム「質問箱」を開発し、質問対応業務の DX を図った話について記したいと思います。
質問対応の業務フロー
Aidemy では、次の 4つのステップで質問対応業務を行なっています。
- 質問まとめ上げ
- 回答執筆
- レビュー
- 返信
図にするとこのようになります:
各ステップで行なっていることは次のとおりです:
① 質問まとめ上げ
Aidemy では頂いた問い合わせを Slack の特定のチャンネル(以下、問い合わせチャンネル)に流すようにしています。受講者からの質問は問い合わせに含まれます。したがって、 Slack に流れてくる問い合わせの中から受講者からの質問であるものをピックアップしてくる必要があります。このピックアップ作業を行うステップが「質問まとめ上げ」です。
② 回答執筆
ピックアップしてきた質問に対して回答を書くステップです。回答が書き終わったらチームメンバーに回答のレビューを依頼します。
③ レビュー
書き終わった回答をレビューし、誤りがないか?分かりやすいか?等を確認します。問題なければそのまま「返信」のステップに進みます。
④ 返信
質問を頂いた受講者へ作成した回答を返信します。
手動管理時代
自分が質問対応チームへアサインされたのは約 2 年前でした。当時、業務は次のような分担で行われていました:
- 質問まとめ上げ・返信担当
- 回答執筆・レビュー担当
頂いた質問は、質問まとめ上げ・返信担当が手作業で質問メッセージの URL 一覧を作成し、 Slack へ投稿することで管理していました。回答執筆・レビュー担当は、 URL 一覧の投稿から質問へ飛ぶことで業務を行なっていました。
参考に、ある日のまとめ上げ状況を以下に示します:
この方法では、次のような問題が発生していました:
- まとめ上げ・返信担当の業務負担が大きい上に属人化しやすい
- 「この質問は回答執筆中?レビュー待ち?」が実際に質問へ飛ぶまでわからない
特に 1 点目の問題の緊急性が高く、早急に DX を進める必要がありました。
Slack ワークフロー時代
DX 推進にあたって現状のフローの問題点を整理した結果、「業務フローのシステム化」が必要であることがわかりました。そこから「どのような機能をシステムに持たせれば、現状を打開できるか?」を考え、最終的に次の要件を満たせる質問管理システム「質問箱」を開発することにしました:
- まとめ上げを担当制ではなくチームメンバー全員で行えるようにする
- 質問の対応状況(回答執筆中、レビュー待ちなど)をリアルタイムで可視化する
これらの要件を満たせるようシステムを作り、出来上がったものが Slack ワークフローとスプレッドシートを組み合わせた次のシステムです。
このシステムでは、スプレッドシートを見ることで質問の対応状況を確認することができ、質問メッセージに所定のリアクションを押すことで対応状況を更新することができます。スプレッドシートの画面例を以下に示します:
どのリアクションを押すとどう対応状況が変わるのかは次の表の通りです:
リアクション | いつ押すか? | 押した後の対応状況 |
---|---|---|
新たに質問が来た時 | 質問対応開始 | |
回答を返信した後 | 質問対応完了 | |
回答の執筆を開始・再開する時 | 執筆開始 | |
回答の執筆を中断・断念する時 | 執筆断念 | |
回答が執筆でき、レビューを依頼する時 | 執筆完了 | |
レビューを開始・再開する時 | レビュー開始 | |
レビューを中断・断念する時 | レビュー断念 | |
レビューが完了し、修正箇所が見つかった時 | レビュー完了 |
このシステムの構成図は次の通りです:
リアクションごとに Slack ワークフローを構築し、ワークフローからスプレッドシートへの書き込みを行なっています。
Slack ワークフローとスプレッドシートを採用した理由は、前述の通り緊急性が高く時間をかけずにシステムを開発する必要があったからです。実際、このシステムは開発開始〜導入開始まで 20 日間しかかかりませんでした。
このシステムの登場により、手動管理時代に発生していた問題は次のように改善されました:
- 全員でまとめ上げを行うので、まとめ上げ・返信担当という分担自体が不要になった
- まとめ上げの際に URL 一覧を作成する手間が要らなくなった
- スプレッドシートを見れば、どの質問が今どのような対応状況なのかが一目でわかる
しかし、システムが稼働して数ヶ月経ったあたりから次のような問題が表面化してきました:
- 「なんか知らんけど動かなくなった」→「なんか知らんけど動くようになった」が時々発生する
- 既存ツールの組み合わせで作っているため拡張性が低い
- より業務を高効率、低負荷にできる機能を追加したいのにできない
加えてある時期から、スプレッドシートを配置していた Google ドライブの共有まわりの不具合により、新機能開発やメンテナンスなどができなくなってしまいました。つまり、「今はまだ動いているが、いつ動かなくなるか分からない」状況になってしまいました。
そこで、今のシステムからの移行と「質問箱」のさらなる発展のため、内製で Web アプリを開発することにしました。
Webアプリ時代
Web アプリを開発する目的は次の通りです:
- 既存システムから移行する
- 拡張性向上
出来上がったシステムが次の通りです:
従来のシステムと比べると、概ね次のような対応関係でリプレイスしたことになります。
- Slack ワークフロー → Slack App + Cloud Functions
- スプレッドシート → Web 画面 (Firebase Hosting + Firestore)
実際の Web 画面がこちらです:
Web アプリ化によって得られた恩恵は次の 3 つです:
- 拡張性向上のおかげで機能追加がしやすくなった
- 開発環境が強化( dev 環境の用意、自動テスト、 etc…)され、より迅速&確実なメンテナンスが可能になった
- システムのデータを蓄積することで、業務 DX の選択肢としてデータ分析・ AI 活用が採れるようになった
Web アプリは今年の 6 月にリリースしました。リリース直後 1 週間ほどは障害も多かったのですが、それ以降は大きな障害もなく安定して稼働しています。
今取り組んでいること
質問対応業務の DX をさらに推進すべく、現在は、データの蓄積・活用に取り組んでいます。具体的には次のようなものを考えています:
- 類似質問レコメンド AI モデル開発:届いた質問と類似した過去質問を AI がレコメンドし、執筆支援を行う
- 質問対応ログデータ基盤構築:質問ごとの各種応対ログを蓄積し、それらを可視化・分析することで業務品質の向上を図る
まとめ
この記事では、質問対応チームで質問管理システム「質問箱」を開発し、質問対応業務の DX を図った話について記しました。
ここまでお読みいただきありがとうございました。
Discussion