TypeError:

エスカレーション対応のチケット駆動開発 中編

#ssmjp Advent Calendar 2020 17日目の記事です。

お話する時間は無かったので、 「チケット駆動開発がまわりはじめるまでの取り組み」では、 「誰が」「何をするか」「何をしているか」「どこまで出来ているか」が 少しずつチケットとして見えるようになってきたとだけ書きました。

「 エスカレーション対応のチケット駆動開発 前編 」では、 「チームにくるエスカレーション」が、どのようなモチベーションではじまり、 どのような状況を観測し、どのような戦略を考えたかについて書きました。

中編では、具体的にどのようなルールを用意し、 どのくらいのペースで巻き込むメンバーを増やしていったかについて書きました。

チケット駆動開発がまわりはじめるまでの取り組み

https://speakerdeck.com/zinrai/okr-tidd-case

小さくはじめる

「 エスカレーション対応のチケット駆動開発 前編 」にて、 声を上げてくれた2名のチームメンバーを巻き込んで、 問い合せ、アラート対応の「チケット駆動開発」がはじまりました。

ヒアリング

「チケット駆動開発」のための運用ルールを整備するためにはするためには、 自分が観測した状況よりも、より詳細を知っておく必要があります。

巻き込んだメンバーに対して、自分達の把握している範囲でかまわないので、 問い合せやアラートを受けている窓口、 対応の流れ、対応完了を相手にどのように通知しているのか、 参加するメンバーの思いなどをヒアリングしました。

参加するメンバーの思いとして、下記のようなことが上がってきて、 自分が観測し、考えていたことと同じようなことを参加者も考えていることがわかりました。

  • 誰が対応しているのかがわかりにくいことはよくある
  • 誰か対応していると思っていたら、誰も対応していなかったことがよくある
  • 自分が着手していたら、他の人も着手していたことがある
  • 受けた結果、他の人が対応する必要があったりする
  • 「誰が」対応しているのかという状況が Redmine で確認できるという状態が第一歩だと思っている
  • チームでの経験は少ないため、自分一人で受けたものを解決まで持ってけることは少ない
  • 対応したものに対して、ここまではやった、この先について助言または対応をお願いしますということを見える形にできるとよいなと思っている
  • エスカレーションの回答には含まれない、チーム内での対応経緯のようなものを蓄積し、検索できるようにすることで、自分の対応できることを増やしていきたい

運用ルールの作成

ヒアリングした内容から運用ルールを作成していきます。

対応宣言

対応が被ってしまわないように、 今から自分が対応するということを相手に伝える必要があると考え、 それぞれの窓口に対しての宣言方法を決めました。

  • メーリングリスト
    • チームで利用している Slack チャンネルにメールの件名と対応を宣言する旨をコメントする
  • Slack チャンネル
    • 該当のコメントに返信またはリアクションする
  • 依頼システム
    • 該当の依頼にコメントする

チケット作成

問い合せやアラートが来たときに、 チケット化するための入力項目が多いと、 面倒臭がられてチケット化されない可能性があります。 対応が発生したときに、 ほとんど考えることなくチケット化できるようにしたいと考え、 下記だけをチケット化するために埋める必須の項目としました。

  • 題名
    • 問題点を題名として短かく書く
    • 題名を付けるのに3分悩んだ場合は、エスカレーションの件名を利用する
  • 説明
    • 「起点」「対応」「回答」をテンプレートとして内容を埋める
    • チケットを作るときは起点となった問い合せ、アラートの内容を「起点」に書き出すだけでよい
    • 「対応」「回答」はチケットをクローズするときにまとめればよい
  • 担当者

対応開始の宣言

問い合せてきた相手に対して、これから対応をここで進めます、 チームメンバーに、これからこのアラートに対して、 このチケットで進めていきますということを見えるようにするため、 各窓口に対して、チケットのリンクを返信することを決めました。

認識合わせ

運用ルール、目標などを参加メンバーと認識合わせしました。

運用ルールについての反応は、 「読んだ感じ違和感はなく、実際に運用してみて出てきた違和感をフィードバックします」でした。

  • 「対応が個人に閉じている」を「チケット駆動開発」によって、「誰が何に対応しているのか見えるようにし、ナレッジの蓄積していく」を目標とする
  • 週次でフィードバックを受ける機会を用意し、運用ルールは「チケット駆動開発」するメンバーに合うように調整する
  • 自分が取った問い合せ、アラート対応をチケット化する
  • 自分が取ったが、対応できそうにない場合に供えて、対応を引き継ぐであろうチームメンバーには、チケットの担当者になる可能性がありますと共有しておく

チームメンバーへの共有

「これから、問い合せやアラート対応をチケット駆動開発していきます。 参加メンバーのみがチケット化することになりますが、 参加メンバーが対応できなかった場合は、 チケットの担当者となる場合があることを覚えておいてください。」 とチームミーティングにて、チームメンバーに共有しました。

週次のミーティング

以下をキーワードに運用ルールをまわしてみた所感をフィードバックしてもらっていた。

  • よかったこと
  • できていないと感じること
  • 自身の行動にていまいちだと感じていること
  • 困っていること

参加メンバーを追加する

初期メンバーとの週次のミーティングを5回行ったところで、 いまのメンバーでは、運用がまわりはじめているという認識が合ったので、 初期メンバーと対応している内容が被っているメンバーを新たに2名追加することに決めました。

5回目の週次ミーティングを行った、次の週の週次ミーティングに新たなメンバーを追加し、 初期メンバーとどのような会議体を実施しているのか、 この「チケット駆動開発」にて目標としていること、運用ルールについてのインプットを行い、 「以降、自分が取る問い合せ、アラートは運用ルールに従いチケット化し、 週次のミーティングにてフィードバックをお願いします」という認識を合わせました。

チームメンバーを全員巻き込む

週次のミーティングは全部で9回実施し、 ここまでに3ヶ月の期間を要しました。 追加した2名のメンバーを混じえてのミーティングは4回実施し、 運用ルールが大きく変わるようなことはなく、思ったよりもうまくまわっていました。

9回目の週次ミーティングにて、 参加しているメンバーにて運用がまわりはじめているという認識が合ったので、 問い合せ、アラートに対応しているメンバー全員を巻き込むことを決めました。