1|2結合テストで遅延発生。原因は?ここでふと、疑問がわきました。そもそもテストの詳細なスケジュールは、何を基準に作成されたのだろう?プログラムの大きさ(ステップ数)、想定されるテストケースの数、障害の発生率......などでしょうか。障害の発生率が想定より低ければ、遅れが出ることはないでしょう。逆に想定より高ければ、遅れが生じてきます。今回、障害の発生率が想定より多いという状況はありませんでした。私は、障害対応の予定工数を都度確認してみることにしました。そこで気付いたのが、だいたいの工数が、私が考えるものよりも大きいということ。実際に工数を見積もった人に確認してみたところ、「バッファ込みの工数です」という答えが返ってきました(ある程度予想はしていましたが......)。バッファって何のためにあるのだろう。私は、以前読んだ『クリティカルチェーン』(エリヤフ・ゴールドラット著、ダイヤモンド社)のバッファマネジメントの話を思い出しました。く完了していても予定の終了日まで次工程に引き渡さない「パーキンソンの法則」などが発生する可能性があること、バッファとはプロジェクトマネージャが管理するものであるということが書かれていました(参考:@IT情報マネジメント用語事典「クリティカルチェーン・プロジェクトマネジメント」)。別に私は、書籍の記述を100%信奉するつもりはありません。すると、期間に余裕があるために、やらなくてもよい準備やテスト、そのほかの余分な作業を実施しているのかもしれないと考えました。遅延が発生しているのを、黙って見ているわけにはいきません。ものは試しと、すべての作業のバッファを私がいただくことにしました。結果、本当に必要と思われる作業に対して、実際にどれぐらい工数がかかったのか、そして遅れた場合はなぜ遅れたのかが明確になりました。バッファを取り除いたことで、1つ1つの仕事がチャレンジングになったのも良かったと思います。プロジェクトの中心は、やはり「人」このバッファマネジメント(?)がうまくいったのかどうか、確証は得られていません。このプロジェクトは、予定どおりに無事カットオーバーすることができました。プロジェクトに携わったすべてのメンバーの努力によるものだと思います。プロジェクトの中心には必ず人がいるということを、あらためて感じました。いい結果を出すためには、やはり人が働きやすい環境をつくることが大切ですね。人が中心にいるということは、絶えずいろいろな変化があるということです。その変化を感じるためにこそ、計画と管理が必要なのだと思いました。変化に対応するために、私も日々勉強し、「引き出し」を増やしておこうと強く感じました。大変なこともありますが、こうした大変さもシステム開発の魅力の1つだと思っています。筆者紹介アクセンチュア・テクノロジー・ソリューションズ新楽清高1973年生まれ。東京生まれの東京育ち。大学で都市計画を専攻後、社員100人ほどのシステムインテグレータにてSEとしてセールス〜要件定義〜開発・テスト〜運用までを行う。その後2003年11月にアクセンチュア・テクノロジー・ソリューションズに入社。Java、.NET、SAPにて大規模な基幹システムの構築に携わり、現在に至る。基本ポリシーは「楽しく」。新人、アーキテクチャチームで「運命の出会い」1人チームで悩む新人。乗り切る?この案件、ぜひ新しいテクノロジでやりましょう!初めてのトラブル対応。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。