進捗管理とは
進捗管理とは、スケジュール計画に対する進捗状況を適時トラッキングし、遅れの発生やタスクの追加などの課題に対して適切な対処を行うことです。プロジェクト管理は「計画」と「実績」を対比することが重要です。進捗管理では、「実績の把握」、「計画との対比」、「対処法の検討」、「進捗の報告」などを行います。
図1：進捗管理とは
進捗管理の目的
進捗管理の目的は、単に進捗状況を把握することではありません。ガントチャートなどで計画したスケジュール通りに作業が進んでいるかをトラッキングし、差異（遅れや進み）が出た場合に計画をリスケしたり、計画をキープするためにメンバーを追加するなどの対処を行います。また、把握した進捗状況はチーム内にとどめずにタイムリーに上長やユーザーに報告する義務もあります。
進捗管理で積上計算する手法
ガントチャートはWBS（Work Breakdown Structue）を線表で表したものなので、階層構造となります。それなのにこの階層構造を無視して、おおざっぱに進捗を報告しているケースが多くあります。
ガントチャートは下位タスクの進捗率の積み上げが、その上位タスクの進捗になります。つまり、下位タスクの進捗をきちんと管理しないまま、上位タスクの進捗を勘に頼って報告してはいけません。末端のタスクで計画工数と進捗率を入力することにより出来高（EV値）が計算できるので、上位タスクはその積み上げにより進捗率が決まるのです。
図2「A社向け勤怠システム構築プロジェクト」を例に考えてみましょう。
プロジェクト全体の見積工数が10人月だったとします。各工程の計画工数を[計画工数] 列のように立て、製造工程については 「製造」→「コーディング」→「勤怠入力」「勤務表」という具合にタスクを順番にブレークダウンします。末端タスク（ワークパッケージと言います）を小さくすると計画工数の見積や出来高（進捗率）の精度が高まります。「コーディング」の進捗率は、「勤怠入力」と「勤務表」という２つのワークパッケージの計画工数、出来高により算出できます。
「勤怠入力」をコーディングするタスクの作業工数を1.5人月、「勤務表」コーディングの作業工数を0.5人月とそれぞれ見積り、これを計画工数とします。
実際に作業を行った結果、「勤怠入力」の進捗率が100%、「勤務表」の進捗率が60%という状態だとしたら、出来高はそれぞれ、1.5人月（1.5人月×100%）、0.3人月（0.5人月×60%）になりますので「コーディング」全体の出来高は1.8人月になります。「コーディング」の計画工数は2.0人月ですので、出来高1.8人月という数値は90％の進捗に値します。
このようにWBSでブレークダウンされた各工程の出来高工数を積み上げることで、全体の出来高がわかり進捗率を求めることができます。図2の例では。プロジェクト全体の計画工数10人月に対して出来高6.5人月ですので、プロジェクト全体の進捗率（EV：Earned Value）が65%であることになります。
図2：「A社向け勤怠システム構築プロジェクト」進捗積み上げ計算の例
進捗管理で定量的に把握するコツ
Excel等を使ってスケジュール管理をしていると、なかなかこの積み上げ計算まではできていません。個々のタスクの進捗は把握できても、遅れているタスクと進んでいるタスクがあって稲妻線がジグザグになっている状態では、上位タスクがどのくらい遅れているのかわからなくなります。
人によっては、図の凸凹具合を何気なく眺めただけで、概ね問題ないと判断するかもしれません。しかし、計画工数の大きなタスクの遅れは、計画工数の小さなタスクの進みで相殺できません。このようなアバウトな進捗管理をしていると進捗遅れの問題が表面化した時点で手遅れになります。常に進捗の積み上げ計算を行い、プロジェクト全体や上位タスクの進捗を把握しておかなければならないのです。
私がこう書くのは、実は過去に全体の進捗をチャート図でしか管理せず、痛い目に合った経験があるからです。そういう管理方法に疑問を持たず、頭の中で計算しておおよそ10日の遅れなどと報告していたことがあります。実際の進捗はそれよりも大きかったのですが、それが判明したのは工程の最後の方であり、プロジェクトメンバーにも負担をかけてしまいました。
プロジェクトマネージャー（PM）は、まだ、プロジェクトの進捗を感覚でつかみやすいですが、プロジェクトメンバーは全体の進捗状況をきちんと把握できていません。数値の積み上げ計算をきちんと行うことにより、プロジェクト全体の進捗が即時にわかってメンバーで共有できます。これだけでもメンバーのストレスが１つ減らせるものだと感じています。
進捗管理で遅れ日数を計算
プロジェクトには、「納品日、リリース日」といった期限がついています。その期日に間に合わせるためには、現時点でどれだけ進んでいるか、どれだけ遅れているかを正確に把握する必要があります。それを数値で表す目安のひとつが「遅れ日数」です。
遅れ日数はどのように算出するのでしょうか。簡単な例で説明しましょう。あなたが2つのプロジェクトを掛け持ちし、毎日8時間のうち6時間を開発のAプロジェクトに、2時間を保守のBプロジェクトで進める計画を立てたとしましょう。 Bプロジェクトで4時間の遅れが発生した場合、この遅れを取り戻すためには、 1日あたりの計画工数2時間を分母に「遅れ日数 ＝ 4時間÷2時間 ＝ 2日」と考えます。
「4時間分の遅れ」と「遅れを取り戻すには２日かかる」というのは違います。実際にどのくらいプロジェクトにリソースをかけられるかを基準に遅れ日数を計算するのです。 これらの事象の両方を把握して、遅れをリカバリーする算段を考えるのです。人を投入して遅れている4時間分の作業をさせるのなら、1日で遅れは取り戻せます。一方、現状のリソースのまま作業するのであれば納期を2日延ばしてもらうことになります。
画面1：[Bプロジェクト]の遅れ日数
1日8時間の労働時間があったとしても、部門の仕事を実施したり、他のプロジェクトのサポートを行ったりして、プロジェクトに関わっている時間は8時間に満たないことが多いと思います。こうした事情を加味して担当者別の計画工数から遅れ日数を算出すると、実はかなり日数的にリカバリーが難しい状況になっていることがわかったりします。
遅れ日数は人別にチェックするのが大切です。一概には言えませんが、私は3日遅れたら注意しています。そして、5日遅れたら要注意とし、場合によっては具体的な対策を講じるようにしています。プロジェクト管理の中では、必ず遅れ日数を把握し適宜プロジェクトを補正していくことが大事だと感じます。
進捗管理で計画工数と実績工数を対比
家計費を計画対実績で対比するように、プロジェクトでも計画と実績を対比することで生産性を高めたり、見積精度をあげたりすることができます。逆に言えば、実績だけとらえているようでは、プロジェクト管理にならないのです。そのため、OBPMでは工数見積をもとにタスクごとの計画工数を立てる仕組みとなっています。
立てた計画工数に対する実績は、工数入力で入れた値です。OBPMでは、勤怠入力と工数入力が連携しており、一日何時間働いたかを勤怠入力で登録し、その内訳としてどのタスクに何時間かかわったかを工数入力で報告します。このタスク単位の工数入力の積算値がガントチャートの実績工数に連携します。
ガントチャートの各タスクは、このように計画工数と実績工数が対比されていますので、計画内に収まりそうか、オーバーしそうかを日々把握することができます。また、タスクが完了した時点で計画工数と実績工数を対比することにより、そのタスクの生産性を確認することができます。
画面2：日々の工数入力値をガントチャートの実績工数へ連携
なぜ、計画工数を登録しなければならないのでしょうか。1つは、タスクごとの目標時間（計画工数）があることで、その目標に向かって取り組むことができるからです。生産性を簡単に確認できるので、生産性アップの意識も強くなるとともに、次回の計画を立てる際にも役立てることができます。
もう1つは、進捗（EV値）を図る指標となるからです。計画工数が10時間のタスクが進捗30%、計画工数50時間のタスクが進捗50%であれば、この2つのタスクの上位タスクの進捗は下記の式により46.7%となります。 上位タスクの進捗＝（10時間×0.3 ＋ 50時間 × 0.5）÷（10時間 ＋ 50時間） 計画工数が設定されてなければ、このような進捗判断はできないのです。
計画工数に余裕を持たせる人とぎりぎり頑張って計画する人がいますね。その人の性格や状況にもよるので一概に評価できないのですが、私としては目標時間より少ない時間で達成する生産性の高い人だけでなく、いかに計画通りにできたかも評価したいと感じています。
進捗管理で生産性を計算
生産性＝計画工数/実績工数×100(%) …進捗100%完了したタスクに対して計算 OBPMでは、毎月、この生産性を人別に集計して、人別の生産性をグラフで表示することもできます。さらに、それを部門別に集計して部門別の生産性もグラフ表示しています。
よく、「メンバーごとの生産性を知りたい」とおっしゃる経営者がいます。働く側の立場だとそんなところまで数値管理されるのには抵抗感があるのですが、遊びで仕事をしているわけではないので数値で把握されるのであれば生産性を高めたい。そんなところからスキルアップになるとポジティブに考えてもいいかと思います。
90%シンドロームを防ぐ
「90%シンドローム」という言葉を聞いたことがあるかと思います。若手のプログラマーにコーディングを任せたら、進捗率の報告が90%くらいから進まず、来る日も来る日も90%だったなんてこと、経験したことないでしょうか。 今、頭の中で誰かを思い浮かべたでしょうか。その人はたぶん経験が浅い人、楽観的な人なのでしょうね。楽観的な人は好きですが、プロジェクトが遅れては困りますので、そんな楽天家でもきちんと報告してもらう仕組みを考えなければなりません。
例えば「プログラミング・単体テスト」を１つのタスクとして管理する場合、プログラミング終了時点でＡさんは「50%」にするのに対して、Bさんは「90%」にするかもしれません。人の主観でパーセントで報告させるとこのようなばらつきが生じます。このようなばらつきを防ぐには、パーセントではなくアクティビティ（活動内容）で報告させるのが効果的です。
OBPMでは、アクティビティごとに進捗率を決めることができます。例えば、画面3の例では、着手10%、担当者作成完了50%、レビュー完了90%という具合にアクティビティに応じた進捗率をマスタ化しています。担当者はアクティビティを選択して進捗報告するのです。このマスタであれば、自分が作成完了してもまだ50%となるので、90％まできてなかなか完了しないといった事態を防ぐことができます。このように基準をしっかり決めておくことにより進捗の精度をあげ、人によるばらつきも防ぐことができるのです。
画面3：コンテキストメニューより進捗率を選択する仕組み
タスク洗い出しと進捗報告のコツ
進捗が思うように進まない原因の１つに、個々のタスクの洗い出しが不十分ということがあります。WBSの計画段階にないタスクが次々と発生してしまい、予定通り進められてないのです。このミスはよくありますので、計画時にタスクを洗い出せているかチェックすることが重要です。特に新技術を採用する際は必要なタスクが見えにくく、プロジェクト終盤になって大きな問題になることがあります。
タスクの洗い出しはリスク管理の面でも重要です。計画プロセスにおいて、予め発生するリスクを洗い出すと、それに対処するためのタスクも洗い出すことができます。備えあれば憂いなし、リスクを洗い出して対策を講じておけば、大きな問題に発展することもありません。
私は入社２年目で1年目の面倒をみるように言われたことがあります。2ヵ月のタスクについて新人から報告を受けたまま上司に報告していたのですが、ある時、進捗率70%からピタッと進捗が止まり、1週間たっても2週間たっても70%という状態に陥りました。そもそもプログラミングの期間２ヵ月に対して、１タスクしか管理していなかったのが問題だったのです。今ならそういう理屈がわかりますが、当時は後輩とのコミュニケーションをどうとればいいか悩んだものです。
私のチームに進捗を的確に報告するメンバーがいます。聞いてみると、単体テスト100件に対し100件実施した時点で60%になると決め、実施した件数の割合で進捗を報告していました。過去の経験から自分で基準を作り工夫して作業をしていたのです。そのメンバーと仕事をしていると、タスクを洗い出すことの重要性や、進捗を正しく報告することでプロジェクトを良い状況をもたらすことを改めて実感します。
タスク関連線の使い方
「このタスクが終了しないと次のタスクが取り掛かれない」という関係を表すのがタスク関連線です。例えばコーディングと単体テストを分けてタスク化した場合、「勤怠入力機能のコーディングが終了しないと単体テストに取り掛かれない」という関係になります。これを線で表すと画面4のようになります。わかっているのであえて書かない場合もありますが、タスクを整理してスケジュールを組みたい場合するのは重要です。特に大規模プロジェクトにおいては関連線を引かないと全体のタスクを最適化しづらいので、タスク関連線でタスクの関係を明確にしましょう。 
画面4：タスク関連線の例
以前、上司に「スケジュールはケツから引け」と教わりました。納期やリリース日など一番重要なケツを決めて、それに間に合うようにスケジュールを立てなければなりません。 どこかで待ち合わせをする際にも、家を出る時間を逆算して考えたりしないでしょうか。9:00に待ち合わせ駅に着くためには8:00の電車に乗らなければならない。8:00の電車に間に合わせるためには、家を7:45に出る。そのためには7:30には着替えてといった感じです。
上司に言われた「ケツから引け」は実は最初ピンと来ませんでした。しかし、いろいろなプロジェクトをこなしていくうちに、プロジェクトではさまざまな予期せぬ事態に出くわすことを学びました。そして、それらを乗り越えてケツに間に合うようにするために、自分なりに各作業のリミットを持つようになりました。ただし、リミットを持ちすぎるといつもギリギリ対応になりかねませんのでご注意ください。
OBPMと進捗管理
OBPMは、進捗管理における計画と実績の対比を重要視しており、楽に正確な進捗を把握できるような機能を完備しています。上記であげた「進捗の積上げ計算によるEV値の把握」、「遅れ日数の算出」、「計画工数と実績工数の対比」、「人別部門別の生産性グラフ」、「90%シンドロームを避けるためのマスタ選択による進捗報告」、「タスクの洗い出し漏れを防ぐためのWBS標準化」、「タスク関連線やイナズマ線」などはすべて完備しています。常に定量的かつ正確な進捗管理ができますので、進捗遅延が発生した際に早めにアラートを出すことができます。
（株式会社システムインテグレータ 羽佐田奈津美）
