プロジェクト計画の立て方

ストーリー

「来月から新プロジェクトが始まる。 ECサイトに新しい決済方法を追加するんだ。期間は2ヶ月。君にはプロジェクトの計画作成を任せたい」

渡辺マネージャーの言葉に驚いた。

「え、自分がですか？」

「ここまで学んできたタスク管理、見積もり、報告のスキルを全て使う場面だ。プロジェクト計画の立て方を教えるから、チームの信頼に応えてくれ」

プロジェクト計画の全体像

プロジェクト計画に含める要素

プロジェクト計画
  │
  ├─ ゴールと成功基準
  │    └─ 何を、いつまでに、どの品質で
  │
  ├─ スコープ（範囲）
  │    ├─ やること
  │    └─ やらないこと
  │
  ├─ WBS（作業分解構成）
  │    └─ タスクの洗い出しと構造化
  │
  ├─ スケジュール
  │    ├─ マイルストーン
  │    └─ 依存関係
  │
  ├─ リソース計画
  │    └─ 誰が何を担当するか
  │
  ├─ リスク管理計画
  │    └─ 想定リスクと対策（次セクションで詳細）
  │
  └─ コミュニケーション計画
       └─ 報告頻度、ステークホルダー

ゴールと成功基準の定義

SMARTゴール

要素	意味	例
Specific（具体的）	何をするか明確	コンビニ決済機能を追加する
Measurable（測定可能）	達成を測定できる	決済完了率95%以上
Achievable（達成可能）	現実的に可能	2ヶ月、4人チームで実現可能
Relevant（関連性）	ビジネス目標に貢献	決済手段追加で売上10%向上見込み
Time-bound（期限あり）	期限が明確	4月末リリース

成功基準の例

markdown

プロジェクト: コンビニ決済機能追加

成功基準:
  - [ ] 4月30日までに本番リリースが完了
  - [ ] 主要コンビニ3社（ローソン、ファミマ、セブン）対応
  - [ ] 決済完了率95%以上
  - [ ] レスポンスタイム3秒以内
  - [ ] セキュリティ審査合格

スコープの定義

やること / やらないことを明確にする

やること（In Scope）:
  ✓ コンビニ決済のAPI連携
  ✓ 決済画面のUI実装
  ✓ バーコード生成機能
  ✓ 決済ステータスの管理
  ✓ 管理画面での決済一覧表示

やらないこと（Out of Scope）:
  ✗ 既存のクレジットカード決済の改修
  ✗ モバイルアプリ対応（Web版のみ）
  ✗ コンビニ3社以外の対応
  ✗ 多言語対応

重要: 「やらないこと」を明確にすることで、スコープクリープ（範囲の際限ない拡大）を防ぎます。

WBS（Work Breakdown Structure）

タスクの洗い出しと構造化

1. 設計フェーズ（2週間）
   1.1 要件定義の確認
   1.2 外部決済API仕様の調査
   1.3 DB設計
   1.4 API設計
   1.5 UI/UXデザイン
   1.6 設計レビュー

2. 実装フェーズ（4週間）
   2.1 決済APIクライアントの実装
   2.2 バックエンドAPI実装
   2.3 DB マイグレーション
   2.4 フロントエンド実装
   2.5 管理画面実装
   2.6 単体テスト

3. テストフェーズ（1週間）
   3.1 結合テスト
   3.2 E2Eテスト
   3.3 セキュリティテスト
   3.4 パフォーマンステスト

4. リリースフェーズ（1週間）
   4.1 ステージング環境デプロイ
   4.2 UAT（ユーザー受入テスト）
   4.3 本番リリース
   4.4 モニタリング設定

スケジュールとマイルストーン

マイルストーンの設定

     3月                    4月
  W1    W2    W3    W4    W5    W6    W7    W8
  |─────|─────|─────|─────|─────|─────|─────|
  [  設計  ]                                    ← M1: 設計完了
              [     実装フェーズ     ]           ← M2: 実装完了
              [API] [Backend][Frontend]
                                    [テスト]    ← M3: テスト完了
                                          [リリース] ← M4: 本番リリース

  M1: 3/14 設計レビュー完了
  M2: 4/11 全機能実装完了
  M3: 4/18 テスト完了・セキュリティ審査合格
  M4: 4/30 本番リリース

依存関係の管理

タスク	前提条件	ブロッカーになる場合の影響
API実装	外部API仕様の確定	仕様遅延 → 実装全体が遅延
フロントエンド	UI/UXデザイン完了	デザイン遅延 → フロント着手不可
結合テスト	API + フロント完了	実装遅延 → テスト期間圧縮
本番リリース	セキュリティ審査合格	審査不合格 → リリース延期

リソース計画

担当の割り当て

メンバー	担当領域	稼働率
あなた	バックエンドAPI、DB	100%
田中	フロントエンド、UI	100%
鈴木	テスト、ドキュメント	80%（研修20%）
佐藤	外部API連携、セキュリティ	50%（他PJ兼務）
渡辺マネージャー	全体管理、ステークホルダー連携	30%

クリティカルパスの特定

プロジェクト完了までの最長経路（クリティカルパス）を特定し、重点管理します。

クリティカルパス:
  外部API仕様確定 → API実装 → 結合テスト → セキュリティ審査 → 本番リリース

  → このパス上のタスクが1日遅れると、プロジェクト全体が1日遅れる
  → 重点的にモニタリングし、早期に問題を検知する

コミュニケーション計画

対象	頻度	方法	内容
チーム全体	毎日	デイリースタンドアップ	進捗、ブロッカー
渡辺マネージャー	週次	1on1 + 進捗報告書	詳細な進捗、リスク、判断事項
プロダクトオーナー	隔週	ステークホルダーミーティング	マイルストーン達成状況
経営層	マイルストーン時	報告メール	サマリーのみ

まとめ

ポイント	内容
ゴール設定	SMART基準で具体的に定義
スコープ	やること/やらないことを明確に
WBS	タスクを構造的に分解
スケジュール	マイルストーンと依存関係を管理
リソース	担当割り当てとクリティカルパスの特定
コミュニケーション	対象別に頻度と方法を計画

チェックリスト

SMARTゴールの5要素を説明できる
スコープの「やること/やらないこと」を定義できる
WBSでタスクを構造的に分解できる
マイルストーンとクリティカルパスを特定できる

次のステップへ

次のセクションでは、プロジェクトの「リスク管理と障害対応」を学びます。計画通りに進まない場合に備え、リスクを事前に特定し対策を準備する方法を身につけましょう。

推定読了時間: 30分