課題追跡システムの勘所(1)
仕事の現場に、新規で課題追跡システム（ITS）を導入する場合、いくつかの障壁があります。これらは主に、システムを使う人の知識と意識の問題ですが、それを列挙して対策をまとめてみます。
ログインしてくれない
まず超根本。「導入しました」「あっそ」でスルーのパターン。課題を投げても気づいてもらえない。ありがちです。
これはまずトップダウンで「見ろゴルァ」と指令を出す必要があります。これが業務の方針だよ、と。その決定が前提。しかしそれでも習慣にならないウチはみんなITSの確認をしません。ならばシステム的な解決を目論む。
「一定期間ログインしないとアラートのメールを飛ばす」という策に出ます。結構強引な策ですが。ひとまずこれで、全員の意識をITSに向けることができるんじゃないかな。（という試みを現在実行中ｗ）
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の「サービス」という機能ですね。これを使えば、上記のアラートメールが実現できます。
チケットを作ってくれないシリーズ
上記で、何とかログインしてくれるようになったとします。しかし次の障壁は「なぜかみんなチケットを作ってくれない」というもの。これにはどんな原因があるのでしょうか？
操作が恐い
新しいものを触る時って、何がどうなるのか分からなくて、もしかして壊してしまわないだろうか？ メンバーに迷惑をかけたりしないだろうか？ という恐怖感を覚えるもんです。恐る恐る触ってみればじきに慣れるんだが、触らぬ神に祟りなしと考える人も多い。
ということで、「サンドボックスプロジェクト」を一つ作ってしまおう。この中では、テストでチケットを作ったり、勝手に他人にアサインしてみたり、と好きな操作をやってもOKです、という空間を作る。そして「OKです」じゃなくて「是非色々やってみてください」と促す。
何をやっても壊さない、仮に壊してしまっても業務に支障はない、他人に迷惑を掛けることもない、と保証する領域を作ってやれば、それなりに安心して操作を体験できるハズです。
チケットが自分に与える影響を誤解
「チケットは、作成したらその内容を必ず遂行するものである」「チケット作成＝完遂しますという表明」と誤解しているケース。このような意識を持っていると、おいそれとチケットを作れない。
チケットを作るというのは、そんな大それたことではない。ITSに登録する課題は、必ず時も「確実に実行しなければならないもの」ではない。思いつきでチケットを作って良い。実行しないと決まれば、そのままクローズすればいいだけ。
ということを、しっかりユーザに伝えるべきだ。下手すると、そもそも「ITSの導入を試みる立場の人」の認識が間違っていることもある。敢えて「間違っている」と言ってしまったが、運用方法はそれぞれ、というコトもあるだろう。しかし、このような意識では、なかなかITSを上手く回していくのは難しいんじゃないかな、と思っている。
JIRAでは、チケットを作成したけれど、処理を開始せずにそのままチケットをクローズする、というワークフローがデフォルトで用意されていることも考えると、やはり「チケットの内容は必ずしも実施されない」と考えた方がよさそうだ。
また、処理せずにクローズされたことによって「あぁ、これはやらないことになったんだな」という周知にもなる。コメント機能で、このチケットが未処理でクローズに至った経緯をメモしておければ、最高の運用だと思う。
というわけで、本当に気軽に、どんどんチケットを作って、タスク管理が出来ればベストだよ、ということを周知する。
チケットが他メンバーに与える影響を軽視
チケットを作らずに仕事をしてしまうケースです。これが難しい。どーーしてもやってしまう。俺もｗ
チケットを作って、状況や進捗をメンバーに周知できる。これがITS運用の最大のメリット。ただ、どうしても客観的に見る事ができなくて、他人からの周知は要求するが、自分からの周知を怠ってしまいがち。
これも、もうトップダウンで「進捗どうなってる？ で、そのチケットはどれ？ 今話した進捗、チケットにコメントいれといて」という指示を、慣れるまで出し続ける。というゴリゴリな方法しか思いつかないｗ
慣れてさえしまえば、報告代わりにチケットを動かすようになってくる。チケットにさえ書いておけば「報告しろ」と言われなくなってくるからね。そして「チケット」が「自分の作業実績」だと感じられるようになってくればしめたもの。チケットを作らずに仕事をすると、仕事はしたのに周囲に認識してもらえない。「俺はこんだけの仕事したぞ！」という主張のためにチケットを動かす。
また、管理者視点も改革の余地がある。誰かに仕事を振る際に、ただ「これやって」と指示するのではなく、必ずチケットを介して仕事を振るようにすること。可能であるならば「チケットを作らなければ、正式な業務命令と見なさない」というルールを作ってしまうｗ 「あの件、どうなってる？ 頼んだよね？」「え、チケットどれですか？ やってませんよ？」「そうか…」がまかり通っちゃえば良いと思うｗ まぁ色々難しいだろうけど。意気込みとしてはこのくらい欲しいものである。
チケットを握り込んでしまう
「担当者とは一体なんなのか？」の認識が甘いケース。
各チケットの「担当者」は、その件に関してボールを握っている人、をあらわす。仕事のボールが飛んできたら、握り込まずにすぐに打ち返せ、という言葉もあります。
http://www.omotesando-ad.jp/archives/50807078.html
これを意識して、自分がなるべく「担当者」である状態を短くするよう心がける。つまり、誰かが振ってきたタスクを、完了したら、すぐにコメントや成果物を送ると共に、「振ってきた人」に再アサインするのです。仕事をこなして終了ではなく、チケットのアサインも返すのがポイント。
例えば、AさんがBさんに「書類を提出せよ」というタスクを作った場合、書類を提出して終わりではなく、その後にBさんがそのチケットの担当者を「Aさん」に変更して終了。アサインを受けたAさんは、その書類を確認して問題がなければクローズ、不備があればコメントと共に、Bさんに再アサインすることになるわけです。
誰もが「責任」は負いたくありませんｗ チケットの担当者であるということは、「本件の処理責任は、現在私にあります」という意味であることを、深く認識すべきです。担当者である限り「本件、どーなってんのよ！？」と突っ込まれる可能性が常にある、と。
逆に管理者の立場からは「とある課題について、話を聞きたい」と思ったら、そのチケットを探し出し、その「担当者」に聞くべきです。
ちなみに、Jiemamyプロジェクトにおいては「チケットの担当者がいない」ことを許す設定になっています。OSSは仕事ではないので、義務はない。そこまでガチに管理する必要もないし、筋合いもない。
しかし、仕事に使っているJIRAではこれを許さない、つまり「チケットは、クローズされない限り、必ず誰かが担当者になっている」という設定にしてあります。スパルタンですねｗ これで、みんなに「チケットの担当者でいたくない」という意識があれば、ボールがぽんぽんやり取りされ、仕事の回りも早くなるというもの。素晴らしい効果です。
というわけで、ITS運用の勘所をまとめてみた。また何か思いついたら書きますね。
*1:http://commons.apache.org/jelly/
*2:といっても、自分で翻訳するんですがｗ
