演習:優先順位をつけてみよう
ストーリー
「優先順位の考え方、見積もりの方法、全部学んだね」
「はい!でも実際にやってみないと身につかないですよね」
「その通り。実際のタスクリストで優先順位をつける練習をしよう」
ミッション概要
5つのシナリオでタスクの優先順位をつけ、その理由を説明してください。
達成条件
- 5つのシナリオすべてで優先順位をつけた
- 優先順位の理由を説明できた
- アイゼンハワーマトリクスを活用できた
シナリオ 1: 月曜の朝、タスクが5つある
状況
月曜日の朝、あなたは以下の5つのタスクを抱えています。
| # | タスク | 期限 | 依存関係 | 備考 |
|---|---|---|---|---|
| A | ユーザー画面のバグ修正 | 本日中 | なし | 本番で軽微なバグ発生中 |
| B | 新機能の設計ドキュメント作成 | 水曜日 | なし | 田中さんが確認待ち |
| C | コードレビュー依頼への対応 | 特になし | なし | 山田さんからの依頼 |
| D | 週次ミーティングの準備 | 本日15時 | なし | 進捗報告資料の作成 |
| E | 技術書を読む(自己学習) | なし | なし | スキルアップのため |
タスク: 優先順位をつけて、理由を説明してください
優先順位:
1位:
2位:
3位:
4位:
5位:
理由:
(ここに理由を書く)
<details>
<summary>解答例</summary>
優先順位:
1位: A(ユーザー画面のバグ修正)
2位: D(週次ミーティングの準備)
3位: C(コードレビュー依頼への対応)
4位: B(新機能の設計ドキュメント作成)
5位: E(技術書を読む)
理由:
■ A が1位の理由:
- 本番環境で問題が発生中 → ユーザーに影響がある
- 期限が本日中 → 緊急
- アイゼンハワーマトリクス: 重要×緊急(第1象限)
■ D が2位の理由:
- 期限が本日15時 → 緊急
- ミーティングに間に合わないとチームに影響
- アイゼンハワーマトリクス: 重要×緊急(第1象限)
- Aより優先度が低い理由: 本番障害の方が影響が 大きい
■ C が3位の理由:
- 明確な期限はないが、山田さんの作業をブロックしている可能性
- 他の人の待ちを作らない方がよい
- アイゼンハワーマトリクス: 重要×緊急でない(第2象限)
■ B が4位の理由:
- 期限は水曜日 → まだ余裕がある
- 田中さんが確認待ちなので早めに出したいが、今日でなくてもOK
- アイゼンハワーマトリクス: 重要×緊急でない(第2象限)
■ E が5位の理由:
- 期限なし、依存関係なし
- 自己成長のためには重要だが、今すぐやる必要はない
- アイゼンハワーマトリクス: 重要×緊急でない(第2象限)
- 他のタスクが終わった後、または別の時間に行う
</details>
シナリオ 2: 割り込みタスクが入った
状況
シナリオ1のタスクに取り組んでいる途中(10:30)に、上司から緊急の連絡がありました。
「本番環境のAPIサーバーが重くなっている。
原因調査を手伝ってほしい。
他の作業より優先で。」
現在の状況:
- A(バグ修正): 50%完了
- D(ミーティング準備): 未着手
- 新タスク F: 本番APIサーバーの原因調査
タスク: 優先順位を再設定し、午前中の行動計画を立てて ください
優先順位:
1位:
2位:
3位:
午前中(10:30〜12:00)の行動計画:
(ここに計画を書く)
<details>
<summary>解答例</summary>
優先順位:
1位: F(本番APIサーバーの原因調査)
2位: A(ユーザー画面のバグ修正)※残り50%
3位: D(週次ミーティングの準備)
午前中(10:30〜12:00)の行動計画:
10:30〜11:30: F(本番APIサーバーの原因調査)
- 上司から「他の作業より優先」と指示あり
- 本番環境の問題は最優先
- 1時間で初期調査を行い、状況を報告
11:30〜12:00: A(バグ修正の続き)
- 残り50%を進める
- 完了しなければ昼休み後に続きを行う
理由:
■ F を最優先にした理由:
- 上司からの明確な指示
- 本番環境の障害 → ユーザーへの影響大
- 複数人で対応が必要な可能性あり
■ A を中断した理由:
- Fの方が影響範囲が大きい
- A は軽微なバグで、数時間遅れても許容範囲
■ D について:
- 15時までに準備が必要
- 午後に時間を確保できる見込み
- 最悪、簡潔な報告でも対応可能
</details>
シナリオ 3: アイゼンハワーマトリクスに分類
状況
以下の8つのタスクをアイゼンハワーマトリクスの4象限に分類してください。
| # | タスク |
|---|---|
| 1 | 明日提出の見積もり資料作成 |
| 2 | 来月の資格試験の勉強 |
| 3 | 本番障害の対応(今発生中) |
| 4 | 不要なメールの削除 |
| 5 | チームの改善提案を考える |
| 6 | 突然の来客対応 |
| 7 | 1年後のキャリア計画を考える |
| 8 | ニュースサイトをチェック |
タスク: 4象限に分類してください
第1象限(重要×緊急): すぐやる
第2象限(重要×緊急でない): 計画的にやる
第3象限(重要でない×緊急): 委任または最小限で
第4象限(重要でない×緊急でない): やらない/後回し
<details>
<summary>解答例</summary>
第1象限(重要×緊急): すぐやる
- 3. 本番障害の対応(今発生中)
- 1. 明日提出の見積もり資料作成
第2象限(重要×緊急でない): 計画的にやる
- 2. 来月の資格試験の勉強
- 5. チームの改善提案を考える
- 7. 1年後のキャリア計画を考える
第3象限(重要でない×緊急): 委任または最小限で
- 6. 突然の来客対応
第4象限(重要でない×緊急でない): やらない/後回し
- 4. 不要なメールの削除
- 8. ニュースサイトをチェック
解説:
- 第2象限が最も重要:ここを計画的に進めることで、
将来の第1象限タスクを減らせる
- 第3象限は「緊急に見えるが重要でない」ものに注意
- 第4象限は思い切って削減または後回しにする
</details>
シナリオ 4: 見積もりをしてみよう
状況
新しいタスク「ユーザー検索機能の実装」を任されました。以下の情報をもとに、見積もりを行ってください。
機能概要:
- 検索フォーム(名前、メールで検索可能)
- 検索結果の一覧表示
- ページネーション
参考情報:
- 類似機能(お知らせ一覧)は先月4時間で実装した
- 検索機能は初めて実装する
- APIは山田さんが作成中(明後日完成予定)
タスク: 3点見積もりを行い、報告用の見積もりを作成してください
■ 作業分解:
(タスクを小さく分解してください)
■ 3点見積もり:
楽観的:
現実的:
悲観的:
■ 期待値:
(計算してください)
■ 報告する見積もり:
(バッファを含めてください)
■ 前提条件とリスク:
(書いてください)
<details>
<summary>解答例</summary>
■ 作業分解:
1. 検索フォームのHTML/CSS作成: 1時間
2. 検索フォームのバリデーション: 0.5時間
3. API連携(検索リクエスト): 1.5時間
4. 検索結果の一覧表示: 1.5時間
5. ページネーション実装: 1時間
6. テスト: 1時間
7. レビュー対応: 0.5時間
合計: 7時間
■ 3点見積もり:
楽 観的: 5時間
- すべてスムーズに進んだ場合
- お知らせ一覧の経験を活かせる部分が多い
現実的: 7時間
- 通常通り進んだ場合
- 検索機能は初めてなので少し余裕を見る
悲観的: 12時間
- 検索ロジックで詰まる
- APIの仕様に問題がある
- レビューで大きな修正が入る
■ 期待値:
(5 + 7 × 4 + 12) ÷ 6 = (5 + 28 + 12) ÷ 6 = 45 ÷ 6 = 7.5時間
■ 報告する見積もり:
約10時間(バッファ+30%含む)
※ 初めての検索機能のためバッファを多めに設定
■ 前提条件とリスク:
【前提条件】
- APIが予定通り明後日に完成すること
- デザインデータが確定していること
【リスク】
- 検索機能の実装が初めてのため、
想定外の問題が発生する可能性あり
- APIの仕様が不明確な場合、追加で2〜3時間かかる可能性
</details>
シナリオ 5: 依存関係を考慮した順番
状況
以下の5つのタスクがあります。依存関係を考慮して、実行順序を決めてください。
| # | タスク | 見積もり | 依存関係 |
|---|---|---|---|
| A | フロントエンド実装 | 4時間 | Cの完了後 |
| B | テスト作成 | 2時間 | A、Dの完了後 |
| C | API設計書の確認 | 1時間 | なし |
| D | バックエンドAPI実装 | 3時間 | Cの完了後 |
| E | デプロイ作業 | 1時間 | Bの完了後 |
タスク: 依存関係を整理し、実行順序を決めてください
依存関係の図:
(矢印で依存関係を表現してください)
実行順序:
1.
2.
3.
4.
5.
理由:
(ここに理由を書く)
<details>
<summary>解答例</summary>
依存関係の図:
C(API設計書の確認)
├── A(フロントエンド実装)
│ └── B(テスト作成)
│ └── E(デプロイ作業)
└── D(バックエンドAPI実装)
└── B(テスト作成)
または:
C → A → ┐
├→ B → E
C → D → ┘
実行順序:
1. C(API設計書の確認)- 1時間
2. D(バックエンドAPI実装)- 3時間
3. A(フロントエンド実装)- 4時間
※ D と A は C 完了後に並行作業可能
4. B(テスト作成)- 2時間
5. E(デプロイ作業)- 1時間
理由:
■ C が最初の理由:
- A と D の両方が C に依存している
- C が完了しないと A も D も開始できない
- 最も早く着手すべきタスク
■ D と A の順番:
- D と A は両方とも C に依存するが、お互いには依存しない
- 並行作業可能なら同時に進める
- 一人で作業する場合は、どちらを先にしてもOK
- D を先にした理由: A より見積もりが短いため、
早く B に渡せる可能性がある
■ B は A と D の両方が必要:
- A と D の両方が完了しないと B は開始できない
- クリティカルパスを意識する
■ E は最後:
- B が完了しないと E は開始できない
- 最終工程
</details>
達成度チェック
| シナリオ | 内容 | 完了 |
|---|---|---|
| 1 | 5つのタスクに優先順位をつけた | [ ] |
| 2 | 割り込み発生時の優先順位を再設定した | [ ] |
| 3 | 8つのタスクを4象限に分類した | [ ] |
| 4 | 3点見積もりを行った | [ ] |
| 5 | 依存関係を考慮した順番を決めた | [ ] |
スキルチェックリスト
- 期限、重要度、影響範囲を基準に優先順位をつけられた
- アイゼンハワーマトリクスを活用できた
- 割り込み 発生時に冷静に優先順位を見直せた
- 3点見積もりとバッファを含めた見積もりができた
- 依存関係を図示し、実行順序を決められた
まとめ
| シナリオ | 学んだこと |
|---|---|
| 1 | 基本的な優先順位付け |
| 2 | 割り込み対応と優先順位の再設定 |
| 3 | アイゼンハワーマトリクスの活用 |
| 4 | 3点見積もりとバッファ |
| 5 | 依存関係の整理 |
次のステップへ
優先順位付けの実践ができました。
次のセクションでは、Step 2で学んだ内容のチェックポイントに挑戦しましょう。
推定所要時間: 60分