お久しぶりです。ツナかふぇです。仕事に忙殺され、前回の投稿より大分間が空いてしまいました。
その原因…プロジェクトの炎上について、今回は書いていこうと思います。
プログラマー、システムエンジニアという職種には『炎上』『デスマ(デスマーチ)』という言葉が付いて回ります。
具体的には
①：製品の完成が納期に間に合わない！
②：稼働時間を上げないと追いつかない！
③：残業！ 休日出勤！ 満身創痍！
という流れで現場が疲弊していきます。
なぜこんな事が起きるのか？ 現場では何が起こっているのか？
それを①～③順を追って、説明していきましょう。
これが炎上の入り口です。
原因はただ一つ【見積もりが甘い】こと。
本来10の労力で完成するものを5で出来る！ と言ってGOサインを出してしまう事ですね。
『想定工数 – 実工数 』の負の値と、炎上度合いが比例します。
①の対応策として本案を取った場合、炎上が加速してきます。
予算の都合か、該当スキルを所持する人がいないか、あるいはクライアントとの力関係からか
【人を増やせない】【納期を後ろにずらせない】
状況にある、ということです。
必然的に『個人の稼働時間を上げるしかない』となり、③へと繋がります。
当然こうなるわけですが…これが延々続くと、以下の現象が起きます。
あれ、これは良い事なのでは？ と思うかもしれませんが、そんなことありません。設計書が間違っている事に気づかない、あるいは気づいても放置するという事は、正常に動かないシステムを作るという事になります。
『設計書が間違っている可能性』を頭に置いておくのは、エンジニアの必須思考です。
…なのですが、炎上が続くと、疲弊から考える事を放棄しがちになります。
全体的にメンバーが殺気立ち、出社時刻が適当になる、作業スペースが散らかる、言葉遣いが荒くなる、寝る… と混沌が渦巻きます。
人間無茶は続きません。必ず作業効率が落ちます。炎上案件において、稼働時間と実績は必ずしも比例しません。…が、炎上に対する姿勢を見せる必要に迫られていると、出社せざるを得なかったりします。
そんな状況にキレて、人はどんどん離れていきます。ただでさえ稼働が足りない中で人員の確保が難しくなり、収集が付かなくなります。
仮に新しい人が助っ人で参画したとしても、その人は業務要件もコードの仕様も知らない為、必ず説明の為に工数を取る事になります。当人だって何の説明も無しには作業しようがありません。
人を増やしたからと言って、その時点からいきなり作業の進捗は上がりません。むしろ一時的に他メンバーの進捗が遅れます。
なんとか鎮火させたとしても、既に挽回不可能な赤字プロジェクトになっていることが殆どです。
さらには設計と実装の乖離や、スパゲティコード、コピペコードと、欠片も保守性のないシステムが残っていることでしょう。
納品したは良いが、今後どうやってこのシステムの面倒を見るのか？ 協力会社は去っていき、中身を知っている人は残らない。でも中身は設計通りになっていない。
ここから改修できるのか？ 不具合対応できるのか？
それは誰にも分かりません…。
と、実体験を元に書いてみました。改めて文章で見ると酷いですね 😥
これだけでは救いが無さすぎるので、後続の記事では『この状態になったらどう立ち回るべきなのか？』を、もう少し掘り下げて書いてみたいと思います。
入会申込
ログイン
