プロジェクト管理の中の課題管理の説明です。
リスクが顕在化したものが課題です。リスクが顕在化したタイミングで、リスク管理から課題管理に移されます。実際にはリスクが顕在化することは滅多に無く、突然発生するものが大半ですが。
課題は、QCDや顧客満足に影響を与えます。
よくある勘違いに「タスク（TODO）」を「課題」として管理するプロジェクトがあります。「タスク」と「課題」を区別できない人たちが非常に多いです。
また「問題」と「課題」を区別して管理するプロジェクトも稀にありますが、通常のプロジェクトでは両者を総称して「課題」と呼びます。無駄に分類を増やしても、分類することにエネルギーを使ってしまって、あまり良いことがありません。
課題管理のキモは、以下の２点です。
・タスクを課題と勘違いして、いたずらに課題の数を増やさないこと。
・困っていることが何で、どのような影響があって、どうなったら解決なのかを明確にすること。
１．リスクと問題、課題、タスクの違い
一番分かりにくいのが問題と課題の違いです。「問題」は目的を阻害する事象や要因で、原因が分かっていないもの、それに対して「課題」は目的を阻害する事象や要因で、原因が分かっているもの、です。原因が分かっているか分かっていないかで、問題と呼ぶか課題と呼ぶかが変わります。
プロジェクトの目的を阻害するようなインシデントは、「リスク」→「問題」→「課題」→「タスク」といった遷移をします。（リスクを認識せず、突然顕在化する場合が大部分ですが）
例えば「プロジェクトが遅延する可能性がある」というリスクが、「プロジェクトが遅延した」という問題となり、遅延した原因を究明して「プロジェクトメンバー１名が離脱したためプロジェクトが遅延した」という課題となり、「新しいメンバーの補充」というタスクとなります。
ただ通常はこのように一つのインシデントに対して４種類の管理をすることは稀で、「プロジェクトが遅延する可能性がある」なんてリスクは普通はリスク管理の対象になりません。よほど通常のプロジェクトと違う何らかの遅延の可能性が高まる要因があれば別ですが。
また問題と課題も区別しません。問題の原因なんて複数あるのが普通ですし、また立場によっても原因が違ったりもして、なぜなぜ分析みたいなことをし出すと、永久に原因に辿り着かなかったりもするので、そこに力を入れるよりも目先の火を消すことを優先します。似たような問題が多く発生した場合には、原因を追及して抜本的な対策を打つ場合もありますが、そういう事態になるプロジェクトはかなり大炎上している状態です。
そして課題に対してのアクションも、わざわざタスクとして分類し直したりしません。普通に課題のステータス管理の中で、対応中というステータスがタスクを意味することになります。ステータスは、「未着手」→「原因究明中」→「対策検討中」→「対応中」→「完了」といったような遷移をします。
つまり一般的なプロジェクトでは、問題と課題は区別しませんし、課題を解決するためのタスクは課題管理のステータスで表現をします。
ただし明確な区別はしなくても、概念としては「問題」「課題」「タスク」の区別は重要で、問題のままにせず課題まで落とし込むことはとても重要です。
２．ダメな課題管理
①何でもかんでも課題にすること
例えば要件定義で少しつまづくと、すぐに課題管理にあげる人がいます。確かに「検討課題」という表現を使ったりもしますが、そもそも要件定義はぼんやりした要求を形にしていく工程なので、検討課題の集まりです。ユーザー部門から難しい要望が出るのは珍しいことではなく、その落としどころを探っていくのが要件定義そのものです。つまり要件定義で発生する「検討課題」と呼ぶものの大部分は課題ではなくタスクです。要件定義工程で、課題の数が二桁にいくようなプロジェクトは、課題を勘違いしている可能性が高いです。
ではなぜ検討課題を課題管理の対象にしてはいけないのか？
それは本当の課題が埋もれてしまうからです。乱暴に言ってしまえば、要件定義の検討課題は要件定義を推進するプロジェクトメンバーが管理するもので、課題管理にあがった課題はプロジェクトマネージャーが管理するものです。それをごちゃごちゃにしてしまうと、本来プロジェクトマネージャーが注力すべき課題がぼやけてしまうのです。
他の例だと、要件定義が終わると発注者側の次の関心は導入教育になります。そこで「教育体制を整えないといけない」というような課題をあげることがあります。これも課題ではなく、ただのタスクです。これがリリース１ヶ月前になっても整っていなければ立派な課題ですが、要件定義が終わった段階では、ただのタスクです。
課題管理にあげる前に一呼吸置いて、それはただのタスクではなく、本当に課題なのか？と考えるようにしましょう。
②漠然とした課題
例えば要件定義で物流拠点を統合するか別々のままか決定しなければいけないのに、要件定義が終わっても決まらないケースがあったとします。これは課題となりますが、「物流拠点を統合するか決まらない」といった課題だといつまで経っても有効な対策が打てません。課題はどのような影響があるのかを明確にする必要があります。この例でいえば「物流拠点を統合するか、統合しないかが決まらないので、××サブシステムの基本設計に着手できない。２週間以内に決まらないと、納期が遅れる可能性がある」といった記載にすれば、上位マネージメントにエスカレーションして、決断を急がせる交渉もしやすくなりますし、「２週間以内に決まらなかったら物流拠点は統合しない前提で設計を進める」といった対策もしやすくなります。
課題管理にあげる際には、「どのような影響があるのか」「どうなったら課題がクローズできるのか」が分かるような書き方にしましょう。もしこの２つが明確になっていない場合、いつまで経っても有効な手が打てず、課題がクローズできないという状態になります。発生して何ヶ月も経っている課題がある場合、この２つが明確になっているか点検してみましょう。
このように課題管理で重要なことは、タスクを課題扱いしないこと、課題は影響とクローズ条件を明確にすること、の２点です。プロジェクトの規模にもよりますが、課題の数が１０個を超えたら、適切な課題管理ができていない可能性があります。
③業務課題や変更要求との混同
業務課題や変更要求とシステム課題を混同しないことも重要です。ユーザー部門とは協力し合いながらプロジェクトを進める必要があり、「これはユーザーの課題だから知らない」という姿勢は論外ですが、適度な線引きは重要です。
業務課題は、ユーザー部門が解決するものなので、システム部門では解決が難しい場合が多いです。それをシステム課題と一緒にシステム部門がボールを持ってしまうと、いつまで経っても解決せず、結果的にユーザーに迷惑をかけることになります。
変更要求も同様です。システムがユーザーの求める要件を満たしていなくても、ベースライン（要件定義での確定内容）を達成できているのであれば、それはシステム課題ではなく変更要求です。
変更要求は、対応した場合のシステム影響（コスト、品質、納期）と対応しない場合の業務影響を比較して、ユーザー部門と一緒に合理的に判断します。（課題管理ではなく変更管理の対象です）
それをシステム課題と混同して、システム部門がボールを持ってしまうと、ユーザーは対応してくれるものと思ってしまいます。結果、予算や期間の都合で対応できないという結論になった場合、変更要求は業務課題に変わり、突然ボールを渡されたユーザー部門との関係が悪化します。
【振り返り】
今回はプロジェクト管理の中の課題管理の説明でした。リスクを敏感に察知して未然に顕在化を防止し、それでも発生してしまった課題を早急に潰し込むことがプロジェクトマネージャーの重要な仕事です。そのリスクや課題を発見する手段の一つが進捗管理や品質管理です。次回は品質管理の説明をしていきたいと思います。
①．進捗管理
②．品質管理
③．コスト管理
④．課題管理
⑤．リスク管理
⑥．変更管理
⑦．コミュニケーション管理
⑧．成果物管理（文書管理）
⑨．要員管理
⑩．ステークホルダー管理
⑪．外注管理
