開発プロジェクトは、何もしなければどんどん混乱していく。計画は破綻し、成果物は四散し、開発要員の心理はズタズタになる。混乱を収拾するのは容易ではない。開発プロジェクトの立ち上げ段階から秩序を導入し、整理整頓されたその状況をカットオーバーまで維持すること。もちろん、それは口でいうほど簡単なことではないのだが、まったく無理なことでもない。本連載では、プロジェクトに秩序をもたらすさまざまな手法を、開発プロジェクトの段階を追って解説していく。そして、手法の説明だけではなく、具体的なツールを使って「どうすれば効率的な管理が可能なのか」という現実的な提案も行うつもりである。ここで使用するツールはすべてオープンソースのプロダクトである。効果的な方法をただ同然で導入し、開発プロジェクトを成功に導こう。本連載の目的はそこにある。
プロジェクトマネージャ(=PM)の石出さんは今日も悩んでいます。
石出さん談――。
「部長には順調ですと報告しているものの、90%終わっていますと報告を受けてから2週間も状況が変わらない。決して、チームのみんながサボっているわけではないのは自分がよく知っている。むしろよく頑張ってくれていると思う。ただ、(作業が)いつ終わるか聞くと3日後と答えが返ってくる。3日後に聞いてもやはり3日後だという。状況を聞けば確かにやむを得ないと思うのだが、いつ終わるか分からず計画からの乖離も大きくなると、何が終わって何が終わっていないかも分からなくなってくる……」。
なるほど、石出さんはプロジェクトの管理について、かなり深刻に悩んでいるようです。この悩みを解決するにはどうすればいいのでしょうか。まずは、なぜ進ちょくを管理するのかという点から考えていきましょう。
進ちょくを管理する目的はプロジェクトを計画通りに進めることです。
プロジェクトを計画通りに進めることは、地図(行く場所とその行き方)を作って出掛けることに例えることができます。地図を見ながら、現在位置を確認し目的地の方向へ進んでいくというわけです。通行止めや混雑があれば、道を変更しながら目的地に近づいていくのが普通です。このことをプロジェクトの進め方に置き換えると、計画を見ながら、進ちょく率を確認し、プロジェクトの終了へ向けて進んでいくというように考えられます。多くの場合、途中でリスクが顕在化しますが、その場合は作業内容を変更しながらプロジェクトの終了に向けて少しずつ作業を進めていくわけですね。
つまり、プロジェクトを進めていくうえで、進ちょく管理というのは非常に重要なのです。実際の進ちょく管理では、以下の2つのことを把握する必要があります。
プロジェクトが全体のどの程度の位置にいるのか?(進ちょく率)
このまま進んで納期に間に合うのか、間に合わないのだとするとどの程度遅れているのか(完了予測)
進ちょく管理を行うためには、計画を作成し(地図を作って)、進ちょく率を確認し(現在位置の確認)、完了予測を行い、補正をする(方向や道を確認する)のが重要なことは上で説明しました。では、このためにどのようなことをすればよいのでしょうか。簡単にいってしまえば、次のようなサイクルを作成することです。
開発計画をスムーズに進めるためには、こういう感じの作業サイクルを作成することが大事なのですが、進ちょく報告(情報収集)を受けなくては何も管理できません。
また、サイクルを作成しても、作業結果報告が精度の低いものだと無意味です。精度を上げるには、作業結果を計画と比較する明確な基準が必要です。もちろん、メンバーの成熟度が高く、各自の作業見積もりおよび作業状況の把握が正しく行われる場合は進ちょく基準を明確にする必要はないかもしれませんが、PM石出さんが抱えている悩みを解決するためには、まず、進ちょく基準を明確にする必要がありそうです。
この「サイクル」と「進ちょく基準」が、進ちょく管理の2つの原則です。これらについてもう少し詳しく見てみましょう。
例えば、以下のようなプロジェクトの進め方を想像してください。
月曜日の朝に、今週の予定を確認します。先週の作業結果によっては遅延を解決するための変更もここで報告し、共有されます。その予定に従い、毎日作業をします。金曜日の17時に今週の作業結果をメールでメーリングリストに報告します。PMはこの報告を基に進ちょく状況をまとめ、対応を検討し月曜日の朝会に備えます。大きな進ちょくの遅延についてはその日のうちに部長に報告され指示を仰ぎます。月末にはこれまでの進ちょくをまとめ顧客に報告することになっています。
このようなプロジェクトの進め方はよくあるのではないでしょうか。ここでも計画・報告・分析・対応のサイクルを作っています。
このサイクルにおいて、進ちょく率は、
Σ(作業の進ちょく率×作業の予定工数)/計画した総工数
というように計算します。総工数を計算する必要があり、WBS(Work Breakdown Structure)を作成しスケジュールを明確にする必要があります。一方で、完了予測は以下のような計算をします。
これでプロジェクトが必要としている日数が分かるので、
この値が「−(マイナス)」であれば予定よりも早く終了し、「+(プラス)」であれば予定よりも遅く終了する予定です。
分かりにくいので簡単な例で説明します。まず以下の図を見てください。
進ちょく率は、全体に対する実績の割合(実績工数÷全体の予定工数)です。そのため、まずすべての実績を求めます。上図では、タスク1の実績は10、タスク2 は予定工数10に対して達成度が50%のため、タスク2の実績は10×0.5=5となります。
同様にしてタスク4の実績は30×0.05=1.5です。これらの実績値を加算し、全体の実績は16.5となるため、進ちょく率は16.5÷60=0.275になります。
完了予測は、現時点のペースで進ちょくした場合に、何日でプロジェクトを終了できるかを予測(予定日数÷現在時点のペースとして計算)しています。現時点のペースとして、現時点での終了予定工数に対する実績工数の割合 (実績工数÷現時点の終了予定工数)を利用しています。現時点の予定終了工数は、タスク1は終了していないといけないので10人日、タスク2は2日間実施されていることになるので、終了予定工数は2人日となります。同様にしてタスク4の終了予定工数は、2人日です。これらを加算すると14人日です。
一方で終了している工数は16.5人日であるため予定よりも早く進んでいることになります。このプロジェクトが終了するには14÷16.5×40=33.93日必要となります。
上の図は全部で40日間、工数60人日のプロジェクトです。このプロジェクトで12日目の進ちょくを確認しています。これを計算すると進ちょく率27%、完了予測は約−6日です。この完了予測はプロジェクト全体から見ると正しく、順調に推移しているといえます。
一方、タスク4はいわゆるクリティカルパスに当たりタスクの進ちょくがプロジェクトの進ちょくに影響します。まだタスク開始後2日目のデータなので分かりませんが、現在2日進行して進ちょくは1.5日分しか進んでいません。そのためその進ちょくトレンドから予測するとタスク4は40日掛かることになります。予定では30日ですから10日遅れることになります。このように考えるとこのプロジェクトは遅延の傾向が出ているといえます。
全体の予測とクリティカルパスにあるタスクの予測をいずれも行ってバランスの良い完了予測を立てる必要があります。また、完了予測は複雑で前提条件によっていろいろな考え方があります。この式は単純な予測をするために、アサインメンバーの生産性は一定、スケジュールは各タスクの標準時間を用いているという前提を利用しています。
つまり、標準時間と現実の作業の比を計算して生産性を測っています。
このような進ちょく管理も進ちょく報告の精度によって信頼性が変わってきます。繰り返しになりますが、上記のサイクルの説明で行っている「報告による進ちょく報告」の場合はメンバーの成熟度が高くないと進ちょく状況を正確に把握できず、遅れに対しての対応が後手に回ってプロジェクトそのものが「デスマーチ」化してしまう可能性を秘めています。そのためにも明確な進ちょく基準が重要です。それでは進ちょくの基準とは何でしょうか。
報告ベースの進ちょく基準で開発作業全体の状況を把握するのはとても難しいと思います。報告者全員の成熟度が高い場合はうまくいくと考えられますが、一般的にはこの方法では冒頭のPMの悩みで説明したような状態になってしまいます。
別の方法としては、成果物のステータスを進ちょくとする方法があります。例えば、何らかの成果物が完成したら50%、内部レビューが済んだら70%という形で成果物のステータスを進ちょくの基準にします。ほかにも完了した場合のみ100%としてそれ以外の場合を0%とする「0−100法」や、着手したら20%として完了したら100%とする「20−100法」などがあります。また、残作業時間を見積もり、
とする進ちょく基準もあります。
Copyright © ITmedia, Inc. All Rights Reserved.