Column

システム開発において、WBSという管理表を用いて進捗を管理する事がよくあります。

これからシステム開発を発注する依頼者にとってもWBSは知っておくべきことで、ここでは主に依頼者視点でのWBSの解説をしていきます。

Work Breakdown Structureの略で作業を分解し、構造を定義することです。

スケジュールを詳細化したものとも取られられますが、それだと作業ごとの関連が分かりません。

作業と作業を関連付けて構造化したものがWBSと言えます。

WBSにはスケジュールが含まれますが、作業ごとの関連は含まれず、

「どの作業の後にどの作業をやる」
「この作業が遅れるとこの作業も遅れる」

などが分かりません。
逆に、「この作業は多少遅れても問題ない」ということはWBSでは判断可能になりますが、スケジュールだけでは分かりません。

WBSはプロジェクトマネジメントする側の視点で考えればあるべきもので、発注する側からしてもあった方が安心感があるだけでなく、プロジェクトマネジメントの知見のある人が見ればプロジェクトの質が 見えてきます。

想定読者は依頼者視点と記載していますので、依頼者側でWBSを書くというケースは少ないと思います。
ただWBSに関する記事としてポイントだけでも記載しておきます。

出来るだけ細かく書く方が望ましいです。

まずは概算スケジュールレベルで大雑把に記載しても構いませんが、徐々にブレイクダウンしていきましょう。

１つの作業は目安としては1～2日程度、長くとも2週間以内程度に分割しましょう。

作業A→作業B→作業Cのようなものもあれば

作業A→作業B→作業D
↓
作業C

のように分岐するものもあります。

担当者を何名配置できるかによりスケジュールにも影響が出ます。

何名配置できるかという観点と、いつまでにプロジェクトを終わらせなければならない、という観点があり、 その中で調整する事になるかと思います。

ここまで行うと、クリティカルパスが見えてきます。 クリティカルパスとは、そこが遅れるとプロジェクト全体が遅れることになるという重要な作業です。

クリティカルパスを担当する人は実績のある信頼できる人をアサインすべきです。

プロジェクトの中では、例えばデータ作成や外部サービスの契約など、依頼者（発注者側）が行うべき作業も含まれるべきです。

WBSは一般的にはシステム開発会社が書くものですが、そこに依頼者（発注者側）側が行うべき内容や希望スケジュールも記載されているかと思いますので、内容やスケジュールが問題ないか確認しましょう。

また、要件定義や設計といったもののレビューも依頼者が行うべきことの1つです。
レビューを行えばフィードバック対応を行うスケジュールも確保しておく必要があり、そういった項目も含め盛り込まれていか確認しましょう。
（稀にそういったものがないWBSを見ることがあります。）

ここではWBSの解説から書き方や確認すべきポイントを書きました。
専門知識がなくともある程度は読むこともできますし、システム開発会社との定例ミーティングで進捗を確認する際にアップデートして見せてもらう事でプロジェクトの質を上げることも出来るかと思います。

WBSを活用してプロジェクトを成功に導きましょう。