ITパスポート 2014年 春期 問42

システム開発のWBS作成における要素分解について【ITパスポート 解説】

正解の理由

解法ステップ

1. 用語確認
   • WBS（Work Breakdown Structure：作業分解構成図）…プロジェクトを成果物（deliverable）や作業に分けて整理する図。
   • 要素分解（decomposition）…上位の成果物を下位の作業単位に細かく分けること。
2. 問題のポイントを把握する
   • 「要素分解の目的」がどこにあるかを問う問題です。目的は見積もりと管理ができるレベルにすること。
3. 各選択肢を目的に照らし合わせる
   • 「見積もりや管理ができるレベルまで分解する」は目的に合致 → 適切。
   • 残りは外注完全委任、会議は対象外、経験で省略はそれぞれ目的に反する・不十分 → 不適切。
4. 結論
   • 目的に最も合う記述を選ぶ（ア）。

選択肢別の誤答解説

• ア（正しい）
  成果物を作るために必要なコストや時間を見積もり、管理可能な単位（ワークパッケージ）まで分解することがWBSの目的に合致します。ワークパッケージは責任者が決めやすく、進捗やコストを追跡できる最小単位です。
• イ（誤り）
  「外部に発注するから全て発注先に任せる」は誤りです。外注しても、発注側は成果物の仕様・受け入れ基準・インターフェース（他システムとの接続や統合の取り決め）を明確にする必要があります。WBSの上位レベルや検収（受け入れ）に関する分解と管理は発注者側の責任です。外注先にすべてを一任すると、品質やスケジュール管理、責任範囲が不明瞭になります。
• ウ（誤り）
  「進捗報告会議はコミュニケーション手段なので要素分解しない」は誤りです。会議そのものは「会議の準備」「資料作成」「会議開催」「議事録作成」といった作業に分解できます。特に定例の進捗会議はプロジェクトのスケジュール・コストに影響するため、必要ならWBSに含めて見積もり・担当者を決めておくべきです。
• エ（誤り）
  「類似システムの経験があれば分解不要」は誤りです。類似経験は確かに参考になりますが、要件や環境、スコープはプロジェクトごとに異なります。再利用可能な要素は活用できますが、プロジェクト固有の差分（追加要件、運用条件、非機能要件など）を反映するために再度分解・見積もりが必要です。

よくある誤解

• 誤解1: 「細かく分解すれば良い」
  → あまりに細かくすると管理がかえって煩雑になります。分解の目安は「見積もりと担当者が明確になり、進捗とコストを追跡できる最小単位（ワークパッケージ）」です。一般的には報告期間や責任の取りやすさを基準にします（例：1週間〜2週間で完了する程度が扱いやすいという目安があります）。
• 誤解2: 「会議や調整は重要でないからWBSに入れない」
  → 実務では会議や調整もコストと時間を使います。特にステークホルダー調整や検収準備は遅延原因になりやすいため、必要ならWBSに含めて管理するべきです。

補足コラム

• 上位成果物：ログイン機能（成果物）
  • 分解例：要件定義、設計、実装、単体テスト、結合テスト、ドキュメント作成、検収準備
  • さらに実装を分解：画面作成、認証API実装、パスワード暗号化処理、テストデータ準備
    各要素が「誰が」「いつまでに」「どれくらいでできるか」を示せる単位まで落とし込みます。

FAQ