炎上プロダクトと、従事したエンジニアの心情

今年は初めて受託開発の炎上を経験したので年が明ける前にその時の心情を書き記しておこうと思う。あくまで従事したエンジニアの心情であるので、案件については言述していない。

本題

自分の経験した炎上はスケジュールが圧倒的に短くて発生したタイプの炎上だった。この記事ではスケジュールが短すぎた場合、エンジニアの心情はどういったものか、プロダクトはどうなるかを記述する。

スケジュール

とりあえず、納期や工数をマネージャー層が全て決定した状態でエンジニアに丸投げするのはやめよう。

ふつう案件にアサインされたエンジニアは要求仕様書から機能の洗い出しを行うが、この時点で 納期が短すぎるのでは？ となった場合はその時点からマネージャーに対して 強い不信感 を抱き始める。（逆に、期間が長いと感じたらマネージャーへの好感度は上がる！）

納期を変えることはできないのでしぶしぶ開発は始めるが、実際に時間が足りなくなった時は クソみたいな見積もりをしたマネージャーの尻拭いをさせられている という考えが絶対に付きまとうので、精神上も良くない。そしてこの時のモチベーションは世界最低ランクだ。

この現象の対処法としては、やはりアサインが想定されるエンジニアも見積もりに参加させることが一番良いと思う。作業者自身もマネージャーと一緒に見積もりを行うことで、作業者に納期への納得感を与えることができるし、なにより技術を良く分かっていないマネージャーの適当なクソ見積もりを防ぐことができる。

この点からも、やはり現役エンジニア（実際の作業者推奨）を見積もりに参加させるのは必須と感じた。

プロダクトの品質

開発（プログラミング）に費やす時間の多くは アルゴリズムを考える 時間でもある。自分は特にその傾向が強く、一旦の実装をとりあえず作ってから綺麗なコードに書きなおすことが多い。

これは実際に案件のスケジュールが完全に遅れた状態になって分かったのだが、スケジュールが切羽詰っていると自分は製品を作るためのプログラミングではなく 帰るためのプログラミング を行うようになるらしい。

帰るためのプログラミングが何かというと、先述した アルゴリズムを考える 時間を大幅に省き、一旦の実装（ HACK 的実装）のままどんどん機能追加を行うことだ。なんたって時間の余裕がないので、 綺麗なコードへの書き直し = 追加の残業 となる状態で自分はコードのリファクタリングまで行えなかった。なぜなら、絶対に残業はしたくなかったからだ。（結局時間が足りず、機能追加で残業や徹夜までしたが）

これがプロダクトの品質に悪いのは明白だが、エンジニアの精神状態にも大きなダメージを与える。コーディングする度に自分やチームメンバーのソースコードを見てリファクタリングしたい気持ちを抑え、「俺はこんな実装をしたいわけじゃないのに…」と思いながら新しい機能を追加していたあの頃は、きっとエンジニアとしては死んでいたのかもしれない。

プロダクトの品質はそのまま改修のしやすさにも繋がる。一時的な実装が多いということは、次に機能追加や改修の案件を担当した人に負債がのしかかるということだ。時間が無いなら仕方ないが、出来るだけ綺麗なコードを心がけたい…。

テスト

リファクタリングを行う時間が無いと言うことは、単体テスト・結合テストのコードを書く時間も無いということだ。いや今回の場合、初めの頃はなんとかテストを書くスタイルだったが、度重なる機能追加と機能変更などの作業増加によって書く時間が明らかに無くなったと言ったほうが正しい。

今回で言うとテストチームがバグ出しを頑張ってくれたので、プロダクトとして最低限の品質は保障できた。中には単体テストをちゃんとやっていれば出ないようなバグも数あり、テストの大切さを改めて実感。（何よりも余裕を持ったスケジュールのほうが大事だけどな）

自分への影響

自分の精神的なストレス耐性は低いらしく、残業と徹夜はかなりしんどい思い出だった。

生きる活力がかなり削がれていたし、具体的には唇がよく切れるようになった。メロンパンを食べた時は、かじった部分が赤くなっていたくらいだ。

おわりに

この遅れが見積もりの失敗であれマネジメントの失敗であれ、どちらにせよ 遅れ （極端に言えば炎上）はプロダクトの寿命を縮めることに繋がることに間違いはない。

それは純粋なコードの品質の低さ、テストの未実施などもあるが、何より疲弊したモチベーションの低いエンジニアから生み出されたプロダクトが良いものであるはずがないからだ。マネージャーにはエンジニアのモチベーションを第一に考え、慎重に見積もりやマネジメントを行ってもらいたい。

そしてやはり、残業は悪い文明である。