第3章 3.2 ← 3.0 計画の基本
5人日の作業が、5週間かかる理由
スケジュールが最初から崩れているプロジェクトには、たいてい同じ原因があります。工数と期間を同じものとして扱っていることです。5人日の作業は、5日では終わりません。その人が、この案件に週何日使えるかによって決まります。
この記事の要点
- 工数は「手間の量」、期間は「実際に経つ時間」です。稼働率を掛けないと日程になりません。
- 見積りを聞いたら、必ず「この案件には週何日使えますか」を足して聞いてください。
- 日程には、作業時間だけでなく待ち時間——回答待ち、承認待ち、レビュー待ち——を入れます。
- バッファは各作業に隠すのではなく、まとめて1か所に置いて、誰が使ったか分かるようにします。
- 納期から逆算した日程は、それが実現可能かどうかを何も証明していません。
工数を期間に変換する
「この作業、どれくらいですか」と聞いて「5人日ですね」と返ってきたとします。この5人日は、その作業だけに専念した場合にかかる手間です。カレンダーの5日ではありません。
聞くべきもう一問
実務でいちばん効く質問は、これです。
「この案件には、週何日使えますか」
この一問を足すだけで、日程の現実味がまったく変わります。そして日本の現場では、答えが「1日」や「0.5日」であることが本当に多い。定常業務があり、別案件があり、会議があるからです。
ここを確認せずに、5人日を「じゃあ来週末までですね」と置いてしまうと、初日から破綻した計画になります。破綻していることが表に出るのは1か月後で、そのときには「なぜか遅れている」という説明しかできません。
待ち時間を、日程に入れる
もうひとつ、日本の現場で日程が伸びる大きな要因が待ち時間です。これは作業ではないので、工数の見積りには入っていません。
- 相手の回答待ち。質問を投げてから返ってくるまで、社内で3日、社外で1週間はかかると見ておきます。
- 承認・稟議が回る時間。金額によっては2週間かかります。決裁のルートを最初に確認しておくと、この日数が読めます。
- レビューと直しの往復。1往復で終わることはまずありません。2往復を前提に置きます。
これらを日程に書いておくことには、副次的な効果があります。待ちが可視化されるのです。「先方の回答待ち：3営業日」と書いてあれば、4日目に催促できます。書いていなければ、誰も気づかないまま2週間が過ぎます。
バッファは、まとめて1か所に置く
不確実なことがある以上、余裕は必要です。ただし置き方に良し悪しがあります。
よくないのは、各作業にこっそり足しておくやり方です。実際にはよくやられていて、5人日の作業を8人日で申告する。理由は分かりますが、これには2つの問題があります。ひとつは、隠された余裕は必ず使い切られること。8人日あると、8人日かかります。もうひとつは、どこにどれだけ余裕があるのか誰にも分からなくなることです。
良いのは、まとめて1か所に置くやり方です。各作業は正直な見積りで並べ、最後にプロジェクト全体のバッファとして2週間置く。そして使うときに記録する。「データ移行で想定外があり、バッファを3日使用」と書けば、残りが見えます。
この形にすると、バッファは「隠れた甘え」ではなく「共有された残量」になります。残り3日になった時点で、全員がそれを知っている状態になります。
納期から逆算した日程は、何も証明していません
「3月末が納期だから、逆算するとテストは2月中旬から」という引き方は、日本の現場でごく普通に行われます。問題は、その日程が実現可能かどうかを何も検証していないことです。逆算は要求であって、計画ではありません。積み上げた日程と逆算した日程を並べて、差がどれだけあるかを見てください。差が2か月あるなら、それは「頑張る」で埋まる差ではありません。範囲か体制を動かす話になります。
急ぐべき場所は、鎖の上だけです
作業を並べて依存関係でつなぐと、いくつかの作業が一本の鎖になります。この鎖がクリティカルパスで、ここが1日遅れると全体が1日遅れます。
逆に言えば、鎖の外にある作業は、多少遅れても納期に影響しません。この区別が見えていないと、全部を同じ強さで急かすことになり、チームの体力が分散します。
実務的には、鎖の上にある作業を3〜5個把握しておけば十分です。「この3つが遅れたら、納期が動く」と言えれば、注意の向け先が決まります。詳しい引き方は5.1 ガントチャートの使い方で扱います。
節目は、他人が判定できる形で置く
日程には、いくつか節目（マイルストーン）を置きます。ここで気をつけたいのは、他人が達成を判定できる形で書くことです。
「2月末：設計完了」は判定できません。誰の感覚かによります。「2月末：要件定義書が○○部長の承認を得ている」なら判定できます。承認があるかないかだけです。
節目が判定できる形になっていると、その日に「達成した／していない」がはっきりします。していないなら、そこで手を打てます。曖昧な節目は、曖昧なまま通過し、遅れが最後まで見えません。
ABではこう見えます
AB Projectsでは、タスクに開始日と期日を入れると、そのままガントの形で見えます。依存関係を線でつないでおけば、前の作業を1日延ばしたときに後ろが動くので、影響範囲を手で計算する必要がありません。
待ち時間は、待ち自体をタスクとして置くのが実用的です。「先方回答待ち」を担当と期日つきで置いておけば、期日が来たときに表に出ます。何も置かないと、待っていることに誰も気づきません。バッファも同様に、独立したタスクとして置いておくと残量が見えます。
このページで使った言葉
- 工数
- 作業に必要な人の手間を人日・人月で表したものです。期間とは別物で、稼働率を掛けて初めて日程になります。くわしく →
- 稼働率
- その人が、実際にこのプロジェクトに使える時間の割合です。兼任が多い現場では20%前後になることも珍しくありません。くわしく →
- バッファ
- 想定外に備えて計画に持たせておく余裕です。各作業に隠すより、まとめて1か所に置くほうが機能します。くわしく →
- クリティカルパス
- そこが1日遅れると全体が1日遅れる、つながった作業の経路です。急ぐべき場所を教えてくれます。くわしく →
- マイルストーン
- 計画上の重要な節目です。他人が達成を判定できる形で書けていなければ、ただの日付です。くわしく →
- 稟議・決裁
- やるかどうかを組織として決める仕組みです。回る時間は日程に入れておかないと、そのぶん遅れます。くわしく →
あわせて読みたい
5.1 ガントチャートの使い方
日程を図にしたときに、初めて見えてくるもの。
3.3 体制と要員
稼働率の話を、人の側から見るとどうなるか。
2.2 WBSの作り方
日程を引く前に、何を並べておくべきか。