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