総合演習：プロジェクトリーダーシミュレーション

ストーリー

「ここまでよく学んだ。最後の総合演習だ」

渡辺マネージャーが真剣な表情で言った。

「プロジェクトの最終週をシミュレーションする。タスク管理、報告、コミュニケーション、リスク対応...... 全てのスキルを統合して、チームの信頼に応えてくれ。これをクリアすれば、君はもう信頼されるメンバーだ」

演習の概要

プロジェクト「ECサイトコンビニ決済機能追加」の最終週（Week 8）をシミュレーションします。月曜から金曜の5日間で発生するイベントに対応し、プロジェクトを無事にリリースまで導いてください。

現在の状況（Week 8 月曜朝時点）

全機能の実装は完了
テストは90%完了（残り: E2Eテスト3件、パフォーマンステスト）
セキュリティ審査は合格済み
ステージング環境にデプロイ済み
金曜の17時が本番リリース予定

Day 1（月曜）: 週の計画

タスク

残りのタスクを整理し、月曜〜金曜のスケジュールを作成してください。

残タスク

タスク	担当	見積もり	依存関係
E2Eテスト残り3件	鈴木	4h	なし
パフォーマンステスト	あなた	3h	なし
ステージングでのUAT	PO + チーム	4h	E2E完了後
バグ修正（発見次第）	あなた/田中	バッファ8h	UAT後
リリース手順書作成	あなた	2h	なし
本番リリース	あなた + 田中	2h	全テスト完了後
リリース後モニタリング	全員	2h	リリース後

<details> <summary>解答例（自分で実装してから確認しよう）</summary>

markdown

# Week 8 スケジュール

## 月曜
- [鈴木] E2Eテスト残り3件（午前〜午後）
- [あなた] パフォーマンステスト（午前〜午後）
- [田中] リリース手順書のレビュー準備
- [あなた] リリース手順書ドラフト作成（夕方）

## 火曜
- [鈴木] E2Eテスト完了 + バグ報告
- [あなた] パフォーマンステスト完了 + 結果報告
- [あなた] リリース手順書完成
- [午後] UAT開始（PO + チーム全員）

## 水曜
- [午前] UAT継続
- [午後] バグ修正（発見されたバグの対応）
- [夕方] バグ修正のレビュー・マージ

## 木曜
- [午前] バグ修正の確認テスト
- [午後] リリースリハーサル（ステージング環境）
- [夕方] Go/No-Go判定ミーティング

## 金曜
- [午前] 最終確認・リリース前チェックリスト
- [14:00] 本番リリース実施
- [15:00] リリース後モニタリング開始
- [17:00] リリース完了確認・チーム打ち上げ

バッファ: 水〜木にバグ修正8h分を確保

</details>

Day 2（火曜）: 問題発生 - パフォーマンス未達

イベント

パフォーマンステストの結果、決済処理のレスポンスタイムが要件の3秒を超え、平均5秒かかっていることが判明しました。

タスク

渡辺マネージャーへの報告を作成（STAR法）
対応策を3つ提示
Go/No-Go判定への影響を分析

<details> <summary>解答例（自分で実装してから確認しよう）</summary>

【渡辺マネージャーへの報告】

S: パフォーマンステストの結果、決済処理のレスポンスタイムが
   平均5秒で、要件の3秒を超過しています。
   原因は外部決済APIの応答に3.5秒かかっていることです。

T: 金曜のリリースに影響する可能性があります。
   対策によってはリリース延期の判断が必要です。

A: 対応策を3つ用意しました。

   A案: 非同期処理に変更（工数: 1日）
     → ユーザーには「処理中」を表示し、バックグラウンドで決済処理
     → 完了後にメール通知
     → UXは若干変わるがレスポンスは1秒以内

   B案: 外部APIのタイムアウトを調整 + キャッシュ導入（工数: 半日）
     → 改善見込み: 5秒→3.5秒（まだ要件未達の可能性）

   C案: 要件を「5秒以内」に緩和（工数: 0）
     → POの承認が必要

   推奨はA案です。根本的な解決になり、将来的な拡張にも有利です。
   水曜に実装・テストを完了させ、木曜のGo/No-Go判定に間に合わせます。

R: A案で進めてよいか判断をお願いします。
   また、UX変更についてPOの承認が必要です。

</details>

Day 3（水曜）: UAT での追加バグ発見

イベント

UATでPOが以下の3つのバグを報告しました。

バグ	重要度	内容
BUG-1	Critical	セブンイレブンのバーコードが正しく表示されない
BUG-2	Medium	決済一覧画面のソート順が仕様と異なる
BUG-3	Low	決済完了画面の文言に誤字

タスク

バグの優先順位付けと担当割り当て
Go/No-Go判定への影響判断
チームへの指示を作成

<details> <summary>解答例（自分で実装してから確認しよう）</summary>

markdown

# バグ対応計画

## 優先順位と担当
| バグ | 優先度 | 担当 | 対応期限 | Go/No-Go影響 |
|------|--------|------|---------|-------------|
| BUG-1 | 最優先 | あなた | 水曜中 | リリースブロッカー |
| BUG-2 | 高 | 田中 | 木曜午前 | リリース前に修正必須 |
| BUG-3 | 低 | 鈴木 | リリース後でOK | ブロッカーではない |

## Go/No-Go判定への影響
- BUG-1が修正されない場合 → No-Go（リリース延期）
- BUG-2が修正されない場合 → 条件付きGo（後日ホットフィックス）
- BUG-3は影響なし

## チームへの指示（Slackメッセージ）

@channel UAT で3件のバグが報告されました。対応を割り振ります。

【最優先】BUG-1: セブンのバーコード表示不正
  → 自分が対応。今日中に修正・テスト・PR作成
  → 明日午前にレビュー → マージ

【高優先】BUG-2: 決済一覧のソート順
  → @tanaka 対応お願いします。明日午前中に修正・PR
  → 午後にレビュー → マージ

【低優先】BUG-3: 完了画面の誤字
  → @suzuki リリース後で構いません。来週対応お願いします

木曜15時のGo/No-Go判定までにBUG-1, BUG-2の修正完了が必要です。
進捗は随時 #proj-ec-general に投稿してください。
質問があればいつでもどうぞ。

</details>

Day 4（木曜）: Go/No-Go判定

タスク

Go/No-Go判定ミーティングで使用する資料を作成してください。以下を含めること。

リリース準備状況のサマリー
残リスク
Go/No-Goの推奨判断と根拠

<details> <summary>解答例（自分で実装してから確認しよう）</summary>

markdown

# Go/No-Go判定 - コンビニ決済機能リリース
日時: 2026/04/24 15:00
参加者: 渡辺マネージャー, PO, あなた, 田中, 鈴木, 佐藤

## リリース準備状況サマリー

| 項目 | ステータス | 備考 |
|------|-----------|------|
| 全機能実装 | 完了 | パフォーマンス改善含む |
| E2Eテスト | 完了 | 全件パス |
| パフォーマンステスト | 完了 | 非同期処理化で平均0.8秒達成 |
| セキュリティ審査 | 合格 | 3/28合格 |
| UAT | 完了 | BUG-1, BUG-2修正済み |
| BUG-1（バーコード表示） | 修正済み | テスト確認済み |
| BUG-2（ソート順） | 修正済み | テスト確認済み |
| BUG-3（誤字） | 未修正 | リリース後に対応（影響小） |
| リリース手順書 | 完了 | リハーサル実施済み |
| ロールバック手順 | 完了 | テスト済み |
| モニタリング設定 | 完了 | アラート設定済み |

## 残リスク
| リスク | 確率 | 影響 | 対策 |
|--------|------|------|------|
| リリース後の未検出バグ | 低 | 中 | ロールバック手順準備済み。モニタリング強化 |
| 外部API障害 | 低 | 高 | サーキットブレーカー実装済み。フォールバック画面あり |

## 推奨判断: Go

根拠:
1. 全てのリリースブロッカー（BUG-1, BUG-2）が修正済み
2. セキュリティ審査合格
3. パフォーマンス要件達成（平均0.8秒 < 目標3秒）
4. ロールバック手順が準備・テスト済み
5. モニタリングとアラートが設定済み

未修正のBUG-3（誤字）はリリース後に対応。
ユーザーへの影響はありません。

</details>

Day 5（金曜）: リリースと振り返り

タスク

リリース完了後のステークホルダーへの報告メールを作成
プロジェクト全体のKPTを作成

<details> <summary>解答例（自分で実装してから確認しよう）</summary>

リリース完了報告

件名: [ECサイト] コンビニ決済機能 本番リリース完了

関係者各位

コンビニ決済機能の本番リリースが完了しましたのでご報告します。

■ リリース概要
  日時: 2026/04/25 14:00
  対象: コンビニ決済（ローソン、ファミマ、セブン）
  ステータス: 正常稼働中

■ 確認結果
  - 決済処理: 正常動作確認済み
  - レスポンスタイム: 平均0.8秒（要件3秒以内を達成）
  - エラー率: 0%（リリース後1時間）

■ 今後の対応
  - リリース後24時間のモニタリングを実施中
  - 軽微なバグ（BUG-3: 画面文言の誤字）は来週修正予定
  - 何か問題がありましたら #proj-ec-alerts でご連絡ください

ご協力いただいた皆様、ありがとうございました。

プロジェクト全体のKPT

markdown

# プロジェクト振り返り - コンビニ決済機能追加

## Keep
- デイリースタンドアップの効率化（平均14分を維持）
- #decisions チャンネルによるリモート情報共有
- PRレビューSLAの運用（最終的に92%達成）
- UATでのバグ発見→修正のスピード感
- リスク管理表による事前対策が機能した

## Problem
- A社のAPI仕様変更で3日遅延（バッファ消費）
- パフォーマンス問題の発見がWeek 7と遅かった
- 佐藤さんの実稼働が想定50%→40%だった
- 初期の設計レビューに時間がかかりすぎた

## Try（次のプロジェクトで）
1. パフォーマンステストを実装フェーズ中に並行実施
2. 外部API連携はリスクバッファを30%追加
3. 設計レビューはPR形式の非同期を標準にする

</details>

達成度チェック

Day	課題	完了
Day 1	週間スケジュールの作成	[ ]
Day 2	パフォーマンス問題の報告と対策	[ ]
Day 3	バグ対応の優先順位付けと指示	[ ]
Day 4	Go/No-Go判定資料の作成	[ ]
Day 5	リリース報告とプロジェクトKPT	[ ]

まとめ

ポイント	内容
計画力	残タスクを整理し、バッファを含むスケジュールを作成
問題対応	STAR法で報告し、複数の対応策を提示
判断力	バグの優先順位をつけ、Go/No-Go判断の根拠を示す
コミュニケーション	ステークホルダーに適切なレベルで報告
振り返り	プロジェクト全体からの学びを整理

チェックリスト

全5日分のシミュレーションを完了した
各場面で適切なフレームワークを使えた
チームへの指示が明確で実行可能だった
ステークホルダーへの報告が適切だった

次のステップへ

最後の卒業クイズに挑戦しましょう。今月学んだ全てのスキルの総合力を確認します。

推定所要時間: 60分