自分のやり方ですので他のやり方もあるとは思います

課題管理・タスク管理のやり方

課題管理・タスク管理のやり方を記述します。
リスクやQAがあり、最終的に課題になり、それはタスクとなるので、課題管理とタスク管理は一緒です
なので次からは課題管理として記述します。
※ 本来のタスクはWBSが出来、ちゃんと進捗管理されるものなので、ここで言う課題管理・タスク管理は、突発的に出てきたWBSに現れないものを表します。

まずは簡単に結論

やるべきこと

つらつらと長いことを書いてもどうせ読まれないので結論を先に書きます

次のアクションを書き、その期限を切る
担当者はボールを持ってる人にする
課題を推進する人を立てる
書くのに簡単なフォーマットを決める

以上です。この4つをやるだけで劇的に課題が回ります。
この中で一番重要なものは

次のアクションを書き、その期限を切る

です。
課題が記述され、その課題の次にすることが分かり、担当が明確で、それに期日が決まっていれば回るのです。
これは絶対です！
そんなの「わかってるよ」という人が居るかもしれないですが、
この「次のアクションとその期限」が出来ない人が多く存在しているのです！！

常識的に考えてやったほうがいいこと

次に常識的に考えてやったほうがいいことを記述します。

プロジェクト管理ツールを使う
課題をフェーズなどで分類わけする
1つのチケットに1つの課題を書く
課題の討論の中で課題が出たら別課題にする
書くのに簡単なフォーマットを決める

以上です。
結構たくさんあるかもですが、1つ1つは大したことないはずです。
むしろ、これは書かなくてもみんなやっていることかと・・・

やってもやらなくてもいいこと

個人ではやらなくてもいいんじゃないか？でも、やってもいいかもしれないというものを書いておきます
経験したPJでは要るときと要らないときがありました（PM次第？）

課題が回らなかったときの影響を書く
最終的なデッドラインを書く

影響やデッドラインを書くと、それありきで考えることになるので、私は最初から書かなくて良いと思います。
回らない！ってなってから影響やデッドラインを考えればよいだけで、最初から考える必要はないです。

ダメなこと

細かい話の前に、これはしないようにという意味を込めて、失敗したときのことを書きます
結論に書いたことの逆は自明なので、書きません。

課題に課題（問題）だけを書く
課題に大きな課題を書く
デッドライン（最終期限）で期限を切る
返答したことに対して、担当を変える
書いた人が担当になる文化を作る（もしくは、その流れになっている）

課題が回らない理由

課題はなぜ回らないかの原因しました。

課題が記述されない
課題を記述したが何をしていいかわからない
課題を記述したが誰が実施するのかわからない
気づいた時が課題の期限

回らない理由を解決するときにはやるべきことが出てきます。
以下、それぞれ理由と解決方法を記述していきます。

課題が記述されない

なぜ課題が記述されないのかを考えると、まずは「課題に書くと俺がやることになる」ということで、
書かなくなる風習が出来たりしています。
これは、課題はまずはリーダを担当にするというルールを作り、ディスパッチなど推進してもらうようにします（課題を推進する人を立てる）

他には、どう書けばいいんだっけ？何書けばいいんだっけ？となりますので、
フォーマットを決定します。また、このフォーマットは簡単であるべきです。
また、フォーマットを決めないと無法地帯となり、欲しい情報が手に入らなくなります。
（書くのに簡単なフォーマットを決める）
例えば以下


* 課題内容
課題の内容を簡潔に書く

* 対応案
どう対応していくかを記述する
進め方が思いつく場合は、次のアクションと期限を記述する
例
お客さんと調整する資料を作成する：1/5
お客さんと調整する：1/6
設計書を修正する：1:10

* 対応内容
どう対応したかを記述する。
対応案の通りの場合は「対応案通り」とする

課題を記述したが何をしていいかわからない

この問題が多分一番の問題ではないでしょうか？
これを解決するために必要なのが「次のアクションを書き、その期限を切る」です。
大きな課題や問題だけを課題に書いた場合、推進者を立てたとしても、推進が出来ません。
アクションを細かくし、それについて期限を切ることで、ちょっとずつ先に進み、いつのまにか
課題が解決しているのです。

例えば、「後発プロジェクトにより、プロジェクトに影響がある」というようなことが書いてある場合
「どんな後発プロジェクト？」「影響って？」「てか、まず、なにすればいいの？」になります。
そこで課題を小さく、「後発プロジェクトと調整する」「後発プロジェクトに対する影響を対応する」などすることで
推進者は次のアクションを決められます。この場合は後発xxxPJと打ち合わせするなどとなるでしょう。
なお、この場合、その打ち合わせ日を期限日にすべきです。後発のxxxPJと調整が完了する日を期限日にしてしまうと、推進者が気づかなかった場合、期限日には取り返しのつかないことになっています（気づいた時が課題の期限）

課題を記述したが誰が実施するのかわからない

課題はチャットツールではないので、返信をしたことを表すために担当者を変更することがない様にします。
なので、次のアクションをやる人を担当にします（担当者はボールを持ってる人にする）

例えば、Aさんが課題に対し「xxxをしてください」とBさんを担当にした場合、xxxをするのはBさんですが、
Bさんが「了解しました」と返信をして担当をAさんとした場合、推進者はxxxをするのをAさんと勘違いします。そのようなことが沢山出てくると、その課題が、現在どうなっているのかわからなくなります。

常識的に考えてやったほうがいいこと（詳細）

次に常識的に考えてやったほうがいいことについての詳細を記述しておきます。

プロジェクト管理ツールを使う

課題管理をするうえで、メンバが簡単に、何の影響もなく、記述出来るべきです。
ですので、ネットがつながって居れば登録できるプロジェクト管理ツールは
ぜひ取り入れるべきものです。

エクセルで管理する場合、誰かが捜査しているときはできない、フォーマットを作るのが大変などがあり
私としてはお勧めできません。スプレッドシートなら及第点

課題をフェーズなどで分類わけする

課題はフェーズ（設計フェーズ、実装フェーズなど）で分けるべきです。
なぜなら、どの課題（影響）なのかが一目瞭然となるからです。
// それ以上でもそれ以下でもないです。

フェーズが完了した（する）時にはその課題がすべてなくなるように出来るなど、管理も楽になります。

1つのチケットに1つの課題を書く（「課題の討論の中で課題が出たら別課題にする」含む）

1つのチケット（プロジェクト管理ツールを使っている場合チケットという）に対して1つの課題を書かなければ、いつその課題がクローズできるのかが分からなくなります。
1つが解決してるなぁという状態でも、課題が複数あるため、クローズできません。
そんなことをやっているうちに、その課題の状態が分からなくなり、推進できなくなります。

課題の内容を討論しているうちに、別課題が出た場合もそうです。
そのままそれを続けていると、課題が管理できなくなります。

最後に

課題が回らないPJは大抵炎上しています。
どうやって回すかをちゃんとPJ開始前に決定しておくのも大事ですが、
途中で上記のルールを取り入れても良いと思います。

そんな時は、一回課題を全部失くすなど、勢いも必要だったりしますw