システム開発のためのWBSの作り方　日経BP 初田賢司

WBSが持つメリット

作業の抜け・漏れや重複を防げる
WBSではトップダウンで論理的に作業や成果物を分解していきます。
これは、分解するという思考過程そのものが"気付き"を促す効果があるからです。
WBSを作成していく過程では、作業計画を洗練させていくことが可能です。
その結果、もっと早く手を付けないと間に合わない、あるいはもっと人が必要だ、
と言った判断を事前にすることができます。

プロジェクトのスコープが決まる
WBSに書かれたプロジェクトスコープ外の作業によってはスケジュール遅延やメンバーの増員が発生したのであれば、これは追加費用が発生することを意味します。
逆に、プロジェクトスコープ内の作業に対応するためのスケジュール遅延や増員であれば、原則として追加費用は認められません。

計画が明確になる
プロジェクトで必要な工数やコストの詳細見積りです。
WBSは、いわゆるボトムアップ見積りと呼ばれます。
ボトムアップ見積りは、生かぶるや実施すべき作業を分解し、分解された構成要素や作業項目ごとに所要工数を算出し、それらを積み上げていく手法です。
過去の事例や経験から全体の工数を見積もる類推（トップダウン）見積りや、基準値や数値から工数を算出する係数モデル見積りに比べて、ボトムアップ見積りは高い精度で見積もることが可能です。
プロジェクトが始まれば、工数（コスト）の実績をWBSの構造を基に集計して、見積もった予定工数（コスト）と対比させて問題点の早期発見につなげることができます。

先を見る習慣が身につく
プロジェクトを遂行する上で、極めて重要なリソースは「時間」です。
お金は使わなければ残るし、いざとなれば他から調達することもできます。
しかし、時間はそうはいきません。
過ぎ去った時間を取り戻すことができないのです。
だからこそ、時間を無駄にしないために、プロジェクトの「先を読む」という習慣が必要です。
WBSはゴールまでの道筋を考えながら作成します。
既に実施した作業を洗い出すのではなく、将来実施する作業を洗い出すわけです。
WBSの作成を経験すると、自然と先を読むという習慣が身につくはずです。

WBSの歴史と定義

WBSの概念が提唱されたのは意外に古く、1960年代前半まで遡ります。
米国防総省（DoD）と米航空宇宙局（NASA）が作業計画やスケジュール計画の立案手法として「PERT/Cost」を考案したのが始まりです。
この中で、WBSやワークパッケージを定義しています。
当時出版された「プログラム学習によるPERT COST入門」という書籍を見ると、WBSの具体的な説明が次のようにあります。
「WBSとは、まず主エンドアイテム（最終成果物）を記し、続いて順に、より小さいエンドアイテムに分解していって、全てのプロジェクト目標やそれらの相互関係を明確に記述するもので、プログラムの系図的表現ともいえる」
50年近く前に書かれたものですが、内容は古さを感じません。
基本的な考えは、当時からずっと変わっていないことの表れでしょう。
注目したいのは、WBSの説明はスケジューリングの技法を一通り説明した後に示されていることです。
一見、WBSは作業項目を洗い出す手法のように見えます。
しかし、WBSはあくまで、スケジューリングの切り口から作業を明確に定義し、コスト管理に繋げることを目指しているのです。

WBSの作成ステップ

①WBS作成準備
②タスクの洗い出し
③工数見積もり
④スケジュールの作成
⑤役割分担の作成

いきなりタスクを洗い出すのはトラブルのもと
なぜ、いきなりWBSを作成してはいけないのでしょうか。
それは、WBSを作成する上で必要な情報が足りないと、方向性の間違ったWBSになってしまうからです。
具体的に収集すべき情報は「全体の情報」「成果物の情報」「制約条件・前提条件」という3つがあります。

●全体の情報
目的→生産管理システム印新によるリードタイムの短縮
狙い→生産設備リニューアルへの対応、新しい生産管理方式の適用
開発方針→生産設備リニューアルのタイミングに合わせ、フェーズを分けて開発する

●成果物の情報
最終成果物の構成→サブシステム構成、業務機能一覧など
納品物→仕様書、設計書、操作手順書、運用手順書

●制約条件・前提条件
品質→許容ダウン時間はn分として設計する
コスト→全体の予算はn万円
納期→フェーズ1納期は翌年3月末
開発方法→生産管理パッケージを導入する
役割分担→要件分析チームに製造部門のキーパーソンが参加する
プラットフォーム→サーバーは二重化する

何かを犠牲にして期間を短縮

こんな問題に悩まされたことはないでしょうか。
それは「今のスケジュールでは、デッドラインである期限を守れない」というものです。
納期を延ばせない限り、与えられた時間を増やすことはできません。
もし納期を変えずに期間を短縮するとしたら何かを犠牲にしなければなりません。
期間を短縮する方法は4つあります。
1つ目は、残業や休日作業でカバーする方法です。
計画段階から休日出勤をスケジュールに組み込むことは避けましょう。
倫理上問題もありますし、休日出勤をすると、生産性や士気が低下します。

2つ目は、スコープの縮小です。
作業の範囲を（スコープ）を削ることで、作業量と期間を縮小し期日までに対応するというものです。
これによって、顧客満足度が低下するといった影響が考えられます。

期間短縮テクニックの王道
3つ目と4つ目はプロジェクトマネジメントでよく使われる王道です。
3つ目のファストトラッキングは、複数のタスクを並行化する方法です。
他のタスクの終了を待たずに、リスク覚悟で作業を前倒しする方法です。
不確定な部分を見込んで作業を進めることになるので、手戻りによりコスト増となるリスクを伴います。
提案書の構成が変更になり、作り直しとなる可能性が出てきます。

4つ目は、クラッシングという方法です。
期間を短縮したいタスクについて要員を追加して対応するというものです。
なお、クラッシングにも注意が必要です。
当初、1人で実施する予定のタスクを2人にしたら、工数はそのままで単純に期間が半減すると考えがちです。
要員が増えれば、マネジメントやコミュニケーションのオーバーヘッドが増えるからです。
特にそれまでチームに参加していなかったメンバーを外部から追加すると、作業の理解に要する工数や、パソコンの手配などの準備に関する工数が加わります。

WBSがシステム開発の成否を決める

WBSの作り方によって、なぜシステム開発の生産性やシステムの品質に差が出るのか。
開発コストの大半は人件費です。
メンバーによるスキルレベルのバラツキは品質や生産性に直結するので、仕事のやり方や分け方をWBSによってコントロールする必要があります。
また、ソフトウェアの開発は、ハードウェアと違って明確な試作工程がありません。
そのため、中間段階の品質を確保するには、WBSにマイルストーンを設けて品質を確認します。
ソフトウェア開発ではさらに、要求に対する実現方法がひとつではないという特徴もあります。
設計者がバラバラの方法で実装しないように、WBSによって統制しなければなりません。