演習：困難なプロジェクトシミュレーション

ストーリー

「いよいよ実践だ。困難なプロジェクトのシミュレーションをやろう」

渡辺マネージャーが複雑なシナリオを用意した。

「計画通りには進まない。問題が次々と起きる。 その中で、ここまで学んだ全てのスキルを使って プロジェクトを完遂させてくれ」

演習の概要

仮想プロジェクト「ECサイト コンビニ決済機能追加」のリーダーとして、プロジェクト計画の作成からリスク対応、ステークホルダー管理、振り返りまでを一通り実施してください。

課題1: プロジェクト計画書の作成

以下の情報をもとに、プロジェクト計画書を作成してください。

プロジェクト情報

• 期間: 8週間（3月3日〜4月25日）
• チーム: 4名（あなた、田中、鈴木、佐藤（リモート・50%稼働））
• 目標: コンビニ決済（ローソン、ファミマ、セブン）をECサイトに追加
• 外部依存: 決済代行サービスA社のAPI
• 制約: セキュリティ審査が必要（リリース2週間前に提出）

# プロジェクト計画書 - コンビニ決済機能追加

## ゴール（SMART）
4月25日までに、主要コンビニ3社（ローソン、ファミマ、セブン）の
決済機能をECサイトに追加し、決済完了率95%以上を達成する。

## スコープ
### やること
- コンビニ決済のAPI連携（A社決済代行サービス経由）
- 決済画面のUI実装（バーコード表示）
- 決済ステータス管理（Webhook受信）
- 管理画面での決済一覧表示
- セキュリティ審査対応

### やらないこと
- モバイルアプリ対応
- コンビニ3社以外の対応
- 既存クレジットカード決済の改修

## マイルストーン
| M# | マイルストーン | 日付 | 成果物 |
|----|-------------|------|--------|
| M1 | 設計完了 | 3/14 | 設計書、API仕様書 |
| M2 | API連携完了 | 3/28 | 決済APIクライアント |
| M3 | 全機能実装完了 | 4/11 | 全機能統合 |
| M4 | セキュリティ審査提出 | 4/11 | 審査書類 |
| M5 | テスト完了 | 4/18 | テスト報告書 |
| M6 | 本番リリース | 4/25 | リリース |

## リソース配分
| メンバー | 担当 | 稼働率 |
|---------|------|--------|
| あなた | バックエンドAPI、全体リード | 100% |
| 田中 | フロントエンド、UI | 100% |
| 鈴木 | テスト、ドキュメント | 80% |
| 佐藤 | 外部API連携、セキュリティ | 50% |

## リスク管理表
| リスク | 確率 | 影響 | 対策 |
|--------|------|------|------|
| A社API仕様変更 | 中 | 高 | 抽象化レイヤーで変更を吸収 |
| セキュリティ審査不合格 | 低 | 高 | 設計段階で事前レビュー |
| 佐藤さんの稼働不足 | 高 | 中 | 佐藤さん担当を前倒しで完了 |
| 見積もり超過 | 中 | 中 | 各フェーズに20%バッファ |

## コミュニケーション計画
| 対象 | 頻度 | 方法 |
|------|------|------|
| チーム | 毎日 | デイリースタンドアップ |
| PO | 週次 | 進捗報告ミーティング |
| A社 | 隔週 | 技術打ち合わせ |
| セキュリティチーム | M1, M4時 | レビューミーティング |

課題2: トラブル対応シミュレーション

プロジェクト進行中に以下の3つのトラブルが発生しました。それぞれへの対応を作成してください。

トラブル1: Week 3 - A社のAPI仕様が大幅変更

A社から「APIバージョンアップにより、認証方式がOAuth1.0からOAuth2.0に変更」との連絡。既存の実装を修正する必要があり、3日の追加工数が見込まれる。

トラブル2: Week 5 - 鈴木さんがインフルエンザで1週間休み

テスト計画を担当していた鈴木さんが1週間離脱。テストフェーズの開始が迫っている。

トラブル3: Week 6 - POからスコープ追加依頼

POから「PayPay対応も追加してほしい。経営からの要請だ」との依頼。

トラブル1への対応

【渡辺マネージャーへの報告（STAR法）】

S: A社からAPI認証方式の変更（OAuth1.0→2.0）の連絡がありました。
T: 修正に3日かかり、M2（API連携完了 3/28）が3/31にずれます。
   バッファ内で吸収可能ですが、バッファの60%を消費します。
A: 対応方針:
   - 佐藤さんと協力してOAuth2.0対応を最優先で実施
   - 認証ライブラリを抽象化し、今後の変更に備える
   - A社との定例を週次に変更し、追加変更を早期キャッチ
R: M2の3日遅延を承認いただきたい。
   M3以降への影響は最小限に抑えます。

トラブル2への対応

【対応計画】

1. 即時対応:
   - 鈴木さんの担当タスクを確認・整理
   - テスト計画書のドラフトはあなたが引き継ぐ
   - テストケースの作成は田中さんが一部分担

2. スケジュール調整:
   - テストフェーズ開始を2日後ろ倒し
   - 鈴木さん復帰後に集中的にテスト実施
   - バッファの残りで吸収（限界ギリギリ）

3. リスク軽減:
   - 実装フェーズ中に開発者テストを厚めに実施
   - 自動テストの比率を上げ、手動テストの負荷を減らす

4. 鈴木さんへのフォロー:
   - 復帰後のキャッチアップ用に状況メモを更新
   - 無理をしないよう配慮

トラブル3への対応

【POへの回答】

「PayPay対応のご要望、承知しました。
 影響を分析させてください。

 分析結果:
 - PayPay対応に追加2週間の工数が必要
 - 現在のスケジュールに含めると、リリースが5/9に延期

 選択肢を3つ用意しました:

 A案: リリースを5/9に延期し、PayPayを含める
   メリット: 一度に全決済手段をリリース
   デメリット: 2週間の遅延

 B案: 4/25にコンビニ決済をリリースし、PayPayは5/16にフェーズ2リリース
   メリット: コンビニ決済は予定通り
   デメリット: リリースが2回に分かれる

 C案: コンビニ決済のうち1社を削除し、PayPayを代わりに追加
   メリット: スケジュール維持
   デメリット: 当初スコープの一部が欠ける

 推奨はB案です。コンビニ決済を予定通りリリースすることで、
 ステークホルダーの信頼を維持しつつ、PayPayも確実に提供できます。

 判断をお願いします。」

課題3: スプリント振り返り（KPT）の実施

プロジェクトの4週目（折り返し地点）で、チーム振り返りを実施します。以下の状況を踏まえて、KPTを作成してください。

4週目の状況

• M1（設計完了）は1日遅れで完了
• M2（API連携完了）は3日遅れ（A社変更の影響）
• PRレビューSLAは85%達成
• デイリースタンドアップは平均14分
• リモートの佐藤さんから「情報共有が改善された」とフィードバック
• テスト環境が2回ダウンした

# Sprint 2 振り返り（KPT）

## Keep（続けること）
- デイリースタンドアップが15分以内に収まっている（平均14分）
- #decisions チャンネルの運用が定着（佐藤さんからのフィードバックが改善）
- PRレビューSLA 85%達成（目標90%にはもう少し）
- 外部API変更にチームが迅速に対応できた

## Problem（問題だったこと）
- A社のAPI変更で3日遅延。バッファの60%を消費済み
- テスト環境が2回ダウンし、計4時間のロス
- M1の遅延（設計レビューのフィードバックループが長かった）
- 佐藤さんの稼働が想定50%だが実際は40%程度

## Try（次のスプリントで試すこと）
1. テスト環境をDocker化して安定性を向上 [田中] 今週中
2. 設計レビューは非同期（PR形式）で実施し、リードタイムを短縮 [あなた] 即日
3. 佐藤さんの担当タスクを前倒しで完了させるため、
   今週中に佐藤さんの残タスクを集中消化 [佐藤 + あなた] 今週中

## 前回のTry確認
（初回のため該当なし）

## アクションアイテム
| 担当 | アクション | 期限 |
|------|-----------|------|
| 田中 | テスト環境Docker化 | 今週金曜 |
| あなた | 設計レビューのPR化ルール策定 | 明日 |
| あなた + 佐藤 | 外部API連携の残タスク消化 | 今週金曜 |

達成度チェック

まとめ

チェックリスト

• プロジェクト計画書を体系的に作成できた
• 3つのトラブルに対して適切な対応を考えられた
• KPTで具体的な改善アクションを設定できた
• ステークホルダーへの報告を適切に作成できた

次のステップへ

演習が完了したら、Step 5のチェックポイントクイズに挑戦しましょう。

推定所要時間: 90分