プロジェクト・マネジャーが知るべき97のこと/現実を考慮して計画する
どれだけ多くのソフトウェアプロジェクトが納期に遅れ、予算を超過し、低品質であるかは驚くばかりです。国際的な認証と成熟度評価を得ていると大々的にうたっているソフトウェア会社ですら、ソフトウェア開発をとりまく非常に不安定な環境をうまく管理するためには、幾多の試練を乗り越えなくてはなりません。
プロジェクトの開発進捗は絶えず変化します。当初のスケジュールよりも早く進むこともあれば、もちろん遅れることもあります。たいていの場合、プロジェクト・マネジャーはこの変動を、正確かつ精巧なプロジェクトタイムライン（タスク割り当てと締め切り期日をあらかじめ定めたもの）によってコントロールしようとします。しかし、ソフトウェアを作るという動的な性質に対処するために、途中で計画を何度も改訂することになります。
細部にわたって抜け目なく見積もったプロジェクト計画を策定して実行することは、プロジェクトを成功させるために重要なことなのですが、多くのプロジェクト・マネジャーは計画に「現実時間」を加味するのが有効であることに気づいています。
クリティカルチェーン法では、ソフトウェア開発ライフサイクルに特有の変動をうまく扱う手段として、「バッファ」という概念を使います。ソフトウェア開発ライフサイクルの各フェーズ（設計、実装、テストなど）に「バッファ時間」や「現実時間」を取り入れてみましょう。
バッファ時間を使うと、大幅なスケジュール調整をする必要なく、各フェーズに柔軟性をもたせることができます。バッファ時間を各フェーズにおける不確実性だと考えるのです。やり方は非常に簡単です。プロジェクトの各フェーズについて、まずは最善の計画に基づいた期間を検討します。それから、フェーズの最後に一定の割合、例えばフェーズ期間の10% のバッファを追加するのです。
例えば40 日の設計フェーズの場合、最後に4 日のバッファ時間を追加して、全体で44 日のフェーズにするのです。実際のところ、このフェーズには44 日かかるのでしょうか？
おそらくはかからないでしょう。「未使用」時間は繰り越してもよいですし、後方にあるバッファに追加しても構いません。
経験豊かなプロジェクト・マネジャーならみんな知っているように、プロジェクトの初期は予定通りに進むかもしれませんが、後半になると結局は遅れていくものです。進捗のカーブよりも先手を打っておく方が、ほとんどの場合得策です。
初めてこのアプローチを試すときには懐疑的な態度をとりましょう。「非生産的」な時間というのは、マネジャーがスケジュールをレビューするときに最初に取り除きたくなるものです。地に足をつけてください。基本的なスケジュールリスク管理を実践しているのだと単純に考えるのです。
ほかよりもリスクの高いフェーズがあれば、そこにはさらにバッファを追加しておきましょう。代わりに、ほかのバッファを減らしてもよいでしょう。
最後に、「二重取り」していないことを確かめましょう。二重取りとは、タスクレベルに余分な時間を追加しているのに、フェーズレベルにも余分な時間を追加することを指しています。あなたが未知なものを扱うときに、いつも当たり前のように余分な時間を加味してタスク期間にバッファを追加しているなら、このテクニックはうまく機能しません。
さあ試してみましょう。うまくいくはずです。
この作品はクリエイティブ・コモンズ 表示 3.0 アメリカ合衆国ライセンスのもとに利用を許諾されています。
あなたは以下の条件に従う場合に限り、自由に
- 共有 – 本作品を複製、頒布、展示、実演できます。
- 再構成 – 二次的著作物を作成できます。
あなたの従うべき条件は以下の通りです。
- 表示 – あなたは適切なクレジットを表示し、ライセンスへのリンクを提供し、変更があったらその旨を示さなければなりません。これらは合理的であればどのような方法で行っても構いませんが、許諾者があなたやあなたの利用行為を支持していると示唆するような方法は除きます。
