アイゼンハワーマトリクスの活用

ストーリー

水曜日の朝、スプリントプランニングが終わった。あなたのスプリントバックログには12個のタスクが積まれている。

渡辺マネージャーが声をかけた。

「12個のタスク、どの順番で進める？」

「えーと、上から順番に......」

「それだと本当に大事なものが後回しになるかもしれない。 Step 1で学んだ優先度マトリクスを、もっと実践的に使ってみよう。アイゼンハワー大統領が使っていた意思決定の枠組みだ」

アイゼンハワーマトリクスとは

第34代アメリカ大統領ドワイト・D・アイゼンハワーの言葉に基づくフレームワークです。

"What is important is seldom urgent and what is urgent is seldom important." （重要なことは滅多に緊急ではなく、緊急なことは滅多に重要ではない）

Step 1で学んだ優先度マトリクスをより体系的に実務に適用する手法です。

4つのアクション

                    緊急
           高 ──────────── 低
          │              │
  重  高  │  DO(実行)     │  SCHEDULE(計画)
  要      │  今すぐやる   │  いつやるか決める
  度      │              │
          ├──────────────┤
          │              │
      低  │  DELEGATE     │  DELETE(削除)
          │  (委任)       │  やらない
          │  誰かに任せる │
          │              │

アクション	説明	具体的な行動
DO	今すぐ自分でやる	即座に着手。他の作業を中断してでも
SCHEDULE	いつやるか決めて計画に入れる	カレンダーに時間を確保。ブロックする
DELEGATE	他の人に任せる	依頼先を特定し、明確に委任する
DELETE	やらない判断をする	タスクリストから削除。勇気を持って

エンジニアの実務での適用

シナリオ: スプリント中の12タスク

以下の12タスクをアイゼンハワーマトリクスで分類してみましょう。

#	タスク	緊急度	重要度	分類
1	本番のログインエラー修正	高	高	DO
2	新機能のAPI設計	低	高	SCHEDULE
3	定例ミーティングの議事録作成	高	低	DELEGATE
4	使われていないコードの削除	低	低	DELETE
5	セキュリティパッチの適用	高	高	DO
6	テストカバレッジの向上	低	高	SCHEDULE
7	社内ツールのUI微調整依頼	高	低	DELEGATE
8	技術ブログの執筆	低	低	DELETE（or後回し）
9	ブロッカーになっているPRレビュー	高	高	DO
10	CI/CDパイプラインの改善	低	高	SCHEDULE
11	Slackボットの不具合対応	高	低	DELEGATE
12	アーキテクチャ設計書の更新	低	高	SCHEDULE

分類結果の整理

DO（今すぐ）:
  #1 本番ログインエラー
  #5 セキュリティパッチ
  #9 ブロッカーPRレビュー

SCHEDULE（計画）:
  #2  API設計         → 木曜午前に2時間確保
  #6  テストカバレッジ → 金曜午後に3時間確保
  #10 CI/CD改善      → 来週のスプリントで計画
  #12 設計書更新     → 金曜の空き時間に

DELEGATE（委任）:
  #3  議事録作成 → 今週の議事録担当に依頼
  #7  UI調整    → フロントエンド担当の田中さんに依頼
  #11 Slackボット → インターンの鈴木さんに依頼（学習機会として）

DELETE（削除）:
  #4 不要コード削除 → 今は不要。リファクタリングスプリントで再検討
  #8 技術ブログ   → 今月は見送り

判断が難しいケースへの対処

ケース1: 「全部緊急」と言われた場合

依頼者に具体的な質問をして、本当の緊急度を見極めます。

質問	目的
「いつまでに必要ですか？」	明確な期限を確認
「これが遅れると誰が困りますか？」	影響範囲を把握
「仮に明日対応だと問題ありますか？」	本当の緊急度を確認
「AとBのどちらを先にすべきですか？」	相対的な優先順位を確認

ケース2: 重要度の判断が難しい場合

以下の基準で点数をつけて判断します。

基準	3点	2点	1点
ビジネス影響	売上・ユーザー直結	間接的に影響	ほぼ影響なし
影響人数	チーム全体/多数ユーザー	数名のメンバー	自分だけ
目標達成への貢献	スプリントゴールに直結	関連している	関連なし
技術的リスク	放置すると障害発生	徐々に悪化	現状維持

合計10点以上 → 高重要度、6〜9点 → 中重要度、5点以下 → 低重要度

ケース3: SCHEDULEが溜まり続ける場合

Q2（重要だが緊急でない）タスクが消化できない場合の対策です。

対策1: 週にQ2専用の時間を確保する
  → 毎週水曜午後は「改善タイム」としてブロック

対策2: Q2タスクにも締め切りを設定する
  → 「テストカバレッジ向上」→ 今月末までに70%達成

対策3: Q2タスクをスプリントバックログに入れる
  → プロダクトバックログではなく、スプリントの公式タスクに

チームでの活用方法

スプリントプランニングでの活用

1. バックログのタスクをマトリクスに配置
2. DOの合計が2〜3割になるように調整
3. SCHEDULEを5〜6割確保（これが本来の仕事）
4. DELEGATEとDELETEで2〜3割を削減

デイリースタンドアップでの活用

「今日のDOタスク:
  - 本番バグの修正（完了見込み: 午前中）

 今日のSCHEDULEタスク:
  - API設計ドラフト（午後に2時間）

 ブロッカー: なし」

週次レビューでの活用

毎週末にマトリクスを見直し、以下を確認します。

DO象限にタスクが溜まりすぎていないか
SCHEDULE象限のタスクが実際に進んでいるか
DELEGATE したタスクが進んでいるか
DELETE すべきなのに残っているタスクはないか

まとめ

ポイント	内容
4アクション	DO（実行）、SCHEDULE（計画）、DELEGATE（委任）、DELETE（削除）
判断基準	ビジネス影響、影響人数、目標貢献度、技術リスクで点数化
SCHEDULEの確保	専用時間をブロックし、締め切りを設定する
チーム活用	スプリントプランニング、デイリースタンドアップで共有

チェックリスト

4つのアクション（DO/SCHEDULE/DELEGATE/DELETE）を説明できる
具体的なタスクをマトリクスに分類できる
判断が難しいケースへの対処法を知っている
SCHEDULEタスクが溜まらないための対策を理解した

次のステップへ

次のセクションでは、タスクの「見積もり」をより高度に行う技術を学びます。ストーリーポイントやTシャツサイズなど、チームで使われる見積もり手法を身につけましょう。

推定読了時間: 30分