未来への出発までのひと時


by for_funekun
カレンダー
S M T W T F S
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

プロジェクトは開発拠点を一箇所に集約すべきだと思う。

木曜日の午前中、大きなトラブルが発生した。
水曜日に発生したトラブルの処理の仕方に問題があったことが原因だ。
影響範囲はエンドユーザにまで及び、リカバリ作業は今日も続いている模様。
当社のかなりお偉方まで登場し、徹夜での対応が続く。

僕の担当している業務には直接的な影響はなかったものの
支援作業をしていたため仕事が少々遅れた。
そんなことよりも大きな影響が出るのは明日以降の作業の進め方だろう。
ちょっとした本番システム変更作業の許可を取るにも
大変な稼動がかかるのが容易に想像できる。

今回のトラブルの直接的な原因は
この「ちょっとした本番システム変更作業」の作業ミスから発生しているからだ。
作業ミスの原因は作業の省略である。

通常、担当者は変更したかった部分以外に変更されていないことを必ず確認する。
担当者はその作業を怠り、さらに作業を実施したと上司に虚偽の報告をした。
上司も内容の確認をせずに本番システムに反映する許可を出した。
ここでは担当者と上司が通常取るべき手順を怠ってしまった。
決まりきった手順であればあるほどこのようなことが起こりうる。

さらに言えばこの上司に対してチェックが行き届かなかったのは
プロジェクトの本部と開発拠点が離れていることも原因の一つだと思う。
プロジェクトの本部は会社のお偉方からの目が行き届くよう
首都圏に集められている。
しかし、開発拠点はプログラムの開発さえできればどこでもよいという考えから、
うちのプロジェクトの開発チームは土地や人件費の比較的安い地方で作業を行っている。
通常はテレビ会議や電話を使って連絡を取っているため困ることは少ないのだが、
今回のような作業の確認自体は本部で実施するのは非常に手間がかかる。

プロジェクト内でも本部と開発拠点が離れていると
細かな調整が行き届きにくいと言われていたが、
トラブルのような迅速性が求められるときはなおさら厳しいということがわかった。
幸い、うちのプロジェクトは日本人しかいないが
中国人やインド人に開発を任せることになったら今回以上に厳しいのではないだろうか。
[PR]
by for_funekun | 2005-08-14 20:51 | business