概要
転職してから、めっきり炎上案件に入ることがなくなりました。
大きな会社なので、どこかでは炎上しているのかもしれませんが、タクシー帰りとか、完徹してるとか、それで30連勤みたいな、そういう次元の話は私の周りにはありません。
前職では数年に一度くらいのペースで、別の場所で炎上したプロジェクトに開発者（火消し）として参画することがありました。
このままではそこで得た知見が消えてしまいそうなので、ここに残しておきます。
Here Comes A New 炎上プロジェクト
それは唐突にやってきます。
と書きましたが、社内で炎上プロジェクトがある、という噂は聞いていることが多いです。
でも自分が行くことになる予兆はなく、いつも急に声がかかる感じでした。
自分のところには上司、もしくは上司の上司から話が来ることが多かったです。いくつか例を。
例１
上司の上司「ねえ〇〇くん、夏休みってどこか旅行に行く予定があったりする？」
私「いえ、今のところ何の予定もないですよ。」
上司の上司「じゃあ、名古屋に旅行に行かない？食べ物美味しいし、会社からお金出すよ。」
私「お、行きます行きます。何すれば良いんですか？」
この後２ヶ月ほどホテル住まいすることになる。
例２
上司「ドームの近くでやってる案件が大変なことになってる。毎日こちらの仕事を定時までやった後で、あっちに移動して終電まで働いて欲しい。」
上司「そして土日も出来る日は働いて欲しい。」
私「ま、まぁわかりました。（移動の途中に自宅があるじゃないか）」
何か事情があれば拒否できるケースもありますが、自分はそういうのがあまりなかったので断る理由もなく炎上プロジェクトに参加していました。一旦拒否しても炎上プロジェクトはどんどん人を吸い込んでいくので、社内で一度目をつけられたらいつかは吸い込まれちゃいますしね。
プロジェクト参加
行った最初の日に、炎上プロジェクトがどれくらいカオスなのかが大体わかります。
私の今までの経験で言うと、別の拠点やプロジェクトの人間を夏休みや定時後に働かせるような炎上プロジェクトはものすごいカオスです。
なるべく自分が痛い目を見ないように行動する必要があります。
プロジェクトや担当する機能の説明
ドキュメントがあり、設計者がドキュメントの在り処を教えてくれる…のであれば問題ありません。
だいたい「この辺にあるから、不具合を対応するときに見ながらやって」みたいなことが多かったです。
そして仕様書のファイルが違うバージョンでいっぱいあったり、エクセルの仕様書が色んな色で訂正されてたり、取り消し線が引かれてたり、吹き出しが無数についてたり。
ひどいときには「〇〇さんが持ってる赤ペンが入った紙が最新」と言われたこともありました。
ここで大事だと思うのは「正しいドキュメントがどれかを把握する」ということです。
簡単に思えますが、思っていたドキュメントが、実は最新じゃなかった・・・ということが結構発生します。
また、コード設計とかエラー標準とか共通チェック仕様とか、まだプロジェクトが穏やかだった頃に作ってあるドキュメントがあったりするので、一通り存在を確認しておいたほうが良いです。たいてい古いですけど、対応を進めていくと後から話に出てくることが多いです。
そして、最初に説明してくれる人はそこまで説明してくれないです。
開発環境の構築
「ドキュメントがあるから、これの通りに作ってね」と言われて、そのとおり作れるのであれば問題ありません。私の経験では「誰々さん（一番大変そうなエンジニア）に聞きながら作って」と言われることが結構ありました。
ここで大事だと思うのは「構築手順をちゃんとドキュメント化する」ということです。
なぜなら、その人が倒れたときに、次に来た人の環境を作るのが自分になる可能性があるからです。
あと、そうじゃなくても、新しい人が来たときに「それを見ながら作ってね」と言えたほうが楽です。
そして、炎上プロジェクトの場合は、大抵また新しい人が来ます。波状攻撃のように来ます。
環境構築に付き合ってくれる人はそういうドキュメントを作る時間がないので、聞きながら自分で作ったほうが結果的に楽です。
不具合修正
炎上プロジェクトに途中から入る場合は、不具合対応部隊として入ることが多い気がします。
全体を知る
知ってそうな人（PMOとか）に、1日に起票される不具合の数と、1日に修正される不具合の数を聞いてみましょう。ここ1,2週間のグラフがあればなお良いです。
こういう炎上プロジェクトでは、こういう数字に関しては上から報告を求められるので、ちゃんと管理していることが多いです。誰も答えられないのであれば、この数字をとったほうが良いと誰かに言いましょう。
誰も取ってくれない場合、10分くらいでいいから時間をかけて自分で数えてみましょう。不具合の一覧と、それぞれの起票日、解消日があれば集計できると思います。
起票される不具合のほうが多い場合、先は長いです。そして、大抵は起票される不具合のほうが多いです。
修正される不具合の数のほうが多い場合は、終焉のタイミングがなんとなく予想できます。テストフェーズが進むなどした際に予想が覆ることもありますが、とりあえず心の拠り所になります。
仕様の正解を探る
参画したときに「正しいドキュメントがどれなのか」を把握していれば大丈夫と思いきや、そういうわけではありません。
テスト（特にユーザーのテスト）が始まり、要件レベルの修正が起票され始めると、正しい仕様は「仕様書に不具合票の修正内容を加味したもの」になることが多いです。
毎回仕様書をちゃんと更新することが望ましいですが、それが出来ているプロジェクトはカオスな炎上プロジェクトにはなりません。
ここで気にしておく必要があるのは「不具合票の修正内容同士の仕様バッティング」です。
ユーザーの希望を聞いて不具合の修正仕様を書いていると、気づかないうちに不具合票の修正内容同士で仕様がバッティングすることが結構あります。
その場合は、まずユーザーにどちらの仕様を採用するかを決めてもらうことが先決なので、修正するときには同じ機能に対する不具合は一通り目を通してから手を付けましょう。
リファクタリング
この状況でやるのか・・・という感じですが、やったほうが良いケースがいくつかありました。
エラーハンドリングとかの不備
あちこちで、エラーハンドリングの不備でエラーが出る、みたいな場合、共通クラスを作って、みんなそれを呼ぶようにすることで漏れなく対応することができます。
DB処理とかAPI処理とかだと、あとから「リトライ処理を入れてくれ」とか「ログに吐くようにしてくれ」とか言われても（ありがち）、対応しやすいです。
マジックナンバーがひどい
これが原因の不具合がいつまでたっても無くならないので、いっそマジックナンバーを無くしてしまえということがありました。
例えば、業者の名前が文字列としてあちこちに定義してあり、その値を条件に分岐している…みたいな感じのものです。
私のときは、コード用のクラスを準備してそこに集約したと思います。今だと違うやり方かも知れません。そもそも、流石に最近こういうのは無いのかな。
1ファイルのコード量が半端なく多い
1画面1クラスみたいに作っていると、1クラスのコードが数万行になりました…みたいなことがありました。
そういう画面は機能が複雑で不具合も多く、修正する機会が多いです。
1つのクラスを5,6人が別々の不具合対応で修正する、という事態になるので、後からでも無理矢理でも分けたほうが良いです。
新規機能開発
炎上プロジェクトに途中から入って新規開発がある、というのは多くはなかったですが、「後から機能が必要なことがわかった」とかで、たまに新規開発することがあります。
開発の進め方
進め方で大事だと思うのは「まずは適当に作る」ということです。
きっちりしたものを最初から作ろうとしても、新しく必要になった機能は大抵途中で仕様が変わるからです。「まずは正常系が何パターンが動くところまで何日くらいでつくりますね」という感じで進めたほうが良い気がします。
変更の受け方
途中で追加or変更要件が来ても、よほどインパクトの大きいものじゃない限りは、無視して最後まで作ったほうが結局は良いことが多いです。
理由は先程と同じで、後から来た要件は、仕様としてまだ柔らかいので、また変わることが多いからです。
それに、ずっと終わらないよりは「ここまで終わった」があったほうが、自分としても進んだ感が出ますし上の人もどこかに説明しやすいですしね。
さようなら炎上プロジェクト
プロジェクトが落ち着いてくると、徐々に人が減ってきます。
このときに、自分が抜けられるようにしておいたほうが、早く抜けられます。
出来る人をたくさん作る
自分だけが出来る、ということを極力ゼロにする、ということです。
これは普段の開発でも大事ですが、炎上プロジェクトの場合は「出来る人がやる」法則が強いので、自分だけが出来ることをゼロにするのは至難の業です。
あまりにカオスで場当たり的な不具合対応しかしていない場合は、いつでも抜けられますけど。
落ち着いてくると、そろそろ抜けていく計画を立てようという話になるので、積極的にいろいろなものを任せていきましょう。くらいしか出来ないと思います。
贅沢を言うと、抜ける側から「伝えたいこと」、残る側から「聞きたいこと」を出し合って引き継ぎができると良いですね。
円満離脱
炎上したプロジェクトの中でも発注側起因で炎上したものは、次のプロジェクトでも炎上する可能性が高いです。
いつか再会するときのために、円満にプロジェクトを抜けましょう。
仲が悪かったら次に炎上したときに呼ばれないんじゃないかという気もしますが、まあそれはそれ。
一緒に炎上プロジェクトをこなしたメンバーはある意味戦友です。
抜けるときはそう思ってないかもしれませんが、数週間が経って落ち着いて振り返るとそうなのです。
これは私がポジティブなだけかもしれませんが。
生活の話
仕事以外の話も書いておきます。
楽しみを作る
人間、どんなときでも楽しみは必要です。
昼食は豪華にしようとか、何人かで夕食を食べに行くとか、終電で帰ってから少しでもゲームするとか、何でも良いので楽しみを見つけましょう。
できるだけ毎日できる楽しみが良いです。
休日にしか出来ない楽しみは、次にいつ出来るかわかりません。
人間をやめない
「ずっと家に帰らなかったら、履いていた靴下が溶けた」という話を聞いたことはありますが、なるべくなら人間らしい生活をしたほうが良いと思います。
誰もが人間らしい生活をしたいと思っているとは思いますが、炎上プロジェクトにいると、意識しないと人間らしくいるのは難しいです。
ご飯を食べて、歯を磨いて、寝て、体を綺麗にしましょう。本当に。
対価を得る
みなし残業で残業代が固定だったりすると、炎上プロジェクトに入ってもあまり給料が増えません。あ、深夜と休日は付きますかね。
「どうせ給料増えないしなー」と思いながら働くのは精神衛生上非常に良くないです。心の支えは一つでも多いほうが折れにくくなります。炎上プロジェクトに入る際に「みなし残業外してくれないなら入らない」ときちんと交渉して、対価を得ましょう。
私の場合、途中でプロジェクトメンバー全員、みなし残業が外れたこともありました。（先輩社員が交渉してくれました）
おわりに
まだまだあるような気がしますが、ひとまずは以上です。
「僕は（私は）こういうのに気をつけてたよ」というのがあれば是非知りたいので、コメントいただけると嬉しいです。