以前にここでも書いたけれども、計画を立ててソフトウェア開発を実施したときに『「計画通りに開始して、計画通りに終了する」ことが良いことだ』という誤解があると、結果としてプロジェクトはうまくいかない。
以下のブログ記事を読んで考えたこと。
プロジェクトのスケジュールバッファは、工程ごとの中にマイルストーンや依存関係を見ながら組み込む。名前づけは大切だ。決してバッファなどとしない。それをプロジェクトメンバが自由に使ったり、当てにしてもらっては困るからだ。これは、プロジェクトのバッファであって、プロジェクトマネージャがリスクが発現したときのへそくりなのだから。
2012-10-07
作業ベースの計画の問題
作業を基準にした計画はスケジュール遅延を招きがちなのには、いくつか理由がある。
- 作業は早く終わらない
- スケジュールの遅れは先へと伝わる
- 作業は独立していない
皮肉な事だけれども、WBS的な管理の大事な事がアジャイル開発の本にわかりやすく書いてある。詳細は同書を読んでいただくとして、ポイントはこんなところだろう。
- パーキンソンの法則により、作業期間は期日まで拡張される。作業は期日より早くに終わりにくい。
- 遅れだけが後続作業に伝播する。前倒しは伝播しにくい。
- ある作業が遅れた場合に「次は挽回する」と思いがち(だがしかし、類似の作業もやっぱり遅れる)。
一般的な世界観だと良いこと(ポジティブな結果)と悪いこと(ネガティブな結果)は釣り鐘状の確率で発生しそうな気がする。いわゆる正規分布である(注:下図は適当です)。
しかし、ソフトウェア開発の作業においては因果律は歪んでいる。この事実をきちんと把握しておく事が大事だと思う。
そして、この因果律の歪みをどう制するかがポイントだろう。もちろんアジャイル関連書籍では短サイクルのフィードバック制御を推すだろう。しかしそれは非常に短絡的な思考であって、もっと工夫をこらす余地があると思っている。
常に生産性の最大化を考える
WBSやガントチャートは、プロジェクトを管理するためには重要なツールだけれども、あくまで目安であるということを忘れてはいけない。WBS通りにプロジェクトが進めば良いというのは誤解だ。WBSの状況がどうかにかかわらず、プロジェクトチームの生産性を常に最大化するようなマネジメントをしないと、前述の理由でスケジュールは遅れるのである。
- すべてのタスクは、可能な限り最短の時間で完了するのが正しい。
- 空いたリソースは他のタスクアサインに振り替えるか、将来のリスクを回避する新たなタスクにアサインする
- 余力は常にゼロとなっている状態が正しい(リスクバッファは除く)
- もちろん、不適切な高稼働などは生産性や品質を下げるので駄目である(念のため)
それでもソフトウェアプロジェクトは遅れていく。これは、たった一つのバグ、不良が全体計画を破壊するリスクがあるからである。これに対してはスケジュールとコストのバッファを確保して対応するしかないだろう。
参考
- ストーリーポイントの見積りは何故時間の見積りより良いのか | Ryuzee.com
- ストーリーポイントによる見積もりが良いという話だけれども、そうではなくて「生産性を最大化する見積もりとマネジメント」が効いているのだというのが個人的感想。