タスクの無間地獄に落ちない、課題管理のコツ【テンプレートあり】

今回のテーマは「課題管理」

　プロジェクトマネジメントのいち分野に「課題管理」と呼ばれるものがあります。特にIT開発プロジェクトの現場では、きっと多くの人が課題管理をしたり、されたりという経験があることでしょう。

　しかし、ひとくちに課題管理といっても、そのやり方や実体は千差万別です。現場によって、とても有効な課題管理がされている場合もあれば、ToDo管理やWBSとごちゃごちゃになってしまい、なんだかよくわからない課題管理になってしまう、という場合もあります。

課題管理における、よくある悩み

　例えば、課題管理のなかで、こんなお悩みはないでしょうか。

WBSで書いている内容と課題管理で書いている内容がダブってしまい、二重管理のようになってしまう

課題管理表に担当者や期日を記載して、ちゃんと管理しているつもりなのに、期限を守ってもらえない

課題の数が膨大になってしまい、全体像がよくわからなくなる

物理的に対応可能な量を超えてしまい、優先順位をつけざるを得なくなる

永遠に消化されない課題が、根雪のように溜まっていく

　こうした悩みがあるとしたら、その現場は、課題管理の本来の目的や意味を、そして適切なやり方を、見失っています。

課題管理は、プロジェクトワークにおけるリーダーシップの具現化

　「社会課題」とか「経営課題」とか「課題解決」とか、なんだか気づけば、社会のあちこちで「課題」という言葉が使われています。プロジェクトワークそのものが、社会や現場における課題を解消するために組成されるものだったりします。
　社会に「課題」という言葉が出回りすぎたせいで、なんでもかんでもとりあえず、問題になりそうなものを「課題」と呼べばそれでいい、という雰囲気があります。

　プロジェクトワークにおいて「課題」という言葉を、なんとなく雰囲気で使うことは、自殺行為に等しいといえます。

　なぜか。

　そもそもプロジェクトとは「無限に発生する問題や要望に対して、有限の資源を用いてこれを解決すること」だからです。

　プロジェクトワークでは、誰かが誰かにやってほしいことは、無限に発生します。「あれも、これも」の世界です。

　しかし、当然ながら、それらに対処するための人間、時間、お金や知識、ノウハウといった資源は、有限です。有限の資源で、無限の結果を出すことは、誰が考えたって、不可能に決まっています。

　プロジェクトとは、「あれも、これも」式に、無限に広がる風呂敷を、誰かが広げることから始まるわけですが、それを閉じるためには誰かが「あれか、これか」という選択を突きつけなければなりません。つまり「本当に実現したいことは、なんですか」「そのためなら、実現を諦めることはなんですか」という視点がなければいけないのです。

　例えば、以下のような整理こそが「課題管理」の観点として、筆者がオススメしたい、まさにベスト・プラクティスと呼びたいものです。

項目	内容
課題の発見	いつ、誰が課題として認識したか
課題の内容	課題が発生している領域 課題の種類（技術的or人的　等） 影響範囲（誰に影響するか、どの程度影響するか） 対処に必要な資源（時間、お金、技術） 対処の難易度
原因区分（責任区分）	当初交わした契約に照らし合わせて位置づけを明確にする （仕様の追加や変更 or スコープの変更 or ミス等）
対応方針	そもそも課題として正式に認定して着手するかどうか いつまでに、どのように対処方針を決めるのか いつまでに解決したいか 対応する選択肢はどの程度あるか 誰がその課題解決をリードするのか
対応方法	取りうる選択肢 各選択肢のメリットとデメリット 各選択肢の成功確率
対応ステータスと結果	着手したかどうか 解決したかどうか 解決した結果をしかるべき手続きで確認したかどうか

　ポイントは、以下の通りです。

●関係者であれば誰だって、「これは課題ではないですか」と発言することができる
●ただし、それをそのまま、そのプロジェクトにおける正式な課題と認定するわけではない
●認定にあたっては、どんな領域で、どんな課題が発生しているのか、影響範囲や原因などを精査する
●解決方法も、闇雲に立案するのではなく、複数の選択肢を列挙したうえで、メリット・デメリットを吟味する

　なんとなく発生した課題を、なんとなく台帳に書いて、なんとなく連絡だけしておく、といったことでは、課題（らしきもの）が雪だるま式に膨れ上がるだけで、なにも解決しません。

　このプロジェクトで、実現したいものはなにか。

　本当に譲れないものは、なにか。

　それと引き換えに、諦めることができるものはあるか。

　そのようなシビアな検討ができて、初めて、課題管理をすることに、意味が生じます。こうした問いを関係各位に提示することは、勇気が必要です。勇気を持って、物を申すことこそが、プロジェクトワークにおいて、あるべきリーダーシップのありようです。

キーワードは「ノックアウト・ファクター」

　勇気を持って物申せ、とはいいましたが、やたらめったらに発言すればよい、ということではありません。蛮勇と勇気は別物です。適切な観点を持てば、物申すための勇気に、胆力は不要です。

　どういうことか。要するに、そのプロジェクトを進めていくなかで「これが起きたらオシマイだ」というような、いわゆる致命的な問題が発生しないように、先を読みましょう、ということです。そのプロジェクトを進めていくなかで「これが起きたらオシマイだ」というような、いわゆる致命的な問題のことを、プロジェクトマネジメント用語で「ノックアウト・ファクター」と呼びます。

「負荷試験で耐えられなかったら、後々の大問題につながる」
「スキルレベルの高いエンジニアを確保しないと、絶対に納期に間に合わない」
「決裁者の機嫌を損ねたら、そこで話が終わってしまう」

　などなど、ノックアウト・ファクターは、プロジェクトによっていろいろなパターンがあります。進捗やフェーズによっても、そのた外部環境からの影響によっても、変わっていきます。
　絶対に、押さえておかないといけないのが、ノックアウト・ファクターです。しかし、ウナギのように、ぬるりと逃げてしまい、とらえどころがないのが、ノックアウト・ファクターです。

　どうすれば、ノックアウト・ファクターを見抜くことができるのか。以下の３つの観点を、ご参考ください。

テンプレートはこちらから！

　プロジェクトワークは、「これが起きたらオシマイだ」ということを見抜けるかどうかが、生死をわけます。これが見抜けるようになると、プロジェクト運営は、とても楽になります。課題管理とは、まさにプロジェクトを楽にするために、することです。

　「あれも、これも」式の、課題の無限列車に押しつぶされそうになったら、ぜひ、ノックアウト・ファクターを考える３つの観点を思い出してみてください。

　また、本文でお話しした課題管理を、実際に業務に落とし込むためのテンプレートを配布しています。

　下記のリンクより、ダウンロードください。

https://www.gotolab.co.jp/wp-content/uploads/2025/06/IssueManagement_gotolabSpecialTemplate.xlsx

本テンプレートの利用にあたりまして

●原則として、本テンプレートは無償で、自由にご利用いただけます。ただし、本テンプレートの販売や改変したものの再配布など、営利目的での無許可での利用は禁止します。