開発会社から「WBSです、ご確認ください」とExcelが送られてきて、行数の多さに目が滑ったまま承認してしまった。あるいは、何をどう見ればいいのか分からず、とりあえず「問題ありません」と返してしまった。そんな経験のある方は少なくないと思います。
WBSを検索すると出てくるのは、作り方の手順とテンプレートばかりです。ですがそれは作る側の話で、発注する側は自分でWBSを作りません。受け取って、読んで、承認するかどうかを決める立場です。この記事では、システム開発のWBSに何が書かれているのかを整理したうえで、開発会社から出てきた表のどこを見れば遅れの兆しに早く気づけるのかを説明します。
この記事のポイント
- WBSは作業を分解して並べた表で、ガントチャートは同じものを時間軸で見た図
- 発注側はWBSを作る側ではなく、読んで承認する側
- 1行が長すぎる作業は進捗が見えず、遅れが隠れる
- 自社側の作業が載っていないWBSは、あとで責任の話になりやすい
目次
システム開発のWBSとは何を並べた表か
まず、送られてきた表が何なのかを押さえます。中身が分かれば、見る場所も決まります。
WBSは作業を分解して並べた計画表
WBSはWork Breakdown Structureの略で、日本語では作業分解構成図と呼ばれます。プロジェクト全体を大きな固まりから細かい作業へと分解して、一覧にしたものです。
実物はたいていExcelで、次のような列が並んでいます。作業の名前、担当、開始日、終了日、工数（何人日かかるか）、進捗率。そして左側に階層があり、大きな工程の下に中くらいの作業、その下に実際の手を動かす単位、という形で枝分かれしています。
| 階層 | 書かれるもの | 例 |
|---|---|---|
| 大分類 | 工程 | 要件定義／基本設計／製造／テスト／移行 |
| 中分類 | 工程の中のまとまり | 画面設計、帳票設計、データ移行の設計 |
| 小分類 | 実際に着手できる単位 | 受注入力画面の設計、承認画面の設計 |
大分類はだいたい工程の名前と一致します。工程そのものの並びや略語の意味はシステム開発の工程と流れで整理しているので、聞き慣れない言葉が出てきたらそちらを見てください。
ガントチャートとの違い
WBSとセットでよく出てくるのがガントチャートです。混乱しやすいのですが、対立するものではありません。
WBSは「何をやるか」を分解した一覧で、ガントチャートはその作業を時間軸の上に横棒で並べた図です。実務では同じExcelの左側がWBS、右側が横棒のガント、という形になっていることがほとんどです。つまり多くの場合、あなたが受け取っている1枚の表は両方を兼ねています。
もうひとつ知っておくと役に立つのは、WBSは一度作って終わりではないという点です。要件が固まるにつれて中身は細かくなりますし、途中で作業が増えれば行も増えます。ですから毎回まったく同じ表が送られてくるわけではなく、更新された版が回ってくるのが普通です。前回と何が変わったのかを開発会社に一言聞く習慣をつけておくと、増えた作業や後ろにずれた日程に早く気づけます。
発注側として見るときの使い分けは単純です。何をやるつもりなのかを確かめるときは左側の一覧を、いつ何が終わる予定なのかを確かめるときは右側の横棒を見ます。作業の抜けは左側でしか見つかりませんし、詰まりすぎた日程は右側でしか見えません。
発注側はWBSを作らず、受け取って読む立場
ここは立場をはっきりさせておきます。WBSを作るのは開発会社です。発注側が自分で作る必要はありませんし、作れる情報も持っていません。
ただし、読まずに承認するのは別の話です。WBSの承認は「この計画で進めてください」という意思表示になります。あとから「その作業は聞いていない」「その日程では困る」と言っても、承認した表に書いてあれば分が悪くなります。逆に言えば、承認前がいちばん自由に質問できるタイミングです。
私の感覚では、WBSは提案時か、要件定義が終わったあたりで出てくることが多いです。提案時のものはまだ粗く、要件定義後のものが実際に運用される版になります。細かく見るべきなのは後者のほうです。
システム開発のWBSから遅れを見抜く読み方
ここからが本題です。専門知識がなくても、見る場所さえ決まっていれば危ない兆しは拾えます。全部で4つあります。
粒度が粗すぎる行に遅れが隠れる
最初に見るのは、1行あたりの長さです。「開発 60日」「実装 3か月」のように、1行で何十日もある作業が並んでいたら、そこは要注意です。
なぜかというと、長い作業は進捗が測れないからです。60日の行に対して「進捗50%」と報告されても、それが本当に半分なのか、手をつけただけなのかを外から判断する方法がありません。そして実際に多いのは、80%のまま何週間も動かず、終盤で「間に合いません」と出てくるパターンです。
目安としては、1行あたり5営業日以内に収まっていると進捗が見えやすくなります。10日を超える行があれば、その中で何をするのかを聞いてください。答えられるなら分解してもらえますし、答えが曖昧なら、その作業自体がまだ固まっていないということです。
工数そのものが妥当かどうかは、正直なところ発注側だけでは判断が難しい部分です。自分の勘だけで多い少ないを言わないためには、外部の目安を持っておくと役に立ちます。IPAはソフトウェア開発分析データ集として、これまでに収集した5,546プロジェクトの定量データを分析して公開しています。技術者の経験と勘に頼るのではなく実際のプロジェクトデータに基づいて管理する、という趣旨のものです。なお、この事業は終了しており今後の発行予定はないと明記されているので、参照する際は公開時点のデータである点に注意してください。
テスト工程が薄いWBSは後半で崩れる
次に見るのは、テストに割かれている日数です。ここが薄いWBSは、後半でほぼ確実に苦しくなります。
確認の仕方は簡単で、製造（実装）の期間と、テストの期間を見比べるだけです。実装に3か月かけるのにテストが2週間しかない、という配分になっていたら理由を聞いてください。もちろん案件によって適切な比率は変わりますが、極端に短い場合は、テストで見つかった不具合を直す時間が計画に入っていないことが多いです。
もし比率の判断に迷うなら、開発会社に「このテスト期間で、不具合が出た場合の修正と再確認はどこに入っていますか」と聞くのがいちばん早いです。テスト期間の中に修正の時間が織り込まれているのか、それとも別に確保されているのかで、実際に使える日数はまったく変わります。答えが曖昧なら、その計画は不具合が出ない前提で組まれているということです。
もうひとつ、テストが1行にまとまっていないかも見てください。単体テスト、結合テスト、総合テスト、受入テストは目的が違う別の作業です。まとめて「テスト」と1行になっていると、どの段階が押しているのか分からなくなります。
そして忘れられがちなのが、受入テストの日数です。これは発注側が自分で動かして確かめる工程なので、自社の担当者を何日拘束するかに直結します。ここが数日しか取られていないなら、承認前に相談すべき点です。詳しくはシステム開発のUATとは？発注側が主役の受け入れテストで扱っています。
自社側の作業が載っていない
3つ目は、発注側の作業がWBSに入っているかどうかです。これが抜けているWBSは、実はかなり多く見かけます。
プロジェクトが進むと、発注側にも作業が発生します。既存データの提供、画面や帳票のレビューと承認、現場へのヒアリング調整、マスタの整備、社内の稟議。これらは開発会社の作業ではありませんが、遅れれば全体が止まります。
WBSに自社の行がないと、2つの問題が起きます。ひとつは、自社の担当者がいつ何をすべきか分からず、依頼が来てから慌てること。もうひとつは、遅れたときに「御社の資料提供が遅れたせいです」と後から言われる形になることです。計画に載っていれば、いつまでに何を出すかが事前の合意になります。
入れてもらうときは、担当者の名前まで書いておくと効きます。「発注側」とだけ書かれていると社内で誰も自分ごとにしませんが、名前が入っていれば期日が意識されます。誰をどの役割に置くかを整理するときは、提案時に出てくる体制図とあわせて見ると決めやすくなります。発注後の進め方を型として持っておきたい場合は、ベンダーコントロールパーフェクトガイドに手順をまとめてあります。
ですので、承認する前に「弊社側でやることも行として入れてください」と依頼してください。これは開発会社にとっても歓迎される依頼です。断られることはまずありません。
余裕がどこに置かれているかを見る
最後は、バッファ（余裕）の置き場所です。少し上級ですが、見方は難しくありません。
危ないのは、余裕が最後にまとめて置かれている計画です。個々の作業はぎっしり詰まっていて、リリース直前に「予備期間」が2週間ある、という形。この置き方だと、途中の遅れがすべて最後の予備を食いつぶし、気づいたときには余裕がゼロになっています。
望ましいのは、工程の区切りごとに少しずつ余裕がある形です。要件定義の終わりに数日、設計の終わりに数日、というように分散していれば、遅れがその区切りで吸収されて次に持ち越されません。
余裕がどこにもない計画も、それはそれで危険です。まったく予備のないWBSは、一見すると引き締まって見えますが、実際には最初の小さな遅れがそのまま納期に響きます。予備が見当たらないときは「遅れが出たときはどこで吸収する想定ですか」と確認しておいてください。
あわせて、どの作業が遅れると全体が止まるのかも聞いておくとよいです。前の作業が終わらないと次に進めない、という連なりのことで、そこが遅れた場合だけは即座に相談が必要になります。全体の期間そのものが妥当かどうかは、システム開発の期間はどれくらい？規模別の目安と照らし合わせてみてください。
- Q. WBSは発注側が作るものですか？
- いいえ、作るのは開発会社です。発注側は受け取って内容を確認し、承認する立場になります。ただし自社側の作業（資料提供やレビュー、承認）は行として入れてもらうよう依頼してください。
- Q. WBSはどれくらいの細かさが適切ですか？
- 案件によりますが、1行あたり5営業日以内に収まっていると進捗が見えやすくなります。10日を超える行は、中で何をするのかを聞いて分解してもらうのが安全です。ただし細かすぎても更新が追いつかなくなるので、際限なく分解を求める必要はありません。
- Q. WBSをもらえない場合はどうすればいいですか？
- 形式にこだわらず、作業の一覧と日程が分かるものを出してほしいと伝えてください。小規模な案件ではWBSという名前の表を作らないこともあります。名前より、何をいつやるかが書面で共有されているかが重要です。
- Q. WBSとガントチャートはどちらを見ればいいですか？
- 両方です。作業の抜けは一覧（WBS）でしか見つからず、日程の詰まりすぎは横棒の図（ガントチャート）でしか見えません。多くの場合、同じ表の左右に並んでいます。
