Edited at

運用の問い合わせチケットを10分の1に削減した話

More than 1 year has passed since last update.

会社で働いていると、運用チームからの問い合わせがあると思います。

問い合わせというものは、割り込みに繋がり生産性を下げるのでなるべく減らしていきたいものです。

Redmineで管理されているオープンなチケットを10分の1に削減した話をまとめます。

常時、約50枚ほどオープンなチケットを5枚ほどに減らしました。

問い合わせが多くて辛みを味わっている方の参考になれば。


概要


  • Web自社サービス

  • タスク管理ツール Redmine

  • 毎日、5枚ほどチケットが増える

  • 運用と開発がそれぞれ20人ほど

こんな環境です。


改善のきっかけ

うちのチームは、当番制で「問い合わせの窓口」(以下、窓口)となる人を作ります。

窓口の人がチケットを解決したり、有識者にチケットを委譲したりします。

その当番が、初めて私にやってきました。

当番になってわかったのが、起票されたまま放置されていたり、数ヶ月もチケットでやり取りしていたり何を問い合わせているのか全くわからないなどの混沌状態でした。

この状態は、開発の生産性を著しく下げ、運用チームへ価値を提供できていませんでした。

開発も運用もオールハッピーになるべく、フローの見直しを行いました。


ヒアリング

まず、行ったのは現状の課題のすり合わせです。

開発と運用チームの関係者を集め、ミーティングを行いました。

するとこのような、課題が上がりました。


開発の課題


  • 「〇〇できません」という問い合わせが多いが、調査に必要な情報が足りない

  • どのように確認をとったのか確認手順と可能であればスクショを撮って貼り付けてほしい

  • お客さんからの問い合わせを、そのまま丸投げするのではなくちゃんと理解して問い合わせてほしい

  • お客さんからのバグの問い合わせであればバグが再現できるか検証を行ってほしい

  • 調査に必要なid, urlといった情報も記入してほしい

  • チケットにコメントを残しても見てもらえない

  • 対応が完了した後は、チケットをクローズにしてほしい

  • 温度感がわからない

  • デッドラインはいつ?

  • リスクが分からないので優先度をつけれない

  • 背景がわからないので、どのように対応すべきかわからない

  • 問い合わせの依頼が、Redmineだけでなく口頭やSlackで行われる


運用の課題


  • 進捗がわからないので、途中経過を書いて進行状態がわかるようにしてほしい

  • Redmine使いづらい

  • 共有アカウントを使用していてメール通知が溜まりまくり見逃してしまう

  • どのようなケースでチケットを起票するのかわからない

  • 問い合わせに対してすぐ対応できるのか, 時間がかかるのか分からない

  • 起票しても対応してもらえない

たった1時間のミーティングでしたが、いろいろ課題が上がりました。

お互いのことを理解し合えていませんでした。

認識のズレやツールの誤った使い方をしているということは、話し合ってみないと分かりません。

まず、お互いが抱えている暗黙知を形式知に変えていきましょう。

課題を見える化しないと改善できません。


ガイドラインを策定

次に行ったのがガイドラインの策定です。

全員が同じ方向を向いていないと改善していくことは出来ません。

そのために、ルールを作り文書化します。

「アジャイルソフトウェア開発宣言」みたいなもんです。(´・ω・`)

ガイドラインの一部を抜粋し紹介します。


運用問い合わせガイドライン

運用問い合わせを行なう場合に必ず守ってもらう指針を取りまとめる。

このガイドラインに則ってチケットを起票しない場合は原則、対応しません。


目的

ガイドラインを守ることで無駄なコミュニケーションコストを減らし、問い合わせスピード/質の向上、本来の業務に集中できる時間を増やすことを目的とする。


ステータスフロー

① 通常 新規(運用) → 進行中(エンジニア)→対応済み(エンジニア)→ 完了(運用)

② 問い合わせ取り消し 新規(運用) → 取消(運用/エンジニア)


起票(運用)

なぜ、この対応を行わなければならないのか 背景を必ず記入して下さい。

対応が遅れてしまうことによるリスクを必ず記入して下さい。例 n日までに対応しないと○○円ほどの損失, 信用問題に関わるなど

障害対応であれば、どのような確認手順を行ったのか明確に記入し可能であればスクショを撮って下さい。

お客様からの問い合わせの場合、確認可能であれば再現を行い同様の事象を確認して下さい。

idやurlが分かる場合、調査に必要なので必ず記入して下さい。

すぐに対応可能できるか知りたい場合、その旨を記入して下さい。

過去に類似問い合わせがあった場合、関連するチケットにひも付けて下さい。対応速度が上がるかもしれません。

起票時に明らかに情報が欠落していると判断した場合、対応しません。

加筆修正を促します。


チケット対応(エンジニア)

チケットに着手した段階でステータスを進行中に変更して下さい。

着手時に何かしらコメントをつけたり途中経過を書いていただけると運用の方が安心します。

対応したissueやPull Requestが存在すれば必ず相互リンクしましょう。

対応・調査した内容は必ず残しましょう。例えば、確認しましただけでは、正しく調査したのか評価できませんし今後、類似調査で参考にできず2度手間になってしまいます。確認したSQL文を残すだけでもいいです。

対応完了した段階でステータスを対応済みに変更して運用の方に連絡して下さい。


完了(運用)

解決したことを確認しステータスを完了に変更して下さい。


取消(運用/エンジニア)

問い合わせる必要がなくなった場合や対応不可と判断した場合にステータスを取消に変更して下さい。

取消の理由は必ず書くこと。


改善プロセス(全員)

このやり方で、ずっと続けるつもりはありません。

実際にこのフローで回してみて上手くいかなければ気軽に相談し、改善していきましょう。

なにかあれば、 @secret_hamuhamu まで。


本当は、もっと細かく起票時のルールや対応時のルールを記載しています。

現場のやり方に合わせて最適化していけばよいかと思います。


Redmineのチューニング

次に行ったのが、Redmineのチューニングです。


チューニング内容


  • 誤った使い方をできないように防止

  • 起票時にテンプレを読み込ませる

  • 運用上都合のいいステータスの追加

  • 問い合わせ時の必須入力項目の変更

  • etc...

これも現場に合わせて、最適化を行えばよいかと思います。

現場に合った設定をするだけで、無駄な作業を省くことが出来ます。

特にテンプレがないと、バラバラのフォーマットで起票されてしまい記入漏れが多発します。


啓蒙活動

さて、ルールを定めフローを整えました。

新しいフローを浸透させていかなければなりません。

しかし、人間はすぐに新しいことに対する変化へ対応できないですし、改善活動の関心が薄いとルールに従ってくれません。


変化への対応

Redmineのチケット警察の出番が必要です。

起票されたチケットを確認し、ガイドラインにそぐわない場合は加筆修正を促し続けます。

気分を害さないように言葉を選びアドバイスしてあげましょう。

いきなり、警察が厳しいルールで始めると物事が何も進まなくなるので、プロセスが浸透して来たところで徐々にルールを厳しくしていくといいと思います。

どうしても言うことを聞いてくれない人には、最終手段でチケットをクローズしてもいいかもしれません。

思っている以上に相手ダメージを与えてしまう可能性もあるので、アフターケアを怠らないように。


関心をもたせる

関心がないのは自分ごとと捉えてないからです。

ちゃんと利益があるということを教えなければなりません。

新しいフローにのっかることで対応スピードがアップ(リードタイムの短縮)するということを理解してもらいましょう。

対応スピードが上がっていることを体験してもらえれば話が早いです。

開発チームの人は頑張りましょう。




啓蒙活動は、1日2日で成し得ることは出来ません。

人数が多いと特にそうです。

根気よく急ぎすぎずに、浸透させていきましょう。


運用の問い合わせチケットが10分の1に削減された

改善活動前は常時、約50枚ほどオープンなチケットがありましたが今は5枚ほどに減りました。

それにより、ゆとりが生まれ運用チームが提起していた問題に取り組むことが出来たり技術的負債に取り組める余地が生まれました。

問題を見える化しチーム一丸となって取り組めば解決していけると思います。

今回は触れていませんが、問い合わせにどれ位時間を使っているか計測し見える化したほうがよいです。

現場の辛さは、周囲に理解されないものです。

計測した結果、かなりの時間を問い合わせに使っていると分かり運用の問い合わせを専門に行うチームが発足しました。


失敗したこと

私の失敗談ですが、啓蒙活動が上手く行きませんでした。

新しいフローを浸透させるのに時間がかかってしまいました。

原因は、新しいフローを展開をするときにSlackで共有してしまったことです。

ちゃんとミーティングを設定し、顔を合わせ何のために行なうのか?このフローにのっかることでどのようなメリットがあるのか?

しっかり目線を合わせて、展開をしなかったからです。

特に非エンジニアは、Redmineを使ったタスクマネジメントの考え方が染み付いていないので、目線合わせをしっかり行う必要があります。


やり残してること

まだやりきれていないことリスト


  • よくある問い合わせのQ&Aを作る

  • 起票時にテンプレ違反であれば、修正をbotが自動で促す


PS

思ったよりも、多くの方に見られてるみたいなので端折った話をその2にまとめました。

運用の問い合わせチケットを10分の1に削減した話 その2