■ 当初の目的
ソフトウェアプロジェクトのスケジュールに対する見積もりを改善する。
■ やったこと
ソフトウェアプロジェクトのスケジュールを作成したとき、当初予定の工数、つまり見積もり工数を記録しておく。プロジェクトが終わったら、実際にかかった工数を実績値として記録する。ここでは当初予定工数を100%としたとき、± 30%に収めることを目標にする。
例えば、10日間のスケジュールが実際には12日間かかったとすると、これは120%の実績値となる。この場合、当初予定の+20%なので、目標の範囲に収まったことになる。
■ どうなったか
実際にやってみると、200%を越えるスケジュール遅延が頻発していることが分かった。
〇 遅延の原因
- 本番障害により、リリースまでにかかった時間と同じぐらいの時間が障害対応に費やされた。この時は一度のパッチで修正しきれずに、二回パッチをリリースしている。
- 修正箇所のソースコードがスパゲッティ状態だったため、修正に予定の二倍の時間がかかった。
- データインポートを実施したが、インポートしたデータに誤りがあったため、作業そのものがやり直しになった。
■ 成果
この分析により、ソフトウェア開発プロジェクトのスケジュール遅延には、理由があることが分かった。原因を分析する中で、以下の事柄が明らかになった。
- 障害が起きやすい作業は何か
- 障害の発生源になっているシステム上の箇所。特定の箇所が多くの障害を引き起こしている。
■ 結論
予定と実績の比較には意味がある。それはシステム上の問題を発見できるためである。スケジュール見積もりの改善にも役立ったが、何より問題が発見できたのが良かった。
■ 今後
スケジュールだけでなく、予算や作業についても、予定と実績の比較をしてみると面白いかもしれない。予算がオーバーした原因は何か？ 作業が予定と違ったとして、それは何が原因だったのか？ 色々と分かりそうである。
