「バッファ込み」の工数がスケジュール遅延の原因：システム開発プロジェクトの現場から（15）（2/2 ページ）

» 2008年06月04日 00時00分公開

[新楽清高，アクセンチュア・テクノロジー・ソリューションズ]

結合テストで遅延発生。原因は？

　ここでふと、疑問がわきました。そもそもテストの詳細なスケジュールは、何を基準に作成されたのだろう？

　プログラムの大きさ（ステップ数）、想定されるテストケースの数、障害の発生率……などでしょうか。例えば障害の発生率が想定より低ければ、遅れが出ることはないでしょう。逆に想定より高ければ、遅れが生じてきます。

　ですが今回、障害の発生率が想定より多いという状況はありませんでした。それでは、なぜ遅れるのでしょう？私は、障害対応の予定工数を都度確認してみることにしました。

　そこで気付いたのが、だいたいの工数が、私が考えるものよりも大きいということ。実際に工数を見積もった人に確認してみたところ、「バッファ込みの工数です」という答えが返ってきました（ある程度予想はしていましたが……）。

　バッファって何のためにあるのだろう。私は、以前読んだ『クリティカルチェーン』（エリヤフ・ゴールドラット著、ダイヤモンド社）のバッファマネジメントの話を思い出しました。そこには、スケジュールに余裕がありすぎると、作業着手を先延ばしする「学生症候群」、早く完了していても予定の終了日まで次工程に引き渡さない「パーキンソンの法則」などが発生する可能性があること、バッファとはプロジェクトマネージャが管理するものであるということが書かれていました（参考：＠IT情報マネジメント用語事典「クリティカルチェーン・プロジェクトマネジメント」）。

　別に私は、書籍の記述を100％信奉するつもりはありません。しかしもしかすると、期間に余裕があるために、やらなくてもよい準備やテスト、そのほかの余分な作業を実施しているのかもしれないと考えました。

　遅延が発生しているのを、黙って見ているわけにはいきません。ものは試しと、すべての作業のバッファを私がいただくことにしました。

　結果、本当に必要と思われる作業に対して、実際にどれぐらい工数がかかったのか、そして遅れた場合はなぜ遅れたのかが明確になりました。バッファを取り除いたことで、1つ1つの仕事がチャレンジングになったのも良かったと思います。

プロジェクトの中心は、やはり「人」

　このバッファマネジメント（？）がうまくいったのかどうか、確証は得られていません。ですがこのプロジェクトは、予定どおりに無事カットオーバーすることができました。プロジェクトに携わったすべてのメンバーの努力によるものだと思います。

　プロジェクトの中心には必ず人がいるということを、あらためて感じました。

　いい結果を出すためには、やはり人が働きやすい環境をつくることが大切ですね。そして人が中心にいるということは、絶えずいろいろな変化があるということです。その変化を感じるためにこそ、計画と管理が必要なのだと思いました。変化に対応するために、私も日々勉強し、「引き出し」を増やしておこうと強く感じました。

　いろいろと大変なこともありますが、こうした大変さもシステム開発の魅力の1つだと思っています。

筆者紹介

アクセンチュア・テクノロジー・ソリューションズ

新楽清高

1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス～要件定義～開発・テスト～運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。趣味はトラブル対応。

「次回」へ

「システム開発プロジェクトの現場から」バックナンバー