システム開発のWBSの作り方｜粒度の決め方と抜けの潰し方
システム開発のWBSの作り方を調べる人の多くは、テンプレートを探しています。ところが他人のWBSをそのまま使うと、自分たちの案件に無い作業が並び、必要な作業が抜けた表ができあがります。WBSは分解のやり方そのものに意味があり、出来上がった一覧はその副産物です。この記事では、何を基準に分けるのか、どこまで細かくするのか、そして何が抜けやすいのかを、実際に手を動かす順番で整理します。
WBSが必要になるのは、見積もりと進捗が同じ言葉で話せないとき
WBSを作らずに進めているチームでも、案件は動きます。それでも作る必要が出てくるのは、たいてい次の場面です。
・見積もりを出した単位と、日々の進捗を報告する単位が違っていて、何割終わったのか説明できない ・作業の抜けが後から見つかり、そのたびに納期が動く ・担当を割り振ろうとしたら、何を渡せばよいのか自分でも分からない ・複数人で分担したら、同じ作業を2人がやっていた
これらは全部、作業の一覧が無いことから来ています。頭の中にある作業と、契約書に書いた成果物と、朝会で報告される内容が、それぞれ違う粒度で存在している状態です。
WBSは Work Breakdown Structure の略で、仕事を分解した構造という意味です。日本語では作業分解構成図と呼ばれます。名前に作業とありますが、実際に分けるのは成果物から始めるのが原則です。ここが理解の分かれ目になります。
定量的に管理することの必要性については、公的機関も同じ趣旨のことを書いています。
技術者の経験と勘に頼った方法ではなく、実際のプロジェクトデータに基づいた開発プロセスの改善を行う定量的なプロジェクト管理が必要です。 出典: ipa.go.jp
データに基づいて管理するには、まず数えられる単位に分かれている必要があります。WBSはその単位を作る作業だと考えると、目的がはっきりします。逆に言えば、数えるつもりのない案件でWBSを作っても、資料が1つ増えるだけで終わります。何を数えるために分けるのかを、作る前に言葉にしておいてください。
作業ではなく、成果物から分ける
WBSを作り始めるとき、いきなり「要件定義」「設計」「実装」「テスト」と工程名を並べる人が多くいます。これは間違いではありませんが、この形だけで止めると抜けが出ます。工程は入れ物であって、中身ではないからです。
まず、納品するものと、その途中で作られるものを全部書き出してください。 画面、バッチ処理、データベースの定義、外部との連携、管理機能、帳票、マニュアル、テスト仕様書、移行手順書。これが成果物です。
そのうえで、それぞれの成果物に対して工程を掛け合わせます。画面という成果物に対して、設計、実装、単体テストという工程がある。データ移行という成果物に対して、方式検討、ツール作成、リハーサル、本番実施という工程がある。この掛け算の形にすると、成果物が漏れていない限り作業も漏れません。
工程から入ると、なぜ抜けるのか。工程は案件によらず似ているため、テンプレートをそのまま使えてしまい、自分たちの案件に固有の成果物を考えないまま先へ進めるからです。マニュアルの作成が契約に入っているのに、工程だけ並べた一覧にはその作業がどこにも現れない、ということが起こります。
成果物を書き出す作業は、契約書と提案書を横に置いてやってください。 納品物の一覧が契約書に書かれているなら、そこが起点です。書かれていないなら、この段階で発注元と確認しておくべきことが見つかります。WBSを作る過程で、契約の曖昧さが表に出るのは、よくあることです。
100%ルール。親に無いものを子に置かない
WBSには、守ると崩れにくくなる原則があります。子の要素を全部足すと、親の要素とちょうど同じになるという考え方です。100%ルールと呼ばれます。
たとえば「ログイン機能」という親の下に、「画面の実装」「認証処理の実装」「単体テスト」の3つを置いたとします。この3つを終えればログイン機能が完成するなら正しく、パスワード再発行の処理が別に必要なのに書かれていないなら、この分解は不完全です。
逆に、親に含まれないものを子に置くのも違反です。「ログイン機能」の下に「サーバーの調達」を置くと、親の範囲を超えます。サーバーの調達は別の親の下に置くべき作業です。
この原則を守ると、次の2つが自動的に得られます。
・足し算で見積もりが作れる。 子の工数を足せば親の工数になる ・進捗が計算できる。 子の完了数から親の進み具合が出る
守らないと、どちらも成立しません。子を全部終えたのに親が終わっていない、という状態は、分解が漏れているという意味です。この確認は、分解した直後にやってください。それぞれの親について「この子を全部やれば、この親は本当に終わるか」と声に出して確かめるだけです。5分で終わり、後から見つかる抜けの大半をここで潰せます。
粒度は、報告の周期から逆算して決める
どこまで細かく分けるかは、WBSで最も迷うところです。よく使われる目安として、1つの作業が8時間から80時間に収まるように分ける、という考え方があります。1日から2週間の範囲ということです。
ただ、この数字をそのまま当てるより、報告の周期から逆算するほうが実務に合います。進捗を週に1回報告するなら、1つの作業が2週間を超えないようにします。 2週間かかる作業は、報告のたびに「まだ途中です」としか言えず、遅れが表に出るのが遅くなります。毎日報告するなら、1つの作業は3日以内が目安になります。
逆に、細かすぎるのも問題です。1件が1時間で終わる粒度まで分けると、100人日の案件で作業が800件になります。この数を維持するには、管理そのものが1人分の仕事になります。
判断の基準を1つ持つなら、その作業が終わったかどうかを、担当者以外が見て判断できるかです。判断できるなら十分な粒度です。「調査する」「検討する」といった作業は、終わりが判断できません。「調査結果を1枚にまとめて共有する」まで書くと、判断できる形になります。
階層の深さにも目安があります。実務で扱いやすいのは4階層までです。案件、機能のまとまり、成果物、作業、という4段でたいていの案件は表せます。5段以上になると、番号が長くなって会話で使えなくなり、表の上でも折りたたみを開かないと全体が見えません。深くしたくなったら、まず上の階層の分け方が適切かを疑ってください。
粒度は、階層によって変えて構いません。契約に近い上のほうは大きく、担当者に渡す下のほうは細かく。全部の枝を同じ深さまで分ける必要はありません。難易度が読めている作業は浅く、初めてやる作業は深く分けるのが現実的です。
作る手順を6つに分ける
実際の作り方を、順番に書きます。
手順1は、成果物を全部書き出すことです。 前述のとおり、契約書と提案書を横に置きます。この段階では順番も工数も考えません。付箋でも表計算でも構いませんが、後で並べ替えるので、行を動かしやすい形にしてください。
手順2は、成果物をグループにまとめることです。 画面が30本あるなら、機能のまとまりで束ねます。ここで作られるのが上の階層です。まとめ方は、案件の説明のしかたに合わせるとよく、発注元との会話で使っている区切りをそのまま使うのが分かりやすくなります。
手順3は、各成果物に工程を掛けることです。 設計、実装、テストという工程を、成果物ごとに展開します。この時点で行数が一気に増えます。100本を超えても構いません。
手順4は、共通作業を別の枝として立てることです。 環境構築、進捗管理、レビュー、会議、ドキュメント整備。特定の成果物に紐づかない作業は、成果物の枝に無理やり入れず、独立した枝を作ります。この枝を忘れると、後述する抜けが発生します。
手順5は、担当と工数を入れることです。 担当を入れると、1人に寄っている枝が見えます。工数を入れると、全体の合計が出ます。この合計が見積もりと大きく違うなら、分解が足りないか、見積もりが甘いかのどちらかです。
手順6は、順序と依存を確認することです。 どの作業がどの作業の後でないと始められないかを見ます。ここで初めてスケジュールの形が見え始めます。順序は最後にやるのが要点で、先に順序を考えると、分解が浅いまま線を引くことになります。
WBS辞書に何を書くか
WBSの一覧だけでは、後から見た人に意味が伝わりません。項目名は短いため、「認証まわりの調整」と書かれていても、何をどこまでやるのかが読めないからです。
そこで、項目ごとに補足を書いた表を別に持ちます。WBS辞書と呼ばれるもので、書く内容は次の通りです。
| 項目 | 書く内容 |
|---|---|
| 番号 | 階層を表す通し番号 |
| 名称 | 作業の名前 |
| 完了の条件 | 何ができたら終わりか |
| 成果物 | 何が残るか |
| 担当 | 誰がやるか |
| 前提 | 何が終わっていないと始められないか |
| 工数 | 見積もった時間 |
このうち、完了の条件が最も重要です。 完了の定義が人によって違うことが、進捗が嘘になる最大の原因です。実装が終わったことを完了と呼ぶ人と、レビューが通ったことを完了と呼ぶ人が同じ表を更新すると、数字の意味が失われます。
辞書を全項目に書くのは負担が大きいので、実務では、初めてやる作業と、複数人が関わる作業に絞って書く形が現実的です。誰がやっても同じ結果になる定型作業には要りません。
前提の欄も、書き方に注意が要ります。「設計が終わっていること」とだけ書くと、どの設計なのかが読めません。前提には、必ず他の項目の番号を書いてください。番号で書いておけば、その項目が遅れたときに、影響する作業を機械的に洗い出せます。文章で書かれた前提は、案件が大きくなるほど照合できなくなります。
システム開発で抜けやすい作業
分解の段階で抜けやすいものは、案件が変わってもほぼ同じです。次を確認してください。
・開発環境と検証環境の構築、および途中での作り直し ・レビューの時間。実装した本人ではなく、レビューする人の時間 ・発注元の確認待ち。こちらが手を止めている期間 ・仕様変更の反映と、それに伴う影響調査 ・テストデータの作成。本番に近いデータを用意する作業は重い ・既存システムからのデータ移行と、そのリハーサル ・他社が担当する部分との結合と、その調整会議 ・受入テストの支援。発注元がテストする間、こちらは待機ではなく対応が要る ・マニュアル、運用手順書、引き継ぎ資料の作成 ・リリース当日の作業と、直後の監視
このうち、レビューと確認待ちは特に見落とされます。どちらも自分が手を動かしていない時間なので、工数として意識に上りません。ところがカレンダー上では確実に日数を消費します。実測すると、開発期間のうち2割から3割が待ち時間だった、という話は現場でよく聞きます。
これらを枝として立てておくと、遅れの原因を後から説明できます。実装が遅れたのではなく確認が返ってこなかった、という事実が、WBSの上に残ります。
抜けを減らすには、過去の案件のWBSを横に置くのがいちばん確実です。ただし、そのまま流用するのではなく、前回の案件で「後から追加した作業」だけを抜き出したリストを作っておいてください。これが自分たちのチームに固有の抜けやすい項目です。他社のテンプレートより、自分たちの前回の反省のほうが精度が高くなります。
もう1つ、非機能の要件から来る作業も抜けやすい部類です。性能を測る作業、負荷をかける試験、障害が起きたときの切り戻し手順の作成、ログの設計。これらは要件定義の文書に1行しか書かれていないことが多く、その1行の裏に何日分の作業があるのかは、分解して初めて見えます。要件定義の文書を読み返しながらWBSを点検する時間を、1回だけ取ってください。
誰と一緒に作るか。1人で作ったWBSは通らない
WBSを1人で作ると、速く終わります。そして、たいてい使われません。理由は2つあります。
1つ目は、抜けが埋まらないことです。 分解する人が経験したことのない作業は、書き出せません。インフラの構築を経験していない人が作ったWBSには、証明書の更新やドメインの設定が現れません。テストを専門にする人が居るなら、テストの枝はその人に分けてもらうべきです。
2つ目は、担当者が自分の作業として受け取らないことです。 誰かが決めた作業の一覧を渡されると、人はそれを「与えられたもの」として扱います。自分で分けた作業なら、期日の妥当性についても自分の判断が入ります。
現実的な進め方は、上の2階層を進行役が作り、その下を担当ごとに分けてもらう形です。全員を集めて全部を分解しようとすると、会議が長くなって最後の枝が雑になります。分解の会議は90分を上限にして、その場で終わらない枝は持ち帰るという区切り方が現実的です。
持ち帰った枝は、期限を決めて回収してください。回収する日を決めていないと、WBSは半分できたところで止まります。半分のWBSは、無いのと同じか、あるいは「できている」と誤解される分だけ悪くなります。
進捗をWBSの上で、どう数えるか
分解ができると、進捗を数えられるようになります。数え方は3種類あり、それぞれ見えるものが違います。
1つ目は、件数で数える方法です。 全200件のうち80件が完了なら4割。最も単純で、誰でも計算できます。ただし作業の大きさが揃っていないと意味が変わります。粒度を揃えておく価値は、ここに出ます。
2つ目は、工数で重みを付けて数える方法です。 各作業の見積もり工数を重みにして、完了した分を足します。大きさのばらつきを吸収できますが、見積もりが外れている作業があると、その分だけ数字が歪みます。
3つ目は、成果物の数で数える方法です。 画面が30本のうち何本できたか。発注元に説明するときは、この形がいちばん伝わります。工程の途中は数に入らないため、序盤は数字が動かず、終盤に一気に伸びる形になります。
社内の管理には2つ目、発注元への報告には3つ目、という使い分けが実務では扱いやすくなります。どれを使うにしても、途中の割合を人の申告で入れないでください。 半分終わったという申告は、実際には半分に達していないことが多いと言われています。完了か未完了かの2値で数え、途中を数えたいなら作業をさらに分けるほうが正確です。
発注元と共有するときに、どこまで見せるか
WBSを発注元に見せるかどうかも、決めておくべきことです。全部見せる、上の階層だけ見せる、見せない、の3つがあります。
上の階層だけ見せる形が、実務では最も多く選ばれます。 理由は、細かい作業まで見せると、作業の1つずつに意見が付き、こちらの作業のやり方まで決められてしまうことがあるためです。発注元が知りたいのは、いつ何ができるかであって、実装の手順ではありません。
ただし、発注元の作業は必ず見せてください。 確認の返事、テストデータの提供、受入テストの実施。これらは相手が動かないと止まる作業です。WBSの中に相手の作業として明示し、期日を入れておくと、遅れが出たときにどちら側の原因かが記録として残ります。
見せる範囲を決めるときに気をつけたいのは、途中で範囲を変えないことです。最初に細かく見せて、途中から上の階層だけにすると、隠しているという印象を与えます。最初に決めた粒度で最後まで通してください。
WBSから見積もりを作るときに起きること
WBSに工数を入れると、そのまま見積もりになりそうに見えます。ここに落とし穴があります。
1つ目は、積み上げた合計が必ず小さく出ることです。 個々の作業を見積もるとき、人は順調に進んだ場合を想定します。それを100件足し合わせると、100件すべてが順調に進む前提の数字になります。実際にはそうなりません。
2つ目は、抜けた作業の分がまるごと欠けることです。 前節で挙げた項目が入っていなければ、その分だけ見積もりが少なくなります。
3つ目は、粒度が粗い枝ほど誤差が大きいことです。 分解が浅い枝は、中身が読めていないという意味でもあります。誤差の大きさは、分解の深さと逆の関係にあります。
対策としては、まず積み上げた数字とは別に、過去の似た案件の実績から出した数字を作り、2つを突き合わせます。差が2割以上あるなら、どちらかが間違っています。差の原因を1つずつ潰していくと、抜けが見つかります。
そのうえで、余裕を1本の枝として明示的に置いてください。各作業に少しずつ上乗せする形にすると、余裕がどこにどれだけあるのか誰にも分からなくなり、結果として全部使われます。まとめて置いておけば、残りがいくつか見えます。
WBSとガントチャートは別物。番号で繋ぐ
WBSとガントチャートを同じものだと思っている人がいますが、役割が違います。WBSは、やることの一覧です。時間の情報は持ちません。 ガントチャートは、それぞれの作業をいつやるかを時間軸に置いたものです。
順番としては、WBSが先です。やることが決まっていないのに線を引くと、線を引きながら作業を思い出すことになり、抜けが増えます。
2つを繋ぐのは番号です。WBSの各項目に階層を表す番号を振り、ガントチャートの各行に同じ番号を持たせます。番号が一致していれば、片方で追加した作業がもう片方に無いことを機械的に見つけられます。
番号の振り方には注意点があります。途中に作業を挿入したとき、番号を振り直さないでください。 振り直すと、過去の議事録やメールに書かれた番号が別の作業を指すようになります。挿入するときは枝番を使い、削除するときは番号を欠番のまま残します。
もう1つ、WBSの階層をそのままガントチャートの行の階層にすると、行数が膨らんで読めなくなります。ガントに載せるのは、報告で使う階層までにしてください。細かい作業は担当者の手元で持ち、全体の図には出さない、という分け方が実務では扱いやすくなります。
作ったWBSが2週間で古くなる理由
丁寧に作ったWBSも、放っておくと現実と離れます。よくある3つの形を挙げます。
1つ目は、更新する人が1人しかいないことです。 作った人が全部の変更を反映する形にすると、その人が忙しい週に更新が止まります。止まった表は、次の週にはもう信用されません。
2つ目は、更新する場所が分かれていることです。 WBSは表計算にあり、進捗はチャットで報告され、課題は別の一覧にある。3か所に同じ情報が散ると、どれが正しいのか分からなくなります。
3つ目は、変更が記録に残らないことです。 作業が増えたとき、いつ誰の判断で増えたのかが残っていないと、後で見積もりとの差を説明できません。行を足すだけでなく、追加した日と理由を書く欄を作っておいてください。
3つとも、仕組みで防げます。更新の担当を枝ごとに分け、進捗の置き場所を1か所に決め、行を足したときに日付と理由を書く欄を用意する。この3つを最初に決めておくだけで、WBSの寿命は大きく延びます。逆に、これらを決めずに配ったWBSは、2週間ほどで参照されなくなると言われています。
対策としては、WBSそのものを更新する頻度を下げ、日々の進捗は別の場所で持つ形が現実的です。WBSは分解の結果であり、確定した構造です。毎日書き換えるものではありません。書き換えが毎日必要になっているなら、分解の粒度が細かすぎるか、要件がまだ固まっていないかのどちらかです。
アジャイルで進める場合、WBSは要るのか
反復して開発を進める場合、WBSは要らないという意見があります。実際には、要らないのではなく、対象が変わります。
繰り返しの中で作るものは、その回ごとに決まります。 ここは一覧を先に固めるものではありません。一方で、案件全体として必ずやる作業は、反復のやり方に関係なく存在します。環境の構築、外部との接続、データの移行、受入の支援、リリースの手順。これらは先に分解しておくべきものです。
つまり、変わらない部分だけWBSにして、変わる部分は反復の仕組みで扱う、という使い分けになります。全部をWBSにすると、変更のたびに作り直すことになり、続きません。全部を反復に任せると、案件全体で見たときの抜けが最後に出ます。
契約の形も判断に効きます。あらかじめ範囲と金額が決まっている契約なら、範囲を示すものとしてWBSが必要になります。作業した分だけ支払う形の契約なら、細かい一覧より、いま何に取り組んでいるかが見えることのほうが重要です。
作ったWBSを、どこに置くか
分解の結果をどこに置くかで、その後の使われ方が変わります。表計算で作るのが最も手軽で、階層も番号も自由に扱えます。ただし、更新する人が増えたときに壊れやすく、担当者が自分の作業だけを見る、という使い方がしにくくなります。
作業の一覧をそのまま日々の進行に使うなら、板の形に載せる選択肢があります。1つの作業を1枚のカードにして、状態の列を移動させる形です。この形の利点は、更新の操作がカードを動かすことだけで済む点にあります。何ができるのかはできることに整理されており、費用の考え方は料金で確認できます。
板に載せる場合、階層の扱いが表計算とは変わります。WBSの上の階層はボードや区分として持ち、実際に手を動かす作業だけをカードにするのが現実的です。番号は、カードの名前の先頭に付けておけば、表計算側と突き合わせられます。
候補を比べるなら、それぞれの道具が階層と時間軸をどう扱うかを見てください。板の形が基本の道具についてはTrelloとの比較、一覧とタイムラインを行き来する形はAsanaとの比較、自分でデータベースを組む形はNotionとの比較、色分けした表で眺める形はmonday.comとの比較にまとまっています。課題管理から入る国内サービスとの違いはBacklogとの比較、無料の板から始める形はJootoとの比較にあります。全体を横に並べたものは比較の一覧です。
いま使っている板から移す場合の手順はTrelloからの移行にありますが、自動で取り込める形が用意されているのはTrelloからで、それ以外は書き出したデータを整えて入れ直すことになります。社内のデータを外部に置くことへの説明が必要なら安全性の考え方、細かい疑問はよくある質問を見てください。
最後に、道具の話と分解の話は別だと押さえておいてください。機能で絞らず、区切るのは人数とボードの数だけという料金の形をとる道具を選んでも、分解が粗ければ進捗は読めません。逆に、丁寧に分解できていれば、置き場所が表計算でも板でも、必要な情報は取り出せます。先に手をかけるべきなのは、分解のほうです。
Q1. WBSは工程から分けるのと成果物から分けるのと、どちらが正しいですか？
成果物から始めて、そこに工程を掛け合わせる形が抜けにくくなります。工程だけを並べると、案件ごとに違う成果物を考えないまま進めてしまい、マニュアルや移行作業のような固有の項目が丸ごと欠けます。契約書と提案書を横に置いて、納品するものと途中で作られるものを全部書き出すところから始めてください。
Q2. WBSの粒度はどこまで細かくすればよいですか？
報告の周期から逆算します。週に1回報告するなら1つの作業が2週間を超えないように、毎日報告するなら3日以内が目安です。あわせて、その作業が終わったかどうかを担当者以外が見て判断できるかを確認してください。判断できない粒度は、成果物まで書き足すと判断できる形になります。
Q3. WBSとガントチャートは同じものですか？
別のものです。WBSはやることの一覧で時間の情報を持たず、ガントチャートはそれをいつやるかを時間軸に置いたものです。作る順番はWBSが先で、番号を一致させて繋ぎます。作業を途中で挿入するときは番号を振り直さず、枝番を使ってください。振り直すと過去の議事録やメールの番号が別の作業を指します。
Q4. アジャイルで開発する場合もWBSは必要ですか？
案件全体として必ず発生する作業については必要です。環境の構築、外部との接続、データの移行、受入の支援、リリース手順などは、反復のやり方に関係なく存在します。一方で、繰り返しの中で作る機能は、その回ごとに決めるほうが実態に合います。変わらない部分だけWBSにして、変わる部分は反復の仕組みで扱う形が現実的です。