タスクの優先順位のつけ方|4つの方法と記入例

タスクの優先順位は、重要そうな順に番号を振るだけでは決まりません。目的、動かせない期限、今日使える時間を確認し、実施する仕事と見送る仕事を一緒に決める必要があります。この記事では4つの判断方法と、架空の4時間の記入例を使い、依頼者へ説明できる決め方を紹介します。
目的・動かせない期限・使える時間を確認する
まず「何を守るための順番か」を一文にします。公開時の誤情報を防ぐ、顧客への約束を守る、今週の制作を前に進めるなど、目的が違えば同じ仕事の重要性も変わります。売上への近さだけでなく、安全、契約、品質、他者への影響も確認してください。
次に、締切が外部との約束なのか、社内の希望日なのかを分けます。変更できない根拠、変更を決められる人、遅れた場合の影響を書けば、すべての依頼が「至急」になる状態を見直せます。期限が不明な依頼は捨てず、確認する担当と次回の確認日を付けます。
最後に、会議、定常対応、休暇を差し引いた作業枠を確認します。今日4時間しか使えない人に8時間分の仕事を最優先として渡しても、優先順位を決めたことにはなりません。各タスクの完了条件と概算工数をそろえ、入らない仕事を誰と調整するかまで決めます。見積に不確実性があれば範囲で示しましょう。
重要度と緊急度で分ける:アイゼンハワーマトリクス
アイゼンハワーマトリクスは、重要度と緊急度を別々に考える方法です。重要度は目的への影響、緊急度は対応可能な時間の短さで判断します。依頼者の声の大きさや通知の回数を、そのまま重要度へ置き換えないことが大切です。
区分 | 確認する問い | 対応の例 |
|---|---|---|
重要・緊急 | 今遅れると何が損なわれるか | 必要な範囲を決め、実施枠を確保 |
重要・緊急でない | 先送りすると将来どんな影響があるか | 準備や改善を予定に入れる |
重要でない・緊急 | 自分が行う必要があるか | 委任・簡略化・期限の再確認 |
重要でない・緊急でない | 現在の目的に必要か | 候補として保留または中止を合意 |
分類だけで作業順まで自動的に決まるわけではありません。同じ箱に入った仕事は、期限、必要時間、依存関係で比べます。「重要で緊急でない」改善をいつも後回しにしているなら、空いたら着手する扱いから、週の作業枠を先に確保する扱いへ変えてみてください。委任する場合も、受け手の容量と完了条件を確認します。
範囲を選ぶ:MoSCoWと必須条件の定義
MoSCoWは、決まった期間に何を含めるかを調整する方法です。Mustは今回の目的を満たすために不可欠、Shouldは重要だが代替策がある、Couldは余裕があれば行う、Won’t this timeは今回は含めない項目です。「大切だからMust」ではなく、外すと何が成立しなくなるかを説明します。
Agile Business ConsortiumのMoSCoW解説にあるMustの60%という目安は、DSDMで当該期間の工数配分を考える文脈です。タスク件数の6割を全職場に強制する基準ではありません。本稿では固定比率より、必要な成果と変更できる範囲を明確にすることを重視します。
Mustだけで作業枠を超えたら、担当者の努力で吸収する前に判断を戻します。目的や必須条件に誤解がないか、納期を変えられるか、範囲を分割できるか、支援を増やせるかを決定者と確認します。今回は行わない項目にも理由と再検討条件を残せば、関係者が追加依頼の影響を理解しやすくなります。
効果・工数・依存関係を照合する
複数の改善案から選ぶときは、見込める効果と必要工数を並べます。効果の評価基準は、問い合わせ削減、対象顧客への到達、品質上のリスク低減など、目的に合わせてそろえます。1〜10点の主観評価を工数で割った値は比較の補助であり、精密な利益予測やROIではありません。データが乏しければ、確信度と確認したい仮説も記載します。
依存関係は「誰かを待たせているから常に最優先」とせず、どの後続作業がいつ止まるかを確認します。半日遅れても余裕がある返答と、今返さないと公開判定ができない返答では影響が異なります。代替の確認者、並行できる作業、法的期限や重大障害の対応も含めて判断してください。
評価が割れたときは、点数を細かく刻むより前提を見直します。目的の違い、未確認の納期、含める範囲の違いをそろえたうえで、決定者を一人決めます。順番を変える理由が説明できれば、別の人が一覧を見ても同じ判断を再現しやすくなります。
記入例:4時間で取り組む4つの依頼を選ぶ
次の表は架空の制作担当の例です。今日の作業枠は4時間、各工数は説明用の見積とします。重大誤記は今日の公開前に直す必要があり、原稿承認の返答は明日の制作着手に必要です。改善案と追加デザインは、同じ強さの約束ではありません。
仕事 | 期限 | 見積 | 根拠 | 今日の判断 |
|---|---|---|---|---|
公開前の重大誤記修正 | 今日12時 | 1時間 | 誤情報の公開を防ぐ | 最初に実施 |
原稿承認の返答 | 今日中 | 0.5時間 | 明日の制作が依存 | 次に返答 |
週次レポート改善 | 明日17時 | 2時間 | 今日の枠で実施可能 | 残り枠で進める |
来月用デザイン案追加 | 来月 | 3時間 | 今回はCould | 保留し再確認日を設定 |
今日の実施分は1+0.5+2=3.5時間で、残り0.5時間です。追加デザインまで約束すると合計6.5時間になるため、今日の作業枠には入りません。保留する仕事は削除せず、いつ再判断するかを依頼者へ伝えます。この例の余裕は推奨比率ではなく、与えた条件から残った時間です。
実績が見積より長くなった場合は、残り枠で完了できるかを再確認します。小さな仕事が早く終わったからといって、すぐ別のMustを増やす必要はありません。途中で重大な依頼が来たら、既存の約束のどれを動かすかを明示して引き受けます。
優先順位を更新し、依頼者へ判断を伝える
優先順位は朝に決めて固定するものではありません。新しい制約、顧客の回答、見積の変化、依存先の遅れが分かったときに更新します。ただし、通知が来るたびに全体を並べ直すと実行枠が細切れになります。通常の見直し時点と、即時に判断を戻す例外をチームで決めてください。
依頼者への報告は「忙しい」だけで終えず、「今日の枠は4時間、AとBとCで3.5時間、Dは次回確認日に再判断」のように選択肢を示します。納期を動かすなら、後続担当と合意が必要です。未確認の影響は不明と伝え、回答を得る担当を置きます。
優先づけを試してもうまく進まない場合は、手法より入力を確認します。完了条件が曖昧なら範囲を定義し直す、すべて高なら判断基準を決める、着手だけ増えるなら同時進行を絞る、と原因に合わせて直します。完了件数だけで良し悪しを測らず、重要な約束を守れたか、保留が放置されていないかを振り返りましょう。
記録は「タスク、完了条件、締切の根拠、重要性の理由、見積工数、依存先、今日の判断、再確認日」を一組にすると使いやすくなります。優先度の列だけを更新しても、担当者が何を変えるべきかは分かりません。着手の対象、止める対象、誰に伝えるかを短い文章で残してください。
たとえば原稿承認が遅れる見込みなら、「返答を先にする」だけでなく、明日の制作担当へ変更を伝え、暫定原稿で進められる範囲を確認します。逆に、追加デザインの保留理由がなくなったら、再確認日を待たず候補へ戻しても構いません。判断の履歴があれば、前の優先順位が誤りだったと責めるより、どの前提が変わったかを話し合えます。
最初は代表的な仕事だけで試し、判断に使わない列は増やさないようにします。見積が粗い段階でも、不明な条件と確認先が分かれば次の行動を選べます。精密な点数を完成させることより、引き受けた約束と実際の容量を一致させることを目標にしましょう。
次に使える関連記事
タスクの進行を施策単位で扱い、月次計画と承認済み予算も確認したい場合は、Xtrategyのプロジェクト機能をご覧ください。Xtrategyでは施策のタスク進行をプロジェクト内で管理し、月次計画と承認済み予算を並べて確認できます。関連する予算・CRM・承認情報へ遷移できます。