問題 No.2262
中規模なWebアプリケーション開発プロジェクトにおいて、プロジェクトマネージャがWBSの作成およびワークパッケージの定義を行う場面を想定する。WBSの運用や管理を効果的に行うための実務的なアプローチとして、最も適切なものはどれか。
【正解の解説】
作成したWBSの最下層の各作業パッケージに対して、コストや所要期間の見積もりが可能となり、かつ単一の責任者が明確に割り当てられる粒度に設定する。
WBSを料理のレシピに例えると、最下層のワークパッケージは「肉を一口大に切る」のような具体的な調理手順にあたります。大雑把すぎて「料理を作る」という粒度のままだと誰がいつまでに何をするか分かりませんが、細かすぎても管理がパンクします。そのため、コストや日数が明確に計算でき、誰が担当するのかがハッキリと決まる絶妙な大きさに調整するのがプロジェクト成功の秘訣です。
スポンサーリンク
【その他の選択肢の解説】
作成したWBSの最下層の各作業パッケージに対して、全体の進捗率を均等に配分するため、すべての工数が同一となる粒度に設定する。
現実の開発現場では、複雑なログイン機能の実装と単純なボタンの色変更とでは、必要となる工数や難易度が全く異なります。それらを「進捗率を管理しやすいから」という理由ですべて同じ工数に無理やり合わせようとすると、実態の伴わない形骸化したスケジュールが出来上がり、プロジェクト崩壊の引き金になるため注意が必要です。
作成したWBSの最下層の各作業パッケージに対して、外部の利害関係者全員が直感的に把握できるよう、専門用語を排除した粒度に設定する。
WBSは一般向けのパンフレットではなく、開発チームが実際に手を動かして作業を進めるための専門的な実行計画書です。そこに登場する「DB設計」や「API連携」といった専門用語を無理に排除してしまうと、エンジニアにとってはかえって抽象的で何をすればいいか分からない曖昧な計画になってしまい、現場の混乱を招く原因となります。
作成したWBSの最下層の各作業パッケージに対して、詳細な設計工程まで事前に網羅できるよう、プロジェクト完了までの全成果物を網羅した粒度に設定する。
アジャイル開発などが混ざる現代の中規模Webアプリ開発では、最初からすべての詳細な設計までを完璧にWBSに落とし込むことは不可能です。初期段階で先の見えない詳細まで無理に決めようとすると、後から仕様変更が発生した際に手戻りが巨大化し、かえってプロジェクトの足かせになるという典型的なアンチパターンに陥ります。