プロジェクトの課題はなぜ減らないのか？｜課題を減らすアクション×８選

どのプロジェクトの現場でも課題は発生する。
そして、「課題管理」は必ず行われている。

課題を課題管理表に記載し、担当者を決め、対応状況を可視化し、解決していく――
プロジェクト経験者であれば、誰もが経験したことがあるだろう。

しかし現実はどうだろうか。
課題管理表を真面目に運用しているはずなのに、課題は減るどころか増え続ける。
毎週の定例会では新しい課題が報告され、古い課題は「継続」「検討中」のまま残り続ける・・・

本記事では、この「課題はなぜ減らないのか？」という根本的な問いに正面から向き合い、課題とは何か、なぜ増殖するのか、どうすれば減らせるのかを、実務ですぐに使えるアクションアイテムとして紹介する。

また、感覚論や精神論ではなく、プロジェクトマネジメント標準であるPMBOKの考え方も踏まえた手法と、課題管理を効率良く行うためのツールも紹介する。

減らない課題に悩んでいるPM／PMOにとって、本記事は参考になる情報を多く含んでいるはずだ。
是非最後まで読んでいただき、効率的な課題管理の役に立てていただきたい。

間違いだらけの課題管理

課題管理表が増殖する本当の理由

課題管理表の課題がすぐに増えてしまう最大の原因は、そもそも課題ではないものまで課題として登録している点にある。

多くのプロジェクトでは、

• 困ったこと
• あとでやるべき作業
• なんとなく不安なこと

までもが、安易に課題管理表へ放り込まれる。

これらが無差別に課題管理表へ登録されると、課題は雪だるま式に増えていく。
その結果、課題管理表は次第に肥大化し、本来の役割を果たせなくなる。

課題管理表は「非常ベル」である

課題とは、プロジェクトにとっての火事である。
課題管理表は、その火事を関係者に知らせるための非常ベルだ。

• 重大な危険をいち早く知らせる
• 適切な担当者を消火（解決）に向かわせる
• プロジェクト全体への影響を最小化する

これが本来の役割である。

しかし、課題ではないものまで登録してしまえばどうなるか？

非常ベルは常に鳴りっぱなしになり、本当の火災に誰も気づかなくなる。
その結果、火炎は消されることなく、いつまでも燃え続ける。

最悪の運用例：To-Doを課題として扱う

課題管理が破綻しているプロジェクトによく見られるケースに、
「あとでやるべきこと」
すなわち「To-Do」を課題管理表に混在させて管理するケースだ。

• 資料を作成する
• 会議を設定する
• 質問に答える

これらは課題ではない。
単なる作業であり、タスクだ。

それ課題管理表に書いておいて

課題管理表を備忘録のように使い始めた瞬間、そのプロジェクトは「減ることのない課題の沼」に足を踏み入れている。

そもそも課題とは何か

課題が増えるプロジェクトの共通点

課題が増え続けるプロジェクトでは、例外なく課題の定義が曖昧である。
「課題とは何か？」がチーム内で共有されていない。

課題・リスク・To-Do・心配事の違い

まずは、課題・リスク・To-Do・メモ・心配事 を明確に分けておく必要がある。

区分	内容	適切な登録先
課題 (Issue)	すでに顕在化しており、プロジェクトのQCDに悪影響を与えているもの。解決策の検討や意思決定が必要。	「課題管理」表
リスク (Risk)	将来発生する可能性があり、起きた場合にQCDへ影響を与える不確定要素。発生前なので監視・対応計画が中心。	❌別途「リスク管理表」で管理
To-Do／タスク	個人やチームが行えば解決する作業。大きな意思決定を伴わない。	❌ 課題管理表には載せない（タスク管理ツールで管理）
メモ/情報	知識共有や注意喚起レベル。問題化していない。	❌ Wikiや議事録に記録
心配事	リスクよりも緩い、漠然とした不安や悩み。	そもそも管理対象外

これらを混在させてはいけない。

課題はQCDに影響するものだけ

PMBOKでは、課題（Issue）とはプロジェクト目標に影響を及ぼす問題として扱われる。
つまり、QCD（Quality・Cost・Delivery）に影響があるものだけが課題である。

• 品質が落ちるのか
• コストが膨らむのか
• 納期が遅れるのか

これらに該当しないものは、課題ではない。

課題を登録する前に、必ず以下を問うてほしい。

答えられなければ、それは課題ではない。

課題対応の優先順位を決める

課題にも「大小」がある

火事にも、大火事から小火まである。
課題も同じだ。

すべての課題を同じ重さで扱ってはいけない。
リソースは有限であり、大きな課題から潰す必要がある。

主観で判断しない

どのプロジェクトでも、課題には「重さ」や「優先順位」を付けて管理しているはずだ。

しかし危険なのは、課題の優先順位を声の大きい人の意見に迎合して決めることだ。

• 上司が気にしているから重要
• 強く主張されたから優先
• なんとなくヤバそう

こうした感覚的な判断は、本当に優先的に対処すべき課題を隠してしまう。

課題の重さや解決の優先順位を判断する基準は、「人の意見」ではなく「QCDへの影響の大きさ」でなくてはならない。

「どのくらい」が主観を排除する

その課題は、Ｑ・Ｃ・Ｄのどれに、どのくらい影響するのか？
影響度を数値化する。

「なんとなくヤバそう」
「たぶん影響あると思う」

といった主観に振り回されないためにも、数字で語るのが有効だ。
議論もスムーズになるし、優先順位もはっきりする。

以下は、QCDを定性的に評価した場合と、定量的に評価した場合の違いである。

定性的評価の例	定量的評価の例
Q：品質にちょっと不安がある C：アドオン化すると予算をオーバーする D：その機能をスコープインさせると納期が遅れる	Q：テストケース100件中、バグが20件発生している C：アドオン化すると、予算が400万円超過する D：その機能をスコープインさせると、納期が3ヶ月遅延する

定量的に見てみると、
「え、それってそこまで重大だったの？」
と気づくことがある。

逆に、誰かが「これは絶対ヤバい！」と騒いでいても、数値で見てみると
「いや、そこまででもないな。今は後回しでいい」
と冷静に判断できることもある。

要は、感覚だけで動くと判断を誤るが、数字で判断すれば正しい判断ができるという話だ。

基準を明確にしておく

QCDへの影響を考える際、以下のような判断基準を設けておくと整理が進む。

影響度基準

• 工程遅延見込みが 3日以上
• コスト増が 30万円以上
• 品質への影響が ユーザ受入テスト以降の工程に及ぶ場合

決定レベル基準

• PM/PL以上の判断 が必要なもの
• 複数のSAPモジュール／部署／ベンダに跨る調整が必要なもの

進行障害基準

• 放置すると工程が進まない
• 依存関係のある後続のタスクが止まってしまう

QCD、特にD（納期）で優先度を決める

課題の優先順位を決めるのに特に有効なのは、次フェーズに進めるかどうか、という観点だ。

特に、QCDの「D（工程）」に影響を与えるかどうかの判断が重要だ。

工程が遅れれば、Q（品質・仕様）を達成する余裕はなくなり、
工程が遅れれば、C（コスト）は結果的に悪化する。
このように、Dの悪化はQとCにも影響を及ぼす。

次フェーズに進めるかどうかの観点からの「重さ」は、以下の3段階で分類しておけば十分である。

課題の放置を防ぐ！アクション × 8選

以下は、「課題を放置させないために、すぐに実践可能なアクション」の8選である。
言い換えれば、これらができていないプロジェクトでは、課題の放置が起きやすくなっているはずだ。
自分達のプロジェクトではどうか、ぜひチェックしてみてほしい。

アクション① 課題をシンプルに言語化する

課題管理表に書く課題は、「何が起きており、何が問題なのか」をシンプルに書くようにする。

課題が曖昧だと、何をすれば解決できるのか判断できず、誰も動けない。
つまり、放置されがちな課題の多くは、「そもそも何が課題なのかよくわからない」という、曖昧な内容になっている。

曖昧な課題とは、たとえば次のような書き方だ。

このように、「何が起きているか（事実）」と「それがQCDのどこにどう影響しているか」を書くと、課題が明確になり、解決のアクションもとりやすくなる。

アクション② QCDへの影響を明示する

書かれている課題は、Ｑ：品質・C：コスト・D：納期 のどれに、どの程度影響するのか。
これを定量的に説明できない課題は、そもそも課題ではない。

課題管理表には、「QCDへの影響度」を定量的に書き込むための入力欄を作っておくとよい。

アクション③ 担当者を一人に決める

課題の担当者には、必ず一人の責任者（Responsibility）を任命し、課題管理表にはその人の名前を明記するようにする。

ありがちなミスが、「〇〇チーム」といった形で”チーム全体”を担当者にしてしまうことだ。
「〇〇チームの誰かさん」という曖昧なアサインメントが習慣化すると、〇〇チームの誰も本気で動かない。

これは「綱引き効果（リンゲルマン効果）」と呼ばれる心理現象によるもので、集団で作業をする場面では「誰かがやるだろう」と思ってしまい、結果として一人ひとりの努力や貢献度が下がってしまう。いわゆる“社会的手抜き”というやつが起きる。

この綱引き効果を防ぐには、「集団ではなく個人を指名する」のが最も効果的とされている。

課題管理表においても、課題を解決する「個人」を明確に記載しておくことが重要だ。

アクション④ 期限を設定する

期限のない課題、すわなち「そのうちやろう」という状態では、課題はいつまで経っても解決されない。
完了日を明確にすることが、行動を生む。

人を動かす原動力は「期限」である。

アクション⑤ 課題はひとつだけ

ひとつの課題に、複数の内容を詰め込んではいけない。
課題管理表でいえば、1行に書いていい課題は、ひとつだけだ。

一度に複数の課題を書いてしまうと、結局何が本当の課題なのかがわかりにくくなる。
さらに、書かれているすべての課題を解決しない限りクローズできないため、課題がいつまでも残っているように見えてしまう。

また、複数の課題のままでは、一人の担当者に過剰な負担をかけることになり、効率も悪い。

複数の課題は、ひとつひとつの課題に分解することで、何が問題なのかが明確になる。
さらに、それぞれの課題に担当者を割り当てれば、解決までのスピードも格段に上がる。

アクション⑥ 定例で必ずレビューする

課題があること自体は、決して問題ではない。
プロジェクトを進めていれば、課題は必ず発生するものであり、それが見えているということは、むしろ健全にプロジェクトが運営されている証拠でもある。

本当に問題なのは、「課題が放置される」状態だ。

放置課題としないためには、定例会などの場で「課題解決の進捗」を必ず確認する仕組み（残課題を棚卸しする場）を作っておく。

アクション⑦ 完了条件を明確にしておく

その課題は、何をもって「解決」とするのか。
解決したことを判断できる人物は「誰」なのか。

これらが曖昧な課題は、いつまでもクローズできない。

課題管理表に登録する時点で「完了条件」を決めておく。

アクション⑧ 別の場所を用意しておく

課題管理表を見ていると、明らかに「これ、課題じゃないよね？」という内容が紛れ込んでいることがある。
たとえば、ちょっとした備忘メモや、ただのToDo、誰かの気づきのようなものだ。

こうしたものが混在している理由をメンバーに聞いてみると、よく返ってくるのがこの一言。

記録する場所がなかったから

なるほど、その気持ちはよくわかる。
でも、課題と課題でないものが同じリストに入ってしまうと、本当に対応すべき課題が埋もれてしまうリスクがある。

QCDに影響しないけれど、残しておきたい気づきやタスクについては、「パーキングロット」や「備忘メモ」といった別の枠組みを用意しておくのがおすすめだ。

課題は課題、メモはメモ。
管理の場所を分けることで、一貫性と運用効率はぐっと上がる。

Excelではなく課題管理ツールを使おう

なぜExcel課題管理は破綻するのか

プロジェクトの課題管理は、「とりあえずExcelでやろう」となりがちだ。
Excelは誰でも使えるし、自由度も高い。だからこそ「これで十分」と思ってしまう。

しかし、プロジェクトが進むにつれ、だんだんと扱いづらくなってくる。
その結果、Excelでの課題管理は早晩破綻する。その理由は以下の通りだ。

同時編集に弱い

複数人で同時に編集しようとすると、ファイルが書込みロックされたり、最新の状態がわからなくなったりする。
プロジェクトメンバーが数人ならまだしも、数十人規模の体制ではかなり厳しい。

履歴管理がめんどう

Excelには「この課題にどんなやりとりがあったか？」という履歴を残す仕組みがない。
毎回コメント欄を増やしたり、変更日や担当者を手入力したりと、自分たちで運用ルールを整えないといけない。
たとえルールを整えたとしても、こうしたルールは往々にして守られない。

担当者・期限が曖昧になりやすい

課題管理に不可欠な「担当者」や「期限」などの項目を用意しても、入力を省略できてしまうのがExcelの弱点だ。
記入漏れが発生しやすく、誰がいつまでにやるのか、不明確になりがちだ。

ステータスを追いにくい

「この課題って、もう終わったの？」「誰が対応してるの？」「まだ保留中のまま？」
こんな会話が日常的に飛び交うのが、Excel課題管理の“あるある”である。
完了・未完了の記載ミスや更新漏れが起きやすく、未解決なのに勝手にクローズされるという事態も起きてしまう。
要するに、ステータスや進捗を把握するのに手間がかかる。

情報共有に向いていない

Excelにはワークフローや通知の仕組みがない。
課題が更新されたことを誰にも知らせず、関係者が気づかないまま放置される、というのはよくある話だ。
「その課題、私が担当だったの？」といった根本的な認識ズレも珍しくない。
これらを防ぐには、連絡手段や運用ルールを別で決めておく必要があるが、なかなか煩雑である。

そして、課題は放置される

こういったExcel課題管理の“弱点”が積み重なると、どうなるか？

• 課題が放置される
• 担当が不明なまま
• 解決済みかどうかもわからない
• 気づいたら、未解決の課題が山のように…

つまり、「課題が管理されていない課題管理表」が出来上がってしまうのだ。

「餅は餅屋」課題管理ツールを使うべし

課題管理には、課題管理が得意なツールを使うべきである。

• asana
• Jooto
• Redmine
• Stock

いずれも課題やタスクを効率良く管理する前提で設計されている。

課題の放置を防ぐ！アクション×8選 で指摘した「担当者」「期限」などの必須管理項目についても、強制的に入力させることが可能だ。

Redmineとは

Redmineの特長

「Redmine」は、オープンソースの課題管理ツールである。

課題を「チケット」として管理し、チケット単位に担当者・期限・進捗を設定することで、課題の状態（未着手／着手／解決済みなど）を可視化・追跡できる。

オープンソースなので基本的に無料であり、Linuxサーバに自分でインストールして使うのが一般的であるが、最近はクラウド型のサブスクサービスとして展開しているプロバイダも存在するので、課金すればすぐに利用開始できる。

Redmineが課題管理に向いている理由

Redmineはプロジェクト管理ツールとしての機能も備えているが、課題管理にこそ威力を発揮するツールだと言える。

そう考える最大の理由は、Redmineが備えるワークフロー機能だ。
課題チケットに担当者を割り当てると、自動でメール通知が送信される。

つまり、課題をチケットとして登録した瞬間に、
「あなたはこの課題を解決する担当者に任命されました。着手してください」
というメールが、任命された担当者に自動送信される。

この仕組みによって、
「聞いてないよ！」
という認識齟齬を、ほぼ完全に防止できる。

これはExcelでは決して実現できない。

また、通知機能はワークフローと連動しているので、課題の状態、たとえば「未着手」「着手」「完了」という課題への対処進捗を可視化できる。

さらに、項目の入力できる・できないを担当者別に制御できるので、「課題を勝手にクローズ」するという誤操作も防止できる。

このように、課題の放置を構造的に防止できる点が、Redmine最大の強みである。

課題管理の仕組みは最初に決めておく

課題管理のやり方は、プロジェクトの立ち上げ段階で決めておくのが鉄則である。

• 課題管理とTo-Doを混在させない運用
• QCDに影響のある事象のみを課題とする方針を徹底させる
• Excel課題管理から、課題管理ツールへの変更

こういったことを、運用が始まってから方向転換しようとすると、想像以上に大変だ。

• 過去の記録を整理し直す手間
• メンバーへの説明と再教育
• ツール変更に伴うデータ移行の手間、メンバの混乱や抵抗

これらが一気にのしかかってくる。

だからこそ、最初の段階でルールをしっかり決めておくことが重要だ。

まとめ｜課題管理の本質

究極的に言えば、課題管理に必要な要素は3つしかない。

この3点が揃わない課題は、解決できないどころか、そもそも「課題」として成立していない。

ピーター・ドラッカーは次のような言葉を残している。

重要なことは、正しい答えを見つけることではない。 正しい問いを探すことである。

課題管理も同じだ。
課題を正しく定義できれば、その裏返しはそのまま解決策になる。

そして、何より重要なのは、課題解決を他人任せにしないという姿勢だ。
この心構えこそが、課題の増殖を抑え、課題解決を加速させ、プロジェクトを成功へ導く原動力となる。

本記事で紹介した方法論やアクションアイテムが、課題管理のやり方を見直すきっかけになれば幸いである。