優先度マトリクスを使おう

ストーリー

「さっきの3つの依頼、どれから手をつけるか考えてみたか？」

渡辺マネージャーが聞いた。

「えっと......本番バグが一番急ぎですよね？」

「そうだな。でも『急ぎ』だけで判断すると失敗する。重要度と緊急度、この2つの軸で考える必要がある。優先度マトリクスを使ってみよう」

渡辺マネージャーはホワイトボードに2x2のマトリクスを描き始めた。

優先度マトリクスとは

優先度マトリクスは、タスクを「緊急度」と「重要度」の2軸で分類するフレームワークです。全てのタスクが「急ぎ」に見える状況で、客観的に優先順位を判断するのに役立ちます。

2つの軸の定義

軸	定義	判断基準
緊急度	すぐに対応しないと問題が拡大するか	期限が迫っているか、放置するとどうなるか
重要度	ビジネスやプロジェクトへの影響が大きいか	目標達成に直結するか、影響範囲は広いか

4象限の分類

              緊急度 高
                │
     ┌──────────┼──────────┐
     │  Q2      │  Q1      │
     │ 重要だが  │ 重要かつ  │
     │ 急がない  │ 急ぎ     │
重   │          │          │
要   │ 計画的に  │ 最優先で  │
度   │ 取り組む  │ 対応する  │
高 ──┼──────────┼──────────┤
     │  Q4      │  Q3      │
     │ 重要でも  │ 急ぐが   │
     │ 急ぎでも  │ 重要度は  │
     │ ない     │ 低い     │
     │          │          │
     │ 削除or    │ 効率化or │
     │ 後回し   │ 委任     │
     └──────────┼──────────┘
              緊急度 低

各象限の詳細と対応方針

Q1: 重要かつ緊急（最優先で対応）

すぐに取り組まなければならないタスクです。

エンジニアの具体例	理由
本番環境のバグ・障害	ユーザーに直接影響している
セキュリティ脆弱性の対応	放置すると被害が拡大する
今日が期限のタスク	約束を守る必要がある
ブロッカーになっている他メンバーへの対応	チーム全体の進捗に影響

対応方針: 今すぐ着手。他のタスクを中断してでも対応する。

Q2: 重要だが緊急ではない（計画的に取り組む）

最も価値のある象限です。ここに時間を多く使えるかが生産性の分かれ目になります。

エンジニアの具体例	理由
アーキテクチャの設計・改善	長期的な品質に影響
テストの充実、リファクタリング	技術的負債の削減
新しい技術の学習	将来の生産性向上
ドキュメントの整備	チームの知識共有
1on1やキャリアについての振り返り	自己成長

対応方針: スケジュールに予め組み込む。毎週決まった時間を確保する。

Q3: 緊急だが重要ではない（効率化 or 委任）

「やらなきゃ」という焦りを感じるが、実は重要度が低いタスクです。

エンジニアの具体例	理由
形式的な会議への出席	自分がいなくても進む
定型的な質問への回答	FAQやドキュメントで代替可能
重要でないSlack通知への即応	まとめて対応すれば十分
影響範囲の小さい軽微なバグ	次のスプリントで対応可能

対応方針: 効率化（テンプレート化、自動化）するか、他の人に委任する。

Q4: 重要でも緊急でもない（削除 or 後回し）

意識的にやらない判断をする象限です。

エンジニアの具体例	理由
現時点で不要な最適化	YAGNI原則に反する
使われていない機能の改修	投資対効果が低い
SNSの閲覧、雑談の延長	生産性に寄与しない

対応方針: タスクリストから削除するか、「いつかやる」リストに移す。

実践：朝の3つの依頼を分類する

ストーリーで出てきた3つの依頼を、優先度マトリクスで分類してみましょう。

依頼の詳細を確認する

依頼	詳細を確認した結果
PRレビュー	先週金曜に依頼あり。機能開発のPRで、レビュー待ちでブロックされている
API設計ドラフト	来週のスプリントプランニングまでに必要。今日中でなくても水曜でOK
本番バグ	ユーザーの10%に影響。決済処理のエラーが断続的に発生

マトリクスへの配置

              緊急度 高
                │
     ┌──────────┼──────────┐
     │          │          │
     │ API設計   │ 本番バグ  │
重   │ ドラフト  │ (決済エラー│
要   │ (Q2)     │  Q1)     │
度   │          │          │
高 ──┼──────────┼──────────┤
     │          │          │
     │          │ PRレビュー │
     │          │ (Q3:      │
     │          │ ブロッカー │
     │          │ なら Q1)  │
     └──────────┼──────────┘
              緊急度 低

判断のポイント

本番バグ（Q1）: ユーザーに影響 + 決済関連 = 最優先
PRレビュー: ブロッカーかどうかで判断が分かれる
- チームメンバーが完全にブロックされている → Q1に格上げ
- 他のタスクを進められる → Q3（今日中に対応）
API設計（Q2）: 重要だが水曜までにOK → 計画的に時間を確保

優先度判断の実践ガイドライン

ビジネスインパクトで重要度を判断する

レベル	影響範囲	例
Critical	全ユーザー、売上に直結	サービス全停止、決済不能
High	多くのユーザー、主要機能	主要機能のバグ、パフォーマンス劣化
Medium	一部ユーザー、補助機能	特定条件でのUI崩れ
Low	ごく少数、見た目のみ	誤字、軽微なデザインずれ

時間的制約で緊急度を判断する

レベル	基準
即時対応	今すぐ（本番障害、セキュリティインシデント）
今日中	当日内に完了が必要
今週中	週内に完了が必要
今月中	月内に完了が必要
いつでも	明確な期限なし

迷ったときの判断フロー

タスクが来た
  │
  ├─ ユーザーに直接影響している？
  │    ├─ Yes → Q1（即対応）
  │    └─ No ↓
  │
  ├─ 他のメンバーがブロックされている？
  │    ├─ Yes → Q1 or Q3（相手の緊急度による）
  │    └─ No ↓
  │
  ├─ 今日/明日が期限？
  │    ├─ Yes → Q1（期限を確認）
  │    └─ No ↓
  │
  ├─ プロジェクト目標に直結する？
  │    ├─ Yes → Q2（計画に組み込む）
  │    └─ No ↓
  │
  └─ Q3 or Q4（効率化/委任/削除を検討）

よくある間違い

1. 全てをQ1に入れてしまう

「急ぎ」と言われたからといって、全てが本当に緊急とは限りません。依頼者に確認しましょう。

聞き方の例: 「このタスクの期限はいつですか？」「他のメンバーがブロックされていますか？」

2. Q2を後回しにし続ける

重要だが急がないタスク（設計改善、テスト充実、学習）を常に後回しにすると、いずれQ1（緊急かつ重要）として降りかかってきます。

Q2を放置した結果

テスト不足（Q2）     →  本番バグ頻発（Q1）
ドキュメント不備（Q2） →  チーム内の誤解による手戻り（Q1）
リファクタリング延期（Q2） → 開発速度の低下、大規模障害（Q1）

3. 自分だけで判断する

優先度の判断に迷ったら、マネージャーやチームリーダーに相談しましょう。「AとBのどちらを先にやるべきですか？」と聞くことは、弱さではなく正しい判断力の表れです。

まとめ

ポイント	内容
優先度マトリクス	緊急度と重要度の2軸で4象限に分類
Q1（重要+緊急）	最優先で即対応
Q2（重要+非緊急）	最も価値のある象限。計画的に時間を確保
Q3（非重要+緊急）	効率化か委任を検討
Q4（非重要+非緊急）	削除か後回し

チェックリスト

優先度マトリクスの4象限を説明できる
具体的なタスクを4象限に分類できる
Q2の重要性を理解した
迷ったときの判断フローを使える

次のステップへ

次のセクションでは、優先順位をつけた後に実際にタスクを進めるための「タイムマネジメントの技術」を学びます。限られた時間の中で、いかに効率よくタスクを完了させるかを身につけましょう。

推定読了時間: 25分