【こうなってます】炎上現場 (前編)

お久しぶりです。ツナかふぇです。仕事に忙殺され、前回の投稿より大分間が空いてしまいました。

その原因…プロジェクトの炎上について、今回は書いていこうと思います。

プログラマー、システムエンジニアという職種には『炎上』『デスマ(デスマーチ)』という言葉が付いて回ります。

具体的には

①:製品の完成が納期に間に合わない!
②:稼働時間を上げないと追いつかない!
③:残業!  休日出勤! 満身創痍!

という流れで現場が疲弊していきます。

なぜこんな事が起きるのか? 現場では何が起こっているのか?

それを①~③順を追って、説明していきましょう。

 

①:製品の完成が納期に間に合わない!

 

これが炎上の入り口です。

原因はただ一つ【見積もりが甘い】こと。

本来10の労力で完成するものを5で出来る! と言ってGOサインを出してしまう事ですね。

『想定工数 – 実工数 』の負の値と、炎上度合いが比例します。

 

②:稼働時間を上げないと追いつかない!

 

①の対応策として本案を取った場合、炎上が加速してきます。

予算の都合か、該当スキルを所持する人がいないか、あるいはクライアントとの力関係からか

【人を増やせない】【納期を後ろにずらせない】

状況にある、ということです。

必然的に『個人の稼働時間を上げるしかない』となり、③へと繋がります。

 

③:残業!  休日出勤! 満身創痍!

当然こうなるわけですが…これが延々続くと、以下の現象が起きます。

・設計書を順守するようになる

 あれ、これは良い事なのでは? と思うかもしれませんが、そんなことありません。設計書が間違っている事に気づかない、あるいは気づいても放置するという事は、正常に動かないシステムを作るという事になります。
『設計書が間違っている可能性』を頭に置いておくのは、エンジニアの必須思考です。
…なのですが、炎上が続くと、疲弊から考える事を放棄しがちになります。

・現場のモラルが低下する

 全体的にメンバーが殺気立ち、出社時刻が適当になる、作業スペースが散らかる、言葉遣いが荒くなる、寝る… と混沌が渦巻きます。

・疲弊から作業効率が落ちる

 人間無茶は続きません。必ず作業効率が落ちます。炎上案件において、稼働時間と実績は必ずしも比例しません。…が、炎上に対する姿勢を見せる必要に迫られていると、出社せざるを得なかったりします。

・人が居なくなる

 そんな状況にキレて、人はどんどん離れていきます。ただでさえ稼働が足りない中で人員の確保が難しくなり、収集が付かなくなります。
仮に新しい人が助っ人で参画したとしても、その人は業務要件もコードの仕様も知らない為、必ず説明の為に工数を取る事になります。当人だって何の説明も無しには作業しようがありません。
 人を増やしたからと言って、その時点からいきなり作業の進捗は上がりません。むしろ一時的に他メンバーの進捗が遅れます。

 

④:そして終焉へ…

 

なんとか鎮火させたとしても、既に挽回不可能な赤字プロジェクトになっていることが殆どです。

さらには設計と実装の乖離や、スパゲティコード、コピペコードと、欠片も保守性のないシステムが残っていることでしょう。

納品したは良いが、今後どうやってこのシステムの面倒を見るのか? 協力会社は去っていき、中身を知っている人は残らない。でも中身は設計通りになっていない。

ここから改修できるのか? 不具合対応できるのか?

それは誰にも分かりません…。

 

と、実体験を元に書いてみました。改めて文章で見ると酷いですね 😥

これだけでは救いが無さすぎるので、後続の記事では『この状態になったらどう立ち回るべきなのか?』を、もう少し掘り下げて書いてみたいと思います。

中編 →

The following two tabs change content below.
関東圏の29歳ITエンジニア。自社開発、受託開発、SESを経て、業界経験6年半でフリーランスに転身。 設計…ER/ロバストネス/クラス図/シーケンス図 実装…java8~/spring/mybatis/SQL/html/css/jQuery/thymeleaf/bootStrap

Related posts

One Thought to “【こうなってます】炎上現場 (前編)”

Comments are closed.