タイム・マネジメントの心得 ~あなたを多忙から開放する10の方法~

第9回 進捗をはかる

2009年1月15日

この記事を読むのに必要な時間:およそ 2.5 分

進捗率を数値化する「アーンドバリュー分析」

次にご紹介するのは,情報処理技術者試験「プロジェクトマネージャ」2004年秋季の問題より,筆者が一部改変したものです。問題の主旨はこうです:

  • 10本のプログラムからなるシステムを完成させるプロジェクトがあります。
  • 1本のプログラムを完成させるには1人月の工数がかかると見積もられました。
  • 各プログラムの開発作業は,設計(20%⁠⁠→コーディング(50%⁠⁠→テスト(30%)のプロセスからなると推定されています。

さて,作業開始から18日たった時点で進捗状況を調べたら下表のとおりでした。このとき,現時点での進捗率を求めなさい。

表1 進捗率の計算

情報処理技術者試験「プロジェクトマネージャ⁠⁠ 2004年秋季の問題より(筆者が一部改変)

  総数(本) 完了数(本) 見積工数(人月) 実績工数(人月)
設計 10 10 2.0 2.5
コーディング 10 6 3.0 4.0
テスト 10 3 0.9 1.5
合計 10 3 5.9 7.0

18日目に,上の表のような状態だった。進捗率を求めよ。

3/10=30%?(完成数基準)
7.0/10=70%?(実績基準)
5.9/10=59%?(見積基準)

この問題,皆さんならどう答えますか? ぱっと考えると,どうも三つの可能性がありそうです。

(1)まず,完成したプログラムの本数の割合で計算する方法。3/10=30%となります。これを「完成数基準」とよぶことにしましょう。
⁠2)つぎは,これまでに実際に費やした費用と労力(すなわち,すでに完了したタスクの実績工数)をベースに計算する方法です。実績工数は現時点で合計7.0人月ですから,7.0/10.0=70%と考えられます。これを「実績値基準」と呼びましょう。予算消化率による計算といっても良いでしょう。
⁠3)もう一つ考えられるのは,すでに完了したタスクについて,見積工数を重みづけとして計算する方法です。見積工数は合計5.9人月でした。この分が終わったのだから,5.9/10.0=59%となります。これを「見積値基準」とよぶことにします。

さて,どれが正解でしょうか。完成数基準の計算は単純で分かりやすいのですが,どれかプログラムが1本でも完成しないうちは,どれだけ設計やコーディングを進めても,進捗率がゼロのままになってしまいます。これは仕事の途中経過を測るにはいささか不便でしょう。

では,実績値基準ではどうか。もし仮に,現在までにすでに9人月かかったとすると,90%の進捗で,もし12人月かかったら,120%の進捗(?)ということになってしまいます。明らかに不合理ですね。つまり,予算消化率で進捗率は量れないのです。

ということは,消去法から考えて,の見積値基準が正しい進捗率の計算法ということになります。この方法を整理すると次のようになります:

  • 各タスクに見積った工数を,プロジェクトにおけるそのタスクの価値とする
  • 完了したタスクの価値の合計を計算する(これを「出来高」ないし「アーンドバリュー」と呼びます)
  • プロジェクト全体の価値は,全タスクの価値の合計によって計算する
  • 「出来高」をプロジェクト全体の価値で割ったものを進捗率と定義する

このような進捗の計算方法を,アーンドバリュー分析と呼び,これをもとにプロジェクトを運営していく方式をアーンドバリュー・マネジメント・システム(EVMS)と呼びます。

隘路とマイルストーンで進捗を測る

アーンドバリューによる進捗計算の方法は理論的にはすっきりと見事なのですが,現実のオフィスワークに適用しようとすると,すべてのタスクの工数見積が必要になり,いささかやっかいです。そこで,費用や工数を使わない方法もご紹介しておきます。

前回学んだように,プロジェクト全体の工程はクリティカル・パス(隘路)の長さで決まります。したがって,いま隘路のどこまで進んだかによって,プロジェクトの進捗を計ることができるわけです。

第7回8回で出した新製品開発プロジェクトを例にとります。隘路全体の長さは70日でした。計画では,基本設計が完了するのは45日たったところです。その先はあと25日かかりますから,進捗率は45÷70=64%となります。ほぼ2/3のところまできたと考えるわけです。

ところで,もし基本設計完了までに50日かかっていたら,進捗率はどう計算すべきでしょうか。このとき,進捗率は50÷70=71%だ,などと計算してはいけません。それだと,実績値基準と同じ誤り,つまり「過去これだけ頑張ったんだから進捗は上がった」という論理になってしまうのです。

過去どれだけ遅れたにせよ,今からは最低25日かかる。それでは,全体で50+25=75日かかることになるから,進捗率=50÷75=66%と計算すればよいでしょうか?

実は,これも誤りです。その論法でいけば,今まで仮に100日かかっていたら進捗率は100÷(100+25)=80%,仮に1000日かかっていたら進捗率=1000÷(1000+25)=98%ということになるはずです。つまり過去に手間取れば手間取るほど,進捗率は100%に近いことになってしまい,明らかに不合理です。

合理的な考え方とは,たとえ現実には過去に何日かかっていたとしても,予定の線から割り出して,45÷70=64%と計算するのが正しいのです。これが,⁠あとどれくらい仕事が残っているかで進捗率を計算する」考え方です。

タイム・マネジメントにおいては,隘路の主要な達成ポイントに「マイルストーン」を置きます。マイルストーンを達成したら,全体の何%かを,計画時点に計算で定めておきます。たとえば,新製品コンセプト完了が50%,詳細設計完了が79%という具合です。こうすると,隘路以外のタスクに従事している他のメンバー全員にも,要所要所で,進捗がどこまで行ったのか,共有しやすいのです。プロジェクトの進捗は,隘路とマイルストーンで把握するものだと心にとめておいてください。

図2 クリティカル・パスとマイルストーンの設定

図2 クリティカル・パスとマイルストーンの設定

著者プロフィール

佐藤知一(さとうともいち)

プロジェクト・アナリスト。エンジニアリング会社に勤務し,国内外の製造業向けの工場設計および生産システムづくりに従事するかたわら,執筆・講演活動などを行っている。専門はプロジェクトマネジメント・スケジューリング・生産計画・リスク分析など。海外におけるプロジェクト事情にも詳しい。

URLhttp://www2.odn.ne.jp/scheduling/

ピックアップ

ヒューマンリソシアのGITサービスが目指す,時代にアジャストするエンジニアチームの作り方

アフターコロナにおけるエンジニアチームの作り方,グローバルな視点でのエンジニア獲得と開発とコミュニケーションの在り方について取り上げます。

LINE テクノロジー&エンジニアリング大全

「LINE DEVELOPER DAY 2020」より,注目すべきテクノロジー,エンジニアリングをピックアップし,詳説インタビューを実施しました。

プロダクト思考で開発が進む「みてね」の今とこれから~みてねの生みの親笠原健治氏,開発マネージャ酒井篤氏が考える,プロダクトとエンジニアリングの素敵な関係

「家族アルバム みてね」を支えるエンジニアリングについて,開発体制やプロダクトの開発・運用,これからのビジョンについて伺いました。

自分の証明と持続的な学びがこれからのDX人材の鍵を握る ~A-BANKが考えるDX人材バンクの在り方とは?

2020年11月にスタートしたA-BANKの人材バンク。評価・育成・紹介の一体型人材紹介から見える,これからの人材エコシステムに迫ります。

APIゲートウェイとサービスメッシュの違い

APIゲートウェイとサービスメッシュの,それぞれの概要とユースケースを紹介し,いずれを使用するかの判断の指針となるチートシートを提供しています。

バックナンバー

No12(2009.04)

今回のSoulHackで主に取りあげるのは,梅田望夫の「ウェブ時代をゆく」という本です。

No11(2009.03)

今回のSoulHackで取りあげるのは,阿部謹也の「世間学への招待」と他1冊の本です。

No10(2009.02)

今回のSoulHackで取りあげるのは,山本七平の「空気の研究」という本です。

No9(2009.01)

今回のSoulHackで取りあげるのは,アーノルド・ミンデルの「紛争の心理学」という本です。

No8(2008.12)

今回のSoulHackで取りあげるのは,河合隼雄氏の「カウンセリングを語る」という本です。

No7(2008.11)

特集:2008年度日本OSS貢献者賞受賞者インタビュー

No6(2008.10)

特集:エンジニアの実践的キャリアアップ思考法

No5(2008.09)

特集:事例でわかる,プロジェクトを失敗させない業務分析のコツ

No4(2008.08)

特集:ゼロからはじめるPSP

No3(2008.07)

特集:今こそ使える! プロトタイピング

No2(2008.06)

特集:「開発スタイル」開発法

No1(2008.05)

特集:エンジニアが身につけたい基本スキル 2008

-->