デスマーチの跡形

そうそう、なぜ何人もの新人(下駄履いてたけど・笑)を
その【3次下請け】プロジェクトに投入できたかといいますと。

そこは、数ヶ月前に大規模なシステムリリースをしたばかりで、
俗に言うデスマーチが繰り広げられておりまして。

⇒デスマーチって何?と思った方はコチラへ

わたしが行ったチームは、
・システムリリース前に、散々お祭り騒ぎ(デスマ)を繰り広げる
(お祭り騒ぎ時の超過分費用は、2次下請けの持ち出し(自腹)だったらしい)
・リリース後は比較的安定稼動(データ件数が少なかった)
・プログラムを組める人が、引き続きデスマってる他チームに持って行かれる
・中間層がいなくなり、新たに人を投入する隙間が生じる
と言うわけで、「×月から○人、投入します」が通る環境だったのです。

で、「なになに、最初っから過酷なプロジェクトに行っちゃうの?」
と思っていたら・・・。

ぜーんぜん!でございました。

そのチームは、特に大きなトラブルもなく。
(というか、トラブる部分は、新人が安易に手を出せないような
コアな部分だったのでやらせてもらえず。)

新人がやることといえば・・・。

デスマーチ中にできなかった設計書のメンテナンスと、
デスマーチ中に手が出せなかったような細かな改善対応。

デスマ中は、設計書直すより先にプログラム直しちゃうんですよ♪
止まっちゃう処理をとにかく動かすことや、ない処理をとりあえず作ることが
優先されてしまう世界なのです。

んで、「設計書は後から直せばいいよ!」って放置しておきます。
そのうち、どれが修正対象なのか、わからなくなってしまいます。

それらを、結局新人がやるハメになりました。

片っ端からプログラムと設計書をつき合わせて、
独断と偏見でドキュメントを修正する日々。
もちろん、プログラムが正しいっていう前提ですよ。

プログラムの仕様も何も、新人には分からないから・・・。

上司は、「設計書とプログラムを見るいい勉強だ!」なんて言ってたけど、
今から思えば、まさにダメ・プロジェクトの典型よねぇ。

右も左もわからない新人が設計書を書き換えるから、
実際、だいぶ壊したと思うわ(笑)
その上、設計書の「変更者」欄に自分の名前入れるように言われたし。
何もわからないまま壊した上に、名前を残すなんて。ハズカシイ。

そうこうしているうちに、チームは一気に縮小体制に。

デスマ中は2次下請けの持ち出し(自腹)対応だったから、
システムが落ち着いてきたと見るなり、
「残業するな」とか「遊んでるなら人減らせ」とか
圧力がかかったようです。

ときどきCOBOLのプログラム修正が入るくらいで、
特に仕事もなく、毎日ほぼ定時に帰る日々が続きました・・・。

やることなくて「ヒマっすぅ〜」ってぼやいたら、
「人減らされちゃうから忙しい振りしろ!」って怒られたことも(汗)
Excelマクロの本を読むことすら却下されたのよ。

このプロジェクトでは、インターネットに接続できなかったので、
それはもう、地獄・・・でした。

結局。

新人ちゃんは、配属後数ヶ月で、そのプロジェクトを
追い出されることになりましたとさ。

ブログランキングへ
トラックバックURL
是非!コメントをどうぞ♪
名前:
URL:
  情報を記憶: 評価:  顔   星
 
 
 
書いてるヒト
いつの間にか、三十路の女。
ハルです。
訳あって会社を辞め、悠々自適のフリーエンジニア生活♪・・・とは、なかなか行かず。あぁ、人生っていろいろ。

このページに迷い込んだ記念にぜひ・・・ブログランキングへ
コメント

livedoor プロフィール
livedoor Readerに登録
RSS
livedoor Blog(ブログ)