この記事は HTアドベントカレンダー 19日目の記事です 
はじめに
Megと申します。
私が所属する博報堂テクノロジーズは、博報堂ＤＹグループ各社の情報システム運用も担っています。
その中で私は、Hakuhodo DY ONEの社内情報システム運用（主にヘルプデスク）を担当しています。
Hakuhodo DY ONEは、2024年4月1日にデジタル・アドバタイジング・コンソーシアム（DAC）とアイレップが統合してできた会社です。
会社の統合に伴い両社のヘルプデスク運用やナレッジ運用も統合することとなり、このタイミングで「SlackとNotionを組み合わせた依頼対応・管理体制」を構築しました。
今回は、2024年から現在にかけて以下の運用をどのように変更してきたかをお話しします。
- 依頼や申請の受付・やり取りの方法
- チケットやナレッジの作成・管理・活用方法
ヘルプデスクの規模
Hakuhodo DY ONEの子会社サポートも受けているため、非常にざっくりですが以下の規模で運営しています。
- サポート対象：4～5,000名
- 月の依頼数：900件程度 （入退職手続きを除く直近6ヶ月の平均）
- 一次対応メンバー：5～6名
現在の体制図
Hakuhodo DY ONEでは以下の2つのツールを柱として利用しているため、それに合わせた体制にしています。
- コミュニケーションツール：Slack
- ナレッジ等の蓄積ツール：Notion
一部の申請については旧来のワークフローを使うことがありますが、依頼全体の9割以上を以下の体制で管理・運用しています。
黒色のDB：依頼者が閲覧可能なもの
橙色のDB：ヘルプデスクのみが閲覧・編集可能なもの
依頼者・ヘルプデスク両者共に、利用ツールの種類を極力少なくする方向を目指しました。
社内開発ツールによって、Slackワークフロー（以下、SlackWF）で届いた依頼は自動でNotionDBへ起票されます。
ステータス・担当者変更やクローズ時のチケットへのログ記載命令も、SlackWFのボタンを押すだけで可能です。
AIを用いて、対応スレッドの内容を要約した上で自動でチケットへ記載することも可能です。
対面対応予定が入った場合は、対応リソース管理のために専用のDBへ別途起票しています。
基本の依頼・対応フロー
ポイントは先述のとおり、
- 依頼者：Slack上で依頼や会話をすれば良い
- ヘルプデスク：基本的にSlackの画面だけで対応できる
という、なるべく利用ツールが少なく済む状況を構築しています。
SlackとNotionへの連携は、Slackワークフローのカスタムステップに組み込まれている社内開発ツールが担ってくれています。
「そこをもっと詳しく！」と言われそうですが、私はシステムの開発依頼をしただけの立場なので、詳細は開発担当にお任せします😶🌫️
また、依頼受付はSlackのパブリックチャンネルで行っており、依頼者自身での過去類似案件検索も容易です。
対応スレッドをNotion AIに読み込ませ、ナレッジページのたたき台自動生成も可能です
Enterprise Grid環境でマルチワークスペース化されたSlackのチャンネルでは、NotionAIで情報が正しく取得できない場合があります。
朝会の運用
ヘルプデスクメンバーにて毎朝15分程度、未着手案件の振り分けや当日の対面対応スケジュール認識合わせ・担当案件で行き詰まっていることを解決するための朝会を実施しています。
朝会議事録ページは、自動作成されるようNotionのオートメーションで設定しました。
また、議事録のテンプレートページ内ではリンクドデータベース機能やリレーション機能を用い、当日の対面対応予定や依頼チケットの未着手一覧が自動で表示されるよう設定しています。
NotionAI議事録のブロックも作っていますので、ストレスなく朝会の内容を記録できます。
レポーティング
図には書いていませんが、依頼チケット管理DBのデータをもとに毎月のヘルプデスク対応レポートをNotion上で作成・管理しています。
NotionAIを活用し、
- 月ごとの依頼数や、期限内完了率、対象月のカテゴリごと・対応者ごとの依頼数をチャートで表示
- カテゴリ分けできない依頼の中で、突出した傾向があったかの分析
- 各人どういった対応を手掛けていたかの傾向分析
といったことが可能です。
以前の体制では、たたき台作成までで3～4人がかり・対応業務の傍らで作業して7～8営業日程度かかっていたため、数字を出すだけで手いっぱいでした。。
今は、NotionAIへ依頼することで待ち時間も含めて1名1～2時間程度でたたき台作成まで行えています。
工数が空いた分で、数字に現れない部分も加味したレポート作成が可能になりました。
この体制にして良かったこと
- 利用ツールがシンプルになり、ツールの習熟リソースを集中できた
- 依頼者・ヘルプデスクの双方でコミュニケーションコストが下がった
- 全社利用ツールを使うことで、チケット管理等への別途コスト（予算・運用）の抑制ができた
- AI活用により、レポーティングやナレッジ作成等周辺業務の工数を大幅に軽減できた
ことが特に大きな効果だと感じています。さらに、
- 全社利用可能なツールを用いているので、情シスでの事例を元に他部署でも同様の体制を構築可能
も挙げられます。
Hakuhodo DY ONE社内では情シスヘルプデスク以外にも依頼受付対応をしている部署が数多くあるため、構築支援もしています。
たとえばアイレップ時代は以下の図のような体制で運用しており、コミュニケーションはSlackでできるものの、以下の困りごとを抱えていました。
- 依頼チケット管理は起票しか行えず、ステータス変更はチケット管理ツール上での操作が必要
- チケットに「どうやってその依頼を解決したのか」が記載されない
- レポート作成において、CSVをDLしての作業が必要
また、デジタル・アドバタイジング・コンソーシアム（DAC）のヘルプデスクでは以下の課題を抱えていました。
- 情報格納場所や依頼ルートが散在している
- チケット管理ツールのコストがかさんでいる
もちろん、以前使っていたツールで実現できていたことが、すべて今の体制で100％再現できているわけではありません。
ツール移行や体制変更にあたり、
- 何の要素を最も優先させるか
- どういった要素であれば、移行後にできなくなっても許容できるか
等を検討した上で移行をしています。
将来的には
SlackWFで届いた依頼を一旦AIが受け取り、解決事例と合致・類似していれば方法を自動的に提示できるようにしたいな。と考えています。
ただ、ヘルプデスクへの依頼範囲が非常に多岐にわたるため、類似判定等が難しく、まだ満足のいくレベルには至っていません。
来年もアドベントカレンダーイベントがあれば、更に進化した内容をお届けできると良いな、と思います。
ここまでお読みいただき、ありがとうございました。