課題追跡システムの勘所(1)

仕事の現場に、新規で課題追跡システム(ITS)を導入する場合、いくつかの障壁があります。これらは主に、システムを使う人の知識と意識の問題ですが、それを列挙して対策をまとめてみます。

ログインしてくれない

まず超根本。「導入しました」「あっそ」でスルーのパターン。課題を投げても気づいてもらえない。ありがちです。

これはまずトップダウンで「見ろゴルァ」と指令を出す必要があります。これが業務の方針だよ、と。その決定が前提。しかしそれでも習慣にならないウチはみんなITSの確認をしません。ならばシステム的な解決を目論む。

「一定期間ログインしないとアラートのメールを飛ばす」という策に出ます。結構強引な策ですが。ひとまずこれで、全員の意識をITSに向けることができるんじゃないかな。(という試みを現在実行中w)

JIRAでは、Jellyスクリプト*1を使って任意のロジックを実行することができます。バッチ処理なんかに向いてますね。特定のレポートを出力したり、今回のようにメールを飛ばしたり。Javaのコードでやりたいことを書いてみてから、それをXMLに変換*2して、JIRA管理画面のformからsubmitすれば、そのロジックを実行できます。以下のようなイメージ。

<core:new className="java.util.Date" var="now"/>
<core:invoke on="${now}" method="toString" var="str"/>
Date now = new Date();
String str = now.toString();

また、単発実行ではなく、一定時間おきにJellyスクリプトを実行する設定もできます。JIRAの「サービス」という機能ですね。これを使えば、上記のアラートメールが実現できます。

このJellyで作った「ログインアラート」スクリプトは次回紹介。初めて書いたので稚拙なスクリプトだと思いますがw

チケットを作ってくれないシリーズ

上記で、何とかログインしてくれるようになったとします。しかし次の障壁は「なぜかみんなチケットを作ってくれない」というもの。これにはどんな原因があるのでしょうか?

操作が恐い

新しいものを触る時って、何がどうなるのか分からなくて、もしかして壊してしまわないだろうか? メンバーに迷惑をかけたりしないだろうか? という恐怖感を覚えるもんです。恐る恐る触ってみればじきに慣れるんだが、触らぬ神に祟りなしと考える人も多い。

ということで、「サンドボックスプロジェクト」を一つ作ってしまおう。この中では、テストでチケットを作ったり、勝手に他人にアサインしてみたり、と好きな操作をやってもOKです、という空間を作る。そして「OKです」じゃなくて「是非色々やってみてください」と促す。

何をやっても壊さない、仮に壊してしまっても業務に支障はない、他人に迷惑を掛けることもない、と保証する領域を作ってやれば、それなりに安心して操作を体験できるハズです。

チケットが自分に与える影響を誤解

「チケットは、作成したらその内容を必ず遂行するものである」「チケット作成=完遂しますという表明」と誤解しているケース。このような意識を持っていると、おいそれとチケットを作れない。

チケットを作るというのは、そんな大それたことではない。ITSに登録する課題は、必ず時も「確実に実行しなければならないもの」ではない。思いつきでチケットを作って良い。実行しないと決まれば、そのままクローズすればいいだけ。

ということを、しっかりユーザに伝えるべきだ。下手すると、そもそも「ITSの導入を試みる立場の人」の認識が間違っていることもある。敢えて「間違っている」と言ってしまったが、運用方法はそれぞれ、というコトもあるだろう。しかし、このような意識では、なかなかITSを上手く回していくのは難しいんじゃないかな、と思っている。

JIRAでは、チケットを作成したけれど、処理を開始せずにそのままチケットをクローズする、というワークフローがデフォルトで用意されていることも考えると、やはり「チケットの内容は必ずしも実施されない」と考えた方がよさそうだ。

また、処理せずにクローズされたことによって「あぁ、これはやらないことになったんだな」という周知にもなる。コメント機能で、このチケットが未処理でクローズに至った経緯をメモしておければ、最高の運用だと思う。

というわけで、本当に気軽に、どんどんチケットを作って、タスク管理が出来ればベストだよ、ということを周知する。

チケットが他メンバーに与える影響を軽視

チケットを作らずに仕事をしてしまうケースです。これが難しい。どーーしてもやってしまう。俺もw

チケットを作って、状況や進捗をメンバーに周知できる。これがITS運用の最大のメリット。ただ、どうしても客観的に見る事ができなくて、他人からの周知は要求するが、自分からの周知を怠ってしまいがち。

これも、もうトップダウンで「進捗どうなってる? で、そのチケットはどれ? 今話した進捗、チケットにコメントいれといて」という指示を、慣れるまで出し続ける。というゴリゴリな方法しか思いつかないw

慣れてさえしまえば、報告代わりにチケットを動かすようになってくる。チケットにさえ書いておけば「報告しろ」と言われなくなってくるからね。そして「チケット」が「自分の作業実績」だと感じられるようになってくればしめたもの。チケットを作らずに仕事をすると、仕事はしたのに周囲に認識してもらえない。「俺はこんだけの仕事したぞ!」という主張のためにチケットを動かす。

また、管理者視点も改革の余地がある。誰かに仕事を振る際に、ただ「これやって」と指示するのではなく、必ずチケットを介して仕事を振るようにすること。可能であるならば「チケットを作らなければ、正式な業務命令と見なさない」というルールを作ってしまうw 「あの件、どうなってる? 頼んだよね?」「え、チケットどれですか? やってませんよ?」「そうか…」がまかり通っちゃえば良いと思うw まぁ色々難しいだろうけど。意気込みとしてはこのくらい欲しいものである。

チケットを握り込んでしまう

「担当者とは一体なんなのか?」の認識が甘いケース。

各チケットの「担当者」は、その件に関してボールを握っている人、をあらわす。仕事のボールが飛んできたら、握り込まずにすぐに打ち返せ、という言葉もあります。

http://www.omotesando-ad.jp/archives/50807078.html

これを意識して、自分がなるべく「担当者」である状態を短くするよう心がける。つまり、誰かが振ってきたタスクを、完了したら、すぐにコメントや成果物を送ると共に、「振ってきた人」に再アサインするのです。仕事をこなして終了ではなく、チケットのアサインも返すのがポイント。

例えば、AさんがBさんに「書類を提出せよ」というタスクを作った場合、書類を提出して終わりではなく、その後にBさんがそのチケットの担当者を「Aさん」に変更して終了。アサインを受けたAさんは、その書類を確認して問題がなければクローズ、不備があればコメントと共に、Bさんに再アサインすることになるわけです。

誰もが「責任」は負いたくありませんw チケットの担当者であるということは、「本件の処理責任は、現在私にあります」という意味であることを、深く認識すべきです。担当者である限り「本件、どーなってんのよ!?」と突っ込まれる可能性が常にある、と。

逆に管理者の立場からは「とある課題について、話を聞きたい」と思ったら、そのチケットを探し出し、その「担当者」に聞くべきです。

ちなみに、Jiemamyプロジェクトにおいては「チケットの担当者がいない」ことを許す設定になっています。OSSは仕事ではないので、義務はない。そこまでガチに管理する必要もないし、筋合いもない。

しかし、仕事に使っているJIRAではこれを許さない、つまり「チケットは、クローズされない限り、必ず誰かが担当者になっている」という設定にしてあります。スパルタンですねw これで、みんなに「チケットの担当者でいたくない」という意識があれば、ボールがぽんぽんやり取りされ、仕事の回りも早くなるというもの。素晴らしい効果です。


というわけで、ITS運用の勘所をまとめてみた。また何か思いついたら書きますね。

*1:http://commons.apache.org/jelly/

*2:といっても、自分で翻訳するんですがw