遅延よさらば。バッファ活用によるプロジェクトマネジメント
プロジェクトっていうのは、進捗に遅れが出始めると、挽回するのがとても難しいと感じます。数多くのソフトウェア開発プロジェクトに関わってきましたが、遅延プロジェクトがオンスケに戻ったケースは記憶に多くありません。むしろ、時間が経つにつれ、じわりじわりと遅延が拡大していくケースが多いように思います。遅延が明らかになった時には既に、それを取り戻す術はほとんど無いのかもしれません。
ステークホルダーとの遅延影響の調整は、誰だって精神的に参ります。不満を表情に滲ませて詰め寄ってくる人だっている。何より、リリースを楽しみに待っていたユーザーに申し訳ない。そんな思いを繰り返したくはありません。
だからこそ、遅延が明らかになってから右往左往するよりも、遅延を予防すること、予兆を早期に検知すること、そして備えることがとても大切です。
約束された遅延
プロジェクトの初期段階は、不確実性がとても大きいものです。曖昧で、分からないこと、気付いていないことも多い状態。プロジェクトが進むにつれてそれらが明らかになっていき、不確実性が小さくなっていきます。
最初期段階の予測に基づいたプロジェクト終了時期に対し、実際の結果は、4倍から1/4倍の範囲でずれると言います。また、平均的なプロジェクトは予定スケジュールの2倍以上かかるとも聞きます。初期の予測だけに頼って突き進むプロジェクトの行く先は「約束された遅延」だと言えそうです。
プロジェクト初期の予測があてにならないなら、プロジェクトを進める中で繰り返し予測を見直し、計画の精度を高めていく必要があります。
その反復的なプロセスの中に組み込まれた「バッファ」は、プロジェクトの遅延を制御可能にします。
"フィーチャバッファ" でリスクマネジメント
「フィーチャバッファ」は、あらかじめ合意されたスコープの幅です。遅延してからステークホルダーと開発チームでスコープ調整するのではなく、事前に両者で合意しておくという点が肝です。
プロジェクトで実現しようとする数多くのフィーチャには、絶対に必要なものと、それほどでもないものが含まれているもの。そこに目を付け、プロジェクト開始時に、必須のフィーチャと、必須ではないオプションのフィーチャを仕分けし、それらに優先順位を付けておきます。
オプションのフィーチャセットのサイズは、必須のフィーチャセットの見積り合計の25%から40%程度とします。
プロジェクト計画では、これらすべてを実現するつもりでスケジュールを作成します。フィーチャを完成させる順序は必須フィーチャが先。もちろん、その中でも優先順位の高いものから順に完成させる。その後にオプションのフィーチャが続きます。
こうしておけば、プロジェクト終了日までに、必須で優先度の高いフィーチャは確実に完成させることができます。オプションのフィーチャも、時間に余裕がある範囲で完成させられます。
このようにフィーチャバッファは、不確実な未来に備え、リスクを回避する効果があります。
"バーンダウンチャート" と組み合わせて未来予測
アジャイル開発を採用する開発チームであっても、バーンダウンチャートはあまり利用されていないように感じます。これはもったいない。バーンダウンチャートを活用することこそアジャイル開発の真髄ではないか、と考えているからです。
プロジェクトを進める中での反復的な計画づくりには、バーンダウンチャートが欠かせません。計画とは未来予測であり、その予測は定期的に更新されるチャートが示す実績データに基づくからです。
フィーチャバッファを使ったプロジェクトでバーンダウンチャートを活用すれば、終了日までに完成できるフィーチャの範囲を予測できるようになります。以下で、その流れを追いかけてみます。
バーンダウンチャートは、縦軸に残作業量、横軸に時間の経過をとります。作業量は、ストーリーポイントの合計でも工数の合計でも構いません。時間の経過は、1週間や2週間といったイテレーション単位です。
開発チームが1回のイテレーションで開発できる作業量が50ポイントであり、プロジェクト開始時の総作業量が400ポイントなら、8回のイテレーションが必要であることがわかります。
次は、3回めのイテレーションを終えた時点のチャートです。
開発チームの作業量がイテレーションあたり平均40ほどしか出ておらず、残作業量が280あります。残り5回のイテレーションで消化できるポイントは200だと予想できるため、80ポイント分のフィーチャが実現不可能であると分かります。
次は、4回めのイテレーションを終えた時点のチャートです。
残作業量が260であり、前回から20しか減っていません。開発チームは40ポイントを消化したのですが、新たに20ポイントの作業が追加されたからです。残り4回のイテレーションで消化できるポイントは160であるため、プロジェクト終了時点で100ポイント分のフィーチャが残ることが予想されます。
このように、イテレーションが終了するたびにバーンダウンチャートを分析すれば、プロジェクト終了時点での残作業量が予測でき、どれだけのフィーチャが実現できていないかを前もって知ることができます。
この情報を、ステークホルダーと開発チームの間で常に共有し、プロジェクトの透明性を高めることで、状況認識の齟齬によるトラブルを防げます。プロジェクトの成果を早期に予測できるため、両者での調整難易度は従来より随分と下がるのではないでしょうか。
開発チームの責任感と、人の性（さが）
開発チームが見積りに含める「時間的なバッファ」を嫌うステークホルダーを見かけることがあります。そういったバッファを「開発チームが自分たちを守るために紛れ込ませた予備的な時間」だと捉えるからのようですが、これは間違いです。見積りは予測に過ぎないので、実際にやってみなければ、本当に正しい開発規模なんてものは分かりません。
3点見積り法の楽観値や悲観値の存在からも分かるように、各タスクの見積りに含まれるバッファとは、実際の開発規模が見積り通りになる確率をどの程度に設定するかによって生じる見積り結果の差です。
50%の確率で正しそうな見積りではリスクが高すぎます。そんな計画に開発チームがコミットできるはずがありません。遅延して迷惑をかけることが分かりきっているからです。もちろん、100%正確な見積りは不可能です。
だから、90%程度の確率で正しいと感じられる見積りを作成します。言わばバッファは開発チームのプロジェクトに対する責任感や誠実さの表れです。
とは言え、実際の開発規模が見積りより十分に小さくても、予定より早くタスクが完了することは滅多にありません。時間いっぱいを使って「良い仕事」をしようとするのが人の性（さが）というものです。そうであれば、プロジェクトが遅延しやすいことも頷けます。
"プロジェクトバッファ" で遅延防止（タイプ1）
「プロジェクトバッファ」を使ったプロジェクトマネジメント手法は、このような問題を解決するためのものです。
プロジェクトで実現しようとしているフィーチャ個々に対して見積りバッファを含めることをやめ、リスクの高い50%見積りでスケジュールを作成します。それぞれのフィーチャ開発が予定通りに完了するかどうかは五分五分になってしまいますが、これで、「人の性」によるバッファの消費は抑制できます。
もちろん、バッファの消費が抑制されたところで、このままでは確実にプロジェクトが遅延してまうので、スケジュールの最後尾にバッファとなるイテレーションを追加します。五分五分の遅延による影響を、このバッファで吸収するわけです。
バッファの大きさの決め方はいくつかあります。最もシンプルなものは、50%見積りによるプロジェクト期間に対し、その半分の長さをバッファとして追加するというものです。
50%見積りで4回のイテレーションを要するプロジェクトなら、上図のように、2回のイテレーションをスケジュールバッファとし、合計6回のイテレーションをプロジェクト期間とします。
スケジュールバッファの素晴らしい点は、フィーチャバッファと同様に、プロジェクトの遅延を早期に検知し、対策を打てることにあります。イテレーション終了の度にバーンダウンチャートを更新していけば、計画していたイテレーション数に収まるかどうかを常にチェックすることが可能になります。
上のチャートでは、ブルーの破線に囲まれた範囲がバッファです。予測線であるグレーの破線が右側のブルーの破線を超えないよう、注意しながらイテレーションをまわしていくことになります。
"プロジェクトバッファ" で遅延防止（タイプ2）
先述したプロジェクトバッファには、ひとつ問題があります。プロジェクト全体で見れば、予定していたフィーチャを全て完成させることができるのですが、イテレーション単位で見れば、それぞれで予定していたフィーチャをその都度全て完成させることが、ほぼ不可能になってしまいます。実際のプロジェクトでそれは許されるのでしょうか。
近年のソフトウェアデリバリは益々リードタイムが短くなり、リリース頻度も高まる一方です。そこで求められるのは、イテレーションごとに、予定していた成果物すべてを完成させ、リリースすることです。これではプロジェクトバッファを採用することができません。
そこで登場するのが、イテレーション単位のプロジェクトバッファです。1回のイテレーションに含まれるフィーチャの実現に必要な全てのタスクを50%見積りし、スケジュールの最後尾にプロジェクトバッファを追加します。3週間のイテレーションであれば、最後の1週間がプロジェクトバッファとなります。
"バッファ傾向グラフ" と組み合わせて未来予測
イテレーションに組み込んだプロジェクトバッファは、消費状況をバーンダウンチャートで可視化できません。バッファ傾向グラフがその代替手段となります。
バッファ傾向グラフでは、横軸に進捗率、縦軸にバッファの消費率をとります。
プロジェクトが順調であれば上図のように、進捗が進むにつれ、徐々にバッファを消費していきます。完了時にはほとんど残りません。もし、進捗率に対しバッファ消費率が高すぎるようなら、イテレーション期間内に全てのタスクが終わらないサインです。
グラフの背景色は、その危険度によって色分けされています。グリーンゾーンは安全。イエローゾーンは危険度が高まっているという警告であり、何らかの対策を準備する。レッドゾーンに達したらその対策を実施して、バッファ消費率を回復させます。
バッファ消費での攻防が醸成するチームの一体感
興味深いことに、プロジェクトバッファの導入は、チームに一体感をもたらすようです。
50%見積りによるプロジェクトの遂行は、エンジニアにとっては非常に疲れます。自身のタスクの遅れが想定以上のバッファ消費につながって、チームに迷惑をかけるようなことはしたくない、という緊張感によるものでしょう。
一方で、バッファ消費率が想定以上に上がり始めると、チームが一丸となってそれを抑え込みにかかります。そういうチームプレーが見られるようになるのです。
それだけに、バッファ消費率を100%以内に抑えてプロジェクトを終えることができた時には、チームとして大きな達成感を得られます。これぞ、チーム。単なる個人の集まり以上の存在です。
予防・早期検知・備え
プロジェクトバッファの考案者は、ビジネス必読書『ザ・ゴール』の著者エリヤフ・ゴールドラット博士です。
同書で知られるTOCに基づいて考案されたクリティカルチェーン・プロジェクトマネジメント（CCPM）の要素として、プロジェクトバッファが登場します。
CCPMには他にも、合流バッファやリソースバッファが存在します。それらもあわせて活用しても良いでしょう。
いずれのバッファにも共通して言えることは、チャートと組み合わせ、未来の遅延を早期に検知する仕組みの中で利用されることです。プロジェクトが遅延するであろうことを事前に知ることができれば、打ち手もそれだけ多くなります。
フィーチャバッファはまさに、初期の計画通りに進まない時に備え、期間内に必須フィーチャの開発を必ず完了させようとするものです。2つのプロジェクトバッファは、人の性による遅延を予防し、さらにリードタイムを短縮しようとする試みにもなっています。
遅延が明らかになってから右往左往するよりも、遅延を予防すること、予兆を早期に検知すること、そして備えることが大切だということです。
この記事が気に入ったらサポートをしてみませんか？