---
title: "プロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方"
url: "https://www.issoh.co.jp/column/details/11042/"
published: 2026-02-18
updated: 2026-10-25
categories: ["ビジネス理論・用語"]
publisher: "株式会社一創"
---

# プロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方

プロジェクト管理とタスク管理は、どちらも「仕事を期限どおりに終わらせるための管理」なので混同されがちです。違いは管理する対象の大きさだけではありません。プロジェクト管理は**期限のある取り組み全体を、計画と照らし合わせて統制する仕事**で、タスク管理は**個々の作業の担当・期限・状態を回す仕事**です。前者は「計画どおりに進んでいるか」を問い、後者は「この作業は今どこまで進んだか」を問います。

この記事では、PMI（米国プロジェクトマネジメント協会）のPMBOKガイドとISO 21502の定義から両者を切り分け、ToDo管理・課題管理との違い、タスク管理の進め方、WBSでのつなぎ方、ツール上の階層、どちらが必要かの判断基準を整理します。

## まとめ：プロジェクト管理とタスク管理の違いの要点

- プロジェクト管理の対象は**有期の取り組み全体**（範囲・期間・コスト・リスク・関係者）。タスク管理の対象は**担当者が実行する個々の作業**です。PMBOKガイド第8版では、プロジェクトの定義が「価値を創出する」取り組みへ書き換わっています。
- ToDoリストもタスク管理の手段です。書き出すだけでなく担当・期限・状態を管理すると、作業の進み具合を共有できます。課題管理が扱うのは作業ではなく、すでに起きていて目標に影響する問題です。
- タスク管理は、洗い出す、数日で終わる大きさに分ける、担当と期限を決める、後続への影響で優先順位を付ける、状態を更新して週ごとに見直す、の順で回します。
- 両者をつなぐ単位として使いやすいのが**WBSの最下位であるワーク・パッケージ**です。ワーク・パッケージを計画の単位にし、担当者がそれをタスクに分けて状態を更新すると、全体の計画と日々の作業を結び付けられます。
- 有期の仕事で、担当者どうしの作業に前後関係がある、または範囲や予算の変更を誰かが判断する必要があるなら、タスク管理の上にプロジェクト管理の層を足すのが目安です。毎月繰り返す定常業務はプロジェクトではないので、WBSで計画を組む必要はありません。

## プロジェクト管理とタスク管理の定義の違い

### プロジェクト管理の定義と全体統制の範囲

PMIは長く、プロジェクトを「独自のプロダクト、サービス、所産を創造するために実施される有期的な業務（a temporary endeavor undertaken to create a unique product, service, or result）」と定義してきました。PMIの公式サイトの解説ページ「[What is a Project?](https://www.pmi.org/about/what-is-a-project)」は、2026年10月時点でもこの文言を掲げています。

2025年11月に英語版が発行されたPMBOKガイド第8版では、この定義が書き換わりました。PMIが2026年7月から適用する[PMP試験内容概要（Examination Content Outline）](https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf)は、PMBOKガイドの定義として「価値を創出するために、固有の文脈で実施される一時的な取り組み（a temporary initiative in a unique context undertaken to create value）」を挙げています（日本語は筆者訳）。作るものの種類から、生み出す価値へと重心が移った形です。

新旧どちらの定義でも、核にあるのは「一時的（有期）」と「独自・固有」の2点です。始まりと終わりがあり、毎回条件が違う仕事だからこそ、事前に計画を立て、計画との差を見て手を打つ管理が要ります。

国際規格の[ISO 21502:2020](https://www.iso.org/standard/74947.html)も、用語の定義（3.20と3.24）で、プロジェクトを「一つ以上の定義された目標を達成するための一時的な取り組み」、プロジェクトマネジメントを「合意された目標の達成を指揮・統制するための調整された活動」としています（日本語は筆者訳）。プロジェクト管理とは、目標と計画を先に合意し、その達成を指揮・統制する活動だと押さえておけば十分です。

対になるのがオペレーション（定常業務）です。PMIのポートフォリオマネジメント標準（第3版）は、オペレーション管理の対象を「継続的で、多くの場合は循環的な組織の活動」としています。月次の請求処理や問い合わせ対応のように終わりのない仕事は、WBSで範囲を区切って完了を目指すプロジェクトの枠組みには乗りません。

第8版の日本語版は、[PMI日本支部](https://www.pmi-japan.org/pmistandard/)によると、2026年4月にPMI会員向けのデジタル先行版PDFがリリースされています。社内の研修資料が第7版以前の定義を引いている場合は、版を明記しておきます。

### タスク管理の対象：個々の作業の担当・期限・状態

タスク管理とは、個々の作業について「誰が・いつまでに・何をするか」を決め、未着手・進行中・完了といった状態を追いかけることです。タスクマネジメントも同じ意味で使われます。PMIの用語でいちばん近いのはアクティビティ（activity）で、PMIの用語集（PMI Lexicon）は「明確に区別され、スケジュールされた作業部分」と定義しています。

タスク管理はプロジェクトの中だけで使うものではありません。定常業務の処理も、個人の仕事の整理も、作業を書き出して状態を追う点では同じタスク管理です。

### プロジェクト管理とタスク管理の比較表

| 観点       | プロジェクト管理          | タスク管理        |
| -------- | ----------------- | ------------ |
| 管理する対象   | 範囲・期間・コスト・リスク・関係者 | 個々の作業        |
| 答える問い    | 計画どおりに進んでいるか      | この作業は今どこまでか  |
| 見る範囲     | 全体の予定・作業の前後関係     | 個々の作業の期限と状態  |
| 主に見る人    | PM・発注者・経営層        | 担当者・チームリーダー  |
| 終わり      | 成果物の受け入れ          | 作業の完了        |
| 主な道具     | WBS・ガントチャート・課題管理表 | ToDoリスト・カンバン |
| 定常業務での要否 | 不要                | 必要           |

表の「答える問い」の行は、ステータスの一覧だけでは遅れが見えない理由を示しています。タスクがすべて「進行中」でも、プロジェクトとしては遅れていることがあります。たとえば予定では今週中に結合テストに入るはずなのに、設計の作業がまだ進行中であれば、ステータスだけを見ている限り異常は見えなくてもプロジェクトは遅延しています。この差は、計画（ベースライン）や後続作業の予定日と比べる層を持たない限り見えません。

## タスク管理とToDo管理・課題管理の違い

### ToDo管理とタスク管理の重なりと運用上の区別

ToDo管理とタスク管理は重なる部分の大きい言葉です。[Microsoft To Do](https://support.microsoft.com/ja-jp/outlook/create-and-manage-task-lists-with-my-day-in-outlook)のように、期限の設定やリストを共有した相手への割り当て、完了の記録ができるToDoアプリもあります。違いは道具の名前ではなく運用にあります。この記事では、用件を書き出して終わったら消すだけの運用をToDo管理、一つひとつに担当者・期限・状態を持たせ、ほかの人が見ても進み具合が分かる形にする運用をタスク管理と呼び分けます。同じ「見積書を送る」でも、メモ帳に書いただけならToDo、担当者と期日を決めて「処理中」と表示されていればタスクです。

この違いは、作業を他人と共有するかどうかで効いてきます。個人の用件だけならToDoリストで足ります。他の人に引き継ぐ、遅れを誰かに知らせる、といった必要が出た時点で、担当・期限・状態の3項目を足してタスク管理へ切り替えます。個人の頭の中にある用件を書き出して整理する方法としては、[GTD（Getting Things Done）の5ステップ](/column/details/9809/)がよく知られています。

### 課題管理とタスク管理の対象・対応関係の違い

プロジェクトの「課題管理」は、タスク管理と名前が似ていますが、扱う対象が違います。PMI Lexiconは課題（issue）を、目標に影響を与えうる「現在の状態または状況（a current condition or situation）」と定義しています。まだ起きていない問題はリスク（risk）で、発生すればプロジェクトなどの目標にプラスまたはマイナスの影響を与える「不確実な事象または状態（an uncertain event or condition）」として別に定義されています（日本語は筆者訳）。

つまり、タスクは「やる作業」、課題は「すでに起きていて片付けないと目標に響く問題」、リスクは「発生すると目標にプラスまたはマイナスの影響を与える、不確実な事象や状態」です。たとえば「テスト環境が先方の都合で2週間使えない」は課題で、その対応として「代替環境の見積もりを取る」「先方と日程を再調整する」がタスクになります。課題1件から複数のタスクが生まれ、課題が解決したかどうかはタスクの完了とは別に判断します。

Backlogのように作業も問題も同じ「課題」の器に入れるツールでは、種別やカテゴリで「作業」と「問題」を分けておかないと、問題の未解決件数がタスクの山に埋もれます。システム開発で課題・リスクをどう回すかは[システム開発のプロジェクト管理の進め方](/column/details/15670/)で扱っています。

## タスク管理の進め方5ステップ

タスク管理は、次の5つの手順で回します。重要なのは2と4で、ここを飛ばすとリストが長くなるだけで遅れは見えません。

1. **作業を洗い出す**：依頼・会議の決定事項・自分の気付きを、1か所のリストかボードに集めます。メール・チャット・手帳に散らばったままだと、どれが残っているか分からなくなります。
2. **数日で終わる大きさに分ける**：「設計」「資料作成」のような大きな単位のまま登録すると、何週間も「進行中」のまま動きません。1件は数日以内に終わる大きさにし、完了の条件（何ができたら終わりか）を1行で書きます。
3. **担当者と期限を決める**：担当者は1人にします。共同作業でも、進捗更新と完了確認の責任者を1人決め、協力者とは役割を分けます。期限は「いつか」でなく日付で入れます。
4. **後続への影響で優先順位を付ける**：締め切りの近さだけで並べると、他の人の作業を止めているタスクが後回しになります。そのタスクが終わらないと着手できない作業を確認し、後続の開始までの余裕、期限、影響の大きさを合わせて優先順位を決めます。
5. **状態を更新し、週に一度見直す**：状態は「未着手・進行中・完了」程度の少ない種類にとどめ、着手したとき・終わったときにその場で変えます。週に一度、期限切れや長く「進行中」のタスク、期限前でも着手が遅れているタスクを確認します。遅れの原因と後続への影響を調べ、分割や支援を検討し、合意済みの期限を変更する場合は関係者の承認を得ます。

作業の流れを列で見える化して滞留を見つけたいなら、[カンバン方式のタスク管理](/column/details/15654/)が向いています。手順4の「後続への影響」は、タスクの一覧だけでは判断しにくい情報です。担当者どうしの作業に前後関係が多い仕事では、次の章のワーク・パッケージと予定日を持つ層が必要になります。

## 両者をつなぐWBSのワーク・パッケージ

### ワーク・パッケージとタスクの関係

プロジェクト管理とタスク管理をどうつなぐかは、WBS（作業分解構成図）で考えると整理しやすくなります。PMI Lexiconはワーク・パッケージを「WBSの最下位レベルで定義された作業で、コスト・工数・期間・資源を見積もり、管理する単位」と定義しています。

実務では、ワーク・パッケージを計画と見積もりの単位にし、担当者がそれを実行のためのタスクに分ける分担にすると、全体の計画と日々の作業が結び付きます。たとえば「画面設計（ログイン・会員登録）」というワーク・パッケージの予定日と工数をPMが計画に載せ、担当者がそれを「入力項目の洗い出し」「エラー文言の決定」「レビュー依頼」といったタスクに分けて状態を更新します。これは標準が定める責任の線引きではなく、運用上の分け方の一例です。アクティビティの順序や期間もスケジュールの一部なので、後続作業の開始に響くタスクはPMも確認します。WBSの作り方そのものは[WBSの作り方5ステップとガントチャートとの違い](/column/details/2345/)で扱っています。

このつなぎ方を検証する手がかりが、PMIのWBS実務標準が示す[100%ルール](https://www.pmi.org/learning/library/applying-work-breakdown-structure-project-lifecycle-6979)です。WBSはプロジェクトの範囲に含まれる作業を100%含み、各階層で子要素の作業の合計が親要素の100%になる、というルールで、作業範囲を漏れなく分解するための原則です。タスクにも同じ考え方を当てはめ、ワーク・パッケージの下のタスクをすべて終えればそのワーク・パッケージが完了する関係にしておけば、タスクの完了情報をワーク・パッケージの完了判定に使えます。ただし完了したタスクの件数を数えても、残りの作業量や完了見込みは分かりません。進捗の評価には、残工数や予定日との比較を別に持つ必要があります。

### タスク粒度のずれが進捗把握と計画更新に与える影響

ワーク・パッケージとタスクの粒度を決めずに運用すると、次の2通りのずれが起きます。

- **タスクが粗すぎる**：ワーク・パッケージをそのまま1件のタスクとして登録すると、「設計」が3週間ずっと「進行中」のままになり、ステータスを見てもどこまで終わって何が残っているかが分かりません。分け方は前の章の手順2のとおりです。
- **計画が細かすぎる**：数十分で終わる作業までPMがガントチャートに載せると、計画の更新に追われて実際の差分を見る時間がなくなります。ガントチャートに載せるのは後続作業の開始日に影響する作業までにし、それ以外の細かな作業は担当者のタスク一覧で管理します。

### タスクのステータスとプロジェクトの進捗の違い

タスクのステータス管理とプロジェクトの進捗管理も、層の違いで整理できます。タスクのステータスは作業そのものの状態で、Backlogなら[標準の「未対応・処理中・処理済み・完了」の4種類](https://support-ja.backlog.com/hc/ja/articles/360037293854-%E7%8A%B6%E6%85%8B%E3%81%AE%E6%A6%82%E8%A6%81)で表します。一方、プロジェクトの進捗は、ワーク・パッケージやマイルストーンが**計画した日付に対して**どこにいるかで測ります。

ステータスの種類を増やしてもプロジェクトの遅れは見えるようになりません。ステータスは「誰の手にあるか」が分かる最小限にとどめ、遅れの判断は予定日との比較で行うのが確実です。

## Jira・Asana・Backlogでのプロジェクトとタスクの階層

多くのツールは、プロジェクト管理の層とタスク管理の層を1つのデータ構造の中に持っています。主要3ツールの階層を並べると次のとおりです。

| ツール        | 入れ物            | 上位のまとまり       | 作業の単位        | 分割した単位       |
| ---------- | -------------- | ------------- | ------------ | ------------ |
| Jira Cloud | スペース（旧プロジェクト）  | エピック          | タスク・ストーリー・バグ | サブタスク        |
| Asana      | ポートフォリオ・プロジェクト | なし（セクションで区切る） | タスク          | サブタスク        |
| Backlog    | プロジェクト         | 親課題           | 子課題          | 孫課題（プレミアム以上） |

Jira Cloudの既定の階層は、[Atlassianのヘルプ](https://support.atlassian.com/jira-software-cloud/docs/map-column-data-to-issue-types/)によるとエピック（レベル1）、タスク・ストーリー・バグ（レベル0）、サブタスク（レベル-1）の3段階です。Atlassianは2025年から画面上の呼び名を「課題（issue）」から「作業項目（work item）」へ切り替えており、既存のAPIは後方互換のため issue の名前のまま動きます。作業を入れる器も「プロジェクト」から「スペース」へ改称され、設定やデータの構造は変わらないと案内されています。古い手順書と画面の用語が食い違っていても、指しているものは同じです。Jiraの画面の使い方は[Jiraの使い方（スペース作成とエピックの使い分け）](/tech/details/7859/)にまとめています。

Asanaは[公式ヘルプの階層の説明](https://help.asana.com/s/article/asana-hierarchy)どおり、プロジェクトをポートフォリオで束ね、プロジェクトをタスクで構成し、タスクをサブタスクに分けます。Backlogは作業も問題も「課題」として登録し、[親子課題](https://help-center.backlog.com/%E8%A6%AA%E5%AD%90%E8%AA%B2%E9%A1%8C-6a1d4d7ee042445b6a27a3ee)をプロジェクト設定で有効にすると、大元の課題を「親課題」、分割した課題を「子課題」として紐づけられます。プレミアムプランとプラチナプランでは、設定で3階層目を有効にすると子課題の下にもう1段（孫課題）を置けます。Backlogのマイルストーンは階層ではなく、課題に付けて期日ごとにまとめる属性です。

WBSとの対応では、ワーク・パッケージをJiraのエピックやBacklogの親課題に当て、担当者の作業をタスク・サブタスクや子課題に当てると、PMが見る層と担当者が見る層が分かれます。Asanaにはエピックに相当する層がないため、ワーク・パッケージを親タスクにしてサブタスクで作業を分けるか、規模が大きければワーク・パッケージごとにプロジェクトを分けてポートフォリオで束ねます。ツールの種類や選び方は[タスク管理ツールの機能・種類・選び方](/column/details/15220/)、プロジェクト管理ツールの選定は[中小企業のプロジェクト管理ツールの選び方](/column/details/15676/)で比較しています。

## タスク管理だけで足りる仕事とプロジェクト管理が要る仕事

### プロジェクト管理の層を足す目安になる4つの条件

ここでは、人数ではなく、作業の前後関係と範囲・予算・納期の調整の必要性を判断軸にします。次の4条件は、規格の必須要件ではなく、本記事で提案する運用上の目安です。終わりのある仕事について、次の条件が当てはまるほど、タスク管理の上にプロジェクト管理の層を足す必要が高まります。とくに前後関係と範囲・予算の判断は、ステータスの一覧だけでは扱えません。

- **作業に前後関係がある**：「設計が終わらないと実装に入れない」のように、ある担当者の遅れが別の担当者の着手日を動かす。
- **範囲や予算を誰かが承認する**：発注者や上長の合意なしに作業を増減できない。追加の要望が来たときに、受けるかどうかを判断する人が要る。
- **締め切りが外部と約束されている**：リリース日や納品日が顧客・他部署との約束で、遅れたときの影響を事前に説明する必要がある。
- **関係者への定期報告がある**：担当者以外の人が進み具合を週次や月次で確認する。

前後関係がなく、各自の作業が独立して完結する仕事、たとえば問い合わせを1件ずつ処理する、記事を1本ずつ書いて出すといった仕事は、タスク管理を中心に回せます。承認や定期報告が必要なら、その手続きだけをワークフローや報告の仕組みとして足せば足ります。

### 受託開発の予定不在と単純作業の過剰計画

管理の層が仕事に合わない失敗は、層が足りない場合と多すぎる場合の両方で起きます。

層が足りない典型は、受託開発をタスクボードだけで回すケースです。各担当者のカードは毎日動いているのに、結合テストの開始日が守れるかを誰も計算していないため、遅れが発覚するのは納期の直前になります。前後関係のある作業が並ぶ時点で、ワーク・パッケージと予定日を持つ層を足すべきです。社内にPMを置く余裕がない場合は、[PMO支援](/service/system/pmo/)のように計画と進捗の層だけを外部に任せる方法もあります。

層が多すぎる典型は、前後関係のない単純な作業にまでWBSとガントチャートを引き、同じ情報をタスク一覧と計画表に二重入力するケースです。計画の更新そのものが仕事になり、管理の手間が実作業を圧迫します。定常業務はプロジェクトではないので、必要なのは範囲の分解ではなく、期限・承認・報告といった業務ごとの要件を満たす管理です。チームでタスク管理を共有する運用の設計は[チームのタスク管理の運用設計](/column/details/15650/)を参照してください。

## よくある質問

### タスク管理とは、簡単にいうと何ですか？

個々の作業について、担当者・期限・状態（未着手・進行中・完了など）を決めて追いかけることです。タスクマネジメントとも呼ばれます。プロジェクトの中だけでなく、定常業務やチームの日々の仕事でも使います。ToDoリストでも担当・期限・完了状態を管理できます。名称よりも、必要な情報を記録し、進み具合を確認できる運用になっているかで判断します。

### WBSとタスク管理の違いは何ですか？

WBSはプロジェクトの範囲に含まれる作業を階層に分解した計画の道具で、最下位のワーク・パッケージまでを定めます。タスク管理は個々の作業の担当・期限・状態を追う運用です。WBSを使うプロジェクトでは、ワーク・パッケージを実行用のタスクに分けることで両者をつなげられます。WBSが計画の層、タスク管理が実行の層にあたり、WBSだけでは日々の進み具合が、タスク管理だけでは全体の範囲の漏れが見えません。

### プロジェクト管理とプロジェクトマネジメントは同じ意味ですか？

同じ意味で使われています。PMBOKガイドやISO 21502の日本語の文脈では「プロジェクトマネジメント」と書かれることが多く、ツールの機能名や社内の呼び方として「プロジェクト管理」が使われます。どちらも、目標と計画を合意したうえで範囲・期間・コスト・リスクを統制する活動を指します。

### 1人で進める仕事にもプロジェクト管理は必要ですか？

人数ではなく、工程の順序・予算・完了条件を調整する必要があるかで決まります。作業が独立していて完了条件も明確なら、タスク管理で回せます。1人でも、複数の工程を順に進める案件や、顧客と納期・範囲を約束している案件では、マイルストーンと予定日を持っておくと遅れを早く説明できます。

### マイルストーンとタスク、ロードマップはどう違いますか？

タスクは時間をかけて行う作業で、マイルストーンはPMI Lexiconの定義では「重要な時点または出来事（a significant point or event）」です。「要件定義の承認」「リリース」のように、複数のタスクが終わった結果として到達する節目に置きます。ロードマップは、Atlassianの[プロダクトロードマップの解説](https://www.atlassian.com/agile/product-management/product-roadmaps)では、製品のビジョン・方向性・優先事項・進捗を時間の経過に沿って示す戦略的な計画です。マイルストーンや主要な取り組みは載りますが、個々のタスクまでは載せません。目標時期の近い語との違いは[メルクマールとマイルストーン・KPIとの違い](/column/details/10103/)でも整理しています。

## 関連記事

- [WBSとは？作り方5ステップとガントチャートとの違いを具体例で解説](/column/details/2345/)
- [タスク管理ツールとは？機能・種類・選び方と既製か自作かの判断軸を解説](/column/details/15220/)
- [中小企業のプロジェクト管理ツールの選び方｜コスト・機能過不足・定着で外さない判断軸](/column/details/15676/)
- [チームのタスク管理とは？共有と進捗可視化の運用設計・既製ツールと自社開発の判断軸を解説](/column/details/15650/)
- [システム開発のプロジェクト管理とは？進め方・QCDと工程/品質/リスク管理と発注側の役割【2026年版】](/column/details/15670/)

---

出典: [プロジェクト管理とタスク管理の違いとは？ToDo・課題管理との区別とWBSでのつなぎ方](<https://www.issoh.co.jp/column/details/11042/>)（株式会社一創）