テクサポ改善録

これはLAPRAS Advent Calendar 2023の記事です。

あらまし

弊社におけるテクニカルサポート（以下「テクサポ」といいます）は、ソフトウェアエンジニア（SWE）が週単位で持ち回りながら担当しています。この際、多くの方から「手が回らない」という声が挙がっており、人手不足なのか、仕組み自体に問題があるのかの判断が難しい状況にありました。私はこの問題に対し、約1年間にわたって計測と改善の取り組みを続けてきました。

この記事では、約1年間私がどういう意図で何をしたのかを簡単にまとめました。

当時の状況

計測及び改善を行う前の状況においては、いくつかの課題が存在していました。

対応の漏れが目立っていました。
担当者の交代により、数週間にわたって対応が続くことがありました。
担当者にどの程度の負担がかかっているのかが明確ではありませんでした。
長年の経験を持つ技術者への負担が顕著に大きかったこと。
担当者の中には、「テクサポ担当週は望ましくない」という認識を持っている方もいました。

計測目的の変化

当初の目的は「人員が不足しているか否かを判断するための十分なデータを収集すること。」でした。

現在はこの目的が達成されたことにより目的を変更し、計測と改善の活動を継続しています。

現在の主な目的

テクニカルサポートの業務負担を軽減する。
将来的にテクニカルサポートがほぼ不要となるような基盤を築くこと。

対応すべきものを“見逃さない”、“零さない“

これまで、Slackのピン留め機能を用いて対応中の要件を管理していましたが、この方法は一覧性に欠け、対応漏れや引き継ぎ漏れの原因となっていることが明らかでした。この時すでに各対応に対してはGitHubのイシューを作成し、それに基づいて対応している状況だったため、この問題を解決するために、ピン留めを行わないように方針を変更しつつGitHub Projectを要件のマスターとして使用してその管理を行うように周知しました。

計測：support-issueのラベルから対応件数と時間を調べる

Data AggregatorにGitHubのissueを取り込むことで、「対応開始日時」、「対応終了日時」、「対応者」を計測できるようになりました。また、ラベルを付けることで、どのような対応にどれくらいの時間がかかっているかを計測できるようにしました。ラベルは、「プロダクト」、「発生元」、「対応種別」の3つのカテゴリーで分類するルールを定めています。

過去のsupport-issueを整理する

計測開始当初、過去に対応したissueが大量に残っており今後の計測の妨げとなっていました。そのため以下の対応を行いました。

対応が完了しているものをcloseしました。
テクニカルサポートが原因のバグ修正イシューについて再検討を行い、「対応済み」、「対応不要」、「未対応」の3つに分類しました。ここで「未対応」以外はクローズしました。
- 対応済み：過去に対応を行って解決しているケース。
- 対応不要：対応は行っていないが、改修等により対応が不要と判断されたケース。
- 未対応：対応が行われておらず、バグが改善されていないケース。
「未対応」のイシューについて、対応が必要かどうかを検討しました。
- 現在のプロダクトのフェーズと照らし合わせ、「根治が必要かどうか」という観点から必要なものだけを残し、再調査を行いました。
- 根治が必要ないと判断された場合は、エラーハンドリングの追加など新たなイシューを作成しました。

可視化：DashBoardを用いて計測した件数や時間を可視化

対応時間が明確にグラフに表されることで、その週にどのような対応が多かったかが分かるようにしました。
例えば、問い合わせ件数が3件程度であるにも関わらず、issue1件あたりのcloseまでの平均時間が長い場合、調査に時間がかかったか、問い合わせの返答待ちであったかなどを推測できます（これは週次の共有時に報告されています）。

また、平均対応時間をグラフ化することで対応時間の短縮へのモチベーションが高まり、改善が実現した際には、その喜びも大きくなります。全体への共有の際文字通り目に見えて分かりやすくなるのも良い点でした。

グラフは週平均および月平均で計測されており、土日の時間はカウントされていません。

持ち回り担当を通知

これまで、担当者はスプレッドシートに手作業で入力するという運用を行っていましたが、以下のような問題が生じていました。

次週の担当者が誰であるかが確認しにくく、忘れがちでした。
気付くと翌日からの担当リストが空となっており、誰も続けて記入していない状況がありました。

翌週の担当者を事前に通知することにより、メインプロジェクトが忙しい時期でも、他の人にテクニカルサポートの担当期間の交代を依頼しやすくなりました。持ち回り担当はスプレッドシートで自動採番するように設定し、必要に応じて手動での入れ替えも可能となっています。

アンケートの実施

いつもテクサポを利用している方向けに、満足度アンケートを行いました。アンケート項目は概ね以下の通りシンプルに設定しました。

満足していますか？（5段階）
不満があると回答した方はその点について（自由記入）
ご意見・ご感想（自由記入）です。

このアンケートは、細かいニーズを確認することよりも、「現在のテクニカルサポートの運営が利用者の方々にどのように受け取られているか」という点を確認するために行いました。この目的に鑑みて、上記の項目で十分と判断しました。

これまでに2回の実施を行い、結果は以下の通りです。

定型の対応に対する手順書の改善

これまではGitHubにMarkdown形式で手順書を書いていましたが、検索性が悪いと感じていたため、手順書の公開方法を見直すことにしました。

新しい方法では、Hugoという静的サイトジェネレーターを使って、ブログのように閲覧できるようにしました。さらに、検索機能を良くするためにAlgoliaを導入し、日本語検索もできるようになりました。加えて、AWSを活用して社内からだけアクセスできるようにIP制限を設定しました（この部分はSREの方に大変お世話になりました🐧）。 Algoliaによって、どんなワードが検索されたか、どの記事に多くアクセスされたかなどが分かるため、担当者がどんな時に手順書を見ているかを知る手がかりになっています。

手順書の定期更新

担当期間が終わる頃に、手順書で不足を感じたところや新たに追加してほしい手順がないかをヒアリングしissue化しました。この方法で、少なくとも週に1件は手順書を改善または追加することで、「いつの間にか手順書が古い」という問題を解決してきました。

便利クエリの作成と整理

弊社ではRedashを活用しており、テクニカルサポートに限らず多くの社員が便利なクエリを作成しています。その中からテクサポの業務にも役立ちそうなクエリを選び、1ページにまとめてすぐに参照できるようにしました。また、新しく必要と感じるクエリがあれば、随時作成してリストに追加しています。

各種ワークフローの作成

基本的に定型の対応を行う問い合わせが多いのですが、依頼の形式が依頼主によって異なっていたため手順書を検索する時に少々手間がありました。そのため、ワークフローを新たに作成し、依頼主にはそのフローに則って依頼をしてもらうようお願いしました。これにより、このワークフローにはこの手順書といった認識を持ちやすくなりました。

週次引き継ぎの際のワークフローを設定

（これは初めて日が浅いのでまだまだ改善予定です）

今後、テクサポが私の手から離れるために担当者のみで自走する仕組みが必要だと考え、引き継ぎ時に何を伝えなければいけないのか、次の担当は何をしなければいけないのか、共有を漏らさない様にするためワークフローを設定しました。

ここまで書いて感想

これまでの対応で、コードを書く機会は少なかったかもしれませんが、私にとってはとても楽しい仕事でした。最初は状況が良くなかったので、目に見えて改善していく様子は本当に気持ちが良いものです。

たった1年ほどでこれだけの変更を行いながらも、文句一つ言わずに協力してくれたテクニカルサポートのSWEの皆さんには本当に感謝しています。時には厳しいことを言ったり、私自身が体調を崩してしまったりと、皆さんには多くのご不便をおかけしたと思います。それでも、文句を言わずに協力してくださったおかげで、ここまで改善できたことに心から感謝しています。今後も色々とお願いすることがあるかと思いますが、今後も盛りだくさんの【おねがい】をしていく予定なのでどうぞ腐らずお付き合いください。