重要度と緊急度の違いとは？優先順位を考える基本
目次
緊急度は、どれだけ早く対応する必要があるかを示します。重要度は、目標や守るべき業務にどれだけ関わるかを示します。
「今日中にお願いします」という依頼と、「いずれ直したほうがよい」という改善案が並ぶと、まず今日中の依頼から手をつけたくなります。ただ、期限が近いことと、成果への影響が大きいことは同じではありません。二つを分けると、急ぎの依頼だけで予定が埋まっていないかを考えやすくなります。
この記事では、日々の仕事や顧客要望を整理するときの基本を説明します。二つの軸で分けただけで、開発の着手順が自動的に決まるわけではありません。
- 対応までの時間と、目標・業務への影響を分けます。
- 重要だけれど急がない仕事にも、見直しの予定を置きます。
- 二つの軸だけで実装順を決めず、根拠や工数も確認します。
緊急度は時間、重要度は目的との関係で見る
緊急度を考えるときは、「いつまでに必要か」「その時点を過ぎると何が起きるか」を確かめます。連絡が何度も届いたことや、強い言葉が使われたことだけでは、期限の理由までは分かりません。
重要度を考えるときは、「誰のどの仕事に関わるか」「今回の目標にどうつながるか」を見ます。重要度が高い理由は、売上への影響だけとは限りません。利用者の仕事を止めないことや、約束した責任を果たすことも、判断の前提になります。
FranklinCoveyの公式解説も、緊急性を対応までの時間、重要性を使命や目標への貢献と結びつけ、二つの軸を分けています。以下は、その区別を顧客要望の整理に当てはめた本記事の考え方です。
| 軸 | 最初に確認すること | それだけでは分からないこと |
|---|---|---|
| 緊急度 | 期限と、遅れたときに起きること | 目標への影響がどれほど大きいか |
| 重要度 | 目標、影響する仕事、守るべき条件 | 今日中に対応する必要があるか |
四つの組み合わせで、違いをつかむ
次は、架空の予約管理ツールを提供するチームの説明用の例です。実際の顧客要望や、アーコレの機能・対応方針ではありません。今回の目標は「店舗が予約受付を滞りなく続けられること」とします。
| 組み合わせ | 架空の例 | 考えること |
|---|---|---|
| 重要度も緊急度も高い | 明日の受付に必要な設定が終わらず、代わりの方法も確認できていない | 影響と期限を確認し、必要な担当へ早くつなぐ |
| 重要度は高いが、緊急度は低い | 毎月の予約確認で起きる手戻りを減らしたい。直近の受付は続けられる | 後回しを続けず、調査や改善を予定に入れる |
| 重要度は低めだが、緊急度は高い | 今日の社内説明用に一覧の色を変えたい。今の色でも説明はできると確認済み | 期限の背景を聞き、既存表示などの代案を検討する |
| 重要度も緊急度も低い | 参考用一覧の並びを変えたい。現状で業務に支障はなく、利用予定も期限もないと確認済み | 現時点では保留し、再確認する条件を残す |
ここでの高低は、設定した目標と仮定に対する分類です。色の変更でも、内容を判別できず業務が止まるなら、重要度の見方は変わります。機能の種類だけで「装飾だから低い」と決めないことが大切です。
「急ぎ」と言われたら、期限の理由を見る
緊急度には、依頼した人の希望だけでなく、その期限が必要になった事情が関わります。「明日まで」と書かれていても、何が明日なのかは別に確認します。
明日の受付開始に欠かせないのか、社内で一度見せたいのか、依頼者が目安として書いたのかを確かめます。必要な対応が異なるため、日付だけを見て並べ替えないようにします。
確認した結果、返答は急ぐ必要があっても、新しい機能をすぐ開発する必要はない場合があります。使える代替手順を知らせることと、機能を実装することを分けて考えます。実際の受付・回答の流れは、急ぎの顧客要望への対応手順で説明しています。
重要だけれど急がない仕事にも、予定をつくる
重要度が高くても、期限がない仕事は目の前の依頼に押されやすくなります。手戻りの原因を調べる、分かりにくい説明を直す、チームで記録方法をそろえる、といった仕事です。
「時間ができたら」と残すだけでは、誰がいつ考えるのかが決まりません。今すぐ大きな改善を始められなくても、「次の見直しで対象を選ぶ」「担当者が記録を確認する日を決める」といった小さな予定を置けます。
ただし、予定を入れることと、実装日を顧客に約束することは別です。調査の予定、判断する日、提供できる見込みを混ぜないようにします。
二つの軸だけでは、着手順は決まらない
重要度も緊急度も高い要望が複数あれば、使える工数や前提作業も確認する必要があります。先に別の機能を直さなければ進められない場合もあれば、短い案内で当面の困りごとを減らせる場合もあります。
四つの分類は、話し合うための整理です。「この枠なら必ず実装する」「この枠なら捨てる」という自動判断にはしません。根拠が足りない項目は、無理に高低を決めず「未確認」として残します。
また、発生中の障害や安全・情報漏えいの問題が疑われる場合は、通常の要望の並べ替えではなく、自社の対応手順と担当窓口に従ってください。
複数の候補から開発対象を選ぶ段階では、機能の優先順位を決める方法が参考になります。判断する人が曖昧なら、受付・判断・回答の役割分担も先に確認しましょう。
最初の一歩は、依頼一件に二つの理由を添える
まず一件だけ選び、「期限が必要な理由」と「重要だと考える理由」をそれぞれ一文で書いてみてください。同じ理由を両方に書いていたら、時間と影響を分けて説明できないか考えます。
たとえば「明日の受付開始までに必要」は期限の理由、「設定できないと店舗が予約受付を始められない」は影響の説明です。どちらも未確認なら、担当者に確認してから優先順位の検討へ進めます。
まとめ
緊急度は対応までの時間、重要度は目標や業務への関わりです。「早いほうがよい」と「大きな意味がある」を分けることで、依頼を比べる理由が見えてきます。
二つの軸は、機械的に順位を出すためではなく、判断の前提をそろえるために使いましょう。まずは一件の期限と影響を別々に書き、分からないところを確認することから始められます。
