総合演習：プロジェクトタスク管理シミュレーション

ストーリー

「いよいよ総合演習だね。これまで学んだことを全部使うよ」

「タスク管理ツール、優先順位、締め切り管理、複数タスク、ブロッカー対応...全部ですか？」

「そう。2週間のプロジェクトをシミュレーションしよう。新人エンジニアとして、プロジェクトを完遂させてみて」

シミュレーション概要

あなたは新人エンジニアです。「社内ポータルサイト」プロジェクトのフロントエンド実装を担当しています。

プロジェクト情報

プロジェクト: 社内ポータルサイト リニューアル
あなたの担当: フロントエンド実装
期間: 2週間（2/2（月）〜 2/13（金））
最終期限: 2/13（金）17:00 リリース

担当タスク

合計: 36時間

チームメンバー

• 佐藤さん（上司・PM）
• 田中さん（先輩エンジニア・メンター）
• 山田さん（バックエンドAPI担当）
• 高橋さん（デザイナー）

Mission 1: プロジェクト計画を立てる

Week 1 の計画

2週間のプロジェクト計画を立ててください。

制約条件:

• 1日の作業可能時間: 6時間（会議・休憩除く）
• 固定ミーティング:
  • 毎日 9:30-9:45 デイリースタンドアップ
  • 金曜 16:00-17:00 週次レビュー
• API完成予定:
  • お知らせAPI: 2/5（木）
  • ユーザー設定API: 2/7（土）→ 2/9（月）に変更の可能性あり

タスク: 2週間の計画を立ててください

【Week 1: 2/2（月）〜 2/6（金）】

月曜日（2/2）:

火曜日（2/3）:

水曜日（2/4）:

木曜日（2/5）:

金曜日（2/6）:

【Week 2: 2/9（月）〜 2/13（金）】

月曜日（2/9）:

火曜日（2/10）:

水曜日（2/11）:

木曜日（2/12）:

金曜日（2/13）:

【マイルストーン】
Week 1 終了時点の目標:

Week 2 中間（2/11）時点の目標:

最終目標:

【Week 1: 2/2（月）〜 2/6（金）】

月曜日（2/2）:
- タスクA: トップページ実装（4h）
- タスクB: ナビゲーション実装（2h）着手

火曜日（2/3）:
- タスクB: ナビゲーション実装（2h）完了
- タスクA: トップページ実装（4h）完了

水曜日（2/4）:
- レビュー対応、微調整（2h）
- バッファ/予備時間（4h）

木曜日（2/5）: ※お知らせAPI完成予定
- タスクC: お知らせ一覧実装（6h）着手

金曜日（2/6）:
- タスクC: お知らせ一覧実装 完了
- 週次レビュー

【Week 2: 2/9（月）〜 2/13（金）】

月曜日（2/9）: ※ユーザー設定API完成予定
- タスクD: ユーザー設定画面実装（4h）着手
- レビュー対応（2h）

火曜日（2/10）:
- タスクD: ユーザー設定画面実装（4h）完了

水曜日（2/11）: ※祝日の可能性あり（要確認）
- タスクE: レスポンシブ対応（4h）
- バッファ（2h）

木曜日（2/12）:
- タスクF: テスト・バグ修正（4h）
- タスクG: 本番デプロイ準備（2h）

金曜日（2/13）: ★最終日
- 最終テスト、微調整（3h）
- 本番リリース（16:00目標）
- 週次レビュー

【マイルストーン】
Week 1 終了時点の目標:
- A, B, C 完了（18h分）
- 進捗: 50%

Week 2 中間（2/11）時点の目標:
- D, E 完了
- 進捗: 83%

最終目標:
- 全タスク完了
- 2/13 17:00 リリース

Mission 2: 優先順位と見積もり

状況

Week 1 の水曜日（2/4）です。以下の追加タスクが発生しました。

タスク: 優先順位をつけ、計画を修正してください

【優先順位】
1位:
2位:
3位:

【理由】


【修正した計画】
水曜日（2/4）:

木曜日（2/5）:

金曜日（2/6）:

【優先順位】
1位: H（既存ページのバグ修正）
2位: I（デザイン変更対応）
3位: J（ドキュメント作成）

【理由】
■ H が最優先の理由:
- 本番環境のバグ → ユーザーに影響
- 期限が今日中 → 緊急
- アイゼンハワーマトリクス: 重要×緊急（第1象限）

■ I が2番目の理由:
- トップページは既に完成予定だが、変更が必要
- 期限が2/6 → 週内対応必須
- デザイン変更後にレスポンシブ対応をしたい

■ J が3番目の理由:
- 期限が2/13 → 余裕がある
- 他の実装が優先
- Week 2 で対応可能

【修正した計画】
水曜日（2/4）:
- 午前: H（バグ修正 1h）★優先
- 午後: バッファ消化 → 予定通りレビュー対応
- 残り: 予備として確保

木曜日（2/5）:
- タスクC: お知らせ一覧実装（6h）
- ※予定通り

金曜日（2/6）:
- タスクC: 完了
- タスクI: デザイン変更対応（3h）
- 週次レビュー

※タスクJは Week 2 のバッファで対応

Mission 3: ブロッカー対応

状況

Week 1 の木曜日（2/5）です。お知らせAPIを使おうとしたところ、問題が発生しました。

山田さんから連絡:
「すみません、お知らせAPIの完成が2日遅れて
 2/7（金）になりそうです。テストで問題が見つかりました」

現在の状況:

• タスクC（お知らせ一覧）はAPIがないと実装できない
• タスクD（ユーザー設定）もAPIが2/9予定
• 期限は変わらず2/13

タスク: どう対応しますか？

【ブロッカーの影響分析】
影響を受けるタスク:

影響を受けない作業:

【対応案】
案1:

案2:

案3:

【選択する案と理由】

【上司への報告】
（ここに報告内容を書く）

【ブロッカーの影響分析】
影響を受けるタスク:
- タスクC: お知らせ一覧実装（2日遅れ）
- タスクE, F, G: Cに依存するため連鎖的に遅れる可能性

影響を受けない作業:
- タスクI: デザイン変更対応（トップページ）
- スタイル調整、リファクタリング
- タスクJ: ドキュメント作成

【対応案】
案1: 待機して他の作業を先にやる
- API待ちの間に I, J を進める
- API完成後にCを実装
- メリット: 無駄がない
- デメリット: スケジュールがタイトになる

案2: モックAPIで仮実装を進める
- ダミーデータでフロントエンドを先に実装
- API完成後に接続
- メリット: 時間を有効活用できる
- デメリット: API仕様が変わると手戻りの可能性

案3: スケジュール延期を交渉
- 全体スケジュールを2日延期
- メリット: バッファが確保できる
- デメリット: プロジェクト全体に影響

【選択する案と理由】
案2（モックAPIで仮実装）を選択。

理由:
- 期限は動かせない前提
- API仕様は仕様書で確認済み、大きな変更は少ないと想定
- フロントエンドの構造は先に作れる
- 最悪、接続部分の調整で済む

【上司への報告】
「佐藤さん、お知らせ機能の進捗についてご報告します。

■ 状況:
山田さんからお知らせAPIの完成が2日遅れ（2/7）と
連絡がありました。テストで問題が見つかったとのことです。

■ 影響:
タスクC（お知らせ一覧）の実装開始が遅れます。
そのままだとE, F, Gにも影響が出る可能性があります。

■ 対応案:
API待ちの間、モックデータで仮実装を進めることで
スケジュールへの影響を最小限に抑えます。

具体的には:
- 2/5-2/6: モックAPIでフロントエンド構造を実装
- 2/7: 本物のAPIに接続してテスト

■ リスク:
API仕様が想定と異なる場合、調整に時間がかかる可能性

この方針で進めてよろしいでしょうか？」

Mission 4: 進捗管理と報告

状況

Week 1 の金曜日（2/6）、週次レビューの前です。今週の進捗を整理してください。

実際の進捗:

• タスクA: 完了（8h）
• タスクB: 完了（4h）
• タスクC: モックで80%完了、API接続待ち
• タスクH: 完了（1h）
• タスクI: 完了（3h）

発生した問題:

• お知らせAPIの遅延（2日）
• デザイン変更対応が追加された

タスク: 週次レビューでの報告を書いてください

【週次進捗報告】2026/02/06

■ 今週の計画と実績


■ 発生した問題と対応


■ 来週の計画


■ リスク・懸念事項


■ 相談事項

【週次進捗報告】2026/02/06

■ 今週の計画と実績
| タスク | 計画 | 実績 | 状態 |
|--------|------|------|------|
| A. トップページ | 8h | 8h | 完了 |
| B. ナビゲーション | 4h | 4h | 完了 |
| C. お知らせ一覧 | 6h | 5h | 80%（API待ち） |
| H. バグ修正（追加） | 1h | 1h | 完了 |
| I. デザイン変更（追加） | 3h | 3h | 完了 |

合計: 計画18h → 実績21h（追加タスク4h含む）
進捗率: 予定の50%達成

■ 発生した問題と対応
1. お知らせAPIの遅延（2日）
   - 原因: バックエンドのテストで問題発覚
   - 対応: モックAPIで仮実装を進め、影響を最小化
   - 状況: 2/7にAPI完成予定、接続テストを行う

2. デザイン変更の追加対応
   - 対応: バッファを使って対応完了

■ 来週の計画
| 曜日 | タスク | 見積もり |
|------|--------|----------|
| 月 | C完了、D着手 | 6h |
| 火 | D完了 | 6h |
| 水 | E（レスポンシブ） | 4h |
| 木 | F（テスト）、G（デプロイ準備） | 6h |
| 金 | 最終テスト、リリース | 4h |

■ リスク・懸念事項
1. ユーザー設定API（2/9予定）が遅れる可能性
   - 対応: お知らせAPIと同様、モックで対応可能

2. テスト・バグ修正のバッファが少ない
   - 対応: 木曜日に集中して対応

■ 相談事項
特になし。予定通り2/13リリースを目指します。

Mission 5: 最終日の対応

状況

最終日の2/13（金）12:00です。テストで重大なバグが見つかりました。

田中さんから:
「山本さん、テストしてたらユーザー設定画面で
 保存ボタンを押しても保存されないバグがあるよ」

状況:

• リリース予定: 17:00
• バグの原因: APIリクエストのパラメータ形式が間違っていた
• 修正見積もり: 30分〜1時間
• 修正後の再テストが必要

タスク: どう対応しますか？

【状況整理】
残り時間:
バグの重大度:
修正見積もり:

【対応】
（ここに対応を書く）

【上司への報告】
（ここに報告を書く）

【状況整理】
残り時間: 5時間（12:00〜17:00）
バグの重大度: 高（保存できないと機能として使えない）
修正見積もり: 30分〜1時間 + 再テスト30分 = 1〜1.5時間

【対応】
■ 即座に対応開始

12:00 - 12:30: バグの原因調査・修正
- APIリクエストのパラメータ形式を修正
- ローカル環境でテスト

12:30 - 13:00: 昼休み（短縮）

13:00 - 13:30: 修正をプッシュ、レビュー依頼
- 田中さんにレビューを依頼

13:30 - 14:00: レビュー対応

14:00 - 15:00: 再テスト（全機能）
- ユーザー設定画面を重点的に
- 他の画面にも影響がないか確認

15:00 - 16:00: バッファ（追加のバグ対応）

16:00 - 17:00: 本番デプロイ
- 手順に沿ってデプロイ
- 本番確認

【上司への報告】
「佐藤さん、緊急のご報告です。

■ 発生した問題:
テストでユーザー設定画面のバグが見つかりました。
保存ボタンを押しても保存されない状態です。

■ 原因:
APIリクエストのパラメータ形式の誤り

■ 対応:
すでに修正を開始しています。
修正と再テストで約1.5時間の見込みです。

■ リリースへの影響:
17:00のリリースには間に合う見込みです。
ただし、追加のバグが見つかった場合は
リリース時刻を遅らせる必要があるかもしれません。

その場合は改めてご相談させてください。
現在は対応を最優先で進めています」

達成度チェック

スキルチェックリスト

• 依存関係を考慮した計画が立てられた
• 追加タスクを適切に組み込めた
• ブロッカー発生時に代替案を考えられた
• 進捗を正確に報告できた
• 緊急事態に冷静に対応できた

まとめ

次のステップへ

プロジェクトタスク管理シミュレーション、お疲れさまでした！

次は最後の「卒業クイズ」です。Month 7で学んだすべての内容から出題されます。

推定所要時間: 90分