TypeError:

ベンダーへの問い合せのチケット駆動開発

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

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

今日は、「ベンダーへの問い合せ」の「チケット駆動開発」が、 どのようなモチベーションで導入されたかについて書きました。

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

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

モチベーション

「 チケット駆動開発をチームメンバーに展開する 前編 」 「 チケット駆動開発をチームメンバーに展開する 後編 」 の仕組みでは、日々の開発業務を親子の構造でチケット管理していました。

利用または検証しているネットワーク機器、アプライアンス、サーバーに対しての ベンダーへの問い合わせも親子のチケット構造の中で管理されている状態になっていました。

チケットの中に自分以外が係ってくるとチケットをクローズする難易度は上がります。 自分がコントロールできる範囲をチケット化し進めていくことが、 チケットを起票してからクローズするまでのリズムを一定に保つコツになってきます。

ベンダーへの問い合せは、すぐに解決するものもあれば、 回答までに時間を要するものもあり、 チケットとして取り扱うとクローズのタイミングが読みにくいです。 自分でコントロールできないチケットを親子のチケット構造で管理してしまうと、 親チケットにぶら下がっている他の子チケットはクローズできているのに、 ベンダーへの問い合せチケットだけが残ってしまい、親チケットをクローズできない ということが容易に発生します。 いくつかの親チケットにおいて、そのような状況を観測しました。

チームミーティングでは、 「あのときのベンダーに問合せた内容の回答ってなんだったっけ。どこかに当時のやり取りのメール残ってるかな。」 というような会話をよく耳にし、問い合せの回答を後から辿れる仕組みは無さそうなことを感じ取りました。

こちらでコントロールしにくい性質を持ったチケットは、 親子チケットで進めていくものと時間の流れが異なります。 時間の流れが異なる「ベンダーの問い合せ」を親子のチケット構造から切り離したいと考えました。

親子のチケット管理の他に、 「 エスカレーション対応のチケット駆動開発 前編 」 でもベンダーへの問い合せが行われていました。 このままでは、ベンダーの問い合せを後追いしたくなったときに、 Redmine プロジェクトの中をあちこち探しまわらなければりません。 ベンダー問い合せを一箇所に集約し、管理できるような仕組みがあるとよいかもしれないなと考えました。

ヒアリング

私がそう考えただけで、実はそうではない可能性は大いにあります。 取り掛かる前に事実を観測する必要があります。 同じような考えや思いを持っている方がいるのかどうかを確かめることにしました。

チケット駆動開発をチームメンバーに展開する 前編 より、 G さんにヒアリングしました。 G さんが既存サービスの運用を一手に引き受けており、 チームミーティングの中での情報共有でもベンダーとのやり取りをしたり、 チームメンバーのベンダー問い合せを追い掛けているところをよく見掛けていたためです。

ヒアリングの結果、以下のような課題を持っていることがわかりました。

  • ベンダーが問い合せにチケットを起票するようなシステムを持ってれば、チームメンバーが起票した問い合せを後から追い掛けることができる
  • メールでのやり取りしかないベンダーも存在しており、その場合は、個人とベンダーでのやり取りになってしまっている
  • ベンダーからの回答が誰かのメールボックスに眠っている状態で、自分を含め他の人が状況を後追いできない
  • 後から回答を参照することが多い立ち位置なので、「こういう話を問い合わせていたりしますか」といったようなコミュニケーションを取り続けるの結構辛いなと感じている
  • チームメンバーが出しているベンダーの問い合せを一覧できて、その問い合せのステータスを確認できるような仕組みは欲しいなと思っている

ヒアリングで聞けた内容から、 確かにチームミーティングにて、 メンバーの「担当者にメールしています」に対して、 G さんが「私も状況を知りたいので CC に入れておいてもらえますか」 というような会話をよくしていたかもしれないことを思い出しました

チームメンバーへの共有

G さんへのヒアリングから、 自分が取り組みたいと考えていることに対して、 同じような課題を持ってそうであることがわかりました。

ベンダーの問い合せを別プロジェクトにて管理していく目的、 モチベーション、どうやっていくのかの叩き台を作成し、 チームミーティングにてチームメンバーに共有しました。

G さんだけでなく、他のメンバーもベンダーへの問い合せについて、 同じような課題を持っていることがわかり、「やってみましょう」ということに決まりました。

運用ルール

何も無いところから「ベンダーの問い合わせ」が発生することは無いと考えました。 問い合せがきたとき、アラート対応したとき、日々の開発などが起点となり、 「ベンダーへの問い合せ」は発生するはずです。

「ベンダー問い合せ」のチケットを作成した際は、起点となったチケットと関連付けます。

チケットの題名は、「対象機器 問い合わせのサマリ」の構成をとり、 何に対するどのような問い合わせであるかを題名からイメージしやすいようにします。

チケットの説明には、「起点、問い合わせ内容、 ベンダーの回答」を埋めます。 チケットを作成するときは「起点」のみを埋め、 ベンダーからの回答が来て、チケットをクローズするタイミングで、 「問い合せ」「ベンダーの回答」の内容を埋めるようにしました。 それまでは雑多にコメントに状況を追記してもらうようにしました。

進行中の状況や、経緯を追い掛けたい人は、コメントを後追いしてもらい、 ベンダーの回答のみを確認したい人は、説明を読めばよい構成をとりました。

ふりかえり

親子の構造でチケット管理している日々の開発業務、 問い合せ、アラート対応から「ベンダーへの問い合せ」の切り離しと集約ができました。

チケットは起票され、更新されていることを観測しているのですが、 効果をチームメンバーにヒアリングすることを忘れていたことに気が付きました。

以前は、「状況を確認したいので、 メールの CC に入れてもらえますか」 をチームミーティングにてよく観測していましたが、最近はあまり見掛けなくなりました。 状況を確認したいだけであればチケットを見るだけでよくなったことによる効果かもしれません。

「ベンダーへの問い合せは」チケットが起票されてからクローズされるまでに時間を要することが頻発します。 チケットが起票されてから、クローズまでに時間を要しているチケットは存在を忘れられることが多いです。 現状、チケットの更新が個人の意思に依存している状態となっており、放置を観測しています。 リマインドする仕組み、棚卸しの会議体などを運用するようなアクションが必要そうだと思いはじめました。 取り組みは作ってしまったら、うまいこと回り続けるというものではないので、 状況に合わせて調整していきたいと考えています。