課題管理表の項目・書き方を分かりやすく説明！「Excel無料テンプレート付き」

どのようなプロジェクトであっても、課題管理表は作成していることだろう。

課題管理表は、プロジェクトマネージャ（以下、PM）やプロジェクトリーダー（以下、PL）だけでなく、他のプロジェクトメンバーも携わる機会がある。

プロジェクトで発生した課題を放置してしまうと、たちまち炎上プロジェクトに変えてしまう危険性があるため、発生した課題を課題管理表で管理していくことが、プロジェクトの基本だ。

しかしながら、課題管理表が十分に活かされず、課題が放置されてしまうことも珍しくない。

また、会社や部署で決まった課題管理表のフォーマットを使ってはいるものの、各項目の必要性や書き方が分からない人も多いのではないだろうか？

そこで今回は、課題管理表の項目や書き方、運営ルールを紹介していこう。

課題管理表の目的

プロジェクトを進めていると何らかの課題が発生する。

発生した課題に対応せず放置しておくと、後々プロジェクトに致命的な影響を与えることになる。

プロジェクトを1つ経験しただけでも課題管理の重要さを感じる人は多い。

このため、プロジェクト内で課題を共有し、期日までに忘れずに対応することがプロジェクトを成功させる重要な要素になるのだ。

課題管理表の項目と書き方

課題管理表は、会社・部署・プロジェクト毎に管理する項目が異なる。

とはいえ、課題をしっかりと管理していくためには、どの組織でも似たような項目を記載することになるはずだ。

ここでは、課題管理表の項目の例と書き方を紹介しよう。

課題管理番号

文字通り課題を管理する番号。

Excelの場合、ROW関数「=row()」を使用して番号を自動採番しているプロジェクトもあるが、これはオススメしない。

というのも、何らかの事情で行追加や削除をしたときに課題管理番号が変わってしまうからだ。

課題の記述に「課題管理番号の○○を参照」と書いていた場合、番号が変わると混乱してしまうだろう。

課題記入日

課題を初回記入した日。

課題記入者名

課題を登録した人の名前。

課題分類

課題の分類は、プロジェクト開始直後は特に意識することなく書けばいいが、1、2ヶ月後には分類を整理し直した方がいい。

分類をキチンと整理しておけば、第三者も理解しやすく、また課題発生の傾向を分析するときにも有効だからだ。

たとえば、分類Aの課題が多く発生する傾向にあれば、分類Aの業務要件の確定が甘かったり、担当者の知見が不足していたり、技術的な不安材料があったりと、根本的な課題に気づくことができたりする。

タイトル（課題の件名）

タイトルの記載には特に気を配った方がいいだろう。

タイトルが良ければ内容を見るまでもなく、概要を把握できるので体力を消耗しない。

コツとしては、「体言止めにせず、ネガティブな表現にする」こと。

このルールを守れば自然と分かりやすいタイトルになるはずだ。
例）
　✖︎：A画面の利用ユーザーの検討
　◯：A画面の利用ユーザーが決まっていない

課題の詳細

詳細には、どういう問題が発生して、どういう影響があるのかを記載する。

影響はQCDのいずれかの観点で書くと分かりやすいだろう。

例えば。

重要度（影響度）

重要度の設定は、キッチリやろうとするとかなり大変だ。

「進捗が1週間遅延しそうな課題ならば重要度大」というようにルールを決めることもできるが、様々な課題が発生するため、一概にルールを決めることができない。

いや、正確に言うと、課題が発生した都度にルールを見て、設定ができなければルールを見直せばいいのだが、そんなことをしていると時間がいくらあっても足りない。

さらに言えば、「詳細」の欄を見れば影響を具体的に把握できるので、こだわりを持ってルールを決めても意味が無いのだ。

よって、課題の重要度は、担当者/PM/PLの感覚で大中小を決めて良いだろう。

なお、「詳細」の欄をみれば重要度は分かるので、必要のない項目のように感じるかもしれないが、「どれが重要な課題か？」と聞いてくる上位者が多いため、項目として持つことをオススメする。

担当者名

いわゆる、課題のボールを持っている人。

顧客の回答を待つ場合は顧客名を書くが、システム側の担当も決めておくことが重要だ。

誰が問い合わせて、だれが回答をドキュメントに反映させるかを決めておかないと放置される可能性が高い。

対応期日

原則、課題が解決されないとプロジェクトに影響が出る日を書く。

顧客や他部門に対応を依頼する課題の場合、相手の都合を加味した期日にしないと反感を買ってしまうので注意しよう。

対応策

課題の対応策は、「何をアウトプットすれば課題をクローズして良いか」ということを念頭に書く。

具体的に言うと、対応した結果をドキュメントに反映させるまでを対応策とするのだ。こうすることで、課題がクローズされたとしても埋もれてしまうことがない。

課題のステータス

課題の状況。
『未着手/対応中/保留/完了確認/完了』の5つのステータスがあれば問題ない。

対応が完了した課題をすぐに”完了”にすると、フィルタ条件を完了にしてしまうと、社内会議や顧客会議で報告する前に非表示になってしまう。

これを避けるために”完了確認”というステータスがあると便利だろう。

対応完了日

項目名の通り、対応策が完了した日。

あると便利な項目

次に、私の経験上で便利だった項目を紹介しておく。

これらの項目があると便利な反面、課題管理の負荷が増えてしまうこともあるので注意して欲しい。

課題発生フェーズ

要件定義や基本設計など、課題が発生したフェーズ。

課題を記載したフェーズではなく、”発生したフェーズ”を書くこと。

記載したフェーズと発生したフェーズが異なる場合は、「なぜ課題に気づかなかったのか」という分析をすることができ、他の課題に気づいたり、今後のプロジェクトの教訓として活かすことができる。

課題対応フェーズ

基本設計や詳細設計など、課題に対応するフェーズ。

課題の中には、現フェーズでの対応を見送る課題も出てくる。

例えば、開発環境準備の課題の場合、多くは詳細設計フェーズでの対応となるため、基本設計で課題に気づいたとしても優先度を下げて後で対応することも多いだろう。

このような場合に”対応フェーズ”という項目があれば課題を管理しやすくなるはずだ。

不要な項目

次に、課題管理表に必要そうで必要のない項目を紹介する。

現在使っている課題管理表にこれらの項目があれば、非表示にして使わないというのもアリだろう。

緊急度

緊急度は、”対応期日”があれば必要の無い項目である。

対応期日が近いものが、緊急度が高い課題なるため、わざわざ”緊急度”という項目を持つ必要はない。

優先度

これも重要度や対応期日があれば必要の無い項目である。

優先度は、状況によってコロコロ変わることも多く、課題管理の手間を増やしてしまいがちだ。

対応策の実施結果

対応策を実施した結果を記載する項目だが、この欄は「対応策の通りに実施し、問題なく完了した」という内容になりがちである。

というのも、対応策を実施した結果、うまくいかなかった場合は、対応策欄を修正するため、「対応策の結果」という欄を用いることがないのだ。

課題管理表は、組織で実績のあるものを使うのが無難だが、これまで説明した項目を取捨選択してみるのも良いだろう。

Excelテンプレート

課題管理表のサンプルとして、Excelテンプレートを用意した。

無料でダウンロードできるので、ぜひ参考にしてほしい。

あなたの部署のテンプレートや、プロジェクトの特性に応じてカスタマイズしてもらえればと思う。

>> 課題管理表のExcelテンプレートをダウンロードする

なお、別記事では、WBSのテンプレートも用意しているので参考にしていただけると嬉しい。

WBSの作り方と注意点〜現役PMが説明「Excelテンプレート付き」

次に、課題管理表の運営ルールを紹介しておこう。

課題管理表で1番マズいのは『課題が書かれないこと』

課題管理で最も避けなければならないのは、課題が書かれないことである。

課題が無いプロジェクトはほぼ無いと言ってもいいのだが、ありがちなのは、課題を認識しているにも関わらず、課題管理表に課題が上がらないケースだ。

例えば、メンバーの一人が「◯◯機能の不備を見つけました」とPMに口頭で伝え、一時的にヤバいと話題になったものの、他の作業に追われて忘れられてしまうケースである。

また、メンバーが自分の担当外の課題に気づいた場合でも、その課題が誰とも共有されずにメンバーの心の中で閉じてしまうケースもある。

なぜこのようなことが起こるのか？

それは課題管理の運営ルールに問題があるからだ。

課題管理の運営ルールに問題があるプロジェクト例

実際の現場である例をいくつかあげてみよう。

①課題を書く人が決まっているプロジェクト

現場でよく目にするダメな例の1つ。

PMやPLなどの決まった人しか課題管理表を書かないプロジェクトだ。

他のメンバーは課題を認識しても「自分の仕事ではない」あるいは「勝手に書くと怒られる」と考えて課題管理表に手をつけなくなってしまう。

課題管理表は課題に気づいた人が書くのが鉄則だ。

課題をたくさん書いた人「すごい！」と称えるようなムードが良いだろう。

②課題を書いた人を『対応担当者』にするプロジェクト

こちらもたまに見かけるダメなプロジェクト。

例えば、自分の担当外の課題に気づいたとしても、自分が課題の対応担当者になってしまうことを恐れて課題に書かないケースがある。

これを避けるには、前述したように課題を書いた人にお礼を伝える雰囲気作りや、PMが担当者の負荷バランスを加味して対応担当者を決めるルールにすると良いだろう。

③課題を書いた人を非難するプロジェクト

意外に多く見られるのが、課題を書いた人を非難するプロジェクト。

「課題を書くのが遅い」
「書いている意味が分からない」
「これは課題ではなく、リスクだ」
「これは課題ではなく、ただのメモだ」

挙げるとキリがないが、実際の現場で頻繁に見かける。

このような批判をされると課題管理表に書く気がしなくなるもの当然だ。

課題を書いた人にお礼を言う雰囲気に加えて、PMやPLがメンバーの書いた課題管理表を分かりやすいように修正してあげるようなサポートがあると良いだろう。

これらを踏まえて課題管理表の運営ルール例を紹介しよう。

課題管理表の運営ルール例

繰り返しになるが、課題管理表で最も避けなければならないことは、課題が書かれないことである。

それを避けるためには、とにかく課題を書いてもらう必要がある。

特に、前述したような課題管理表を書くことにデメリットがあるプロジェクトは絶対に避けたい。

このため、プロジェクト開始時には、下記のような内容をメンバーに伝えるようにしよう。

ここではサンプルとして、メール連絡をイメージして書いてみた。

メールではごちゃごちゃ書いているが、運営ルールとしては下記だけだ。

当たり前のようなことしか書いていないが、課題管理表を運営していく上では欠かせないことなので、参考にして欲しい。

さいごに

課題管理表の項目や書き方を説明してきた。

課題管理はプロジェクトの成功を左右する重要な作業であり、課題管理のツールとして、課題管理表を共有/更新するのが一般的だ。

しかしながら、課題管理表がキチンと管理されずに後々になって致命的になってしまうプロジェクトは珍しくない。

PM/PLだけでなく、プロジェクト関係者全員が課題を認識し、解決に向かって行動できるように課題管理表を利用して欲しい。

そうすれば、プロジェクトを成功にむかって推し進めることができるはずだ

この記事が参考になれば幸いである。