前回,目標達成までのスケジュールの立て方について,WBSへの展開や依存関係の設定,クリティカルパスの特定などを重点的に説明しましたが,例えば事業計画を融資者やプロジェクトスポンサーに説明する際などには,作成したスケジュール通りの目標達成が可能であることを客観的に論理立てて説明する必要があります。
こんな方におすすめ
- スケジュールは立てたが,本当にこのスケジュール通りに進められるか検証したい
- ステークホルダーにスケジュールの妥当性を示すため,スケジュールの客観的な裏付けをしたい
今回はもう少し踏み込んで,WBSに細分化した工程の期間を見積もる方法を説明します。
1. 期間の見積 (工数を定量化できる場合)
期間を見積ろうとしている作業の内容によって,大きく二つのケースに分けて考えます。工数を定量化できる場合とできない場合です。
いきなり工数という用語が出てきました。そもそも工数ってなんだ?と思われた方もいると思います。
ざっくりいうと作業量のことで,一人が一時間/一日/一か月でこなせる作業量をそれぞれ1人時間/1人日/1人月というように表現します。
工数を定量化できるのは,仕事量を定量化でき,類似の仕事の実績などから作業効率がわかる場合です。
このとき,作業日数は以下の式で算出することができます。
期間 (日) = 工数 (人日) / 作業人数 (人)
= [仕事量 (単位) / 作業効率 (単位/人日)] / 人数 (人)
たとえば,あなたが5人のエンジニアを率いてあるシステムを開発するプロジェクトのマネージャーとして,顧客からどれくらいの納期で納品できそうかを尋ねられたとしましょう。
あなたはそのシステムを構成するコードがおおよそ200,000行程度になるだろうと見積もり,あなたのチームのエンジニアはひとり1日当たり800行のコードを書く能力があるとします。 このとき,納期は
200,000 / 800 / 5 = 50 (日) = 10週間 (1週間5営業日と想定),2か月強
と計算できます。
ただし,実務の世界ではこうして見積った納期をそのまま正直に答えてはいけません。実際にはプロジェクトにはトラブルがつきもので,ここでざっくりと見積もった納期に間に合わなくなるような状況は往々にして起こります。
たとえば,作業開始から1週間は順調に進捗していたものの,2週目にあなたのチームのエンジニアが休日のサイクリング中に交通事故にあい,右腕に全治3か月の重傷を負ってしまったとしたらどうでしょうか。
残りの作業を4人に減ったチームで終わらせるには,
(200,000-800*5*5)/ 800 /4 = 56.25 (日)
と,残り9週間で終わるはずが追加で2週間以上必要,という計算になってしまいます。
少し話がそれていますが,プロジェクトにはこのように不測の事態がつきもので,当初予定したスケジュール通りにプロジェクトが進むことは滅多にありません。それを踏まえて,顧客などへの期限の返答は少しバッファを持ったスケジュール感に基づいて行うようにしたいところです。
2. 期間の見積 (工数を定量化できない場合)
WBSに細分化した作業の中には,契約の交渉など工数設定が適切でない作業や,実績がなく作業効率がわからないような作業も出てくると思います。
そうした作業の期間の評価には自身の経験や情報収集をベースにしたベンチマーキングを行うことになりますが,ここではより精度を上げるための3点見積という手法を紹介します。
3点評価とは,「最も楽観的なスケジュール,もっともありえそうなスケジュール, 最も悲観的なスケジュール」を検討し,3ケースの期間から期待値を算出する方法です。期待値の算出方法は次の2通りがあります。
ココがポイント: 3点見積の計算式
(O+M+P)/3 (三角分布)
(O + 4M + P) /6 (ベータ分布,PERT式)
ここで,
O: 最も楽観的な所要期間 (日) ,M: もっともありえそうな所要期間 (日),P: 最も悲観的な所要期間 (日)
です。
詳しい説明をしようとすると確率分布などの知識が必要なのでここでは踏み込みませんが,PERT式のほうがより正確に期間を見積ができるといわれています。
具体例で考えてみましょう。
例えば企画開発において,商品の試作品を作るのにどれだけ時間がかかるかを見積もるときに,
28才男性
何もかもうまくいって5日,まあ12日くらいに落ち着きそう,遅くても25日くらいかなあ
とシミュレーションしたとしたら,計画上の所要日数はPERT式を用いて
(5 + 4 x 12 + 25) / 6 = 13日
と計画することになります。
この考え方は会社員としての仕事にも応用が利くかもしれません。あなたが上司からとっさに「あの仕事いつまでに終わる?」と聞かれたとき,最も楽観的な見通しに基づいて期限を返答してしまうことが多いと思いますが,少し冷静になって3点評価で算出した期限を答えられると,結果としてスケジュールをきっちり守る人として評価が上がっていくかもしれません。
3. 押さえておきたいポイント
リソースは想定通りのパフォーマンスか?想定通りの稼働時間か?
期間の見積をに行う場合,工数を定量化できる場合もできない場合もタスクにアサインできるメンバーの仕事効率をもとに期間を見積りますが,実際にはメンバーごとにスキルのレベルは異なりますので,本当に想定通りの作業効率でプロジェクトを進めることができるか,あらためてレビューしましょう。また,ほかのプロジェクトと掛け持ちしているためにパートタイムで参画しているメンバーがいる場合,その人の一日あたりの作業量を稼働時間に合わせる必要があることに留意しましょう。
PDCAに活かす
どんなに緻密に計画を練ったとしても,計画段階でプロジェクト進行中に起こりうるイベントを悉く予言できるわけがないので,想定外の事態が起こって計画通りにいかないのがプロジェクトの常です。
「だったら計画なんてしなくていいじゃん」と考えた方もいるかもしれませんが,ベースラインがあるからこそ
- なぜ計画通り進んでいないのか
- 計画時の想定と現状のギャップは何なのか
- 軌道修正して計画に戻るにはどうすればいいのか
と予実の差を分析し,次の施策に活かす,というPDCAが回るわけです。なので,ぜひ計画段階から
「この計画をもとにPDCAサイクルを回すんだ」
という意識をもってスケジュールを立てていただければと思います。
4. まとめ
2回に分けて,スケジュールの立て方の概要を説明してきました。建設業やIT開発などの案件では,プロジェクト入札時に納期が契約条件の一部となることがほとんどなので,今回説明してきたような手法を駆使し,社内の人的資源の稼働状況などを見極めながら,顧客要求をWBSに分割,各工程の依存関係や各工程の作業期間を分析し,実現可能性を評価したうえで受注戦略を立案しています。
このような大規模案件に携わる方のみならず,これから事業立ち上げを目指している方など,ある時点までに何らかの目標を達成したいと考えている方は,このような考え方を活用してスケジュールを作成されてみてはいかがでしょうか。