もしかしてこんな状況ですか？

１．依頼元が社内外を問わず広範囲（自部門:依頼部門 = 1:N）。
２．自部門のメンバーは少数(3人以下？)。
３．不定期で急に依頼されるタスクが多い。
４．タスクのボリュームはばらばら。数分で対応できるものから数か月以上かかるものまで。
５．期限を聞くと「なるはや～」で返ってくる。
６．依頼手段はなんでもあり(メール、チャット、口頭など)。
７．タスク一覧はあるが、管理がままならない。

抱えがちな課題

上記の状況だと自部門でこんな課題を抱えがち。

１．タスク一覧が随時更新されず、自部門メンバー間でも進捗が共有できていない
２．進捗の反映が適時にされないがために、タスクが管理できなくなっていく。もしくは、タスク管理に相当な努力（時間）が必要となる。
３．タスクの優先順位付けができない。最悪の場合、「口頭 > 電話 > チャット > メール」順に優先順位付いてしまう。

じゃあ、どうすれば？

新規タスクのinterruptが多い環境下では、きっちりした運用策をたててやっていくと変化の速度に遅れてしまいがち。
そのため、ゆるく気楽に管理できる策はないかと考えました。

ズバリITIL + kanbanのいいとこ取り

チームのタスクへの入り口はITILのインシデントと問題管理から着眼。
着手したタスクの管理は、kanban。

タスク管理の全体イメージはこんな感じです。

いきなりですが、プロジェクトやルーチンワークも入れました。。一応。

不定期な運用・保守

ITILのインシデントとインシデントの原因となる問題解決を分けて考えることから、「インシデント > 問題・改善対応」で優先順位を設定。

一般的な解釈ではないが、自部門の管理対象に関する不定期な以下の要求をインシデントとして定義。
１．アラート
２．リクエスト
３．問い合わせ

以下の通り優先順位を決め、全タスクを消化する(もしくは目指す)。

■タスクの優先順位
１．アラートを最優先して対応
２．リクエストと問い合わせは、基本First in First out
　　期限がある場合は、期限が短いものを優先

上記のインシデントを減らすための問題・改善点があれば、「問題・改善点一覧」へ追記する。

改善

インシデント一覧からでなくてもリスクとして想定されることがあれば、一覧に追記する。
ここの項目はその気になれば無限(多分。。)に書くこともできるため、最初からすべてをやることなど考えないようにする。

■タスクの優先順位
以下三つの項目をざっくり評価し、その結果から優先度を決める。
優先度の高いものだけをkanbanのタスクに積む。
１．インパクト：どれだけ組織目標へインパクトがあるか。
２．対応にかかる予想期間
３．気軽さ：対応者が気軽く対応できそうなもの。

上記１，２，３の結果からどうやって優先度を決めるかは自部門内で話し合ってみるとよいかと思います。
例えばすぐ対応でき、かつ気軽くできるタスクから優先度を高くつけるなど。

ただ、問題解決や改善となるとそれなりにタスクのボリュームが膨らむ場合もあるので、基本的にタスク分割した上kanbanにのせましょう。

プロジェクト、定期運用・保守作業

詳細は割愛しますが、不定期運用・保守対応をしながらもプロジェクトを消化する場合、ルーチンワークがある場合もそれぞれ優先順位を考えながらkanbanへ盛り込む。

kanbanについて

数多くの参考資料があるので割愛します。
個人的にはyou tubeに公開されているEric Brechnerさんのkanban説明がよかったです。

得られた効果

タスク管理という業務自体はなくなりませんが、kanbanへの入り口からタスクを絞りある程度優先順位をつけることができる上、すべてのタスクの状況がkanban上で一目瞭然と見える化できた。

jiraのkanbanテンプレートを使うと該当kanbanの火力（個/週）とタスク毎の平均リードタイムを確認するレポート機能があるため、2～3ヵ月ほど運用実績を積むとデータをもとにチームタスクの予定調整がしやすくなりました。

まとめ

いざ書き出したら思った以上に複雑そうに見えて伝わらないか少し不安ではあるが、実際運用でやってみるとかなり色んなことがすっきりします。「管理」をされている方にはぜひこの爽快感を味わってもらいたいと思います。