株式会社ネクスタの奥上です。
はじめに：システムヘルプとは何か
「今まで期待通りに動作していたシステムが急に思うように動かない、午後からユーザへ訪問しないといけないのに…そんな時、あなたはどうしますか？」
弊社ではシステムヘルプという問い合わせチャンネルがあり、
毎日何十件も色々な「困った」についてやり取りをしています。
システムヘルプの役割
運用開始当初
- 不具合対応：原因調査と改修仕様の策定
- 操作方法・仕様に関する質問対応
- 運用相談への回答
事業拡大時に増えた役割
- 設定不備の調査・回答
＜お困り例＞ユーザに導入支援中に、期待通りに動作しないが何が原因か分からない - データ調整など技術作業の依頼対応
＜お困り例＞大量に意図しない値でデータを登録してしまって、今さら1つずつ手修正できない - ログの解析・データの履歴調査
＜お困り例＞いつの間にかデータが変わっていて、誰がいつ変更したか知りたい - カスタマーサポートでは解決しきれない問題の調査・回答
＜お困り例＞普通に操作しただけでは再現しない
なぜこの業務が重要か
- 顧客満足度向上への貢献
- 開発チームとの連携のハブとしての役割
- プロダクトに関するナレッジメントの蓄積
- プロダクトの使いにくい・分かりにくいの解消
システムヘルプの誕生と初期の課題
業務立ち上げの背景
Slackで質問・回答を以前から行っていましたが、事業の拡大に伴い人員も増え、
やり取りする機会が増えたことで、専用のチャンネルを1つ設けることにしました。
他には、個人間のやり取りに終始しており、有用な情報が会社全体で共有できていませんでした。
また、Biz側が不具合と認識してるものでも、実は利用方法が誤ってるだけで、
開発側に不要な依頼が多発したことがありました。
初期の体制
開発チームが3チームあり、チームリーダが企画＆設計担当を兼ねて対応していました。
プロダクト立ち上げ時から参画してるメンバーで、一番仕様に詳しいためアサインしてました。
直面した課題
| No | 課題 |
|---|---|
| 1 | プロダクトに関する使い方のコツがSlackにしか残ってなく、同じことで困っても探し出せない |
| 2 | 問い合わせがどんどん増える中、どういう問い合わせが多いのか分析できておらず、課題が可視化できていなかった |
| 3 | 開発チームへの負荷増加 |
| 4 | 作業依頼の対応内容の属人化 |
| 5 | 不具合の認識の齟齬による開発への負荷 |
| 6 | ヘルプが減らない |
課題解決のための施策と効果
| No | 施策 | 効果 |
|---|---|---|
| 1 | トラブルシューティングを用意 | その後、Kブックと呼んでるプロダクトのドキュメントに統合し業務の中核に |
| 2 | SlackからリアクションすることでNotionに連携しデータを集めて、チャートで分析できるように | 数値で打ち手を検討可能に |
| 3 | 専門チームの立ち上げ | 開発チームは設計・開発に専念（200h→20h） |
| 4 | Notionにナレッジメントとして蓄積し共有 | 技術力のあるメンバーであれば、誰でも対応できるように |
| 5 | システムヘルプで一次切り分け | 開発作業の必要がない開発依頼の削減 |
| 6 | 今後同じ問い合わせが発生しないように、プロダクトの機能改修・ツールの開発 | 継続中 |
チャート分析の例（件数や割合は実際のものとは異なります）
システムヘルプの現在
現在の業務体制と効果
CTO室というグループの中のシステムヘルプチームとして2名＋一部開発チームの力を借りて対応しています。
以前と比べて、開発チームは開発作業に力を注げるようになっています。
月300件近くのヘルプを対応していて、
同様の問い合わせ削減のための機能開発は月20～30件を開発チームと連携、
プロダクトドキュメント（Kブック）の記事追加・改修依頼を月100件出して、ドキュメントを更新してくれるコンテンツチームと連携しています。
システムヘルプの「今」の価値
単なる「問い合わせ対応」に留まらない、プロダクト改善や顧客との関係構築における戦略的な役割があります。
問い合わせには、プロダクトの弱点を知るための貴重な情報源として捉えています。
これを活かすことで、プロダクトの成長に繋がるはずです。
（企業によって、いろいろなポジションの方が業務にあたられてると思いますが、CEO直々に対応されてるという記事も拝読したことがあります。その他、知見の深いプロダクトマネージャーやITサポート/ヘルプデスク/情シスの方々が対応されてるでしょうか。）
例えば、データ取り込み処理で非同期に対応したとき、処理実行時に「受け付けました」というメッセージのみを表示していましたが、それだと取り込み結果がどうなったか分からないという問い合わせが多発しました。
モニタ画面で確認すればよいだけだったため、その画面へ誘導するメッセージに変更しました。
ちょっとしたことですが、少しのことで「困った」が解消され、問い合わせを減らすことができました。
業務で必要とされる能力
- プロダクトに関する深いドメイン知識
知識があることで調査なしですぐに回答することができます - 開発能力
デバッグすることですばやく問題の原因特定が可能になります - 設計能力
仕様の不備を問い合わせ起点ですぐに改修依頼することが可能になります - データベース
データの不備をすぐに修正したり、データ設定によって問題の解消をすぐに対応できます - クラウド（AWS）
インフラ/サーバ上の障害から復旧することができます - プリンタ、ハンディーターミナルなど関連機材の知識
印刷できないなどの機材のトラブルを解消できます - セキュリティ
アプリがセキュリティソフトに遮断されたときなどの対応の案内ができます - ネットワーク
サーバとの通信内容から問題の解析が可能になります - AI
AIを利用して膨大な情報から必要な情報を得てすばやく回答できます - PCに関する一般知識
エクセルやブラウザでの不正挙動について対策を回答できます
今後の展望
- AI/自動化の活用
→問い合わせに対してAIで回答できる仕組みはありますが、まだまだ人の手を介在しないと解決までサポートできていません。将来的には少しでも多くAIで回答できる仕組みを用意したいと考えています。 - プロアクティブなサポートへの移行
- ユーザー体験（UX）向上へのさらなる貢献
→事前に分かりにくい/使いにくいを能動的に改修したり、不具合にいち早く気づき改修できるようにしたいと考えています。 - チームの成長とキャリアパス
→知見のあるメンバーが属人的に対応してきましたが、今後は新メンバーでもすばやく立ち上がり、再現性のあるチーム作りをしていきたいと考えています。また、プロダクト理解×開発力×設計力×プロダクト課題を知ったメンバーは他のどの業務へも応用が利くはずです。
おわりに
みなさまの社内では、このシステムヘルプ業務についてどのように向き合っていますか？
弊社ではプロダクトを陰ながら下支えしつつ、より前身させるための役割を担ってます。
もしよかったらコメントで教えていただけると嬉しいです。
Discussion