私は現在、約10MM規模のソフトウェア開発のプロジェクトリーダーをやっています。ここ1年間で、3回の開発プロジェクトを経験しましたが、特に初めのうちは「なぜ、プロジェクトは予定どおりに進まないのか？1」と絶句する日々でした。
しかし、経験を積んでいくうちに、最低限これをやっておけば大きな進捗トラブルは防げるというポイントが分かってきたので、ここではその話をします。
1. バッファを考慮した見積をする
この図は、エリヤフ・ゴールドラット『クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?』という本の最初の方に出てくる確率分布図です。
横軸はプロジェクト開始からの経過日数、縦軸はその日までにプロジェクトが完了している確率です。
例えば、3人でバッファなし9MMのプロジェクトを進める場合、ちょうど3ヶ月が経過したあたりで確率が最も高くなります。つまり、「3ヶ月」がグラフでいうところの、一番山が盛り上がっている箇所になります。
しかし、確率の分布に着目すると、実際に3ヶ月でプロジェクトが完了する可能性は50%にも満たない（中央値よりも左側である） ことが分かります。これは、プロジェクトが1日で終わる可能性はゼロですが、4か月、半年、1年かけても終わらない可能性はゼロにならないので、中央値が山の頂点よりも右側に引っ張られるためです。
もし、あなたがプロジェクトの工数見積を初めて任された場合、この確率分布を念頭に置いてください。プロジェクトには不確実性がつきもの です。設計時に考慮できていなかった技術的課題が後工程で見つかるかもしれないし、何日待ってもクライアントからの回答が得られないかもしれないし、チームのメンバーが一週間病気で寝込んでしまうかもしれません。プロジェクトを安心して進めたいのであれば、期限までに終わる確率が80%~90%あたりになるように、セーフティー（バッファ）を考慮した見積を作成すべき です。
では、具体的に何MMのバッファを積めばいいでしょうか。考え方は色々あるかと思いますが、私の場合は開発規模やチーム構成が近しいプロジェクトの実績をもとに、バッファを設定するようにしています。具体的には、バッファなしの工数 (MM) / 前回の生産性 (一人当たりのMM/月) で、バッファありの工数を導出します。例えば、前回のプロジェクトが10 (MM)の規模で、生産性が0.8 (一人当たりのMM/月)の場合、10 / 0.8 = 12.5 (MM)がバッファ込みの工数です。
※ちなみに、このときに用いる生産性は、基準日までのEV (MD) / 基準日までにチームが使った工数 (MD) の中央値で算出しています。2
2. バッファは個々のタスクにではなく、プロジェクト全体に積む
バッファを考慮した見積が無事にOKをもらえたら、スケジュールを立てます。ここでポイントになるのは、バッファは個々のタスクにではなく、プロジェクト全体に積む ということです。
どういうことでしょうか。先ほどの例では、12.5 (MM) - 10 (MM) = 2.5 (MM)が、あなたのチームが手にしたバッファでした。この2.5MMをWBSの各行にまぶして、チームメンバーの個々のタスクに少しずつゆとりを与えるとします。すると、何が起きるかというと、このプロジェクトはバッファを設けなかった時とさほど変わらず、期限までに完了できません。
その大きな理由の一つに、学生症候群というものがあります。これは、期限ぎりぎりになるまでタスクに取り掛からないという、人間の傾向を言い表した言葉です。同じ予定工数のタスクに対して、12/23が締切であれば12/21に着手するし、12/25が締切あれば12/23に着手するので、バッファ込みで12/25を期限としてもあまり意味がないということです。
また、同じような傾向で、期限が来るまでタスクを完了にしないということもよく起きます。チームメンバーが仕事熱心だからこそ、品質を高めようと締切のギリギリまで設計書の体裁を整えたり、細部にわたってテストケースを量産したりすることもあるかと思います。確かに、品質は多少上がるかもしれませんが、プロジェクト全体で見ると、バッファが食いつぶされることでより重要な課題に対応できなくなるリスクの方が大きくなります。
それでは、プロジェクトのバッファはどのように管理しておくのがよいでしょうか。答えは、バッファなしの工数でスケジュールを立て、バッファはプロジェクト全体のためにプロジェクトリーダーが別で管理しておくということです。
具体的には、バッファなしの工数 10 (MM) でスケジュールを引きます。つまり、顧客に伝えているほんとうの締切（12.5MMの場合の締切）よりも、早く終わる想定のスケジュールを引くことになります。
そのスケジュールで日々の進捗を管理していると、おそらくどこかで何かが起きて遅延が発生します。その遅延が容易には挽回できないと見込まれた場合、プロジェクトリーダーが取っておいた2.5 (MM)のバッファを切り崩し、リスケジュールを実施します。
このやり方をとることで、バッファを個々のタスクで食いつぶされることなく、プロジェクトのリスクが集中する部分（主にクリティカルパス）にあてることができます。
3. EVM管理をする
プロジェクトが開始したら、日々EVM管理を行いましょう。私のいるプロジェクトでは、このような進捗管理ツールを利用してEVM管理を行っています。
まず、スケジュールの作成者が、各行にタスク名、予定工数 (MD)を入力し、稼働予定日を画面右側のカレンダーにプロットしておくことで、自動的に各タスクの予定開始日、終了日が入力されます。
あとは各タスクの担当者が、日々の実績（開始日、終了日、進捗率）を入力することで、その日までのタスクの予定工数 (PV) と 実績工数 (EV) が出力されるようになっています。
このような管理を行うことで、遅延の発生を日次で検知できることはもちろん、どのタスクで何MDの遅延が発生しているか (PV - EV) を定量的に把握することができます。
また、EV / PV で生産性 (SPI) を得ることができますが、これを日々記録しておくことで、プロジェクトの遅延が改善傾向にあるとか、悪化傾向にあるということを把握することができます。
個人的に、EVM管理をする上で重要だと感じているポイントは、
- 1日当たりのEVや生産性を記録しておき、減少傾向が出てきたら、どのタスクが原因で生産性が落ちているかを把握する
- 生産性が落ちているタスクを特定できたら、その原因と対策をチームで話し合って決める
というサイクルを日次ベースで回し続けることです。
前者について、たんにプロジェクト全体のPVとEVを日々眺めているだけでは、遅延の傾向をつかむことができず、対策をとるのが出遅れてしまうことがあります。
そのため、日々のPVとEVは別途どこかに記録しておいて、生産性の上昇・下降傾向が分かるようにしておくとよいです。例えば、下表のようにSPIに条件付き書式で色を付けておくと、黄色信号、赤信号ということが視覚的に分かりやすくなります。
後者について、遅延が発生したときの対策はどのようなものがあるでしょうか。
軽度～中度の遅延の場合は、
- 作業の段取りを明確にする、担当者を入れ替えるなどの対策を立てて挽回する
- 先行タスクの待ちが発生する場合は、作業の順序を入れ替えて、別のタスクでEVを出せるようにする
- 残業することでEVを多めに出す
- バッファを切り崩して、リスケジュールする
などの対応でカバーすることが多いです。
ここでポイントなのは、リスケの回数はできるだけ少なく抑えることと、リスケした際は切り崩したバッファの量を把握しておくことです。
リスケをなるべくしたくない理由は、頻繁にリスケが発生すると、そのたびに当てたバッファが学生症候群によって食いつぶされてしまう可能性があるからです。しかし、あまりにもPVとEVの乖離が大きくなってしまうと、徐々にスケジュールが効力をもたなくなってしまうので、そうならないうちにリスケする必要があります。
また、リスケを繰り返すうちに、知らず知らずのうちにバッファがなくなってしまっていたという事態は避けるべきです。したがって、リスケ時にはきちんとバッファの記録を行いましょう。私は下図のようなやり方で、管理しています。
上記のような対応を日々繰り返していても、プロジェクトには不確実性がつきものなので、より重度の遅延――バッファがゼロになり、これ以上遅れるとプロジェクトの期限が守れなくなるような遅延――が発生してしまうこともあります。
そのような状況下では、むやみやたらに残業するというだけではなく、冷静に次のような対策を検討することが重要です。
- 顧客と相談して、プロジェクトの終了予定日を後ろ倒しにできないか相談する
- 追加要員をアサインしてもらえないか（上司や、マネージャーに）相談する
4. プロジェクトの完了予想日を可視化する
とはいえ、経験の浅いプロジェクトリーダーにとって、遅延に冷静に対応するというのはなかなか難しいことです。私自身も、初めのうちは「自分が頑張れば何とかなる」という精神論で、がむしゃらに乗り切ろうとしては失敗した経験があります。
状況を冷静かつ迅速に把握するために、以下のようなグラフを作成して、遅延を可視化するというのは一つの方法です。
グラフの見方ですが、青線がPVの推移、赤線が基準日までのEVの推移、黄色線がこれまでの生産性をもとにした未来のEVの推移予想、緑の点線がプロジェクト完了ラインです。
例えば、このグラフで青線と緑の点線が交わるのは9/6(金)なのですが、これはこのプロジェクトの完了予定日が9/6(金)であることを表しています。これに対して、黄色線が緑の点線と交わるのは、9/12(木)となっています。つまり、このままの生産性で進むと、このプロジェクトは4営業日分、期日から遅れてしまう ということが分かります。
このようなグラフでプロジェクトの着地予想を可視化しておくことには、次のようなメリットがあります。
- 顧客や上司に相談する際に、このままいくとどのくらい遅れるかを定量的に報告できる
- プロジェクトがいつ終わるのか分からないという不安から、脱却することができる
- チーム内で生産性を向上させる施策を話し合うための、スタート地点になる
特に、マネジメント経験の浅い人がリーダーを担当する場合、報連相の遅れがプロジェクト上の重大なリスクを招く恐れがあります。しかし、このようなグラフをチーム内で日々確認しておくことで、重大な遅延が放置されてしまうことを防ぐことができます。
具体的なグラフの作成方法ですが、まず、以下のような表にプロジェクトの完了日までの日毎のPVと、日々の要員計画 (MD/日) を記入しておきます。
次に、日付が進むごとにEV (actual)と、生産性 (1人あたりのMD/日)3 を更新していきます。そして、EV (expected)ですが、これは 当日の要員(MD/日) * 生産性(1人あたりのMD/日) + 前営業日までのEV を未来の全営業日に適用して算出します。
こうしてできた表をインプットに、ExcelやGoole Spreadsheetのグラフ機能を活用することで、上述したようなグラフを簡単に作成できます。
5. リスク要因を後回しにしない
ここまでで、
- リスクを加味した見積、スケジュールを立てることの重要性
- プロジェクトを遅延させるようなリスクが発生した場合に、どのように対処すべきか
- プロジェクトの遅延をいち早く検知するには、どうしたらいいか
という話をしてきました。
最後に、どうしたらプロジェクトを遅延させるようなリスクを減らせるかという話をします。どうしてもここは経験に大きく依存する部分なので、これまでに書いてきたような具体的な方法論があるわけではありません。
ただ、私の経験上、次のような施策はリスク回避に有効だと考えています。
- リスク要因を後回しにしない
- プロジェクトが終わるたびにチームで反省会を実施する
まず、「リスク要因を後回しにしない」ですが、自分がそのような心掛けで作業にあたるのはもちろんのこと、チームメンバーにリスクとなり得る箇所を日々共有し、それをチーム全体で放置しないような雰囲気作りが重要だと感じます。
基本的に作業者は、周りから何も指定がなければ、自分にとってやりやすい作業から着手するものです。しかし、そのような状況を許容していると、プロジェクトの後半で一気に生産性が低下し、途端に遅延が拡大します。これまでに放置してきたリスクが、終わりが見え始めてきたころになってようやく明るみに出るということです。
そのような事態を回避するためには、「リスク要因を後回しにしない」ことが重要です。どこがプロジェクトのリスクになり得るかは経験のある人にしか分からないので、なるべく経験豊富なリーダーや開発メンバーが、そうではないメンバーに日頃から積極的に声掛けしてあげることが大事だと思います。
次に、「プロジェクトが終わるたびにチームで反省会を実施する」です。今回のプロジェクトのどこで遅延が発生したのか、その原因は何だったかを振り返ることで、次回以降のプロジェクトでどこがリスクになり得るかの予想を立てやすくなります。ちなみに、私たちのチームでは、プロジェクトが終わるたびに、KPT表というフォーマットを利用して反省会を行っています。
参考：https://hrnote.jp/contents/kpt-20201023/
おわり
以上、私がこの一年間で得てきた進捗管理まわりの知見でした。参考になりましたら幸いです。
-
エリヤフ・ゴールドラット『クリティカルチェーン―なぜ、プロジェクトは予定どおりに進まないのか?』https://amzn.asia/d/bQ4hztN
ちょうど絶句しているときに上司に勧めてもらって読んだ本。プロジェクトリーダーが何に注視すべきかが、小説調で分かりやすく書かれています。 ↩ -
ここでの生産性にSPI (EV / PV)の中央値や平均値を使わない理由は、途中でリスケジュールが発生していた場合、SPIは1に戻ってしまうため、チームのパフォーマンスを正確に表さないからです。 ↩
-
このときに用いる生産性は、基準日までのEV (MD) / 基準日までにチームが使った工数 (MD) で算出しています。 ↩