業務改革やシステム導入、製品開発をはじめとした各種プロジェクトでは、プロジェクトの着手から完了まで予定通りに進捗することは稀で、通常はプロジェクトの過程でその進捗を阻む多くの課題が発生します。
従ってプロジェクトを推進していくには、適切に課題をマネジメントするスキルが必要になります。
本日のテーマはプロジェクト運営における課題管理についてです。
課題管理表の作り方に加え、課題管理を運用していくうえでのポイントや、課題とタスク、リスクとの違いについても扱います。
それでは一緒に学んでいきましょう。
課題管理とは何か？ 課題・リスク・タスクの違いも紹介
課題管理とは、その名の通り、”課題を管理すること”です。
具体的には、プロジェクトを推進するうえで障壁となる課題を漏れなく拾い上げ、それらの課題に対する進捗状況や対応方針、更にネクストアクション等を明確化することで課題解決を促していくことです。
通常、プロジェクト運営では様々な課題が生じますので、課題を適切に管理しないと、どのような課題が生じているのか、どのくらいの規模感で課題が生じているのか、各課題が滞りなく対応されているのか等が把握できず、プロジェクトの遅滞等を招いてしまいます。
従って、プロジェクトの円滑な推進には、課題管理は重要な要素となります。
なお、課題と混同されやすい概念として、リスクやタスクがありますが、これらの違いは何でしょうか？
まず、課題とリスクの違いは、プロジェクト運営上の障壁となる事象が、既に生じているか否かの違いです。
既に生じている事象であれば課題であり、まだ生じていない（しかし手を打たないと、生じる可能性がある）事象であればリスクとなります。
また、課題とタスクの違いは、事象か作業かの違いです。
解決が必要な事象そのものであれば課題であり、課題を解決する為の1つ1つの具体的な作業であればタスクとなります。
つまり、リスクが現実化すると課題になり、リスクや課題を解決するためにタスクが発生するというイメージになります。
課題管理表のフォーマット例・具体的内容
通常、課題管理は課題管理表を用いて行います。
大規模なプロジェクトでは、JIRAなどのソフトウェアを用いて課題管理を行う場合もあり、それらのツールには標準的な管理項目が既に設定されています。
本記事ではExcel等でゼロから課題管理表を作成する場合について紹介します。
プロジェクトの内容や運営ルール等により多少の違いはありますが、課題管理表のフォーマット例としては以下のようになります。
課題管理表の各項目について、左から順に見ていきましょう。
① 課題No.
各課題に対する付番であり、基本的に1・2・3・・・の順で連番で記載します。
② 課題名
課題の概要を把握できるよう、課題のタイトルを端的に記載します。
③ 課題詳細
課題の具体的内容を把握できるよう、課題の詳細を記載します。
この項目が肝となるので、記載内容を関係者と擦り合わせ、認識齟齬が生じないようにすることが重要です。
④ 起票日
課題管理表に、その課題を起票した日にちを記載します。
⑤ 更新日
課題への対応が進捗し、課題管理表の記載内容を更新した日にちを記載します。
更新日が長らく変わっていない場合、課題への対応が遅滞している懸念があるため、定期的なチェックが必要です。
⑥ 提起者
部署名含め、課題を提起した人をバイネームで記載します。
提起者が課題管理表に直接起票する運用の場合は、この項目名は「起票者」になることもあります。
⑦ ステータス
「未着手」・「対応中」・「完了」などのように、各課題の状況を記載します。
課題管理表上でソートし易いよう、”完了”・”完了済”・”クローズ”などのように、同一ステータスに対する表現は混在させないことが重要です。
⑧ 優先度
課題は通常、優先対応すべき課題、劣後してもよい課題に分けられる為、課題の優先度を記載します。
優先度の判断基準は後述します。
⑨ 完了条件
各課題の完了条件を記載します。
後述しますが、課題がいつまでも完了とならない要因の1つに、完了条件が定義されていないことが挙げられる為、各課題に対する完了条件をしっかり明記することが望ましいです。
⑩ 完了期限
課題のステータスが「完了」となるべき期限を記載します。
あくまで完了期限であり、後述のネクストアクションの期限ではありません。
⑪ 対応状況
課題の進捗内容を把握できるよう、時系列で課題への対応状況を記載します。
⑫ ネクストアクション
各課題について、次に行うべきアクションを記載します。
「⑪ 対応状況」の項目内に書いてしまう方法もありますが、次のアクションを即座に把握できるようにする為、⑪とは分けて管理することを推奨します。
⑬ 最終結果
各課題がどのような内容で完了したかを後々に把握できるよう、課題への対応結果・検討結果を記載します。
課題管理を運用する上でのポイント
課題管理を行ううえで、課題管理表を作成し、そこに課題を列挙して、対応状況を管理していくことは重要ですが、それだけでは不十分です。
ここでは、課題管理を効果的に行うための、運用上のポイントを紹介します。
課題管理表で管理する対象範囲を定義する
課題管理においては、課題管理表で管理する範囲を定義することが重要です。
課題管理表なので、対象範囲は課題では？と思われる人もいるかもしれませんが、実際のプロジェクトでは、上記で挙げた”リスク”や”タスク”など、課題ではない内容も課題管理表に混ざって管理されていることがあります。
そうなると、何でも課題管理表に起票してしまい、課題のボリュームを正確に把握できなかったり、管理するボリュームが増大して収拾つかなくなってしまうなど、機能不全に陥る可能性があります。
従って、課題管理表では”課題”のみ管理するなど管理範囲を明確化し、課題管理表に起票する際は、定義した管理範囲に合致するかをチェックしてから起票することが重要です。
課題管理の運用ルールを設ける
課題管理表の運用に統制を効かせる為、課題管理の運用ルールを設けることが重要です。
何もルールを定義せずに、いつでも誰でも自由に課題の起票・更新・完了が可能であると、本来は課題ではない内容が次々に課題管理表に起票されたり、課題管理表に記載された内容が誰も理解できずに対応が進捗しなかったり、まだ検討が必要な課題がいつの間にか「クローズ」のステータスに変わっていたりと、プロジェクト運営に支障をきたす可能性があります。
従って、課題管理の機能不全を回避する為、課題管理の運用ルールを定義することが重要で、一例として以下のようなルールが考え得ます。
- 課題管理表への課題の起票・完了には、関係者間の合意形成を必要とする。
- 課題を起票する際は、課題の詳細内容や対応方針、ネクストアクション等を関係者間で擦り合わせたうえで、起票する。
- 週に1度など、定期的に関係者全員で課題管理表を一通りレビューする。
課題の完了条件を明確化する
前章で述べたとおり、課題管理表の項目として課題の完了条件を設け、各課題に完了条件が明記されていることが望ましいです。
完了条件が定義されていないと、課題に対する完了or未完了の判断が人によって異なり、いつまでも完了できない課題や、まだ対応が必要にも関わらず完了してしまう課題が生じる為です。
基本的に、完了条件は個々の課題ごとに定義しますが、完了条件のベースとなる考え方は、予め関係者と認識をあわせておくとよいでしょう。
例えば、「システムの再テストで同様のバグが再現しないこと」、「課題に対する対応方針が具体的なタスクレベルで明確になり、WBSに反映されること」などのようなイメージです。
このようにベースとなる考え方を事前に定義しておけば、課題が発生する度に、完了条件をチューニングすればよいだけなので、課題発生の都度、ゼロから完了条件を考える必要はなくなります。
課題のボリュームを可視化する
課題の内容は実務担当者のみでなく、プロジェクト責任者やプロジェクトリーダーなど、マネジメント層も関心をもつ内容です。
またマネジメント層は課題の内容だけでなく、課題の規模感も常に気にかけており、通常は、マネジメント層に向けて発行するステータスレポートにも課題数を明記します。
従って、現状の課題のボリュームをいつでも把握できるよう、課題数を可視化しておくことが望ましいです。
また課題を集計する際は、単に何個の課題が発生しているというだけでなく、優先度やステータスなどの軸で課題を分類したうえで、集計・可視化すると分かり易いでしょう。
課題の優先度を定義する
課題にも様々な性質があり、あるマイルストンまでの完了が必須の課題もあれば、マイルストンやローンチに影響せず劣後して問題ない課題もあります。
従って、全ての課題に手あたり次第対応するのでなく、優先度を設定し、優先度が高い課題から対応していくべきです。
優先度の設定基準は様々ありますが、代表的な基準を以下に挙げます。
- プロジェクトの計画（スケジュール、リソース、コスト、スコープなど）に影響するか
- 他のワーキンググループの検討内容に影響するか
- （製品に関する課題の場合）その課題が解消されない場合、顧客からのクレームが想定されるか
上記に当てはまる課題は基本的に優先度が高く、たとえ取っ付きにくい課題であっても、プロジェクトを推進するため優先的な対応が必要になります。
この記事で紹介する内容は以上です。
少しでも参考になれば、幸いです。
