ストーリー
水曜日の朝、スプリントプランニングが終わった。 あなたのスプリントバックログには12個のタスクが積まれている。
渡辺マネージャーが声をかけた。
アイゼンハワーマトリクスとは
第34代アメリカ大統領ドワイト・D・アイゼンハワーの言葉に基づくフレームワークです。
“What is important is seldom urgent and what is urgent is seldom important.” (重要なことは滅多に緊急ではなく、緊急なことは滅多に重要ではない)
Step 1で学んだ優先度マトリクスをより体系的に実務に適用する手法です。
4つのアクション
graph TD
subgraph Q1 ["DO(実行)<br/>緊急 x 重要"]
DO["今すぐやる"]
end
subgraph Q2 ["SCHEDULE(計画)<br/>非緊急 x 重要"]
SCHED["いつやるか決める"]
end
subgraph Q3 ["DELEGATE(委任)<br/>緊急 x 非重要"]
DEL["誰かに任せる"]
end
subgraph Q4 ["DELETE(削除)<br/>非緊急 x 非重要"]
DELETE["やらない"]
end
classDef do fill:#f8d7da,stroke:#dc3545,color:#000
classDef schedule fill:#d4edda,stroke:#28a745,color:#000
classDef delegate fill:#fff3cd,stroke:#856404,color:#000
classDef delete fill:#e2e3e5,stroke:#6c757d,color:#000
class DO do
class SCHED schedule
class DEL delegate
class DELETE 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分