第2章 2.2 ← 2.0 プロジェクトの進み方
計画とは、作業を並べることではなく「渡せるもの」を並べることです
計画フェーズでつくるものは、たいていWBSとスケジュールです。ここでほとんどの人がやってしまう間違いがひとつあります。「作業」を並べてしまうことです。作業で割ると、終わったかどうかを本人しか判定できなくなり、そのあとの進捗管理が全部あいまいになります。
この記事の要点
- WBSの末端は、すべて名詞で書いてください。「〜する」ではなく「〜されたもの」です。
- 工程名を並べただけのWBSは、何が終わったのかを誰も判定できません。
- 分解の目的は網羅ではなく、抜けを見つけることと、担当を割り当てられる大きさにすることです。
- 末端の大きさの目安は、1〜5人日。これより大きいと、遅れに気づくのが遅れます。
- 見積りは、作業をする人と一緒に出してください。ひとりで出した見積りは、必ず自分の得意分野に寄ります。
末端を名詞で書く、それだけです
WBSの良し悪しは、末端が名詞になっているかどうかでほぼ決まります。理由は単純で、名詞なら他人が見て終わったかどうか判定できるからです。
「テストする」は、終わったかどうか本人にしか分かりません。「テスト済みの給与連携」なら、動かしてみれば誰でも分かります。「設計する」は本人の感覚ですが、「承認された要件定義書」なら、承認印があるかどうかで判定できます。
分け方は、工程よりも「決める・つくる・渡す」
WBSの中段をどう切るかには決まりがありません。ただ、工程名（要件定義・設計・製造・テスト）で切るのは、日本の現場でよく見かけるわりにあまり良い切り方ではありません。理由は2つあります。
ひとつは、工程名で切ると成果物が見えなくなることです。「設計」の下に何がぶら下がるのかが人によって違い、結局は工程の中に作業を並べることになります。
もうひとつは、渡す準備が丸ごと落ちることです。マニュアル、研修、運用手順、問い合わせ窓口の取り決め。これらは工程の並びのどこにも入らないので、テストが終わってから慌てて始まります。図のように「渡すもの」という枝を最初から立てておけば、忘れません。
末端の大きさは、1〜5人日を目安に
どこまで細かく分けるかは悩みどころですが、目安があります。末端がおおむね1〜5人日に収まる大きさです。
これより大きいと、遅れに気づくのが遅れます。20人日の項目は、1か月間ずっと「着手中」のままで、遅れているかどうか分かりません。逆に細かすぎると、管理する手間のほうが大きくなり、更新されなくなります。更新されないWBSは、ないのと同じです。
ただし、これは近い時期の話です。半年先の作業を1人日単位まで割っても、その精度には意味がありません。近いところは細かく、遠いところは粗く。進むにつれて細かくしていきます。この考え方は3.2で詳しく扱います。
見積りは、やる人と一緒に出します
WBSができたら工数を入れますが、ここでひとりで数字を埋めないでください。作業をする人と一緒に出すことに、2つの意味があります。
精度が上がるのは、当然のこととして。それ以上に大きいのは、その人が数字を自分のものとして扱うようになることです。上から降ってきた5人日と、自分が「5人日です」と言った5人日では、超えそうになったときの反応がまったく違います。前者は黙って超え、後者は超える前に言ってきます。
そして、見積りを聞くときには必ずもう一問足してください。「これが倍かかるとしたら、何が起きたときですか」。この問いには、みんな正直に答えます。自分の能力ではなく、世の中の話だからです。返ってくる答え——テスト環境が用意できていなければ、先方のデータが前回並みに汚ければ、また別案件に引っ張られたら——が、そのままリスクの一覧になります。
「工数」と「期間」は別のものです
5人日の作業が5日で終わるとは限りません。その人が3つの案件を掛け持ちしていれば、実際には3週間かかります。工数を期間に変換するときは、その人がこのプロジェクトに週何日使えるのかを必ず確認してください。ここを100%として計算した計画は、初日から破綻しています。
順番は、依存関係で決まります
末端が並んだら、次は順番です。ここで見るのは「やりやすい順」ではなく、何が終わらないと何が始められないかです。
「移行された社員データ」は「確定した勤務ルール」が決まらないと作れません。「研修を受けた人」は「操作マニュアル」がないとつくれません。この前後関係を書き出すと、いくつかの項目が一本の鎖でつながっていることが見えてきます。この鎖がクリティカルパスで、ここが1日遅れると全体が1日遅れます。
逆に言えば、鎖の上にない作業をいくら前倒ししても、納期は1日も動きません。忙しいのに終わりが近づかない、という感覚がある現場では、たいてい鎖の外側で頑張っています。
ABではこう見えます
AB Projectsでは、WBSの末端をそのままタスクとして登録できます。名詞で書いておけば、タスク名を見ただけで完了条件が分かるので、「これって終わってますか」という確認の往復が減ります。
依存関係は、ガントの表示で線としてつながります。線がつながっていれば、前の作業を1日延ばしたときに後ろが自動的に動くので、影響範囲を頭で計算する必要がありません。逆に線を引いていないと、それはただの棒グラフです。詳しくは5.1で扱います。
このページで使った言葉
- WBS
- 成果物や作業を、管理できる大きさまで分解して並べたものです。目的は網羅ではなく、抜けを見つけることと担当を割り当てられる粒度にすることです。くわしく →
- 成果物
- 相手が受け取れる形になった結果です。作業ではなく成果物で計画を組むと、進捗が意見ではなく事実になります。くわしく →
- 工数
- 作業に必要な人の手間を人日・人月で表したものです。期間とは別物で、その人の稼働率を掛けないと日程になりません。くわしく →
- 依存関係
- ある作業が終わらないと次を始められない、という前後のつながりです。先行・後続とも言います。くわしく →
- クリティカルパス
- そこが1日遅れると全体が1日遅れる、つながった作業の経路です。急ぐべき場所を教えてくれます。くわしく →
- 見積り
- どれくらいの手間や費用がかかりそうかを、根拠をもって示したものです。幅を添えずに出すと、受け取った側では約束に変わります。くわしく →
あわせて読みたい
3.2 スケジュールの立て方
工数を日程に変換するときに、必ず必要になる考え方。
5.1 ガントチャートの使い方
依存関係を線でつなぐと、何が見えるようになるのか。
2.3 実行
計画ができたあと、ずれをどうやって見つけるか。