■はてなブックマーク - 運用の問い合わせチケットを10分の1に削減した話

http://qiita.com/secret_hamuhamu/items/718924867ff3ed11d6b9

の「起票(運用)」を批判するブコメ

http://b.hatena.ne.jp/entry/qiita.com/secret_hamuhamu/items/718924867ff3ed11d6b9

を読んで，少し暗澹たる気分になったので書く。

元記事の「起票(運用)」に書かれているのは，人に仕事を依頼する上では割と当たり前のことだと思う。

例えば，「背景」がなければ，なぜその問い合わせが発生したのか／なぜ回答しなければいけないのかがわからない。自分は特に「理由」厨なので，「なぜ」がわからないのは論外だと思っている。自分でチケット切って自分で作業する時ですら「背景」は書く。そうしないと，チームの他の人がチケットを見た時「こいつ何でこんなことやってるんだ（この忙しい時に）」と思われる可能性だってある。背景を書くことで，自分の中の優先順位を確認することもできる。

「リスク」は，なぜこのチケットを処理しなければいけないか／どれくらい優先してやるべきかという価値を共有するための一つの手段だろう。背景だけだと認識ズレがおきる可能性があるので，それを避けるためのものだ。認識合わせためのコミュニケーションのきっかけくらいの位置づけだと思うので，その見積もりが間違ってても（非常識なものでない限り）責められることはないだろう。

次の「事象の確認＆再現手順」は，障害対応やったことのある人ならほぼ必須であることはわかるだろうと思うので以下略。

「すぐに対応可能できるか」は，個人的には「リスク」とまとめてもいい気がするが，このチームでは優先順位と緊急度を分けて考えているのだろうという理解はできる。

「過去の同様チケットへの参照」は，optionalだが，書いておけば双方にメリットがあるのだから，思い当たる節があれば書けばいい。Optionalなのだから書かなくても責められない。

改めて見てみても，特に不当な要求はないと思う。

「背景」の重要性

自分が特に気になったのは「背景」の軽視だ。

「背景」を書く＝コンテキストの共有 である。チームで仕事を進めるにあたって，コンテキストの共有が極めて重要であることは，それができていないお偉いさんに仕事をぶち壊された経験がある人なら，よくわかるだろう。

先にも書いた通り，自分は理由厨なので，「背景」のないチケットなどあり得ないと考えている。むしろそんなチケット今までどうやって処理してたのだろうと疑問に思うくらいだ。

例えば，以下のようなタイトルのチケットを考えてみる。

◯○機能で△△ができるかどうかの調査

「背景」の記述がなければ，このチケットがどれくらい重要なのかわからない。

「背景」が書いてあれば，例えば，

【背景】

顧客の□□社から，標題の件で問い合わせがありました。社内体制の変更により，△△が必要になりそうなので，可否を至急教えて欲しいとのことです。

というのと，

【背景】

マニュアルの検査をしていて，標記の件が気になりました。

というのとでは，チケットの価値が全く違うことがわかる。

考察

とはいえ，暗澹となった理由は別にある。

「お客様神様主義」の変形？

1つは，これが「お客様神様主義」の変形ではないかと感じたからだ。

いわゆるIT業界では，よく「要件定義のできないクライアント」が批判される。そして，そんな顧客の曖昧な要求に対してナァナァで対応する営業や管理職が批判される。

運用から開発への問い合わせチケットも，仕事の依頼という点では同じである。

顧客は仕事の依頼と引き換えに金を払っているし，ITに関しては（他社に依頼するくらいだから）ある程度素人だが，運用から開発であれば，たいていの場合は同一社内で金が動くわけでもないし，しかも双方プロなんだから，むしろもっと厳しくてもいいくらいだと思う。

なのに http://qiita.com/secret_hamuhamu/items/718924867ff3ed11d6b9 程度のルールを作っただけで批判するのは，要件定義のできないクライアントを擁護するのと同じではないかと思う。

手段の目的化？

ブコメに多い（しかもスターを集めている）のが，この種のルールによって「チケットの数が減る」「Redmineが使われなくなる」という声だ。

だが考えてみてほしい。Redmineを使うことが目的なのではない。Redmineを使って仕事を効率的に進めるのが目的なのだ。仕事が効率化するなら，チケットが減ろうがRedmineの使用頻度が落ちようが本質的には問題ではない。

（もちろん，Redmineが全く使われなくなってしまうのであれば本末転倒だが。）

そもそも実際にチケットが減ったりRedmineの使用頻度が落ちたりしたのかは元記事には書いていないので，事実はわからない。もしかしたら，この施策によって，運用側でもチケット化するメリットがはっきりして，今までチケットを使ってなかった人（実際元記事には「Redmine使いにくい」という声が書かれていた）が使うようになった可能性だってある。

何か「Redmineでチケット管理」というとそれ自体を目的にしたようなコメントが（この記事以外でも）しばしば見られるような印象があるので気になった。

まとめ

「問い合わせの削減」というと，サポートやったことがある人ならわかると思うが，ドキュメント，特にFAQの充実が定番である。

今回の記事のチームでも，当然そういう努力は別途行うべきだろう。

（その辺を全く書いていなかったのが，ブコメでの批判につながった可能性はありそう。）

しかし，チケットを使って問い合わせを行うのは仕事の効率化が目的であり，そのためには（依頼する側もプロなんだから）ある程度仕事の依頼＝チケットの起票をルールに則ってやることはごく当たり前のことだと思う。

そういう当たり前のことが批判されている背後に，もし上にあげたような理由があるとしたら，と思って少し暗澹となった。

Permalink | 記事への反応(0) | 02:16

ツイートシェア