BackLogを課題のゴミだめにしない為の運用ルール

1.要旨

BackLogを課題のゴミだめにしない為の運用ルール
①「担当者」と「期日」は強引に設定すること
②未解決課題は25件以内をめざす
③１つのチケットには１つの課題

BackLog（バックログ）は、少なくとも国内ではタスク/課題管理ツールとしてはデファクトの存在だと思いますがこのツール、上手く運用できていますか？
けっこう「課題やタスクを投げっぱなしの放置プレイ」で、情報ゴミだめ状態になってしまうことも多いと思います。

そこで以下、単純なルールながらBackLogを効果的に運用するコツを整理します。

2.「担当者」と「期日」は強引に設定すること

私の印象ではここをキッチリやってる運用はほとんど見かけません。
確かに「担当者」に「期限」まで指定するのはちょっと相手に対して　気が引けますよね。
しかし、タスク/課題管理をしっかり行う上ではここが一番重要ではないか？と思います。

宛先が不明ならカウンタの担当者名を強引にセット。期限が無い内容でも「1ヶ月後」を強制指定、です。

そもそも、担当者もいない、期限もないタスク/課題などBackLogに載せてはいかんのです。

ついでに、課題一覧に担当名と期日が表示されるように、UI設定を変えましょう。画面に見えていないのは設定してないのと同じです。
（プロジェクト全員が設定するようにしましょう）

3.未解決課題は25件以内を目指す

こちらも小うるさいルールですが、タスク/課題は投げるだけでは溜まり続けます。
PM氏が小まめにお尻を叩いて課題をクローズに導いていく必要があります。

過去、大規模案件に従事していた際、女性のPM（結構細かい人）が定例会議後に、いつもカウンターの担当者と膝を突き合わせてBackLog課題を検分していました。
妥協無く課題を追い込む姿勢に「すげーな」と思った記憶があります。
ちょっと油断すると直ぐに100件くらい行ってたでしょう。

「割れ窓理論」ではないですが、放置課題が40件を超えてくると急に参加メンバーの課題の扱いが雑になっていく印象があります。
こまめに片づけていくことが重要です。

4.１つのチケットに１つの課題

タイトルは分かり易く、
1つのチケットに１つの内容を記載する
ことが大事なのですが、文章表現の話というよりはタスク/課題の粒度が大事と言えると思います。

1つの課題でも、中身がふわっとした内容だと、課題が複数に派生したり、スレッドの中で話があちこちに飛散して「結局なんのチケットだったの？」となります。

話がそれたら別チケットに立て直す、などの交通整理も必要です。

以上、運用のポイントを３つに絞ってみました。
多くの開発会社ではあたりまえにやっていることだと思いますが、ルールを守る/守らせるのは結構大変、、です。

おわりに。
si-digitalでは再現性の高い仕事ノウハウを共有していきます。