労働基準法やコンプライアンスが重視される現代において、「デスマーチ（炎上案件）」は絶対悪とされています。私も炎上案件を他人に推奨する気は毛頭ありません。
しかし、過去に経験した「100時間近い残業」「休日出勤」「オフィスへの泊まり込み」といった地獄のような日々が、エンジニアとしての私の実力を劇的に底上げしてくれたのは、否定しようのない事実だと感じています。
あの地獄の中で、具体的にどんなスキルが血肉となったのかを振り返ってみます。
炎上の実態：動くゴールポストと絶望
文字通り「炎上したな」と呼べる案件は、過去に3回ほどあります。
原因は、自分の実力不足や交渉という考えがなかったこともありますが、最も過酷だったのは「動くゴールポスト」でした。
実際に動く画面を見た顧客が、「よくあるシステムだけど、これじゃない。こうしてくれないと完了にできない」と言い出します。百歩譲って別のやり方で対応するのは良いとしても、「スケジュールは変えたくない」と理不尽な要求を突きつけられます。数日、数週間遅れても実運用に影響がない部分ですら、です。
当時は「殴りかかろうか」と何度も思いました。また、同じ社内のチームメンバーの鈍い動きにもイライラが募っていました。
デスマーチがもたらした3つの圧倒的成長
そんな極限状態を乗り越えた結果、以下の3つのスキルが半強制的に身につきました。
1. 「手戻りを許さない」コーディング力と圧倒的なコード把握
「後で直す」余裕などないため、経験から「このコードだと遅くなる」「画面ではこう言われる」と予測し、最初からUXを意識したコードを一発で書くようになりました。
また、ずっとコードを触り続けていると、巨大なプロジェクトでも「どの辺りに何が書かれているか」を脳が自然に覚えるものです。結果、不具合が発生してもすぐ原因の特定と対応ができるようになりました。
2. 「言われっぱなしにならない」交渉力とリスク管理
請負開発において、顧客は平気でゴールポストを変えてきます。それを身をもって知ったことで、見積もりの時点でそのリスクを織り込むようになりました。
無茶な指摘に対しても、「修正はするが、スケジュールは調整させてほしい」と対等に交渉するようになりました。顧客側の都合で回答待ちになる場合は、その遅れがもたらすリスクと影響を事前に伝えて調整します。言われっぱなしにはならなくなりました。
3. WBS至上主義からの脱却と「逆算の計画力」
WBS（作業分解構成図）は至上主義ではありません。
「ゴールから逆算して何が必要か？」を俯瞰し、実装やテストだけでなく、対人コミュニケーションや打ち合わせなど、すべてを想定した上で「やるべきこと」を日単位・時間で収まるよう計画する力が身につきました。バッファを持たせ、現実的か、利益は出るかまで考えるようになりました。
平和な環境で育つ若手への本音
何かのフェーズや作業に集中できる平和な環境は素晴らしいと思います。
しかし、全体を俯瞰した上での動き、つまり設計やPGだけでなく「境界線の部分」や「次にやること」を見越して先回りして動かないと、ただ「対処しているだけの動き」になってしまい、あるべき姿が実現しにくい気がしています。
コーディングも保守対応も特段早くなく、設計も突っ込まれるところが多い若手を見ていると、コンプライアンス的には正しいと分かっていながらも、正直「ちょっと物足りないな」と感じてしまう自分がいるのは事実です。
コメント