ITSの導入障壁

ここ数年来関わったプロジェクトでITSを運用に乗せるの意外と難しいなと思ったのでメモ。
ITS（イシュートラッキングシステム）、BTS（バグトラッキングシステム）、課題管理システムと色々呼び方はあるがとりあえずここではITSと呼ぶ。

新しいツールを使うというのは誰にとってもストレスで、特に有用性が腑に落ちていない状態ではなおさら。
セットアップしてアカウントを用意しただけではだいたいみんな使ってくれない。

運用に乗せるために一手間、運用が軌道に乗るまでに何度かの振り返りが必要となる。
とか色々考えるまでもなくすんなりうまく回るケースもあるが、そう言う場合はラッキー。

なおITSを使うこと自体は目的ではなく手段なので、使わないという選択肢もあり得る。短期のプロジェクトで、仕様が明確で、バグが極めて少ないなど。
しかし長期にわたる運用が絡む場合はやはりあった方がいいかなと思う。

とりあえず使ってもらうには

何者であるかを一言で分かりやすく説明する

• 「要はバグを管理するためにバグごとにスレッドを立てられる掲示板です」など
  • 「掲示板って何？」と言う人もいるので難しいときもある

利点の説明をしっかり行う

• 問題の解決を確実にトラッキングできる = 着実に修正を進めていくことができる
  • メールやチャットと違い、未解決の問題が流れて行方不明になったりしない
  • 未解決の課題のみを表示できるなど現状把握もしやすい
• 過去の問題を検索しやすいし、対応履歴としても有用

ユーザーは説明を受けた上で使ってみないと多分腑には落ちないとは思うが、理解されるまで説明を続けることは大切。

課題を登録する上での不安を取り除く

「こんな些細なものを登録していいのかな？」と悩んで手が止まる人がけっこう多いようなので、懸念を感じたらとりあえずどんどん登録してもらう。

ITSで管理するべきものでなければ管理する側の開発サイドがどんどんクローズしていく。

そのうち利用する側も何を登録すべきかそうでないか分かるようになってくるはず。

運用ルールはなるべくシンプルに

だいたいのITSには優先度、タグやカテゴリなど項目が色々とあるが、まずは使わないで運用をスタートし、あとから必要性を判断。
とにかく利用者が迷わないことが大切。迷うとそこで利用がストップする。

担当者の割り当ても。分からないときはそのまま未設定で。対応する人が自分で担当を割り振る。

未対応、対応済み、完了などのステータスの変化も登録側はノータッチで、対応する人が操作すれば良い。

タイトルだけ分かりやすく登録してもらうようにする。

最低限の運用ルールの例

• タイトルを的確に付ける
  • タイトルを見ただけで内容が分かることが肝要
  • 良い例と悪い例
  • 「サイドバーの表示について」などは悪い例
  • 「サイドバーの表示が乱れている」などは良い例。もっと具体的だとなお良いが登録側の負荷を考えると適度な妥協も必要
• 1つのイシューに複数の問題を詰め込まない
  • 完了の定義が難しくなるため
  • そうしたイシューが登録された場合は破棄して分割する
• スクリーンショットの添付を推奨

ITSを通さない修正は受け付けない運用とする

もっとも効果的。
ただ強権的手段でもある。カドが立たないようにうまく誘導できれば良し。

長期にわたるプロジェクトの場合は多少カドが立ってもメリットの方が上回るので原則とすべき。

トレーニング/ハンズオンを行う

準備や実施に時間が必要なのがネックなのでなかなか難しいが有効な手段。

てかITSのトレーニングだけで仕事になる気が。

検索してみるとバックログの初回導入サポートとかあるのね。
Redmineも導入サポートとかコンサルやってるところあるっぽい。

利用を始めるタイミングを計る

開発が終わりに近づいて結合テストを開始したあたりが妥当かと個人的には思っている。

開発初期から仕様の整理や検討に利用する運用も可能だが、そうしたイシューを登録する手間に見合うリターンが得られるかと言うと疑問。
なんとなれば具体的な問題が発生しているわけでもないのでぼんやりしたイシューが増えがちで、誰が何をしたらいいのか分からないまま開発終了までゴミとしてずっと残り続けることが多い。

開発初期のタスク管理ツールとしてはPivotal TrackerやWaffle.io、ZenHub、Trelloなどのカンバン系を使った方がいいような気がする（自分の経験のある中規模くらいまでの開発では）

モノが形になってきて運用が回り始めたら開発のタスク管理ツールとして使うのもあり。

定期的に運用状況をチェックし、必要ならば見直しを行う

使い続けてもらうためのフォローアップ。

顔を合わせる機会があったときなどに確認するとだいたい何か出てくるので、都度説明を入れたり運用ルールの変更などを行う。

運用が軌道に乗れば要望管理ツールとして使うなどアクティブな使い方もあり。

使われないパターンあるある

メールやチャットが主流のまま

• ITSを通さない修正依頼に対応しているとこうなりがち
• とりあえず問題解決はできるが、後でトラッキングが大変
• 問題の数が多い場合は対応漏れが出やすい
  • 課題を投げた方が忘れてしまうこともある

一部の人しか使わない

• IT親和性やITリテラシの差がもろに出る
• 情報格差ができてしまい、コミュニケーションロスに繋がりやすい

問題があるのに報告がなくなる

• 「ITSを通さない修正は受け付けない運用とする」を無理矢理通したときに起こりがち
• 関係悪化と言うより何をやったらいいのか分からなくなり動けなくなっていることが多い
• いずれにせよすごくまずい状態

諦めも肝心

• ITSは手段であって目的ではない
• メンバーが付いてこられないのであれば導入断念も選択肢
• その代わり余計にコストはかかりますよorスピードは落ちますよ的な話はしたい
  • 手動の課題管理
  • または開発側だけに閉じた状態でITSを使うことにするなど。メールやチャットの内容を転記したり、解決の報告を手動で行ったりする分手間がかかる

他の手段との比較

ITSの利用推進に説得力を持たせるために整理。

ITS

• 問題を確実にトラッキングでき、現在進行形のタスクが一目瞭然で対応漏れが出にくい
• 過去の問題が検索しやすい。完了したタスクを一覧で眺めることもできる
• 運用を整備したり使い方を覚える必要があるという初期コストのデメリットはあり

口頭/電話

• 記録が何も残らないため、その場にいなかった人間との情報共有がしにくい
• 行き違いが起きたときに言った言わないを記憶に頼るしかなくなる
• 決定事項も時間が経つと記憶とともに曖昧になっていく
• 瞬間的に極めて高速であるというメリットはあるが、デメリットもまた大きい

メールやチャット

• 現在進行形のタスクはまあまあうまく扱えるが、タスクの数が増えてくるとトラッキングが大変で破綻しやすい
• 過去の出来事に関してキーワードや時期が思い出せないと検索が困難
• だいたい誰でも使えるというメリットはある
• 問題の数が極めて少なく、短期で終わるプロジェクトであればむしろメールやチャットのみでもOK

Excel

• バグや課題表を作成しメールでやりとりして管理する方法が一昔前・・・いや二昔前（二十世紀）はよく行われていた
• 誰が最新バージョンを持っているのか分からなくなり、内容が先祖返りするなどの問題がしばしば起こる
• メリットは探せば何かあるのかもしれないがデメリットの方が大きすぎる
• Excel便利だけどその使い方は違うよねという話

余談

勝手に担当にされてイラッとする問題

「以前はITSを使っていたが、勝手に担当に割り振られるとイラッとして職場がギスギスするようになったので利用をやめた」という話を聞いたことがある。

すごく分かる。

このあたりの合意形成や運用の工夫は大切。機械的な押しつけはNG。

トップダウン

そういや割と大きな会社で上の人が自らバックログ探してきて「使ってください」と言ったときはみんなやけにすんなり使ってたことあったな、と思い出した。

権力！

ただまあしばらく経つと何人かはメールに戻ってしまった。フォローアップがないとそうなってしまうか。