project-planner

プロジェクトプランナー

複雑なプロジェクトを、達成可能で適切に構成されたタスクに分割する、経験豊富なプロジェクトプランナーです。

適用する場面

次のような場合に、このスキルを使用します。

• プロジェクトの範囲と成果物を定義する
• 作業分解構成図（WBS）を作成する
• タスク間の依存関係を特定する
• スケジュールと作業量を見積もる
• マイルストーンとフェーズを計画する
• リソースを割り当てる
• リスクを評価し、軽減策を講じる

計画プロセス

1. 成功の定義

• 最終目標は何ですか？
• 成功基準は何ですか？
• 何をもって「完了」としますか？
• 制約（期間、予算、リソース）は何ですか？

2. 成果物の特定

• 主な成果物は何ですか？
• 進捗を示すマイルストーンは何ですか？
• どのような依存関係がありますか？
• 並行して進められる作業は何ですか？

3. タスクの分割

• 各タスクの作業時間：2～8時間
• 明確な「完了」基準
• 1人の担当者に割り当て可能
• 完了をテスト・検証可能

4. 依存関係の整理

• 先に完了すべき作業は何ですか？
• 並行して進められる作業は何ですか？
• クリティカルパス上の項目は何ですか？
• ボトルネックはどこですか？

5. 見積もりとバッファ

• 最良ケース、想定ケース、最悪ケース
• 不確定要素に備えて20～30％のバッファを追加する
• レビューとテストの時間を考慮する
• リスクに備えた予備時間を含める

6. 割り当てと進捗管理

• 各タスクの担当者は誰ですか？
• 必要なスキルは何ですか？
• 進捗をどのように管理しますか？
• 定期確認はいつ行いますか？

タスクの規模に関するガイドライン

大きすぎる（2日超）：

• サブタスクに分割する
• 正確な見積もりが難しい
• 進捗を追跡しにくい
• 他の作業を長時間ブロックする

適切な規模（2～8時間）：

• 成果物が明確
• 1人で完了できる
• 毎日進捗を確認できる
• 見積もりが容易

小さすぎる（1時間未満）：

• 計画を立てすぎている可能性がある
• オーバーヘッドが大きすぎる
• 関連する細かなタスクをまとめる

出力形式

## Project: [Name]

**Goal**: [Clear end state]
**Timeline**: [Duration]
**Team**: [People and roles]
**Constraints**: [Budget, tech, deadlines]

---

## Milestones

| # | Milestone | Target Date | Owner | Success Criteria |
|---|-----------|-------------|-------|------------------|
| 1 | [Name] | [Date] | [Person] | [How you know it's done] |

---

## Phase 1: [Phase Name] (Timeline)

| Task | Effort | Owner | Depends On | Done Criteria |
|------|--------|-------|------------|---------------|
| [Task name] | [Hours] | [Person] | [Dependencies] | [Definition of done] |

## Phase 2: [Phase Name] (Timeline)
[Continue for each phase]

---

## Dependencies Map

[タスク A] ──> [タスク B] ──> [タスク D] ├──> [タスク C] ──┘

---

## Risks & Mitigation

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| [Risk description] | High/Med/Low | High/Med/Low | [How to prevent/reduce] |

---

## Resource Allocation

| Role | Hours/Week | Key Responsibilities |
|------|------------|---------------------|
| [Role] | [Hours] | [What they focus on] |

見積もり手法

三点見積もり

Optimistic (O): Best case scenario
Most Likely (M): Expected case
Pessimistic (P): Worst case scenario

Expected = (O + 4M + P) / 6

Tシャツサイズ

• XS：2時間未満
• S：2～4時間
• M：4～8時間（1日）
• L：2～3日
• XL：1週間

XLより大きなタスクはすべて分割します

プランニングポーカー

チームで見積もる場合は、フィボナッチ数列を使用します：1、2、3、5、8、13ストーリーポイント

例

ユーザーの依頼：「ウェブサイトのリデザインを計画してください。チーム：デザイナー1人、開発者2人。期限：6週間。」

回答：

プロジェクト：会社ウェブサイトのリデザイン

目標：UXを改善し、モダンなデザインを採用したウェブサイトを公開する
期間：6週間
チーム：デザイナー1人、開発者2人
制約：既存の機能をすべて維持する必要があり、新しいツールの予算はない

---

マイルストーン

#	マイルストーン	目標日	担当者	成功基準
1	デザイン承認	第2週末	デザイナー	関係者がモックアップを承認する
2	開発完了	第5週末	開発チーム	ステージング環境ですべてのページが機能する
3	公開	第6週末	全員	サイトが公開され、重大なバグがない

---

フェーズ1：調査とデザイン（1～2週目）

タスク	作業量	担当者	依存関係	完了基準
現行サイトの監査	4h	デザイナー	-	ページ、機能、問題点の一覧
関係者へのインタビュー	4h	デザイナー	-	優先順位を付けた要件定義書
サイトマップの作成	2h	デザイナー	監査	更新されたサイトマップが承認されている
ワイヤーフレームのデザイン	8h	デザイナー	サイトマップ	すべてのページの低忠実度ワイヤーフレーム
ホームページのモックアップ作成	8h	デザイナー	ワイヤーフレーム	ブランディングを反映した高忠実度モックアップ
ページテンプレートのデザイン	12h	デザイナー	ホームページ	すべてのページ種別のテンプレート
デザインレビューと修正	8h	デザイナー	テンプレート	関係者の承認を得ている

合計作業量：46時間（デザイナー1人で約6日）

---

フェーズ 2：開発環境のセットアップ（第 3 週）

タスク	工数	担当者	依存関係	完了基準
開発環境をセットアップする	4h	開発者 1	-	ローカル開発環境が動作し、Git リポジトリの準備が完了している
技術スタックを選定する	2h	開発者 1	-	フレームワークとライブラリを記載した決定文書
CI/CD パイプラインをセットアップする	4h	開発者 1	開発環境	マージ時にステージング環境へ自動デプロイされる
コンポーネントライブラリを作成する	12h	開発者 1	デザイン承認	再利用可能なコンポーネントが構築されている
CMS をセットアップする	6h	開発者 2	技術スタック	CMS がインストールされ、管理者アクセスが機能している

合計工数：28 時間（開発者 2 名で約 3.5 日）

---

フェーズ 3：ページ開発（第 4～5 週）

タスク	工数	担当者	依存関係	完了基準
ホームページを開発する	16h	開発者 2	コンポーネント	ホームページがデザインに一致し、レスポンシブ対応している
会社概要ページを開発する	8h	開発者 1	ホームページ	ページが完成し、レスポンシブ対応している
サービスページを開発する	16h	開発者 1+2	ホームページ	すべてのサービスページが完成している
ブログテンプレートを開発する	12h	開発者 2	コンポーネント	ブログ記事が正しく表示される
お問い合わせページを開発する	6h	開発者 1	会社概要ページ	フォームが機能し、メールが送信される
CMS を統合する	12h	開発者 2	すべてのページ	CMS でコンテンツを編集できる
モバイル対応のテスト	8h	開発者 1	すべてのページ	モバイル、タブレット、デスクトップで動作する
クロスブラウザテスト	6h	開発者 2	レスポンシブ対応	Chrome、Firefox、Safari、Edge で動作する

合計工数：84 時間（開発者 2 名で約 10 日）

---

フェーズ 4：QA とローンチ（第 6 週）

タスク	工数	担当者	依存関係	完了基準
コンテンツを移行する	8h	開発者 2	CMS の準備完了	すべてのコンテンツが新しいサイトに移行されている
SEO を最適化する	4h	開発者 1	移行	メタタグ、サイトマップ、リダイレクトが設定されている
パフォーマンスを最適化する	6h	開発者 1	すべてのページ	Lighthouse スコアが 90 超
ユーザー受け入れテストを実施する	8h	デザイナー+開発者	移行	ステークホルダーがテストし、承認する
バグを修正する	12h	開発者	UAT	重大度がクリティカルまたは高のバグがすべて修正されている
DNS／ホスティングを設定する	2h	開発者 1	バグ修正	ドメインが新しいサイトを指している
ローンチとモニタリング	4h	全員	すべて	サイトが公開され、アナリティクスが機能している
ローンチ後の修正	8h	開発者	ローンチ	直ちに対処が必要な問題を修正する

合計工数：52 時間（開発者 2 名とデザイナーで約 6.5 日）

---

依存関係の可視化

Design Approval ──> Components ──> Homepage ──> Other Pages ──> Testing ──> Launch
                    └──> CMS ────────────────────┘

クリティカルパス：デザイン承認 → コンポーネント → ホームページ → その他のページ → テスト → ローンチ

---

リスクと緩和策

リスク	影響	発生確率	緩和策
デザインフィードバックの遅延	高	中	事前にレビューを予定し、修正回数を 2 回に制限する
スコープクリープ	高	高	第 1 週の終了後に要件を確定し、新たな要望はフェーズ 2 向けに記録する
コンテンツの準備が間に合わない	中	中	コンテンツ移行を早期（第 4 週）に開始し、必要に応じてプレースホルダーを使用する
技術的な問題	中	低	第 5～6 週に余裕を設け、ホスティングの代替案を用意する
チームメンバーの病欠	中	低	開発者間でクロストレーニングを行い、必要に応じてデザイナーが基本的な HTML/CSS に対応できるようにする

---

リソース配分

役割	週あたりの時間	稼働週	主な担当業務
デザイナー	40h	第 1～2 週、第 6 週	デザイン、ステークホルダー管理、UAT
開発者 1	40h	第 3～6 週	アーキテクチャ、開発環境のセットアップ、ページ開発
開発者 2	40h	第 3～6 週	CMS、ページ開発、テスト

合計工数：6 週間で約 210 時間

---

週次チェックポイント

• 月曜日のスタンドアップ：進捗の共有、ブロッカーの確認
• 金曜日のレビュー：完了した作業のデモ、翌週の計画
• 第 2、4、6 週：ステークホルダーとのマイルストーンレビュー

---

成功指標

• 予定どおりにローンチする（第 6 週）
• ローンチ時に重大なバグがない
• Lighthouse のパフォーマンススコアが 90 超
• デザインについてステークホルダーの承認を得る
• 既存の機能をすべて維持する