Redmine、Asana、Backlogなど様々なタスク管理ツール(プロジェクト管理ツール)があり、それぞれに長所・短所はあるのでツール選びは重要なのですが、「どう使うか」がとても重要です。良いツールがあり、直感的に操作できたとしても、正しく使えなければ良い管理はできません。
今回は私がPM・PMOとしてプロジェクトに関与している時に意識している使い方について紹介します。

チケットのクローズは誰が行うのか。

チケットのクローズを行うのは基本的に起票者です。自分が作ったタスクが誰かによって勝手にクローズされたら気持ち悪いので。ただし、起票者がその権限を誰かに委譲することは問題ないと思います。「○○の対処が終わったらクローズしてください。」といった感じで。

チケットクローズ時に担当者は誰にするか。

重要なことは、クローズすることを起票者に伝えることです。そのためには担当者を「起票者」に変更するのが一番無難ではあります。ただし、タスク管理ツールの仕様に「起票者には必ず更新通知を行う」という設定があったりするので、実際は担当者を起票者に設定する必要はそれほどないかもしれません。

共同編集する資料はファイルサーバに格納

ほとんどのタスク管理ツールは、チケットにファイルを添付することができると思います。チケット上で必要な資料が貼ってあると内容確認はスムーズです。ただし、共同で編集したり、常に最新版を見る必要があるファイルの場合は、ファイルサーバ上にファイルを置き、そのフォルダのリンクを貼るほうが効率的です。

期限に入力するのは直近のTODO期限なのか、最終完了期限なのか

1つのタスクの中に複数のTODOが発生することは多々あります。
その場合、それぞれのTODOの期限を定めて管理しないと、最終的なタスク完了期限を守れないリスクが高まりますので、TODOの期限を管理する必要があります。そのため、チケットの「期限」に設定するのは「直近のTODO期限」が良いと思います。
タスクの最終完了期限は、チケットの説明欄などに書いておくと良いでしょう。管理項目を追加できるのであれば、「直近のTODO期限」と「タスク完了期限」の2つを設定するのもアリです。 

子チケットを作成するタイミング

上述したように、1つのタスクの中に複数のTODOが発生することはあります。1つのチケットで複数のTODOを管理するのも1つの手なのですが、例えば、それぞれのTODOが同時並行で進んだりすると期限設定が難しいです。また、議論が必要な課題が発生している場合は、チケット内で特定課題に対する議論が行わることとなり、そのチケット本来の管理したい内容とずれてしまいます。そのため、このような場合は1つのチケット内で管理せず、子チケットを作成したほうがよいです。
まとめると、以下のような場合は子チケットを作成したほうがよいです。
・TODOが平行で進行
・議論が必要な課題が発生

(これが難しいんですけどね。。。)

入力項目(管理項目)は必要最低限に絞る

チケットの入力項目を増やして進捗状況や障害状況の細かい分析をしようとする方がしますが、入力項目が増えれば増えるほど、1つ1つの入力内容が適当になりますし、そもそもチケットを起票する気がなくなります。
入力項目が40フィールドくらいあるチケットを見たことがありますが、ほとんどまともに運用されてませんでした。できるだけシンプルにすることが重要です。

しばらく検討しないタスクは保留にして一定期間経過後にクローズ

いったんタスク化したものの、期限もなく、必須でもないようなタスクっていっぱいあるんですよね。部長から「時間あるときにやっておいたほうが良いよ。」みたいなものとか。一定期間過ぎると、やる意味も無くなってきますし、未完了タスクが増えると、管理工数が増えますので、一定期間過ぎたらクローズしてしまいましょう。また必要になったら再度オープンにするだけです。

選択肢の設定はよく考える、修正する。

何らかの統計情報が取りたいときなどに選択式のフィールドを設けたりすると思いますが、入力される値をしっかり網羅しないと、正しく情報がとれないのでよく考える必要があります。「その他」という選択肢を作っておき、「その他」が設定された場合はヒアリングを行い、選択肢を追加する運用にするのも良いと思います。

履歴を残したいタスクはできるだけチケット化

例えば協力会社や、社内の他部門からメールで依頼がきたからといって、そのままメールでやりとりしてしまうと、情報がタスク管理ツールに集約できなくなります。理想は、新規チケットに情報を転記し、チケット上でやりとりを行うことです。

履歴を残す必要のない場合はチケット化不要

チケット化するのは記録を残すためですので、例えば会議日程調整のような記録を残す必要のないやりとりはメールのままでも良いと思います。

使用マニュアルはできる限り完結に！

正しい使い方をマニュアル化し、社内に展開することが望ましいですが、量の多いマニュアルは使用者の理解を妨げます。経験豊富なコンサルの方が重厚な手順書を作ったりするのですが、それが良いものとは思いません。マニュアルはできるだけシンプルなものが望ましいです。基本的な操作は完結に書き、ユーザが迷いそうなことはQ&A的にまとめるのも良いと思います。