顧客のコンテンツデータを消失させた話

## 簡単な自己紹介

18日にポツンと空いていたので、枯れ木も山のなんとやら..で書かせて頂きます。

エンジニアとしてもうすぐ7年目になります。専門はバックエンド(メイン：Java/C#)です。
しかし、少人数開発かつ安定していない現場が多かったため、足りないロールは巻き取って仕事をすることが多く、AWSの構築を一部やったり、アプリ(iOS/Android/ReactNative)の面倒を見たこともあります。

最近１年で一番やって楽しかった仕事は、<a href="https://www.bitrise.io/">bitrise</a>でリリースやstgアプリ環境構築したこと。
一番嫌だった仕事は、超レガシーなReactNativeアプリをAndroid64bit対応でバージョンアップしたこと。(なお私はバックエンド担当...)
もう完全にバックエンド関係ないですね:relaxed:

## やらかした案件概要

エンジニアとして２年目の秋になります。
とある、Webサイト構築屋さんにエンジニアとして出向していた時になります。

この現場は良い言い方をすると、とても個人に裁量があって自由な会社。
基本的にミーティングは最初に説明するだけ。あとは納期だけ示されて、それまでに作っておけばOK。
コードレビューはないですし、テストも構築者が各自行うこと。テスト内容とか顧客からの要望がなければ作る必要はなし。
時期が来たら営業から本番環境の情報が渡されて、エンジニアが決められた日取りに一人で作業してリリースする。
もし、何か分からなかったら、その辺の人捕まえて聞いてね♪

そんな現場で<a href="https://ja.wordpress.org/">WordPress</a>(WP)新規Web案件2件を短納期で構築した後に、<a href="https://www.sixapart.jp/movabletype/">MovableType</a>(MT)案件にアサイン。

案件のざっくりした内容は・・・

- 既存Webサイトのリプレース案件
- 構築サイトは小さく、納期：3週間。
- 元のサイトもMTで構築されていて、引き続きMTで構築。
- お知らせ・ブログ記事は引き継いで欲しい。

## やらかした流れ
私「いやーMTとか経験ないんですけど、3週間いけるもんなんですかね？」
営業「大丈夫！大丈夫！ WordPressみたいなものだから！」

### とりあえずサクッと先輩エンジニアに聞いて構築開始
私「MTって現環境引き継いだまま、ローカル環境作るにはどうするんですかねー？」
先輩エンジニア「ローカル環境を作って、本番DBをダンプしてローカル環境用に一部直してリストアすればいいよー」

ということで、下記の手順で実施。

1. ローカル開発環境を作る
1. 本番環境のDBをダンプする
1. ローカル用に手直し(本番環境のURL/フルパスをローカル用に置換)
1. ローカル環境のDBにダンプした内容をリストアする

### ハマって実装ギリギリ
MTはかなりWPとかなり違うもので、全く思った通りにいかなったけど、色々考え方違うことを実感しつつ、
ドキュメントもそこそこあったので、駆使して実装することで確実に完了に向かっていった。

・・・しかし。実装終盤に全く原因が分からない事象に出会ってしまう。

あるコンテンツ内に関連する別コンテンツを入れ子構造(1対多)にしたテンプレートを実装した時のこと。
子コンテンツの内容を変更したので、全てのページの該当コンテンツが変わることを期待したのだが、
なぜか子コンテンツの内容が全く変わらない・・・。

いくらなんでも、こんな分かりやすいバグがあるとは思えない。
何かおかしいことした？...が。いくら確認しても実装ミスした感じはない。

結論から言えば、MTはコンテンツ保存時にサイト構築アクションが実行されて、影響あるページを静的HTMLとして
出力する仕組みになっているのだが、実装方法がまずかったか、構築アクションが適用されなかったようだ。
（もはや実装内容は覚えていないけど、おそらく自分の知識不足が原因だと思う）

結果として、期限ギリギリに。

### リリース日
厄介なことは多々あったけど、なんとかリリース日には間に合った！！
リリース手順等の確認とか全くできてないけど、基本的に開発開始と逆手順をすれば問題ないはず。

下記がリリース手順（基本的に、開発開始の方法と逆変換）

1. ローカル環境のDBをダンプ
1. 本番用に手直し(ローカル環境のURL/フルパスを本番用に置換)
1. 本番環境にログインして、本番DBに適用する
1. 本番環境MTの接続先を新規DB側に向ける
1. 問題が発生したら、DBの向き先を元に戻す

この手順でリリース後動作確認。問題なく動いてるようなので、顧客に確認してもらう。
（２−３時間後、OKもらう）

### 後日
営業から連絡を受ける。
「あのー・・。最近から３週前にかけて、ブログ記事がなくなったらしいんですけど、何か知りませんか？」

　　　:scream:！？

## 何が起こったか
ローカル開発環境を作ってから、実装完了までの間。顧客側でもブログやお知らせを配信しており、
開発環境にその内容を取り込まないまま、ローカル開発データを本番環境に上げた。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/318759/53653254-e42b-764f-5904-f1bd4bdb58e8.png)


## この事象を発生させないために何をすべきだったか
[絶対に必要だったこと]
先輩エンジニアに状況をしっかり説明してレビューをしてもらうこと。
少なくとも過去にやったことがないリリース(MTもそうだけど、データを継承したリプレース自体初めて)は必ず見てもらうこと。

[絶対に必要だったこと２]
顧客に対して、現状開発中のため、コンテンツの追加・編集・削除した場合は、その情報を共有してもらいリリースまでに取り込むようスケジュールすること。

[技術的には]
今回の構築では、コンテンツデータおよびテンプレートデータを構築してました。
そして、MTはテンプレートとコンテンツがDBに同梱されているため、基本的にはDBを適用するしかリリースできないと勝手に思っていました。

後日、先輩エンジニアから聞いたところによると、<a href="https://movabletype.net/2015/07/designimportexport.html">デザインのインポート・エクスポート機能</a>があり、デザインだけ既存DBに取り込むこともできたそうです。。。（最初に教えてくれョ・・・:sob:）

もちろん、コンテンツデータは開発側と顧客側の双方で追加しているので、その部分はマージする必要がありますが、
既存DBにこちらで作成した新規データを入稿すればいいだけなので、少なくとも顧客側のデータを消すなんていう恐れはなかったわけです・・・。

## 幸運にも大事にならずに済みました...
既存DBを残していたため、それを切り替えることによって、すぐに復旧はできました。
既存DBから、３週間分のデータ差分を営業の人に顧客とコミュニケーションを取って抽出してもらい、
新規DBに移植してもらったことにより、データの消失は防げました。（なので、、タイトル詐欺にはなります:sweat_smile:）

自分は、他社の人間ということもあり、自分が直接謝ることはありませんでしたが、
謝ってくれた営業さん。今回の件で、顧客からの追加要望のjsのIE7対応引き受けて対応してくれたデザイナーさん。
この時は、本当ありがとうございました。。。

## 最後に
「今回もなんとかできる！」そんな、慢心が招いた事態を今回題材にさせて頂きました。

今回、このような機会に改めて、回想してみました。
リリース日、この事態を自分で防ぐ方法はあっただろうか？
...おそらく無理だっただろう。あの時は、技術力もなく、間違った手順を間違いと気付けなかっただろう。

そうだとすれば。グループとしてどう防げばよかったのだろう？
その時、自分が先輩エンジニアの立場だったら、どういったことができただろうか？
こういった事態が発生する前に、若いエンジニアに伝えるべきはなんだったのだろう？


---気付けば中堅エンジニアとして、年数の浅いエンジニアとも仕事をすることが増えました。
今では自分の経験を踏まえ、**理解できていないことを気づかせる環境づくり**が一番大事なことだと思っています。
これにより、自分と同じような経験をするエンジニアが減るのであれば、これに勝る幸せはありません。

最後まで、おつきあい頂きありがとうございました。
最後に今回このような素敵なAdventカレンダーを開催して頂いた主催者様、
そして、拙い文章ですが、読んで頂いた皆様、本当にありがとうございました。