なぜ4階層にしたか ― 「成果物」の層を足した理由
WBS を扱うツールをいくつか触ると、たいてい構造は似ています。いちばん上に「プロジェクト」があって、その下に作業の「タスク」がぶら下がる。もう少し丁寧なものだと、間に「フェーズ」や「リスト」を一段挟んで3階層になっている。LayerClock はここに、もう一つだけ層を足しました。フェーズとタスクの間に「成果物」を置いて、4階層にしています。
階層は多ければいいというものではありません。深くするほど入力の手間は増えるし、浅いほうが気持ちよく回る場面も多い。それでも一段増やしたのには理由があって、この記事はその「増やした一段」だけの話です。なぜフェーズとタスクだけでは足りなかったのか、成果物を挟むと計画の何が変わるのか、そして良い成果物の切り方とは何か、という順で書きます。
フェーズとタスクの間に、穴が空いている
私は昔フリーランスで受託をやっていて、その後は大きな会社で SE をやり、今はセキュリティのコンサルをしています。職種も現場も変わりましたが、どこでも同じ場面を見てきました。立派な WBS を作ったのに、途中から誰も見なくなる。 いわゆる形骸化です。
なぜ形骸化するのか、理由はいくつもあります。でも構造の面で一つはっきりしているのは、「何が完成したら、この塊は終わりなのか」を表す単位が、計画から抜け落ちていることだと思っています。
具体的に見てみます。3階層のツールで、あるプロジェクトの「設計」というフェーズを作ったとします。その下に、タスクとして「画面遷移を書く」「テーブルを決める」「レビュー対応」「認証まわりを調べる」をぶら下げた。一見、ちゃんと分解できています。でも、ここで抜けているものがあります。設計フェーズの中で、そもそも何を作り終えたら設計は終わりなのか――「基本設計書」なのか、「画面モックの一式」なのか、「API 仕様書」なのか。この「作り終えるべきもの」が、フェーズとタスクの間からこぼれ落ちています。
抜けたまま進むと、何が起きるか。フェーズは大きすぎて、いつ終わったのか判定しづらい。タスクは細かすぎて、一つ消しても全体のどこが進んだのか分からない。その間に「これが出来上がれば一区切り」と言える単位がないと、進捗は「タスクを何個消したか」でしか語れなくなります。「設計フェーズ、7個中3個完了」――この数字は、忙しさは表していても、完成は表していません。残り4個が軽いタスクなら設計はほぼ終わりだし、残り1個が本丸の基本設計書なら、まだ半分も来ていない。件数は、その区別を消してしまいます。
「成果物」という一段を、あいだに挟む
そこで LayerClock は、フェーズとタスクの間に「成果物」を置きました。設計フェーズなら「基本設計書」「画面モック」、実装フェーズなら「ログイン機能」「決済機能」、といった、出来上がったら人に渡せる／レビューに出せる単位です。タスクはその成果物を作るための細かい手順として、成果物の下にぶら下げます。
さっきの例を、この一段を入れて組み直してみます。設計フェーズの下に、まず「基本設計書」「画面モック」という成果物を置く。「画面遷移を書く」「テーブルを決める」は基本設計書の下に、「認証まわりを調べる」も基本設計書の下に。すると進捗は、「基本設計書は8割、画面モックはまだ着手前」と、完成の単位で語れるようになります。件数ではなく、渡せるものが何割仕上がっているか、で見える。
この一段があると、まず見積もりの当て方が変わります。「設計フェーズ全体で40時間」と大づかみに置くのでもなく、「タスク一個ずつ」と細かく積むのでもなく、成果物ひとつあたり何時間かかるかで見積もる。人が実務で自然に考える単位はたぶんこれで、「基本設計書を仕上げるのに3日、画面モックに2日」のほうが、「設計フェーズに40時間」より腹落ちします。大きすぎず、細かすぎない。見積もりを置くのにちょうどいい粒度が、ここにあります。
実績の読み方も変わります。タイマーで積み上げた時間が成果物ごとに集計されるので、「画面モックに、見積もりの倍かかった」といった読み方ができる。次に似た成果物を見積もるとき、この一行がそのまま根拠になります。フェーズ単位だと粗すぎて「設計が長引いた」までしか言えず、タスク単位だと細かすぎて「この関数に47分」がバラバラに散らばるだけ。成果物という単位は、振り返って次に活かせる、ちょうどいい塊なのだと思います。
良い成果物の切り方、悪い切り方
とはいえ、「成果物を置け」と言われても、最初はどこで切ればいいか迷います。私が目安にしているのは、次の三つです。
一つ、名詞で書けるか。「設計する」「テストする」は動詞で、これはフェーズや作業です。「基本設計書」「テスト結果報告書」は名詞で、これが成果物。動詞で書きたくなったら、それはまだ成果物になっていない合図です。
二つ、完成が判定できるか。「だいたい終わった」ではなく、「これで完成、レビューに出せる」と言い切れる線が引けるか。線が引けないものは、成果物としては大きすぎるか、曖昧すぎます。「フロントエンド」は判定できないが、「ログイン画面」なら判定できる。
三つ、誰かに渡せる／見せられるか。成果物は、突き詰めると「バトンを渡す単位」です。設計書はレビュアーに、機能はテスターに、記事は編集者に渡る。渡す相手が思い浮かぶ単位で切ると、粒度がだいたい合います。逆に、自分の中だけで完結して誰にも渡らない作業は、成果物ではなくタスクとして下にぶら下げたほうがいい。
悪い切り方の典型は、フェーズをそのまま成果物にコピーしてしまうことです。「設計」フェーズの下に「設計」という成果物を一つ置いても、何も分割していません。フェーズと成果物が1対1になったら、それは成果物の層を活かせていない合図で、フェーズの中を「渡せるもの」で2つ3つに割れないか、を考えてみるといいです。
これは Web 開発だけの話ではない
「成果物」と聞くと開発の設計書やモジュールを思い浮かべますが、この考え方は職種を選びません。私自身、受託開発から大手の SE、今のセキュリティコンサルまで、扱うものは変わっても、この「渡せる単位で切る」だけはどの現場でも効きました。
デザインなら、フェーズが「ビジュアル制作」で、成果物が「トップページのカンプ」「ロゴ一式」「バナー5点」。ライティングなら、フェーズが「執筆」で、成果物が「構成案」「本文ドラフト」「入稿版」。動画編集なら「本編」「サムネイル」「予告カット」。私が今やっているセキュリティ診断でも、フェーズが「診断」で、成果物は「診断報告書」「再テスト結果」「経営層向けサマリ」といった、渡すべきものの単位で区切ると、途端に見積もりと進捗が締まります。
共通しているのは、どの仕事にも「これが出来上がったら、ひと塊が終わる」というものがあるということです。エンジニアだけの概念ではなく、成果物を納める仕事なら、たいていこの単位を持っています。その単位を計画に持ち込めるかどうかで、WBS が生きた道具になるか、作った瞬間に飾りになるかが分かれる気がしています。
とはいえ、4階層をいつも全部埋める必要はない
正直に言うと、4階層は「必要ならそこまで割れる」という余地であって、「常にそこまで割れ」という強制ではありません。小さな個人案件なら成果物を並べるだけで足りるし、成果物がはっきりしない探索的な作業では、無理に切ろうとすると手が止まる。私自身、いつも浅く始めて、粗さが気になったところだけ深く割ります。どの深さが自分に合うかは「階層」が必要なのはどんな人かで別に書いたので、そちらに譲ります。
この記事で言いたかったのは、深さの選び方ではなく、その手前の一点――フェーズとタスクのあいだに「終わりの単位」を一つ持ち込めるかです。成果物という一段は地味ですが、私が WBS で「これは形だけになりそうだな」と感じる場面を、いちばん減らしてくれた工夫でした。増やすなら、ここだ、と思って足しています。
関連記事
- WBS とは何か。初めて聞いた人のための入門
- 見積もり精度を2倍にしたWBS分解の方法
- 職種別WBSサンプル集：Web開発・デザイン・ライティング・動画編集編
- 「どの工程に時間がかかっているか」を数字で語るための工数管理
- 工数管理ツールに「階層」が必要なのは、どんな人か
この記事で書いた4階層 WBS（プロジェクト・フェーズ・成果物・タスク）は、LayerClock の中心にある考え方です。 成果物ごとに見積もりを置き、タイマーで積んだ実績を成果物単位で読み返せます。この4階層とタイマーはずっと無料で使えます。