社会人

炎上プロジェクト体験記 1つ目【IT】

記事内に商品プロモーションを含む場合があります

私はエンジニアとして7年ほど働いてきました。

運が悪いのか普通なのかは分かりませんが、数々の炎上プロジェクトに巻き込まれてきました。

供養という意味を込めて、何回かに通して私が体験した炎上プロジェクトをご紹介していきたいと思います。

本記事は炎上プロジェクト体験記の1つ目です。

自動脆弱性診断サイトで大炎上

脆弱性診断をしたいサイトを登録しておくと、日次/週次/月次で登録したサイトの様々な脆弱性を診断するサイトの構築案件で2回ほど炎上しました。

このプロジェクトは既存システムが存在しており、既存システムのソースを流用しつつ機能追加もするというものでした。

人員はスキルあり、人数十分、PMも経験豊富ということもあって、当初はまさか炎上するようなプロジェクトだと考えられていませんでした。

しかし炎上したのです。2回も。

1回目の炎上

要件定義から製造までは、多少忙しくなることはあれど、炎上はしていませんでした。

しかし結合テストのフェーズで、炎上発生のキーの一つ、顧客の担当者が変わるというイベントが発生しました。

この担当者は非常に細かい性格で(悪く言えば神経質)、こちら側の報告に不審な点があると、理由が分かるまで追求してくるタイプの人でした。

変わった当初は、うわぁヤバい人が担当者になったなあ(笑)というくらいにしか感じていませんでしたが、結合テストの結果を報告するたびに、ガチでヤバい感じが出てきました。

そして、ある時顧客担当者がブチギレたのです。

「報告する内容が足りなさ過ぎる!」「バグが少ない!ちゃんとテストしているのか?」「テスト仕様書を見せてみろ!」「バグの理由はなんだ!」

ごもっともな内容でしたが、この要求を満たすために結合テスト仕様書を1から検討し直すことになり、10人程度が2週間ほど毎日終電、休日出勤、人によっては徹夜もやりますという状態でした。

ある程度は収まりましたが、結合テスト/総合テストが終わるまでの2ヶ月ほどは、かなり遅い時間まで残業が発生しました。

これは地獄でした。

みんな疲れ切ってしまっていて、ギスギスした現場になってしまっていました。

時は流れ、一応無事ではないですが総合テストまで完了し、後はデータ移行とリリースが残されることになりました。

そのため、数名を残してプロジェクトは解散となることで、現場はギスギスから解放されました。後味はとても悪いです。

2回目の炎上

データ移行、運用保守の契約を受注していたため、数名は引き続きこのプロジェクトで作業していました。私も引き続き作業することになりました。

データ移行は非常に大変でしたが、無事にやり遂げリリースまで完了しました。

リリース後、2ヶ月ほどは大変ながらもなんとかプロジェクトは回っていましたが、ある時、脆弱性診断のバッチで不具合が発生しました。

不具合自体はちょこちょこ発生していたのですが、この不具合は致命的な不具合でした。

脆弱性診断バッチはサービスの根幹となるもので、この不具合がある状態でバッチが動いてしまうと、処理が緊急停止してしまいユーザーはお金を払っているのにサービスを受けられないという、最悪な状態になってしまっていました。

この時点でかなり嫌な予感はしていました。燃える予感がしていたのです。。。

脆弱性診断の不具合自体は軽く徹夜をすることで、修正リリースをすることができましたが、不具合の原因に深刻な問題がありました。

不具合の発生した原因は、プロジェクトで流用した既存システムの処理でした。既存システムでその不具合が発生していないのに、新システムで発生した理由に炎上の要因がありました。

このプロジェクトでは PHP を使用していたのですが、新システムでは PHP のバージョンに最新のものを使用しており、現行システムのバージョンよりも新しかったのです。

このバージョンの差異が原因で不具合が発生していました。こちら側の落ち度ですが、現行システムから移行してきた、特殊なデータの場合にのみ発生したため、結合テストや総合テストで発見できていませんでした。

ここで例の顧客担当者がまたもやブチギレまして、「既存システムを流用している箇所を洗い出して、テストし直せ!すぐにやれ!」と言ってくるわけです。(まあごもっともな話なのですが。。。)

ここから大炎上です。1ヶ月くらい会社に住んでいましたね。耐えられなくなったら仮眠する様な生活をしていたので、1週間の睡眠時間は10時間ほどしかなかったと思います。

1ヶ月の稼働は少なくとも500時間くらいはあったと思います。

近くに銭湯があったことが唯一の救いでした。

最終的にはよそのプロジェクトから人を借りてなんとかなりましたが、本当にきつかったですね。。。もう同じことはできないと思います。。。

ちなみにバージョンアップが影響の不具合は、最初に発生したもの以外発見されませんでした。良かったような無駄なことしたようなって感じです。

プロジェクトの炎上は読めない

ということで2回も炎上したプロジェクトのお話でした。

このプロジェクト、当初は炎上するなんて想像もできないくらい、好条件が揃っていたのですが、イレギュラーケース(ヤバい担当者降臨)や、既存システムの流用に失敗などで無事炎上しました。

この案件からは安心できる状態なんて無いんだよということを学びました。

完璧だ。と思っていても何か穴があるんです。

脆弱性診断サイト自体はとてもいいもので、Webサイトを作成するために欠かせない脆弱性のこと、対策法などを学ぶことができたので、そこだけは非常に良かったです。

脆弱性をしっかりと対策したWebサイトを作成することは非常に大切です。

脆弱性の対策方法を学ぶのであれば、徳丸浩さんの「体系的に学ぶ 安全なWebアプリケーションの作り方」という本がおすすめです。むしろこの本以外にオススメがないくらいの完成度です。

Web サイトを作成する方は必ず読んでおいたほうが良い1冊です。是非読んでみてください。

炎上プロジェクト体験記は続きます。