予定したコストの範囲内で，決められた期日までにプロジェクトを完了させる。そのために必須となるのが，科学的な進ちょく管理だ。正しく収集した進ちょくデータを様々な角度から分析し，計画通りの，あるいは計画を上回る実績を上げるようにプロジェクト作業をコントロールしなければならない。
布川 薫／日本IBM
 |
| 図1●進ちょく報告の悪い例 [画像のクリックで拡大表示] |
第7回から前回まで，「品質」のトラッキングとコントロールに焦点を当てて解説してきた。今回は，トラッキング／コントロールの対象として「進ちょく」を取り上げる。
「進ちょくはどうだね」，「まあまあですね」。システム開発の現場ではよく聞くセリフである（図1）。しかし，「がんばっている」，「まあまあですね」といったあいまいな言葉は，進ちょくが遅れ気味であることの「言い訳」や「逃げ口上」であることが多い。
プロジェクト・マネジャーやチーム・リーダーがこのようなあいまいな形で進ちょくを表現していては，正しく進ちょくを管理できないだけではなく，報告を受けるユーザー企業や上位のマネジャーに誤解を与える。これでは，プロジェクト成果物の品質基準を達成しつつ，予定したコストの範囲内で，決められた期日までにプロジェクトを成功裏に完了させることはできない。
正しく進ちょくを管理するためには，元々の計画値と対比できる「進ちょくデータ」を，プロジェクトの進行に合わせて収集していく必要がある。プロジェクトの進行が計画から逸脱した場合には，その対策を速やかに立てる。
このように，進ちょくをしっかりとモニタリングし，これに基づいて計画値どおりの，あるいは計画値を上回る実績を上げるようプロジェクトの作業全体をコントロールする。これがプロジェクトの進ちょく管理にほかならない。
進ちょく管理の方法
進ちょく管理は，プロジェクトにおける各チーム・メンバーの実作業の進行状況を，正確に把握することから始まる。
チーム・メンバーごとの作業状況を把握できなければ，上位の作業工程やプロジェクト全体の進ちょくを正しくとらえることは不可能だ。各チーム・メンバーによる作業実績報告が進ちょくのトラッキングのための基礎データとなり，このデータを集計した結果がプロジェクト全体や上位の作業工程の進ちょくを判断するためのデータとなる。
チーム・メンバーによる作業実績の報告は，週次などの間隔で定期的に行うよりも，ある作業が完了次第，リアルタイムに行う方がよい。定期的に報告を行うと，どうしても実際に作業が終わった時点とのギャップが生じてしまうからである。
また，グループウエアなどを使って作業実績を容易に入力できる仕組みを構築することで，メンバーによる実績報告の負荷をできるだけ小さくするのも大事なポイントだ。
作業実績の把握を，メンバーが一堂に会するミーティングの場で行うのは絶対に避けるべきである。これは，プロジェクトマネジメントの観点では非常に重要なことだ。作業実績報告だけを目的としたミーティングを長時間あるいは頻繁に実施することは，報告の準備作業を含めて各メンバーの大きな負担となるため，好ましくない。
完了分のタスクのみを計上
進ちょく管理の対象は，WBS（Work Breakdown Structure）で分割したタスクの最小単位（5人日程度のタスク，第5回参照）である。例えば設計や開発の工程では，まとまった入出力処理を行う画面の設計作業，テーブルの設計作業，プログラム・モジュールの作成作業，一連のテストケースの実施作業などが，典型的な管理単位となる。
作業実績は，WBSで分割したタスクごとの完了／未完了による積み上げで把握する（図2）。例えば，100人日の「タスクA」が詳細な作業計画のレベルで5人日の小タスク20個に分割されたとする。同様に，200人日の「タスクB」は40個の小タスクに，300人日の「タスクC」は60個の小タスクに，100人日の「タスクD」は20個の小タスクに分割したとしよう。この例では小タスクはすべて5人日としたが，実際には3人日のタスクや6人日のタスクもありえる。
 |
| 図2●実績計上の方法。作業の実績としては完了分のみ計上する（仕掛かり中のタスクは数えない） |
現時点でタスクAは15個の小タスクが完了しており5個が仕掛かり中。タスクBは35個の小タスクが完了，3個が仕掛かり中，2個が未着手。「タスクC」は10個完了で50個未着手。「タスクD」は全く未着手とする。
この場合，
（5人日×15）+（5人日×35）+（5人日×10）=300人日分
を実績実績として報告する。すなわち，完了分のタスクのみを計上し，仕掛かり中のタスクは数えない。
グラフで遅れを把握する
進ちょく状況の分析には，計画／実績対比グラフを利用する。図3にその例を示した。図に示すように，進ちょく計画と，作業担当者や作業チームから収集した実績データを同一グラフ上に表現する。グラフの横軸は期間（月や週），縦軸はタスク量（人日や人月）の累計を表す。
 |
| 図3●計画／実績対比グラフの例 |
このグラフの現時点における計画値と実績値の縦方向の差から「遅れの仕事量の大きさ」が分かり，現時点の計画値と実績から導いた予測値との横方向の差から「遅れの期間」が分かる。
進ちょくの予測線が作成できない場合は，「現在完了している仕事が本来いつまでに終わらなければならなかった」と現時点との差を，「遅れの期間」の代替案とする。現実には，ほとんどのプロジェクトでこの代替案を使っている。
こうしたグラフにより，プロジェクト・マネジャーは作業の状況を一目瞭然に把握できる。この分析結果から，現状の問題点の有無を判定し，プロジェクトの進ちょくに関するリスクを評価する。
プロジェクトの進ちょく状況を分子と分母が不明確な「進ちょく率（％）」で表現することもあるが，これは避けるべきだ。進ちょく率は極めて主観的なものであり，あてにならないからである。
ただし，プロジェクトの組織構造が2階層，3階層を超すような大規模プロジェクトの場合は，集計結果を分析するだけでは進ちょくを完全に把握しているとは言えない。2階層以上のプロジェクトの作業実績報告には，願望やあいまいな見込み，あるいは（悪意のない）誤りが入り込むことが多いからだ。
そこで，プロジェクト・マネジャー自身が作業担当者レベルの作業状況を直接把握して，その実態を検証しておくことが不可欠となる。そのためには，いわゆる「飲ミュニケーション」も必要になる。
