タスクのステータスとは？種類・一覧と設計・運用のコツを図解で解説

タスクのステータスとは、一つひとつのタスクが「今どの状態にあるか」を表す区分のことです。

「未着手・進行中・完了」のように状態でタスクを仕分けると、誰の何がどこまで進んでいるかがひと目で分かり、抜け漏れや期限遅れを防げます。

この記事では、タスクのステータスの種類と一覧（基本5つ＋拡張）、進捗率や優先度との違い、職種別の設計例、そしてエクセルやチームで運用するときのコツまでを図解で解説します。

そのまま使える無料のステータス管理テンプレートも配布します。

タスクのステータスとは？意味と役割

タスクのステータスは、タスクの「現在地」を全員が同じ言葉で共有するための状態区分です。
状態でタスクを分けることで、進捗の見える化と抜け漏れ防止が同時に実現します。

ステータス＝タスクの「現在地」を表す共通言語

ステータス（status）は英語で「状態」を意味し、タスク管理ではそのタスクが完了までのどの段階にいるかを表します。

たとえば「未着手」「進行中」「完了」は、もっとも基本的な3つのステータスです。

ステータスの価値は、チーム全員が“同じ言葉”でタスクの状態を認識できる点にあります。

ある人は「やってる」、別の人は「ほぼ終わり」と口頭で言っても実態はバラバラですが、状態を「進行中」「レビュー中」と定義しておけば、認識のズレが起きません。

タスクそのものの考え方はタスク管理とはもあわせて確認すると理解が深まります。

なぜステータス管理が必要なのか

ステータスを管理しない現場では、進捗が個人の頭の中にだけあり、「あの件どうなった？」という確認のやり取りが日々発生します。

状態を見える化すれば、この確認コストが大きく減り、遅れているタスクにも早く手を打てます。

生産性向上の土台はチームのタスク管理にあり、「見える化が改善のはじまり」である。

小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年、ISBN 978-4-408-65143-9

株式会社スーツ 代表取締役社長CEO 小松裕介氏は、著書『1+1が10になる組織のつくりかた』（実業之日本社、2025年）で、生産性を上げる出発点として「タスクの見える化」を挙げています。

日本の労働生産性は日本生産性本部『労働生産性の国際比較』でも主要国の中で低い水準が続くと指摘されており、限られた人数で成果を出すには、まず「今どのタスクがどの状態か」を全員が見られる状態を作ることが第一歩です。

見える化の具体的な進め方はタスクの見える化でも解説しています。

ステータス管理と進捗管理の関係

ステータス管理は、より広い進捗管理とはの一部です。

進捗管理が「計画に対して全体がどれだけ進んでいるか」を扱うのに対し、ステータスは個々のタスク単位の状態を扱います。

両者は対立するものではなく、各タスクのステータスが正しく更新されているからこそ、それを積み上げたプロジェクト全体の進捗も正確になります。

つまりステータス管理は、進捗管理の“最小単位”を支える土台だといえます。

タスクのステータスの種類と一覧【基本5＋拡張】

まずは「未着手・進行中・レビュー中・保留・完了」の5ステータスモデルを押さえ、必要に応じてブロック中や却下を足します。
以下の一覧表で全体像をつかんでから、各区分を詳しく見ていきましょう。

タスクのステータスに絶対の正解はありませんが、多くの現場で共通して使われる基本の5区分があります。

まずはこの5つを土台に、自分のチームに必要な状態だけを足し引きするのがおすすめです。

→ 表は横にスクロールできます

上の5つに加え、開発や製造の現場では「ブロック中（詰まり）」を、企画や検討が多い現場では「却下・中止」を足すことがあります。

ここからは、代表的な7つのステータスを一つずつ、定義・誤解しやすい点・具体例まで掘り下げます。

未着手（To Do／Not Started）とは？

タスクとして登録されているが、まだ誰も作業を始めていない「これからやる」状態です。

未着手は、やるべきことが決まって一覧には載っているものの、実際の手はまだ動いていない段階を指します。

担当者と期限だけが決まっていて中身が進んでいないタスクは、すべてここに入ります。

未着手をきちんと「見える」状態にしておくと、チーム全体でこれから何が発生するかを先読みできます。

未着手が山積みなのに期限が近い、という状況を早めに察知できれば、着手前に人を割り振り直したり、優先順位を組み替えたりする余地が生まれます。

逆に未着手を管理せず頭の中だけに置いておくと、そのまま忘れ去られて抜け漏れになりがちです。

誤解されやすい点：「まだ手をつけていない＝管理しなくてよい」ではありません。
未着手こそ、期限から逆算して“いつ始めるか”を決めておくべき状態です。

• ToDoリスト：これからやることを書き出したもの（未着手タスクの集合に近い）
• 期限：未着手のうちに着手日を逆算して決めておくと遅延を防げる

進行中（対応中・作業中）（In Progress／Doing）とは？

担当者が実際に手を動かして作業を進めている「いま取り組んでいる」状態です。

進行中は、着手済みでまだ完了していないタスクを表します。

もっとも動きのある状態であり、進捗の遅れや停滞がここで発生するため、チームがいちばん目を配るべき区分です。

進行中のタスクが一人に偏っていないか、進行中のまま何日も止まっていないかを見るだけで、負荷の偏りや停滞のサインをつかめます。

ひとりが同時に抱える進行中タスクを絞ると、切り替えのロスが減り、結果的に一つひとつが早く終わります。

進行中が多すぎるチームは「同時に手をつけすぎて、どれも終わらない」状態に陥りやすいので、あえて進行中の数に上限を設ける運用も有効です。

誤解されやすい点：「着手したらすぐ進行中にして放置」ではなく、進行中は“今まさに動いている”タスクだけに絞るほど、状態が実態を正しく表します。

• 仕掛かり（WIP）：進行中タスクの総量。増やしすぎると全体が遅くなる
• 進捗率：進行中タスクが今どのくらい進んだかを補助的に表す指標

レビュー中（確認中・承認待ち）（In Review / Waiting for Approval）とは？

作業自体は終わり、上長や依頼者のチェック・承認を待っている状態です。

レビュー中は、担当者の手を離れて「他の人の確認待ち」になっているタスクを表します。

作業は終わっているのに完了にできない、という宙ぶらりんの時間を可視化するための区分です。

レビュー中を独立した状態として設けると、「誰の確認で止まっているのか」がはっきりします。

レビュー待ちのタスクが溜まっているなら、それはチェックする側がボトルネックになっているサインです。

進行中と完了の間にこの状態を挟むかどうかは、承認プロセスの有無で決めます。

上長承認や相互レビューが常にあるチームなら設ける価値が大きく、そうでないチームでは省いて状態を減らしたほうが運用が軽くなります。

誤解されやすい点：レビュー中は「担当者が忘れていい状態」ではありません。
差し戻し（手戻り）が来たら再び進行中に戻る、往復のある状態だと理解しておきます。

• 差し戻し：レビューで指摘が入り、進行中へ戻ること
• 承認フロー：レビュー中の状態を設けるかどうかの判断基準になる

保留（ペンディング・待ち）（On Hold / Pending）とは？

自分たちの都合ではなく、外部要因や情報待ちで一時的に進められない状態です。

保留は、やめたわけではないが今は進められないタスクを表します。

取引先の返答待ち、上位方針の決定待ち、必要な情報がそろっていない、といった“こちら側では動かせない理由”で止まっているものが該当します。

保留を「進行中」に混ぜてしまうと、実際は止まっているのに動いているように見え、進捗の実態がぼやけます。

保留を独立させておけば、「何を・誰の返答を・いつまで待っているのか」を一覧でき、待ち時間が長引いているタスクに催促をかけられます。

保留にするときは“再開条件”（何がそろえば動かせるか）と“待ち先”をメモしておくのが、放置を防ぐコツです。

誤解されやすい点：保留は「あとで考える」という曖昧な棚上げではなく、“外部の何を待っているか”が明確な状態に限定すると機能します。

• ブロック中：他タスクや障害で進めない、より“詰まった”状態
• 再開条件：保留を解除して進行中に戻す引き金

ブロック中（滞留・詰まり）（Blocked）とは？

他のタスクの未完了や障害が原因で、物理的に前へ進めなくなっている状態です。

ブロック中は、前工程が終わらない・システム障害・意思決定の停止などで、担当者の努力とは無関係に手が止まっているタスクを表します。

保留が“待ち”なら、ブロック中は“詰まり”です。

ブロック中は、チームの流れが止まっている最も危険なサインです。

ここを可視化しておくと、「何がこのタスクを止めているのか（＝解消すべき原因）」を優先的に片づける判断ができます。

ブロックの原因が他メンバーの別タスクにあることも多いため、状態として明示して原因タスクとひも付けると、詰まりの連鎖を早くほどけます。

ブロック中の件数を毎日確認する運用にすると、停滞が長期化する前に手を打てます。

誤解されやすい点：「難しくて進まない」はブロックではありません。
ブロックは“外的な障害で進めない”状態で、原因を取り除けば動き出すものを指します。

• 依存関係：前のタスクが終わらないと始められない関係。ブロックの主因
• エスカレーション：ブロックを解消するために上位へ判断を求めること

完了（Done / Completed）とは？

作業も確認も終わり、それ以上やることが残っていない「終わった」状態です。

完了は、成果物が出て承認も済み、クローズしてよいタスクを表します。

何をもって完了とするか（完了の定義）をチームで揃えておかないと、人によって“終わった”の基準がずれてしまいます。

完了状態は、単なる達成記録ではなく振り返りの材料になります。

どのタスクがいつ完了したかを残しておくと、見積もりと実績のズレや、どの工程に時間がかかったかが見えてきます。

また、完了の基準（レビュー通過なのか、公開まで含むのか）を明文化しておくと、レビュー中や進行中との境界が曖昧になりません。

完了したタスクは一覧から自動で畳まれる設定にしておくと、進行中の見通しがよくなります。

誤解されやすい点：「自分の作業が終わった＝完了」とは限りません。
レビューや納品まで含めて“完了の定義”を先に決めておくことが、状態管理の精度を左右します。

• 完了の定義（DoD）：何を満たせば完了とみなすかの共通基準
• アーカイブ：完了タスクを一覧から畳んで見通しを保つこと

却下・中止（キャンセル）（Cancelled / Rejected）とは？

方針変更や不要になったなどの理由で、着手・完了せずに取りやめた状態です。

却下・中止は、やらないと決めたタスクを表します。

単に削除するのではなく“中止した”と状態で残すことで、「なぜやめたのか」の判断履歴がチームに蓄積されます。

タスクを消してしまうと、後から「あの件はどうなった？」と問われたときに経緯が分かりません。

却下・中止という状態で残しておけば、意思決定の記録として機能し、同じ検討を蒸し返す無駄を減らせます。

中止にするときは理由を一言添えるのが、後任者や他部署への親切です。

未完了のまま放置されているタスクを定期的に見直し、やらないものは中止に落とす運用が、一覧を“生きた状態”に保ちます。

誤解されやすい点：却下・中止は「失敗の記録」ではなく、“やらない判断をした”という前向きな整理です。
残すことに価値があります。

• 棚卸し：未完了タスクを定期的に見直し、中止するものを決める作業
• 判断履歴：なぜやめたかを状態として残すことで蓄積される情報

ステータスの英語表現一覧（外資・グローバルチーム向け）

外資系やグローバルなチームでは、ステータスを英語で運用することもあります。

代表的な日本語ステータスと英語表現の対応は次のとおりです。

→ 表は横にスクロールできます

表記ゆれに注意：同じ状態でも「Doing／In Progress」「Done／Completed／Closed」など複数の言い方があります。
チーム内でどれを使うか1つに統一しておくと、状態の解釈がぶれません。

ステータスと進捗率・優先度・カンバンの違い

ステータス（状態）は、進捗率（量）や優先度（順序）とは別の軸です。
混同すると管理が二重になったり抜けたりするので、役割の違いを整理しておきましょう。

ステータスと進捗率の違い（状態 vs 量）

ステータスが「未着手・進行中・完了」という段階（状態）を表すのに対し、進捗率は「30%・80%」のようにどれだけ進んだか（量）を数値で表します。

両者は補い合う関係です。

ステータスだけだと「進行中」の中の進み具合が分からず、進捗率だけだと「レビュー待ちで止まっている」といった状態が見えません。

多くのチームはステータスを主、進捗率を補助として併用します。

→ 表は横にスクロールできます

進捗率は便利に見えますが、更新のたびに「今何％か」を主観で見積もる必要があり、人によって数字がぶれやすいという弱点があります。

一方ステータスは選ぶだけで更新でき、判断が入りません。

だからこそ、まずは全員が正しく維持できるステータスを軸に据え、進捗率は必要なタスクにだけ添える、という使い分けが現実的です。

ステータスと優先度の違い（状態 vs 順序）

優先度は「高・中・低」のように、どれから手をつけるかの順序を表す軸で、状態を表すステータスとはまったく別物です。

この2つは掛け合わせて使います。

たとえば「優先度：高」かつ「ステータス：未着手」のタスクは、“急ぎなのにまだ手をつけていない”危険なタスクとして真っ先に着手すべき対象になります。

状態と順序を別々に持つことで、こうした見るべきタスクの絞り込みができます。

タスクを溜めがちな人は抜け漏れが多い人の対策もあわせて参考にしてください。

カンバンの「列」＝ステータスという関係

ふせんやカードを「未着手・進行中・完了」の列に貼って動かすカンバン方式とはは、まさにステータスを縦の列で表現した仕組みです。

カードを右の列へ動かすこと自体が、ステータスの更新にあたります。

カンバンの考え方はもともとトヨタ生産方式に由来し、ソフトウェア開発ではIPA『アジャイル型開発におけるプラクティス活用リファレンスガイド』などでもアジャイル開発のプラクティスとして整理されています。

ステータスを「列」として見せると、どの段階にタスクが滞留しているかが視覚的につかめます。

具体的な運用はタスク管理のカンバン方式でも解説しています。

職種・業界別のステータス設計例

ステータスは仕事の流れに合わせて設計します。
ここでは代表的な職種・業界での設計例を紹介します。
自分のチームの“工程の切れ目”を状態に置き換えるのがコツです。

開発・営業・製造・管理部門のステータス例

同じ「タスク」でも、職種によって通る工程が違うため、最適なステータスも変わります。

自分たちの仕事の“工程の切れ目”を状態に置き換えると、無理のない設計になります。

→ 表は横にスクロールできます

プロジェクトマネジメントの国際的な標準を整理するProject Management Institute（PMI）でも、作業を状態で管理し、工程の進み具合を可視化する考え方は共通しています。

業界特有の言い回しがあっても、根っこは「未着手→進行中→完了」の流れに、その仕事ならではの“待ち”や“確認”を挟んだものだと捉えると設計しやすくなります。

自社に合わせてステータスを設計する手順

テンプレートをそのまま使うより、自分たちの実際の流れに合わせて微調整したほうが定着します。

次の手順で、無理なく自社版のステータスを作れます。

1. 自分たちの典型的なタスクが「登録〜完了」までに通る工程を書き出す
2. 工程の切れ目のうち、“止まりやすい／確認が入る”ポイントを状態にする
3. まず3〜5個に絞り、使われない状態が出たら統合する
4. 各状態への“変える条件”を1行で決め、チームに共有する

設計でつまずきやすいのは、「他社がやっているから」と状態を借りてくるケースです。

開発チームのステータスを営業チームに当てはめても、通る工程が違うので機能しません。

大事なのは、自分たちが実際に止まりやすい場所を状態にすることです。

たとえば承認で毎回止まるなら「承認待ち」を、外注の戻り待ちが多いなら「保留」を厚めに設計します。

コツ：最初から完璧を目指さず、1〜2週間運用して「足りない・多すぎる」を調整する前提で始めると失敗しません。

ステータス設計・運用のコツと失敗例

ステータス管理は、状態を作って終わりではありません。
「増やしすぎない」「遷移ルールを決める」「停滞を検知する」の3つが、形骸化させないための勘どころです。

ステータスを増やしすぎない（設計のコツ）

状態は基本3〜5個から始め、本当に運用が回る範囲でだけ増やすのが鉄則です。

最初から10個以上の細かい状態を用意すると、メンバーは「これはどの状態？」と迷い、更新自体が面倒になって形骸化します。

まずは未着手・進行中・完了の3つ、必要ならレビュー中と保留を足した5つで始め、実際に「この状態が無くて困った」と感じてから追加します。

状態は多ければ精密なのではなく、全員が迷わず正しく更新できてはじめて機能します。

1. 未着手・進行中・完了の3状態で運用を始める
2. 承認や確認が必ずあるなら「レビュー中」を追加する
3. 外部待ちが頻繁なら「保留」を追加する
4. 実際に困ってから、その困りごとに対応する状態だけを足す

コツ：「この状態は先週1件でも使ったか」を定期的に見直し、使われない状態は思い切って統合する。

遷移ルールと更新タイミングを決める（運用のコツ）

「いつ・誰が・どの状態に変えるか」を決めておかないと、状態は実態とずれていきます。

状態の種類をそろえるだけでは不十分で、「着手したら進行中にする」「作業が終わったらレビュー中にする」といった遷移のルールと、更新のタイミングをチームで合意しておく必要があります。

理想は、作業の切れ目にその場で更新する運用です。

朝会や終業前など、状態を見直す時間を1日1回でも決めておくと、一覧が実態を映し続けます。

更新されない状態表は、古い地図と同じで、かえって判断を誤らせます。

1. 各状態への“変える条件”を1行で言語化する（例：確認依頼を出したらレビュー中）
2. 更新のタイミングを決める（作業の切れ目／1日1回の見直し）
3. 状態を最新にする責任者（原則は担当者本人）を明確にする

コツ：状態変更を報告と兼ねる。
状態を動かせば周囲に伝わる仕組みにすると、二重の報告が要らない。

停滞（滞留）を検知する仕組みを持つ（運用のコツ）

同じ状態に留まり続けているタスクを見つけ、詰まりを早めにほどくことが重要です。

状態管理の本当の価値は、「進行中のまま何日も動いていない」「レビュー中で放置されている」といった停滞をあぶり出せる点にあります。

状態が変わった日付を残しておけば、一定期間動いていないタスクを機械的に洗い出せます。

停滞の多くは、ブロック中や保留を可視化しきれていないことが原因です。

詰まりを個人の頑張り不足と決めつけず、状態から原因タスクへたどって、チームで解消する姿勢が生産性を左右します。

1. 状態が変わった日時を記録する（手動でも日付列で可）
2. 一定期間同じ状態のタスクを定期的に洗い出す
3. 停滞タスクは原因（ブロック元・保留理由）まで確認して手を打つ

コツ：「3日以上進行中のまま」など自チームの基準を決め、朝会で停滞タスクだけを見る時間を作る。

エクセル・スプレッドシートでの管理方法【無料テンプレ】

まずは手元のエクセルやスプレッドシートでも、プルダウンと色分けでステータス管理を始められます。
作り方と、チームで使うときの限界を押さえておきましょう。

プルダウンと色分けでステータス列を作る

エクセルやスプレッドシートなら、追加コストなしでステータス管理を始められます。

ポイントは、状態をプルダウン（入力規則）で選ぶ形にして表記ゆれを防ぎ、条件付き書式で状態ごとに色分けして一覧性を高めることです。

1. 「タスク名・担当者・期限・ステータス」などの列を用意する
2. ステータス列に入力規則（リスト）を設定し、未着手／進行中／完了…を選べるようにする
3. 条件付き書式で、状態ごとに背景色を変える（例：完了＝グレー、遅延＝赤）
4. フィルターや並べ替えで「進行中だけ」「保留だけ」を絞り込めるようにする

エクセルでのタスク管理そのものの作り方はエクセルでのタスク管理、共同編集しやすいスプレッドシート版はスプレッドシートでのタスク管理でも詳しく解説しています。

タスク名,担当者,期限,ステータス,優先度,メモ（保留理由・ブロック元）
請求書を作成する,山田,2026-07-20,進行中,高,
見積書を確認する,佐藤,2026-07-18,レビュー中,中,上長の承認待ち
取引条件を照会する,鈴木,2026-07-22,保留,中,取引先の回答待ち
旧フォーマットを廃止する,田中,2026-07-31,却下・中止,低,方針変更のため中止
月次レポートを提出する,山田,2026-07-15,完了,高,

↑をコピーして「task-status-template.csv」として保存し、エクセル／Google スプレッドシートで開けばそのまま使えます（文字化けする場合は文字コードをUTF-8で開く）。ステータス列はプルダウン、状態ごとの色分けはご自身の環境で設定してください。

エクセル管理の限界とツールへの切り替え目安

エクセルは手軽な一方、複数人で同時に使い始めると限界が出ます。

「最新版はどれ？」問題、上書き事故、更新の属人化、そして期限が近づいても自動で知らせてくれない——といった課題です。

一人〜数人で扱う短期の管理ならエクセルで十分ですが、複数人が毎日更新し続ける段階になると、同時編集・変更履歴・自動通知を備えたツールへ切り替えたほうが、結果的に手間が減ります。

複数人でのタスク管理の考え方は複数人でのタスク管理も参考になります。

切り替えの目安になるのは、件数よりも“関わる人数”と“更新の頻度”です。

ひとりが自分のために管理しているうちはエクセルで十分ですが、複数人が毎日同じ表を触り、しかもその表を見て次の判断をするようになったら、ファイルを配り合う運用の限界が近づいているサインだと考えてよいでしょう。

このタイミングで、状態の更新がそのまま全員に共有される仕組みに移すと、「最新はどれ？」という確認そのものが消えます。

ステータス管理をチームで回すには

ステータス管理の効果は、チーム全員が同じ最新の状態を見られてはじめて最大化します。
個人の管理からチームの運用へ広げる視点が重要です。

個人の管理からチームの見える化へ

個人が自分のタスクの状態を管理できても、チーム全体の状態が“一枚の最新版”として見えていなければ、結局は「あの件どうなった？」の確認が残ります。

株式会社スーツ 代表取締役社長CEO 小松裕介氏は、著書『1+1が10になる組織のつくりかた』（実業之日本社、2025年）は、個人のタスク管理からチームのタスク管理へ広げることが、組織の生産性を上げる鍵だと述べています。

一人ひとりの状態更新が、そのままチームの見える化につながる仕組みを作ることが理想です。

見える化をチームで続ける方法は進捗管理の見える化でも触れています。

更新を習慣にする＝通知と“続けやすさ”

ステータス管理が形骸化する最大の原因は、状態が更新されなくなることです。

更新を個人の意志だけに頼らず、期限前の自動通知や、状態を動かせば周囲に伝わる仕組みで“続けやすさ”を設計することが、定着の分かれ目になります。

よくある質問（FAQ）

タスクのステータスについて、検索でよく調べられる質問に短く答えます。

まとめ：ステータスは“チームで回して”はじめて活きる

タスクのステータスは、タスクの「現在地」を全員が同じ言葉で共有するための状態区分です。

基本の5区分（未着手・進行中・レビュー中・保留・完了）を土台に、自分のチームの工程に合わせて足し引きするのが設計の基本でした。

そして状態は作って終わりではなく、更新され続けてはじめて価値を持ちます。

増やしすぎず、遷移ルールを決め、停滞を検知する——この3つを押さえ、チーム全員が同じ最新を見られる状態を作ることが、生産性向上の入り口になります。

最後に一点だけ補足すると、ステータス管理は“管理のための管理”になってはいけません。

状態を細かく分けること自体が目的化すると、更新の負担だけが増えて現場は疲れます。

目的はあくまで、止まっているタスクに早く気づき、チームで手を打てるようにすることです。

この目的に立ち返りながら、自分たちにとって“ちょうどよい”ステータスを育てていってください。

参考文献・出典

• 小松裕介『1+1が10になる組織のつくりかた ── チームのタスク管理による生産性向上』実業之日本社、2025年（ISBN 978-4-408-65143-9）
• 日本生産性本部『労働生産性の国際比較』
• 中小企業庁『中小企業白書』
• 総務省『情報通信白書』
• 経済産業省『DXレポート』
• IPA『アジャイル型開発におけるプラクティス活用リファレンスガイド』
• デジタル庁
• Project Management Institute（PMI）