PWBS FWBSとは？
「PWBS」と「FWBS」は、主にプロジェクトマネジメントの文脈で使用される用語で、いずれも「WBS（Work Breakdown Structure：作業分解構成図）」に関連しています。 以下にそれぞれの意味を説明します。
PWBS（Product Work Breakdown Structure）
プロダクトWBS / 成果物ベースのWBS
定義：プロジェクトで作成すべき「成果物（プロダクト）」をベースに分解したWBS。
目的：プロジェクトで何を作るのか（＝成果物）を明確にし、それらを構成要素に分解して管理する。
特徴：
- システム開発であれば、「画面設計」「DB設計」「マニュアル」などの成果物に分解。
- 成果物を起点とするため、品質管理や受け入れテストに適している。
- 要件定義→設計→開発→テストといった成果物単位での確認がしやすい。
FWBS（Functional Work Breakdown Structure）
機能WBS / 機能ベースのWBS
定義：プロジェクトで実装する「機能（ファンクション）」をベースに分解したWBS。
目的：どのような機能を提供するのかに焦点を当て、作業を細かく分解する。
特徴：
- 「ログイン機能」「ユーザー管理機能」「注文処理機能」など、機能単位で分解。
- 開発や設計、テストが機能ごとに行われるプロジェクトに適している。
- アジャイルや機能単位のスプリント管理と相性が良い。
違いのまとめ
項目 PWBS（成果物ベース） FWBS（機能ベース） 分解の起点 成果物（ドキュメント、設計書など） 機能（システムの機能、サービスなど） 管理の視点 「何を作るか」に焦点 「何を実装するか」に焦点 適した工程 上流工程（設計・品質・受け入れ） 下流工程（開発・テスト）
補足：WBSとは？
WBSは「作業を細かく分割して整理した構造図」で、プロジェクト管理の基盤です。PWBSやFWBSはこのWBSの派生概念であり、どの視点で分割するかの違いです。
インフラ環境の構築もPWBS（成果物ベースWBS）に含まれます。 なぜなら、インフラ自体が「プロジェクトで最終的に提供する成果物の一部」だからです。
具体例：S3を使ったファイルアップロード機能のPWBSでの位置づけ
たとえば、ファイルアップロード機能を提供するシステムを作る場合：
🔹 成果物の例（PWBSの要素）
- 画面設計書（アップロードUIの設計）
- バックエンドAPI仕様書（アップロード処理の仕様）
- AWS S3構成図（←インフラ）
- S3バケット設定ファイル／Terraformスクリプト（←インフラ）
- 環境構築手順書
- 運用設計書（ログ、アクセス制御など）
このように、S3やAWSの設定そのものも「成果物」として扱われるため、PWBSに含まれます。
✅ 補足：FWBSとの違い
一方、FWBSではこのように機能ベースで分解されるイメージです：
- ファイルアップロード機能
- バックエンド処理（API）
- UI実装
- バリデーション
- S3アップロード処理（機能）
FWBSでは「S3アップロード処理」は機能の一部として扱いますが、PWBSではその処理を実現するために必要な設定や設計資料も成果物として管理します。
✅ 結論
インフラ（例：S3構成、設定ファイル、ネットワーク設計書など）は、PWBSにしっかり含めるべき成果物です。 必要であれば、PWBSの具体例を図として作成できますが、見たいですか？
学生のポートフォリオサイトを作成する場合、「マトリクスチャート（Matrix Chart）」は、機能と成果物の対応関係や、作業と担当者／フェーズ／重要度の関係を整理するのに便利です。 ここでは、ポートフォリオサイトを例に、「機能 × 成果物」マトリクスを作成してみます。
🔍 解説
- 横軸（成果物）：PWBS的視点。「成果物」として管理される設計書、コード、設定ファイルなど。
- 縦軸（機能）：FWBS的視点。実際にサイトに実装される機能群。
- ✅マーク：その成果物が、その機能の実現に必要であることを示しています。
🎯 このマトリクスの目的
- 成果物の抜け漏れチェックができる（設計書を書いてない機能がないか？など）
- プロジェクトメンバーで作業分担するときに、誰が何を担当するか明確にしやすい
- 開発と管理の全体像を俯瞰しやすくなる