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